AVR Freaks

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.

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

or RF (VLF thru GHz)

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!

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. 

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

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) 

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?

@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?

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

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

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

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

Indeed - my point exactly in #3.

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

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

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.

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.

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.

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