Re: [riot-devel] Proposal: Use Gitter to allow users and developers easier and simpler chat functionality

2017-01-18 Thread Johann Fischer

> I am a relatively new user to Riot OS. I understand that this type of 
> proposal from a new user may be frowned upon or unwarranted. So I understand 
> if this idea gets shot down and closed. However, I would like to see if there 
> is any interest in using Gitter rather than freednode and the mailing lists 
> (or maybe the mailing lists stay in parallel) for developers and users to 
> chat.
> I have worked with other open source projects (ardupilot for one) that use 
> Gitter for real-time interactions between developers and with users. The 
> interface is clean and easy to use, integrates with GitHub nicely, and has 
> infinite message persistence.

It sounds interesting, there are still some obscurities.

What is the definition of this real-time, is it hard real time or very hard
real-time? Because only the very hard real-time gives the most fixed connection
between the user and developer.

Also how infinite is this infinite persistence?

> Does anyone else think this would be a big improvement in helping the 
> community grow?
Sure, I fill it already, it is most funny mail what I have read here. Also
this mailing list has a (not infinite) persistence.

devel mailing list

Re: [riot-devel] Organizing device drivers

2016-07-12 Thread Johann Fischer

On Tue, 12 Jul 2016 10:49:07 +0200
Peter Kietzmann <> wrote:

> Another solution would be to handle common and individual functions in 
> one file (without #ifdef). This might bloat code size but allows usage 
> of different versions in parallel. Also, it does not bloat the file 
> structure. The problem about naming schemes is still present here.

I prefer clear only this solution, with the difference to handle common
and individual functions in one directory. 
The derivative functions can be controlled using C if statements, which should
be optimized by the compiler and the modern linker should remove the
unused functions. I pour a little oil into the fire: some developer overdo it
with the macros and the driver (also other) sources look like "a macro-monster
has puked on the display".


Johann Fischer
devel mailing list

Re: [riot-devel] Notification: Biweekly virtual meeting @ Wed Jun 15, 2016 2pm - 3pm (RIOT Events)

2016-06-15 Thread Johann Fischer

Am 15.06.2016 um 14:35 schrieb Martine Lenders:

Should we rathe change to skype & co?



Johann Fischer
devel mailing list

Re: [riot-devel] Regarding RNDIS support

2016-06-06 Thread Johann Fischer

Hello Stefan,

Am 06.06.2016 um 14:39 schrieb Stefan Schmidt:

I am working on usb device support for RIOT. There is a PR[1] for it,
but it is outdated and will be rebased/updated with [2].

[2] supports kinetis and sam[r,d]-21. The CDC-ACM and CDC-ECM support
is very anstable and WIP. Currently I am working on the stability of

I plan:
- remove CDC-ECM first
- add a netdev2-802154-over-usb interface and opposite driver for
linux kernel

Could you elaborate on this part? I'm not sure I understand what your
plan is here.

If your plan is to expose 15.4 level API over USB and write a matching
Linux Kernel driver that fits into linux-wpan at least Alexander and
myself would be interested in your plans. :)

That's exactly what I planned. For the beginning we can take the netdev2 
for it. If we (someday) have a proper MAC in RIOT, then it may be a 
better way to use it with linux hardmac interface and to build a 15.4 
dongle based on RIOT.

We currently have even the hardware for it [1] and a SAM-R21 Xplaned 
board can also be used as the dongle.

Unfortunately, I have some ugly bugs in CDC-ACM code and the code needs 
clean up, when it is fixed i will update [2].



Johann Fischer
devel mailing list

Re: [riot-devel] Regarding RNDIS support

2016-06-06 Thread Johann Fischer


Am 06.06.2016 um 11:55 schrieb shishir tiwari:


As RIOT support Ethernet devices and USB device , Is someone working
on rndis(Remote Network Driver Interface Specification)  Protocol.??

I am working on usb device support for RIOT. There is a PR[1] for it, 
but it is outdated and will be rebased/updated with [2].

