amforth-devel — Development discussion and user support

Re: [Amforth] defer.frt

[Mark R. <cab...@gm...>]

Thank you Tristan for the welcome and all of it.

Yeah, I had done that. I guess pointing out that was missing was just an
easy way to start. What I had actually done was to move everything into my
app directory to try and get things to import. The changes you mention do
work. Where I am getting stuck is in the flash-block.frt file at line 33.
After making some changes (well adding #requires) I'm also seeing it in
i2c-eeprom-block.frt at line 76 which is the same issue.

S|   76|   ['] i2c.ee.load-buffer is load-buffer

which is about the same type of line in flash-block. That makes me think it
is something that is not included yet.

It's late here. Tomorrow is another day. Thanks again for the welcome.
Really :)

On Sat, Jun 27, 2020 at 12:41 AM Tristan Williams <ho...@tj...> wrote:

> Hello Mark,
>
> Welcome to the list.
>
> > Should I be concentrating more on following along with the I2C EEPROM
> > recipe in the cookbook instead?
>
> It depends upon what you want to achieve - but perhaps. At the end of
> cookbook recipe[1] you should have an I2C eeprom connected to the I2C bus
> and be able to write/read a byte/word to/from an address on the
> eeprom. If you put multiple eeproms on the bus make sure they have
> different I2C addresses. i2c.detect is very useful as an interactive
> check to see if things are as you expect.
>
> > The problem is that it seems there is no defer.frt anymore
>
> You are correct.
>
> i2c-eeprom-block.frt requires blocks.frt which
> in turn requires defer.frt - which does not exist.
>
> I think the word Rdefer used in blocks.frt is now in this file
>
> amforth-6.8/common/lib/forth2012/core-ext/defers.frt
>
> I have not tested this, but changing
>
> #require defer.frt
>
> to
>
> #require defers.frt
>
> in
>
> amforth-6.8/common/lib/forth2012/blocks/blocks.frt
>
> may help.
>
> Best wishes,
> Tristan
>
> [1]
> http://amforth.sourceforge.net/TG/recipes/I2C-EEPROM.html?highlight=eeprom
>
> On 26Jun20 22:04, Mark Roth wrote:
> > Hello,
> > I have been working (and reading extensively) with AmForth this past week
> > or so as I learn Forth from Starting Forth. I wanted to try to play with
> > some eeproms on an I2C bus and from reading here I drifted toward the
> > i2c-eeprom-block.frt
> > post. The problem is that it seems there is no defer.frt anymore? Should
> I
> > be concentrating more on following along with the I2C EEPROM recipe in
> the
> > cookbook instead? I tried to upload the requirements with the
> > amforth-shell.py script and that gave me the error message of:
> > E=file defer.frt not found in search path
> > I am running 6.8 on an atmega1284p if that  makes a difference.
> >
> > It was a little tricky getting started since I was following the linux
> > instructions, but once I read through the windows stuff (and just the
> docs
> > in general) I was able to get my chip set up correctly. It really is a
> > pretty cool system that reminds me of my old computers back in the olden
> > days. :)
> >
> > Mostly I've been using the e4thcom console, but I couldn't manage to get
> it
> > to search for the sources correctly. The python script seems to work a
> > treat for that.
> >
> > Also, I'm sorry I just missed out on the creator of all this. It's always
> > nice to see a project live on though. That's really why they are open
> imho.
> >
> > All the best,
> > Mark
> >
> > _______________________________________________
> > Amforth-devel mailing list for http://amforth.sf.net/
> > Amf...@li...
> > https://lists.sourceforge.net/lists/listinfo/amforth-devel
> >
>
>
> _______________________________________________
> Amforth-devel mailing list for http://amforth.sf.net/
> Amf...@li...
> https://lists.sourceforge.net/lists/listinfo/amforth-devel
>

Re: [Amforth] defer.frt

[Tristan W. <ho...@tj...>]

Hello Mark,

Welcome to the list.

> Should I be concentrating more on following along with the I2C EEPROM
> recipe in the cookbook instead?

It depends upon what you want to achieve - but perhaps. At the end of
cookbook recipe[1] you should have an I2C eeprom connected to the I2C bus
and be able to write/read a byte/word to/from an address on the
eeprom. If you put multiple eeproms on the bus make sure they have
different I2C addresses. i2c.detect is very useful as an interactive
check to see if things are as you expect.

> The problem is that it seems there is no defer.frt anymore

You are correct. 

i2c-eeprom-block.frt requires blocks.frt which
in turn requires defer.frt - which does not exist.

I think the word Rdefer used in blocks.frt is now in this file

amforth-6.8/common/lib/forth2012/core-ext/defers.frt

I have not tested this, but changing

#require defer.frt

to

#require defers.frt

in

amforth-6.8/common/lib/forth2012/blocks/blocks.frt

may help.

Best wishes,
Tristan

[1] http://amforth.sourceforge.net/TG/recipes/I2C-EEPROM.html?highlight=eeprom

On 26Jun20 22:04, Mark Roth wrote:
> Hello,
> I have been working (and reading extensively) with AmForth this past week
> or so as I learn Forth from Starting Forth. I wanted to try to play with
> some eeproms on an I2C bus and from reading here I drifted toward the
> i2c-eeprom-block.frt
> post. The problem is that it seems there is no defer.frt anymore? Should I
> be concentrating more on following along with the I2C EEPROM recipe in the
> cookbook instead? I tried to upload the requirements with the
> amforth-shell.py script and that gave me the error message of:
> E=file defer.frt not found in search path
> I am running 6.8 on an atmega1284p if that  makes a difference.
> 
> It was a little tricky getting started since I was following the linux
> instructions, but once I read through the windows stuff (and just the docs
> in general) I was able to get my chip set up correctly. It really is a
> pretty cool system that reminds me of my old computers back in the olden
> days. :)
> 
> Mostly I've been using the e4thcom console, but I couldn't manage to get it
> to search for the sources correctly. The python script seems to work a
> treat for that.
> 
> Also, I'm sorry I just missed out on the creator of all this. It's always
> nice to see a project live on though. That's really why they are open imho.
> 
> All the best,
> Mark
> 
> _______________________________________________
> Amforth-devel mailing list for http://amforth.sf.net/
> Amf...@li...
> https://lists.sourceforge.net/lists/listinfo/amforth-devel
> 

[Amforth] defer.frt

[Mark R. <cab...@gm...>]

Hello,
I have been working (and reading extensively) with AmForth this past week
or so as I learn Forth from Starting Forth. I wanted to try to play with
some eeproms on an I2C bus and from reading here I drifted toward the
i2c-eeprom-block.frt
post. The problem is that it seems there is no defer.frt anymore? Should I
be concentrating more on following along with the I2C EEPROM recipe in the
cookbook instead? I tried to upload the requirements with the
amforth-shell.py script and that gave me the error message of:
E=file defer.frt not found in search path
I am running 6.8 on an atmega1284p if that  makes a difference.

It was a little tricky getting started since I was following the linux
instructions, but once I read through the windows stuff (and just the docs
in general) I was able to get my chip set up correctly. It really is a
pretty cool system that reminds me of my old computers back in the olden
days. :)

Mostly I've been using the e4thcom console, but I couldn't manage to get it
to search for the sources correctly. The python script seems to work a
treat for that.

Also, I'm sorry I just missed out on the creator of all this. It's always
nice to see a project live on though. That's really why they are open imho.

