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
Post a Comment