Real Time Spectrum Analyzer

Go To Last Post
45 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I am trying to find out which tasks are real time tasks in Real Time Spectrum Analyzer. I read the description given in link https://www.electronics-notes.com/articles/test-methods/spectrum-analyzer/realtime-spectrum-analyser.php

 

I would say there are three tasks 

 

  1. Sampling
  2. FFT processing
  3. Display

 

I think sampling is real time task and we can't miss any sample. It's necessary to process each data and display data without losing 

 

I am trying to understand how this system keeps the CPU busy to achieve the deadline

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 2

I am trying to find out which tasks are real time tasks in Real Time Spectrum Analyzer. 

You prob won't---You are somewhat confused---"real time analyzer" almost nothing to do with your question, per se...the analyzer type, just works very fast without the normal "sweeping"...hence its result is instant (someone just decided to call it real time).

So the fact they call it a real-time  analyzer vs a normal analyzer, doesn't mean they used an rtos or something specific in one vs the other.  Either, both, or neither type of analyzer could use similar processing (in terms of real time).

 

I could own a normal thermostat (A) that updates the temperature display every minute

I could have the deluxe "real time" version (B) that updates the temperature display 100 times a second

Both units use the same software

 

I am trying to find out which tasks are real time tasks in Real Time Spectrum Analyzer. 

Why exactly this--did you pick a spectrum analyzer for any specific reason (other than its name)?

There are lots of app notes on how spectrum analyzers operate internally (less on software functions)...so tht could serve as a guide for things the software needs to do...you prioritize them.

 

I am trying to understand how this system keeps the CPU busy to achieve the deadline

You probably consider how the system keeps the CPU from being overloaded (scheduling, efficiency, prioritization, etc) to give a fast "real time" response.

There is no reason to be befuddled by a mystery.  So far, have you run into any roadblock?  You can likely come up with a handful of viable organizations for the software.

When in the dark remember-the future looks brighter than ever.   I look forward to being able to predict the future!

Last Edited: Wed. Jan 12, 2022 - 01:17 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

muke12 wrote:
I would say there are three tasks 

that's "tasks" with a small 't' - it may or may not correspond to software Tasks in an OS (or RTOS) sense.

 

In fact, it's quite likely that some of it will not be done in software at all.

 

I would add a further task:

 

4. User Interface 

 

There may well be others - such as a network interface, storage, calibration, etc ...

 

muke12 wrote:
the CPU

What makes you think it has only 1 CPU ... ?

 

In such a system, keeping the (sic) CPU busy is not a problem - there is loads for it (or them) to do!

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
Last Edited: Wed. Jan 12, 2022 - 12:55 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0


 

Just to give you an idea of possibly the simplest spectrum analyzer possible see;

 

 

http://elm-chan.org/works/akilcd...

 

;----------------------------------------------------------;
; Main

main:
	sbrc	_Flags, 0	;Wait for end of wave captureing
	rjmp	PC-1		;/

	 rcall	make_wave	;Make wave form				[410us]
	 rcall	rfsh_wave	;Display wave form into LCD		[480us]

	 rcall	do_window	;Fill butterfly table			[340us]
	sbr	_Flags, bit0	;Restart captureing for next
	 rcall	do_fft		;Butterfly operations			[4.4ms]
	 rcall	make_bars	;Get scalar values, update spectrum	[3.3ms]
	 rcall	rfsh_bars	;Display spectrum bars into LCD		[660us]

	 rcall	check_pause	;Check MOSI pin for Pause/Resume	[0.8us]

	rjmp	main		; (approx. 70 cycles/sec)

 

That's basically a continuous loop of performing FFT then updating the display. All parts of that are "real time" (there'd be no point updating the display with a "picture" of the sound as it was a few seconds ago!).

 

It's a good example as (because it is so resource limited) it's only doing what is absolutely necessary to produce and display a small spectrum analysis.

 

Last Edited: Wed. Jan 12, 2022 - 01:07 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

avrcandies wrote:
You are somewhat confused---"real time analyzer" almost nothing to do with your question, per se

Indeed.

 

Have you just googled "real time" and assumed that all hits must relate to Real-Time computer Operating Systems?

 

This, of course, is not the case - the term "real time" is widely used in many different contexts; eg,

 

https://www.gov.uk/government/publications/real-time-information-improving-the-operation-of-pay-as-you-earn

 

