Go Down

Topic: ChibiOS/RT RTOS version 2.6.0 (Read 12302 times) previous topic - next topic

fat16lib

I have ported ChibiOS/RT 2.6.0 to AVR, Due, and Teensy 3.0 Arduinos.  The download file is ChibiOS20130710.zip http://code.google.com/p/rtoslibs/downloads/list.

ChibiOS/RT 2.6.0 has many improvements over 2.4.3.

Here is a summary of ChibiOS/RT features:
Quote

ChibiOS/RT is a fast compact full featured RTOS written by Giovanni Di Sirio.

ChibiOS/RT is designed for embedded applications on 8, 16 and 32 bit microcontrollers; size and execution efficiency are the main project goals.

The ChibiOS_AVR library supports AVR Arduinos. The ChibiOS_ARM library supports the Due Arduino, and Teensy 3.0.

ChibiOS/RT microkernel features:

    Static architecture, everything is statically allocated at compile time
    Best in class context switch performance
    Preemptive multithreading
    128 priority levels
    Round-robin scheduling for threads at the same priority level
    Software timers
    Counting semaphores
    Mutexes with support for the priority inheritance algorithm
    Condition variables
    Synchronous and asynchronous Messages
    Event flags and handlers
    Queues



MarsWarrior

Great!

This is for Arduino IDE 1.05 and 1.52 I assume?

fat16lib

I tested AVR with 1.0.5, Due with 1.5.2, and Teensy 3.0 with 1.15/1.0.5.

MarsWarrior

Thanx.

I see that the Arduino port only contains the ChibiOS core sources.
I wonder if it is also possible to 'port' the I2C/SPI and serial drivers as an Arduino library. I also see analoque / PWM low level drivers in the repository.

fat16lib

There is no low level support for Due drivers.

Currently the AVR low level drivers are not very complete. 

See the ChibiOS_2.6.0/os/ha/platforms/AVR folder.  There are low level drivers for i2c, pal, and serial.

Serial only supports two ports so is not good for Mega.

Serial and i2c will need to be separate libraries for AVR since including them in the Chibios_AVR folder interferes with Arduino Serial and Wire.  It's the ISR conflict problem.

I am playing with the AVR drivers but have not decided what to do.

I have developed RTOS friendly drivers for Nil RTOS and they are a big improvement over Arduino.  The Nil drivers sleep when possible.  This saves lots of cpu time for i2c and anlogRead.




gdisirio

Probably MarsWarrior is referring to the work done in ChibiOS for AVR recently. There are two people working on the code for AVR now and they are very busy implementing all HAL drivers. Of course the code is in the trunk, version 2.6.0 does not contain the new drivers yet.

Giovanni

fat16lib

One major problem with using drivers for an RTOS with the Arduino IDE is that many people want to use existing Arduino libraries.

It is impossible to use many RTOS drivers with existing libraries.  For example many i2c devices use Wire.  Other libraries use Serial.  The Arduino IDE and the RTOS drivers both try to load ISRs so it won't work.

For Nil RTOS, I wrote an i2c library with an efficient API for new software but added a compatibility Wire style API.  I also wrote an analog driver that sleeps while conversions take place.  This allows existing Arduino libraries to be easily converted to more efficient use of the drivers I wrote for Nil.  With libraries for i2c devices, you often only need to change the include file from Wire.h to NilTwi.h.

I designed the Nil i2c library so it will work with ChibiOS and FreeRTOS.  There are two weak functions in the i2c library, one signals from an ISR when a tranfer is done and one waits in a thread while the transfer occurs.  Adding a very small file to ChibiOS or FreeRTOS allows this i2c library to be use efficiently with these RTOSs.

Having a standard Hal interface is a great feature for an RTOS.  This allows easy porting of applications to various processors.  This advantage is not so clear in the Arduino environment.

The Arduino IDE makes it difficult to include drivers since you can't put them in the kernel library because any ISRs always get loaded.

I am now trying to decide on the best approach for the ChibiOS Hal drivers.  Is there any advantage in using the Arduino IDE if you are not interested in existing Arduino libraries and software?

MarsWarrior


Probably MarsWarrior is referring to the work done in ChibiOS for AVR recently. There are two people working on the code for AVR now and they are very busy implementing all HAL drivers. Of course the code is in the trunk, version 2.6.0 does not contain the new drivers yet.

Indeed, this is what I was referring to. Didn't realize it was not in the 2.6.0 version though...

I know fatlib16 also has some TWI/SPI drivers adapted to Nil & Chibi, but have no idea how the hal drivers and these compare.
TWI contains a wrapper AFAIK to be compatible with the existing implementations.

I'm using both Nil/Chibi and the Arduino libraries. This worsk fine, except for those cases where multiple threads want to use I2C/SPI devices: in that case I need some synchronization, or even bus allocation. If a hal/dedicated driver can deliver de basics with a C++ wrapper for ease of use, adapting an existing Arduino library would not be very difficult (I hope).

kowalski is doing a great job with Cosa (using interrupts / events in a lot of drivers/devices). I guess it is even possible to extend/adapt these libraries with the hal/dedicated drivers and have a very good & stable RTOS platform to work from...

fat16lib

Quote

This worsk fine, except for those cases where multiple threads want to use I2C/SPI devices: in that case I need some synchronization, or even bus allocation.


