SPI driver for SPIRIT1 Module on X86 platform

[Jayaram Matta]

Posted on April 25, 2017 at 13:47

Dear Developers,

    This is Jayaram Matta ,Now I want to write a SPI Driver for Spirit1(X_NUCLEO-IDS-01A4 [868 Mhz]) on X86 Platform. for the spirit1 module I want to add support for

http://en.wikipedia.org/wiki/6LoWPAN

over

http://en.wikipedia.org/wiki/IEEE_802.15.4

to the Linux kernel 3.6(&above).With this we can turn a Raspberry Pi into a 6LoWPAN border router.

     If any of you tried this please suggest on it.

[Gregory Nutt]

Posted on August 14, 2017 at 18:00

Is there any kind of standard about how a non-IEEE 802.1.5 radio interfaces with 6LoWPAN?   I see that you mention 6LoWPAN over IEEE 802.1.54, specifically.  Are you thinking of doing this like Contiki?

Contiki solved this by adding a 25 byte 'fake' IEEE 802.15.4 at the beginning of each payload. With this (and something Adam calls the null RDC), Contiki was able to make the Spirit1 radio look enough like an IEEE 802.15.4 radio for 6LoWPAN.  Is that what your Linux implementation would do as well?  Seems wasteful since the preferred packet size is less than the 96 byte FIFO sizes (although it should be possible to go much larger with some integration effort).

I have recently integrated the Spirit1 radio into the NuttX 6LoWPAN.  The NuttX 6LoWPAN derives from the Contiki 6LoWPAN but has diverged quite a bit. 

NuttX does NOT use any fake 'IEEE 802.15.4 header' but, instead, uses the native radio MAC layer. Thus, the NuttX Spirit1 6LoWPAN will never be able to communicate with either Contiki or any platform that 'support[s] 6LoWPAN over IEEE802.15.4'

This is why I ask about the standard?  Is there one?  I would prefer not to added a bogus IEEE 802.15.4 that is used for nothing other than to keep the software simpler and burns up 25% or your radio bandwidth.

Thoughts?

[Gregory Nutt]

Posted on August 14, 2017 at 19:21

I am also thinking about simple point-to-point 6LoWPAN support for the super cheap NRF24L01 radios (32 byte payload). And BLE.  BLE 4.0 is limited to 33 byte packets with only 20 bytes for payload.  With L2CAP that can be extended but you still could not fit the max IEEE 802.15.4 packet into a single frame.  BLE 4.2 eliminates this limitation, however.

So, it seems to me that it is a tremendous limitation to have to carry around a garbage IEEE 802.15.4 header in all radio frames.