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)...
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?
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?
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.
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.
>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.
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: