0
\$\begingroup\$

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

\$\endgroup\$
  • \$\begingroup\$ Can you form a committee to screw in a light bulb? You sure can! \$\endgroup\$ – DKNguyen Apr 6 at 20:47
  • \$\begingroup\$ 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. \$\endgroup\$ – jonk Apr 7 at 5:55
  • \$\begingroup\$ 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. \$\endgroup\$ – jonk Apr 7 at 6:00
  • \$\begingroup\$ @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? \$\endgroup\$ – xyf Apr 7 at 14:01
  • \$\begingroup\$ 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. \$\endgroup\$ – Lundin Apr 7 at 14:10
1
\$\begingroup\$

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..

| improve this answer | |
\$\endgroup\$
  • \$\begingroup\$ 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 \$\endgroup\$ – xyf Apr 6 at 21:41

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.