Longan Nano, freeRTOS, drivers

 

Things are progressing nicely.

I now have freeRTOS , Serial (with DMA), SPI (with DMA) and basic LCD support. The goal is to remove all dependencies toward the GD32 fw lib and the longduino externals ultimately.




Why do that ?


First, the low level GD32 library is just a wrapper on top of the registers.

It does not do consistency check, it does not bring features/optimization/...

The library i'm doing is a little bit higher level. You setup the DMA parameters and that''s it. In a single call. No need to do X calls to setup all registers one per one.

Additionally, the coding style is a bit different. The GD32 firmware lib is using C macros so that

SPI_CTL(SPI0) is the "Control" register of SPI0

I'm using a structure defining all the registers of a given SPI

To get the same thing, i do

spi0->CTL

But it's basically the same thing, no ?

Almost. The main difference is , under gdb, i can just do 

p /x *spi0

to see all the registers of SPI0 and check everything is alright. Same for DMA etc...

i.e.

(gdb) p /x *aspi0
$2 = {CTL0 = 0xc004, CTL1 = 0x0, STAT = 0x2, DATA = 0x0, CRCPOLY = 0x7, RXCRC = 0x0, TXCRC = 0x0, I2SCTL = 0x0, I2SPSC = 0x0}

Additionally, it is much less error prone.

Multitasking

The 2nd difference is that since we are using FreeRTOS, all the interrupts are just unlocking the underlying task with a semaphore/mutex/whatever upon completion

But it's not faster, it's most of the time slower ?

True, it is a bit slower, but you can do something else meanwhile. For example having a low priority task doing ADC measurements whenever the main task is doing SPI transfer. The chip is running at 108 Mhz, so even 1 us is a lot of cycles ( 108 :) )


Task switching within freeRTOS

I made a stupid mistake when using QQxiaoming FreeRTOS port, so i had to look into it to debug that.

Usually freeRTOS wraps all the syscall/Irq with store context/restore context over pxCurrentTCB sp so that whenever a task switch is caused by an interrupt, pxCurrentTCB changes and the restore part restores the new task context.

So nothing special to do, when exiting the interrupt/exception you'll resume operation on the appropriate task.

QQxiaoming does something different : It does nothing  special as far as interrupt store/restore is concerned BUT it triggers an exception when a rescheduling is needed. 

That exception is not processed preemptively.

So you'll finish your current interrupt normally, and just after that, another interrupt/exception will happen that will just switch the task

It is a little bit more expensive in terms of cycles, i.e. a second exception to handle.




Comments

Popular posts from this blog

Component tester with STM32 : Part 1 ADC, Resistor

Fixing the INA3221

INA3221, weird wiring