flashforth-devel — FlashForth users and developers

Re: [Flashforth-devel] Arduino Classic character LCD display drive

[Christopher H. <chr...@li...>]

Hi, for the legally aware: are you treating this as "trivial code", or
did you want to attach a license to it? For the small size of the
project, Apache 2.0 might be appropriate: 
https://www.apache.org/licenses/LICENSE-2.0.html
Christopher Howard

-----Original Message-----
From: craig bair via Flashforth-devel <
fla...@li...>
Reply-To: craig bair <dab...@ya...>
To: fla...@li...
Subject: [Flashforth-devel] Arduino Classic character LCD display drive
Date: Thu, 22 Apr 2021 17:39:11 +0000 (UTC)

Hi there.    Wow, and I thought I tried to do crazy stuff in
FlashForth... Recursion?
    I've landed in a pile of classic Arduinos and been asked to come up
with some I2c based programs for sensor simulation and production board
testing.  Having little or no regard for the 'Duino psudeo-C and its
environment and performance, of course I turned to FlashForth.  I'm
happy to report that a wide spectrum of Mega2560, UNO-r3, and Pro-Mini
versions all seem to run the "FlashForth 5 ATmega328 18.11.2020" and
"FlashForth 5 ATmega2560  18.11.2020" hex binaries just fine for me so
I haven't had to try recompiling (grin).
    I can also report that the  i2c-base-avr  performs well at reading
the SHT31 temperature/humidity sensors, but since there's only a polled
master mode, I'm trying to port the TWI_Master/Slave Interrupt code out
of C.  I'll let you know how that goes.
    What I discovered along the way was that the  mt128.fs  code, as
elegantly opaque as it looks, probably won't work for driving the 16x2
char LCD displays that I've got laying around.  The ATmega328 doesn't
even have 8 pins in PortC.  Neither the UNO or the ProMini have a port
with 8 pins that are free to use unless one feels like stealing the
UART pins from PortD.  It seemed reasonable to shoot for compatability
with the old LCD-Keypad Shields so I took a Sainsmart v1.0 as my guide
but ignored the buttons and gave the  R/W  line a pin in case I wanted
to read back from it. (People have been known to steal the unused
display ram for temporary storage in a pinch.)
    Not feeling comfortable with AVR assembler yet, I rewrote it in
more conventional forth.  It's not as sophisticated as what I did in
one of the Pic18 projects, but is a good functional starting point for
this class of display.  Feel free to have your way with it if it's
useful to you and post any problems you have with it.  I make no claim
of having torture-tested every possible thing that can be done to it.
    Enjoy.    craig
bair_______________________________________________Flashforth-devel
mailing lis...@li...
https://lists.sourceforge.net/lists/listinfo/flashforth-devel

Re: [Flashforth-devel] Arduino Classic character LCD display drive

[BK N. <bkn...@gm...>]

Great projects, in four bit mode, an lcd driven by the hitachi hd44780 
driver, needs only 7 pins. I put the data pins on one port and the 
enable, r/w, r/s on any other available pins. works like a champ, they 
don't need to be all on one port.
<https://en.wikipedia.org/wiki/Hitachi_HD44780_LCD_controller>

Brian-in-ohio

On 4/22/21 1:39 PM, craig bair via Flashforth-devel wrote:
> Hi there.
>      Wow, and I thought I tried to do crazy stuff in FlashForth... Recursion?
>
>      I've landed in a pile of classic Arduinos and been asked to come up with some I2c based programs for sensor simulation and production board testing.  Having little or no regard for the 'Duino psudeo-C and its environment and performance, of course I turned to FlashForth.  I'm happy to report that a wide spectrum of Mega2560, UNO-r3, and Pro-Mini versions all seem to run the "FlashForth 5 ATmega328 18.11.2020" and "FlashForth 5 ATmega2560  18.11.2020" hex binaries just fine for me so I haven't had to try recompiling (grin).
>
>      I can also report that the  i2c-base-avr  performs well at reading the SHT31 temperature/humidity sensors, but since there's only a polled master mode, I'm trying to port the TWI_Master/Slave Interrupt code out of C.  I'll let you know how that goes.
>
>      What I discovered along the way was that the  mt128.fs  code, as elegantly opaque as it looks, probably won't work for driving the 16x2 char LCD displays that I've got laying around.  The ATmega328 doesn't even have 8 pins in PortC.  Neither the UNO or the ProMini have a port with 8 pins that are free to use unless one feels like stealing the UART pins from PortD.  It seemed reasonable to shoot for compatability with the old LCD-Keypad Shields so I took a Sainsmart v1.0 as my guide but ignored the buttons and gave the  R/W  line a pin in case I wanted to read back from it. (People have been known to steal the unused display ram for temporary storage in a pinch.)
>
>      Not feeling comfortable with AVR assembler yet, I rewrote it in more conventional forth.  It's not as sophisticated as what I did in one of the Pic18 projects, but is a good functional starting point for this class of display.  Feel free to have your way with it if it's useful to you and post any problems you have with it.  I make no claim of having torture-tested every possible thing that can be done to it.
>
>      Enjoy.
>      craig bair
>
>
> _______________________________________________
> Flashforth-devel mailing list
> Fla...@li...
> https://lists.sourceforge.net/lists/listinfo/flashforth-devel

Re: [Flashforth-devel] jumping without a return

[Mikael N. <mik...@fl...>]

What I meant to ask was if the the cross function tail jump works when
using eval("foo") at the tail ? 

On 2021-04-22 19:35, Christopher Howard wrote:

> It works fine so long as the procedure call is at the end of calling procedure. Scheme standard guarantees tail call optimization. In other cases you might get a return stack overflow. 
> 
> When you define the first of the two procedures, you get a warning that the other procedure might not be defined. Or at least this is how it works in Guile scheme: 
> 
> scheme@(guile-user)> (define (foo) (display "|") (sleep 1) (bar)) 
> ;;; <stdin>:13:38: warning: possibly unbound variable `bar' 
> scheme@(guile-user)> (define (bar) (display "-") (sleep 1) (foo))

[Flashforth-devel] Arduino Classic character LCD display drive

[craig b. <dab...@ya...>]

Hi there.
    Wow, and I thought I tried to do crazy stuff in FlashForth... Recursion?

    I've landed in a pile of classic Arduinos and been asked to come up with some I2c based programs for sensor simulation and production board testing.  Having little or no regard for the 'Duino psudeo-C and its environment and performance, of course I turned to FlashForth.  I'm happy to report that a wide spectrum of Mega2560, UNO-r3, and Pro-Mini versions all seem to run the "FlashForth 5 ATmega328 18.11.2020" and "FlashForth 5 ATmega2560  18.11.2020" hex binaries just fine for me so I haven't had to try recompiling (grin).

    I can also report that the  i2c-base-avr  performs well at reading the SHT31 temperature/humidity sensors, but since there's only a polled master mode, I'm trying to port the TWI_Master/Slave Interrupt code out of C.  I'll let you know how that goes.

    What I discovered along the way was that the  mt128.fs  code, as elegantly opaque as it looks, probably won't work for driving the 16x2 char LCD displays that I've got laying around.  The ATmega328 doesn't even have 8 pins in PortC.  Neither the UNO or the ProMini have a port with 8 pins that are free to use unless one feels like stealing the UART pins from PortD.  It seemed reasonable to shoot for compatability with the old LCD-Keypad Shields so I took a Sainsmart v1.0 as my guide but ignored the buttons and gave the  R/W  line a pin in case I wanted to read back from it. (People have been known to steal the unused display ram for temporary storage in a pinch.)

    Not feeling comfortable with AVR assembler yet, I rewrote it in more conventional forth.  It's not as sophisticated as what I did in one of the Pic18 projects, but is a good functional starting point for this class of display.  Feel free to have your way with it if it's useful to you and post any problems you have with it.  I make no claim of having torture-tested every possible thing that can be done to it.

    Enjoy.
    craig bair

Re: [Flashforth-devel] jumping without a return

[Christopher H. <chr...@li...>]

It works fine so long as the procedure call is at the end of calling
procedure. Scheme standard guarantees tail call optimization. In other
cases you might get a return stack overflow.

When you define the first of the two procedures, you get a warning that
the other procedure might not be defined. Or at least this is how it
works in Guile scheme:

scheme@(guile-user)> (define (foo) (display "|") (sleep 1) (bar))
;;; <stdin>:13:38: warning: possibly unbound variable `bar'
scheme@(guile-user)> (define (bar) (display "-") (sleep 1) (foo))

