0

I am trying to switch to embedded from a software test role, and been working on learning about STM32, and almost finishing up writing drivers for I2C which I used for interfacing with a sensor. I have looked at a lot of job descriptions and most of them do find having an understanding of RTOS essential and I'm wondering if I can incorporate in my existing simple project in any way. One approach I thought of was maybe have two threads with one reading values off the sensor while the other displaying on the screen. Not sure if RTOS is really essential for this specific use-case but just a thought.

Any ideas are appreciated

xyf
  • 315
  • 1
  • 3
  • 12
  • Can you form a committee to screw in a light bulb? You sure can! – DKNguyen Apr 06 '20 at 20:47
  • So much is too often conflated under the term, RTOS. The simplest O/S (by my own definition) is where you support separate stacks for threads, but have an otherwise shared memory layout and shared heap. There's a huge value in merely having separate stacks to switch between. This doesn't even have to be pre-emptive; it can be co-operative and still gain a lot of value. Besides, everything is "real-time." Either that, or it doesn't work or else is a simulator. You have to do what needs doing and do it on time, or better. Windows 10 on a desktop is real-time for some things. Context matters. – jonk Apr 07 '20 at 05:55
  • Reading sensor values and displaying them is more of a loop. Perhaps the minimum case where separate stacks/threads pays off for the trouble is in the case of reading ADC values, processing those values through some functions, and generating DAC output values (in a loop, perhaps) and then add in the need to manage a user interface that includes keys and a display. At this point, you've risen sufficiently to where you might want to start building or looking for some minimum features of an O/S, including separate stacks and perhaps even pre-emption. Maybe even a sleep queue might be nice then. – jonk Apr 07 '20 at 06:00
  • @jonk - how does reading off the sensor and displaying is more of a loop but reading off ADCs isn't? Or you mean one thread solely for reading off ADC, second maybe for processing, and third for sending it to DAC? What's the flow going to be like? – xyf Apr 07 '20 at 14:01
  • Might be smarter to start with bare metal MCU programming and learn how things work underneath the hood. Basic assembler, how to write a proper interrupt while avoid race conditions etc. If you start from the hardware-related programming, you'll actually know what's going on. If you start with abstract stuff like OS and multi-threading, you risk ending up yet another hopeless PC programmer who can't program embedded systems without using consoles, heap allocation, threads etc - things that are most often nonsense in embedded systems. – Lundin Apr 07 '20 at 14:10
  • @Lundin - I have used interrupts for GPIOs and I2C now and I feel I do have a decent understanding of how interrupts work now. I haven't used other peripherals like ADCs, DACs, DMA to name a few though. With the project that I have now, I'm thinking of building something on top of it and given how essential RTOS is nowadays, I thought I'd learn and use it in some way. – xyf Apr 07 '20 at 14:27
  • @xyf Okay. In my experience, some rough 90% of all people dabbling with embedded systems don't know how to use interrupts though. You can check how much you actually know by peeking at these posts: https://electronics.stackexchange.com/questions/329339/avoiding-global-variables-when-using-interrupts-in-embedded-systems/329961#329961 and https://electronics.stackexchange.com/a/409570/6102. If everything said there is stuff that goes without saying to you, then you know interrupts indeed. – Lundin Apr 07 '20 at 14:35
  • @Lundin - thanks for sharing the links. I can relate to most of the things here because I did face similar issues regarding the scoping particularly for the driver code with one of them being able to use variables inside the IRQ handler, so I defined a volatile static pointer for that. Also, IRQ handler is within my driver code and not being touched outside of it so that's good. One thing that I haven't addressed is the usage of semaphores though - how essential are they when it comes to interrupts in a single thread application? – xyf Apr 07 '20 at 16:13
  • @Lundin - also, just a note -> the comment regarding efficiency on here is wrong I reckon https://electronics.stackexchange.com/a/329376/247689 – xyf Apr 07 '20 at 16:48
  • @xyf If you didn't get it already, it may be too hard to explain here in comments. I'm saying that it is very easy, in a loop, to read an ADC value, pass it through a function to compute a DAC value, and then write that out to a DAC. Simple cases don't require threads. But if you now need to deal with a keyboard, say with shift and ctrl keys which modify other keys, or various key combos; then now you would benefit (ease of reading and maintaining the code) from threads. That's all. Not that there aren't a dozen other ways to do it. Just that threads make it easy to maintain and read. – jonk Apr 08 '20 at 06:04
  • @xyf An application with interrupts is pretty much to be regarded as "multi-threaded", that is the re-entrant information sharing problem is the very same as during threading. What makes interrupts a bit easier is that they can normally not get interrupted by themselves on most ISA, which in turn means that you can often implement semaphores with plain booleans etc. – Lundin Apr 08 '20 at 06:31

1 Answers1

1

Sure you can use RTOS even for small projects, even when it might make little sense, it is better to start with simple project than to start with complex project. ST officially supports FreeRTOS with STM32 MCUs. Read the FreeRTOS manual how you might want to use it, like having a I2C thread, message passing interface between threads or mutual exclusion etc..

Justme
  • 127,425
  • 3
  • 97
  • 261
  • I'll surely take a look. I also have Mastering STM32 book which seems to have good examples. Any suggestions on using RTOS for an existing project? @Justme – xyf Apr 06 '20 at 21:41