I was looking for a real world application to understand RTOS system. I found frequency spectrum analyzer maybe an example.
What are the tasks in this system which are real time tasks and which need to be completed within the time limit?
It seems to me that the frequency spectrum analyzer can easily be implemented without RTOS.
ok but if it has to do with RTOS ( FreeRTOS) then how will the tasks be divided and deadline for task
I don't know much about it and I haven't programed at that level...
An RTOS could be used with a spectrum analyzer but since the Arduino doesn't normally use an OS I'd guess that the OS overhead would slow everything down and you might need one of the faster Arduinos. (I'm assuming audio frequencies... For very low frequencies you can process slower.)
From what I understand, the "standard" audio frequency spectrum analyzers made with the Arduino don't really run continuously... They sample the waveform for awhile, then run the FFT analysis, then display the results, and then start the loop over. They are more of a frequency analyzer effect, rather than a measurement instrument.
Depends on your definition of "Arduino". Since OP explicitly mentioned FreeRTOS, see ESP32.
Using the dedicate IC (like MSGEQ7 ) make the task nore easy...
Yes ESP32
So you have suggested some Tasks like samples FFT analysis and display.
Sampling should be a high priority task if I'm not mistaken. Each sample should be taken at regular intervals
Hello kittu20
You might take view to a HAM radio forum to get some ideas too.
To get meaningful results, sampling MUST be done entirely in hardware - jitter in sample timing translates to random noise in the output data. Beyond that, how you process the samples depends almost entirely on what kind of performance you expect to get. NONE of these chips are suitable for anything other than VERY low sample rates, without using a MUCH faster, MUCH more accurate A/D.
What frequency range are you interested in viewing?
What sample rate do you intend to use for musical spectrum analyzer ( because OP meant analyzer for music, as I understand). The typical sample rate for this purpose is 20-50Hz, that can be easily achieved by any technic...
Perhaps you meant 20-50 KHz?
Nope, exactly 20-50Hz.
I meant reading the already converted amplitude results by several frequency bands from the MSGEQ7 chip.
it makes no sense to read them more often, a user simply will not be able to see them
I missed that. The MSGEQ7 itself obviously must sample at or above Nyquist. But yea, reading the chip's processed output can be at the rate you suggested.
YOU are talking about using the MSGEQ7 chip. The OP is asking about doing FFTs to do a spectrum analyzer. You are completely changing the topic of the thread, and doing nothing but muddying the waters.
Quite simply this task has to be done in stages, you can't do a stage without completing the previous stage. Therefore this task is not suitable for doing any sort of parallel processing, even if you want it to be.
Pick something like blinking three LEDs at different set speeds that are not multiples of each other.
A spectrum analyzer is not really related to RTOS.
Sure, you can launch your spectrum analyzer when an RTOS thread has finished, e.g. received an audio frame. The RTOS is just there to schedule tasks/threads, but not to call your spectrum analyzer (it might be part of the receiving process, e.g. audio frame: when done, call the function to analyze the spectrum, inside the same thread receiving the data).
If have such FFT, with LCD running on several STM32 boards. My hints are:
- for doing spectrum analyze (which is Math) - use the ARM DSP (if you have available at your platform)
- also: use HW FPU (floating point unit), to speed up the Math operations (FFT is pretty heavy in terms of Math to do)
- when you use RTOS and threads, e.g. you get periodically audio frames, e.g. in a thread: fight for speed: you have to make sure that your FFT processing, even displaying the results is faster as the next audio frame comes in. If not? ... garbage.
If all your math, your display takes longer as receiving audio frames - all is messed up: it just generated garbage on screen, stalls the audio (esp. when you play it out) and might crash your FW (out of stack).
Very challenging topic: my main suggestion is: can you make sure that FFT processing can be completed before a new (audio) packet comes in?
If not (not enough performance on MCU) : no way for endless real-time FFT.
I suggest really: check if your MCU and platform (IDE) allows to use ARM DSP (and how to add, enable on your project).
Use the ARM DSP functions (they provide Fast FFT as a function call).
This is a "must" for fast FFT processing. Doing FFT without Math-Instructions Supported By HW, without HW FPU, it can be too slow for regular C-code.
A spectrum analyzer application is not a great choice.
Which application can you mention that can be good choice
Nope.
OP asked about any application of RTOS technology.