scheme@(guile-user)> (foo)
|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|...

-----Original Message-----
From: Mikael Nordman <mik...@fl...>
To: Christopher Howard <chr...@li...>
Cc: fla...@li...
Subject: Re: [Flashforth-devel] jumping without a return
Date: Thu, 22 Apr 2021 19:20:07 +0300



Does the mutual recursion example really work in Scheme ?
BR Mikael

Re: [Flashforth-devel] jumping without a return

[Mikael N. <mik...@fl...>]

You can use value or defer for mutual recursion.

flash 0 value foo  ok<$,flash>
flash 0 value bar  ok<$,flash>
:noname ." foo " bar execute ; is foo  ok<$,ram>
:noname ." bar " foo execute ; is bar  ok<$,ram>

bar execute<enter>

bar foo bar foo bar foo bar foo bar foo bar foo
bar foo bar foo bar foo bar foo bar foo bar foo
bar foo bar foo bar foo bar foo bar foo bar foo bar foo bar foo

Goes on forever.

foo dis<enter>
3ab2 940e 035f call (s"
3ab6 6604
3ab8 6f6f
3aba 0320
3abc 940e 0351 call type
3ac0 dff4      rcall bar
3ac2 940c 01a0 jmp execute

bar dis<enter>
3ac6 940e 035f call (s"
3aca 6204
3acc 7261
3ace 0320
3ad0 940e 0351 call type
3ad4 dfe3      rcall foo
3ad6 940c 01a0 jmp execute

This also works with defer instead of value.

flash defer foo  ok<$,flash>
flash defer bar  ok<$,flash>
:noname ." foo " bar ; is foo  ok<$,ram>
:noname ." bar " foo ; is bar  ok<$,ram>

bar<enter>

bar foo bar foo bar foo bar foo bar foo bar foo bar foo
bar foo bar foo bar foo bar foo bar foo bar foo bar foo
bar foo bar foo bar foo bar foo bar foo bar foo

Goes on forever.

Calling foo or bar in the middle of the word would overflow the return 
stack.

Like in Scheme you can tail jump yourself using FlashForth.

: foo ( n -- ) dup . 1+ dup 100 = if drop exit then foo ;

It is equivalent to using begin and again.

: foo ( n -- ) begin dup . 1+ dup 100 =  if drop exit then again ;

The stuff with evaluate will not work in FlashForth without blowing the 
return stack.
Evaluate and interpret would make calls using the return stack.

Does the mutual recursion example really work in Scheme ?

BR Mikael

On 2021-04-22 16:51, Christopher Howard wrote:
> The goal is to make a call to the function /without/ growing the return
> stack. An example would be tail call optimization in a language like
> scheme. In that specific example, you would be calling the same
> function recursively, but the optimization would prevent you from
> growing the return stack. It would also be helpful for things like
> mutual recursion. E.g., in gforth:
> 
> : foo 124 emit s" bar" evaluate ;
> : bar 43 emit s" foo" evaluate ;

Re: [Flashforth-devel] jumping without a return

[Christopher H. <chr...@li...>]

The goal is to make a call to the function /without/ growing the return
stack. An example would be tail call optimization in a language like
scheme. In that specific example, you would be calling the same
function recursively, but the optimization would prevent you from
growing the return stack. It would also be helpful for things like
mutual recursion. E.g., in gforth:

: foo 124 emit s" bar" evaluate ;
: bar 43 emit s" foo" evaluate ;

This does not work however, because the return stack quickly overflows.
However, if I had another version of execute, which worked exactly like
execute normally does, but does not place a return value on the stack,
then it would work.

: foo 124 emit s" ' bar myexecute" evaluate ;
: bar 43 emit s" ' foo myexecute" evaluate ;

I have not seen that forth has a built-in word for this, but thought
maybe you knew how it could be done with other ff5-specific words.

-- 
Christopher Howard
blog: https://librehacker.com
social: https://gnusocial.club/librehacker

On Thu, 2021-04-22 at 14:36 +0300, Mikael Nordman wrote:
> I am not sure what you are after, but the Forth way is to use
> EXECUTE. If you give an address to EXECUTE
> on the parameter stack, the code execution will continue at that
> address.
> 
> 12 ok<$,ram> 12 
> 2+ ok<$,ram> 14 
> ' 2+ ok<$,ram> 14 15b8 
> execute ok<$,ram> 16
> 
> Any other solution must revert to ATmega assembler to compile a jmp
> or ijmp.
> 
> In order to not break the Forth there must by a return address on the
> stack. That gets you back to after the address where EXECUTE was
> executed.
> 
> What do you want to achieve ?
> 
> On 2021-04-22 04:06, Christopher Howard wrote:
> 
> > Hi, I was wondering if in FlashForth there was some trick to
> > execute a word without throwing anything on the return stack? Kind
> > of like you would with a tail call recursion, but in any arbitrary
> > place? It looks like there are some jumping instructions in ff5
> > reference but I don't understand how to use them. I'm thinking in
> > avr context if that makes a difference.
> >  
> > Christopher Howard
> 
> _______________________________________________
> Flashforth-devel mailing list
> Fla...@li...
> https://lists.sourceforge.net/lists/listinfo/flashforth-devel

Re: [Flashforth-devel] jumping without a return

[Mikael N. <mik...@fl...>]

I am not sure what you are after, but the Forth way is to use EXECUTE.
If you give an address to EXECUTE
on the parameter stack, the code execution will continue at that
address. 

12 ok<$,ram> 12 
2+ ok<$,ram> 14 
' 2+ ok<$,ram> 14 15b8 
execute ok<$,ram> 16 

Any other solution must revert to ATmega assembler to compile a jmp or
ijmp. 

In order to not break the Forth there must by a return address on the
stack. That gets you back to after the address where EXECUTE was
executed. 

What do you want to achieve ? 

On 2021-04-22 04:06, Christopher Howard wrote:

> Hi, I was wondering if in FlashForth there was some trick to execute a word without throwing anything on the return stack? Kind of like you would with a tail call recursion, but in any arbitrary place? It looks like there are some jumping instructions in ff5 reference but I don't understand how to use them. I'm thinking in avr context if that makes a difference. 
> 
> Christopher Howard

[Flashforth-devel] jumping without a return

[Christopher H. <chr...@li...>]

Hi, I was wondering if in FlashForth there was some trick to execute a
word without throwing anything on the return stack? Kind of like you
would with a tail call recursion, but in any arbitrary place? It looks
like there are some jumping instructions in ff5 reference but I don't
understand how to use them. I'm thinking in avr context if that makes a
difference.

Christopher Howard

Re: [Flashforth-devel] hex files

[BK N. <bkn...@gm...>]

fixed it, wrong fuse setting thanks for the quick response.

Brian-in-ohio

On 4/21/21 3:05 PM, Mikael Nordman wrote:
> Hard to say. I use the UNO all the time.
> Maybe you have the wrong serial speed setting ?
> It should be 38400 baud.
>
> /Mikael
>
> On 2021-04-21 20:35, BK Navarette wrote:
>> I uploaded the hex files to a knockoff arduino nano and it works fine.
>> When I upload the same file to an genuine arduino uno I get no
>> response at the serial terminal. I did change to the correct tty (USB0
>> for the nano ACM0 for the uno) any ideas why its not working?
>
>
> _______________________________________________
> Flashforth-devel mailing list
> Fla...@li...
> https://lists.sourceforge.net/lists/listinfo/flashforth-devel

Re: [Flashforth-devel] hex files

[Mikael N. <mik...@fl...>]

Hard to say. I use the UNO all the time.
Maybe you have the wrong serial speed setting ?
It should be 38400 baud.

/Mikael

On 2021-04-21 20:35, BK Navarette wrote:
> I uploaded the hex files to a knockoff arduino nano and it works fine.
> When I upload the same file to an genuine arduino uno I get no
> response at the serial terminal. I did change to the correct tty (USB0
> for the nano ACM0 for the uno) any ideas why its not working?

[Flashforth-devel] hex files

[BK N. <bkn...@gm...>]

I uploaded the hex files to a knockoff arduino nano and it works fine. 
When I upload the same file to an genuine arduino uno I get no response 
at the serial terminal. I did change to the correct tty (USB0 for the 
nano ACM0 for the uno) any ideas why its not working?

thanks Brian-in-ohio

Re: [Flashforth-devel] building flashforth with avra?

[Christopher H. <chr...@li...>]

Thank you. I am hoping to play around with this in the next week or so
during some lunch break. 
Christopher
-----Original Message-----From: Mikael Nordman <
mik...@fl...>To: Christopher Howard <
chr...@li...>Subject: Re: [Flashforth-devel] building
flashforth with avra?Date: Fri, 16 Apr 2021 09:13:57 +0300

Hi Chris,
Here is the verbose output of building with XC8.
BR Mikael

CLEAN SUCCESSFUL (total time: 82ms)
make -f nbproject/Makefile-default.mk SUBPROJECTS= .build-conf
make[1]: Entering directory '/home/mikael/ff/avr/mchip1.X'
make  -f nbproject/Makefile-default.mk
dist/default/production/mchip1.X.production.hex
make[2]: Entering directory '/home/mikael/ff/avr/mchip1.X'
"/opt/microchip/xc8/v2.32/bin/xc8-cc" -c  -mcpu=ATmega328P  -x
assembler-with-cpp -D__ATmega328P__    -O0 -funsigned-char -funsigned-
bitfields -I"../src" -v -Wall -DXPRJ_default=default  -gdwarf-3 -Wa,
--defsym=__MPLAB_BUILD=1   -MD -MP -MF
"build/default/production/_ext/1360937237/ff-xc8.o.d" -MT
"build/default/production/_ext/1360937237/ff-xc8.o.d" -MT
build/default/production/_ext/1360937237/ff-xc8.o -o
build/default/production/_ext/1360937237/ff-xc8.o  ../src/ff-xc8.asm 
/opt/microchip/xc8/v2.32/avr/bin/avr-gcc @/tmp/xcXIIDODB.cmd [ -c
-mmcu=atmega328p -x assembler-with-cpp -D__ATmega328P__ -O0 -funsigned-
char -funsigned-bitfields -I../src -v -Wall -DXPRJ_default=default
-gdwarf-3 -Wa,--defsym=__MPLAB_BUILD=1 -MD -MP -MF
build/default/production/_ext/1360937237/ff-xc8.o.d -MT
build/default/production/_ext/1360937237/ff-xc8.o.d -MT
build/default/production/_ext/1360937237/ff-xc8.o
-obuild/default/production/_ext/1360937237/ff-xc8.o ../src/ff-xc8.asm
-Wl,--info-linker -mdevice=atmega328p -mconst-data-in-progmem
-mdfp=/opt/microchip/xc8/v2.32/dfp/xc8 -D__XC -D__XC8 -D__XC__
-D__XC8__ -D__XC8_VERSION=2320 ]
Using built-in specs.
Reading specs from /opt/microchip/xc8/v2.32/dfp/xc8/avr/device-
specs/specs-atmega328p
COLLECT_GCC=/opt/microchip/xc8/v2.32/avr/bin/avr-gcc
Target: avr
Configured with: /home/toolsbuild/workspace/xc8-avr-
gcc/src/gcc/configure CFLAGS='-Os -g0 -I
/home/toolsbuild/workspace/xc8-avr-gcc/avr8-gnu-toolchain-linux_x86_64-
hostlibs/include/libxml2
-DMCHP_XCLM_SHA256_DIGEST=1c9650392a44b34ccfd84f998b692a608aac687e614c1
ae66f6fd1791578e752
-DMCHP_FXCLM_SHA256_DIGEST=8727ea3da9bdd624fee0130eb6133188719892bcbee7
da32606911a8b08a1a8d  -I /home/toolsbuild/workspace/xc8-avr-gcc/avr8-
gnu-toolchain-linux_x86_64-hostlibs/include/' CXXFLAGS='-I
/home/toolsbuild/workspace/xc8-avr-gcc/avr8-gnu-toolchain-linux_x86_64-
hostlibs/include/libxml2
-DMCHP_XCLM_SHA256_DIGEST=1c9650392a44b34ccfd84f998b692a608aac687e614c1
ae66f6fd1791578e752
-DMCHP_FXCLM_SHA256_DIGEST=8727ea3da9bdd624fee0130eb6133188719892bcbee7
da32606911a8b08a1a8d  -I /home/toolsbuild/workspace/xc8-avr-gcc/avr8-
gnu-toolchain-linux_x86_64-hostlibs/include/' LDFLAGS=-
L/home/toolsbuild/workspace/xc8-avr-gcc/avr8-gnu-toolchain-
linux_x86_64-hostlibs/lib CPPFLAGS= --target=avr --host=x86_64-pc-
linux-gnu --build=x86_64-pc-linux-gnu --
prefix=/home/toolsbuild/workspace/xc8-avr-gcc/avr8-gnu-toolchain-
linux_x86_64 --libdir=/home/toolsbuild/workspace/xc8-avr-gcc/avr8-gnu-
toolchain-linux_x86_64/lib --enable-languages=c,c++ --with-dwarf2 --
enable-doc --disable-shared --disable-libada --disable-libssp --
disable-nls --with-avrlibc=yes --with-
mpfr=/home/toolsbuild/workspace/xc8-avr-gcc/avr8-gnu-toolchain-
linux_x86_64-hostlibs --with-gmp=/home/toolsbuild/workspace/xc8-avr-
gcc/avr8-gnu-toolchain-linux_x86_64-hostlibs --with-
mpc=/home/toolsbuild/workspace/xc8-avr-gcc/avr8-gnu-toolchain-
linux_x86_64-hostlibs --with-
pkgversion=AVR_8_bit_GNU_Toolchain_3.6.6_293 --with-bugurl=
http://www.microchip.com
Thread model: single
gcc version 5.4.0 (AVR_8_bit_GNU_Toolchain_3.6.6_293) 
COLLECT_GCC_OPTIONS='-c'  '-D' '__ATmega328P__' '-O0' '-funsigned-char' 
'-funsigned-bitfields' '-I' '../src' '-v' '-Wall' '-D'
'XPRJ_default=default' '-gdwarf-3' '-MD' '-MP' '-MF'
'build/default/production/_ext/1360937237/ff-xc8.o.d' '-MT'
'build/default/production/_ext/1360937237/ff-xc8.o.d' '-MT'
'build/default/production/_ext/1360937237/ff-xc8.o' '-o'
'build/default/production/_ext/1360937237/ff-xc8.o' '-
mdevice=atmega328p' '-mconst-data-in-progmem'  '-D' '__XC' '-D' '__XC8'
'-D' '__XC__' '-D' '__XC8__' '-D' '__XC8_VERSION=2320' '-mpack-
dir=/opt/microchip/xc8/v2.32/dfp/xc8' '-B'
'/opt/microchip/xc8/v2.32/dfp/xc8/avr/' '-I'
'/opt/microchip/xc8/v2.32/dfp/xc8/avr/include' '-B'
'/opt/microchip/xc8/v2.32/dfp/xc8/avr/lib' '-specs=device-specs/specs-
atmega328p' '-mmcu=avr5' '-mdevice=atmega328p'
 /opt/microchip/xc8/v2.32/avr/bin/../libexec/gcc/avr/5.4.0/cc1 -E
-lang-asm -quiet -v -I ../src -I
/opt/microchip/xc8/v2.32/dfp/xc8/avr/include -imultilib avr5/memx-const 
-iprefix /opt/microchip/xc8/v2.32/avr/bin/../lib/gcc/avr/5.4.0/
-isystem /opt/microchip/xc8/v2.32/dfp/xc8/avr/include -MD
build/default/production/_ext/1360937237/ff-xc8.d -MF
build/default/production/_ext/1360937237/ff-xc8.o.d -MP -MT
build/default/production/_ext/1360937237/ff-xc8.o.d -MT
build/default/production/_ext/1360937237/ff-xc8.o -D__AVR_ATmega328P__
-D__AVR_DEVICE_NAME__=atmega328p -D__AVR_DEV_LIB_NAME__=m328p -D
__ATmega328P__ -D XPRJ_default=default -D __XC -D __XC8 -D __XC__ -D
__XC8__ -D __XC8_VERSION=2320 ../src/ff-xc8.asm -mn-flash=1 -mno-skip-
bug -mdevice=atmega328p -mconst-data-in-progmem -mpack-
dir=/opt/microchip/xc8/v2.32/dfp/xc8 -mmcu=avr5 -mdevice=atmega328p
-Wall -funsigned-char -funsigned-bitfields -gdwarf-3 -fworking-
directory -O0 -fno-directives-only -o /tmp/cclHrIj6.s
ignoring nonexistent directory
"/opt/microchip/xc8/v2.32/avr/bin/../lib/gcc/avr/5.4.0/../../../../avr/
sys-include"
ignoring duplicate directory
"/opt/microchip/xc8/v2.32/avr/bin/../lib/gcc/../../lib/gcc/avr/5.4.0/in
clude"
ignoring duplicate directory
"/opt/microchip/xc8/v2.32/avr/bin/../lib/gcc/../../lib/gcc/avr/5.4.0/in
clude-fixed"
ignoring nonexistent directory
"/opt/microchip/xc8/v2.32/avr/bin/../lib/gcc/../../lib/gcc/avr/5.4.0/..
/../../../avr/sys-include"
ignoring duplicate directory
"/opt/microchip/xc8/v2.32/avr/bin/../lib/gcc/../../lib/gcc/avr/5.4.0/..
/../../../avr/include"
ignoring duplicate directory
"/opt/microchip/xc8/v2.32/dfp/xc8/avr/include"
  as it is a non-system directory that duplicates a system directory
#include "..." search starts here:
#include <...> search starts here:
 ../src
 /opt/microchip/xc8/v2.32/dfp/xc8/avr/include
 /opt/microchip/xc8/v2.32/avr/bin/../lib/gcc/avr/5.4.0/include
 /opt/microchip/xc8/v2.32/avr/bin/../lib/gcc/avr/5.4.0/include-fixed
 /opt/microchip/xc8/v2.32/avr/bin/../lib/gcc/avr/5.4.0/../../../../avr/
include
End of search list.
COLLECT_GCC_OPTIONS='-c'  '-D' '__ATmega328P__' '-O0' '-funsigned-char' 
'-funsigned-bitfields' '-I' '../src' '-v' '-Wall' '-D'
'XPRJ_default=default' '-gdwarf-3' '-MD' '-MP' '-MF'
'build/default/production/_ext/1360937237/ff-xc8.o.d' '-MT'
'build/default/production/_ext/1360937237/ff-xc8.o.d' '-MT'
'build/default/production/_ext/1360937237/ff-xc8.o' '-o'
'build/default/production/_ext/1360937237/ff-xc8.o' '-
mdevice=atmega328p' '-mconst-data-in-progmem'  '-D' '__XC' '-D' '__XC8'
'-D' '__XC__' '-D' '__XC8__' '-D' '__XC8_VERSION=2320' '-mpack-
dir=/opt/microchip/xc8/v2.32/dfp/xc8' '-B'
'/opt/microchip/xc8/v2.32/dfp/xc8/avr/' '-I'
'/opt/microchip/xc8/v2.32/dfp/xc8/avr/include' '-B'
'/opt/microchip/xc8/v2.32/dfp/xc8/avr/lib' '-specs=device-specs/specs-
atmega328p' '-mmcu=avr5' '-mdevice=atmega328p'
 /opt/microchip/xc8/v2.32/avr/bin/../lib/gcc/avr/5.4.0/../../../../avr/
bin/as --gdwarf2 -mmcu=avr5 -mno-skip-bug --defsym=__MPLAB_BUILD=1 -o
build/default/production/_ext/1360937237/ff-xc8.o /tmp/cclHrIj6.s
COMPILER_PATH=/opt/microchip/xc8/v2.32/dfp/xc8/avr/:/opt/microchip/xc8/
v2.32/dfp/xc8/avr/lib/:/opt/microchip/xc8/v2.32/avr/bin/../libexec/gcc/
avr/5.4.0/:/opt/microchip/xc8/v2.32/avr/bin/../libexec/gcc/:/opt/microc
hip/xc8/v2.32/avr/bin/../lib/gcc/avr/5.4.0/../../../../avr/bin/
LIBRARY_PATH=/opt/microchip/xc8/v2.32/dfp/xc8/avr/lib/avr5/memx-
const/:/opt/microchip/xc8/v2.32/avr/bin/../lib/gcc/avr/5.4.0/avr5/memx-
const/:/opt/microchip/xc8/v2.32/avr/bin/../lib/gcc/avr/5.4.0/../../../.
./avr/lib/avr5/memx-
const/:/opt/microchip/xc8/v2.32/dfp/xc8/avr/:/opt/microchip/xc8/v2.32/d
fp/xc8/avr/lib/:/opt/microchip/xc8/v2.32/avr/bin/../lib/gcc/avr/5.4.0/:
/opt/microchip/xc8/v2.32/avr/bin/../lib/gcc/:/opt/microchip/xc8/v2.32/a
vr/bin/../lib/gcc/avr/5.4.0/../../../../avr/lib/
COLLECT_GCC_OPTIONS='-c'  '-D' '__ATmega328P__' '-O0' '-funsigned-char' 
'-funsigned-bitfields' '-I' '../src' '-v' '-Wall' '-D'
'XPRJ_default=default' '-gdwarf-3' '-MD' '-MP' '-MF'
'build/default/production/_ext/1360937237/ff-xc8.o.d' '-MT'
'build/default/production/_ext/1360937237/ff-xc8.o.d' '-MT'
'build/default/production/_ext/1360937237/ff-xc8.o' '-o'
'build/default/production/_ext/1360937237/ff-xc8.o' '-
mdevice=atmega328p' '-mconst-data-in-progmem'  '-D' '__XC' '-D' '__XC8'
'-D' '__XC__' '-D' '__XC8__' '-D' '__XC8_VERSION=2320' '-mpack-
dir=/opt/microchip/xc8/v2.32/dfp/xc8' '-B'
'/opt/microchip/xc8/v2.32/dfp/xc8/avr/' '-I'
'/opt/microchip/xc8/v2.32/dfp/xc8/avr/include' '-B'
'/opt/microchip/xc8/v2.32/dfp/xc8/avr/lib' '-specs=device-specs/specs-
atmega328p' '-mmcu=avr5' '-mdevice=atmega328p'
Using built-in specs.
Reading specs from /opt/microchip/xc8/v2.32/dfp/xc8/avr/device-
specs/specs-atmega328p
COLLECT_GCC=/opt/microchip/xc8/v2.32/avr/bin/avr-gcc
COLLECT_LTO_WRAPPER=/opt/microchip/xc8/v2.32/avr/bin/../libexec/gcc/avr
/5.4.0/lto-wrapper
Target: avr
Configured with: /home/toolsbuild/workspace/xc8-avr-
gcc/src/gcc/configure CFLAGS='-Os -g0 -I
/home/toolsbuild/workspace/xc8-avr-gcc/avr8-gnu-toolchain-linux_x86_64-
hostlibs/include/libxml2
-DMCHP_XCLM_SHA256_DIGEST=1c9650392a44b34ccfd84f998b692a608aac687e614c1
ae66f6fd1791578e752
-DMCHP_FXCLM_SHA256_DIGEST=8727ea3da9bdd624fee0130eb6133188719892bcbee7
da32606911a8b08a1a8d  -I /home/toolsbuild/workspace/xc8-avr-gcc/avr8-
gnu-toolchain-linux_x86_64-hostlibs/include/' CXXFLAGS='-I
/home/toolsbuild/workspace/xc8-avr-gcc/avr8-gnu-toolchain-linux_x86_64-
hostlibs/include/libxml2
-DMCHP_XCLM_SHA256_DIGEST=1c9650392a44b34ccfd84f998b692a608aac687e614c1
ae66f6fd1791578e752
-DMCHP_FXCLM_SHA256_DIGEST=8727ea3da9bdd624fee0130eb6133188719892bcbee7
da32606911a8b08a1a8d  -I /home/toolsbuild/workspace/xc8-avr-gcc/avr8-
gnu-toolchain-linux_x86_64-hostlibs/include/' LDFLAGS=-
L/home/toolsbuild/workspace/xc8-avr-gcc/avr8-gnu-toolchain-
linux_x86_64-hostlibs/lib CPPFLAGS= --target=avr --host=x86_64-pc-
linux-gnu --build=x86_64-pc-linux-gnu --
prefix=/home/toolsbuild/workspace/xc8-avr-gcc/avr8-gnu-toolchain-
linux_x86_64 --libdir=/home/toolsbuild/workspace/xc8-avr-gcc/avr8-gnu-
toolchain-linux_x86_64/lib --enable-languages=c,c++ --with-dwarf2 --
enable-doc --disable-shared --disable-libada --disable-libssp --
disable-nls --with-avrlibc=yes --with-
mpfr=/home/toolsbuild/workspace/xc8-avr-gcc/avr8-gnu-toolchain-
linux_x86_64-hostlibs --with-gmp=/home/toolsbuild/workspace/xc8-avr-
gcc/avr8-gnu-toolchain-linux_x86_64-hostlibs --with-
mpc=/home/toolsbuild/workspace/xc8-avr-gcc/avr8-gnu-toolchain-
linux_x86_64-hostlibs --with-
pkgversion=AVR_8_bit_GNU_Toolchain_3.6.6_293 --with-bugurl=
http://www.microchip.com
Thread model: single
gcc version 5.4.0 (AVR_8_bit_GNU_Toolchain_3.6.6_293) 
COMPILER_PATH=/opt/microchip/xc8/v2.32/dfp/xc8/avr/:/opt/microchip/xc8/
v2.32/dfp/xc8/avr/lib/:/opt/microchip/xc8/v2.32/avr/bin/../libexec/gcc/
avr/5.4.0/:/opt/microchip/xc8/v2.32/avr/bin/../libexec/gcc/:/opt/microc
hip/xc8/v2.32/avr/bin/../lib/gcc/avr/5.4.0/../../../../avr/bin/
LIBRARY_PATH=/opt/microchip/xc8/v2.32/dfp/xc8/avr/lib/avr5/memx-
const/:/opt/microchip/xc8/v2.32/avr/bin/../lib/gcc/avr/5.4.0/avr5/memx-
const/:/opt/microchip/xc8/v2.32/avr/bin/../lib/gcc/avr/5.4.0/../../../.
./avr/lib/avr5/memx-
const/:/opt/microchip/xc8/v2.32/dfp/xc8/avr/:/opt/microchip/xc8/v2.32/d
fp/xc8/avr/lib/:/opt/microchip/xc8/v2.32/avr/bin/../lib/gcc/avr/5.4.0/:
/opt/microchip/xc8/v2.32/avr/bin/../lib/gcc/:/opt/microchip/xc8/v2.32/a
vr/bin/../lib/gcc/avr/5.4.0/../../../../avr/lib/
COLLECT_GCC_OPTIONS= '-D' 'XPRJ_default=default' '-O0' '-funsigned-
char' '-funsigned-bitfields' '-I' '../src' '-v' '-Wall' '-gdwarf-3' '-
nostartfiles' '-o' 'dist/default/production/mchip1.X.production.elf' '-
o' 'dist/default/production/mchip1.X.production.elf' '-
mdevice=atmega328p' '-mconst-data-in-progmem'  '-D' '__XC' '-D' '__XC8'
'-D' '__XC__' '-D' '__XC8__' '-D' '__XC8_VERSION=2320' '-mpack-
dir=/opt/microchip/xc8/v2.32/dfp/xc8' '-B'
'/opt/microchip/xc8/v2.32/dfp/xc8/avr/' '-I'
'/opt/microchip/xc8/v2.32/dfp/xc8/avr/include' '-B'
'/opt/microchip/xc8/v2.32/dfp/xc8/avr/lib' '-specs=device-specs/specs-
atmega328p' '-mmcu=avr5' '-mdevice=atmega328p'
 /opt/microchip/xc8/v2.32/avr/bin/../libexec/gcc/avr/5.4.0/collect2
-plugin
/opt/microchip/xc8/v2.32/avr/bin/../libexec/gcc/avr/5.4.0/liblto_plugin
.so -plugin-
opt=/opt/microchip/xc8/v2.32/avr/bin/../libexec/gcc/avr/5.4.0/lto-
wrapper -plugin-opt=-fresolution=/tmp/cczRqt3L.res -plugin-opt=-pass-
through=-lgcc -plugin-opt=-pass-through=-lm -plugin-opt=-pass-through=-
lc -plugin-opt=-pass-through=-latmega328p -mavr5 -Tdata 0x800100 -o
dist/default/production/mchip1.X.production.elf -o
dist/default/production/mchip1.X.production.elf
-L/opt/microchip/xc8/v2.32/dfp/xc8/avr/lib/avr5/memx-const
-L/opt/microchip/xc8/v2.32/avr/bin/../lib/gcc/avr/5.4.0/avr5/memx-const 
-L/opt/microchip/xc8/v2.32/avr/bin/../lib/gcc/avr/5.4.0/../../../../avr
/lib/avr5/memx-const -L/opt/microchip/xc8/v2.32/dfp/xc8/avr
-L/opt/microchip/xc8/v2.32/dfp/xc8/avr/lib
-L/opt/microchip/xc8/v2.32/avr/bin/../lib/gcc/avr/5.4.0
-L/opt/microchip/xc8/v2.32/avr/bin/../lib/gcc
-L/opt/microchip/xc8/v2.32/avr/bin/../lib/gcc/avr/5.4.0/../../../../avr
/lib -Map=dist/default/production/mchip1.X.production.map --
defsym=__MPLAB_BUILD=1 --memorysummary
dist/default/production/memoryfile.xml
build/default/production/_ext/1360937237/ff-xc8.o --start-group --end-
group --info-linker --start-group -lgcc -lm -lc -latmega328p --end-
group
"/opt/microchip/xc8/v2.32/bin/xc8-cc"  -mcpu=ATmega328P -Wl,-
Map=dist/default/production/mchip1.X.production.map 
-DXPRJ_default=default  -Wl,--defsym=__MPLAB_BUILD=1    -O0 -funsigned-
char -funsigned-bitfields -I"../src" -v -Wall -gdwarf-3
-nostartfiles      -Wl,
--memorysummary,dist/default/production/memoryfile.xml -o
dist/default/production/mchip1.X.production.elf  -o
dist/default/production/mchip1.X.production.elf 
build/default/production/_ext/1360937237/ff-xc8.o      -Wl,--start-
group  -Wl,--end-group 
/opt/microchip/xc8/v2.32/avr/bin/avr-gcc @/tmp/xcXpLeMMo.cmd [
-mmcu=atmega328p -Wl,-
Map=dist/default/production/mchip1.X.production.map
-DXPRJ_default=default -Wl,--defsym=__MPLAB_BUILD=1 -O0 -funsigned-char 
-funsigned-bitfields -I../src -v -Wall -gdwarf-3 -nostartfiles -Wl,
--memorysummary,dist/default/production/memoryfile.xml
-odist/default/production/mchip1.X.production.elf
-odist/default/production/mchip1.X.production.elf
build/default/production/_ext/1360937237/ff-xc8.o -Wl,--start-group
-Wl,--end-group -Wl,--info-linker -mdevice=atmega328p -mconst-data-in-
progmem -mdfp=/opt/microchip/xc8/v2.32/dfp/xc8 -D__XC -D__XC8 -D__XC__
-D__XC8__ -D__XC8_VERSION=2320 ]
Info: Loading file:
/opt/microchip/xc8/v2.32/avr/avr/bin/../lib/ldscripts/avr5.xn
"/opt/microchip/xc8/v2.32/bin"/avr-objcopy -O ihex
"dist/default/production/mchip1.X.production.elf"
"dist/default/production/mchip1.X.production.hex"
make[2]: Leaving directory '/home/mikael/ff/avr/mchip1.X'
make[1]: Leaving directory '/home/mikael/ff/avr/mchip1.X'

BUILD SUCCESSFUL (total time: 880ms)
Loading code from
/home/mikael/ff/avr/mchip1.X/dist/default/production/mchip1.X.productio
n.hex...
Program loaded with pack,ATmega_DFP,2.1.87,Microchip
Loading completed

Re: [Flashforth-devel] building flashforth with avra?

[Christopher H. <chr...@li...>]

After some work searching around and getting registered at their
Website, I was finally able to download source archive for XC8 2.31 at 
https://www.microchip.com/en-us/development-tools-tools-and-software/mplab-ecosystem-downloads-archive#Source%20Archives
. I don't know where are the sources for 2.32 - hopefully you are
getting them with the the 2.32 binaries. The 2.31 archive contains
modifications to avr-gcc. Hopefully that is all that I will need,
beside figuring out the build commands of course. If XC8 outputs a list
of avr-gcc calls that somebody could share, that would be helpful. I'm
hoping all the definitions used in ff-xc8.asm are contained entirely in
config-xc8.inc and avr-gcc toolchain but I've really got no idea at
this point.

Christopher

-----Original Message-----
From: Mikael Nordman <mik...@fl...>
To: fla...@li...
Subject: Re: [Flashforth-devel] building flashforth with avra?
Date: Thu, 15 Apr 2021 23:44:47 +0300


I do not have instructions. I need to publish the XC8 instructions,
have not done that yet.

You can try with the avr-gcc, but I believe it does not support the

.section .NRWW, code, address() directive.

Microchip stated the address() part was their addition to XC8, but you
can try.



On 2021-04-15 21:15, Christopher Howard wrote:

> Hi, for those not willing to use MPLABX/XC8, do you have any
> instructions on how to build with avr-gcc toolchain?
>  

_______________________________________________Flashforth-devel mailing
lis...@li...
https://lists.sourceforge.net/lists/listinfo/flashforth-devel

Re: [Flashforth-devel] building flashforth with avra?

[Mikael N. <mik...@fl...>]

I do not have instructions. I need to publish the XC8 instructions, have
not done that yet. 

You can try with the avr-gcc, but I believe it does not support the 

.section .NRWW, code, address() directive. 

Microchip stated the address() part was their addition to XC8, but you
can try. 

On 2021-04-15 21:15, Christopher Howard wrote:

> Hi, for those not willing to use MPLABX/XC8, do you have any instructions on how to build with avr-gcc toolchain?

Re: [Flashforth-devel] building flashforth with avra?

[Christopher H. <chr...@li...>]

Hi, for those not willing to use MPLABX/XC8, do you have any
instructions on how to build with avr-gcc toolchain?
Christopher
-----Original Message-----From: Mikael Nordman <
mik...@fl...>To: Christopher Howard <
chr...@li...>Cc: 
fla...@li...Subject: Re: [Flashforth-devel]
building flashforth with avra?Date: Tue, 30 Mar 2021 09:48:32 +0300
XC8 is based on the Gnu Compiler toolchain.There is a free licence with
the MPLABX and XC8 toolchains.
These are the binaries you get.$ ls
/opt/microchip/xc8/v2.32/avr/binavr-addr2line  avr-as   avr-
c++filt  avr-elfedit  avr-gcc        avr-gcc-ar  avr-gcc-ranlib  avr-
gcov-tool  avr-gdb-py  avr-ld      avr-man  avr-objcopy  avr-
ranlib   avr-size     avr-stripavr-ar         avr-c++  avr-
cpp      avr-g++      avr-gcc-5.4.0  avr-gcc-nm  avr-gcov        avr-
gdb        avr-gprof   avr-ld.bfd  avr-nm   avr-objdump  avr-
readelf  avr-strings
I have not looked for the source code. I do not need it.
If you do not want to use XC8 you can find prebuilt Gnu Compiler
toolchains on the internet.For example here 
https://gnutoolchains.com/avr/

BR Mikael
On 2021-03-29 23:28, Christopher Howard wrote:
> I'm a little confused -- I'm not seeing anything by way of source
> code or free software licensing for these projects. Is that something
> you get access to after getting the installers to run on your
> system...?
> -----Original Message-----From: Mikael Nordman <
> mik...@fl...>
> Inspired by this question, I started to re-write FlashForth for
> Atmega
> to compile with the Microchip MPLABX and XC8 compiler.

Re: [Flashforth-devel] questions re allot & dump

[Mikael N. <mik...@fl...>]

The marker word stores the dictionary pointers as data in itself, and
restores the pointers when the marker word is executed.
There are five pointers stored and restored. 

Try to use a count of at least $10. There is no output if the count is
smaller. 

hex 0 400 dump 

BR Mikael 

On 2021-04-14 00:30, Christopher Howard wrote:

> Hi, I had two question: 
> 
> (1) I was wondering how does FF know how much data section memory to deallocate when you delete words (with marker or empty)? Is a pointer value stored in marker words for this? 
> 
> (2) Is there something wrong with the `dump' word in E FlashForth 5 ATmega328 18.11.2020? I can't seem to get any output from it. 
> 
> Christopher Howard 
> _______________________________________________
> Flashforth-devel mailing list
> Fla...@li...
> https://lists.sourceforge.net/lists/listinfo/flashforth-devel

-- 
--
Mikael

Re: [Flashforth-devel] data sections

[Mikael N. <mik...@fl...>]

Christopher, 

The allot mechanism is intended for static memory allocation. 

You would need to implement allocate and free yourself in some static
area reserved by allot 

There is a system variable called CSE that tells which is the current
data section. But there is no word to read it.
It is really not needed. The intended use is to always return to ram
after eeprom or flash has been used. 

i, is used for creating new compiler words, but it is just a short cut
for 'flash , ram' 

Actually ',' could always use the flash context, there is not much use
for creating constant data in ram or eeprom.
But to keep the symmetry of the memory management words, ',' can be used
for ram and eeprom also. 

Mikael 

On 2021-04-13 01:44, Christopher Howard wrote:

> Hi, I'm kind of new to forth in general, so bear with me: but I see in FF the effect of `,' and `c,' and `allot' are affected by which data section is set. I was wondering if there was a way in FF to determine what data section is currently set, so you could restore that setting after changing it. The use case I was thinking of would be if I had a word which temporarily allots some array space in ram to perform some matrix calculations or whatever. My word can't really assume that data section is already pointing to ram. But if I set it to point to ram, I might be destroying the previous state. 
> 
> I see in the reference that there is a special word 'i,' for allot'ing just to flash data section, but I also see there aren't words like 'r,' or 'rallot'. 
> _______________________________________________
> Flashforth-devel mailing list
> Fla...@li...
> https://lists.sourceforge.net/lists/listinfo/flashforth-devel

-- 
--
Mikael

[Flashforth-devel] questions re allot & dump

[Christopher H. <chr...@li...>]

Hi, I had two question:

(1) I was wondering how does FF know how much data section memory to
deallocate when you delete words (with marker or empty)? Is a pointer
value stored in marker words for this?

(2) Is there something wrong with the `dump' word in E FlashForth 5
ATmega328 18.11.2020? I can't seem to get any output from it.

Christopher Howard

[Flashforth-devel] data sections

[Christopher H. <chr...@li...>]

Hi, I'm kind of new to forth in general, so bear with me: but I see in
FF the effect of `,' and `c,' and `allot' are affected by which data
section is set. I was wondering if there was a way in FF to determine
what data section is currently set, so you could restore that setting
after changing it. The use case I was thinking of would be if I had a
word which temporarily allots some array space in ram to perform some
matrix calculations or whatever. My word can't really assume that data
section is already pointing to ram. But if I set it to point to ram, I
might be destroying the previous state.

I see in the reference that there is a special word 'i,' for allot'ing
just to flash data section, but I also see there aren't words like 'r,'
or 'rallot'.

Re: [Flashforth-devel] building flashforth with avra?

[Mikael N. <mik...@fl...>]

Peter, sorry for my slow response.

FF Atmega is now transformed to be compiled with MPLABX and XC8.

Does ASCIIDOC require some server side support? I am not familiar with 
it.

It seems all peripherals, including flash and eeprom, are different on 
the 4809.
Maybe you have an eager student to take on the task ?

BR Mikael

On 2021-03-28 13:49, Peter Jacobs wrote:
> Mikael,
> It would be interesting to have FF running on Atmega4809.  I bought a
> few of those thinking that I would come back to doing some FF-related
> work this year (2021). It has been a while since I have had any time
> to play, so part of my plans included a refresh of the tutorial
> documents, possibly into ASCIIDOC source form.   I expect that such a
> form would allow them to be more easily included on your web site and,
> also, that it would be easier to copy and paste code from them.
> Cheers,
> Peter J.

Re: [Flashforth-devel] building larger program words -- arduino mega2560 FF5

[Mikael N. <mik...@fl...>]

The MS word behaves exactly the same interactively and when compiled. 

The extra delays in interactive mode are caused by the interpreter
parsing the input and finding the words in the dictionary. 

Mikael 

On 2021-04-06 15:39, craig bair via Flashforth-devel wrote:

> I got it to work well enough yesterday that I sent it to the Test Group to use. Thanks for jogging my mind out of the rut it was going around in. The problems were all timing related and come back to not observing the behavior of the "ms" word closely enough. It behaves VERY differently inside a program word than it does in interactive mode. The 27+ milliseconds that it takes interactively is moore than enough for the sensor to complete its highest resolution data conversion. The portion of a millisecond till a tick occurs inside a larger word is far too short. The sensor NACKs until data conversion completes and I'm now allowing 17 msec plus whatever portion comes through in the first one. Good data every time as long as I wait a bit before switching sensors. The rate of change in the environment chamber is relatively slow compared to sampling 4 sensors round-robin one per second.

Re: [Flashforth-devel] building larger program words -- arduino mega2560 FF5

[Mikael N. <mik...@fl...>]

Craig, 

FF used to have a long first millisecond. As do many other Forths. 

But then there was a complaint ( by Stefan I think) that 

: test ticks 100 for 1 ms next ticks swap - . ; 

took 200 ms. So I changed the first millisecond to be short. 

Maybe a long first millisecond is actually better, at least you are
guaranteed 1 millisecond. 

BR Mikael 

On 2021-04-06 15:39, craig bair via Flashforth-devel wrote:

> Hi Mikael,
> Just a note that I'm not used to getting short 1 millisecond times. GCC (and my own timing routines) synchronize on the first ms tick and start decrementing on the next one so they run a long 1 millisecond instead. Not a problem once noticed, but curse-me-for-a-novice for not paying attention to details (grin).

Re: [Flashforth-devel] building larger program words -- arduino mega2560 FF5

[craig b. <dab...@ya...>]

 Hi, Stefan,
 I got it to work well enough yesterday that I sent it to the Test Group to use. Thanks for jogging my mind out of the rut it was going around in. The problems were all timing related and come back to not observing the behavior of the "ms" word closely enough. It behaves VERY differently inside a program word than it does in interactive mode. The 27+ milliseconds that it takes interactively is moore than enough for the sensor to complete its highest resolution data conversion. The portion of a millisecond till a tick occurs inside a larger word is far too short. The sensor NACKs until data conversion completes and I'm now allowing 17 msec plus whatever portion comes through in the first one. Good data every time as long as I wait a bit before switching sensors. The rate of change in the environment chamber is relatively slow compared to sampling 4 sensors round-robin one per second.

Hi Mikael,
 Just a note that I'm not used to getting short 1 millisecond times. GCC (and my own timing routines) synchronize on the first ms tick and start decrementing on the next one so they run a long 1 millisecond instead. Not a problem once noticed, but curse-me-for-a-novice for not paying attention to details (grin).


THANKS FOR THE HELP, guys!

 Next problem is to do the interrupt-driven I2c Slave protocol in a 'duino Pro Mini... Ain't we got fun.

craig


     On Monday, April 5, 2021, 04:26:31 PM EDT, Stefan <fli...@gm...> wrote:  
 
 Hi Craig,

If I enter at the prompt:
        wrSHT3x drop 1 ms rdSHT3x rstow .rdump
    It reads the sensor and dumps the packet bytes as nicely as you please.
    If I define a word...
        : try wrSHT3x drop 1 ms rdSHT3x rstow .read ;

    ...and enter  try<ret>  it sends the command to the sensor, immediately sends other junk out and blows up.


I think the problem is to come out with a NACK from MWBYTE in rdSHT3x:
you'll have an empty stack before going into rstow. That happens if you
ask for the results before they're ready. That is because of '1 ms'
beeing to short (in the compiled version).

\ Read Data Packet from Sensor if ACK on stack

: rdSHT3x  (  0 -- n n n n n n )
            ( -1 -- )          \ !!!!!!

    START Raddr MWBYTE        \ addr w Read-bit

      0= if $5 for MRBYTE DOACK next \ ACK bytes

        MRBYTE DONACK                \ NACK last

      else                      \ to do, if read command is NACK-ed
        ??????
        ??????

      then

    STOP

;

greetz bitflipser


Am 05.04.2021 um 01:25 schrieb craig bair via Flashforth-devel:
> Hi Stephan,
>
> These are prebuilt sensor modules and though the chip allows a second address, it's unavailable.  That would still give me only two and we need to compare at least four at a time.
> I2c dates back to before processor chips could supply any current via pins, so it's designed to operate with pull-down only.  My attempt to use the AVR pullups rather than external 6.2k resistors proved unreliable.
> The ms bug, annoying as it is isn't a problem, the SHT31 is VERY forgiving about wait time before reading back. One experiment had 150 msec between command and read and it was fine.
>
> Mikael,
>
> I did an "empty" and started over.  I've got my basic survival extras (without the vt100 emu) in a file so I can just run it into the system first thing.  I then loaded in the part I posted and that went ok.  I added the routines to convert the raw data to temp&Humidity numbers then cold restarted it.  It announces its system & compile date then the next line says "ESC" the cursor stays there and nothing else comes out.  The led blips with each entered keystroke, but nothing seems to be happening.  I'll probably have to wipe it and run the systen .HEX file into it when I get back to work in the morning.  I think I'll set up a second duino as a backup at the same time.
>
> Just thought of something, I'll try chucking another "empty" down its throat and see if it's just the tx that gets pooched.
>
> Bonsai.
> craig
>
>
>
>
>
>
>
>  On Sunday, April 4, 2021, 02:41:38 AM EDT, Stefan <fli...@gm...> wrote:
>
>
>
>
>
>  Hi Craig,
>
> maybe the problem is the '1 ms' you're giving the sensor to deliver.
> The difference between entering at the prompt and using a defined word
> is, that the line at the prompt has to be interpreted, which takes much
> more time as runnig the compiled one.
> When I take a look at the data sheet, I find measurement times from 2,5
> ms up to 15 ms - so your compiled version polls the sensor before beeing
> ready (and it (probably) repeats a "NACK"), while the prompted version
> seems to give it enough time.
>
> By the way: I'm confused and amazed by the way you use the
> DataDirectionRegister to transmit the data over the lines. Good job!
> Nevertheless I ask myself, why you do not use the hardware TWI of the
> Arduino?
> In your first mail you wrote:
>
> They're I2c interfaced and all have the same buss address.
>
> That's not quite right. The SHT31 has an 'ADDR'-pin, making it possible
> to switch the address it's assigned to between $44 and $45. According to
> the datasheet that pin can be used to handle multiple SHT31-sensors on
> the same bus (Sensirion Datasheet SHT3x-DIS: chapter 3.4). I think it's
> like handling a 'chip select'-line.
>
> greets bitflipser
>
> Am 03.04.2021 um 19:50 schrieb craig bair via Flashforth-devel:
>> ...
>>
>>
>>
>>
>>      If I enter at the prompt:
>>          wrSHT3x drop 1 ms rdSHT3x rstow .rdump
>>      It reads the sensor and dumps the packet bytes as nicely as you please.
>>      If I define a word...
>>          : try wrSHT3x drop 1 ms rdSHT3x rstow .read ;
>>
>>      ...and enter  try<ret>  it sends the command to the sensor, immediately sends other junk out and blows up.
>>
>>      I remember in the PIC18-s if a word definition got too long sometimes the relative branching would mess up, but I thought I had avoided that in this case.  Maybe I just haven't figured out AVR-8-bit yet.  Shrugs.
>>      Anyway, If you notice anything, please feel free to castigate me (grin).
>>
>> Thanks greatly,
>> craig
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>    On Saturday, April 3, 2021, 12:18:59 PM EDT, Mikael Nordman <mik...@fl...> wrote:
>>
>>
>>
>>
>>
>>    Hi Craig,
>> Really hard to say unless you show the full code.
>>
>> There is a configuration fuses that divides the clock by 8,
>> maybe that makes your ticks run slower.
>>
>> Here are the correct fuse settings
>> avrdude -p m2560 -c stk500 -P /dev/ttyACM0 -e -u -U
>> flash:w:../hex/2560-16MHz-38400.hex:i -U efuse:w:0xff:m -U
>> hfuse:w:0xdc:m -U lfuse:w:0xff:m
>>
>> I sent you my address, where are those boards you wanted to send to me?
>> Maybe my mail went in to the spam bin.
>>
>> I have just about ported FF to XC8, and next would be to take a stab at
>> at the Atmega 4809 or some other of the new microchip architecture
>> chips.
>>
>> BR Mikael
>>
>> On 2021-04-03 17:27, craig bair via Flashforth-devel wrote:
>>> Hi again,
>>>
>>>        As usual I'm trying to do something in Forth that may be slightly
>>> insane.  We need to do simultaneous testing of some SHT31
>>> Temperature/Humidity sensors in an environment chamber.  They're I2c
>>> interfaced and all have the same buss address.  And they handed me a
>>> 'Duino Mega 2560...  Of course I said "FlashForth! I've been
>>> bit-banging I2c since the early '90-s, how hard could it be?".
>>>
>>>        Well building the pieced was pretty smooth, basic I2c Master comes
>>> down to 6 routines that can be combined to do pretty much everything
>>> you need.  These sensors want to be written a 2 byte command, given a
>>> millisecond to do their thing, and read out a 6 byte data packet.
>>> Simple enough, and all of the parts work just fine.  I use  a single
>>> port for 4 clock lines, 4 data lines, and a ram value system to change
>>> which line pair gets used at any given time.  No problem till I try to
>>> roll the whole sequence into something that can run as a program and
>>> spew data till the environmental chamber boils over.  Then it blows
>>> up, the delay between operations disappears, and communication breaks
>>> down.
>>>
>>>        I'm an old PIC programmer and not really well informed about
>>> ATMEGA internals.  I'm guessing that somewhere a stack overflows, a
>>> system variable gets clobbered, or a branch instruction gets compiled
>>> in that winds up crossing some boundary it shouldn't...  Or something
>>> else.
>>>
>>> (Oh and just for reference I'm running the most recent
>>> 2560-16MHz-38400.hex  out of the box on an old-school Arduino brand
>>> Mega2560...  and according to my 'scope "ms" is running over 20x
>>> slower than it advertises.)
>>>
>>>        I noticed oddly similar things in PIC18 FlashForth, but I was
>>> playing around in the interrupts as well.  I understand the PIC
>>> assembler well enough to make some good guesses about what needed
>>> restructured.
>>>
>>>        If anyone has any pointers to offer about how to build larger
>>> convoluted routines to run for hours (or days), I could use some ATMEL
>>> insights on what to look for.  Any guesses about what pit (hiding in
>>> my blind spot) I might be tripping into would be greatly appreciated.
>>>
>>> Thanks for your attention,
>>> craig bair
>>>
>>> OBTW: Why does the spellcheck want to replace "atmel" with "oatmeal"?
>>>
>>>
>>>
>>> _______________________________________________
>>> Flashforth-devel mailing list
>>> Fla...@li...
>>> https://lists.sourceforge.net/lists/listinfo/flashforth-devel
>> --
>> --
>> Mikael
>>
>>
>> _______________________________________________
>> Flashforth-devel mailing list
>> Fla...@li...
>> https://lists.sourceforge.net/lists/listinfo/flashforth-devel
>
> _______________________________________________
> Flashforth-devel mailing list
> Fla...@li...
> https://lists.sourceforge.net/lists/listinfo/flashforth-devel

  

Re: [Flashforth-devel] building larger program words -- arduino mega2560 FF5

[craig b. <dab...@ya...>]

 Mikael,
I've never had a good relationship with the turnkey... Couldn't break into it so I've wiped the duino and started over.
I'm keeping log files of the loads and grepping them for questionmarks. (grin) Taking 7-8 minutes to run them in in previous projects has made me cautious.
The ms variables all check out so far. I'm only using constants to load ram variables and ram values.
Flash should only be getting written when loading my source files in or hacking around trying to debug... I guess that's a pretty big hole... I'll see.

Gotta get back on it and see what I can clear up.

Thanks again,
craig


     On Sunday, April 4, 2021, 11:38:45 PM EDT, Mikael Nordman <mik...@fl...> wrote:  
 
 Craig,
The symptoms seems to point to that you are writing in to places you 
shud not.

When you upload your code. Are you sure there are no errors ?

"ESC" means there is a turnkey value greater than zero and less than 
$ffff.
Does it point somewhere meaningful ?

If your ms is too slow, you have written something into
$44(TCCR0A==2),$45(TCCR0B==3),$47(OCR0A==$f9) or $6e(TIMSK0==2)
Check that the values are as indicated above.
  hex 44 c@ 45 c@ 47 c@ 6e c@

Not reacting to incoming UART data can be caused by the RX0 interrupt 
vector being overwritten in ram.
But, it is inited in "warm" so probably it is OK.

Slowness in the code can also be caused by using a variable that is 
located in flash or eeprom.
That could wear them out quite fast.
I have a habit of using "fl-" in the beginning of my main word, it will 
lock
the flash and eeprom writes and restart FF in case there are attempts to 
write to either one.
In case you have code that that writes to flash or eeprom in a loop, the 
chip will start to malfunction,
as the memory wears out.

BR Mikael


On 2021-04-05 02:25, craig bair via Flashforth-devel wrote:
> I did an "empty" and started over.  I've got my basic survival extras
> (without the vt100 emu) in a file so I can just run it into the system
> first thing.  I then loaded in the part I posted and that went ok.  I
> added the routines to convert the raw data to temp&Humidity numbers
> then cold restarted it.  It announces its system & compile date then
> the next line says "ESC" the cursor stays there and nothing else comes
> out.  The led blips with each entered keystroke, but nothing seems to
> be happening.  I'll probably have to wipe it and run the systen .HEX
> file into it when I get back to work in the morning.  I think I'll set
> up a second duino as a backup at the same time.


_______________________________________________
Flashforth-devel mailing list
Fla...@li...
https://lists.sourceforge.net/lists/listinfo/flashforth-devel