Hello Erich, Thank you for looking at my code.
I will stick with not redirecting EMIT within a task (though I do still like the idea of it). Thanks and best wishes, Tristan > On 7 Oct 2019, at 20:34, Erich Wälde <ew.fo...@nassur.net> wrote: > > Hello Tristan, > > I just spent some time on your problem. > > 1. I can reproduce this problem with your code! Your code looks > innocent to my eyes, with the possible exeption of changing " > emit? " as well. But leaving that out does not change the > problem. > > > 2. stack size > > I replaced >> 1 +noop . -noop > with >> N @ drop > and it did not work. This code comes to life when increasing > the memory sizes for the task >> $40 $40 0 task: task1 > I remember being bitten by this as well a long time ago. > > > 3. Nonetheless the problem persists. > > > So. > > I think you found a bug. Allthough I do not understand why emit > or dot triggers a reset ... at least at this time. > > On the other hand I believe this stuff has worked before, so > going back to Version 4.6 or something such could be worthwhile. > > > One other thing: I strongly discorage using "emit" or its kin > from within a task. I have done this before. Had a few tasks, > each one reading some sensor and printing the value (on serial > or to display, doesn't matter) while at the same time asking the > foreground task for data. I don't print anything from inside a > task anymore, because these different task do share the buffer, > where number output is formatted. PAD? I forgot its name. I got > errors in formatted numeric output --- which of course looks > like calculation errors. > > > Cheers, > Erich > > > > > > > Tristan Williams writes: > >> Hello Erich, >> >> Thank you for your email. >> >> The example I posted was the simplest I could think of that would >> illustrate the what I was trying to achieve - the redirection of EMIT >> within a task. What I actually have is various sensors attached to an >> AVR. Rather than poll each of them in a loop I decided (as an >> experiment) to put each of them in their own task. Each task would >> then respond to (or poll) its sensor and also output the result. This >> I could do by writing directly (not via EMIT) to their output medium >> (display, leds, sound) for each sensor. I think doing this by >> redirecting EMIT within the task would be a better solution - but not >> one I achieved. >> >> Kind regards, >> Tristan >> >> >>> On 19Sep19 20:32, Erich Wälde wrote: >>> >>> Hello Tristan, >>> >>> I need to look into my stuff, but that won't happen before next >>> week. If I understand you correctly, you want to "shut down the >>> output of the task, no matter what." I think, I have done this >>> somewhere ... but I do not remember the details. You need to >>> place " ' drop " in the correct field in the task control block. >>> Something like this ... I'll check this out next week. :-) >>> >>> >>> Cheers, >>> Erich >>> >>> >>> Tristan Williams writes: >>> >>>> Hello, >>>> >>>> I have been trying to redirect emit from within a task in a forth >>>> multitasking setup. Redirection works perfectly for me in a word run >>>> from the interpreter but when I try to do it from a task I fail to get >>>> it to work. Below is a stripped down example which aims to redirect >>>> emit to drop - so nothing should be output. The result of go! is >>>> either a mcu reset or a hang. Without the redirection line, the task >>>> runs and I can use the interpreter. Any ideas as to where I am going >>>> wrong very gratefully received. >>>> >>>> Regards, >>>> Tristan >>>> >>>> \ include ms.frt \ with pause >>>> \ include avr-values.frt >>>> \ include multitask.frt >>>> >>>> ' emit defer@ Evalue emit.amforth >>>> ' emit? defer@ Evalue emit?amforth >>>> >>>> : +noop ['] drop is emit ['] true is emit? ; >>>> : -noop emit.amforth is emit emit?amforth is emit? ; >>>> >>>> $20 $20 0 task: task1 >>>> >>>> : tx1.ex >>>> >>>> task1 tib>tcb activate >>>> >>>> begin >>>> +buzz 1000 ms >>>> \ uncomment one of three lines below >>>> \ 1 +noop . -noop \ works in the interpreter >>>> 1 +noop . -noop \ resets the mcu in task >>>> \ +noop -noop \ does not reset mcu in task >>>> -buzz 1000 ms >>>> again >>>> ; >>>> >>>> : go! >>>> >>>> buzz.init >>>> >>>> task1 task-init >>>> >>>> tx1.ex >>>> >>>> onlytask >>>> task1 tib>tcb alsotask >>>> multi >>>> >>>> ; >>>> >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> Amforth-devel mailing list for http://amforth.sf.net/ >>>> Amforth-devel@lists.sourceforge.net >>>> https://lists.sourceforge.net/lists/listinfo/amforth-devel >>> >>> >>> -- >>> May the Forth be with you ... >>> >>> >>> _______________________________________________ >>> Amforth-devel mailing list for http://amforth.sf.net/ >>> Amforth-devel@lists.sourceforge.net >>> https://lists.sourceforge.net/lists/listinfo/amforth-devel >> >> >> _______________________________________________ >> Amforth-devel mailing list for http://amforth.sf.net/ >> Amforth-devel@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/amforth-devel > > > -- > May the Forth be with you ... > > > _______________________________________________ > Amforth-devel mailing list for http://amforth.sf.net/ > Amforth-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/amforth-devel _______________________________________________ Amforth-devel mailing list for http://amforth.sf.net/ Amforth-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/amforth-devel