All the best,
Mark

Re: [Amforth] documentation error

[Tristan W. <ho...@tj...>]

Hello Brian,

Welcome to the list. Seems like you got a bargain. I was surprised to
see I could still buy a new AVR butterfly in the UK, but it would cost
me quite a bit more than 8 USD!

> How would I submit this as a patch for the documentation?

Emailing this mailing list is the way I have done it in the past.

Best wishes,
Tristan


On 16Jun20 20:46, Brian wrote:
> begin
>        ASSR c@
>        1 2 lshift    \ TCN2UB
>        1 0 lshift or \ TCR2UB
>        1 1 lshift or \ OCR2UB
>        and
>    until
> 
> I am new to the forth world and i'm loving it. I was on the newark ( an
> electronics parts distributor ) a few months ago and they were selling
> avrbutterflys for 8 US dollars. So I bought a few and while thinking about
> what to do with them I found forth and fell into the rabbit hole. That being
> said, in the cookbook section/popular boards/avr butterfly section it gives
> an rtc example code. The problem is that the above loop should wait until
> those three registers are 0. If you leave a 0 on the stack you end up in an
> infinite loop, and yet surprisingly the +32kHz function that loop comes from
> works. Well if you dump the ASSR register value ( using .s ) you see that
> the first look at the register that the TCRTUB flag is set so the value on
> the stack is one and the loop ends. This is not what the exit condition you
> want for this loop. Those last three bits in ASSR should be 0 according to
> the data sheet for the atmega169 (and I also for the atmega328) before
> moving on. A simple fix is:
> 
>   begin
>        ASSR c@
>        1 2 lshift    \ TCN2UB
>        1 0 lshift or \ TCR2UB
>        1 1 lshift or \ OCR2UB
>        and
>        0=  \ add this line
>    until
> 
> How would I submit this as a patch for the documentation?
> Thanks,
> Brian-in-ohio
> 
> ps used this loop to see the values on the stack
>  begin
>     ASSR c@
>     1 2 lshift    \ TCN2UB
>     1 0 lshift or \ TCR2UB
>     1 1 lshift or \ OCR2UB
>     bin .s cr hex
>     and
>     0=
>   until
> 
> 
> 
> _______________________________________________
> Amforth-devel mailing list for http://amforth.sf.net/
> Amf...@li...
> https://lists.sourceforge.net/lists/listinfo/amforth-devel

[Amforth] documentation error

[Brian <bkn...@gm...>]

begin
        ASSR c@
        1 2 lshift    \ TCN2UB
        1 0 lshift or \ TCR2UB
        1 1 lshift or \ OCR2UB
        and
    until

I am new to the forth world and i'm loving it. I was on the newark ( an 
electronics parts distributor ) a few months ago and they were selling 
avrbutterflys for 8 US dollars. So I bought a few and while thinking 
about what to do with them I found forth and fell into the rabbit hole. 
That being said, in the cookbook section/popular boards/avr butterfly 
section it gives an rtc example code. The problem is that the above loop 
should wait until those three registers are 0. If you leave a 0 on the 
stack you end up in an infinite loop, and yet surprisingly the +32kHz 
function that loop comes from works. Well if you dump the ASSR register 
value ( using .s ) you see that the first look at the register that the 
TCRTUB flag is set so the value on the stack is one and the loop ends. 
This is not what the exit condition you want for this loop. Those last 
three bits in ASSR should be 0 according to the data sheet for the 
atmega169 (and I also for the atmega328) before moving on. A simple fix is:

   begin
        ASSR c@
        1 2 lshift    \ TCN2UB
        1 0 lshift or \ TCR2UB
        1 1 lshift or \ OCR2UB
        and
        0=  \ add this line
    until

How would I submit this as a patch for the documentation?
Thanks,
Brian-in-ohio

ps used this loop to see the values on the stack
  begin
     ASSR c@
     1 2 lshift    \ TCN2UB
     1 0 lshift or \ TCR2UB
     1 1 lshift or \ OCR2UB
     bin .s cr hex
     and
     0=
   until

Re: [Amforth] Stack pointer

[Martin N. <amf...@mg...>]

On Mon, 8 Jun 2020 11:58:15 +0100
tur bine <mai...@gm...> wrote:

> Hi just wished to expand my knowledge base with forth, the stack
> pointer increases during runtime and does not decrease unless using
> certain commands if etc, can somebody explain what happens when sp
> and thus the stack gets full please
> Thank you

Your program will crash!

AmForth, certainly on the AVR, makes no run-time checks on stack bounds.
In the firing line are: the return stack (RP), the Terminal Input Buffer
(TIB), any variables ALLOTed, User Variables (UP), etc.

The Forth approach is that it's up to you to test your words as you
write them for offending behaviour. The Forth development environment
also makes this dead easy. For example to test '+' type:

3 2 + . .

The first dot prints the answer of 5. The second dot THROWs error 4 as
the stack has under-flowed. Thus you have proven '+' uses two items
from the stack and leaves just one.

'?stack' checks the Computation Stack only and is part of 'interpret'
which is taking what you typed and executing it a word at a time.

-- 
Regards,

Martin Nicholas.

E-mail: rep...@mg... (Address will be valid throughout 2020).

[Amforth] Stack pointer

[tur b. <mai...@gm...>]

Hi just wished to expand my knowledge base with forth, the stack pointer
increases during runtime and does not decrease unless using certain
commands if etc, can somebody explain what happens when sp and thus the
stack gets full please
Thank you

Re: [Amforth] A very, very minor suggestion for amforth-shell.py

[Tristan W. <ho...@tj...>]

Hello John,

> Can you provide a unified diff of your proposed changes?

Yes. A good idea. Output of diff -u below, with amforth-shell.py taken from a fresh amforth-6.8.tar.gz


--- amforth-shell.py	2020-05-10 08:06:14.000000000 +0100
+++ new-shell.py	2020-05-10 08:08:46.000000000 +0100
@@ -750,6 +750,7 @@
             raise AMForthException("file " + filename + " not found in search path")
           if len(self._filedirs[filename])!=1:
             # oops, too many files or no one at all found?
+            self.progress_callback("Error", None,  "Wrong # of file "+ filename+" found in search path") # add this line above the one below 
             raise AMForthException("Wrong # of file occurances: " + filename + " ("+str(len(self._filedirs[filename]))+")\n\t"+"\n\t".join(self._filedirs[filename]))
           self.progress_callback("Information", None,  "using "+ filename+" from"+ self._filedirs[filename][0])
           fpath = os.path.join(self._filedirs[filename][0], filename)


Best wishes,
Tristan