The I2C Hal has a wrapper for a Mutex or semaphore.
Code: [Select]

#if I2C_USE_MUTUAL_EXCLUSION || defined(__DOXYGEN__)
void i2cAcquireBus(I2CDriver *i2cp) {

  chDbgCheck(i2cp != NULL, "i2cAcquireBus");

#if CH_USE_MUTEXES
  chMtxLock(&i2cp->mutex);
#elif CH_USE_SEMAPHORES
  chSemWait(&i2cp->semaphore);
#endif
}

void i2cReleaseBus(I2CDriver *i2cp) {

  chDbgCheck(i2cp != NULL, "i2cReleaseBus");

#if CH_USE_MUTEXES
  chMtxUnlock();
#elif CH_USE_SEMAPHORES
  chSemSignal(&i2cp->semaphore);
#endif
}
#endif /* I2C_USE_MUTUAL_EXCLUSION */


I didn't put this wrapper in my TWI driver since I plan to have the same code work for standard Arduino sketches, Nil RTOS, ChibiOS/RT, and FreeRTOS.

You just need to declare a Mutex or Semaphore and call lock/unlock or wait/signal instead of acquire/release bus.

I can't get real excited about the I2C Hal since it lacks much I2C functionality like repeat start and continue a transfer.  It will not be easy to use the Hal in existing Arduino libraries for I2C devices.

I provide a Wire compatibility API so existing libraries for I2C devices can be more efficient with an RTOS.  For many libraries you only need to replace the include of Wire.h with an include for TwiMaster.h.

Quote
kowalski is doing a great job with Cosa (using interrupts / events in a lot of drivers/devices).


It is not likely that Cosa code will work well with a preemptive RTOS.  The extreme speed of ChibiOS/RT in doing a context switch in response to an interrupt requires the proper ISR integration with the RTOS scheduler.

The asynchronous SPI Hal is not very effective since AVR has no DMA.  Interrupt driven SPI is very slow on AVR since so many context switches are required.

Once again, use of the Arduino SPI library with a mutex or semaphore will give you sharing/synchronization.  The SPI Hal has the same type wrapper as I2C for a mutex or semaphore. 

It would be nice if the Arduino SPI library had efficient synchronous block transfer functions since these are so simple to write.

fat16lib

Here is a more general observation about porting RTOSs to Arduino.

Using a RTOS standalone is very different than trying to integrate an RTOS with Arduino.

When you choose an RTOS for a large embedded system, having a good Hal with support for lots of CPUs and boards is very important.  This allows you to use the same techniques, tools, and code throughout the project.  I was involved with the development of VxWorks  about 30 years ago and it is still very popular.  NASA JPL has used it in many space projects.

With Arduino, the RTOS adds missing multitasking functionality. 

Forty years ago it became clear that preemptive scheduling was very important with results like the 1973 Liu and Layland theorem on Rate Monotonic Scheduling.

Horn's algorithm for Earliest Deadline First was published in 1974.  This algorithm also requires preemptive scheduling.

So the big thing that an RTOS brings to Arduino is a preemptive priority based scheduler and synchronization functionality such as semaphores.

With Arduino, the Hal is less important because the massive amount of existing Arduino software is about the only reason not to just use the RTOS standalone.  Therefore I think it is important, when possible, to provide as much compatibility with basic I/O such as I2c, SPI, ADC(analogRead), and Serial while improving I/O performance when using an RTOS.

This allows maximum use of existing libraries in a multitasking environment with Arduino boards.



MarsWarrior


The I2C Hal has a wrapper for a Mutex or semaphore.
I didn't put this wrapper in my TWI driver since I plan to have the same code work for standard Arduino sketches, Nil RTOS, ChibiOS/RT, and FreeRTOS.

You just need to declare a Mutex or Semaphore and call lock/unlock or wait/signal instead of acquire/release bus.


I assume you mean that I should use a mutex/semaphore around the code that calls the TWI driver to assure thread safety?

Quote

I can't get real excited about the I2C Hal since it lacks much I2C functionality like repeat start and continue a transfer.  It will not be easy to use the Hal in existing Arduino libraries for I2C devices.

I provide a Wire compatibility API so existing libraries for I2C devices can be more efficient with an RTOS.  For many libraries you only need to replace the include of Wire.h with an include for TwiMaster.h.


I noticed the differences, but wasn't aware of the fact that there are existing libraries that use that functionality. If the hal drivers are not compatible, than it has no use for me, as I'm using a lot of existing Arduino libraries. Some of them need some changes for an RTOS, but most can be reused...


So the big thing that an RTOS brings to Arduino is a preemptive priority based scheduler and synchronization functionality such as semaphores.

With Arduino, the Hal is less important because the massive amount of existing Arduino software is about the only reason not to just use the RTOS standalone.  Therefore I think it is important, when possible, to provide as much compatibility with basic I/O such as I2c, SPI, ADC(analogRead), and Serial while improving I/O performance when using an RTOS.

This allows maximum use of existing libraries in a multitasking environment with Arduino boards.


I guess that sums it up very nicely. I do like/need the RTOS functionality added to Arduino, but I want to retain as much compatibility with existing libraries as it alows reuse of those libraries.

Go Up