amforth-devel — Development discussion and user support

Re: [Amforth] Missing DU<

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

Hello Martin,

> Also, a bug in D0>:
> Hmmm, something wrong here I feel:
>
>> (ATmega2560)> decimal  1553994000. d0> .   1572137999. d0> .
>> -1 0  ok

yes there is.

Short answer:

The assembly version produces the wrong result,
when the MostSignificantBit of the lower *word* is set.
> trunk/avr8/words/d-greaterzero.asm

The forth version is ok.
> trunk/common/lib/forth2012/double/d-greater-zero.frt

Workaround: use the forth code.


Sightly longer answer:
> | > $55557FFF. d0> .
> | -1  ok
> | > $55558000. d0> .
> | 0  ok

The exakt value of the high word (here $5555) is irrelevant.
The Forth version works as advertised:

> | > : new.d0> 2dup or >r  d0< 0=  r> and 0= 0= ;
> |  ok
> | > $55557FFF. new.d0> .
> | -1  ok
> | > $55558000. new.d0> .
> | -1  ok


The gory details:

So after a dive into the assembly code, reading the docs and a
fair amount of head scratching I think I see cause of the
problem:


#+name: trunk/avr8/macros.asm
#+begin_src asm
    .macro loadtos
        ld tosl, Y+
        ld tosh, Y+
    .endmacro
#+end_src

#+name: trunk/avr8/words/d-greaterzero.asm
#+begin_src asm
; ( d -- flag )
; Compare
; compares if a double double cell number is greater 0
VE_DGREATERZERO:
    .dw $ff03           ; flags,length
    .db "d0>",0         ; name
    .dw VE_HEAD         ; link to previous voc entry
    .set VE_HEAD = VE_DGREATERZERO ; advance pointer to first voc entry
XT_DGREATERZERO:        ; XT eXecution Token is here
    .dw PFA_DGREATERZERO; branch to PFA, this is an assembly word
PFA_DGREATERZERO:       ; so PFA is right here!

    cp tosl, zerol      ; compare            top-of-stack-low,  zero-low
    cpc tosh, zeroh     ; compare-with-carry top-of-stack-high, zero-high

; The result at this point is stored as flags in the STATUS
; register. The original values are left unchanged.

    loadtos             ; *I guess at this point*
                        ; TOS resides in a register pair
                        ; Y points to the remainder of the stack
                        ;   in RAM. So loadtos moves the former
                        ;   TOS-1 element into register pair tos
; does ld change the status register flags? nope.

    cpc tosl, zerol     ; compare-with-carry top-of-stack-1-low,  zero-low
    cpc tosh, zeroh     ; compare-widh-carry top-of-stack-1-high, zero-high

; at this point we have consumed 4 Register values and compared
; them with zero. Reading up on the exact workings of "cp" and
; "cpc" I conclude
;
; cp Rd, Rr
; calculates R = Rd - Rr
; and stores the flags derived from the result R in the status
; register. In particular
;
; Flag Z is set if all bits of the result R are cleared.
;
; Flag S (Signed) = N xor V
;
; Flag N (Negative) is set when R7 (MSB in R) ist set, clear
;        otherwise
;
; Flag V (oVerflow) is set if calculating the result produces a
;        2 complements overflow.
;        since Rr is zero, there should never be such an
;        overflow. So in this case V=0.
;
; The S flag is set, if any of the 4 Bytes (== 2 words) have
; their MSB set. That's what we see in the example above.
;

    brlt PFA_ZERO1      ; Branch if Less Than, Signed
                        ; Tests the signed flag and branches, if S is set
; at this point, the S flag is used. I currently think that only
; the MSB of the highest Byte should be inspected for this
; decision.

    brbs 1, PFA_ZERO1   ; Branch if Status Flag Set, bit 1 (Z) is used
; however, at this point the Z flag is used! Therefore the lower
; Bytes must have been inspected as well!

    rjmp PFA_TRUE1      ; jump, (tail call opt.)

; ----------------------
PFA_ZERO1:
    movw tosl, zerol    ; copy 0,0 to tosl,h
    jmp_ DO_NEXT

; ----------------------
PFA_TRUE1:
    ser tosl            ; ser set all bits in register
    ser tosh
    jmp_ DO_NEXT
#+end_src

I'm not sure I have yet understood the problem in all details.
E.g. the error should show up as well, if only the MSB of a
lower Byte is set.
> | > $00000080. d0> .
> | -1  ok
> | > $00008000. d0> .
> | 0  ok
> | > $00800000. d0> .
> | -1  ok
> | > $80000000. d0> .
> | -1  ok
But that is not the case.

Moreover I'm uncertain, how to fix this, or whether the assembly
version should just be removed. Inspecting the code tree
reveals, that this file was added in Version 5.2 and was
unchanged ever since. So it never has worked, it seems.


Any suggestions?
Happy Hacking.

Cheers,
Erich

--
May the Forth be with you ...

Re: [Amforth] Redirect EMIT from within a task

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

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

Re: [Amforth] Redirect EMIT from within a task

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

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

Re: [Amforth] Redirect EMIT from within a task

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

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
> 

Re: [Amforth] Redirect EMIT from within a task

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

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] Redirect EMIT from within a task

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

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

;

Re: [Amforth] Missing DU<

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

Hello Martin,

