CMSIS problems

Bill Greiman · Jan 28, 2017

There are scraps of CMSIS V3 in the Teensy IDE that make it extremely difficult for me to use Teensy 3.6.

I wrote a new library for exFat/FAT32/FAT16 a while back. I did a little testing on Teensy 3.6 then tried to port ChibiOS/RT to Teensy 3.6. I finally gave up.

Today I decided to try again with Teensy 1.35.

The bits of CMSIS in Teensy3 are an incomplete early version V3. ChibiOS/RT and other parts of my software need V4 and will soon use V5.

Even the simplest things fail.

Code:

#include "core_cm4.h"
void setup() {
}
void loop() {
}

Code:

Arduino: 1.8.1 (Windows 10), TD: 1.35, Board: "Teensy 3.6, Serial, 180 MHz, Fast, US English"

In file included from C:\Users\bill\Documents\ArduinoSdFs\junk\junk.ino:1:0:

D:\Teensy\teensy135\hardware\teensy\avr\cores\teensy3/core_cm4.h:155:95: fatal error: core_cmFunc.h: No such file or directory

 #include <core_cmFunc.h>                 /* Core Function Access                            */

                                                                                               ^
compilation terminated.

Error compiling for board Teensy 3.6.

This report would have more information with
"Show verbose output during compilation"
option enabled in File -> Preferences.

When I try to use newer versions of CMSIS I get failures since the CMSIS has been refactored plus a few of the old bits are needed for teensy or are in non-standard files.

Code:

// In kinetis.h
#define __enable_irq()	__asm__ volatile("CPSIE i":::"memory");

// In cmsis_gcc.h
__attribute__( ( always_inline ) ) __STATIC_INLINE void __enable_irq(void)
{
  __ASM volatile ("cpsie i" : : : "memory");
}

It's not just a few cases like this - I get about a 1,000 lines of errors with the latest version of ChibiOS/RT.

So I am giving up on Teensy 3.xx.

Frank B · Jan 28, 2017

So you're not able to edit the core ?

you're right, Teensy is crap. I tried to install ubuntu, this did not work, too. I gave up.
Even the simplest things fail.

Theremingenieur · Jan 28, 2017

For many years, I've been trying to understand women but it didn't work. Shall I give up and tell that they're crap?

Frank B · Jan 28, 2017

Theremingenieur said:
For many years, I've been trying to understand women but it didn't work. Shall I give up and tell that they're crap?

Try to install something...

Bill Greiman · Jan 28, 2017

Frank B said:
Try to install something...

Sorry I said anything. I installed the latest ChibiOS/RT for most of the current Arduino boards with Arduino 1.81. I didn't know I was forbidden to install it with the Teensy 1.35 IDE.

PaulStoffregen · Jan 28, 2017

Bill, do you wish to talk about how we can improve Teensyduino, or are you only here to vent frustration?

You can do either, but I need to know whether to expect constructive dialogue and helpful feedback for changes attempting to improve this situation. As a practical matter, since I don't personally use ChibiOS, there's not much point to me trying to change things without someone who does use it actively involved.

If you've given up and there's no going back, that's your choice. While I hope that's not really the case, there's probably little I can do to change your mind. Robin and I try never to censor non-spam conversations, even when they're offensive. If you're only going to vent, you can, and I will put ChibiOS on my low-priority bug list. I can assure you it will sit there indefinitely, waiting until someone who is willing to put some time into testing ChibiOS and constructive feedback comes along.

Bill Greiman · Jan 28, 2017

I didn't think my original post was offensive I stated the problems I face and said I can't see a way to go forward and am giving up on the Teensy IDE. I should have asked if anyone has an idea.

Frank B clearly found what I said to be offensive.

So you're not able to edit the core ?

your right, Teensy is crap. I tried to install ubuntu, this did not work, too. I gave up.
Even the simplest things fail.

The Arduino IDE works with ChibiOS/RT because Atmel provided CMSIS and other core software for Due and Zero. Atmel uses CMSIS in a conventional way.

I understand why you didn't use Freescale's software and the ARM stuff when you started with Teensy 3. I did the same with STM32 and Atmel ARM in the past.

ChibiOS/RT uses a huge number of ARM features so it requires a full standard CMSIS distribution. This will break lots to Teensy software. This is not a simple bug fix or editing the core.