On 08May20 15:44, John Verne wrote:
> Can you provide a unified diff of your proposed changes?
> 
> On Fri, 8 May 2020 at 15:42, Tristan Williams <ho...@tj...> wrote:
> >
> > A very, very, minor suggestion for amforth-shell.py in the next
> > release.
> >
> > If amforth-shell.py finds multiple matches for a filename whilst
> > executing a #include directive then it exits silently. It really has
> > no choice but to exit (which one to load?). Adding a
> > self.progress_callback line (as per the other filename related tests)
> > gives a hint that things are going awry.
> >
> > I think this would work
> >
> > self.progress_callback("Error", None,  "Wrong # of file "+ filename+" found in search path") # add this line above the one below
> > raise AMForthException("Wrong # of file occurances: " + filename + " ("+str(len(self._filedirs[filename]))+")\n\t"+"\n\t".join(self._filedirs[filename]))
> >
> > An easy way to demonstrate this is to defeat amforth-shell.py inbuilt
> > intelligence and knowledge of mcu type by
> >
> > export AMFORTH_LIB=/path-to/amforth-6.8
> >
> > and create a file with the line
> >
> > #include marker.frt
> >
> > and send it to the mcu with amforth-shell.py
> >
> > In the standard distribution there are two marker.frt files
> >
> > ../amforth-6.8/avr8/lib/forth2012/core-ext/marker.frt
> > ../amforth-6.8/msp430/lib/forth-2012/core-ext/marker.frt
> >
> > so amforth-shell.py will silently exit after the #include marker.frt
> > line.
> >
> > Best wishes,
> > Tristan
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > _______________________________________________
> > Amforth-devel mailing list for http://amforth.sf.net/
> > Amf...@li...
> > https://lists.sourceforge.net/lists/listinfo/amforth-devel
> 
> 
> 
> -- 
> 
> 
> John Verne
> about.me/jverne
> 
> 
> _______________________________________________
> Amforth-devel mailing list for http://amforth.sf.net/
> Amf...@li...
> https://lists.sourceforge.net/lists/listinfo/amforth-devel
> 

Re: [Amforth] A very, very minor suggestion for amforth-shell.py

[John V. <joh...@gm...>]

Can you provide a unified diff of your proposed changes?

On Fri, 8 May 2020 at 15:42, Tristan Williams <ho...@tj...> wrote:
>
> A very, very, minor suggestion for amforth-shell.py in the next
> release.
>
> If amforth-shell.py finds multiple matches for a filename whilst
> executing a #include directive then it exits silently. It really has
> no choice but to exit (which one to load?). Adding a
> self.progress_callback line (as per the other filename related tests)
> gives a hint that things are going awry.
>
> I think this would work
>
> self.progress_callback("Error", None,  "Wrong # of file "+ filename+" found in search path") # add this line above the one below
> raise AMForthException("Wrong # of file occurances: " + filename + " ("+str(len(self._filedirs[filename]))+")\n\t"+"\n\t".join(self._filedirs[filename]))
>
> An easy way to demonstrate this is to defeat amforth-shell.py inbuilt
> intelligence and knowledge of mcu type by
>
> export AMFORTH_LIB=/path-to/amforth-6.8
>
> and create a file with the line
>
> #include marker.frt
>
> and send it to the mcu with amforth-shell.py
>
> In the standard distribution there are two marker.frt files
>
> ../amforth-6.8/avr8/lib/forth2012/core-ext/marker.frt
> ../amforth-6.8/msp430/lib/forth-2012/core-ext/marker.frt
>
> so amforth-shell.py will silently exit after the #include marker.frt
> line.
>
> Best wishes,
> Tristan
>
>
>
>
>
>
>
>
>
>
>
>
> _______________________________________________
> Amforth-devel mailing list for http://amforth.sf.net/
> Amf...@li...
> https://lists.sourceforge.net/lists/listinfo/amforth-devel



-- 


John Verne
about.me/jverne

[Amforth] A very, very minor suggestion for amforth-shell.py

[Tristan W. <ho...@tj...>]

A very, very, minor suggestion for amforth-shell.py in the next
release.

If amforth-shell.py finds multiple matches for a filename whilst
executing a #include directive then it exits silently. It really has
no choice but to exit (which one to load?). Adding a
self.progress_callback line (as per the other filename related tests)
gives a hint that things are going awry. 

I think this would work

self.progress_callback("Error", None,  "Wrong # of file "+ filename+" found in search path") # add this line above the one below 
raise AMForthException("Wrong # of file occurances: " + filename + " ("+str(len(self._filedirs[filename]))+")\n\t"+"\n\t".join(self._filedirs[filename]))

An easy way to demonstrate this is to defeat amforth-shell.py inbuilt
intelligence and knowledge of mcu type by 

export AMFORTH_LIB=/path-to/amforth-6.8

and create a file with the line

#include marker.frt

and send it to the mcu with amforth-shell.py

In the standard distribution there are two marker.frt files

../amforth-6.8/avr8/lib/forth2012/core-ext/marker.frt
../amforth-6.8/msp430/lib/forth-2012/core-ext/marker.frt

so amforth-shell.py will silently exit after the #include marker.frt
line.

Best wishes,
Tristan

 

Re: [Amforth] Multitasking/emit/hold

[Tristan W. <ho...@tj...>]

Hello Erich,

My original 2019 problem of "why can't I redirect emit to output to my
LCD from a task" is perhaps most simply addressed by an addition to the
documentation. Once (I) it is understood that the user area a task has
access to needs to be explicitly populated, it all works as expected.
Your solutions would cover such a documentation addition I think.

> There is an area in EEPROM holding all these values.
> Much to my surprise these values are stored at some odd location. Look
> for "EE_INITUSER:" in main.lst (the assembler list file). It will
> reveal this location:
> > |                  ; default user area
> > |                  EE_INITUSER:
> > | 000074 00 00         .dw 0  ; USER_STATE
> > | 000076 00 00         .dw 0  ; USER_FOLLOWER
> > | 000078 ff 10         .dw rstackstart  ; USER_RP
> In this case $74. So we can pick things from $74 plus some offset.
>
> If I want to do this in run-demo, then a Forth constant holding that
> offset would be nice (change to AmForth asm).

I think such a Forth constant would be a good addition, and gives the
option of ee>ram in a custom task-init.

> Making the HOLD area (and possibly TerminalInputBuffer) task local,
> can be solved, no doubt. But I'm not convinced that this is the way to
> go unless different tasks operate on separate output destinations.

Making the various buffers (HLD, PAD, etc.) task local appeals to me,
but (I think) it would mean changes rather than additions to AmForth
and the "one resource" issue would always remain.
       
> Now back to your original problem. I rephrase: "Wouldn't it be
> nice if I have one or more background tasks running along and
> printing their output as they go --- independantly of each
> other"?

In mitigation, each of my outputing tasks did have its own output device :)

> My experiments reminded me very clearly, that more than one task
> emitting output on the same destination can only be a bad idea.

Agreed.

Best wishes,
Tristan