> Also, a bug in D0>:
> Hmmm, something wrong here I feel:
> 
> > (ATmega2560)> decimal  1553994000. d0> .   1572137999. d0> .  
> > -1 0  ok  

Yes, you are right. There is something odd with d0>

It seems when the sign[1] of the least significant cell and the most
significant cell is the same, d0> gives the right answer. When they
are different, d0> gives the wrong answer.

[1] with sign defined by state of msb

amforth 6.8 ATmega328P Forthduino
> 0 0 d.
0  ok
> 0 0 d0> . cr
0 

> 1 0 d.
1  ok
> 1 0 d0> . cr
-1 

> 0 1 d.
65536  ok
> 0 1 d0> . cr
-1

> 1 1 d.
65537  ok
> 1 1 d0> . cr
-1 

> -1 0 d.
65535  ok
> -1 0 d0> . cr
0 

> 0 -1 d.
-65536  ok
> 0 -1 d0> . cr
-1 
 
> -1 -1 d.
-1  ok
> -1 -1 d0> . cr
0 

> -1 1 d.
131071  ok
> -1 1 d0> . cr
0 

> 1 -1 d.
-65535  ok
> 1 -1 d0> . cr
-1 

Kind regards,

Tristan

On 26Aug19 07:46, Martin Nicholas via Amforth-devel wrote:
> Not present in 6.8 as far as I can see.
> 
> > 8.6.2.1270 DU< “d-u-less” DOUBLE EXT
> > ( ud1 ud2 -- flag )
> > flag is true if and only if ud1 is less than ud2.
> 
> Also, a bug in D0>:
> Hmmm, something wrong here I feel:
> 
> > (ATmega2560)> decimal  1553994000. d0> .   1572137999. d0> .  
> > -1 0  ok  
> 
> Cheers!
> 
> -- 
> Regards,
> 
> Martin Nicholas.
> 
> E-mail: rep...@mg... (Address will be valid throughout 2019).
> 
> 
> _______________________________________________
> Amforth-devel mailing list for http://amforth.sf.net/
> Amf...@li...
> https://lists.sourceforge.net/lists/listinfo/amforth-devel

[Amforth] Missing DU<

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

Not present in 6.8 as far as I can see.

> 8.6.2.1270 DU< “d-u-less” DOUBLE EXT
> ( ud1 ud2 -- flag )
> flag is true if and only if ud1 is less than ud2.

Also, a bug in D0>:
Hmmm, something wrong here I feel:

> (ATmega2560)> decimal  1553994000. d0> .   1572137999. d0> .  
> -1 0  ok  

Cheers!

-- 
Regards,

Martin Nicholas.

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

Re: [Amforth] Read/write from safe known fixed EEPROM address

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

Hello Erich,

Project was probably too grand a word! I have made a few notes below,
though they are not of cookbook standard.

https://www.mostlymostly.uk/post/2019.08.09/

kind regards,

Tristan

On 14Aug19 08:39, Erich Wälde wrote:
> Hello Tristan,
> 
> > Thanks again for your help.
> You are welcome!
> 
> > I managed to modify applturnkey to read from internal EEPROM,
> > which was the missing part of my project to have AmForth use
> > the RC oscillator as a clock source.
> Glad I could help. It is often only a tiny piece of information,
> which opens the door.
> 
> Happy hacking!
> Please consider to share more details of your project,
> we are all eager to learn from others, aren't we?
> 
> Cheers,
> Erich
> 
> 
> --
> 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] Read/write from safe known fixed EEPROM address

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

Hello Tristan,

> Thanks again for your help.
You are welcome!

> I managed to modify applturnkey to read from internal EEPROM,
> which was the missing part of my project to have AmForth use
> the RC oscillator as a clock source.
Glad I could help. It is often only a tiny piece of information,
which opens the door.

Happy hacking!
Please consider to share more details of your project,
we are all eager to learn from others, aren't we?

Cheers,
Erich


--
May the Forth be with you ...

Re: [Amforth] Read/write from safe known fixed EEPROM address

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

Hello Erich,

Thanks again for your help. I managed to modify applturnkey to read
from internal EEPROM, which was the missing part of my project to have
AmForth use the RC oscillator as a clock source. 

kind regards,

Tristan

On 08Aug19 19:47, Erich Wälde wrote:
> Hello Tristan,
> 
> 
> >
> > In avr8/amforth-eeprom.inc the top line is
> >
> >     .dw -1           ; EEPROM Address 0 should not be used
> >
> > Does this mean that $0 is reserved and used by AmForth internally or
> > $0 is not to be used because historically it has been used by other
> > programs e.g. storing calibrated OSCCAL value? If it is the latter,
> > then it would be very opportune.
> 
> If my memory serves me well, some toolchains keep track of the
> number of erase cycles they did, or something such. I do not
> know why Matthias has chosen to not use addr 0. But I do not use
> it either. Once I have defined an new label at the end, and
> used it somewhere else, I tend to forget, where it was. Because
> I never have do deal with this address again.
> 
> So, imho not important.
> 
> Cheers, and good luck!
> Erich
> 
> 
> -- 
> 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] Read/write from safe known fixed EEPROM address

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

Hello Tristan,