I use ChibiOS/RT since it is one of the fastest most sophisticated open source RTOSs and is amazingly small. It has most of the features of commercial systems I have used for the last 30 years. When I do large projects I don't want to reinvent the equivalent of preemptive multi-threading. Modern tickless RTOSs even have less overhead than systems like Arduino.

Now ChibiOS need CMSIS V4 but soon CMSIS V5 will be required. CMSIS V5 is a huge step. It even includes two versions of the RTX RTOS kernel. The zip file is 105 MB.

Probable trying to "fix Teensy software" to run ChibiOS is a bad idea.

Sorry I offended Frank B and others.

Frank B · Jan 28, 2017

No, my answer was just fun...
And the "try to install something" was a reply to Theremingenieur

Sorry, I'm not a native english speaker (and i know my English is not good), some of my replies might sound harsher than intended.

PaulStoffregen · Jan 28, 2017

I'd like to point out, other than including core_cm4.h (which in Teensyduino is not meant to be used without arm_math.h), no test cases have been posted here. There's no sketch+libs, or non-Arduino makefile to actually reproduce "about a 1,000 lines of errors with the latest version of ChibiOS/RT".

Look, if you've gone to the trouble to arrange this as a library or other way to build in Arduino, or as a makefile or some other way to do it without Arduino, why can't you just put it all into a zip file and post it here? Then at least we could see the 1000 lines of errors without having to come up to speed on ChibiOS and put in some guesswork about exactly how you've got it all set up.

Bill Greiman · Jan 28, 2017

PaulStoffregen said:
I'd like to point out, other than including core_cm4.h (which in Teensyduino is not meant to be used without arm_math.h), no test cases have been posted here. There's no sketch+libs, or non-Arduino makefile to actually reproduce "about a 1,000 lines of errors with the latest version of ChibiOS/RT".

Look, if you've gone to the trouble to arrange this as a library or other way to build in Arduino, or as a makefile or some other way to do it without Arduino, why can't you just put it all into a zip file and post it here? Then at least we could see the 1000 lines of errors without having to come up to speed on ChibiOS and put in some guesswork about exactly how you've got it all set up.

I only did the example with core_cm4.h to show that only a few of the CMSIS include files are in the Teensy IDE. core_cm4.h requires core_cmFunc.h which is not in Teensy.

Also it appears you modified some of the CMSIS file putting "#if 0/#endif" around includes so core_cm4.h isn't used. I can delete core_cm4.h and Teensy 3 programs still work.

The errors, mostly duplicate symbols, occur when I use the version of CMSIS shipped with ChibiOS/RT. The last resort is to modify CMSIS files.

I can remove some of these but I want the library to work with AVR, and ARM STM32, SAM, SAMD, Teensy.

Code:

-rwxrwx---+ 1 bill None   7265 Apr 22  2016 arm_common_tables.h
-rwxrwx---+ 1 bill None   3942 Aug  1  2015 arm_const_structs.h
-rwxrwx---+ 1 bill None 252339 Apr 22  2016 arm_math.h
-rwxrwx---+ 1 bill None  24423 Apr 22  2016 cmsis_armcc.h
-rwxrwx---+ 1 bill None  55083 Apr 22  2016 cmsis_armcc_V6.h
-rwxrwx---+ 1 bill None  41435 Apr 22  2016 cmsis_gcc.h
-rwxrwx---+ 1 bill None  37218 Apr 22  2016 core_cm0.h
-rwxrwx---+ 1 bill None  44796 Apr 22  2016 core_cm0plus.h
-rwxrwx---+ 1 bill None 103909 Apr 22  2016 core_cm3.h
-rwxrwx---+ 1 bill None 114498 Apr 22  2016 core_cm4.h
-rwxrwx---+ 1 bill None 139660 Apr 22  2016 core_cm7.h
-rwxrwx---+ 1 bill None   3620 Apr 22  2016 core_cmFunc.h
-rwxrwx---+ 1 bill None   3715 Apr 22  2016 core_cmInstr.h
-rwxrwx---+ 1 bill None   3662 Apr 22  2016 core_cmSimd.h
-rwxrwx---+ 1 bill None  45262 Apr 22  2016 core_sc000.h
-rwxrwx---+ 1 bill None 102809 Apr 22  2016 core_sc300.h

The second example shows problems where CMSIS symbols like __enable_irq() are defined in kinetis.h.

The CMSIS files in Teensy are very old and ARM has refactored the new files so there are conflicts. Also many new symbols are defined.

