Hello amforth'ers,
I'm trying to get the multitasker coming with amforth doing
something useful, but I have hit a problem.
I create one task in addition to "the input handling". It
increments a counter, and occasionally a message should be
written to the (serial) terminal. I dont care if it would
interfere with my typing. Consider this code:
#include ../../lib/multitask.frt
decimal
: message
cr ." c2_null_msg"
;
variable c0 0 c0 !
: task0 ( tid -- )
activate
begin
1 c0 +!
c0 @ 8 /
0= if message then
pause
again
;
onlytask
20 20 task ( -- tid0 )
dup task-sleep ( -- tid0 )
dup alsotask ( -- tid0 )
task0 ( -- )
I upload the program
user@box$ amforth-upload.py -t /dev/ttyS1 taskdemo.frt
and connect to the controller (<ret> is the return key):
user@box$ minicom -o atmega
...
<ret>
ok
> tlist<ret>
96 running rp0= 2143 TOR= 43784 sp0= 2063 TOS= 96
sp= 2057
297 running rp0= 361 TOR= 14597 sp0= 341 TOS= 357
sp= 339
Multitasker is not running ok
I can call message:
> message
c2_null_msg ok
and it does exactly, what it should. However, calling the
contents of message "manually", fails to show on the terminal:
> ." c2_null_from_prompt"
ok
Note that the string did not show up. Is this a bug or a
feature? This looks like a feature to me.
Now I start the tasker. I expect the count in c0 to increase,
and occasionally the message to show up.
> c0 @ u.
50964 ok
> multi
ok
> c0 @ u.
53896 ok
The counter does increase indeed, however, the message does show
up only partially.
> >
> c2_
-------^ stops here! no " ok", no newline, no "> "
It looks like the string is not handled correctly, since calling
message manually does work:
> message
c2_null_msg ok
Is this a bug or a feature? Looks like a bug to me anyway. Am I
doing something wrong? Is IO on the serial terminal somehow
colliding with the tasker? Interestingly, the output from tlist
is processed ok. Also interestingly, leaving "activate" and
"pause" out of "task0" and running it "in the foreground" (no
tasks involved), does work as well. Any insight would be
appreciated.
FWIW: I'm running this on a atmega32 with a 11.05920 MHz crystal
clock.
Cheers,
Erich W.
|
