Modify (fix) the transceiver module API

Hello everyone,

While discussing with Thomas Eichinger during corrections to the #1223 PR, we wondered about possible modifications to "fix" the transceiver module API.

Specifically: * the get_channel()/set_channel() functions are supposed to work with int32_t numbers for channel number... Since these channel numbers never go beyond 100, maybe can we change the type to an int: this would improve performance and reduce memory/register consumption on 16-bit architectures like MSP430; * the get_address()/set_adress() functions work with the radio_address_t type, which is an alias to uint16_t defined in a legacy header file (sys/transceiver/radio/types.h); forcing radio drivers to depend on an old file stored in the transceiver module tree doesn't seem very optimal to me. I thought to change these functions' signature to use uint16_t, or move the definition of radio_address_t type to the drivers/include/radio_driver.h file. If we choose the latter solution, we may also define specific types for long (64 bit) addresses, PAN ID and the likes...

Of course, changing the transceiver module API may also imply changes to other modules (probably the set of available radio drivers)...

What are your opinion on this subjects?

Hi,

as already mentioned in the PR discussion I'm also in favour of changing the mentioned types but can't estimate the implied changes to other modules than radio drivers.

Can someone give an educated estimation how much effort it would take to adopt the network stack to this?

Best, Thomas

Dear Kévin,

we discussed this topic today offline in our dev & maintenance meeting.

In short it was consensus that changing the mentioned types is sensible although we didn't agree whether to define explicit types like radio_address_t, going with uint16_t and similar or change to unsigned int.

In the bigger picture we want to hold a dedicated meeting discussing how to refactor/harmonise/optimise the network stack to keep (or get:)) it clean and maintainable. Discussing transceiver API would definitely be on this agenda too.

We didn't specify a date yet but wanted to ask if you'd be interested in participating in this meeting remotely?

Best, Thomas

My two-cents worth is that for such a small device operating system, it would be good to focus on having one way to interface to radio/network packets. Whatever the hardware that's actually being used.

I know this isn't the traditional network stack approach, but in this day, different radio/network hardware devices come and go on a regular basis without substantially changing in capabilities.

I'd be happy for example if the Native Linux port could broadcast to MQTT, or if not that, then Sockets/UPD-Packets. And if not that, then onto a serial-device. But not neccessarily all together at the same time.

Best Regards

David

On

Sorry to double post.

I just wanted to add that it would be a really easy entry point for us hackers if we could use an Atmega328p based system + nrf24L01+ modules and do some sort of communication with those.

Maybe it already exists somewhere and I didn't know about it.

Regards

David

Hi David,

>In the bigger picture we want to hold a dedicated meeting discussing how >to >refactor/harmonise/optimise the network stack to keep (or get:)) it clean >and >maintainable. Discussing transceiver API would definitely be on this >agenda

My two-cents worth is that for such a small device operating system, it would be good to focus on having one way to interface to radio/network packets. Whatever the hardware that's actually being used.

The "Transceiver API" already exists. It is the low level hardware abstraction layer. If I understand you correctly, what you suggest already exists.

While it is possible to use it directly (and might be necessary for devices with too little memory or sufficient depending on your application), there are higher level interfaces that build on the Transceiver API.

I'd be happy for example if the Native Linux port could broadcast to MQTT, or if not that, then Sockets/UPD-Packets. And if not that, then onto a serial-device. But not neccessarily all together at the same time.

Does this look good? http://riot-os.org/#usage (scroll down to the diagram)

I'm not sure I understand what you mean by broadcasting to a serial device, but you can already use UDP sockets and the application is hardware independent: https://github.com/RIOT-OS/RIOT/pull/1251/files

I am not aware of an MQTT project.

Cheers, Ludwig