CC13xx Application Integration Survey

[jpnorair 340]

Hey folks:

 

I've been working on CC13xx for some time now, porting OpenTag and various other new stuff to it.  I'm not using TI-RTOS -- too clunky.  As usual (for those who know me), I've pushed the RF to the limit and it is shaping up to be a formidable LPWAN/LAN option.

 

Anyway, I'm trying to decide how I want to enable 3rd party applications.  NuttX is one option, but someone (or I) will need to port that, too.  Energia/MT might be another option -- we'll still need to port that.  I'd be happy to take any information on this topic.  What would be best?

 

1. Network processor with another MCU for application FW

2. NuttX

3. Energia-MT

4. Something else

[Rickta59 589]

Energia-MT is really tirtos

[spirilis 1,265]

I think #1 is going to make a handful of folks happy, and practically might work for a lot of people, but it's not "sexy" in my opinion.  That said I am doing my own Network Processor interface firmware but only for the "base station" application--hooking it up to a Raspberry Pi 3 in my instance.  The remote nodes will all run firmware directly on the CC1310.

 

I'm curious if there's any interpreted languages worth considering, like Forth or Lua.  Never used either of them personally but the "era of tiny programmable radio nodes" is really upon us with the tech enabled by these chips.

 

My own stuff will be C atop TI-RTOS for now.

[jpnorair 340]

Energia-MT runs atop TI-RTOS.  It could be made to run atop something else.

 

I have two issues with TI-RTOS:

 

1. The build environment is such a disaster.  If there were a standard build environment, not so burdened by eclipse, that would help a lot.  As it stands, it is not something that can be distributed in the way I need to distribute (which is open source with licensable closed-source tie-ins).

 

2. It's too general purpose.  The number one job I need to do is MAC and network processing.  Some of the MAC is offloaded to the radio core in the CC13xx implementation, but nonetheless I need a certain degree of asynchronous task management, and usage of ISRs, that isn't worth the trouble of TI-RTOS.

 

NuttX is easier to integrate than TI-RTOS, since it is organized like a normal project.  But there's a lot of work to port it.

 

Another option is "RIOT," which I need to evaluate.

 

eLua was a thought.  It would be a more serious thought if someone was already working on it, for CC13xx/CC26xx.

 

Forth is something I've used in the past, and it can be added as a bonus nonetheless.  Forth is ideal for doing embedded shells.

 

Getting back to TI-RTOS, a lot of the work is already done, but it will be such a headache to manage in the future.  At the moment, it's only good for reference purposes.  Again, if someone knows of a normally organized source distribution, I'd love to know.

[zeke 693]

What about FreeRTOS?

What about MicroPython?

[jpnorair 340]

What about FreeRTOS?

What about MicroPython?

 

My opinions:

 

1. There's a reason FreeRTOS is invisible in IoT -- too slow for networking applications.  API is also cumbersome.  The point of adding an upper-level OS is to make it easier to program applications than it is now.  So "POSIX-like" is an important attribute, or alternatively "Arduino-like."

 

2. MicroPython is way too heavy, won't fit on the device.

 

Yesterday I took a look at "RIOT."  My first opinion is that the website and marketing are more impressive than the actual product, but I'm giving them a chance to contact me and set it all straight.  I actually hope that it's workable for me.

[jpnorair 340]

Answering some of my own questions (for posterity):

 

Turns out that all I need to do to port most TI-RTOS drivers to another OS is to provide an interface to five headers.  So that's good news for Energia-MT.

 

Here's a link, describing more.  You can see the driver support matrix, but scroll down to the "Driver Ports" section to see the specific method for attacking a port job.  I tip my hat to TI, they did a nice thing, here.

Drivers: TI-RTOS Full Driver API Reference

[spirilis 1,265]

Answering some of my own questions (for posterity):

 

Turns out that all I need to do to port most TI-RTOS drivers to another OS is to provide an interface to five headers.  So that's good news for Energia-MT.

 

Here's a link, describing more.  You can see the driver support matrix, but scroll down to the "Driver Ports" section to see the specific method for attacking a port job.  I tip my hat to TI, they did a nice thing, here.

Drivers: TI-RTOS Full Driver API Reference

That's awesome, I didn't know about that.

[fatihinanc 14]

Hi jpnorair,

 

Did you check this ? http://www.ti.com/tool/download/SIMPLELINK-CC13X0-SDK

I think, you can find some useful information under doc folder. It seems TI will officially support both FreeRTOS and non-RTOS'ers.

[jpnorair 340]

Hi jpnorair,

 

Did you check this ? http://www.ti.com/tool/download/SIMPLELINK-CC13X0-SDK

I think, you can find some useful information under doc folder. It seems TI will officially support both FreeRTOS and non-RTOS'ers.

 

Thanks, it's a decent reference.  FreeRTOS is supported through the "Driver Ports" mechanism.

 

I've already implemented the "at" feature for OpenTag which will take care of the ClockP requirements.  The other requirements are Mutex, Semaphore, etc, which are more or less compatible with CMSIS-RTOS interface requirements, so ok there, too.  For Hwi, it's just busy-work.

 

Frankly, the TI drivers are high latency and suboptimal, but for now they will do.  It beats trying to implement an asynchronous driver on a tight schedule, for the modules I don't care about so much.