>
> In avr8/amforth-eeprom.inc the top line is
>
>     .dw -1           ; EEPROM Address 0 should not be used
>
> Does this mean that $0 is reserved and used by AmForth internally or
> $0 is not to be used because historically it has been used by other
> programs e.g. storing calibrated OSCCAL value? If it is the latter,
> then it would be very opportune.

If my memory serves me well, some toolchains keep track of the
number of erase cycles they did, or something such. I do not
know why Matthias has chosen to not use addr 0. But I do not use
it either. Once I have defined an new label at the end, and
used it somewhere else, I tend to forget, where it was. Because
I never have do deal with this address again.

So, imho not important.

Cheers, and good luck!
Erich


-- 
May the Forth be with you ...

Re: [Amforth] Read/write from safe known fixed EEPROM address

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

Hello Erich,

Thank you! 

I wish to read/write the value from/to a known fixed EEPROM address
from applturnkey using assembler. Thank you for pointing me towards
avr8/amforth-eeprom.inc 

In avr8/amforth-eeprom.inc the top line is

    .dw -1           ; EEPROM Address 0 should not be used

Does this mean that $0 is reserved and used by AmForth internally or
$0 is not to be used because historically it has been used by other
programs e.g. storing calibrated OSCCAL value? If it is the latter,
then it would be very opportune.

kind regards and thanks,
Tristan


On 07Aug19 12:09, Erich Wälde wrote:
> Hello Tristan,
> 
> 
> Tristan Williams writes:
> 
> > Hello,
> >
> > I would like to modify my AVR build of AmForth to read/write a byte
> > from a known fixed EEPROM address, perhaps from applturnkey. This byte
> > may be written outside of AmForth. Is there a safe area of EEPROM
> > from which to do this or a way making one? Any pointers as to where to
> > look appreciated.
> 
> 
> Words like "eallot" "Evalue" "e@" "e!" and the like are
> available, let's see ...
> 
>   | @e              | ./avr8/words/fetch-e.asm
>   | !e              | ./avr8/words/store-e.asm
>   | ehere           | ./avr8/words/ehere.asm
>   | eallot          | ./avr8/lib/eallot.frt
>   | Evalue          | ./avr8/lib/forth2012/core/avr-values.frt
>   | 2@e 2!e 2Evalue | ./avr8/lib/2evalue.frt
>   | Eallot Ebuffer  | ./avr8/lib/forth2012/core/eeprom-buffer.frt
> 
> 
> So I think, creating an Evalue could help you. There is some
> more text here
> http://amforth.sourceforge.net/TG/recipes/Values.html
> 
> You can then wrap such stuff together with applturnkey
> (example):
> 
> >  : run-turnkey
> >    applturnkey \ call the original turnkey first
> >  
> >    init        \ add one time stuff here
> >  
> >    starttasker \ start the loop!
> >  ;
> 
> 
> 
> 
> However, if you want to modify AmForth to be assembled with this
> value already, then avr8/amforth-eeprom.inc is the place to
> start. Add another label and value in this file, verify that
> ehere points to the correct (first empty) location after
> assembling, and be sure to add a word, which will retrieve this
> EEprom content and place it on the stack.
> 
> Well, I have done this before ... /me searches the archives ...
> 
> in a project-local copy of amforth-eeprom.inc I added 2 lines to
> define a location in eeprom
> 
> >  EE_UBRRVAL:
> >      .dw UBRR_VAL     ; BAUDRATE
> > +EE_PROMPT_RDY:
> > +        .dw XT_PROMPTREADY_INT
> 
> This label (EE_PROMPT_RDY) is used in a word defined in asm:
> 
> >  cat words/prompt-ready.asm
> >  ; make prompt_ready a deferred word
> >       
> >  VE_PROMPTREADY:
> >      .dw $ff04
> >      .db "p_rd"
> >      .dw VE_HEAD
> >      .set VE_HEAD = VE_PROMPTREADY
> >  XT_PROMPTREADY:
> >      .dw PFA_DODEFER1
> >  PFA_PROMPTREADY:
> >      .dw EE_PROMPT_RDY      ; <---- used here
> >      .dw XT_EDEFERFETCH
> >      .dw XT_EDEFERSTORE
> 
> The content of this location is retrieved (edefer@) and should
> be on top of the stack then (it is consumed again by edefer! in
> this case.)  The defined "p_rd" is used in Forth code later:
> 
> : +stationid
>   ['] prompt_rd to p_rd
> ;
> : init
>   +stationid
>   ...
> ;     
> 
> In this particular case I made the ready prompt to be a deferred
> word, because I wanted it to print some information (the
> stationID). Nowadays all prompt functions are deferred and I
> don't need to do this any more. But it should give you an idea
> on how to proceed.
> 
> There is one more option: the Evalue can live in an external i2c
> EEPROM, too. See
> http://amforth.sourceforge.net/TG/recipes/I2C-Values.html#i2c-values
> 
> 
> So many options!
> Hope this helps,
> 
> Erich
> 
> --
> 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] Read/write from safe known fixed EEPROM address

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

Hello Tristan,


Tristan Williams writes:

> Hello,
>
> I would like to modify my AVR build of AmForth to read/write a byte
> from a known fixed EEPROM address, perhaps from applturnkey. This byte
> may be written outside of AmForth. Is there a safe area of EEPROM
> from which to do this or a way making one? Any pointers as to where to
> look appreciated.