[2] supports kinetis and sam[r,d]-21. The CDC-ACM and CDC-ECM support is 
very anstable and WIP. Currently I am working on the stability of CDC-ACM.

I plan:
- remove CDC-ECM first
- add a netdev2-802154-over-usb interface and opposite driver for linux 
kernel :-)

About RNDIS:
- why should RIOT supports a Microsoft proprietary protocol?
- why not CDC-ECM or CDC-EEM ?



Johann Fischer
devel mailing list

Re: [riot-devel] USB BLE HCI protocol

2016-02-08 Thread Johann Fischer

Hello Phanindra,

Am 08.02.2016 um 11:03 schrieb PHANINDRA SURA:


I would like to work on the above issue, related to Bluetooth low Energy,a
topic of my interest.
Please tell me the pre-requisites to be learnt for contributing to this

You need the following hardware:
- a Bluetooth compatible transceiver connected to a NXP Kinetis or Atmel 
SAM[R,D]21 MCU (for these both exist the usb device driver for RIOT).

You need the following software support:
- a Bluetooth compatible protocol stack (there is no one mainline)

Where can I find relevant material to build my knowledge on these

See [1...3], but based on the questions that you ask, I do not think it 
is an appropriate project for you, maybe one of [4]?


Johann Fischer
devel mailing list

[riot-devel] usb device stack ...

2015-11-05 Thread Johann Fischer

Hello hardworking developers,

if someone wants to test "USB Device Stack # 3890" on Phytec boards or 
want to use the Board (PhyNode, pba-d-01-kw2x) as a boarder router, I 
have completed the PR with instructions for the modifications [1].


Johann Fischer
devel mailing list

Re: [riot-devel] Using C++ in device drivers

2015-07-10 Thread Johann Fischer


What are your opinions on writing device drivers or system modules in C++?

Please under no circumstances. Is there something worse, how about APL 
or Pascal? :-)

I know some of the more constrained platforms might not yet have C++
support, but still it might be an interesting option for some device
drivers. C++ objects for example can be used as an alternative to the
device descriptor pattern we are using in many drivers.

What's wrong with the device descriptor? Is the CPP Object something 
else? The scope in which CPP would be used for RIOT, is just an 
extension of C with poor readability and design.

I don't have any particular driver in mind, I just want to hear any
opinions around the community.

It is noteworthy that this discussion occurs repeatedly in open source 
projects. It's pretty much my opinion about CPP (except for verbal abuse):

And that is also interesting:

Johann Fischer
devel mailing list

Re: [riot-devel] Notification: Hack'n'ACK @ Tue Jun 30, 2015 5pm - 10pm (RIOT Events)

2015-06-30 Thread Johann Fischer

Hi Oleg,

Am 30.06.2015 um 12:06 schrieb Oleg Hahm:

Dear readying IOTlers,

is anyone planning to join tonight's HA session remotely?



Am Mon, Jun 29, 2015 at 03:00:05PM + schrieb Google Calendar:

This is a notification for:

Title: Hack'n'ACK
When: Tue Jun 30, 2015 5pm - 10pm Berlin
Where: c-base Berlin; HAW Hamburg
Calendar: RIOT Events
 * Martine Lenders - creator

Event details:

Invitation from Google Calendar:

You are receiving this email at the account because
you are subscribed for notifications on calendar RIOT Events.

To stop receiving these emails, please log in to and change your notification settings for
this calendar.

Forwarding this invitation could allow any recipient to modify your RSVP
response. Learn more at

devel mailing list

devel mailing list

Johann Fischer
devel mailing list

Re: [riot-devel] C++ Style Guide

2015-06-25 Thread Johann Fischer

Hi Raphael,

Am 25.06.2015 um 11:09 schrieb Hiesgen, Raphael:


it is time to write a C++ Coding Style Guide for RIOT. Since C and C++ have 
different traditions here, I will simply start to suggest using the C++ Style 
used in CAF [1]. While it is not identical, the style is relates to the 
guidelines used by Google and C++ Standard Library.