On 06May20 20:33, Erich Wälde wrote:
> 
> Hello Tristan,
> 
> back to mulitasking on AmForth.
> 
> I spend an afternoon to create a background task, which does some
> output by itself (see code below). There is nothing really new in
> this. If I equip the background tasks with base and pointers to emit
> (and emit?), it does work, including pictured output of numbers. 
> 
> I gained a few insights along the way:
> 
> 1.
> the background task has any form I want. So noone can stop me from
> writing 
> > | : run-demo
> > |   \ some init stuff
> > |   #10 base !
> > |   \ loop
> > |   begin
> > |     \ repeated work goes here
> > |   again
> > | ;
> This "init" space can be used to set missing bits without any need to
> change init-task.
> 
> 2.
> however: the real XT found in emit is hidden behind a defer.
> > | ' emit defer@
> will not work in run-demo. 
> 
> First solution: store this value in a constant before defining
> run-demo.
> 
> > | ' emit defer@ constant emit.orig
> > | 
> > | : run-demo
> > |   emit.orig is emit
> > |   ...
> > | ;
> 
> This works for the io functions emit emit? key key?. I expect this to
> work for the prompts .ok .ready .error .input as well.
> 
> But storing these values separately seems kind of odd.
> 
> Second solution: There is an area in EEPROM holding all these values.
> Much to my surprise these values are stored at some odd location. Look
> for "EE_INITUSER:" in main.lst (the assembler list file). It will
> reveal this location:
> > |                  ; default user area
> > |                  EE_INITUSER:
> > | 000074 00 00         .dw 0  ; USER_STATE
> > | 000076 00 00         .dw 0  ; USER_FOLLOWER
> > | 000078 ff 10         .dw rstackstart  ; USER_RP
> In this case $74. So we can pick things from $74 plus some offset.
> 
> If I want to do this in run-demo, then a Forth constant holding that
> offset would be nice (change to AmForth asm).
> 
> Third solution (not tested) instead of 
> > | : task-init ( tib -- )
> > |   dup tib>tcb over tib>size  0 fill \ clear RAM for tcb and stacks
> > |   ...
> we could write something like
> > | : task-init ( tib -- )
> > |   dup tib>tcb over tib>size  \ -- r-addr length
> > |   ee_user rot rot            \ -- e-addr r-addr length
> > |   \ possibly 2/ to correct for cells
> > |   ee>ram
> > |   ...
> instead. So we get all the missing stuff delivered. This needs the
> same Forth constant as in 2.
> 
> I expect this to break on targets other than avr8 --- at least for my
> current lack of understanding, how/where this information is stored on
> the other platforms.
> 
> 
> Still reading? No, I have not even tried to go beyond what we did know
> already. 
> 
> 
> However.
> 
> I wrote:
> > Now back to your original problem. I rephrase: "Wouldn't it be
> > nice if I have one or more background tasks running along and
> > printing their output as they go --- independantly of each
> > other"?
> 
> My experiments reminded me very clearly, that more than one task
> emitting output on the same destination can only be a bad idea. In the
> end you get garbled output. Unless of course, you lock access to this
> one resource using semaphores. Thats one more thing to work out.
> 
> "this one resource" starts pointing to a better understanding. This is
> the classical "several clients/tasks compete for a single resource"
> problem. This is what an operating system kernel must organize all the
> time. Any access to (any) resource must go through one instance.
> 
> So we enter the world of locks and queues and privileges and
> priorities and what not.
> 
> Use case:
> 
> Task-1 acquires the "output on uart0"-lock.
> { Task-1 prepares the output
>   Task-1 emits the output } possibly more than once
> Task-1 releases the lock.
> 
> This also includes the fact, that emitting e.g. on uart, takes long.
> You copy one byte to the output register, and then basically you call
> pause. A task switch occurs at this point. Probably several task
> switches later, the next byte can be emitted. For some applications
> this might work. For other maybe not. 
> 
> Making the HOLD area (and possibly TerminalInputBuffer) task local,
> can be solved, no doubt. But I'm not convinced that this is the way to
> go unless different tasks operate on separate output destinations.
> 
> Having cooperative multitasking basically offers that one task holds
> the cpu and calls pause only after it is done. But you need to check
> carefully, that pause isn't called in unexpected places.
> 
> Having one task to emit output, and all the other report to this one?
> Enter the world of queues, dynamic memory allocation and locks. :-/
> 
> 
> Well well. I hate to say that, but this seems like a slippery slope.
> And no, I'm neither a good system programmer nor living in kernel
> space. So my understanding of this sort of problems is very limited.
> 
> I want to see if semaphores can help in some cases.
> 
> 
> One more thing: in my rs485-bus project, I hit a similar problem, of
> course: several sensor stations sending their values whenever their
> local clock says "it's time", to the one resource called rs485 bus. No
> thanks. My solution thus far is: The bus master is soliciting data
> from each station, when the bus master's clock says "it's time". And I
> have spend some effort to silence the sensor stations, whenever they
> start, and even if they receive a command they do not understand. This
> stringent system runs since 2011, with very few problems (I get
> a hickup once in a while, but I have not change code in a long time).
> 
> 
> So much for today.
> 
> Cheers,
> Erich
> 
> 
> --- code example ---
> \ 2020-05-06
> \ try to make multitasker play tristans game.
> 
> \ --- loaded by " make marker "
> \ include lib/builds.frt
> \ include lib/forth2012/core/erase.frt
> \ include lib/dot-base.frt
> \ include lib-avr8/imove.frt
> \ include lib-avr8/bitnames.frt
> \ include lib-avr8/forth2012/core-ext/marker.frt
> \ include lib-avr8/forth2012/core/environment-q.frt
> \ include lib-avr8/dot-res.frt
> \ include lib-avr8/forth2012/core/avr-values.frt
> \ include lib/forth2012/core/is.frt
> \ include lib/forth2012/tools/dumper.frt
> \ include lib-avr8/hardware/interrupts.frt             ???
> \ include atmega644p.fs
> \ include first.fs
> 
> marker --start--
> 
> \ --- leds are on PorbB 0,1,2,3 ---
> PORTB 2 portpin: led.0
> PORTB 3 portpin: led.1  
> PORTB 4 portpin: led.2  
> PORTA 7 portpin: led.3
> 
> 
> \ --- famous includes ---
> : ms        ( n -- )     0 ?do pause 1ms loop ;
> : u0.r      ( u n -- )   >r 0 <# r> 0 ?do # loop #> type ;
> 
> include leds.fs
> 
> ' emit defer@ constant emit.orig
> 
> $74 constant ee_user \ EE_INITUSER, looked up in mail.lst
> #14 constant ee_emit \ offset into user area
> #16 constant ee_emitq
> 
> \ --- include multitasker ---
> include lib/multitask.frt
> variable N
> 
> : run-demo
>   \ --- task 2 ---
>   #7 base ! \ funny base to identify output.
>   \ emit.orig is emit
>   ee_user ee_emit  + @e is emit
>   ee_user ee_emitq + @e is emit?
>   [char] t emit cr
>   led.3 on
>   begin
>     1 N +!
>     led.2 on
>     #250 ms
>     led.2 off
>     [char] . emit space N @ . cr
>     #250 ms
>   again
> ;
> $40 $40 0 task: task_demo
> \ create task, allot tcb + stack space
> : start-demo
>   task_demo tib>tcb activate
>   \ words after this line are run in new task
>   run-demo
> ;
> : starttasker
>   task_demo task-init
>   \ create TCB in RAM
>   start-demo
>   \ activate tasks job
>   onlytask
> \ task_demo tcb>tid alsotask \ error
>   task_demo tib>tcb alsotask
>   multi
> ;
> 
> 
> 
> : init
>   42 N !
>   +leds leds-intro
>   cr [char] i emit space N ?
>   cr
> ;
> : run-turnkey
>   \ make cmd loop task-1
>   \ start task-2
>   \ activate multitaskingMultitasking
>   applturnkey
>   init
>   starttasker
> ;
> 
> 
> 
> 
> -- 
> May the Forth be with you ...
> 
> 
> _______________________________________________
> Amforth-devel mailing list for http://amforth.sf.net/
> Amf...@li...
> https://lists.sourceforge.net/lists/listinfo/amforth-devel
> 

Re: [Amforth] Multitasking/emit/hold

[Erich W. <ew....@na...>]

Hello Tristan,

back to mulitasking on AmForth.