Words like "eallot" "Evalue" "e@" "e!" and the like are
available, let's see ...

  | @e              | ./avr8/words/fetch-e.asm
  | !e              | ./avr8/words/store-e.asm
  | ehere           | ./avr8/words/ehere.asm
  | eallot          | ./avr8/lib/eallot.frt
  | Evalue          | ./avr8/lib/forth2012/core/avr-values.frt
  | 2@e 2!e 2Evalue | ./avr8/lib/2evalue.frt
  | Eallot Ebuffer  | ./avr8/lib/forth2012/core/eeprom-buffer.frt


So I think, creating an Evalue could help you. There is some
more text here
http://amforth.sourceforge.net/TG/recipes/Values.html

You can then wrap such stuff together with applturnkey
(example):

>  : run-turnkey
>    applturnkey \ call the original turnkey first
>  
>    init        \ add one time stuff here
>  
>    starttasker \ start the loop!
>  ;




However, if you want to modify AmForth to be assembled with this
value already, then avr8/amforth-eeprom.inc is the place to
start. Add another label and value in this file, verify that
ehere points to the correct (first empty) location after
assembling, and be sure to add a word, which will retrieve this
EEprom content and place it on the stack.

Well, I have done this before ... /me searches the archives ...

in a project-local copy of amforth-eeprom.inc I added 2 lines to
define a location in eeprom

>  EE_UBRRVAL:
>      .dw UBRR_VAL     ; BAUDRATE
> +EE_PROMPT_RDY:
> +        .dw XT_PROMPTREADY_INT

This label (EE_PROMPT_RDY) is used in a word defined in asm:

>  cat words/prompt-ready.asm
>  ; make prompt_ready a deferred word
>       
>  VE_PROMPTREADY:
>      .dw $ff04
>      .db "p_rd"
>      .dw VE_HEAD
>      .set VE_HEAD = VE_PROMPTREADY
>  XT_PROMPTREADY:
>      .dw PFA_DODEFER1
>  PFA_PROMPTREADY:
>      .dw EE_PROMPT_RDY      ; <---- used here
>      .dw XT_EDEFERFETCH
>      .dw XT_EDEFERSTORE

The content of this location is retrieved (edefer@) and should
be on top of the stack then (it is consumed again by edefer! in
this case.)  The defined "p_rd" is used in Forth code later:

: +stationid
  ['] prompt_rd to p_rd
;
: init
  +stationid
  ...
;     

In this particular case I made the ready prompt to be a deferred
word, because I wanted it to print some information (the
stationID). Nowadays all prompt functions are deferred and I
don't need to do this any more. But it should give you an idea
on how to proceed.

There is one more option: the Evalue can live in an external i2c
EEPROM, too. See
http://amforth.sourceforge.net/TG/recipes/I2C-Values.html#i2c-values


So many options!
Hope this helps,

Erich

--
May the Forth be with you ...

[Amforth] Read/write from safe known fixed EEPROM address

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

Hello,

I would like to modify my AVR build of AmForth to read/write a byte
from a known fixed EEPROM address, perhaps from applturnkey. This byte
may be written outside of AmForth. Is there a safe area of EEPROM
from which to do this or a way making one? Any pointers as to where to
look appreciated.

Kind regards,
Tristan

Re: [Amforth] Looking for instructions io install Amforth on Arduino

[devin d. <lyo...@gm...>]

I am using the avrdude packaged with winavr. After running the command
provided by peter, i was able to get it programmed and greeted with the
forth prompt via putty.

Thank you for your assistance. Hopefully now i can get started with it and
make something interesting.

On Wed, Jul 17, 2019 at 12:20 PM Peter Mortensen <
spa...@pm...> wrote:

>
>  >>> On 10 Jul 2019, at 21:12, devin davison <lyo...@gm...> wrote:
>  >>>
>  >>> I am interested in trying out AmForth on an Arduino Uno.
>  >>>
>  >>> I have many of them, from what I understand I can use
>  >>> one Arduino Uno as the ISP programmer to program others.
>  >>> I have not found a guide on how to get AmForth onto the
>  >>> Arduino. Can anyone provide some advice or a link to
>  >>> some relevant information to get me on track?
>  >> ...
>  >
>  > On 17/07/2019 06:46, devin davison wrote:
>  >
>  > Thanks for the info. I am on a Windows machine, using avrdude. I am
> trying
>  > to use the following command, taken from the link provided by Peter C.
>  > (I replaced the COM port with my COM port, COM8)
>  >
>  >     *avrdude -p m328p -c avrispmkII -P com8 -U efuse:w:0xFF:m -U
> hfuse:w:0xD9:m -U lfuse:w:0xFF:m -U flash:w:uno.hex:i -U
> eeprom:w:uno.eep.hex:i*
>  >
>  > It does not appear to be working properly. I just get a timeout message
>  > repeating indefinitely. I can get the command to work and flash the hex
>  > file if I leave out the fuse settings, but I'm unable to connect via
> a serial
>  > terminal.
>
> I have the exact same setup. This worked for
> me (for the Arduino ISP programmer on COM3):
>
>
>      avrdude -pm328p -P\\.\COM3 -carduino -b19200 -U flash:w:uno.hex -U
> eeprom:w:uno.eep.hex -U efuse:w:0xfd:m -U hfuse:w:0xd9:m -U
> lfuse:w:0xff:m -v
>
>
> Make sure you are actually using a more recent version of AVRDUDE (the
> version that comes with
>
> more recently versions of the Arduino IDE is OK). Some other installed
> software may have placed an
>
> outdated version of AVRDUDE that is started instead, due to the content
> of the "PATH" environment
>
> variable. I once positively found I had to use at least version 6.1 of
> AVRDUDE (both the older ones
>
> that came with a version of AVR-GCC and with Arduino IDE v. 1.0.5 (v.
> 5.11) were too old).
>
>
> Regards,
>
> Peter Mortensen
>
>
>
>
>
> _______________________________________________
> Amforth-devel mailing list for http://amforth.sf.net/
> Amf...@li...
> https://lists.sourceforge.net/lists/listinfo/amforth-devel
>

Re: [Amforth] Looking for instructions io install Amforth on Arduino

[Peter M. <spa...@pm...>]

 >>> On 10 Jul 2019, at 21:12, devin davison <lyo...@gm...> wrote:
 >>>
 >>> I am interested in trying out AmForth on an Arduino Uno.
 >>>
 >>> I have many of them, from what I understand I can use
 >>> one Arduino Uno as the ISP programmer to program others.
 >>> I have not found a guide on how to get AmForth onto the
 >>> Arduino. Can anyone provide some advice or a link to
 >>> some relevant information to get me on track?
 >> ...
 >
 > On 17/07/2019 06:46, devin davison wrote:
 >
 > Thanks for the info. I am on a Windows machine, using avrdude. I am 
trying
 > to use the following command, taken from the link provided by Peter C.
 > (I replaced the COM port with my COM port, COM8)
 >
 >     *avrdude -p m328p -c avrispmkII -P com8 -U efuse:w:0xFF:m -U 
hfuse:w:0xD9:m -U lfuse:w:0xFF:m -U flash:w:uno.hex:i -U 
eeprom:w:uno.eep.hex:i*
 >
 > It does not appear to be working properly. I just get a timeout message
 > repeating indefinitely. I can get the command to work and flash the hex
 > file if I leave out the fuse settings, but I'm unable to connect via 
a serial
 > terminal.

I have the exact same setup. This worked for
me (for the Arduino ISP programmer on COM3):


     avrdude -pm328p -P\\.\COM3 -carduino -b19200 -U flash:w:uno.hex -U 
eeprom:w:uno.eep.hex -U efuse:w:0xfd:m -U hfuse:w:0xd9:m -U 
lfuse:w:0xff:m -v


Make sure you are actually using a more recent version of AVRDUDE (the 
version that comes with

more recently versions of the Arduino IDE is OK). Some other installed 
software may have placed an

outdated version of AVRDUDE that is started instead, due to the content 
of the "PATH" environment

variable. I once positively found I had to use at least version 6.1 of 
AVRDUDE (both the older ones

that came with a version of AVR-GCC and with Arduino IDE v. 1.0.5 (v. 
5.11) were too old).


Regards,

Peter Mortensen

Re: [Amforth] Looking for instructions io install Amforth on Arduino

[Peter C. H. <pet...@un...>]

Devin,

What programmer are you using?  If you are not using the AVRISP mkII or a clone then you will need to change "avrispmkII" in the command string to something else.  

If you are using a second Arduino as programmer "arduino" will probably work.

Peter



> On 17 Jul 2019, at 06:46, devin davison <lyo...@gm...> wrote:
> 
> Thanks for the info. I am on a windows machine, using avrdude. I am trying
> to use the following command , taken from the link provided by Peter C.
> (i replaced the com port with my com port, com8)
> 
> *avrdude -p m328p -c avrispmkII -P com8 -U efuse:w:0xFF:m -U hfuse:w:0xD9:m
> -U lfuse:w:0xFF:m -U flash:w:uno.hex:i -U eeprom:w:uno.eep.hex:i*
> 
> It does not appear to be working properly, i just get a timeout message
> repeating indefinitely. I can get the command to work and flash the hex
> file if i leave out the fuse settings, but im unable to connect via serial
> terminal.
> Any further help is much appreciated.
> 
> On Wed, Jul 10, 2019 at 4:04 PM Peter C. Hauser <pet...@un...>
> wrote:
> 
>> You may also find this useful:
>> 
>> https://www.chemie1.unibas.ch/~hauser/open-source-lab/styled/index.html <
>> https://www.chemie1.unibas.ch/~hauser/open-source-lab/styled/index.html>
>> 
>> (scroll to the bottom of the page)
>> 
>> 
>> Peter
>> 
>> 
>> 
>>> On 10 Jul 2019, at 21:12, devin davison <lyo...@gm...> wrote:
>>> 
>>> Hello, New around here. I am interested in trying out Amforth on an
>> arduino
>>> uno. I have many of them, from what I understand I can use one arduino
>> UNO
>>> as the ISP programmer to program others. I have not found a guide on how
>> to
>>> get amforth onto the arduino, can anyone provide some advice or a link to
>>> some relevant information to get me on track?
>>> 
>>> Thanks
>>> 
>>> --Devin D.
>>> 
>>> _______________________________________________
>>> 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
>> 
> 
> _______________________________________________
> Amforth-devel mailing list for http://amforth.sf.net/
> Amf...@li...
> https://lists.sourceforge.net/lists/listinfo/amforth-devel

Re: [Amforth] Looking for instructions io install Amforth on Arduino

[devin d. <lyo...@gm...>]

Thanks for the info. I am on a windows machine, using avrdude. I am trying
to use the following command , taken from the link provided by Peter C.
(i replaced the com port with my com port, com8)

*avrdude -p m328p -c avrispmkII -P com8 -U efuse:w:0xFF:m -U hfuse:w:0xD9:m
-U lfuse:w:0xFF:m -U flash:w:uno.hex:i -U eeprom:w:uno.eep.hex:i*

It does not appear to be working properly, i just get a timeout message
repeating indefinitely. I can get the command to work and flash the hex
file if i leave out the fuse settings, but im unable to connect via serial
terminal.
Any further help is much appreciated.

On Wed, Jul 10, 2019 at 4:04 PM Peter C. Hauser <pet...@un...>
wrote:

> You may also find this useful:
>
> https://www.chemie1.unibas.ch/~hauser/open-source-lab/styled/index.html <
> https://www.chemie1.unibas.ch/~hauser/open-source-lab/styled/index.html>
>
> (scroll to the bottom of the page)
>
>
> Peter
>
>
>
> > On 10 Jul 2019, at 21:12, devin davison <lyo...@gm...> wrote:
> >
> > Hello, New around here. I am interested in trying out Amforth on an
> arduino
> > uno. I have many of them, from what I understand I can use one arduino
> UNO
> > as the ISP programmer to program others. I have not found a guide on how
> to
> > get amforth onto the arduino, can anyone provide some advice or a link to
> > some relevant information to get me on track?
> >
> > Thanks
> >
> > --Devin D.
> >
> > _______________________________________________
> > 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] Looking for instructions io install Amforth on Arduino

