Would it be possible to have some quality screenshots of shell project, specially LIST function output. I am half way on coding shell inside MCU and have problems with formatting and output so this would be helpful. Please send latest version. Also some more explanation on presented data would be great (more than in Youtube clip).
Best regards
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Tomorrow i will look if i still have a chip programmed with the shell lying around. If so, i will make some screen shots and explain what can be seen there. At the moment i am porting the code to xmega and it is not working right now. Of course, best would be if you have a tiny861, flash the shell and connect it to the parallel port of some old pc. It is really not a lot of work, and you can play with the shell yourself. The shell demonstrates preemptive and cooperative tasks running simultaneously, as well as the file system, a os load monitor and much more.
Your other post also gave me something to think about, I will react later.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Below please find a copy from the input/output of the shell program. It says id is 0.91, but i am pretty sure it is a near 0.92 version. Below that there is an explanation of the fields. Hopefully this provides some information. Text behind the '>' is type by me, and the response is from the chip, exept for '>help', this is generated by the terminal program. Please note that the terminal program does not send full commands, but short versions of them. The tiny861 is simply not large enough to do text processing.
Bus started
>help
FemtoOS Shell by R. Vlaming
general commands:
help : generate this text
id : report the FemtoOS system ID
ticks : report the system tickcounter in ticks
uptime : report the time past since the last reboot
reboot : reboot (not reset!) the system
list : show OS and task process variables
suspend (nr) : stops the given task (nr) from being run
resume (nr) : task (nr) is rescheduled for execution again
kill (nr) : terminate task (nr)
recreate (nr) : complete recreation of task (nr)
priority (nr) (pr) : give task (nr) new priority (pr) (0..7)
dump (t) (s) (l) : dump (l) bytes of the (t) ram/flash/eeprom, starting at (s); s,l: hex/dec
store (nr) (cont) : store ascii content (cont) under filenumber (nr)
recall (nr) : recall the content of filenumber (nr)
test : may have any effect, including a full crash
democommands:
ledstate {(led)|all} {off|on|flash|freeze|follow} : led new state
ledcycle {(led)|all} (ontime) (offtime) : dutycycle, blocks of 32ms.
ledsave (nr) : save the current ledstate and cycles in file (nr) (0..3)
ledload (nr) : load the current ledstate and cycles from file (nr) (0..3)
examples:
kill 0 : immideately terminates task 0.
priority 4 2 : sets the priority of task 4 to level 2.
dump ram 0x200 100 : dump 100 bytes starting from address 0x200.
ledstate 2 flash : make ledtask 2 (third led) flash
ledstate 3 follow : make ledtask 3 follow the interrupts on pin PB6
ledcycle 2 1 10 : make ledtask 2 cycle 32 ms on and 320 ms off.
ledstate all off : switch all leds off.
>list
task------ file system------ time------------- stack----
first curr -mode -burn tsk/# ---os -idle --isr -os --isr
far 1 - free 0 8809 56285 43 25 0
identifier-- status----------------------------- admin------------------ watermarks----
-nr ----name state -lock sched dress -wdog -file prio -time -nest -slots stack register
0 T4 Bus go free delay ready sleep - 3 123 0 0 0 -----0 24 xxxx____
1 Shell go free run done dead - 3 0 0 0 0 -----1 38 xxxxxxxx
2 LED 0 go free delay ready dead - 4 48 0 0 0 ------ 21 xxxx____
3 LED 1 go share delay done dead - 2 32 0 0 0 ------ 21 xxxx____
4 LED 2 go share delay done dead - 2 32 0 0 0 ------ 21 xxxx____
5 LED 3 go share delay done dead - 2 32 0 0 0 ------ 21 xxxx____
6 LED 4 go share delay done dead - 2 34 0 0 0 ------ 21 xxxx____
7 LED 5 go share delay done dead - 2 32 0 0 0 ------ 21 xxxx____
8 LED 6 go share delay done dead - 2 32 0 0 0 ------ 21 xxxx____
9 LED 7 go share delay done dead - 2 35 0 0 0 ------ 21 xxxx____
>id
id: FemtoOS 0.91
>suspend 2
sys: ok
>kill 6
sys: ok
>list
task------ file system------ time------------- stack----
first curr -mode -burn tsk/# ---os -idle --isr -os --isr
near 1 - free 0 8767 56317 38 25 0
identifier-- status----------------------------- admin------------------ watermarks----
-nr ----name state -lock sched dress -wdog -file prio -time -nest -slots stack register
0 T4 Bus go free delay ready sleep - 3 183 0 0 0 -----0 24 xxxx____
1 Shell go free run done dead - 3 36 0 0 0 -----1 57 xxxxxxxx
2 LED 0 susp --- run --- dead - 4 0 0 0 0 ------ 21 xxxx____
3 LED 1 go share delay done dead - 2 26 0 0 0 ------ 21 xxxx____
4 LED 2 go share delay done dead - 2 32 0 0 0 ------ 21 xxxx____
5 LED 3 go share delay done dead - 2 32 0 0 0 ------ 21 xxxx____
6 LED 4 term --- --- --- dead - 0 10 0 0 0 ------ 21 xxxx____
7 LED 5 go share delay done dead - 2 32 0 0 0 ------ 21 xxxx____
8 LED 6 go share delay done dead - 2 32 0 0 0 ------ 21 xxxx____
9 LED 7 go share delay done dead - 2 32 0 0 0 ------ 21 xxxx____
>resume 2
sys: ok
>list
task------ file system------ time------------- stack----
first curr -mode -burn tsk/# ---os -idle --isr -os --isr
near 1 - free 0 8749 56331 40 25 0
identifier-- status----------------------------- admin------------------ watermarks----
-nr ----name state -lock sched dress -wdog -file prio -time -nest -slots stack register
0 T4 Bus go free delay ready sleep - 3 173 0 0 0 -----0 24 xxxx____
1 Shell go free run done dead - 3 32 0 0 0 -----1 57 xxxxxxxx
2 LED 0 go free delay ready dead - 4 25 0 0 0 ------ 21 xxxx____
3 LED 1 go share delay done dead - 2 28 0 0 0 ------ 21 xxxx____
4 LED 2 go share delay done dead - 2 30 0 0 0 ------ 21 xxxx____
5 LED 3 go share delay done dead - 2 32 0 0 0 ------ 21 xxxx____
6 LED 4 term --- --- --- dead - 0 0 0 0 0 ------ 21 xxxx____
7 LED 5 go share delay done dead - 2 32 0 0 0 ------ 21 xxxx____
8 LED 6 go share delay done dead - 2 32 0 0 0 ------ 21 xxxx____
9 LED 7 go share delay done dead - 2 32 0 0 0 ------ 21 xxxx____
First group of three lines are about the OS itself, second group of lines about the tasks that are running. If a field has "--" it means that particular field is not appropriate to the task.
task:
first: (near|far)
near: indicates that a task is scheduled within 256 ticks
far: there are no tasks in the comming 256 ticks
curr: number of the task currently running
file system:
mode: (read|write|pend)
read: eeprom is in reading mode
write: eeprom is in writing
pend: currently reading, waiting for write state, no new reads allowed
burn: (block|free)
block: eeprom writing is still in progress
free eeprom may be read or written
tsk/#: which task is writing or the number of tasks simulteanously reading
time:
os: the number of subticks spend in the os
idle: the number of subticks spend in the idle mode
isr: the number of subticks spend in an isr (must cooperate)
stack:
os: the number of bytes of the os stack in use
isr: the number of bytes of the isr stack in use
identifier:
nr: number of the task (always starts with 0)
name: dynamic task name (not static one) if present
status:
state: (term|susp|sleep|go)
term: task is terminated, context is deleted
susp: task is suspended, task will no be scheduled for execution
sleep: task is sleeping, if all tasks are sleeping chip goes power down until interrupt
go: task will be scheduled for execution
lock: (sync|free|file|share)
sync: task is blocking on synchronizer,
file: task is blocking on filesystem,
share: cooperative task in shared mode, waiting for its turn
free: task is able to run
sched: (delay|run)
delay: task is delayed or if blocked waiting for timeout
run: task is running
dress: (ready|done|read|write)
ready: task is waiting to be scheduled in the round robbin
done: task was already scheduled in this round robbin
read: task is waiting for a read from eeprom
write: task is waiting for a writing to eeprom
wdog: (dead|sleep|wake|bark)
dead: the watchdog is not being used
sleep: the watchdog is put to sleep, task seems running fine
wake: the watchdog is monitoring this task, it may crash
bark: the watch caugth a crashed task
file: (read|write|ERROR)
read: task is currently reading from eeprom
write: task is currently writing to eeprom
ERROR: internal state of file system, should not occur
admin:
prio: the priority of the task 0..7,
time: number of subticks the task has spend
nest: levels of nesting per critical section (global interrupts , tick interrupts, context switches)
slots: numbers of slots that are in use
watermarks:
stack: maximal number of bytes used from the stack
register: registergroups used by the stack
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Just one more remark, all values given under 'time' can be added to get the total (does not have to be 65536, but is usually close), and it is guaranteed that the measurements are done in the same time frame, so they are comparable. In this case:
os: 8749 13.35%
idle: 56331 85.95%
isr: 40 0.06%
T4 Bus: 173 0.26%
Shell: 32 0.05%
LED 0: 25 0.04%
LED 1: 28 0.04%
LED 2: 30 0.05%
LED 3: 32 0.05%
LED 4: 0 0.00%
LED 5: 32 0.05%
LED 6: 32 0.05%
LED 7: 32 0.05%
============= ======
Total: 65536 100%
I have put the load percentages by hand. Please note that mere doing such statistics also takes cycles in OS space. Of course these are always snapshots of some time ago.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thank you for your response. major source of confusion for me was API documentation from your site (and comments from femtoos_core.h) whish is not the same as in femtoos_core.c.
Character count for genLogOS and genLogTask are not correct in API. Correct values are form femtoos_core.c.
Tomorrow I will have some screenshots of mine to show off. I hope.
Best regards
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Character count for genLogOS and genLogTask are not correct in API. Correct values are form femtoos_core.c.
That may be possible, i will have a look into that. This is probably because this function changes whenever there is a change in the OS. Thanks for the hint.
Tomorrow I will have some screenshots of mine to show off.
:-) I am very curious.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
As promised on Balansero blog you can find first screenshot of shell running on ATmega328p, communicating to PC over UART. Output of few list functions is shown and I need some help.
On Sourceforge there is a complete project if you have some time to check it.
Here is what I need:
1. shell file is shell/shell.c. If you could check functions printLogOs and printLogTask and see if I got it all right. Basically this is rewrite of functions in shell trace code you provided. I believe it is full of bugs. I got all the output: for some I know it is OK for some not.
2. Most suspicious to me are nest and slots columns.
3. Registers: I have UART task defined as follows:
but shell reports all registers are in use. I am using Eclipse and avr-gcc under Windows and I can not find file/output that is produced during compilation with use of registers, stack… Help? May be this is correct register count? Or something to do with OS configuration?
3. From time to time I get unusually big load of Shell task (as you can see on screenshot, last output) that do not add up to 65536 and I do not know if this is OS or just my printfu function
Any suggestions would be helpful, configuration option…
At this point this is not something to brag about. At this moment this is how to say "proof of concept" and hopefully will grow. Here is what I plan:
1. Realise all functions, except maybe blink examples.
2. Make new command parser.
3. Make print functions hardware independent so one can use UART, telnet…
4 …
It takes one by one painful step forward.
So any help will be appreciated. And of course if anyone who knows to program in C, unlike me, would takeover, step in or whatever…
Thanks
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
It is just special to see others use my work and go beyond that. You have actually made the shell work over the standard UART. Of course i will have a look into you code. But i must be realistic too. I want to get the port to xmega done some day, and my spare time is very limited. You know, work, kids, house etc, so it will probably only be a quick look.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
One first thing. I see in the screenshots on task 3 (Shell) is running but the OS is in the 'far' state. I don't think this is possible, since the task is actually running. However, the code that sorts this out, and prints the state seems valid:
/* [StatusOs(1)] * Definitions for the uiOsStatus byte. The whole state of the Femto OS is kept in one byte. * 8 bit structure: ccnstttt * cc: context state of the OS: This indicates in which state the OS is at the moment. * n: presence of a near wake: one or more tasks have to waked with 256 ticks. * s: share bit. If set we have shared task running. * tttt: number of the current task: Number of the task that is currently running. */
So for
n: presence of a near wake: one or more tasks have to waked with 256 ticks
I tried following: changed taskDelayFromNow(5000); in Debug task to taskDelayFromNow(50); and I get OS to be in near state. This is in accordance with your explanation. But if you say there is something wrong…
Thanks for the tip on expanding macros.
Progress so far:
- Implemented new command parser
- implemented all functions except blinking leds
- added possibility to assign value to 10 variables from command line. This could be useful for controlling robot, for example. Also it prints out value for this variable.
- shell will be easily expandable
All functions work as expected, except suspend. I can not suspend my tasks for some reason.
On registers: I checked your code and it seems that shell only prints out registers configuration from config_application.h. The same is for me. My expectation was that OS could follow and give "realtime" usage of registers, like it gives for stack, and that this information could be used for minimizing register usage for tasks. Could you explain this?
In next few days I will prepare screen-cast of shell performing and will put online updated code.
Best regards
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Well I'm only human … What you have tried seems good. Is the shell without any delays? Of with very long delays only? In that case it could be correct after all. I run my shell with a shore delay, so the state is always near. I assumed you did something alike, but of course never assume anything … ;-)
All functions work as expected, except suspend. I cannot suspend my tasks for some reason.
Suspending a task can be a dangerous action in a embedded system. On older versions of my OS it was possible to suspend a task, "just like that". However, since you do not know when the suspend hits the task, it may well hold system resources when the suspend comes, thereby blocking the whole system. Thus, i changed the design somewhat. In its present form a genSuspend() call must be paired with a taskSuspend(defSuspendCheck) call in the task to be suspended. Now, at least you know where the suspend will take place. Without that no suspend takes place. Shared tasks should be suspended in their shared state. Of course a task can immediately suspend itself with taskSuspend(defSuspendNow). For more info see: http://www.femtoos.org/code_api.html#0113 http://www.femtoos.org/code_api.html#0120
If you where already fully known with this setup, please post what is going on. The feature is relatively new, maybe there is a design flaw.
On registers: I checked your code and it seems that shell only prints out registers configuration from config_application.h. The same is for me. My expectation was that OS could follow and give "realtime" usage of registers, like it gives for stack, and that this information could be used for minimizing register usage for tasks. Could you explain this?
Well that should not be the case. It should print out the live use of registers, at least that is what my shell does. In the config you must specify which registers are to be checked. At the moment, i cannot verify this. Btw, "you checked my code", fine of course, but can you pinpoint on which line you came to this conclusion? The code handling this is rather complex, since assembly is involved too. But maybe you are correct.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
As you can see shell task has no delays, but is blocked on UART input buffer, waiting for next character. As delays from keyboard are significant it is always more then 256 ticks (I think :-) ) so I get far all the time.
Point taken on suspending tasks. I will try the setup. Of course, if nothing else helps, read the manual.
Btw, "you checked my code"
Of course I could not find this in your code. What I wanted to say is I checked config file of your example to find out how to configure my project and I could not figure out what I do wrong except this:
So I assumed this is the problem: you already optimized register use, and now you are just printing this. Please do not assume I can, at this point, find any bugs just by reading your code. This is out of my abilities.
As reporting register use is one functionality I want to have correctly, I ask you to check my config file to see if there is something obvious wrong there.
Just to point out another problem: Screen shot shows that Debug task is using all registers and this can not be true since:
If I compile project without Shell task I get following main.defs file with used registers properly listed.
If I compile with Shell task I get main.defs without register use. I saw that there could be issues with jump names but I do not understand a thing.
So bottom line: could you help me resolve this issue with registers, or point out in a good direction.
Best regards
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Indeed, i check the code Saturday on my mobile phone, so i missed this. The near state just indicates that a delayed task is to be released within 255 ticks or less. Non delayed tasks are not involved, blocks are not involved either, unless you use the timeout feature.
Of course I could not find this in your code … Please do not assume I can, at this point, find any bugs just by reading your code.
Ah, ok. But from what you make i see you are a quick learner. So that day will not be far. Now, lets hope that by that time there are none to be discovered … :-)
Now about the register optimization. This is 'advanced stuff'. First, make sure you store and check all registers on the context:
If correct, you now should see which registers are being used by the tasks. Let the application run sufficient time. If you see for example that a particular task is not using the registers r0-r15, you can eliminate them from the configuration, and reduce the stack size by 15 bytes.
#define RegisterUse_yourtask r16_upto_r31
...//specify all other tasks as well.
If you only(!) change that, a recompilation should not change any code or register use. If you started adding more code, or just change a minor thing about your code, the optimization must be done from the start. This is really dangerous, since registers being use but not saved on the context may lead to very strange behavior. So, if you have the ram to spare, do not do register optimization, just save the every register on the context.
If I compile project without Shell task I get following main.defs file with used registers properly listed. If I compile with Shell task I get main.defs without register use. I saw that there could be issues with jump names but I do not understand a thing.
My compile script also tries to analyze the assemble and displays which registers are used. It is not 100% foolproof however, so introspection of the code may still be needed. The problem lies in the disassemble of the code (produced by the compiler) Sometimes, jumps are not given the correct name, but some address, which is not related to the call. I don't know why this is the case. But for me it is not possible any more to analyze the jump structure. If you post the .lss files for both cases i can show you where the problem lies.
As reporting register use is one functionality I want to have correctly, I ask you to check my config file to see if there is something obvious wrong there.
This seems ok to me.
Just to point out another problem: Screen shot shows that Debug task is using all registers and this can not be true since:
Indeed, i agree. I remember there was a time i was playing around with this part of the code. Maybe there is a bug. Such a bug is not so easily spotted. Please give me some time to sort this out.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
- new command parser is based on Ragel state machine compiler. Works as expected, will skip all spaces, tabs, parses commands and all arguments correctly. Any wrong command will be skipped silently
-All commands are implemented
-there are variables from v0 to v9 (16bit) that can be assigned value and checked for current value
-shell occupies some 15k of flash but can be scaled down by using only just a subset of commands needed.
Things to be done:
- optimize code to use less flash and ram. This can be done in few ways: using different compile switch for Ragel (-T1 instead of -G1, that is used now). This requires some manual tweaking of generated code. Can save some 1.5 kbyte. Also there are 1.8 kbyte strings in flash that could be moved to eeprom ( it is unused in my application, so why not using it?) This has to be checked (I need to be sure of file system use in OS.) Try to use less RAM: at this point compiling reports 1173 byte bss, but after reducing stack from 200 to needed size I can save 650 byte. Not bad having shell running ??
-change characters are feed in and out of shell. This can save time and space
- implement telnet communication to shell
- implement some more file system commands
Known bugs and differences from original shell:
- register reporting is not correct (or it is?)
-uptime counter is 32 bit long not 40
- reboot is not working for me (may be because I use Arduino with bootloader? Do not know, but it sends my MCU to endless reboot loop)
-list command: time reporting for Shell task is not always correct. I do not know why.
- dump command made just one stupid listing for all time used. You can see it in listing I will provide.
-storing in same file multiple times in the raw is causing me problems. I have to learn file system interface.
This is it.
I prepared Flash screen cast but Youtube will not take it. I have to find another way. Instead I will give screenshot and terminal output listing of all commands used.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I needed shell to understand what is system load in ticks, flash, ram. It was fun coding it and I will continue until I am satisfied. If anyone has something to add or take please do.
For me it already payed off.
Again I am surprised what this OS can do for me. Excellent job Ruud.
I am one step closer from coding communication to coding robot automation.
Consider this application pre alpha. I will post it today on Sourceforge.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Again I am surprised what this OS can do for me. Excellent job Ruud.
Thanks for the compliments. You did a pretty good job yourself. I know there are more people out there working with my OS, but most do not post their work on the net. It is good you did.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hello Ruud,
Would it be possible to have some quality screenshots of shell project, specially LIST function output. I am half way on coding shell inside MCU and have problems with formatting and output so this would be helpful. Please send latest version. Also some more explanation on presented data would be great (more than in Youtube clip).
Best regards
Tomorrow i will look if i still have a chip programmed with the shell lying around. If so, i will make some screen shots and explain what can be seen there. At the moment i am porting the code to xmega and it is not working right now. Of course, best would be if you have a tiny861, flash the shell and connect it to the parallel port of some old pc. It is really not a lot of work, and you can play with the shell yourself. The shell demonstrates preemptive and cooperative tasks running simultaneously, as well as the file system, a os load monitor and much more.
Your other post also gave me something to think about, I will react later.
Thank you,
Almost all is clear about the Shell project, but I need a good explanation on LIST command, fields that are on the screen etc
Also I will have some more questions along the way.
I do not have MCU required, and believe me it is difficult to get some here. So your help would be of great value, as always.
Best regards
Below please find a copy from the input/output of the shell program. It says id is 0.91, but i am pretty sure it is a near 0.92 version. Below that there is an explanation of the fields. Hopefully this provides some information. Text behind the '>' is type by me, and the response is from the chip, exept for '>help', this is generated by the terminal program. Please note that the terminal program does not send full commands, but short versions of them. The tiny861 is simply not large enough to do text processing.
Bus started >help FemtoOS Shell by R. Vlaming general commands: help : generate this text id : report the FemtoOS system ID ticks : report the system tickcounter in ticks uptime : report the time past since the last reboot reboot : reboot (not reset!) the system list : show OS and task process variables suspend (nr) : stops the given task (nr) from being run resume (nr) : task (nr) is rescheduled for execution again kill (nr) : terminate task (nr) recreate (nr) : complete recreation of task (nr) priority (nr) (pr) : give task (nr) new priority (pr) (0..7) dump (t) (s) (l) : dump (l) bytes of the (t) ram/flash/eeprom, starting at (s); s,l: hex/dec store (nr) (cont) : store ascii content (cont) under filenumber (nr) recall (nr) : recall the content of filenumber (nr) test : may have any effect, including a full crash democommands: ledstate {(led)|all} {off|on|flash|freeze|follow} : led new state ledcycle {(led)|all} (ontime) (offtime) : dutycycle, blocks of 32ms. ledsave (nr) : save the current ledstate and cycles in file (nr) (0..3) ledload (nr) : load the current ledstate and cycles from file (nr) (0..3) examples: kill 0 : immideately terminates task 0. priority 4 2 : sets the priority of task 4 to level 2. dump ram 0x200 100 : dump 100 bytes starting from address 0x200. ledstate 2 flash : make ledtask 2 (third led) flash ledstate 3 follow : make ledtask 3 follow the interrupts on pin PB6 ledcycle 2 1 10 : make ledtask 2 cycle 32 ms on and 320 ms off. ledstate all off : switch all leds off. >list task------ file system------ time------------- stack---- first curr -mode -burn tsk/# ---os -idle --isr -os --isr far 1 - free 0 8809 56285 43 25 0 identifier-- status----------------------------- admin------------------ watermarks---- -nr ----name state -lock sched dress -wdog -file prio -time -nest -slots stack register 0 T4 Bus go free delay ready sleep - 3 123 0 0 0 -----0 24 xxxx____ 1 Shell go free run done dead - 3 0 0 0 0 -----1 38 xxxxxxxx 2 LED 0 go free delay ready dead - 4 48 0 0 0 ------ 21 xxxx____ 3 LED 1 go share delay done dead - 2 32 0 0 0 ------ 21 xxxx____ 4 LED 2 go share delay done dead - 2 32 0 0 0 ------ 21 xxxx____ 5 LED 3 go share delay done dead - 2 32 0 0 0 ------ 21 xxxx____ 6 LED 4 go share delay done dead - 2 34 0 0 0 ------ 21 xxxx____ 7 LED 5 go share delay done dead - 2 32 0 0 0 ------ 21 xxxx____ 8 LED 6 go share delay done dead - 2 32 0 0 0 ------ 21 xxxx____ 9 LED 7 go share delay done dead - 2 35 0 0 0 ------ 21 xxxx____ >id id: FemtoOS 0.91 >suspend 2 sys: ok >kill 6 sys: ok >list task------ file system------ time------------- stack---- first curr -mode -burn tsk/# ---os -idle --isr -os --isr near 1 - free 0 8767 56317 38 25 0 identifier-- status----------------------------- admin------------------ watermarks---- -nr ----name state -lock sched dress -wdog -file prio -time -nest -slots stack register 0 T4 Bus go free delay ready sleep - 3 183 0 0 0 -----0 24 xxxx____ 1 Shell go free run done dead - 3 36 0 0 0 -----1 57 xxxxxxxx 2 LED 0 susp --- run --- dead - 4 0 0 0 0 ------ 21 xxxx____ 3 LED 1 go share delay done dead - 2 26 0 0 0 ------ 21 xxxx____ 4 LED 2 go share delay done dead - 2 32 0 0 0 ------ 21 xxxx____ 5 LED 3 go share delay done dead - 2 32 0 0 0 ------ 21 xxxx____ 6 LED 4 term --- --- --- dead - 0 10 0 0 0 ------ 21 xxxx____ 7 LED 5 go share delay done dead - 2 32 0 0 0 ------ 21 xxxx____ 8 LED 6 go share delay done dead - 2 32 0 0 0 ------ 21 xxxx____ 9 LED 7 go share delay done dead - 2 32 0 0 0 ------ 21 xxxx____ >resume 2 sys: ok >list task------ file system------ time------------- stack---- first curr -mode -burn tsk/# ---os -idle --isr -os --isr near 1 - free 0 8749 56331 40 25 0 identifier-- status----------------------------- admin------------------ watermarks---- -nr ----name state -lock sched dress -wdog -file prio -time -nest -slots stack register 0 T4 Bus go free delay ready sleep - 3 173 0 0 0 -----0 24 xxxx____ 1 Shell go free run done dead - 3 32 0 0 0 -----1 57 xxxxxxxx 2 LED 0 go free delay ready dead - 4 25 0 0 0 ------ 21 xxxx____ 3 LED 1 go share delay done dead - 2 28 0 0 0 ------ 21 xxxx____ 4 LED 2 go share delay done dead - 2 30 0 0 0 ------ 21 xxxx____ 5 LED 3 go share delay done dead - 2 32 0 0 0 ------ 21 xxxx____ 6 LED 4 term --- --- --- dead - 0 0 0 0 0 ------ 21 xxxx____ 7 LED 5 go share delay done dead - 2 32 0 0 0 ------ 21 xxxx____ 8 LED 6 go share delay done dead - 2 32 0 0 0 ------ 21 xxxx____ 9 LED 7 go share delay done dead - 2 32 0 0 0 ------ 21 xxxx____First group of three lines are about the OS itself, second group of lines about the tasks that are running. If a field has "--" it means that particular field is not appropriate to the task.
Just one more remark, all values given under 'time' can be added to get the total (does not have to be 65536, but is usually close), and it is guaranteed that the measurements are done in the same time frame, so they are comparable. In this case:
I have put the load percentages by hand. Please note that mere doing such statistics also takes cycles in OS space. Of course these are always snapshots of some time ago.
Thank you for your response. major source of confusion for me was API documentation from your site (and comments from femtoos_core.h) whish is not the same as in femtoos_core.c.
Character count for genLogOS and genLogTask are not correct in API. Correct values are form femtoos_core.c.
Tomorrow I will have some screenshots of mine to show off. I hope.
Best regards
That may be possible, i will have a look into that. This is probably because this function changes whenever there is a change in the OS. Thanks for the hint.
:-) I am very curious.
Hello Ruud,
Thanks for your help, but I need some more.
As promised on Balansero blog you can find first screenshot of shell running on ATmega328p, communicating to PC over UART. Output of few list functions is shown and I need some help.
On Sourceforge there is a complete project if you have some time to check it.
Here is what I need:
1. shell file is shell/shell.c. If you could check functions printLogOs and printLogTask and see if I got it all right. Basically this is rewrite of functions in shell trace code you provided. I believe it is full of bugs. I got all the output: for some I know it is OK for some not.
2. Most suspicious to me are nest and slots columns.
3. Registers: I have UART task defined as follows:
#if (preTaskDefined(UART)) void appLoop_UART(void) { while (true) { //UART_putc(UART_getc()); taskDelayFromNow(5000); } } #endifbut shell reports all registers are in use. I am using Eclipse and avr-gcc under Windows and I can not find file/output that is produced during compilation with use of registers, stack… Help? May be this is correct register count? Or something to do with OS configuration?
3. From time to time I get unusually big load of Shell task (as you can see on screenshot, last output) that do not add up to 65536 and I do not know if this is OS or just my printfu function
Any suggestions would be helpful, configuration option…
At this point this is not something to brag about. At this moment this is how to say "proof of concept" and hopefully will grow. Here is what I plan:
1. Realise all functions, except maybe blink examples.
2. Make new command parser.
3. Make print functions hardware independent so one can use UART, telnet…
4 …
It takes one by one painful step forward.
So any help will be appreciated. And of course if anyone who knows to program in C, unlike me, would takeover, step in or whatever…
Thanks
Just a quick first reaction: SO VERY COOL!
It is just special to see others use my work and go beyond that. You have actually made the shell work over the standard UART. Of course i will have a look into you code. But i must be realistic too. I want to get the port to xmega done some day, and my spare time is very limited. You know, work, kids, house etc, so it will probably only be a quick look.
And that is fine with me just check those two functions for obvious mistakes and registers. Just a good look.
This was for anybody other out there
One first thing. I see in the screenshots on task 3 (Shell) is running but the OS is in the 'far' state. I don't think this is possible, since the task is actually running. However, the code that sorts this out, and prints the state seems valid:
/* Determine nearwake state*/ if ((queuRead & defNearWakeStateGetMask) == defNearWakeStatePresent) rprintfProgStrM(" near"); else rprintfProgStrM(" far");thus, maybe the queuRead is not the correct byte. But the code that prepares the queue seems valid too (with removed comments):
static void WriteQueuPipe(Tchar c) { genQueuWriteOnName(ShellQueu,c); } ..... taskQueuWriteRequestOnName(ShellQueu,12); genQueuClearOnName(ShellQueu); genLogOs(WriteQueuPipe); taskQueuReleaseOnName(ShellQueu); ..... taskQueuReadRequestOnName(ShellQueu,12); if ( genQueuReadOnName(ShellQueu) != defResponseLogOs ) return; /* read byte: 1*/ queuRead = genQueuReadOnName(ShellQueu); /* read byte: 2*/now, since rprintfProgStrM are macro's it would be better to use compound statements { }, since you never know if these expand to two statements:
if ((queuRead & defNearWakeStateGetMask) == defNearWakeStatePresent) { rprintfProgStrM(" near"); } else { rprintfProgStrM(" far"); }but in this situation this is not the case. So something seems wrong, but i don't know what yet. Maybe some other task is reading the queue?
Hello
So for
I tried following: changed taskDelayFromNow(5000); in Debug task to taskDelayFromNow(50); and I get OS to be in near state. This is in accordance with your explanation. But if you say there is something wrong…
Thanks for the tip on expanding macros.
Progress so far:
- Implemented new command parser
- implemented all functions except blinking leds
- added possibility to assign value to 10 variables from command line. This could be useful for controlling robot, for example. Also it prints out value for this variable.
- shell will be easily expandable
All functions work as expected, except suspend. I can not suspend my tasks for some reason.
On registers: I checked your code and it seems that shell only prints out registers configuration from config_application.h. The same is for me. My expectation was that OS could follow and give "realtime" usage of registers, like it gives for stack, and that this information could be used for minimizing register usage for tasks. Could you explain this?
In next few days I will prepare screen-cast of shell performing and will put online updated code.
Best regards
Well I'm only human … What you have tried seems good. Is the shell without any delays? Of with very long delays only? In that case it could be correct after all. I run my shell with a shore delay, so the state is always near. I assumed you did something alike, but of course never assume anything … ;-)
Suspending a task can be a dangerous action in a embedded system. On older versions of my OS it was possible to suspend a task, "just like that". However, since you do not know when the suspend hits the task, it may well hold system resources when the suspend comes, thereby blocking the whole system. Thus, i changed the design somewhat. In its present form a genSuspend() call must be paired with a taskSuspend(defSuspendCheck) call in the task to be suspended. Now, at least you know where the suspend will take place. Without that no suspend takes place. Shared tasks should be suspended in their shared state. Of course a task can immediately suspend itself with taskSuspend(defSuspendNow). For more info see:
http://www.femtoos.org/code_api.html#0113
http://www.femtoos.org/code_api.html#0120
If you where already fully known with this setup, please post what is going on. The feature is relatively new, maybe there is a design flaw.
Well that should not be the case. It should print out the live use of registers, at least that is what my shell does. In the config you must specify which registers are to be checked. At the moment, i cannot verify this. Btw, "you checked my code", fine of course, but can you pinpoint on which line you came to this conclusion? The code handling this is rather complex, since assembly is involved too. But maybe you are correct.
if (preTaskDefined(Shell))
void appLoop_Shell(void) { initShell(); while (true) { cmdlineInputFunc(UART_getc()); } } #endifAs you can see shell task has no delays, but is blocked on UART input buffer, waiting for next character. As delays from keyboard are significant it is always more then 256 ticks (I think :-) ) so I get far all the time.
Point taken on suspending tasks. I will try the setup. Of course, if nothing else helps, read the manual.
Of course I could not find this in your code. What I wanted to say is I checked config file of your example to find out how to configure my project and I could not figure out what I do wrong except this:
So I assumed this is the problem: you already optimized register use, and now you are just printing this. Please do not assume I can, at this point, find any bugs just by reading your code. This is out of my abilities.
As reporting register use is one functionality I want to have correctly, I ask you to check my config file to see if there is something obvious wrong there.
Just to point out another problem: Screen shot shows that Debug task is using all registers and this can not be true since:
#if (preTaskDefined(Debug)) void appLoop_Debug(void) { while (true) { taskDelayFromNow(5000); } } #endifIf I compile project without Shell task I get following main.defs file with used registers properly listed.
If I compile with Shell task I get main.defs without register use. I saw that there could be issues with jump names but I do not understand a thing.
So bottom line: could you help me resolve this issue with registers, or point out in a good direction.
Best regards
Indeed, i check the code Saturday on my mobile phone, so i missed this. The near state just indicates that a delayed task is to be released within 255 ticks or less. Non delayed tasks are not involved, blocks are not involved either, unless you use the timeout feature.
Ah, ok. But from what you make i see you are a quick learner. So that day will not be far. Now, lets hope that by that time there are none to be discovered … :-)
Now about the register optimization. This is 'advanced stuff'. First, make sure you store and check all registers on the context:
If correct, you now should see which registers are being used by the tasks. Let the application run sufficient time. If you see for example that a particular task is not using the registers r0-r15, you can eliminate them from the configuration, and reduce the stack size by 15 bytes.
If you only(!) change that, a recompilation should not change any code or register use. If you started adding more code, or just change a minor thing about your code, the optimization must be done from the start. This is really dangerous, since registers being use but not saved on the context may lead to very strange behavior. So, if you have the ram to spare, do not do register optimization, just save the every register on the context.
My compile script also tries to analyze the assemble and displays which registers are used. It is not 100% foolproof however, so introspection of the code may still be needed. The problem lies in the disassemble of the code (produced by the compiler) Sometimes, jumps are not given the correct name, but some address, which is not related to the call. I don't know why this is the case. But for me it is not possible any more to analyze the jump structure. If you post the .lss files for both cases i can show you where the problem lies.
This seems ok to me.
Indeed, i agree. I remember there was a time i was playing around with this part of the code. Maybe there is a bug. Such a bug is not so easily spotted. Please give me some time to sort this out.
Ok. There will be few posts on latest development on Shell over UART:
Registers:
With following Config I get this output:
Config1
Output11
Config2
Output2
Config3
Output3
As promised I have been busy:
Application works as expected:
- new command parser is based on Ragel state machine compiler. Works as expected, will skip all spaces, tabs, parses commands and all arguments correctly. Any wrong command will be skipped silently
-All commands are implemented
-there are variables from v0 to v9 (16bit) that can be assigned value and checked for current value
-shell occupies some 15k of flash but can be scaled down by using only just a subset of commands needed.
Things to be done:
- optimize code to use less flash and ram. This can be done in few ways: using different compile switch for Ragel (-T1 instead of -G1, that is used now). This requires some manual tweaking of generated code. Can save some 1.5 kbyte. Also there are 1.8 kbyte strings in flash that could be moved to eeprom ( it is unused in my application, so why not using it?) This has to be checked (I need to be sure of file system use in OS.) Try to use less RAM: at this point compiling reports 1173 byte bss, but after reducing stack from 200 to needed size I can save 650 byte. Not bad having shell running ??
-change characters are feed in and out of shell. This can save time and space
- implement telnet communication to shell
- implement some more file system commands
Known bugs and differences from original shell:
- register reporting is not correct (or it is?)
-uptime counter is 32 bit long not 40
- reboot is not working for me (may be because I use Arduino with bootloader? Do not know, but it sends my MCU to endless reboot loop)
-list command: time reporting for Shell task is not always correct. I do not know why.
- dump command made just one stupid listing for all time used. You can see it in listing I will provide.
-storing in same file multiple times in the raw is causing me problems. I have to learn file system interface.
This is it.
I prepared Flash screen cast but Youtube will not take it. I have to find another way. Instead I will give screenshot and terminal output listing of all commands used.
Terminal Log of FemtoOS shell commands:
This forum platform is $%/&(/(")(/=)(=(Q/(/#Q
I needed shell to understand what is system load in ticks, flash, ram. It was fun coding it and I will continue until I am satisfied. If anyone has something to add or take please do.
For me it already payed off.
Again I am surprised what this OS can do for me. Excellent job Ruud.
I am one step closer from coding communication to coding robot automation.
Consider this application pre alpha. I will post it today on Sourceforge.
Indeed.
Thanks for the compliments. You did a pretty good job yourself. I know there are more people out there working with my OS, but most do not post their work on the net. It is good you did.