Hello Erich, I revisited "Redirecting emit from within a task in AmForth", as I still like the idea of having a self contained task that can perform its own io, but without having to write my own version of pictured numeric output.
The bug was in my understanding, rather than anything else. It turned out that redirecting emit was not the problem. The xt for the new emit was correctly being stored in the task's user area (user+14) and was being called correctly by emit within the task. What I had not appreciated at the time was that (user+12) which holds the task's base value is zero by default. This meant that after . or u. , emit was never called as the mcu had crashed in the pictured numeric output routines (in #s I think, though it is # that fetches base) which use base. Ironically, to establish this I did end up re-writing versions of the pictured numeric output routines in Forth so that they wrote to part of an extended task user area - so providing task specific pad and numeric picture buffers that I could be (more) sure were not being modified elsewhere. When this still crashed the mcu, I re-read http://amforth.sourceforge.net/TG/Architecture.html?highlight=user http://amforth.sourceforge.net/TG/recipes/Multitasking.html and I realised that I was responsible for providing a newly created task with more than just an xt for emit. task-init only does so much. Once 10 was written to the task's base location (user+12), my versions of . u. wrote correctly to the task's local buffers and the redirected emit was called by type (from my numeric picture routines). AmForth's . and u. also wrote correctly to the (shared) numeric picture buffer below the (shared) pad. Tristan On 09Oct19 15:44, Tristan Williams wrote: > 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 _______________________________________________ Amforth-devel mailing list for http://amforth.sf.net/ Amforth-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/amforth-devel