[Peter C. H. <pet...@un...>]

You may also find this useful:

https://www.chemie1.unibas.ch/~hauser/open-source-lab/styled/index.html <https://www.chemie1.unibas.ch/~hauser/open-source-lab/styled/index.html>

(scroll to the bottom of the page)


Peter



> On 10 Jul 2019, at 21:12, devin davison <lyo...@gm...> wrote:
> 
> Hello, New around here. I am interested in trying out Amforth on an arduino
> uno. I have many of them, from what I understand I can use one arduino UNO
> as the ISP programmer to program others. I have not found a guide on how to
> get amforth onto the arduino, can anyone provide some advice or a link to
> some relevant information to get me on track?
> 
> Thanks
> 
> --Devin D.
> 
> _______________________________________________
> Amforth-devel mailing list for http://amforth.sf.net/
> Amf...@li...
> https://lists.sourceforge.net/lists/listinfo/amforth-devel

Re: [Amforth] Looking for instructions io install Amforth on Arduino

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

Check here for the basics:
http://amforth.sourceforge.net/UG/amforth_user.html


On Wed, 10 Jul 2019 at 15:13, devin davison <lyo...@gm...> wrote:

> Hello, New around here. I am interested in trying out Amforth on an arduino
> uno. I have many of them, from what I understand I can use one arduino UNO
> as the ISP programmer to program others. I have not found a guide on how to
> get amforth onto the arduino, can anyone provide some advice or a link to
> some relevant information to get me on track?
>
> Thanks
>
> --Devin D.
>
> _______________________________________________
> Amforth-devel mailing list for http://amforth.sf.net/
> Amf...@li...
> https://lists.sourceforge.net/lists/listinfo/amforth-devel
>


-- 


[image: --]

