Comparison to FreeRTOS

[Justin Mclean <ju...@classsoftware.com>]

Hi,

Possibly off topic so feel free to ignore this. 

But other then the licence (which is GPL so that may be reason enough) I’m curious to to how the aims and functionality of this project compares to something like FreeRTOS.

Thanks,
Justin

Re: Comparison to FreeRTOS

[Justin Mclean <ju...@me.com>]

Hi,

> - I personally find FreeRTOS painful to read because of excess
> #ifdef’ing.

:-) Yep the equivalent Mynewt code is a lot more readable to my eyes.

Thanks,
Justin

Re: Comparison to FreeRTOS

[marko kiiskila <ma...@runtime.io>]

One thing that I did not like about working with FreeRTOS was
that OS interfaces were abstracted too much.

Specifically this was bothersome when there was a need to
inspect the state of data structures (mutex, semaphore etc), and
gdb was not able to find the data structure definition to print out.

However, I did like the ease of porting that OS to different CPU architectures.

> On Oct 25, 2015, at 11:00 AM, Sterling Hughes <st...@apache.org> wrote:
> 
> I'll let others chime here as well, but he's what I'd say:
> 
> FreeRTOS is a relatively simple, straightforward RTOS that is ported
> to a lot of platforms.  It's well tested.  Outside of the RTOS core,
> it offers a FS and IP stack, and not much else.
> 
> In the core, I think we're doing a few things in addition to that:
> 
> - HAL: We have the basics of the hardware abstraction layer up and
> running, but the goal is to make this more complete.  This is one of
> the things I think Arduino has done an excellent job on.  When you
> download the OS for your platform, there should be a well-develop HAL
> that allows you to read/write GPIOs, manage analog input/outputs,
> control servos, etc in a platform independent fashion.
> 
> - Package Management and Build: While the Newt tool is more painful
> than make, especially at the moment.  The reason we've gone to the
> effort of developing this, is so we can allow people to develop and
> redistribute source packages.  It should be easy to compose an
> embedded project, with standard re-usable libraries (and we want to be
> able to accomodate thousands of these!), building from an OS core.
> 
> You start with the core OS, and HAL, and then can select which
> packages you need for your application, and developing a connected
> becomes more about the glue and the application logic, then about
> developing a library to control a motor or writing a full Thread
> stack.
> 
> - I personally find FreeRTOS painful to read because of excess
> #ifdef'ing.  I'll admit, my eyes bleed easily:
> https://github.com/cjlano/freertos/blob/master/FreeRTOS/Source/tasks.c
> 
> Our equivalent of this file:
> 
> https://github.com/mynewt/larva/blob/master/libs/os/src/os_sched.c and
> https://github.com/mynewt/larva/blob/master/libs/os/src/os_task.c
> 
> Cheers,
> Sterling
> 
> 
> 
> 
> 
> On Sun, Oct 25, 2015 at 2:30 AM, Justin Mclean <ju...@classsoftware.com> wrote:
>> Hi,
>> 
>> Possibly off topic so feel free to ignore this.
>> 
>> But other then the licence (which is GPL so that may be reason enough) I’m curious to to how the aims and functionality of this project compares to something like FreeRTOS.
>> 
>> Thanks,
>> Justin

Re: Comparison to FreeRTOS

[Sterling Hughes <st...@apache.org>]

I'll let others chime here as well, but he's what I'd say:

FreeRTOS is a relatively simple, straightforward RTOS that is ported
to a lot of platforms.  It's well tested.  Outside of the RTOS core,
it offers a FS and IP stack, and not much else.

In the core, I think we're doing a few things in addition to that:

- HAL: We have the basics of the hardware abstraction layer up and
running, but the goal is to make this more complete.  This is one of
the things I think Arduino has done an excellent job on.  When you
download the OS for your platform, there should be a well-develop HAL
that allows you to read/write GPIOs, manage analog input/outputs,
control servos, etc in a platform independent fashion.

- Package Management and Build: While the Newt tool is more painful
than make, especially at the moment.  The reason we've gone to the
effort of developing this, is so we can allow people to develop and
redistribute source packages.  It should be easy to compose an
embedded project, with standard re-usable libraries (and we want to be
able to accomodate thousands of these!), building from an OS core.

You start with the core OS, and HAL, and then can select which
packages you need for your application, and developing a connected
becomes more about the glue and the application logic, then about
developing a library to control a motor or writing a full Thread
stack.

- I personally find FreeRTOS painful to read because of excess
#ifdef'ing.  I'll admit, my eyes bleed easily:
https://github.com/cjlano/freertos/blob/master/FreeRTOS/Source/tasks.c

Our equivalent of this file:

https://github.com/mynewt/larva/blob/master/libs/os/src/os_sched.c and
https://github.com/mynewt/larva/blob/master/libs/os/src/os_task.c

Cheers,
Sterling





On Sun, Oct 25, 2015 at 2:30 AM, Justin Mclean <ju...@classsoftware.com> wrote:
> Hi,
>
> Possibly off topic so feel free to ignore this.
>
> But other then the licence (which is GPL so that may be reason enough) I’m curious to to how the aims and functionality of this project compares to something like FreeRTOS.
>
> Thanks,
> Justin