I spend an afternoon to create a background task, which does some
output by itself (see code below). There is nothing really new in
this. If I equip the background tasks with base and pointers to emit
(and emit?), it does work, including pictured output of numbers. 

I gained a few insights along the way:

1.
the background task has any form I want. So noone can stop me from
writing 
> | : run-demo
> |   \ some init stuff
> |   #10 base !
> |   \ loop
> |   begin
> |     \ repeated work goes here
> |   again
> | ;
This "init" space can be used to set missing bits without any need to
change init-task.

2.
however: the real XT found in emit is hidden behind a defer.
> | ' emit defer@
will not work in run-demo. 

First solution: store this value in a constant before defining
run-demo.

> | ' emit defer@ constant emit.orig
> | 
> | : run-demo
> |   emit.orig is emit
> |   ...
> | ;

This works for the io functions emit emit? key key?. I expect this to
work for the prompts .ok .ready .error .input as well.

But storing these values separately seems kind of odd.

Second solution: There is an area in EEPROM holding all these values.
Much to my surprise these values are stored at some odd location. Look
for "EE_INITUSER:" in main.lst (the assembler list file). It will
reveal this location:
> |                  ; default user area
> |                  EE_INITUSER:
> | 000074 00 00         .dw 0  ; USER_STATE
> | 000076 00 00         .dw 0  ; USER_FOLLOWER
> | 000078 ff 10         .dw rstackstart  ; USER_RP
In this case $74. So we can pick things from $74 plus some offset.

If I want to do this in run-demo, then a Forth constant holding that
offset would be nice (change to AmForth asm).

Third solution (not tested) instead of 
> | : task-init ( tib -- )
> |   dup tib>tcb over tib>size  0 fill \ clear RAM for tcb and stacks
> |   ...
we could write something like
> | : task-init ( tib -- )
> |   dup tib>tcb over tib>size  \ -- r-addr length
> |   ee_user rot rot            \ -- e-addr r-addr length
> |   \ possibly 2/ to correct for cells
> |   ee>ram
> |   ...
instead. So we get all the missing stuff delivered. This needs the
same Forth constant as in 2.

I expect this to break on targets other than avr8 --- at least for my
current lack of understanding, how/where this information is stored on
the other platforms.


Still reading? No, I have not even tried to go beyond what we did know
already. 


However.

I wrote:
> Now back to your original problem. I rephrase: "Wouldn't it be
> nice if I have one or more background tasks running along and
> printing their output as they go --- independantly of each
> other"?

My experiments reminded me very clearly, that more than one task
emitting output on the same destination can only be a bad idea. In the
end you get garbled output. Unless of course, you lock access to this
one resource using semaphores. Thats one more thing to work out.

"this one resource" starts pointing to a better understanding. This is
the classical "several clients/tasks compete for a single resource"
problem. This is what an operating system kernel must organize all the
time. Any access to (any) resource must go through one instance.

So we enter the world of locks and queues and privileges and
priorities and what not.

Use case:

Task-1 acquires the "output on uart0"-lock.
{ Task-1 prepares the output
  Task-1 emits the output } possibly more than once
Task-1 releases the lock.

This also includes the fact, that emitting e.g. on uart, takes long.
You copy one byte to the output register, and then basically you call
pause. A task switch occurs at this point. Probably several task
switches later, the next byte can be emitted. For some applications
this might work. For other maybe not. 

Making the HOLD area (and possibly TerminalInputBuffer) task local,
can be solved, no doubt. But I'm not convinced that this is the way to
go unless different tasks operate on separate output destinations.

Having cooperative multitasking basically offers that one task holds
the cpu and calls pause only after it is done. But you need to check
carefully, that pause isn't called in unexpected places.

Having one task to emit output, and all the other report to this one?
Enter the world of queues, dynamic memory allocation and locks. :-/


Well well. I hate to say that, but this seems like a slippery slope.
And no, I'm neither a good system programmer nor living in kernel
space. So my understanding of this sort of problems is very limited.

I want to see if semaphores can help in some cases.


One more thing: in my rs485-bus project, I hit a similar problem, of
course: several sensor stations sending their values whenever their
local clock says "it's time", to the one resource called rs485 bus. No
thanks. My solution thus far is: The bus master is soliciting data
from each station, when the bus master's clock says "it's time". And I
have spend some effort to silence the sensor stations, whenever they
start, and even if they receive a command they do not understand. This
stringent system runs since 2011, with very few problems (I get
a hickup once in a while, but I have not change code in a long time).


So much for today.

Cheers,
Erich


--- code example ---
\ 2020-05-06
\ try to make multitasker play tristans game.

\ --- loaded by " make marker "
\ include lib/builds.frt
\ include lib/forth2012/core/erase.frt
\ include lib/dot-base.frt
\ include lib-avr8/imove.frt
\ include lib-avr8/bitnames.frt
\ include lib-avr8/forth2012/core-ext/marker.frt
\ include lib-avr8/forth2012/core/environment-q.frt
\ include lib-avr8/dot-res.frt
\ include lib-avr8/forth2012/core/avr-values.frt
\ include lib/forth2012/core/is.frt
\ include lib/forth2012/tools/dumper.frt
\ include lib-avr8/hardware/interrupts.frt             ???
\ include atmega644p.fs
\ include first.fs

marker --start--

\ --- leds are on PorbB 0,1,2,3 ---
PORTB 2 portpin: led.0
PORTB 3 portpin: led.1  
PORTB 4 portpin: led.2  
PORTA 7 portpin: led.3


\ --- famous includes ---
: ms        ( n -- )     0 ?do pause 1ms loop ;
: u0.r      ( u n -- )   >r 0 <# r> 0 ?do # loop #> type ;

include leds.fs

' emit defer@ constant emit.orig

$74 constant ee_user \ EE_INITUSER, looked up in mail.lst
#14 constant ee_emit \ offset into user area
#16 constant ee_emitq

\ --- include multitasker ---
include lib/multitask.frt
variable N

: run-demo
  \ --- task 2 ---
  #7 base ! \ funny base to identify output.
  \ emit.orig is emit
  ee_user ee_emit  + @e is emit
  ee_user ee_emitq + @e is emit?
  [char] t emit cr
  led.3 on
  begin
    1 N +!
    led.2 on
    #250 ms
    led.2 off
    [char] . emit space N @ . cr
    #250 ms
  again
;
$40 $40 0 task: task_demo
\ create task, allot tcb + stack space
: start-demo
  task_demo tib>tcb activate
  \ words after this line are run in new task
  run-demo
;
: starttasker
  task_demo task-init
  \ create TCB in RAM
  start-demo
  \ activate tasks job
  onlytask
\ task_demo tcb>tid alsotask \ error
  task_demo tib>tcb alsotask
  multi
;



: init
  42 N !
  +leds leds-intro
  cr [char] i emit space N ?
  cr
;
: run-turnkey
  \ make cmd loop task-1
  \ start task-2
  \ activate multitaskingMultitasking
  applturnkey
  init
  starttasker
;




-- 
May the Forth be with you ...

Re: [Amforth] Multitasking/emit/hold (was: Redirect EMIT from within a task)

[Erich W. <ew....@na...>]

Hello Tristan,


Tristan Williams writes:

> Hello Erich,
>
> Within task-init from multitask.frt I think a task's entire tcb/user
> area is filled with zeros and then only the values from the task's
> (flash) tib are copied across to the task's tcb/user area. A value for
> BASE is not stored within the tib. Only sp0, sp0-- and rp0 are stored
> in the task's tib.   
>
> : tib>tcb  ( tib -- tcb )                  @i ;
> : tib>rp0  ( tib -- rp0 )  i-cell+         @i ;
> : tib>sp0  ( tib -- sp0 )  i-cell+ i-cell+ @i ;
> : tib>size ( tib -- size )
>   dup tib>tcb swap tib>sp0 1+ swap -
> ;
>
> : task-init ( tib -- )
>   dup tib>tcb over tib>size  0 fill \ clear RAM for tcb and stacks
>   dup tib>sp0 over tib>tcb #6 + !       \ store sp0    in tcb[6]
>   dup tib>sp0 cell- over tib>tcb #8 + ! \ store sp0--  in tcb[8], tos
>   dup tib>rp0 over tib>tcb #4 + !       \ store rp0    in tcb[4]
>       tib>tcb task-sleep                \ store 'pass' in tcb[0]
> ;

You have clearly spend more time on this, I see! Populating base
won't be difficult, but I wonder what other candidates are
there.

>
> I believe the interpreter user area is fully populated from eeprom
> at boot time, but all other tasks rely on the programmer to fill in
> what is relevant to their tasks. I did not appreciate that included a
> value for BASE, but I do now.

That's what I had in mind.
COLD avr8/words/cold.asm does jump to PFA_WARM.
WARM common/words/warm.asm does call XT_INIT_RAM
init-ram avr8/words/init-ram.asm does the copy loop
> | XT_INIT_RAM:
> |   .dw DO_COLON
> | PFA_INI_RAM:          ; ( -- )
> |     .dw XT_DOLITERAL
> |     .dw EE_INITUSER
> |     .dw XT_UP_FETCH
> |     .dw XT_DOLITERAL
> |     .dw SYSUSERSIZE
> |     .dw XT_2SLASH
> |     .dw XT_EE2RAM
> |     .dw XT_EXIT
something like "  eeinituser up@ sysusersize 2/ ee>ram "
where " : ee>ram   0 do over @e over ! cell+ swap loop 2drop ; "
no garantees. But there is ee>ram, which could be called in
task-init, too, before storing sp0 rp0 ...


>
>> Having said that I feel inclined to add another: "Wouldn't it be
>> nice, if I could run a second commandline task (quit) on an
>> existing second serial connection (thing atmega644pa or
>> similar)"? Thus effectively creating a *Two User AmForth on one
>> AtMega644pa*? Actually I do have a use case for this. And I have
>> started to implement something in small steps[2]:
>
> Would the two users have separate dictionaries?
Good question! I haven't really thought about that.
But I had in mind to prepend a new (limited) dictionary for that
second serial connection, in order to make it deal correctly
with the incoming data (well data wrapped in forth syntax).


Thank you for your input.
Cheers,
Erich


-- 
May the Forth be with you ...

Re: [Amforth] Multitasking/emit/hold (was: Redirect EMIT from within a task)

[Tristan W. <ho...@tj...>]

Hello Erich,

Within task-init from multitask.frt I think a task's entire tcb/user
area is filled with zeros and then only the values from the task's
(flash) tib are copied across to the task's tcb/user area. A value for
BASE is not stored within the tib. Only sp0, sp0-- and rp0 are stored
in the task's tib.   

: tib>tcb  ( tib -- tcb )                  @i ;
: tib>rp0  ( tib -- rp0 )  i-cell+         @i ;
: tib>sp0  ( tib -- sp0 )  i-cell+ i-cell+ @i ;
: tib>size ( tib -- size )
  dup tib>tcb swap tib>sp0 1+ swap -
;

: task-init ( tib -- )
  dup tib>tcb over tib>size  0 fill \ clear RAM for tcb and stacks
  dup tib>sp0 over tib>tcb #6 + !       \ store sp0    in tcb[6]
  dup tib>sp0 cell- over tib>tcb #8 + ! \ store sp0--  in tcb[8], tos
  dup tib>rp0 over tib>tcb #4 + !       \ store rp0    in tcb[4]
      tib>tcb task-sleep                \ store 'pass' in tcb[0]
;

I believe the interpreter user area is fully populated from eeprom
at boot time, but all other tasks rely on the programmer to fill in
what is relevant to their tasks. I did not appreciate that included a
value for BASE, but I do now. 

> Having said that I feel inclined to add another: "Wouldn't it be
> nice, if I could run a second commandline task (quit) on an
> existing second serial connection (thing atmega644pa or
> similar)"? Thus effectively creating a *Two User AmForth on one
> AtMega644pa*? Actually I do have a use case for this. And I have
> started to implement something in small steps[2]:

Would the two users have separate dictionaries? 

kind regards,
Tristan

[Amforth] Multitasking/emit/hold (was: Redirect EMIT from within a task)

[Erich W. <ew....@na...>]

Hello Tristan,

thanks for your message.

My below answers/comments only regard AVR8. I have currently no
idea, how this is similar or different in the other 3 targets.


> 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.

It sure would be nice, if this worked without a hitch. Agreed!


> 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.

A base of value '0' is not good. However, it seems a little more
convoluted:

The USER area is filled from a snippet stored in EEPROM. The
EEPROM values are defined in "avr8/amforth-eeprom.inc". In trunk
the relevant snippet looks like this:

> | ; default user area
> | EE_INITUSER:
> |     .dw 0  ; USER_STATE
> |     .dw 0  ; USER_FOLLOWER
> |     .dw rstackstart  ; USER_RP
> |     .dw stackstart   ; USER_SP0
> |     .dw stackstart   ; USER_SP
> |     
> |     .dw 0  ; USER_HANDLER
> |     .dw 10 ; USER_BASE
> |     
> |     .dw XT_TX  ; USER_EMIT
> |     .dw XT_TXQ ; USER_EMITQ
> |     .dw XT_RX  ; USER_KEY
> |     .dw XT_RXQ ; USER_KEYQ
> |     .dw XT_SOURCETIB ; USER_SOURCE
> |     .dw 0            ; USER_G_IN
> |     .dw XT_REFILLTIB ; USER_REFILL  
> |     .dw XT_DEFAULT_PROMPTOK
> |     .dw XT_DEFAULT_PROMPTERROR
> |     .dw XT_DEFAULT_PROMPTREADY
> |     .dw XT_DEFAULT_PROMPTINPUT

So base is set to #10. When setting up a user area, these values
are copied over. If you end up with the value zero in USER_BASE,
it either was overwritten afterwards, or it wasn't copied
correctly to begin with. For that I need to investigate, how
exactly a task area is setup. And propably read a lot of
documentation along the way :-)



> 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. 
>

> http://amforth.sourceforge.net/TG/recipes/Multitasking.html
This piece of documentation was written by me a long time ago.
It does need some brush up.


Now back to your original problem. I rephrase: "Wouldn't it be
nice if I have one or more background tasks running along and
printing their output as they go --- independantly of each
other"?

I think, it would. Now, what can we do about it? What is /the/
problem? One problem I mentioned is that the HOLD area (the
place where pictured output is stored before emitting it) is
shared between all tasks, as of this time[1]. A similar problem
occurs, if more than one task print to the same output,
character by character: we probably end up with a little mess.
Sometimes this is not a problem, other times it is.