this has absolutely nothing to do with software operating systems.

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 2

muke12 wrote:

I read the description given in link ...

 

But that description is simply a load of marketing speak lifted from a press release.

#1 Hardware Problem? https://www.avrfreaks.net/forum/...

#2 Hardware Problem? Read AVR042.

#3 All grounds are not created equal

#4 Have you proved your chip is running at xxMHz?

#5 "If you think you need floating point to solve the problem then you don't understand the problem. If you really do need floating point then you have a problem you do not understand."

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Rather curiously my project links in #4 are actually better than $10,000 (or whatever it is) in #1 because Chan's project actually shows you the signal in both the time domain and the frequency domain at the same time! ;-)

 

(actually many scopes these days can show you both the discrete analog input and the FFT at the same time - it's actually a feature worth looking for - especially if you work with audio where spectrum analysis is particularly useful)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson wrote:
especially if you work with audio where spectrum analysis is particularly useful)

or RF (VLF thru GHz)

 

FF = PI > S.E.T

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson wrote:

 

 

That's basically a continuous loop of performing FFT then updating the display. All parts of that are "real time" (there'd be no point updating the display with a "picture" of the sound as it was a few seconds ago!).

 

 

clawson wrote:

Rather curiously my project links in #4 are actually better 

 

I would like to know the answers to some questions related to your project. 

 

ADC sampling is hard real time requirement 

 

Within what time interval samples should be taken ? 

 

How many samples were you taking. were you taking 128 samples? 

 

If you were taking 128 samples then how many milliseconds were you taking to process 128 samples i.e. FFT processing time. 

 

Did you have to process 128 samples in 7.3 milliseconds?

 

The spectrum is displayed on the LCD, does the LCD need to be updated, if yes, within how many milliseconds the LCD needs to be updated? 

Last Edited: Wed. Jan 12, 2022 - 05:28 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

muke12 wrote:
I would like to know the answers to some questions related to your project.

He gave you a link to the project - you could take a look and answer most of these for yourself.

 

Did you have to process 128 samples in 7.3 milliseconds?

Where does 7.3 ms come from?

 

does the LCD need to be updated

Of course it does - otherwise it's not going to display anything!

 

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The sample timing requirement depends totally on the frequency range to be measured. According to Nyquist Sampling Law, sample rate needs to be at least two times the highest frequency.

 

If sampling is not uniform (e.g. each sample-sample time is the same as all the others), the spectrum will be blurred. How tight this requirement is depends on the spectrum. If there is a very narrow signal (e.g. a low phase-noise oscillator), the timing requirement is very tight. If it is very broad (lets say, a broad-band amplifier), then timing requirements are less tight.

 

Jim

 

Until Black Lives Matter, we do not have "All Lives Matter"!

 

 

Last Edited: Wed. Jan 12, 2022 - 05:39 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Just to be clear it's not MY project. It's something written by an engineer who's far more talented than I could ever hope to be called E L Chan. 

 

While you can download the same ZIP as I did and study the same code you can even see a comment in the short snippet I posted above that suggests 70Hz for display updates. I seen to remember the FFT is split into 64 bins (in fact the LCD is surely 128 pixels wide and half is used to show FFT bins and half for ADC samples).

 

So if it's doing 64 ADC samples in 1/70th second then maybe ADC is sampling at 4.4kHz? However I suspect it may be oversampling for accuracy and perhaps the sample rate is 4 times this? That could be right as the theoretical limit is 15.3kHz

 

But don't GUESS about any of this (as I just did). Download the project and spend a few nights studying it and I'm sure you can answer any questions you have. 

 

As I say this is a bit of a toy (though a clever display if you were doing something like a low end synth!) but the point is that in minimal code and hardware it's giving the merest hint of a taste of what goes on in a $10,000 Rohde & Shwarz or whatever.

 

It is a work of genius of course, especially the tight/fast FFT. The rest of the project is basically a showcase for the FFT library. 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson wrote:

While you can download the same ZIP as I did and study the same code you can even see a comment in the short snippet

 

I don't know assembly language,  I am trying to know that all tasks are real-time tasks.  I think the first task  is a real time task.

 

Are FFT and Display Tasks also Real Time Tasks? 

 

If I have to set task priority, I will consider the first Task as the higher priority Task.  

 

