Found the FreeRTOS+IO software, but it’s only for the LPC processor boards.
I’m using STM32 processors, and I have no real desire to try to figure out your BSP file structure and software.
I don’t use bsp, as a thing, and if I could get the drivers to be initialized before (a la CubeMX), I’d be able to use it. So has anyone done any work on a port for the STM32 processors? If it existed, I can rewrite the board description to account for the hardware pinouts on my custom board.
FreeRTOS+IO is deprecated, and to my best knowledge, there are no active attempts to define or implement a generic I/O model for FreeRTOS.
If ST is your only target, your probably best bet is to try the ST HAL if you do not wish to write your own BSP. The HAL is not the best software ever written, but for simple I/O it would serve your purpose.
We only provide the interface here and not any implementation. Where did you get the LPC implementation from? I am not aware of any existing STM32 implementation. What problem are you trying to solve?
That’s a problem, since FreeRTOS seems to be weak on I/O. STMicro documentation also does not seem to teach I/O gracefully.
I do think that there’s a need for generic I/O, although my goals would be USART, SPI, and I2C. Each has use cases that cause the use of queues, blocking, IRQ, and DMA modes to be dropped out. SPI, for instance, does not benefit from queues on a driver level, but does on a system packet level. (and that depends on the hardware addressed).
The HAL drivers are not only poorly written (IMHO, but they manage to work), but they are poorly documented. A bunch of “do this” for limited circumstances, but very little “why”.
The LPC implementation is here:
After the Demo 2 paragraphs
All the source files required to build both projects are contained in a single zip file.
Nor am I aware of any STM32 documentation.
What I wanted was the software to do (reasonably) and integrated with FreeRTOS, serial I/O with variable modes, IRQ, Blocking, DMA, all gracefully handled, and with or without queues as needed.
The same basic scheme can be used for SPI, and I2C, within limits, as the use cases are different. Queues, as I mentioned, do not make sense for SPI data except at a system packet level.
I was looking for a well tested and implemented solution.
Still am, although it’s looking like I just need to keep on working on mine,
I do not think that “weakness” is a fair term. When you look at the I/O systems of older OSs (in particular Linux), you will find that they carry a lot of historical ballast around and do not map well to more recent peripherals. Any generic I/O model necessarily projects a certain perspective on hardware which fits many to most state-of-the-art-at-design-time but tends to become awkward over time.
There are discussions going on about a “new” I/O model, but if there was a best widely agreed upon solution, it would have been adopted.
Perhaps fair, perhaps unfair. However, there are a short ton of enhancements to use the cloud, MQTT, and AWS services. Understandable.
I’d like to see this at a lower level for the various interfaces where practical.
What you might be able to do, say-for serial devices, are implementations that provide a skeleton for sending things out, and provide a stub to hook into the send one character, receive one character, etc.
I’d like to see how those discussions about an I/O framework are going.
I’m assuming these discussions on a new I/O model are for Linux. I am unaware of a ‘new’ model being discussed for FreeRTOS.
IMO the biggest concern with a generic framework, as always, is cycle waste and memory bloat. Providing a lower level interface with hooks does project a perspective as @RAc mentioned. This perspective may help in quick development but could become inefficient if the underlying hardware provides more optimized functionality for operations (say writing a C string to a i2c channel). While possibly excusable in development, these inefficiencies may become production problems later.
Ah, that would be a difference.
I’m playing in the embedded processor world, specifically STM32 ARM processors.
What I’m looking for is a generic framework which goes from a system level, employs queues, has an interrupt framework and a DMA framework, and is generic.
You either use hooks to your own operating system’s routines (say serial send character) or have places where you call your own routines directly. Of the two, the hooks seem to be nicer.
If you find that the model is inefficient, then you’d be free to modify your low level drivers.