Need some orientation about using vendor SDK when porting MCU

Hello Riot Devs,

As I have written before, I would like to use Riot in my 6lowPan project that is using CC1310 and CC1350 MCU.

No long ago, Texas Instruments have separated its common provided SDK into CC13XXWARE and CC26XXWARE. Currently there are many code that are still equals, but I did a file to file compare using Meld and found significant differences between some of them (9 files).

What I heard was that in the next MCUs versions (CC1312 and CC1352) more differences will come...

Besides that, those MCU have written in they ROM the most used SDK's driverlib binaries. So using the binaries instead flash them can give us more space for the applications.

So I would like to use headers and driverlib from CC13XXWARE in a best way that would fit in Riot and also facilitate maintenance when new updated come.

Would like to hear suggestion about what would be the best approach to work on this.

thanks for any comment,


Hi Cristiano,

I think in general, the inclusion of at least the vendor/firmware headers for those CPUs should probably be done in a similar fashion than the inclusion of the stellaris ware (cpu/stellaris_common). But dependent on the amount of headers (or even library source files), it would be definately worth a thought to consider adding the vendor libraries as packages. This way there would be no need for keeping all these files in the RIOT source tree directly, and code duplication would not be an issue. Further, it would be simple to update the libraries. Drawback here is, that we/someone would need to provide a public available repository containing these libraries - I guess TI is not doing this, right?

Cheers, Hauke

Hi Hauke,

I took more time than I was expecting to understand the changes that the new version of TI's CC13x0 sdk [1] have brought.

The SDK have generalized some of its functionalities to allow one application to run on more than one of TI's platforms and also use another RTOS.

They achieved that creating multiple highlevel drivers that interact with the lowlevel drivers and have created a set of 7 interfaces called DPL (Driver Porting Layer) that allows the SDK to interact with TI-RTOS or FreeRTOS when is necessary.

The high level SDK is now responsible to initialize the board, Gpio and interrupts and also peripherals as I2c, spi, watchdog, uart, etc. Also, the most important to me, manage power and RF, letting the SO to deal with threads and other lower level stuffs.

So, unfortunately seems that it is doing what RIOT-OS also is doing and won't be possible to do what I was having in mind initially (just reuse the highlevel drivers as package). But seems that the best approach will be to mimic some of its behaviour and use the low-level driver in the Riot-OS port.

I'm trying now to understand a bit more how Riot-OS works. For while, I just run some few native examples and read some pages at the github wiki.

I'm trying to find any documentation about how RIOT is managing power levels and also how it deals with watchdog, but couldn't find any. Who is responsible to initialize those services?

best regards,


1 -