Which Task will lower priority task  FFT or the display Task?
 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Surely, sampling is the only time critical task. Everything else has to be done "soon enough".

 

I really think that you are missing some critical design concepts by trying to force this into a prioritized task model. Many sub-RTOS programs never use this model and just structure the program to be "good enough". Flow charting and finite state machine concepts tend to be far more useful tools. But, even more important is the simple fact that there often is no, single, "Best Way". You use what works for you and the application. 

 

Jim

 

Until Black Lives Matter, we do not have "All Lives Matter"!

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

ka7ehk wrote:

I really think that you are missing some critical design concepts by trying to force this into a prioritized task model.

 

Isn't  clawson saying in post #4 that all Tasks are real time task? 

 

Only one task can be executed at a time, so I ask for priority.

 

clawson wrote:

 

That's basically a continuous loop of performing FFT then updating the display. All parts of that are "real time" 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

That whole program is "real time", the collection of the ADC samples, the Fourier Transform and the display. This is so the display can be updated 70 times per second so it's always an up to date ("real time" if you like? ) representation of what the input sound signal is doing.

 

Most AVR programs are "real-time" in fact.

 

The one limiting factor (well, OK, two) that would stop it going any faster are (a) you probably can't collect ADC samples any quicker and (b) even if you could that is an old technology display that uses Super Twist Nematic (STN) liquid crystal and it can take up to several milliseconds to switch any pixel between on/off or off/on states so there comes a point on such a display that if you try to update it too quickly the pixels simply "blur" (see games on original "Gameboy" that sometimes showed signs of blurring the action for instance) 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

UHH, the "priority" is baked into the code structure. YOU design the code so that the elements of the program are executed when they need to be and at the necessary speed. It is all hand crafted so that it just works. That is typical of many smaller embedded applications. Sorry that its not nice and tidy for you. That is just the way that folks have been doing it for a long time.

 

Jim

 

Until Black Lives Matter, we do not have "All Lives Matter"!

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

so I ask for priority.

Why?  It is sort of like asking which shoe are you supposed to put on first?---you get to decide many things yourself....planning and execution are what you will need to undertake.

If I have to set task priority

Who is telling you to set any priority, or even use an RTOS?  Are you being told (perhaps by an instructor) to analyze something in a certain way? 

Maybe you already have a post about that?

When in the dark remember-the future looks brighter than ever.   I look forward to being able to predict the future!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson wrote:

That whole program is "real time", the collection of the ADC samples, the Fourier Transform and the display. This is so the display can be updated 70 times per second so it's always an up to date ("real time" if you like? ) representation of what the input sound signal is doing.

 

My main goal  is to understand how tasks are executed in spectrum analyzer. I'm taking a hypothetical example. I think it wouldn't hurt to assume hypothetical situation to understand the concept. 

 

An ADC is sampled at a fixed sampling rate using a timer interrupt. Timer interrupts occur, e.g. every 10μs. This is high priority Task that must be handled and completed without failure. 

 

Assuming the display must be updated every e.g. every 20ms. If it takes longer than 20ms, display and/or sound performance will affected. 

 

Assuming that we are taking 1024 samples, so we should not take more than 20ms to FFT computing process. 

 

Thus we need to do the time analysis and determine how to do all tasks under time limit
 

Last Edited: Thu. Jan 13, 2022 - 06:48 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0


@OP Just because a unit is called a Real Time Spectrum Analyzer DOES NOT mean that the internal software has to use any form of real time operating system.

 

I offer this example...

 

 

...that, as you can read, is a Klark Teknik DN60 Real Time Spectrum Analyser.

 

However, it does not use a processor to do any of the analysis. Instead, it has a bank of 32 analogue filters followed by 32 analogue rectifiers. Those 32 signals are then fed to an ADC so that they can be displayed, 'digitally', on the LEDs.

 

The processor is a lowly 6502, with 2k of EPROM and 1k of RAM. All it does is control the timings of the analogue/digital circuits.

 

 

In your other posts about this subject you have been given suggestions as to reading material. Have you actually read anything and done other research?

#1 Hardware Problem? https://www.avrfreaks.net/forum/...

#2 Hardware Problem? Read AVR042.

#3 All grounds are not created equal

#4 Have you proved your chip is running at xxMHz?

#5 "If you think you need floating point to solve the problem then you don't understand the problem. If you really do need floating point then you have a problem you do not understand."

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0



