stm32f4 and EasyBee-SO IEEE802.15.4

Hello everybody,

I would like to use RIOT with stm32f4-discovery boards and EasyBee-SO IEEE802.15.4 tranceiver modules (datasheet[1]). Is there already a driver implementation for these modules available?

To understand the API structure I've had a look at the driver implementations for other boards (telosb, wsn430-v1_4 and z1). Is it correct that there has to be a specific driver implementation for the stm32f4-discovery (driver_cc2420.c) based on the interface functions in /drivers/cc2420/include/cc2420_arch.h to get this work? Is there something else to care about?

Best regards, Marco

[1]http://docs-europe.electrocomponents.com/webdocs/09d4/0900766b809d4827.pdf

Hi Marco,

welcome to RIOT!

I would like to use RIOT with stm32f4-discovery boards and EasyBee-SO IEEE802.15.4 tranceiver modules (datasheet[1]). Is there already a driver implementation for these modules available?

No there is no support for these modules in RIOT, yet.

To understand the API structure I've had a look at the driver implementations for other boards (telosb, wsn430-v1_4 and z1). Is it correct that there has to be a specific driver implementation for the stm32f4-discovery (driver_cc2420.c) based on the interface functions in /drivers/cc2420/include/cc2420_arch.h to get this work? Is there something else to care about?

Yes, cc2420_arch.h is the main interface needed to implement to add support. Additionally there is cc2420_spi.h in the same directory which has to be implemented.

The stm32f4-discovery however is somewhat different to the other, msp430 based, platforms as it already implements the new peripheral driver interfaces, namely spi.h and gpio.h in `drivers/include/periph` directory. These should take a lot of hassle from you and make porting way easier. As a reference how these driver interfaces are deployed for a radio driver you can take a look at the implementation for the at86rf231 chip.

Due to the fact the msp430 based platforms (telosb, z1 …) don’t implement the peripheral driver interfaces yet, you’d still have to wrap the functionality of the periph drivers by the functions defined in cc2420_(arch|spi).h.

Hope this helps and don’t hesitate to ask any upcoming questions here on this list or in the IRC. Looking forward to review you PR for this!

Best, Thomas

Hi Thomas and Marco.

I like to do the same in the future, using a STM32F4 Discovery with a CC2420 radio.

But at the moment my spare time is to less :-/

It is a philosophic question but I think the other option is to implement a new S/W driver layer (module) in the CC2420 driver, which acts as a I/F between the existing CC2420 driver and the new driver I/F as provided by the STM32F4....

Or do I'm thinking to simply?

Best regards Joachim