Electronics > Microcontrollers

FreeRTOS - pre-emptive or not?

<< < (11/13) > >>

NorthGuy:

--- Quote from: SiliconWizard on October 14, 2021, 07:03:22 pm ---That said, even if in the above case, sharing the UART RX wouldn't make much sense.

--- End quote ---

I think by UART RX you mean pins or registers. The example was about buffering and unbuffering, and I expessedly said:


--- Quote from: NorthGuy on October 13, 2021, 06:21:16 pm ---... your UART buffer has become a shared resource ...

--- End quote ---

The buffer is shared between the thread that writes the data to the buffer and the thread that retrieves the contents from the buffer.

Aside of that, you certainly can share a single UART peripheral between different tasks. You can even dynamically re-assign pins to use the same UART peripheral module to talk to different devices connected to different pins, although typically UART modules are not in short supply.

peter-h:
I am doing that but with SPI3, not a UART. That SPI channel is used for multiple devices: ADCs, DACs, special-purpose I/O chips, etc. I've set it up so there is a mutex around the code accessing each device (just one mutex for all of them) and there is a "last device used" value stored so if the new device is not same as last, you re-initialise the SPI and store that device # as "last".

Perhaps surprisingly, it works, but unsurprisingly it took a lot of time to get it to work because the SPI controller needs some undocumented number of APB clocks (and/or the SPI clocks; the frequency is different for each device, from ~500kHz to 21MHz) to settle down. Also some devices need clock parked high, some parked low, some evidently don't care, some clock data on +ve edge, some on -ve edge, some need long timing before/after CS, etc. We had a long thread on this a while ago.

I suspect most people totally avoid doing this sort of thing :) but when it works, it shows the power of an RTOS and mutexes etc. Just don't try it with delta-sigma ADCs which have a 100ms conversion time ;)

SiliconWizard:
I suppose you are reusing a single SPI peripheral by reconfiguring it on the fly if needed and using separate chip select lines?
That would be an example indeed.

But even in such a case, you can still use a single-task approach, which is often less trouble to get right.
Basically, all SPI accesses would be issued in one task dedicated to it. Then you would communicate with other tasks using queues. You can typically set up one "command" queue that each task needing SPI access would fill with SPI access parameters, and then queues for pure data exchange. That may look a bit intimidating at first, but is a lot easier to get right in the end, and scales up better IMO. Hope I was clear enough here with this approach - didn't get into details.

NorthGuy:

--- Quote from: SiliconWizard on October 15, 2021, 06:02:08 pm ---But even in such a case, you can still use a single-task approach, which is often less trouble to get right.

--- End quote ---

That is for sure. Abandoning RTOS is even better. With direct access to peripheral, interrupts, and DMA, you can organize everything much better than RTOS ever could, and write much less code too.

But bring in few huge blocking libraries, and you cannot get by without RTOS any more. Hence the popularity.

ogden:

--- Quote from: NorthGuy on October 16, 2021, 06:04:39 pm ---
--- Quote from: SiliconWizard on October 15, 2021, 06:02:08 pm ---
--- Quote from: peter-h on October 15, 2021, 05:25:06 am ---I am doing that but with SPI3, not a UART. That SPI channel is used for multiple devices: ADCs, DACs, special-purpose I/O chips, etc. I've set it up so there is a mutex around the code accessing each device

--- End quote ---
But even in such a case, you can still use a single-task approach, which is often less trouble to get right.

--- End quote ---
That is for sure. Abandoning RTOS is even better. With direct access to peripheral, interrupts, and DMA, you can organize everything much better than RTOS ever could, and write much less code too.

--- End quote ---

SiliconWizard suggested dedicated task with queues for handling I/O of common peripheral - to avoid blocking of consumer tasks. If you think that better solution is to abandon RTOS - then think/learn again :)

Navigation

[0] Message Index

[#] Next page

[*] Previous page

There was an error while thanking
Thanking...
Go to full version