My main goal  is to understand how tasks are executed in spectrum analyzer.

well that was already brought up with some examples and even a photo (here is a more readable)

 

One way:

1 grab a set of samples

2 calc the FFT of the samples

3 display the FFT 

4 go back to 1

Each of these steps can take 1ms or 1 minute or 1 hour to do...the real time speed is how fast they can all be done so the display looks live for the signal.

Other arrangements are certainly possible, it is up to you.

This is high priority Task that must be handled and completed without failure.

 Well not really...   Take a look: 1.2.3.4.1.2.3.4.1.2.3.4.

 

You can make it complicated if you want to make it complicated, but you need a reason to do so.

You could have an IRQ firing to gent new samples while the display is being written .  Have you seen interrupts before?  Note this is not required for basic operation.

 

Take a look at some example Ham projects if you plan to build a spectrum analyzer.

When in the dark remember-the future looks brighter than ever.   I look forward to being able to predict the future!

Last Edited: Thu. Jan 13, 2022 - 07:29 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The OP may be misunderstanding the basic concept of 'real time'. There's no such animal.

 

What there is are functions which must be performed in a certain time period. In your hypothetical signal analysis system, that is controlled by the speed at which the display can be updated: assume for the sake of argument that it cannot be updated in less than 20ms, as a function of the display technology. Getting data to the display might take less than a millisecond, but it takes a while for the display to sort itself out.

 

Assume further your FFT and signal display require 128 points of data. How long that will take to gather depends on your sampling rate, but the significant thing is that there is no point in collecting those 128 samples more than once in any 20ms period - you will be unable to see them on the display (for simplicity I ignore signal processing issues such as windowing and oversampling). If you sample at 1MHz you will be able to grab your samples in 128us - and will display a result with frequency information up to 500kHz. If you sample at 1kHz you will require several display periods to collect sufficient data to process; that's part of your design requirements.

 

The point I am making is that nowhere here is any requirement for 'real time'. There is just 'as long as it takes' - and that is decided by you. At a higher sample rate you may need to employ DMA techniques to grab the data; at a lower rate you might do it with individual timer interrupts. It doesn't matter. The basic structure is still

  • wait until data is ready
  • perform fft
  • update display

and you can't do that any faster than once every 20ms or your display will be a hopeless blurry mess. That's the real time aspect.

 

A real-time-operating-system doesn't guarantee real time in any sense except this: it guarantees that certain system calls will occur within a specific time.

 

Neil

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Of course the Chan project falls down as an example as it's only doing one thing, one task, as fast as possible. For example it is not reading buttons and knobs from a user interface (for example). That is the kind of thing that you might not need to service quite as often as the very regular requirement to read the samples, do the FFT and update the display. So in such a system the UI might be "non-real time" because there is not a very definite/specific requirement for when that activity must happen.

 

BTW in modern oscilloscopes and logic analyzers the reason there's often a 5 to 10 second delay between you turning it on and then actually being able to see a waveform or use the device is because it is booting an operating system (quite possibly Linux) so in these more complex devices where multiple things may appear to be happening at once they are probably running multiple threads of execution and some may have a very "real time" requirement whereas some may be lower priority tasks that just slot in when there's a bit of free CPU time.

 

