Test, debug and validate the mux driver on GD32VF103

Test, debug and validate the flash driver for GD32VF103

I'm not a huge fan of this idea, but round-robin would be a nice feature.
The general idea would be to use some 2-step round-robin management.

First, create a round-robin task that would fit in the normal picoRTOS scheduling.
Second, provide this task a fixed-sized array of sub-tasks to run sequentially.

This way, the hi-speed, ultra-reliable low-latency standard picoRTOS scheduler stays unaffected.
Round-robin is more of an extension than a rewrite of the scheduler.

The API stays to be defined, maybe something like:
picoRTOS_round_robin_task_init(struct picoRTOS_rr_task *task, struct picoRTOS_task *array, size_t n);
picoRTOS_add_round_robin_task(struct picoRTOS_rr_task *task, picoRTOS_priority_t prio);

A lot of drivers use CONFIG_DEADLOCK_COUNT as a way to avoid infinite loops. This doesn't work.
Depending on the CPU power or level of optimization, this could trigger an assert and make a perfectly good software stall.

The solution is not obvious... We can increase the countdown but take the risk to see it fail anyway or find a way to determine the max counter depending on the CPU frequency.
This one is available in the clock HAL, but this means the clocks must be initialized, which is not satisfying either.

This is related to issue #19
We might have to implement some variant of activate wait, like delay_us() or delay_ms() for every arch & every clock speed.

This is not that obvious withotu a massive refactoring, unless maybe arch_counter() might be used differently (as a freerunnning counter, similar to MIPS and RISC-V).

For the moment the embryo of a flash HAL is only dedicated to tests.
For it to be more useful it has to be able to communicate with potential file systems & offer better interfaces.

The HAL should be able to communicate to the upper layers:

• Its total size (in bytes ?)
• Its erase size depending on the address/sector ? (erasable sectors might vary in size)
• Its various or minimum available write size (page, qword, word, etc)
• ECC, OOB ?

This has to be very practical and eliminate as much guess work as possible for the upper layers, so accessors might be a solution, like:

• int flash_get_size(struct flash *ctx);
• int flash_get_erase_size(struct flash *ctx, size_t addr);
• int flash_get_write_size(struct flash *ctx, size_t addr);
• int flash_get_block(struct flash *ctx, size_t addr) ?
• ...

Otherwise, a flash_probe(ctx, &probe_info) can be a solution that offers the option to be easy to extend in the future, but will probably require to output a complete flash mapping, which might prove to be difficult with no dynamic memory allocation.

We still have the option to put this mapping statically in picoRTOS_device.h, though, but what about hypothetical external flashes ?

The newer version of GCC seems to add a notes header.
It's not handled by the current linker files so ld puts it at the beginning, ruining the boot for all ARM platforms in the process.

It might be time to factor the link for all ARM platforms anyway.

Add support for a decently accurate arch_counter() in arch/riscv/rv32imac

Define a coherent HAL + a reference driver for Ethernet peripherals

Test, debug and validate the ADC driver on the GD32VF103 device

Test, debug and validate the twi driver on GD32VF103.
This one is probably not working right and the state machine might need to be adjusted to increase reliability and performance, so there's probably a decent amount of development to do during that phase.

Only a few platforms support hardware cache synchronisation but almost all of them support DMA operations.

This will become a problem with DMA and SMP at some point.

Cache invalidation and cache flush operations will have to be implemented, ideally in an optional way that won't force platforms with no caches to implement dummy calls.

Test, debug and validate the can-pic32mx driver

Port picoRTOS to 8bit PIC to see if it fits.

It's more of a challenge than anything else, but who knows ?

Test, debug and validate PWM driver on GD32VF103

Test, debug and validate CAN driver on SAME5x.
This will require the support for a new device & a new demo, as picoRTOS only supports SAMD51 at the moment.

Test, debug and validate SPI driver on GD32VF103

As more and more architecture and drivers are added, some configuration system similar to what can be found in the Linux kernel might become necessary.

Add something like:

bool lsb_first

or maybe better:

typedef enum {
SPI_ENDIANNESS_LSB_FIRST,
SPI_ENDIANNESS_MSB_FIRST,
SPI_ENDIANNESS_COUNT
} spi_endianness_t;

in struct spi_settings

Test, debug and validate the risc-v architecture

The stm32h743 is rated for 400Mhz but when i try to switch the sys_ck to a 400Mhz pll1_p_ck, the system stalls.

Test, debug and validate wd driver on GD32VF103

Add support for mips cores in general and pic32 in particular

Right now, cache functions are ifdef-ed depending on the need (especially on the staging PowerPC archs).

This shouldn't be the case, a cache management function is a cache management function regardless if it's used or not, this should be handled at the drivers, scheduler or device level.

More or less any level except the current one.

For better readability, i suggest to remove all booleans from the xxx_setup() arguments.
This would make structure inits more readable for the casual reviewer, not having to guess what this "true/false" statement is all about.

This is a generalisation of issue #59

Test, debug and validate uart driver on GD32VF103

Test, debug and validate the flash driver on SAM3x series