How I see it is very similar to RIOT coding style.  2 spaces per 
indentation level is not acceptable to me, should be 4 as in C coding 
style. Otherwise, I find it very good.

By the way, can someone explain to me short why we need C ++ at all?

Johann Fischer
devel mailing list

Re: [riot-devel] Board Selection for RIOT

2015-05-29 Thread Johann Fischer

Hello Alexander,

Phytec are happy to support master's students. If your work is related 
to RIOT or IEEE802.15.4 stack on Linux, we can support you with our 
phyNODE's [1] or the IoT Kit [2]. Please describe briefly your work and 
send it to me.


Best regards

Johann Fischer

Am 29.05.2015 um 05:19 schrieb Alexander Talavari:


As part of my MScThesis i will be devoloping on RIOT and i was interest
on your suggestion on what board i should buy.

I am already testing it on my Linux Mint image but it would be nice to
have the board that plays the best with RIOT.

Best regards,
Alexander Talavari

PS I am copy pasting the description of my Thesis as proposed by my
professor fyi

RIOT [1] is an open source operating system designed for small and
resource constrained devices. Such devices are expected to be the norm
in the Internet of Things (IoT). RIOT provides support for standardized
IoT protocols (e.g., 6LoWPAN and CoAP), as well as, as for experimental
architectures (e.g., CCN-lite, a lightweight version of the CCN
Information-Centric Networking [4] architecture [2]). FIT-IoT lab [3] is
a distributed testbed that enables IoT experimentation at a large scale.
FIT-IoT provides a variety of devices that can be used for experiments,
including devices equipped with the RIOT OS. The purpose of this thesis
is to implement a simple application for exchanging content (e.g.,
sensor measurements) in RIOT. The application will be developed in two
versions one using CoAP and another using CCN-lite. Both versions will
be evaluated and compared in the FIT-IoT lab.
[2] CCN-lite, a lightweight implementation of the Content Centric
Networking protocol CCNx of XEROX PARC, 2014 (
[4] G. Xylomenos, C.N. Ververidis, V.A. Siris, N. Fotiou, C.
Tsilopoulos, X. Vasilakos, K.V. Katsaros, G.C. Polyzos, “A Survey of
Information-Centric Networking Research,” IEEE Communications Surveys
and Tutorials, vol. 16, no. 2, pp. 1024-1049, 2014

devel mailing list

devel mailing list

Re: [riot-devel] kinetis common - differences between families

2015-03-16 Thread Johann Fischer
Am Sat, 14 Mar 2015 13:59:06 +0100
schrieb Jozef Maslik

Hi Jozef,

 Some example with major differences:
 SPI has min 3 variants: DSPI (K family), SPI (L, M family), SPI(L0x
 family) UART has min 3 variants: 1. K, M family, 2. L family, 3. L0x
 family low power UART is in L families (except L0x)

We currently have the conflict in spi. The driver for the SPI at KL0x
(or KW01) can simply mean spi_kl.c, etc...
 Some functionality (as @Joakim wrote) can be handled by conditional
 compilation like KINETIS_UART_ADVANCED, but I think, some extended
 functionality can be omitted because it is not interesting for our
 use case.

We have done so for uart.

 But I think, best way is to say, which families are interesting for
 RIOT OS and compare only these. Maybe wiki page can be helpful for
 this task.

Coordination: RIOT port for Freescale Kinetis CPUs:

 At this moment, I’m working with Cortex M0+ families (which are not
 supported on RIOT yet) - I have port on KL02 and in future I want to
 do port for KW01 (if someone else do not do it).

RIOT port for the KW01Z128 SiP, outdated, I'll update it in the next

 From my point of view, best option is to have one common
 kinetis_family directory with all driver regardless of the family.

Johann Fischer
devel mailing list

Re: [riot-devel] About function pointers

2015-02-20 Thread Johann Fischer
Am Fri, 20 Feb 2015 08:01:58 +0100
schrieb Oleg Hahm

 Was this a vote for a function pointer based HAL or just a
 Torvalds-like reflex?  If the former is the case, then I'm apparently
 the only one - counting the silent people on this topic as agreeing
 or not caring - against this approach. In this case I would advice to
 rethink and remodel the whole driver and HAL design. With the use of
 function pointers it could be made extremely more (pseudo)
 object-oriented what make many things much more convenient to

Hi Oleg,

I vote for function pointer based HAL and I think more of them will
make RIOT much better :-).