I will try to make something I can post. Since I can't get close to compiling, it is difficult to be sure I have all the files. ChibiOS/RT has 700 folders with 4000 files.

Teensy 3.6 is the first Cortex M4 with FPU that I tried.

Theremingenieur · Jan 28, 2017

Ok, now without kidding (please accept my apologies for Frank B's and my European humor)...

Just out of scientific curiosity: What are use cases for using a RTOS on an embedded processor like the Teensy? What features and optimizations does it bring compared to manually optimized event driven (IRQs, DMA) code? Doesn't it add much overhead consuming CPU resources?

PaulStoffregen · Jan 29, 2017

Bill Greiman said:
The CMSIS files in Teensy are very old and ARM has refactored the new files so there are conflicts.

Yeah, I know. That stuff got put into the core library only because many people wanted to use arm_math.h (now called CMSIS-DSP). It was the most recent version in late 2012 when Teensy 3.0 got started. A lot of people have built some really awesome projects using that stuff (mostly the FFT) and we use some of it in the audio library, so overall it's worked out pretty well for the last 4.5 years.

Honestly though, it is something of a mess, and much of that is my fault. I made several edits so it would work "stand alone". Until now, nobody has really complained. Well, except some people have asked for it to be updated to newer versions, mainly because the new ones support larger FFT sizes. The new versions do this by including a huge lookup table (even if using the smallest FFT) that burns about 90K of flash in the old version we use, and becomes too larger for even Teensy 3.2 using the newest versions. Obviously that's a huge problem for Teensy, so we've just stayed with the old version. About a year ago I started some work to rebuild the library, with the intention to someday update it and create patches to solve the huge table size problem. But that's been a much lower priority than so many other things....

I will try to make something I can post. Since I can't get close to compiling, it is difficult to be sure I have all the files. ChibiOS/RT has 700 folders with 4000 files.

Thanks. I'll take a look. There may indeed by issues that can't be resolved, but perhaps the bulk of them can be fixed by just renaming some of the stuff we have only for arm_math.h, and some careful use of #ifdef checks to not compile same-name, same-function stuff when CMSIS is present (its headers included first).

Bill Greiman · Jan 29, 2017

PaulStoffregen said:
Yeah, I know. That stuff got put into the core library only because many people wanted to use arm_math.h (now called CMSIS-DSP). It was the most recent version in late 2012 when Teensy 3.0 got started. A lot of people have built some really awesome projects using that stuff (mostly the FFT) and we use some of it in the audio library, so overall it's worked out pretty well for the last 4.5 years.

Honestly though, it is something of a mess, and much of that is my fault. I made several edits so it would work "stand alone". Until now, nobody has really complained. Well, except some people have asked for it to be updated to newer versions, mainly because the new ones support larger FFT sizes. The new versions do this by including a huge lookup table (even if using the smallest FFT) that burns about 90K of flash in the old version we use, and becomes too larger for even Teensy 3.2 using the newest versions. Obviously that's a huge problem for Teensy, so we've just stayed with the old version. About a year ago I started some work to rebuild the library, with the intention to someday update it and create patches to solve the huge table size problem. But that's been a much lower priority than so many other things....

Thanks. I'll take a look. There may indeed by issues that can't be resolved, but perhaps the bulk of them can be fixed by just renaming some of the stuff we have only for arm_math.h, and some careful use of #ifdef checks to not compile same-name, same-function stuff when CMSIS is present (its headers included first).

I deleted all old ARM Limited files from 1.35. I had to delete the old versions of the math files since they are not compatible with the new CMSIS.

Code:

-rwxrwx---+ 1 bill None   1191 Jan 28 08:15 arm_common_tables.h
-rwxrwx---+ 1 bill None 248129 Jan 28 08:15 arm_math.h
-rwxrwx---+ 1 bill None 108157 Jan 28 08:15 core_cm4.h
-rwxrwx---+ 1 bill None  16025 Jan 28 08:15 core_cm4_simd.h
-rwxrwx---+ 1 bill None  10065 Jan 28 08:15 core_cmInstr.h
-rwxrwx---+ 1 bill None   9774 Jan 28 08:15 math_helper.c
-rwxrwx---+ 1 bill None   1949 Jan 28 08:15 math_helper.h

I did a small edit to kinetis.h to remove a conflict with the new files.

Code:

// about line 5615
#if 0 // WHG
#define __disable_irq() __asm__ volatile("CPSID i":::"memory");
#define __enable_irq()	__asm__ volatile("CPSIE i":::"memory");
#endif  // WHG

Then I had to add this at the top of kinetis.h for Teensy 3.6. It won't work for other Teensy 3 boards

Code:

#include "ARMCM4_FP.h"  // WHG
#include "core_cm4.h"   // WHG
#include "cmsis_gcc.h"  // WHG

I added the following new CMSIS 4.5 files

Code:

-rwxrwx---+ 1 bill None  15393 Nov 17 06:59 ARMCM4.h
-rwxrwx---+ 1 bill None  15399 Nov 17 06:59 ARMCM4_FP.h
-rwxrwx---+ 1 bill None  41435 Nov 17 06:59 cmsis_gcc.h
-rwxrwx---+ 1 bill None 114498 Apr 22  2016 core_cm4.h
-rwxrwx---+ 1 bill None   3620 Nov 17 06:59 core_cmFunc.h
-rwxrwx---+ 1 bill None   3636 Nov 17 06:59 core_cmInstr.h
-rwxrwx---+ 1 bill None   3662 Nov 17 06:59 core_cmSimd.h
-rwxrwx---+ 1 bill None   2577 Nov 17 06:59 system_ARMCM4.h

I can now compile ChibiOS/RT and continue with the port.

Bill Greiman · Jan 29, 2017

Theremingenieur said:
Ok, now without kidding (please accept my apologies for Frank B's and my European humor)...

Just out of scientific curiosity: What are use cases for using a RTOS on an embedded processor like the Teensy? What features and optimizations does it bring compared to manually optimized event driven (IRQs, DMA) code? Doesn't it add much overhead consuming CPU resources?

A major myth about a modern RTOS is overhead. RTOS code just does not run unless you use some RTOS feature. My first port to teensy will have extra overhead since Teensy uses a tick. I won't try to use tickless mode to begin with.

I have managed very large embedded projects with many programmers and it is difficult to find exceptional talent. One thing I like is that you can have the outstanding talent do very general things for other programmers.

Here is a simple example from the port of ChibiOS I did for AVR. analogRead and the I2C wire library just spin while the ADC or I2C interface is busy.

I wrote replacement functions/classes so a thread that calls the replacement function sleeps. It saves about 85% of the wasted CPU for both analogRead and Wire. Even a novice can use these functions. Just replace analogRead(pin) with chAnalogRead(pin).

Here are details of how it works.

Code:

SEMAPHORE_DECL(adcSem, 0); 
CH_IRQ_HANDLER(ADC_vect) {   
  CH_IRQ_PROLOGUE();         
  chSysLockFromISR();        
  chSemSignalI(&adcSem);     
  chSysUnlockFromISR();      
  CH_IRQ_EPILOGUE();         
}

int chAnalogRead(uint8_t pin) {
#if defined(__AVR_ATmega32U4__)
  pin = analogPinToChannel(pin);
  ADCSRB = (ADCSRB & ~(1 << MUX5)) | (((pin >> 3) & 0x01) << MUX5);
#elif defined(ADCSRB) && defined(MUX5)
  // the MUX5 bit of ADCSRB selects whether we're reading from channels
  // 0 to 7 (MUX5 low) or 8 to 15 (MUX5 high).
  ADCSRB = (ADCSRB & ~(1 << MUX5)) | (((pin >> 3) & 0x01) << MUX5);
#endif
  // set the analog reference (high two bits of ADMUX) and select the
  // channel (low 4 bits).  this also sets ADLAR (left-adjust result)
  // to 0 (the default).
#if defined(ADMUX)
 ADMUX = (nil_analog_reference << 6) | (pin & 0x07);
#endif

  // Use interrupt and sleep.
  ADCSRA |= (1 << ADIE) | (1 << ADSC);
  chSemWait(&adcSem);
  ADCSRA &= ~(1 << ADIE);
  // this will access ADCL first.
  return ADC;
}

I sleep on a semaphore waiting for the ADC to finish at the end of chAnalogRead(pin).

I add a ChibiOS style ISR that gives the semaphore when the ADC finishes and wakes the thread.

Another way an RTOS can help is with large complex libraries that spin on some event, like my SD libraries. You could modify them to sleep but it is not easy and doesn't really solve the problem of lost data when logging from a sensor. An SD can have very long write latencies.

You can easily run sensor read in a high priority thread, use an RTOS queue to buffer data and do the SD write in a low priority thread. It take very little code.

Here is the code for a high priority thread that uses ChibiOS mailboxes to send data to a low priority thread that formats and writes data to an SD.

Code:

// Declare thread function for thread 1.
THD_FUNCTION(Thread1, arg) {
  uint16_t overrun = 0;
  (void)arg;

  // Check for very fast reads.
  if (NADC*160 > PERIOD_USEC) {
    // Set ADC prescaler to 64 for very fast reads.
    chAnalogPrescalar(ADC_PS_64);
  }
  // Initialize ADC by doing first read.
  chAnalogRead(0);

  // Start timer 1 with a period of PERIOD_USEC.
  chTimer1Start(PERIOD_USEC);

  // Record data until serial input is available.
  while (!Serial.available()) { 
    // Sleep until it's time for next data point.
    if (!chTimer1Wait()) {
      Serial.println("time1 err");
      break;
    }
    chSysLock();
    cnt_t nfree = chMBGetFreeCountI(&adc_data);
    chSysUnlock();
    if (nfree < NADC) {
      overrun++;
      continue;
    }
    // Read ADCs
    for (int i = 0; i < NADC; i++) {
      msg_t data = chAnalogRead(i);
      if (overrun && i == 0) data |= 0X8000;
      if (i == (NADC-1)) data |= 0X4000;
      if (MSG_OK != chMBPost(&adc_data, data, TIME_IMMEDIATE)) {
        Serial.println("mbox err");
        break;        
      }
    }
    overrun = 0;
  }
  // Done, sleep forever.
  chThdSleep(TIME_INFINITE);
}

Note the high priority thread uses chAnalogRead() so it takes almost no CPU time. This AVR program can record data to an SD at 5,000 samples per second without overruns. SD cards can have write latencies of many milliseconds so you need to write lots of code to do this even on a Teensy 3 and no RTOS.

I could go on for many pages describing systems I have designed over the years with much more complex uses of a RTOS. This gives the flavor of using an RTOS.

PaulStoffregen · Jan 29, 2017

I'd like to make some improvements to help, but I can't just take those files out and replace them, as that would break many programs people have written using arm_math.h, including the audio library.

I also can't just disable the defines for __disable_irq() and __enable_irq(), as that breaks everything! I need a reliable way to detect if a ChibiOS or CMSIS header as already been included, so they can be excluded only when needed for compatibility.

Can you help my out here, with a zip file containing all the stuff I need to compile what you're testing, and any steps I need if it's not a matter of just installing libraries and clicking Verify in Arduino?

Or could you suggest how I go about this in ways that preserve compatibility with Arduino sketches and libraries that already exist?

Bill Greiman · Jan 30, 2017

PaulStoffregen said:
I'd like to make some improvements to help, but I can't just take those files out and replace them, as that would break many programs people have written using arm_math.h, including the audio library.

I also can't just disable the defines for __disable_irq() and __enable_irq(), as that breaks everything! I need a reliable way to detect if a ChibiOS or CMSIS header as already been included, so they can be excluded only when needed for compatibility.

Can you help my out here, with a zip file containing all the stuff I need to compile what you're testing, and any steps I need if it's not a matter of just installing libraries and clicking Verify in Arduino?

Or could you suggest how I go about this in ways that preserve compatibility with Arduino sketches and libraries that already exist?

I understand that you can't use my changes. I want to get ChibiOS running then try to find a way to run it with backward compatible code. I want to get a working example before sending you a zip file.

ChibiOS is not a simple Arduino library that you easily debug. ChibiOS thinks it does startup and is the OS. I had to write a part that undoes your startup. I have the part that changes to to thread/handler mode and uses a handler stack and main stack working. The interrupt handlers for USB Serial seem to work in handler mode. I need to get SVC_Handler and PendSV_Handler working. Then I can start running threads. I hope all I need to do is adapt your names, svcall_isr, and pendablesrvreq_isr, to the ARM names.

Edit: any idea how large the handler stack should be? I will fill it and provide a function to check how much is unused.

I won't be upset if I can't get it to work. It's fun working with the ChibiOS code. Giovanni Di Sirio, the author of ChibiOS does amazing things with the OS. His implementation is often twice as fast as FreeRTOS and smaller.

Bill Greiman · Jan 30, 2017

I think I can make ChibiOS/RT work on Teensy 3.6 with no changes to Teensy code. I use the new CMSIS 4.5 and work around standalone stuff in Teensy with this small change to a single include.

Code:

#ifdef CORE_TEENSY
#undef __disable_irq
#undef __enable_irq
typedef enum IRQn {
  SVCall_IRQn                   =  -5,      /* 11 SV Call Interrupt */
  DebugMonitor_IRQn             =  -4,      /* 12 Debug Monitor Interrupt */
  PendSV_IRQn                   =  -2,      /* 14 Pend SV Interrupt */
  SysTick_IRQn                  =  -1,      /* 15 System Tick Interrupt */
} IRQn_Type;

#define __NVIC_PRIO_BITS 4
#include "../CMSIS/core_cm4.h"
#endif  // CORE_TEENSY

I have a slightly older version of ChibiOS/RT working on Teensy 3.6. Now I need to find why I am getting a Hard Fault with the newest version of ChibiOS/RT.

PaulStoffregen · Jan 30, 2017

Ok, sounds good.

When/if you want me to look at some updates in Teensyduino, just ask. I will need something I can compile for testing...

Bill Greiman · Jan 30, 2017

PaulStoffregen said:
Ok, sounds good.

When/if you want me to look at some updates in Teensyduino, just ask. I will need something I can compile for testing...

Looks like I don't need any changes to Teensyduino, I have the latest stable ChibiOS/RT running on Teensy 3.5/3.6 and Teensy 3.1/3.2. I did a slight edit to CMSIS files changing #include <file.h> to #include "file.h". That insures I get my new stuff.

I did a scope test using this program to determine the context switch time for Teensy 3.6 at 180 MHz. The result is just under a microsecond. Not bad since the FPU and general registers need to be swapped.

Code:

// Connect a scope to pin 13
// Measure difference in time between first pulse with no context switch
// and second pulse started in thread 2 and ended in thread 1.
// Difference should be about 15-16 usec on a 16 MHz 328 Arduino.
#include "ChRt.h"

// LED_BUILTIN pin on Arduino is usually pin 13.

// Semaphore to trigger context switch
SEMAPHORE_DECL(sem, 0);
//------------------------------------------------------------------------------
// thread 1 - high priority thread to set pin low
// 64 byte stack beyond task switch and interrupt needs
static THD_WORKING_AREA(waThread1, 64);

static THD_FUNCTION(Thread1, arg) {

  while (true) {
    chSemWait(&sem);
    digitalWrite(LED_BUILTIN, LOW);
  }
}
//------------------------------------------------------------------------------
// thread 2 - lower priority thread to toggle LED and trigger thread 1
// 64 byte stack beyond task switch and interrupt needs
static THD_WORKING_AREA(waThread2, 64);

static THD_FUNCTION(Thread2, arg) {
  pinMode(LED_BUILTIN, OUTPUT);
  while (true) {
    // first pulse to get time with no context switch
    digitalWrite(LED_BUILTIN, HIGH);
    digitalWrite(LED_BUILTIN, LOW);
    // start second pulse
    digitalWrite(LED_BUILTIN, HIGH);
    // trigger context switch for task that ends pulse
    chSemSignal(&sem);
    // sleep until next tick (1000 microseconds tick on Teensy)
    chThdSleep(1);
  }
}
//------------------------------------------------------------------------------
void chSetup() {
  // start high priority thread
  chThdCreateStatic(waThread1, sizeof(waThread1),
    NORMALPRIO+2, Thread1, NULL);

  // start lower priority thread
  chThdCreateStatic(waThread2, sizeof(waThread2),
    NORMALPRIO+1, Thread2, NULL);
}
//------------------------------------------------------------------------------
void setup() {
  chBegin(&chSetup);
  // does not return - stacks and processor mode are changed in chBegin().
}
//------------------------------------------------------------------------------
void loop() {
  // not used in this program.  Is called like normal Arduino loop using main stack.
}

Jeff Williams · Feb 3, 2017

Hi Bill,

I was wondering if you are planning to share your latest work with ChibiOS/RT on Teensy 3.6?

I used your https://github.com/greiman/ChibiOS-Arduino on an Arduino in the past but for my new data logger project I wanted some additional capabilities and the size and features of Teensy 3.6 seemed about right. I have the basics of my logger working but I have recently been trying to figure out how to get some RTOS features on Teensy 3.6 such as a Queue and maybe priority based threading. I have also looked at maybe moving the project again to a board that ChibiOS supports (though I still like the Teensy 3.6 capabilities and package!)

I'm just a hobby hacker who added a Adruino based data logger to my road motorcycle after I hacked it from carbs to fuel injection. Now I want to put a data logger on my track bike with bunch more sensors. Without RTOS I have the basics working but I would like to continue some of my learning with RTOS and when I think about how the logger should work a Queue with readings handled by a lower priority thread with higher priority sensor thread(s) that feed the queue seems more natural to me coming from the IT Server scale development world.

Thanks, Jeff

KurtE · Feb 27, 2017

Bill Greiman said:
I think I can make ChibiOS/RT work on Teensy 3.6 with no changes to Teensy code. I use the new CMSIS 4.5 and work around standalone stuff in Teensy with this small change to a single include.

I have a slightly older version of ChibiOS/RT working on Teensy 3.6. Now I need to find why I am getting a Hard Fault with the newest version of ChibiOS/RT.

Any updates? Do you have a version of RTOS for the Teensy 3.2 or 3.6 you currently recommend?
I would like to try one out again to do some lightweight threading.

Things like have a thread wait for input from the host
Have another thread handle timings of output to servos.
Maybe one or two others monitoring sensors like IMU...

Thanks

Kurt

dauntless89 · Jul 23, 2017

I would also like to know how this is coming along.

yoonghm · Jul 24, 2017

I saw this

https://hackaday.io/project/18505-chibios-on-teensy-36

Has you seen it?

Jeff Williams · Jul 24, 2017

I believe that is a rather old (3.0.3) version of ChibiOS, current is 17.6 I believe

Jeff

yoonghm said:
I saw this

https://hackaday.io/project/18505-chibios-on-teensy-36

Has you seen it?

Bill Greiman · Jul 24, 2017

I would also like to know how this is coming along.

I decided to try again with a newer version of ChibiOS. I downloaded ChibiOS_RT stable/ Version 17.6.0. It has a new version of CMSIS.

It only took a few hours to get it working on Teensy 3.6. Paul also made several changes that made things easier. It is a single library with support for AVR, SAMD, SAM3X, and Teensy3 (only tested on teensy 3.6, not 3.2 yet). I will do some additional testing and post a beta on GitHub soon.

ChibiOS/RT offers threads, virtual timers, binary and counter semaphores, mutexes, condition variables, monitors, event flags, event listeners, event sources, messages, mailboxes.

You should not think of the port as true ChibiOS/RT. I didn't implement tickless mode and I am not porting any of the HAL. Think of the port as a scheduler, not an OS. I do setup the processor to use thread mode and handler mode. This means you can have smaller stacks for threads.

Tickless mode is great but I didn't try to use it with the Arduino core using a tick. With tickless mode you can have a very high resolution system time, there is no extra interrupt overhead, and power management is easier to implement.

One of the biggest advantages of ChibiOS is the HAL and low level drivers. They are RTOS/multi-thread friendly and very high performance. I am not sure of the state of user developed low level drivers for kinetis.

I do most of my complex/high performance work using native ChibiOS/RT on STM32. ChibiOS has a complete set of drivers for STM32. There are STM32 drivers for ADC, CAN, DAC, EXT, GPT, I2C, I2S, ICU, MAC, MMC, PAL, PWM, RTC, SDC, Serial, UART, USB, USB-CDC, SPI, ST, WDG.

The ADC driver is great. You can log data from a list of up to 18 pins at over a million values per second with one ADC and even faster with interleaved ADCs.

Here is a test logging a sine signal to a SD at a million samples/sec. I setup the driver to continuously log samples to 512 byte blocks and queue them for the SD write thread.

Network performance is outstanding. I did an iperf test with 10 tcp connections and got 95 mb/sec total over a 100 mb/sec Ethernet on a STM32F407 board. That's almost exactly the theoretical max for a 100 mbit enet.

CMSIS problems

Well-known member

Senior Member

Senior Member+

Senior Member

Well-known member

Well-known member

Well-known member

Senior Member

Well-known member

Well-known member

Senior Member+

Well-known member

Well-known member

Well-known member

Well-known member

Well-known member

Well-known member

Well-known member

Well-known member

Member

Senior Member+

Well-known member

Active member

Member

Well-known member