Test, debug and validate the DMA driver on GD32VF103.
This might require to support #26 first.

After a quick investigation, the problem come from the latest arm-none-eabi-gcc update which inserts a gnu header before the .boot2 section.

Will be fixed ASAP

The F28379D (and F2838x) series offer a dual CPU system that is not quite a dual-core system.
More a dual-MCU system.

Limitations are the following:

• Each CPU/MCU has its own non-shared flash & internal memories (Mx Dx & LSx RAMs)
• The shared memory (GSx RAM) has no arbitration, each cpu needs to take ownership of a section to be able to write or fetch
• And God knows what else

With these limitations in mind, is it possible to run a software on both MCUs at the same time and make it act like it's a dual-core system ? At what cost ?

Don't use the tick as a reference point for ipwm as the task using the ipwm might be run at any time during the scheduling.

Maybe use a separate timer or picoRTOS_get_tick() + arch_counter()

On some projects, having fixed vectors is a prerequisite for safety reasons, ATSAM3X8E & ATSAME5x (and maybe PIC32MX) are a good example of that.

For the moment the trick is do copy the vectors to RAM before altering them. Not an ideal solution by any means.
As we don't want to provide init & linker files, we have to find a way to account for this.

Here's the idea:

1. Add an entry in picoRTOS_device.h, something like DEVICE_HAS_FIXED_VECTORS
2. Add a second entry in the form of ARCH_SYSTICK_HANDLER, which will point to the (hopefully) weak vector entry
3. Add a final entry, ARCH_SYSCALL_HANDLER, same as above
4. Include "picoRTOS_device.h" in the assembly files
5. Replace arch_SYSTICK (or similar) in the ports by ARCH_SYSTICK_HANDLER
6. Replace arch_SYSCALL by ARCH_SYSCALL_HANDLER
7. Put ifdefs on DEVICE_HAS_VECTORS in the picoRTOS_port.c files to remove interrupt registration for tick & syscall

I don't like ifdefs but this one might be acceptable, as devices will work only one way or the other, testing will be done per device/project & not on a global scale.

Plus, this one will just remove stuff & not generate another use case so the complete code can be parsed by the static analyzer as long as DEVICE_HAS_FIXED_VECTORS is defined. Unit test only apply to the scheduler, not the ports anyway.

Test, debug and validate the gpio driver on GD32VF103

Here's the basic idea for MPU:

• Must be fully integrated to the scheduler
• Every task will have its stack protected
• IPCs will create an entry for all tasks
• A new shared memory IPC will probably be required

Unsovled problems:

• Drivers
• Globals (maybe)

Make a script to run static analysis + unit tests + build of all demos to catch any obvious error prior to a release

Test, debug and validate the gd32vf103 device (startup + support)

To increase portability it might be useful to add a gpio_setup function allowing, for example, to invert the gpio output.

The raspberry-pico-SMP demo periodically crashes after a while with a HardFault exception.
The second core seems to crash on a context switch but it is hard to tell exactly the cause as things escalate quickly, core #0 cannot get the spinlock after that and the system freezes.

This is related to inter-core communication, either spinlocks or sio_fifo, as the bus seems quite sensitive to any kind of race condition. Pushing the system to 10Khz helps to highlight the problem (never seen it at 1Khz).

I removed the execute-in-place in this demo already cause it showed the same symptoms but i thought at the time it was due to both cores accessing the flash, called it a unsolvable issue & moved on. There might be more to it.

So maybe there's something we can do about it, maybe the rp2040 cannot tick that fast without having issues. Investigation needed.

Test, debug and validate DMA driver for RP2040.
This one probably need a lot of adjustments, especially to interface with other drivers.

Test, debug and validate the clock system driver on GD32VF103

As i2c is probably my least favorite peripheral to develop and test, a lot has been left out.

It requires at least one more interface in the form of twi_poll() for the slave part.

A simple not twi_poll(struct twi *ctx) that returns -EAGAIN, 0 (write) or 1 (read) should do the trick.

This will allow a slave to know if he’s addressed for a read or a write, allowing asynchronous read and writes.

this is already present in different state machines so it’s just moving code around, the big part of the work will be to re-test everything.

Regarding the setup, 10bit mode is missing, unbalanced scl hi/Lo is not supported, etc, etc and most of the drivers simply ignore basic errors like arbitration loss.

This is a bad idea that will inevitably lead to user error, just use "int addr" to allow direct use of the ADDR_ define and cast in the driver init.

Fix all drivers and demos

Test, debug and validate the CAN driver on GD32VF103

dma-ti_f28x doesn't work properly, don't know if it is software or hardware (like configuration) related.

You can check it out in demo/amigaball-lcd, if you activate the (well needed) DMA, it doesn't work, SPITXBUF doesn't seem to received any word.

Offer support for USB device and host.

Define a coherent USB HAL + a reference driver. Rp2040 or SAM3x seem good candidates.

The USB HAL would ideally make a TinyUSB port to picoRTOS easy

Test, debug and validate the CAN driver on SAME3X (Arduino Due)