AVR os-less OSAL Topic is solved

[Marco]

Hi,

I want to try ChibiOS/HAL on an AVR without OS.
Did someone try this on AVR already? There is an os-less OSAL for ARMCMx but not yet for AVR. I can try writing an os-less OSAL for AVR unless there is some reason why it would not be possible to run on an AVR.

Marco

[Giovanni]

Hi,

Currently there is no OSAL for AVR, it should be "easily" derivable from the ARM Cortex-M one, the HW-dependent parts are limited.

Giovanni

[Marco]

Hi,

I succeed in creating an os-less OSAL for AVR, it was easily derived from the ARMCMx OSAL. Attached are the zipped AVR OSAL files.

While creating the OSAL for AVR i noticed there is quite some duplicated code. Maybe it is a good idea to have a common set of functions for os-less OSAL implementations. What do you think?

Marco

[Giovanni]

Interesting thought, probably it is mostly portable code except for the few asm bits.

Giovanni

[utzig]

osal.c is basically the same, so maybe creating a common/osal.c. Apart from that the code LGTM, I could add this to SVN now and patch to create a common infrastructure later. Will wait for your inputs...

Cheers,
Fabio Utzig

[Giovanni]

Apply it as-is, I will look at the shared code when the OSAL will get another dev pass.

Giovanni

[utzig]

Done.

[Marco]

Hi,

I found out that the os-less AVR OSAL is not working with optimization other than -O0. The application was stuck in the loop in osalThreadSuspendS after calling spiStartSendI:

Code: Select all

  while (self.message == MSG_WAIT) {
    osalSysUnlock();
    /* A state-changing interrupt could occur here and cause the loop to
       terminate, an hook macro is executed while waiting.*/
    OSAL_IDLE_HOOK();
    osalSysLock();
  }

Stepping trough this loop showed the Global Interrupt Enable flag in the SREG register was toggling as expected since osalSysUnlock and osalSysLock are continuously called. At this point the SPI Interrupt Flag in the SPSR was also set so the interrupt vector should be called, but this was not the case.

I checked the sei instruction in the ATmega162 datasheet and found the following:

When using the SEI instruction to enable interrupts, the instruction following SEI will be executed
before any pending interrupts, as shown in this example.

The instruction following SEI is CLI. This means the interrupts are immediately disabled and the SPI interrupt has no chance of being called.

Adding

Code: Select all

asm volatile ("nop");

after

Code: Select all

asm volatile ("sei" : : : "memory");

in osalSysUnlock fixes the problem.

I'm wondering if RT and NIL could have issues with this as well since there is no instruction following sei in chcore.h

Marco

[Giovanni]

Good point, it should be added in my opinion.

Giovanni

[utzig]

I never had any problem running ChibiOS/RT on AVR using -O2 but this is a really interesting find and I would like to investigate more the possible effects of that behavior because it seems to affect every AVR MCU out there.

For now I would suggest that you submit a patch with the extra nop. Btw, feel free to also submit patches for every change we have been discussing, that has been quite useful.

Cheers,
Fabio Utzig