Page 1 of 1

OSDebbug() and SALVO scope

PostPosted: Sun Nov 10, 2002 4:40 am
by luben
Hello,

When working with SALVO there are not so many ways to understand that the tasks work smooth. From my own experience I can tell that SALVO just works without problems and all tasks have enogh time.

Thinking in this direction I suspect that if the project grows too much, or the calculations are too heavy, or there are too many runned tasks.. maybe will come moment when I have to determine the current status of SALVO - need I to increase the uP speed, to optimize tasks, etc.. Well, there is a special feature in SALVO that brings this information, but I never used it - first it takes too much time and second - too much resources.

I propose to add some new feature, OSDebug() that is extremely fast and in the same time brings enough information for the tasks. What I need is when the tasks run, from one side and from other side - when they are delayed, waiting, eligible... This info is binary - RUN/NOT_RUNNED - one bit for every task. It could be accumulated into some variable and then displayed via LEDs or RS232 or other way. OSDebug have to be called from the main level, where OSSched exists. You just call it and then transfere the data to other variable, or directly to pins, LEDs, etc.

I still don't have clear vision of how it have to look like. I will explain what it should do and maybe you can find the best way to create it.

When I call OSDebug() it returns one character - the task that will run after OSSched is executed, nothing more. This character could be displayed on LEDs or via pins, (if= 0 -> pin0 = 1, if=1 -> pin1 =1, etc.) then with simple osciloscope I could measure the duty of the tasks, how often they run. If I have multichannel osciloscope I can even find the whole pictures of all tasks at once.
The simpliest what I can propose right now should look like:

.... // if there are for example 8 tasks
var = OSDebbug();
PORTC = 1 << var; (the correcponding to the task number pin will LIGHT or =1
OSSched();
....

The result - I can see in real time the RUN diagram of the tasks, when they are active and when not.... well, on the price of several pins. For sure you can go forward by adding simple serial register (like on your fan project) - then the user will lost 3 pins and gets 8 task display. Even more (like present to SALVO) - I can make small debbug board with 8 or 16 LEDs, controlled from 2 pins that displays the TASK diagram.... SALVO will distribute small and very fast subroutine to display data on this board and even can bring such board in addition to the SALVO (I'm sure that such board will not exceed 5-10$).

Writing this letter in my mind came many ideas ... to display different information (OSDebbug(OSWHAT_TO_RETURN) - like momentary picture of all taks into variables - OSVAR_RUNNED, OSVAR_ELIGIBLE, OSVAR_WAITING, OSVAR_DESTROYED....

For sure I'll make for myself such "SALVO scope" - simple board to display data via SPI (the communication should be extremely fast) with several LEDs and even more - with LCD and rotary encoder to display on the LCD the duty of tasks in %, free time and other parameters, chosen from the user. The individual average duty could be easy created by simple integration /analog multiplexing and ADC conversion. Well, in the beginning it will be just small and simple board with LEDs. In fact I never used more the 8 tasks, so 8 LEDs could be OK for beginning. The final result should look like on the osciloscope:

TASK1 ____+___+_++_______+ // high prority task
TASK2 ++____________+_+___
TASK3 ___________________+_ // low priority task
TASK4______+______+______ // periodic task
- you can simply check periodical tasks how they work, if low priority task wake up in expected manner

or if using SALVO scope with LCD dipslay

TASK 0 24%
av.PERIOD 20 ms
DURATION max = 7 ms aver.= 4 ms

/with the rotary encoder you just browse the channels. If using faster processor on debbuger board (DSP) you can determine coflicts between tasks, statistic,

In short:
- I propose to add some new service that returns the status of the SALVO - what task (number) will run after calling OSSched. In future it could be extended to - "binary map" of eligible/waiting/stopped/destroyed tasks. This infor is extremely short and compact, don't take place and could be extremely quickly output (if using SPI - within couple of uS on 4MHz PIC)
- this simple and fast service will allow to users to reveal the internal working of SALVO, how the tasks works, do they have time, does "free time" exists and to display the status on cheap hardware (board with LEDs and some shift register and simple logic). If the user has osciloscope (if multichannel - the best) he can see many details in the intertask behaviour... unfortunately hidden at this moment.

If you note, the service should be called just before calling OSSched. If you call it ommediately after calling the OSSched, you will have distorted picter of the timimg - the time will be delayed with one OSSched() call and the timing diagram will be incorrect.... as "father" of SALVO you can get a wy to extract the info before calling OSSched().

Even I have idea - if you use OSDebbug, then you can separate the OSSched into 2 parts - calculating part and executing part. The first part just calculates which task will run now, the second service just brings the control to the task. Then I can call OSDebbug() between these services.. like:

............
OSSched_calculate(); // calculate which task should be run now
var = OSDebbug();
send_to_DEBBUGER(var);
OSSched_execute()
...........

I don't insist for OSDebbug() automatically to output the data - in this case you can implement the service inside OSSched. The disadvantage is that every project needs different pins and maybe has diferent free resources to output the debbug data. So - it need separation of OSSched, or OSDebbug just to can calculate the same things like OSSched (in the second case we should be careful for cases, when some event appeared in the window between finishing the OSDebbug and starting the OSSched, that changes the current "have to run" task).

Just an idea... but I feel that there is something useful.

Best regards and have you a nice weekend
Luben

[This message has been edited by luben (edited November 10, 2002).]


Re: OSDebbug() and SALVO scope

PostPosted: Wed Nov 13, 2002 6:42 am
by luben
Hello,

For one debbugger monitor for SALVO the most important things are:
- to be extremely fast
- to use as less as possible RAM and ROM resources

Because I propesed to output only the sequential number of task (OSECBP), that will be run, then the size of data is very small - for ordinary use of SALVO will take 3-4 bits (3bits - monitoring of 8 tasks, 4 bits - monitoring of 16 tasks, etc,) In the case, when no task is elligible - the user should send to monitor ZERO - no task available. It's even possible to use single wire to transmit data (like DALLAS protocol, or other type of coding) .. of course on the price of lower speed.

If the SALVO monitor uses uP, it can bring to user statistic for the different tasks on LCD like :
- average % of total time usage
- max using time (the longest time, used from the task
- min using time (the shortest time, used from the task)
- average frequency of running the task
- corelation between tasks
- statistic (total counts of run for all tasks, average "free" time in %)

It's possible to output events as well.

In fact one byte is more then enough to output very, very valueable information. In addition, if the the SALVO monitor uses uP, it can calculate and show on LCD monitor useful information in real time.

Of course simple indicator with LEDs and outputs, that could be measured with osciloscope are welcomed.

For the uP version of the SALVO monitor I feel that one rotary encoder will allow fast browsing between menus and data. Why not to menshen, that graphic displays exist and the information could be arranged in smart and pleasent way... don't forget that we are in 21 century.

All this is just an idea, about device and process of tranfering data, that will help to SALVO users to debbug the multitasking system.... monitor of the running tasks.

Thinkg for the future, we can imagine that this monitor receives initial information from the tested system about the priority of the tasks, or tracking for events. It's possible or the user to chose different protocols to exchange more or less data. For example, in the "enchenced mode" the user can send full picture of the SALVO - the status of all tasks and events.

Best regards
Luben


Re: OSDebbug() and SALVO scope

PostPosted: Tue Nov 26, 2002 1:55 am
by aek
Hi Luben.

I've sent you an updated sched.c that you can use as the basis for your monitor program ...

------------------