Option 1: create a semaphore to ensure, that only one task is
accessing HOLD, until it's finished. I was convinced there is an
example in the cookbook. But there isn't. What I found is this:
> | common/lib/multitask-semaphore.frt
> | common/lib/multitask-messages.frt
That can serve as inspiration.


Option 2: create a separate hold area for each task.
Well. It surely can be done, and others have surely done so. I
need to spend some time on the exact layout of the RAM space.



Having said that I feel inclined to add another: "Wouldn't it be
nice, if I could run a second commandline task (quit) on an
existing second serial connection (thing atmega644pa or
similar)"? Thus effectively creating a *Two User AmForth on one
AtMega644pa*? Actually I do have a use case for this. And I have
started to implement something in small steps[2]:

- add a second interrupt service routine on incoming data on
  that second serial interface. 
  solved.
  
- add a second input ring buffer (below rx/key/key?)
  solved.
  
- add a second set of rx/key/key? tx/emit/emit? functions
  operating on the second serial interface
  solved.

these remain to done:

- add a second Terminal-Input-Buffer --- how hard could that be?

- add a second HLD area --- there we go! add a pointer to the
  task local hld area in the user area. Make sure it does not
  move somehow.

- setting up a second task and get it all going

- cleaning up a few (nasty?) tar pits found along the way and
  my own messes.

So I am practically at the same point, from a different
direction.


Interesting times ahead!


Dear list: if you have suggestions, snippets of code or
documentation, do not hesitate to chime in. I do appreciate any
help. 


Cheers,
Erich


[1] I learned this the hard way. I had a background task (a
clock) which would update the connected LCDisplay every second.
I did use the serial interface with the command loop at the same
time. And I did calculations there. Nothing spectecular. But
/sometimes/ AmForth would get it wrong! Wrong??? But why???

After a lot of staring (and cursing maybe) one day I saw, that
the wrong results interestingly occured at the turn of the
second! And suspiciously, the result was never greater than 59!
So updating the lcd using pictured numeric output of course,
overwrote the string that the foreground u. had prepared and
printed an unexpected result.

Another case of "afterwards everything is obvious!"


[2] AmForth provides the neccessary files and configuration
switches to use any one of up to 4 serial interfaces. See
> | avr8/drivers/usart_?.asm
However, the assumption is that only one interface is used at a
given controller configuration.


<...snip............................................>


-- 
May the Forth be with you ...

Re: [Amforth] Redirect EMIT from within a task

[tw <ho...@tj...>]

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....@na...> 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/
> >>>> Amf...@li...
> >>>> https://lists.sourceforge.net/lists/listinfo/amforth-devel
> >>> 
> >>> 
> >>> --
> >>> May the Forth be with you ...
> >>> 
> >>> 
> >>> _______________________________________________
> >>> Amforth-devel mailing list for http://amforth.sf.net/
> >>> Amf...@li...
> >>> https://lists.sourceforge.net/lists/listinfo/amforth-devel
> >> 
> >> 
> >> _______________________________________________
> >> Amforth-devel mailing list for http://amforth.sf.net/
> >> Amf...@li...
> >> https://lists.sourceforge.net/lists/listinfo/amforth-devel
> > 
> > 
> > --
> > May the Forth be with you ...
> > 
> > 
> > _______________________________________________
> > Amforth-devel mailing list for http://amforth.sf.net/
> > Amf...@li...
> > https://lists.sourceforge.net/lists/listinfo/amforth-devel
> 
> 
> _______________________________________________
> Amforth-devel mailing list for http://amforth.sf.net/
> Amf...@li...
> https://lists.sourceforge.net/lists/listinfo/amforth-devel

Re: [Amforth] Watchdog Timer on AVR8s

[Martin N. <amf...@mg...>]

I should add this is a follow-up to a thread started in 2019.
Here's the archive of that thread:
https://sourceforge.net/p/amforth/mailman/message/36683433/

-- 
Regards,

Martin Nicholas.

E-mail: mg...@mg....

Re: [Amforth] Watchdog Timer on AVR8s

[Martin N. <amf...@mg...>]

Hi,

I've had this one brewing for some time.

Looking at schemes for: AT90CAN128 & ATA6612C. Common variables
between chips: WDTCSR (WDTCR), WDTOE (WDCE), WDCE, WDE.
WDTCSR & WDTOE are included "For compatibility" in the CAN chip.

I include this in cold.asm. It should work with the two WDTs in the
chip series above as well as chips with no WDT at all:

.if defined(WDTCSR)
; There's a WDT, so we reset it as per the docs.
	in_	temp0, WDTCSR
	ori	temp0, (1<<WDCE) | (1<<WDE)
	out_	WDTCSR, temp0
	andi	temp0, ~(1<<WDE)
	out_	WDTCSR, temp0
.endif

If there is a third type of WDT then I'll think again.

IMHO this should be included in the boot-up code for all AVR8's. At the
end of the day, Aunty Atmel knows best and more about their chips than
any of us do, so if they say do it - just do it.

RIP Matthias Trute.

-- 
Regards,

Martin Nicholas.

E-mail: rep...@mg... (Address will be valid throughout 2020).

[Amforth] fixed D0>, updated website

[Erich W. <ew....@na...>]

Dear AmForthers,

so I "jumped" and actually wrote new content to the amforth
repository and project web site.

D0> has been fixed.

I added a new section "Opinion" to the website, sort of a blog.
There I added a entry describing how I went about fixing "D0>".


If you find errors, things not working as expected, or other
"observations", please do not hesitate to report them on this
list. Thank you.


Happy Forthing,
Erich

--
May the Forth be with you ...

Re: [Amforth] Sad News

[<di...@sc...>]

Hi all,
I have learned Forth back in the 80s on a TI99/4A.
Four years ago I found amforth and gave it a try.
So far I have not used it for a real project, but for me the absolutely best feature
is that amforth allows to run an interpreter directly on the hardware.
As you notice, I have not yet written about Matthias. I did not know him, only had
one exchange on the mailing list.
But a guy who creates such a good solution/environment and documentation
must have been a good person.
So I also wish him a pleasant journey to wherever and thanks for amforth!
Dieter
Am Sa., Mrz. 28, 2020 09:52 schrieb Erich Wälde :
Dear AmForthers,

I'm quite certain, that many of you have noticed Matthias'
unusual silence. Since July 2019 he was fighting a serious
health issue. His wife has informed me that Matthias has
left this planet for good on Wednesday evening (2020-03-25).

We wish him an exceptionally pleasant journey!

Matthias has contributed remarkable pieces to the Forth
community. Not only is he the creator of AmForth, which I have
used from an early stage. Not only has he increased the range of
target controllers to msp430, arm, and risc-v. He has always
been keen to make his work conform to the Forth Standard.
Moreover, he has gone even further by advancing the concept of
"recognizers" (originally proposed by Anton Ertl) through
several stages of implementation to a "Commettee supported
proposal", something that has not been seen before. If someone
wants to implement recognizers for her/his Forth, then this is
the interface to be written. The list of articles in the "Vierte
Dimension" dealing with or mentioning AmForth is simply
impressive.

I do feel privileged to have met him im person a few times.

Several weeks ago I had decided to at least try to keep the
website/repository updated, fixing bugs and documentation as
much as I can, and maybe a little more with your help.
Very fortunately I have been granted access to the web site.

