EEVblog® Electronics Community Forum
Electronics => Microcontrollers => Topic started by: Kittu20 on August 08, 2023, 04:53:53 pm
-
Hello everyone
I've been immersing myself in the fascinating realm of Real-Time Operating Systems (RTOS) with a focus on FreeRTOS. The concepts of task scheduling, synchronization, and multitasking have got me intrigued, but now I'm on the hunt for exciting project ideas to put theory into practice.
Please keep in mind that I'm looking for projects that are within my reach and not too advanced, so projects like radar systems, air traffic control, and satellites are a bit beyond my current capabilities.
Do you have any project suggestions that would be a perfect fit for a RTOS? I’d really appreciate it!
-
Hello,
One project (at least potentially) that you could do is some sort of a medical device or a combination of a health data collection system + smart watch for displaying the health data. The potential problem you have (at least in my personal experience) is that RTOSes in general are seen to have very little actual purpose outside of space, defence, aircraft, medical and vehicle control (everything else can normally be solved without ). So you might be pushed to find an interesting and yet simple real-world RTOS project for learning the RTOS principles.
//Ilya
-
You probably want a simple problem that you can expand and use to explore different RTOS design patterns.
Consider a traffic light controller. Start simple, then expand to include traffic sensors, pedestrian request switches, internal logging, remote monitoring and control, etc.
Pretend you are caught up in a lawsuit where you are having to prove what happens (and/or happened) and why, and that you have to defend you choices and implementation. Those real world considerations can shape the design patterns you choose and implement.
Make sure you understand FSM events and actions, how external sensors cause interrupts that create events. Work out how to guarantee and verify timing by design (not measurement). Avoid multiple priorities; they cause as many problems as they help.
-
what about a simple MODBUS server able to serve up to n clients?
mutex data (kind of central database, on the server)
n tasks, one for each client
:D
-
How about starting with reading Hoare's "Communicating Sequential Processes"? ;D
-
How about starting with reading Hoare's "Communicating Sequential Processes"? ;D
An excellent idea :) Seriously.
Then spot the RTOS primitive functions that are useful for implementing a system using CSP design patterns - and use those and no other primitive functions.
Avoid using functions related to fiddling around with task scheduling.
-
Do you have any project suggestions that would be a perfect fit for a RTOS? I’d really appreciate it!
The most simple OS https://github.com/AVI-crak/Rtos_cortex/tree/master
-
How about starting with reading Hoare's "Communicating Sequential Processes"? ;D
An excellent idea :) Seriously.
Then spot the RTOS primitive functions that are useful for implementing a system using CSP design patterns - and use those and no other primitive functions.
Avoid using functions related to fiddling around with task scheduling.
The only downside is you might find yourself yearning for a language that supports the formalism in a first-class way rather than rebuilding it with an ad-hoc subset of other primitives. ;)
-
How about starting with reading Hoare's "Communicating Sequential Processes"?
I dunno. Communicating processes are the "interesting" and "difficult" part, but the "useful" part of an RTOS is usually being able to have processes that don't need to communicate (much) with each other.
-
How about starting with reading Hoare's "Communicating Sequential Processes"? ;D
An excellent idea :) Seriously.
Then spot the RTOS primitive functions that are useful for implementing a system using CSP design patterns - and use those and no other primitive functions.
Avoid using functions related to fiddling around with task scheduling.
The only downside is you might find yourself yearning for a language that supports the formalism in a first-class way rather than rebuilding it with an ad-hoc subset of other primitives. ;)
Yes and no...
No: you don't have to yearn - use xC on the XMOS xCORE processors (up to 32 cores) with guaranteed hard realtime behaviour (i.e. not measure and hope you've come across the worst cas behaviour)
Yes: even if you have a trad language, "thinking in CSP" is a good way to structure a design and hence structure an implementation using whatever is available.
-
How about starting with reading Hoare's "Communicating Sequential Processes"?
I dunno. Communicating processes are the "interesting" and "difficult" part, but the "useful" part of an RTOS is usually being able to have processes that don't need to communicate (much) with each other.
"Process" in CSP is a much more general concept than an RTOS process. It can be a piece of hardware, or a piece of software running without any RTOS, or any combination. As one example, in the xC/xCORE ecosystem, each "process" has its own dedicated core, and the RTOS is implemented in hardware.
Having said that, avoiding comms between processes is a good principle - provided it makes the design and implementation simpler and easier to understand and modify.
-
if you're looking at freeRTOS specifically, you could just read their book: https://www.freertos.org/Documentation/RTOS_book.html (https://www.freertos.org/Documentation/RTOS_book.html)
(Mastering the FreeRTOS Real Time Kernel - a Hands On Tutorial Guide)
Even if it's written for freeRTOS 9 you can still implement the code examples in the current release. The book is easy to understand at it will also acquaint you with the API and the reference manual
-
Nearly any microcontroller project does lots of things "seemingly simultaneous".
things like:
* Keyboard scanning.
* Display output (muliplexing some 7-segment displays is a fun beginners project).
* Gathering sensor data, keeping track of limits etc.
* Communication with external devices.
And for all "simple" applications this is usually done in a master loop combined with neatly placed ISR routines.
For small systems an RTOS is not needed.
When projects get bigger, quite often an RTOS is still not strictly needed, but it can be nice to add that extra abstraction layer for code readability and re-usablility. Barriers between parts of the software get bigger, and apart from the inherent complexity of the RTOS in itself, this makes software easier to understand, maintain and extend.
But keeping motivation is also much easier when you have a project that personally interests you.
I think it may be a good idea to search around the net (and/or search directly on gitlab) for a project that interests you, and then re-write that project to work with an RTOS.
Also, reading and analyzing code written by others is a separate skill. It's often less fun then writing your own code, but it is a quite essential skill that enables you to stand on the shoulders of all the giants before you. Without that skill you're playing among the insects in the grass. That can be fun too (I remember some book about that). It's just another branch in this Wonderfully Weird World.
-
if you're looking at freeRTOS specifically, you could just read their book: https://www.freertos.org/Documentation/RTOS_book.html (https://www.freertos.org/Documentation/RTOS_book.html)
(Mastering the FreeRTOS Real Time Kernel - a Hands On Tutorial Guide)
Even if it's written for freeRTOS 9 you can still implement the code examples in the current release. The book is easy to understand at it will also acquaint you with the API and the reference manual
That appears to be a tutorial on how to invoke sequences of freeRTOS primitives. That's necessary and useful, but...
It does not indicate something I strongly suspect the OP needs: a discussion of the "high level" structure of his application and its use of any RTOS's facilities. Understanding such "Design Patterns" - particularly when and why (and when not) to use individual patterns will greatly benefit the OP.
Whether the OP realises that is a separate issue, of course.
-
Hey everyone!
If you've got hands-on experience with real-time operating systems (RTOS), I'd love to hear about your projects.
-
The book
FreeRTOS for ESP32-Arduino
is quite an illuminating read with plenty of practical examples if you are getting started.
-
I don't use RTOS, but on general note, I believe in learning through both positive and negative experience.
Positive is the straighforward one: write a program which both blinks a LED and transmits anecdotes through an UART.
Negative is hard and I don't think there are many helps with that out there. It basically means, how to write a program which does fail, so that I can observe that failure.
JW
-
Buy any funny chip (say: a FM receiver, a MP3 decoder,...) and add a keyboard, a display and put that chip to work.
-
Some RTOS project ideas can be taken from this 2023 thread:
https://forums.freertos.org/t/practical-rtos-project-ideas-for-real-world-applications/17981 (https://forums.freertos.org/t/practical-rtos-project-ideas-for-real-world-applications/17981)
And some more ideas from the 2022 thread: https://www.edaboard.com/threads/rtos-learning.407994/ (https://www.edaboard.com/threads/rtos-learning.407994/)
-
I used FreeRTOS to implement a battery charger with a twist.
It not only turns a charger on and off during daylight hours when the battery needs it, but it also collects some stats that are both displayed on a local LCD and uploaded over LoRaWAN so that I can graph them at home and keep an eye on things remotely (since the charger is in a remote building, and is actually solar powered).
There are a few tasks (I think about 13 +/- in total), and a couple of other things like mutexes and queues in use for things like: user interface, ADC readings, relay control, LoRaWAN uplink messages etc.
An RTOS probably wasn't strictly necessary to achieve all of this, but it was a fun learning experience and the various features offered by FreeRTOS made some aspects much more trivial to implement I think.
-
Some RTOS project ideas can be taken from this 2023 thread:
https://forums.freertos.org/t/practical-rtos-project-ideas-for-real-world-applications/17981 (https://forums.freertos.org/t/practical-rtos-project-ideas-for-real-world-applications/17981)
And some more ideas from the 2022 thread: https://www.edaboard.com/threads/rtos-learning.407994/ (https://www.edaboard.com/threads/rtos-learning.407994/)
I see what you did there ;D ;D ;D
-
Some RTOS project ideas can be taken from this 2023 thread:
https://forums.freertos.org/t/practical-rtos-project-ideas-for-real-world-applications/17981 (https://forums.freertos.org/t/practical-rtos-project-ideas-for-real-world-applications/17981)
And some more ideas from the 2022 thread: https://www.edaboard.com/threads/rtos-learning.407994/ (https://www.edaboard.com/threads/rtos-learning.407994/)
I hope the OP takes note. I won't hold my breath.
-
Something in the back of my mind was saying "this name sounds familiar". And there you go.
-
On topic:
The best way to learn something is to implement it yourself.
My guess is that most of the forum users at some point attempted to implement an OS.
Here is my attempt to create a very basic RTOS - just a simple scheduler, for ARM. About 200 lines of code, two files only - rtos.c and rtos.h, and (I think) easy to understand:
https://github.com/cpq/newrtos
No preemption, no message passing/queue API, just a simple round-robin scheduler with 1ms tick.
-
I'm on the hunt for exciting project ideas
Make electronic access-cards and keys copier. Very simple. Very useful. Helps to avoid criminals to steal your keys when you need copy.
-
You can start with some simple project like temperature/pressure/humidity logger.
You can begin with 3 threads:
1) Measurement thread requests data from sensors and archive it in some database.
2) UI thread implements displaying information and interaction with user through menu
3) Communication thread implements communication protocol with PC
-
The world's only intelligent person @tellurium , who is so arrogant about his knowledge and enjoys belittling those with less experience. How sad that arrogance is his only companion