John Verne
[image: https://]about.me/jverne
<https://about.me/jverne?promo=email_sig>

[Amforth] Looking for instructions io install Amforth on Arduino

[devin d. <lyo...@gm...>]

Hello, New around here. I am interested in trying out Amforth on an arduino
uno. I have many of them, from what I understand I can use one arduino UNO
as the ISP programmer to program others. I have not found a guide on how to
get amforth onto the arduino, can anyone provide some advice or a link to
some relevant information to get me on track?

Thanks

--Devin D.

Re: [Amforth] how to use bitmask:

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

Dear Jan,

thanks for your message.

see my answer below the text.


Jan Kromhout via Amforth-devel writes:

> Hello,
>
>
> After trying for a while, I failed to get these three words together.
> Do not master the bitmask. Despite the examples and the email. Can someone please help me with this.
> This is my simple code. The source is from flashForth.
> The tree words are setBitmask,clearBitmask and testBitmask.
>
> Thanks for any help.
> With kindly regards,
>
> Jan
>
> $24 constant ddrb
> $25 constant portb
> $4c constant spcr
> $4d constant spsr
> $4e constant spdr
>
>
> \ bit masks
> %000100 constant mSS          ( PB2 - pin 10 )
> %001000 constant mMOSI        ( PB3 - pin 11 )
> %010000 constant mMISO        ( PB4 - pin 12 )
> %100000 constant mSCK         ( PB5 - pin 13 )
> $80     constant mSPIF
> $40     constant mWCOL
>
>
> : setBitmask ; ( bitmask port -- )
>
> : clrBitmask ; ( bitmask port -- )
>
> : testBitmask ; ( bitmask port -- flag )
>
> : spi.init ( -- )
>   mSCK ddrb setBitmask                \ SCK as output
>   mSCK portb clrBitmask               \ clock idles low
>   mMOSI ddrb setBitmask               \ MOSI as output
>   mMISO ddrb clrBitmask               \ MISO as input
>   mMISO portb setBitmask              \ activate pull -up on MISO
>   mSS ddrb setBitmask                         \ SS as output
>   mSS portb setBitmask                \ deselect
>   $51 spcr c!                                         \ enable as master with cpolarity 0, cphase 0, fosc /16
>   $00 spsr c!                                         \ SPI2X =0 for fosc /16
>   spsr c@ drop spdr c@ drop           \ will clear SPIF
> ;
>
> : spi.wait ( -- )
>   begin mSPIF spsr testBitmask until 
> ;
>
>


your line
>  mSCK ddrb setBitmask   \ SCK as output

expands to
>  $20  $24  setBitmask

so your question is: what is "setBitmask" supposed to be? At first
sight you might want to set

> : setBitmask ( mask addr -- ) c! ;  \ no good!

But that would not work well. Setting exaktly 1 bit in 1 register
would work, but setting the second bit in the same register would
overwrite the first set bit. So what would help? Well we need to
1. read the actual content of the register
2. fiddle with the wanted bit
3. write the new content back to the register

> : setBitmask ( mask addr -- )
>                     \ mask addr
>   dup               \ mask addr addr
>   c@                \ mask addr content   1.
>   rot               \ addr content mask
>   or                \ addr new_content    2.
>   swap              \ new_content addr
>   c!                \                     3.
> ;

likewise for

> : clearBitmask ( mask addr -- )
>                     \ mask addr
>   dup               \ mask addr addr
>   c@                \ mask addr content   1.
>   rot               \ addr content mask
>   invert            \ addr content !mask
>   and               \ addr new_content    2.
>   swap              \ new_content addr
>   c!                \                     3.
> ;

UNTESTED CODE!

Now, the pattern "read modify write" and "content mask or" and
"content mask invert and" are needed very often. So this is, what
the bitnames library abstracts away for us.

If you look into "amforth/trunk/avr8/lib/bitnames.frt" you find

> \ Turn a port pin on, dont change the others.
> : high ( pinmask portadr -- )
>     dup  ( -- pinmask portadr portadr )
>     c@   ( -- pinmask portadr value )
>     rot  ( -- portadr value pinmask )
>     or   ( -- portadr new-value)
>     swap ( -- new-value portadr)
>     c!
> ;
> 
> \ Turn a port pin off, dont change the others.
> : low ( pinmask portadr -- )
>     dup  ( -- pinmask portadr portadr )
>     c@   ( -- pinmask portadr value )
>     rot  ( -- portadr value pinmask )
>     invert and ( -- portadr new-value)
>     swap ( -- new-value port)
>     c!
> ;

which look suspiciously similar to what I wrote above. The difference
is that this code is tested!

So

> : setBitmask ( mask addr -- ) high ;
> : clearBitmask ( mask addr -- ) low ;

should work in my opinion.


Now, there is one more thing that "bitnames.frt" can do for you.
Instead of writing

> $24 constant ddrb
> %100000 constant mSCK         ( PB5 - pin 13 )
> ...
> mSCK ddrb setBitmask          \ SCK as output

you could write instead

> #include bitnames.frt
> $25 constant portb
>
> portb 5 portpin: mSCK
> ...
> mSCK high

Now what happens is this:

This line
> portb 5 portpin: mSCK

defines a new word "mSCK". When you call this word it will
place two items on the stack:
1. the bitmask corresponding to 5, namely %0010_0000
2. the address of the portb register, namely $24   (top of stack)

This is exactly what the functions "high" or "low" expect. They will
do the "read modify write" thing for you and all there is left to
write is this:

> mSCK high

isn't this wonderfully short and easy to read? Well, maybe not
at first sight.

So looking at my own spi start code from way back:


> \ 2010-05-24  EW   ewlib/spi.fs
> \ spi, using hw interface
> \ needs in dict_appl.inc: .include "words/spirw.asm"
> 
> \ words:
> \     +spi   ( -- )
> \     -spi   ( -- )
> \     ><spi  ( x -- x' )   transfer 2 bytes
> 
> \ Needs at least these definitions
> \ SPI
> \ $2D constant SPCR        \ SPI Control Register
> \ $2F constant SPDR        \ SPI Data Register
> \ $2E constant SPSR        \ SPI Status Register
> 
> \ needs lib/bitnames.frt   \ port_pin: high low pin_{out,in}put
> \ ----------------------------------------------------------
> 
> \ SPCR (control register)
> \ . 7 SPIE   spi interrupt enable
> \ . 6 SPE    spi enable
> \ . 5 DORD   data order, 0 msb first
> \ . 4 MSTR   master/slave mode, 1 master
> \ . 3 CPOL   clock polarity, 0 clock low on idle
> \ . 2 CPHA   clock phase,    0 sample on leading edge
> \ . 01 SPIR  data rate, 00 f/4, 01 f/16, 10 f/64, 11 f/128
> \ SPE | MSTR | SPIR0  ==> $51
> 
> \ needs these defined before loading:
> PORTB 4 portpin: /ss
> \ PORTB 5 portpin: _mosi
> \ PORTB 6 portpin: _miso
> \ PORTB 7 portpin: _clk
> 
> : +spi ( -- )
>   /ss high \ activate pullup!
>   _mosi high _mosi pin_output
>   _clk  low  _clk  pin_output
> \  _miso pin_pullup_on  \ not needed, see datasheet
>   $53 SPCR c! \ enable, master mode, f/128 data rate
> ;
> : -spi  0 SPCR c! ;
> 
> \ transfer 1 byte:  spirw (  c -- c' )
> \ transfer 1 cell: 2spirw ( n1 -- n2 )

Please note, the bit definitions are for a atmega644 and need to
be adjusted accordingly.


There we go: "high" and "low" do their bit as explained above.
Additionally "pin_output" and "pin_input" will deduce
the address of the DataDirectionRegister from the Port address.
No need to pay any attention.


There are two more noteworthy items in function "+spi"

1. /ss high \ activate pullup

*even if nothing is connected to that pin!*
If you do not activate this, your spi unit remains in slave mode iirc.

2. \ _miso pin_pullup_on  \ not needed, see datasheet

if I remember correctly, calling this command breaks spi. But I might
be wrong on this.

If you reread the spi section in the datasheet this information
should now stare right at you. It was there on first read, but
you (and I as well :-) did not understand its implications.
Keep going!


So, hopefully this will get you out of this somewhat dark area.

Cheers,
Erich

<snip>

-- 
May the Forth be with you ...

Re: [Amforth] how to use bitmask:

[Jan K. <jan...@ic...>]

Hello,


After trying for a while, I failed to get these three words together.
Do not master the bitmask. Despite the examples and the email. Can someone please help me with this.
This is my simple code. The source is from flashForth.
The tree words are setBitmask,clearBitmask and testBitmask.

Thanks for any help.
With kindly regards,

Jan

$24 constant ddrb
$25 constant portb
$4c constant spcr
$4d constant spsr
$4e constant spdr


\ bit masks
%000100 constant mSS      	( PB2 - pin 10 )
%001000 constant mMOSI  	( PB3 - pin 11 )
%010000 constant mMISO  	( PB4 - pin 12 )
%100000 constant mSCK   	( PB5 - pin 13 )
$80     constant mSPIF
$40     constant mWCOL


: setBitmask ; ( bitmask port -- )

: clrBitmask ; ( bitmask port -- )

: testBitmask ; ( bitmask port -- flag )

: spi.init ( -- )
  mSCK ddrb setBitmask 		\ SCK as output
  mSCK portb clrBitmask 		\ clock idles low
  mMOSI ddrb setBitmask 		\ MOSI as output
  mMISO ddrb clrBitmask 		\ MISO as input
  mMISO portb setBitmask 		\ activate pull -up on MISO
  mSS ddrb setBitmask  			\ SS as output
  mSS portb setBitmask  		\ deselect
  $51 spcr c!  					\ enable as master with cpolarity 0, cphase 0, fosc /16
  $00 spsr c! 					\ SPI2X =0 for fosc /16
  spsr c@ drop spdr c@ drop 		\ will clear SPIF
;

: spi.wait ( -- )
  begin mSPIF spsr testBitmask until 
;



> Op 17 jun. 2019, om 21:31 heeft Matthias Trute <mt...@we...> het volgende geschreven:
> 
> Hi Jan,
> 
>> I need to do a  bitmask on register.
> 
> The simplest operations are the ones documented
> in the source file
> 
> \ Use it this way:
> \ PORTD 7 portpin: PD.7  ( define portD pin #7)
> \ PD.7 high              ( turn portD pin #7 on, i.e. set it high-
> level)
> \ PD.7 low               ( turn portD pin #7 off, i.e. set it low-
> level)
> \ PD.7 <ms> pulse        ( turn portD pin #7 for <ms> high and low)
> \ the following words are for "real" IO pins only
> \ PD.7 pin_output        ( set DDRD so that portD pin #7 is output)
> \ PD.7 pin_input         ( set DDRD so that portD pin #7 is input)
> \ PD.7 pin_high?         ( true if pinD pin #7 is high)
> \ PD.7 pin_low?          ( true if pinD pin #7 is low)
> \ 
> 
> These word use only one bit.
> 
>> In bitnames.frt there is a word bitmask: How can I use it to do
>> the two actions above?
> 
> Note that the hex coding is used (a single F means $f)
> 
> \ multi bit operation
> \ PORTD F bitmask: PD.F  ( define the lower nibble of port d )
> \ PD.F pin@              ( get the lower nibble bits )
> \ 5 PD.F pin!            ( put the lower nibble bits, do not change the
> others )
> 
> A bitmask operates on all bits that are 1 in the bitmask. All others
> are unaffected, c! would overwrite all bits.
> 
> Matthias
> 
> _______________________________________________
> Amforth-devel mailing list for http://amforth.sf.net/
> Amf...@li...
> https://lists.sourceforge.net/lists/listinfo/amforth-devel

Re: [Amforth] Broken turnkey example [documentation]

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

Hello Peter,

> This was also to automate as much as...

I use amforth-shell.py to automate the process of loading AmForth files
onto the mcu. I use OS X, so I don't know if it will work on Windows, but
I find it indispensable.

http://amforth.sourceforge.net/TG/recipes/Upload.html?highlight=amforth%20shell

Kind regards,

Tristan