Johann Fischer
devel mailing list

Re: [riot-devel] Switch to BSD?

2014-12-16 Thread Johann Fischer
Am Tue, 16 Dec 2014 12:44:57 +0100
schrieb Oleg Hahm

 Hey Kaspar!
  If RIOT is BSD'ed, for *me* personally time spent on it is not fun
  time I like to in my unpaid spare time anymore, it becomes work
  that is also fun. Work others can (and will) sell under their terms.
 I totally don't get this point. How do more possibilities to work
 with RIOT for *others*, take fun away from *you*?
  (L)GPL guarantees that my contribution will stay part of something
  that might improve, but is always available to me under clear
 I disagree. The RIOT community guarantees that your and everyone
 else's contribution stay part of open and free software that might
 improve. Additionally, it might become part of something else, true.
I agree with Kaspar. Also as a company we have interests that if a
competitor uses our work, it would be forced to admit changes or
improvements back.

Best regards
Johann Fischer
devel mailing list

Re: [riot-devel] Switch to BSD?

2014-12-11 Thread Johann Fischer
On Tue, 9 Dec 2014 16:31:00 +0100
Emmanuel Baccelli wrote:

 I agree with you: we need another Linux and not another Contiki. But
 two questions:
 (1) can we realistically mimic the Linux story and stay with LGPL?
 (2) why would RIOT necessarily become another Contiki if the license
 evolves to BSD/MIT?

 Concerning (1): what does our experience from the last year show? That LGPL
 is far from a perfect solution, because too many company lawyers cannot
 deal with it. On the other hand, we know that BSD/MIT also has its down
 sides. So we have to trade-off between the dangers of BSD/MIT and the
 dangers of LGPL. There is no perfect solution, I agree. But still, we
 have to make a choice.
 On one hand, if we do not change the license, we can force people to do
 things our way, and it has indeed moral value. But it's difficult to force
 people/companies to do things. Those who do not want to, or cannot, give
 back will simply not use RIOT in the first place -- hence a much slower
 adoption that looks like a potentially fatal problem in the short term.

 If we change the license, some people/companies could indeed fork and close
 their source, and that is not what we want. However, these people will use
 RIOT and have a chance to change their mind about contributing back -- when
 they realize the burden of rebasing their code all the time. The bet is
 that the momentum in the community will remain sufficiently attractive to
 aggregate enough contributions to thrive in the mid-term.

Hello Emmanuel,
sorry for late reply. The company where I work develops and produces embedded
boards and makes the portings of linux kernel. We know the advantages and
disadvantages of (L)GPL. We spend time and money to porting linux to our
boards because we want to sale hardware and our customers benefit from it.

 What is the most unclear to me is: what are the consequences of the choice
 of license in the long run?
Can you explain exactly what you expect of licence change? That more hardware
will be supported? That RIOT will be more spread?
There are also companies that have made the ports for contiki but
will only give the porting for the hardware back to the project, but not the
improvements of core (I can not say more).

 However, one thing is for sure: this question is irrelevant if we're out in
 the mid-term.
 The value of an open source community is equally (i) the quality of the
 code base it provides and (i) the liveliness of the community. So
 concerning (2), do you think BSD/MIT would:
 - harm the RIOT community?
-yes, not everyone will agree with the change.

 - harm the RIOT code base?
-no, but I think it will not improve the code base.
 If so how, and at which stage (short, mid long term), and how bad? Is it
 worse the risks of too slow adoption if we stay with LGPL? This is what we
 really have to gauge now.

Johann Fischer

devel mailing list