I’m going to put this here and hope that it is close enough in group. I’m working on a successful (it’s working) project using STM32CubeMXIDE. What I want to implement are queue driven Interrupt enabled handlers for a Wroom32 (UART), NRF24L01 (SPI), and I2C (OLED displays). I have working, interr…

It is related since it addresses a similar topic. Since there are two questions wrapped up here, I’ll go with the FreeRTOS_IO first. Somewhere in the FreeRTOS_IO documentation there was mention of using queues gracefully with such things as SPI, USART, and I2C drivers. Naturally, once you start t…

[image] madyn: I’ve looked at the data link in the other post that I had never seen. FreeRTOS_IO might help with #1, blocking, but apparently this version supports absolutely none of the other features I need. The aim of common IO is to provide a common interface which you implement for your …

As far as I can tell, when you removed the zero footprint mode, you took out at least one feature that I wanted. At the level (I/O drivers for a particular chip type), that I need, I am not seeing how the existing code would be useful. It would be if I wanted this code to run on multiple platforms…

Given SPI, Serial, and I2C, I started working on I2C in the framework of the STM ecosystem. With any interface, receive and transmit are options. For I2C, I have blocking mode, DMA, and IRQ mode working. None of these need queues. Oddly enough, the implementation of I2C with queues seems to avo…

[image] madyn: It would be if I wanted this code to run on multiple platforms, but that is not the case. Then you are right - it probably is not suitable for your application. [image] madyn: Writing a queue at the application level, reading it into a buffer, then sending that buffer seem…

In the STMicro world as provided by CubeMXIDE, there are a number of (rather awkwardly) written drivers for each subsystem. They have a crude form of semaphore built into them (which may not work). There’s generally a driver for blocking I/O, Interrupt driven I/O, and DMA I/O. My drivers (as orig…

I’ll look, in summary, at three interfaces, SPI, I2C, USART. Each has three native modes. Blocking, Interrupt, DMA. There’s a fourth mode, Queues. That opens up a can of worms. For the three interfaces: I2C: working in blocking, Interrupt, DMA. Transfer rate limited by bus speed. Queue, ha…

[image] madyn: A universal driver cannot make sense with only one model considered, there needs to be a different model for each interface. Thanks for summarizing! I agree with your assessment and the assessment of @aggarg . A universal drive interface will only make sense if your underlying d…

The advantage I have here is that, with a bit of connivance, the initialization for each driver family is the same, or nearly so. for I2C: uint32_t create ( char which = 0, int IN_QUEUE_SIZE = 0, int OUT_QUEUE_SIZE = 0, I2C_TRANSFER_MODE IN_MODE = I2C_BLOCKING, I2C_TRANSFER_M…

FreeRTOS_IO and Updating STM32CubeMXIDE

Libraries

aggarg (Gaurav Aggarwal) September 15, 2024, 10:31am 2

Is this related to this post - Replacement for FreeRTOS-IO??

Topic		Replies	Views
Replacement for FreeRTOS-IO? Kernel	19	508	September 26, 2024
FreeRTOS+IO for STM generic boards Libraries	9	167	September 3, 2025
Correct Pattern for FreeRTOS Drivers using Critical Sections Kernel	16	1395	November 7, 2016
learning freertos using pic24 and microsticii 232 comm Kernel	33	674	January 28, 2017
is there an object-oriented C++ port of FreeRTOS or even an over-layer Kernel	29	1300	December 29, 2015

FreeRTOS_IO and Updating STM32CubeMXIDE

Related topics