CMSIS RTOS support.

[Lincoln Simmons]

Hello,

I am looking at porting some existing application + driver level code to use NuttX which previously ran on FreeRTOS.  I've found the code utilized a FreeRTOS CMSIS interface layer for task creation (osThreadDef, osThreadCreate, etc...) and initially I thought this would be great because I assumed there may be an existing NuttX implementation of cmsis_os.c.

After looking this morning, I cannot seem to find a preexisting implementation, or even a reference to CMSIS in any NuttX documentation or discussion on this group. 

1. Is there a reason NuttX doesn't appear to support CMSIS RTOS on first Google?
   
2. Will I run into issues if I try and implement a subset of the cmsis_os.c to support NuttX?

Full disclosure, I have just started looking at this and am new to NuttX and RTOS's in general.  I haven't reviewed all of the code I'm working with, but I think it's just needing a simple task_create() type interface, and maybe some standard scheduling functions like delays and signal interrupts.

Does anyone have any comments on this?

Thanks!

[Alan Carvalho de Assis]

Hi Lincoln,

There is an old discussion on previous Yahoo group mailing list about CMSIS.

It is better to create at complete/native NuttX port, more info:

http://nuttx.yahoogroups.narkive.com/QxSBuUvM/cmsis

BR,

Alan

On 3/21/18, Lincoln Simmons <lincoln...@gmail.com> wrote:
> Hello,
>
> I am looking at porting some existing application + driver level code to
> use NuttX which previously ran on FreeRTOS. I've found the code utilized a
>
> FreeRTOS CMSIS interface layer for task creation (osThreadDef,
> osThreadCreate, etc...) and initially I thought this would be great because
>
> I assumed there may be an existing NuttX implementation of cmsis_os.c.
>
> After looking this morning, I cannot seem to find a preexisting
> implementation, or even a reference to CMSIS in any NuttX documentation or
> discussion on this group.
>

> 1. Is there a reason NuttX doesn't appear to support CMSIS RTOS on first
>
> Google?
> 2. Will I run into issues if I try and implement a subset of the

> cmsis_os.c to support NuttX?
>
> Full disclosure, I have just started looking at this and am new to NuttX
> and RTOS's in general. I haven't reviewed all of the code I'm working
> with, but I think it's just needing a simple task_create() type interface,
> and maybe some standard scheduling functions like delays and signal
> interrupts.
>
> Does anyone have any comments on this?
>
> Thanks!
>

> --
> You received this message because you are subscribed to the Google Groups
> "NuttX" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to nuttx+un...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

[patacongo]

Non CMCIS code will be accept into the NuttX repositories unless it is properly released with the NuttX BSD license and is 100% compatible with the NuttX coding standard in every way: http://nuttx.org/Documentation/NuttXCCodingStandard.html

Nor will I accept any duplicate or alternative implementations for any logic that is already present in the OS.  Use of copied CMSIS files only in order to avoid effort is not an acceptable justification for it inclusion.  NuttX is an original OS and not a redistributor of 3rd party files nor is it a minimal effort body of software.

[Lincoln Simmons]

Awesome. I did not see this discussion. I will look it over, thanks

-Lincoln

[Lincoln Simmons]

Thanks for the response. To be fair, I wasn't referring to actually incorporating CMSIS-core support into core NuttX.  I understand this would duplicate unnecessarily duplicate functionality.  However, I'm specifically referring to the CMSIS-RTOS API layer shown here (Not the CMSIS-CORE:

I have application code which previously interfaced with FreeRTOS through the generic CMSIS-RTOS API defined here: https://www.keil.com/pack/doc/CMSIS/RTOS/html/usingOS.html

I was just wondering if there was a reason I couldn't find an implementation of cmsis_os.c for NuttX, other than someone just hadn't made one and published it.  For reasons, I'd like to continue to keep this application compatible with FreeRTOS, and a cmsis_os.h layer for NuttX would help maintain that requirement for me.

I was planning on going this route but wanted to make sure there wasn't something I was missing.

Thanks!

[patacongo]

NuttX is a POSIX standard, Unix-like OS.  It will never support any non-POSIX application interfaces such as those provided by FreeRTOS or ChibiOS or mbedOS or Zephyr.  All application interfaces must conform to documented standards for Unix-like operating systems and be specified at OpenGroup.org (or in common practice with Linux or BSD).  There will never be non-standard application/OS interfaces.

So, now that that I understand what you are asking.  The answer is clearly no.  What you are described can never be accepted upstream.  Read the "mission statement" for NuttX on the opening page of this group.  That would violate the fundamental nature of the OS and destroy its reason for being.

[Lincoln Simmons]

Okay good answer, Thanks.  I will think about my direction more... :)

[patacongo]

I have tossed around the idea in the past of developing a FreeRTOS portability layer.  Such a thing would not be pat of the OS, but rather part of the application. perhaps a library.

But on further thinking, that is not really a feasible concept because of the vastly different device interface model:  NuttX uses a strict POSIX device diver model; FreeRTOS uses a C-callable, free-for-all, HAL.  There is no way to reconcile those two models.

So it follows that any OS API that deals with tasks is non-POSIX.

[Alan Carvalho de Assis]

Hi Lincoln,

I don't know how complex is your FreeRTOS application, but I can say
that using POSIX you can get things working fast because it is very
well documented and there are tons of examples to base on.

What microcontroller are you planing to use?

BR,

Alan

On 3/21/18, Lincoln Simmons <lincoln...@gmail.com> wrote:

[Lincoln Simmons]

Alan, Thanks for the response.

It is an application that interfaces with a wireless radio over SPI.  We're porting it to a Nordic nRF52832 SoC, have NuttX running on the nRF52 ARM core, and the NuttX driver for the radio appears to be communicating with the chip over SPI.

The "application" is basically a MAC for the radio with some higher level functions on top.  It previously ran on an STM32 chipset with FreeRTOS.

My background is more baremetal and proprietary (non-RTOS) embedded work, so I'm 'graduating' to a higher level.  If you have anything to point me to that is basically a beginners guide to POSIX API, I would appreciate it.  I should learn it anyways to understand how to write Linux drivers and other applications.  I notice a lot of the API in the NuttX User Guide says, "This is a NON-POSIX interface" , which is a little confusing to me. Example, how does task creation work in a POSIX compliant way?

Probably dumb question, sorry.

Thanks!

[Alan Carvalho de Assis]

Hi Lincoln,

I started the nRF52832 last year, but I stop working on it because I was busy:

https://bitbucket.org/acassis/nuttx_nrf52

Now I will restart working on it. If you want to help you are welcome,
since you worked on baremetal, it could be useful to do the MCU
bring-up.

There are a lot of POSIX stuff on the Internet that you can use as
base to create applications. Also many looks, like the "POSIX
Programmer's Guide" - Donald A. Lewine.

BR,

Alan

>> > email to nuttx+un...@googlegroups.com <javascript:>.

[patacongo]

...  I notice a lot of the API in the NuttX User Guide says, "This is a NON-POSIX interface" , which is a little confusing to me. Example, how does task creation work in a POSIX compliant way?

There is no concept of a "task" in POSIX.  In fact, the concept of a task is not well-defined at all.  POSIX talks only about threads and processes.  Tasks are unique to RTOSs and have no POSIX APIs.  This is all pretty will covered in the following:

http://www.nuttx.org/doku.php?id=wiki:nxinternal:tasks-vs-processes

http://www.nuttx.org/doku.php?id=wiki:nxinternal:tasksnthreads