I'm willing to take on this task as an expression of my deepest
respect for Matthias' work. I know that he spend countless hours on
AmForth. He has always been willing to listen to my many bug reports
and suggestions --- many more than the ones visible in the mailing
list archive. He had countless ideas to expand the system and keep it
useful for others. He is already sorely missed.

If I (or anyone) can learn anything from this situation: grant access
to your most important (digital) information or files to a trusted
person while you can. You might be unable to do so later.

Despite the sad facts:
Happy Forthing nonetheless! Keep going!
Maybe even get wild occasionally!

Greetings,
Erich

If you would like to express your feelings to his wife, I'm more
than happy to forward anything verbatim, if you send it my way.
If you would like a snail mail address from me, contact me via
ew....@na... (mailto:ew....@na...) ---

--
May the Forth be with you ...

_______________________________________________
Amforth-devel mailing list for http://amforth.sf.net/ (http://amforth.sf.net/)
Amf...@li... (mailto:Amf...@li...)
https://lists.sourceforge.net/lists/listinfo/amforth-devel (https://lists.sourceforge.net/lists/listinfo/amforth-devel)

Re: [Amforth] Sad News

[tristan <ho...@tj...>]

Very sad news.

AmForth was my introduction to Forth and Matthias' expertise and 
generosity were key to making that such a very positive experience. He 
is indeed already sorely missed.

Tristan

Re: [Amforth] Sad News

[John V. <joh...@gm...>]

Thank you for taking on the responsibility and "keeping the lights on".

Condolences to Matthias family. He will be missed.


On Sat., Mar. 28, 2020, 04:52 Erich Wälde, <ew....@na...> wrote:

>
> Dear AmForthers,
>
>
> I'm quite certain, that many of you have noticed Matthias'
> unusual silence. Since July 2019 he was fighting a serious
> health issue. His wife has informed me that Matthias has
> left this planet for good on Wednesday evening (2020-03-25).
>
> We wish him an exceptionally pleasant journey!
>
>
> Matthias has contributed remarkable pieces to the Forth
> community. Not only is he the creator of AmForth, which I have
> used from an early stage. Not only has he increased the range of
> target controllers to msp430, arm, and risc-v. He has always
> been keen to make his work conform to the Forth Standard.
> Moreover, he has gone even further by advancing the concept of
> "recognizers" (originally proposed by Anton Ertl) through
> several stages of implementation to a "Commettee supported
> proposal", something that has not been seen before. If someone
> wants to implement recognizers for her/his Forth, then this is
> the interface to be written. The list of articles in the "Vierte
> Dimension" dealing with or mentioning AmForth is simply
> impressive.
>
> I do feel privileged to have met him im person a few times.
>
>
>
> Several weeks ago I had decided to at least try to keep the
> website/repository updated, fixing bugs and documentation as
> much as I can, and maybe a little more with your help.
> Very fortunately I have been granted access to the web site.
>
>
> I'm willing to take on this task as an expression of my deepest
> respect for Matthias' work. I know that he spend countless hours on
> AmForth. He has always been willing to listen to my many bug reports
> and suggestions --- many more than the ones visible in the mailing
> list archive. He had countless ideas to expand the system and keep it
> useful for others. He is already sorely missed.
>
>
>
> If I (or anyone) can learn anything from this situation: grant access
> to your most important (digital) information or files to a trusted
> person while you can. You might be unable to do so later.
>
>
> Despite the sad facts:
> Happy Forthing nonetheless! Keep going!
> Maybe even get wild occasionally!
>
> Greetings,
> Erich
>
>
> If you would like to express your feelings to his wife, I'm more
> than happy to forward anything verbatim, if you send it my way.
> If you would like a snail mail address from me, contact me via
> ew....@na... ---
>
>
> --
> May the Forth be with you ...
>
>
> _______________________________________________
> Amforth-devel mailing list for http://amforth.sf.net/
> Amf...@li...
> https://lists.sourceforge.net/lists/listinfo/amforth-devel
>

Re: [Amforth] Sad News

[<dn...@se...>]

>
> Dear AmForthers,
>
>
> I'm quite certain, that many of you have noticed...

Ah, that explains the silence, and I'm soooo glad someone is picking up
the torch! We'll miss Matthias, but life goes on.

[Amforth] Sad News

[Erich W. <ew....@na...>]

Dear AmForthers,


I'm quite certain, that many of you have noticed Matthias'
unusual silence. Since July 2019 he was fighting a serious
health issue. His wife has informed me that Matthias has
left this planet for good on Wednesday evening (2020-03-25).

We wish him an exceptionally pleasant journey!


Matthias has contributed remarkable pieces to the Forth
community. Not only is he the creator of AmForth, which I have
used from an early stage. Not only has he increased the range of
target controllers to msp430, arm, and risc-v. He has always
been keen to make his work conform to the Forth Standard.
Moreover, he has gone even further by advancing the concept of
"recognizers" (originally proposed by Anton Ertl) through
several stages of implementation to a "Commettee supported
proposal", something that has not been seen before. If someone
wants to implement recognizers for her/his Forth, then this is
the interface to be written. The list of articles in the "Vierte
Dimension" dealing with or mentioning AmForth is simply
impressive.

I do feel privileged to have met him im person a few times.



Several weeks ago I had decided to at least try to keep the
website/repository updated, fixing bugs and documentation as
much as I can, and maybe a little more with your help.
Very fortunately I have been granted access to the web site.


I'm willing to take on this task as an expression of my deepest
respect for Matthias' work. I know that he spend countless hours on
AmForth. He has always been willing to listen to my many bug reports
and suggestions --- many more than the ones visible in the mailing
list archive. He had countless ideas to expand the system and keep it
useful for others. He is already sorely missed.



If I (or anyone) can learn anything from this situation: grant access
to your most important (digital) information or files to a trusted
person while you can. You might be unable to do so later.


Despite the sad facts:
Happy Forthing nonetheless! Keep going!
Maybe even get wild occasionally!

Greetings,
Erich


If you would like to express your feelings to his wife, I'm more
than happy to forward anything verbatim, if you send it my way.
If you would like a snail mail address from me, contact me via
ew....@na... ---


--
May the Forth be with you ...

[Amforth] -jtag broken, workaround

[Erich W. <ew....@na...>]

Dear AmForthers,

to my knowledge noone has ever complained that " -jtag " ceased to
work after version 5.5. Is it only me using this command?

Short version:

Since version 6.2 the content of the files
> releases/*/avr8/devices/*/words/no-jtag.asm 
is essentially an empty function. This can be fixed by copying 
> releases/5.5/core/words/no-jtag.asm 
to your project, and reassembling AmForth.


Longer version:

While porting an /old/ program from version 4.6 to 6.8 on an
atmega644p, it surprisingly failed to work. After some searching it
became clear that pin C.2 did not work as expected. Suspiciously, this
pin is part of the JTAG port. Moving to a non-jtag pin made the
program work.

Some code archeology found the following details:

- File "words/no-jtag.asm" was added in version 2.7
- it has changed a few times until version 5.5
- in version 5.6 it disappeared
- it reappeared in version 6.2 --- possibly because someone complained
  (may have been me). However, it reappeared in the devices subtree,
  separate for each controller. And it was and still is an empty
  function. 

I have no idea, why Matthias has distributed this function. To my
knowledge it is the same everywhere --- whereas sleep.asm had to be
distributed per controller before.


So, maybe this information saves some head scratching.

Cheers,
Erich


-- 
May the Forth be with you ...