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
