From: Erich W. <ew....@on...> - 2008-01-09 19:51:21
|
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. |