(if they do run Linux (rather than something like VXWorks/NucleusPlus/etc) then it's probably a one with real-time mods to the kernel so some very time constrained tasks can be arranged to un at exact points in the execution cycle).

Last Edited: Thu. Jan 13, 2022 - 09:31 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson wrote:
if they do run Linux (rather than something like VXWorks/NucleusPlus/etc) then it's probably a one with real-time mods to the kernel so some very time constrained tasks can be arranged to un at exact points

Or, possibly, the really "hard" real time stuff is done on a separate processor (or processors or, possibly, FPGA at the high end), and the Linux stuff is just a "manager" and user interface ...

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

barnacle wrote:
the speed at which the display can be updated

There's also the fact that the purpose of the screen is to be viewed by a human being - so there's no point updating it more frequently than a human being can perceive

 

there is no point in collecting those 128 samples more than once in any 20ms period

Unless you're averaging several 'acquisitions' for each display update - where it would become (n x 128) samples in the 20ms period ...

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

awneil wrote:

...possibly, FPGA at the high end...

 

That.

 

And not just at the high-end. See here for a tear down of a budget 'scope which uses an FPGA to do all the heavy lifting.

 

https://www.youtube.com/watch?v=...

#1 Hardware Problem? https://www.avrfreaks.net/forum/...

#2 Hardware Problem? Read AVR042.

#3 All grounds are not created equal

#4 Have you proved your chip is running at xxMHz?

#5 "If you think you need floating point to solve the problem then you don't understand the problem. If you really do need floating point then you have a problem you do not understand."

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

Again, l assert that the OP is not doing himself/herself any benefit by trying to force things into a task model with priorities. Of course, every designer has to determine what is important and how to guarantee that things are done when they need to be done. But trying to force that into a model that is compatible with an RTOS gains you little or nothing unless you actually need to use an RTOS.

 

For example, I have a product that does real time sampling, signal processing, data storage in a memory card, manages serial I/O with a menu system, manages a real-time clock, monitors battery voltage with the ADC, and provides status indications on some LEDs. There is NO RTOS anywhere. BUT, it does depend, heavily on finite state machines (several of them); I could not retain any hope of sanity without FSMs. Yes, I do still have hope! This program essentially fills a 32K chip (M328), so it is not trivial. 

 

For small programs (think microwave oven timer), there might not even be any "real-time" element involved. Even the "real-time-clock" clock is not very time critical; it just needs to not loose seconds! There is a whole class of small-medium size applications where timing of one or a few actions is absolutely time critical, so critical that an RTOS is NOT appropriate because the RTOS overhead is too great. In the same size range, there are a host of applications where using an RTOS would not hurt, but really does not help much. I would argue that it is that grey zone between an application that requires a full operating system and the smaller applications that do not really need an RTOS where an RTOS can really help. Few of us, here, ever do anything that complex. I have not in 40+ years of embedded system work (whale trackers, security system controllers and support hardware, timers, data loggers, and more). 

 

I basically argue that focussing on the idea of tasks (and whether or not a given task is cooperative or preemptive or something else) really omits the skills needed to do a good basic embedded design. With such a focus, you will end up loosing, in my opinion.

 

Jim

 

Until Black Lives Matter, we do not have "All Lives Matter"!

 

 

Last Edited: Thu. Jan 13, 2022 - 08:45 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Many previous threads from OP suggest a possible fixation on tasks/threads/OS/real-time etc though, as you say, it's seldom relevant to AVR8 work. But it's probably true that a $10,000 piece of very fancy lab equipment does touch on some of this though, as others have observed, for the real high spec sampling rates in devices like this the real-time data capture is likely FPGA anyway and not multi-tasks battling to share time on some single CPU

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I amm not trying to belittle the OP, or criticize the questions. They are valid and important questions in certain contexts. 

 

I simply think that the OP seems to have becomes obsessed with the idea of tasks. Of course. many of us divide out programs into tasks, whether or not we call them that or think of them as that. And, we decide on priority (sometimes changing the priority as we design), but informally. Sometimes, we may even list things to be done, when they need to be done, which can be interrupted and which can't. But, for many of us, this is informal. And, almost always, the program is simply structured to make it happen. As Captain Picard was fond of saying, "Make it So!".

 

Perhaps, the name "task" bothers me, because the OP uses it continually and it is strongly associated with an RTOS. I tend to think "data reading from the sensor is the most time critical thing in the whole program", and thats it. Were I to call it "task", for me, that immediately invokes RTOS and a particular way of thinking and program structuring. 

 

Jim

 

Until Black Lives Matter, we do not have "All Lives Matter"!

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

ka7ehk wrote:
Perhaps, the name "task" bothers me, because the OP uses it continually and it is strongly associated with an RTOS.

Indeed - my point exactly in #3.

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson wrote:
Rather curiously my project links in #4 are actually better than $10,000 (or whatever it is) in #1 because Chan's project actually shows you the signal in both the time domain and the frequency domain at the same time! ;-)

 

Great,The best of Elm-Chan

http://elm-chan.org/works/vlp/re...

http://elm-chan.org/works/pci/re...

www.tokopedia.com/madagang .Buy and Donated cheap electronics and manuscripts.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

I would assert that the most important "work of genius" that Chan has contributed to the world is actually:

 

http://elm-chan.org/fsw/ff/00ind...

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

ka7ehk wrote:

Perhaps, the name "task" bothers me, because the OP uses it continually and it is strongly associated with an RTOS.

 

I have used the term task because I wanted to understand how each task run in scheduling when there are multiple tasks. I liked this example to understand scheduling, so I have tried to understand it. 

 

With this specific example, I was trying to understand which scheduling algorithm is being implemented for this example.

 

There can be many ways to design this. I was thinking if it has to be achieved by scheduler then how can it be done?

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

muke12 wrote:
I have used the term task because I wanted to understand how each task run in scheduling when there are multiple tasks.

and there you go again - right there!

 

You are confusing the generic, plain-Enlish word "task" (small 't') - which just means "some work to be done" - with the specific, technical term "Task" (big)  as used in relation to Real-Time Operating Systems.

 

You really need to separate the two.

 

With this specific example, I was trying to understand which scheduling algorithm is being implemented for this example.

But what we're talking about isn't an example of RTOS implementation - Again, we don't even know that it uses an RTOS at all.

 

A particular instrument might,  but we don't - and can't - know that.

 

You can't generalise and say that all real-time spectrum analysers must inherently use a particular RTOS model or scheduling algorithm.

 

 

There can be many ways to design this.

exactly.

 

I was thinking if it has to be achieved by scheduler

That's the point - it doesn't.

 

then how can it be done?

There are many ways it could be done, with & without an RTOS.

 

Even if an RTOS is chosen, there would still be plenty of options for choosing different Task partitions, and different scheduling options

 

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I would like to offer a bit of pseudo-code that illustrates "task scheduling" without task scheduling. In this case, the order is created by the design of the program. Please overlook spelling or syntax "issues"; this is not intended to be an executable program!

 

void main(void) {

    initialize_system();

    while (1) {  //the enless loop
        if (TimeToSample) {
            EnoughSamples = sensor_read();

            if (EnoughSamples) {
                EnoughProcessedData = process_samples();  //must take less time than sample interval
                if (EnoughProcessedData) {
                    send_values_to_memory();
                } //end time to send data
            } //end time to process data

        } // end time to read data
    } //end endless loop

}  //end main()

 

Something, somewhere else, determines when TimeToSample is true. Maybe it is a timer interrupt, maybe a status signal from the sensor. The sample reader counts the number of samples it has read and returns TRUE when enough have been read for processing. The sample processor counts the number of accumulated processed data values and returns TRUE when the appropriate number have been accumulated. 

 

So, it is a "daisy chain", each part setting the status of the next part. This "scheduling" is done by creating a particular program structure. The program designer (e.g. me) thought that sample reading is the most important and that needs to be checked every time through the loop. The designer (me) decided that the sample processor only needs to be checked after a sample is actually taken. And, the data output only has to be checked after processing was done. The designer (me) never considered terms such as task or priority or pre-emptive vs cooperative. The program was simply designed to do what is important at the time each part needs to be done. 

 

A real program would have a lot more code and a lot more details, but this should show how program structure can define the order in which various parts get executed. There is no "scheduling algorithm"; scheduling is achieved by program design.

 

Hope this helps!

Jim

 

Until Black Lives Matter, we do not have "All Lives Matter"!

 

 

Last Edited: Fri. Jan 14, 2022 - 07:24 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

awneil wrote:

 

But what we're talking about isn't an example of RTOS implementation - Again, we don't even know that it uses an RTOS at all.

 

 

Read full discussion I did not say that it needs RTOS. I am saying that there are many tasks in this system that must be scheduled in the right order at the right time. because i was looking for some specific project for scheduling and this project for scheduling seems right to me. 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

You can read about it forever. The best way to gain a better understanding is to build an audio spectrum analyzer yourself. A mems mic, avrdb with an OP amp, and an led matrix display, or a small LCD, for a bouncing bar graph. Less than 10 usd, but incredible learning experience. 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

muke12 wrote:

Read full discussion I did not say that it needs RTOS. I am saying that there are many tasks in this system that must be scheduled in the right order at the right time.

 

Why are you ignoring what you have been told?

 

There is absolutely no concept of tasks or scheduling needed to achieve real time spectrum analysis. It is very very very likely that the main function of the instrument is carried out by dedicated hardware, implemented inside one or more FPGAs.

 

Tasks and Scheduling, as concepts, only apply to software; real time spectrum analysis is a hardware function.

#1 Hardware Problem? https://www.avrfreaks.net/forum/...

#2 Hardware Problem? Read AVR042.

#3 All grounds are not created equal

#4 Have you proved your chip is running at xxMHz?

#5 "If you think you need floating point to solve the problem then you don't understand the problem. If you really do need floating point then you have a problem you do not understand."

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Brian Fairchild wrote:

Why are you ignoring what you have been told?

It seemed to me that spectrum analyzer would use scheduling. ok i assume my example is not useful for scheduling

 

I know what preemptive scheduling is, but don't know what specific project it will be used for.

 

Can anyone suggest specific project to where preemptive scheduling will be used. 

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I am saying that there are many tasks in this system that must be scheduled in the right order at the right time. because i was looking for some specific project for scheduling

Well then, start planning your project!!   Don't just grind to a halt because you have to make decisions and tradeoffs.  That is what design is all about.

There is probably no "right order" & such ordering is up to you.  Whether or not you use a "schedule" of some sort is also up to you.

There will be lousy choices, and others much better--but it is in your hands to analyze them and plan accordingly.

 

One issue is: you probably aren't a spectrum analyzer guru (apologies, if you are).  Not truly being familiar with this rather complex product makes it 10x harder for any concept understanding, especially on the first try.

Pick something simpler & that you already know about much better, like a washing machine, burglar alarm, or cash register.     

 

Can anyone suggest specific project to where preemptive scheduling will be used. 

Absolutely not (ignoring the suggestions above)!!!! 

If you have little idea of where you can use this tool or when it should be used, implies you need to study the concepts further! 

That seems to be the basis of what has been happening so far.

When in the dark remember-the future looks brighter than ever.   I look forward to being able to predict the future!

Last Edited: Fri. Jan 14, 2022 - 11:33 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

muke12 wrote:

Can anyone suggest specific project to where preemptive scheduling will be used. 

 

The best way to learn is by doing so here is an example of a piece of equipment that almost certainly runs a pre-emptive scheduler.

 

In my lounge I have a twin-tuner PVR (personal video recorder). It has the following features...

 

Can receive two TV channels at once

Can record one or both of those channels to a hard disk at the same time

Can playback a previously recorded programme while it is recording one or two channels

Can set a timer to start recording

Has an Infrared remote

Has a small number of buttons on the front panel

Has a basic 4-character 7-segment LED display on the front panel

Has an on-screen GUI menu system

Receives and updates the EPG (electronic programme guide) over the air

Can dump a pre-recorded programme to a USB stick

 

My challenge to you is for you to identify at least 25 software tasks that are needed to achieve that and to show, on a piece of paper, how they interact.

#1 Hardware Problem? https://www.avrfreaks.net/forum/...

#2 Hardware Problem? Read AVR042.

#3 All grounds are not created equal

#4 Have you proved your chip is running at xxMHz?

#5 "If you think you need floating point to solve the problem then you don't understand the problem. If you really do need floating point then you have a problem you do not understand."

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

muke12 wrote:
i was looking for some specific project for scheduling and this project for scheduling seems right to me. 

But what you're looking at isn't a project - it's just a general article about a class of test equipment.

 

You cannot draw any specific conclusions from that article.

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Obviously the answers we give here aren't good enough...

 

https://www.eevblog.com/forum/mi...

#1 Hardware Problem? https://www.avrfreaks.net/forum/...

#2 Hardware Problem? Read AVR042.

#3 All grounds are not created equal

#4 Have you proved your chip is running at xxMHz?

#5 "If you think you need floating point to solve the problem then you don't understand the problem. If you really do need floating point then you have a problem you do not understand."

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Not only that, but he's stolen Cliff's example - the one that was specifically given as an example which does not use an RTOS !!

 

frown

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Brian Fairchild wrote:

Obviously the answers we give here aren't good enough...

 

https://www.eevblog.com/forum/mi...

There’re numberous ways for starting such as DSP chips(offer at Marketplace $1 eBay),Soundcard,etc.

....Bidding starts at $1.   Just hoping to  this from the trash to someone who might appreciate it..  'buyer' pays shipping. 

 

7-day listing began 2021 Aug 12.  

Listing title:  Vintage ADSP 2181 EZ-Kit Lite Development Kit

eBay item number:334111343944

my e-bay username is 'espeterb.'

www.tokopedia.com/madagang .Buy and Donated cheap electronics and manuscripts.

Last Edited: Sun. Jan 23, 2022 - 10:47 AM