flashforth-devel

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

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

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"?

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

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

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

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

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

Hi Mikael,
	I've been caught by the fuses before so I pay pretty good attention to them.
	I'm doing the chip programming in AS7 because I've already got it up for the SAM development projects.
	This one's for an ATTiny84A but doing the sensor testing driven from that little bugger would be a pain.  Thus the Arduino.
	I had a horrifying thought as I go back through the Forth development file weeding out the dead stuff,  Is there a potential problem calling a word using for-next from inside another word's for-next?  I do that in reading the data packet.
	The code. Here's what I've tested out so far:

\ Buss I/O Port Declarations

$010b constant portl          \ Output Latch; Input Pull-Up

$010a constant ddrl           \ Data Direction Reg: "1" is OUTPUT

$0109 constant pinl           \ Pin Input Read; Pin Output Toggle



\ Buss Referencing Constants -- defines CLK & DAT usages

$ff constant cHdH   \ both

$aa constant cHdL   \ Clk-bits

$55 constant cLdH   \ Dat-bits

$00 constant cLdL   \ neither

\ Buss Pin Selections

%00000011 constant bus#1

%00001100 constant bus#2

%00110000 constant bus#3

%11000000 constant bus#4



\ Buss Mask Registers -- define Current Buss Selection; default ALL

cHdH value CHDH 

cHdL value CHDL 

cLdH value CLDH 

cLdL value CLDL 



\ SHT3x Sensor Address & Command Usage

$89 value Raddr     \ Addr $44 shifted left with READ-bit set

$88 value Waddr     \ Addr $44 shifted left with WRITE-bit clear

$24 value NOckst    \ cmdHI no clock stretch

$00 value HIacur    \ cmdLO high accuracy read



\ SHT3x Data Packet in Stacked Order

variable rhCRC

variable rhuLO

variable rhuHI

variable tmCRC

variable tmpLO

variable tmpHI

\ data display working variables

variable t-raw

variable h-raw

variable tempF

variable tempC

variable Humid



\ Buss Selection Words

: busset

    dup cHdH and to CHDH

    dup cHdL and to CHDL

        cLdH and to CLDH

;

: bus1  bus#1 busset ;

: bus2  bus#2 busset ;

: bus3  bus#3 busset ;

: bus4  bus#4 busset ;



: I2cINIT 

    hex ram

\ Init RAM VALUE registers after powerup

    cHdH to CHDH 

    cHdL to CHDL 

    cLdH to CLDH 

    cLdL to CLDL 

    $89 to Raddr

    $88 to Waddr

    $24 to NOckst

    $00 to HIacur

\ release port to external pullups

    $00 portl c!

    $00 ddrl c!

;



\ Short Delays

: dly1  ( c -- ) for [ nop, ] next ;



\ I2c Function Blocks =====================================

\ Buss Acquire by pulling DAT to low before CLK to low

: START   ( -- )

    CLDL portl c!  CLDL ddrl c! [ nop, ]    \ START

                CLDH ddrl c! CHDH ddrl c!   \ START

;

\ Buss Release by releasing CLK to high before DAT to high

: STOP    ( -- )

    CLDL portl c! CHDH ddrl c! [ nop, ]             \ STOP

    CLDH ddrl c@ and ddrl c! [ nop, ] CLDL ddrl c!  \ STOP

;

\ 9-th bit clocked with Master releasing DAT; ACK if stays low

: ACKIN   ( -- f )    \ 0 from Slave is ACK otherwise NACK

    CHDL ddrl c@ and ddrl c!

    CLDH ddrl c@ and ddrl c! $1 dly1 

    pinl c@ CHDH ddrl c! CLDH and          \ (N)ACK on stack

;

\ 9-th bit after reading slave byte low to ACK & continue

: DOACK  ( -- )    \ send ACK to slave

    CHDL ddrl c@ and ddrl c!          \ pull clk LO

    CHDH ddrl c! CLDH ddrl c! $6 dly1 \ dat LO then clk HI

    CHDH ddrl c! CHDL ddrl c! $6 dly1 \ clk LO then dat LO

;

\ 9-th bit after reading slave byte high to NACK & stop

: DONACK   ( -- )    \ send NACK to slave

    CHDL ddrl c@ and ddrl c!          \ pull clk LO

    CHDL ddrl c! CLDL ddrl c! $3 dly1 \ dat HI then clk HI

    CHDL ddrl c! CHDL ddrl c!         \ clk LO then dat LO

;

\ write a byte to Slave & get ACK/NACK back

: MWBYTE   ( c -- f )

    $8 for

      dup $80 and if CHDL ddrl c@ and ddrl c!

                else CLDH ddrl c@  or ddrl c!

                then \ data set

      CLDH ddrl c@ and ddrl c! 1 lshift

      CHDL ddrl c@  or ddrl c! next drop  \ bit-out & cleanup

    \ get Slave ACK

    CHDL ddrl c@ and ddrl c!

    CLDH ddrl c@ and ddrl c! $1 dly1 

    pinl c@ CHDH ddrl c! CLDH and          \ (N)ACK on board

;

\ read byte from Slave; ACK-bit not included...

: MRBYTE    ( -- c )

    0 ( r@ ) $8 for     \ stack 0 for result & get 8 bits

      CLDL ddrl c!      \ release clk & dat lines

      $1 lshift         \ shift result left

      pinl c@           \ read dat

      CHDL ddrl c!      \ pull clk LO

      CLDH and          \ mask out clk from read

      if 1+ else 0 + then   \ accumulate latest bit

    next

;

\ Send Sensor One-Shot-Reading command; return ACK/NACK

: wrSHT3x   ( -- f )

    START Waddr MWBYTE

      0= if NOckst MWBYTE

        0= if HIacur MWBYTE

        then

      then

    STOP

;

\ Read Data Packet from Sensor if ACK on stack

: rdSHT3x   ( f -- n n n n n n )

    START Raddr MWBYTE         \ addr w Read-bit

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

        MRBYTE DONACK                \ NACK last

      then

    STOP

;



\ stash read data packet from stack

: rstow   ( n n n n n n -- ) 

    rhCRC c!    rhuLO c!    rhuHI c!

    tmCRC c!    tmpLO c!    tmpHI c!

;

\ dump data packet bytes in Sensor Output order

: rdump cr    ( -- )

    tmpHI @ . tmpLO @ . tmCRC @ . 

    rhuHI @ . rhuLO @ . rhCRC @ . 

;





	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

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

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

On 2021-04-03 20:50, craig bair via Flashforth-devel wrote:
> Hi Mikael,
> 
> 	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 ;

Compiles and runs fine on my atmega2560. I replaced both .rdump and 
.read with rdump.
Assuming just typos in the mail.

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

There is no such risk on the Atmegas, and for..next do nest until the 
stack is full.

You could run SEE on TRY and see if it decompiles nicely.
There is always a risk of bad flash bits.
FF verifies the flash writes, but you never know.

Mikael

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

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

Fascinating...  Well I just discovered that I haven't got a spare arduino here at home, so I'll either have to run back up to work to try that or wait till Monday.
Do you have any special things added on top of the base install?  I put in core, arrays, forget, math, bits, and asm (not asm2).
craig








 On Saturday, April 3, 2021, 02:38:20 PM EDT, Mikael Nordman <mik...@fl...> wrote:





 On 2021-04-03 20:50, craig bair via Flashforth-devel wrote:
> Hi Mikael,
>
>     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 ;

Compiles and runs fine on my atmega2560. I replaced both .rdump and
.read with rdump.
Assuming just typos in the mail.

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

There is no such risk on the Atmegas, and for..next do nest until the
stack is full.

You could run SEE on TRY and see if it decompiles nicely.
There is always a risk of bad flash bits.
FF verifies the flash writes, but you never know.

Mikael


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

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

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

I loaded see core math bits asm and you stuff.

wrSHT3x drop 1 ms rdSHT3x rstow rdump
0 0 0 0 0 0  ok<$,ram>
: try wrSHT3x drop 1 ms rdSHT3x rstow rdump ;  ok<$,ram>
try
0 0 0 0 0 0  ok<$,ram>
see try
51a8 df8f      rcall wrSHT3x
51aa 9189      ld r24 y+
51ac 9199      ld r25 y+
51ae 940f f120 call 1
51b2 940f f849 call ms
51b6 dfa0      rcall rdSHT3x
51b8 dfbe      rcall rstow
51ba 940d a8b1 jmp rdump
  ok<$,ram>


On 2021-04-03 21:52, craig bair via Flashforth-devel wrote:
> Fascinating...  Well I just discovered that I haven't got a spare
> arduino here at home, so I'll either have to run back up to work to
> try that or wait till Monday.
> Do you have any special things added on top of the base install?  I
> put in core, arrays, forget, math, bits, and asm (not asm2).
> craig

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

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

In earlier experiments I found that the command write with the packet read worked in a word but not when I added the  rstow.
The ACK failure from not having a sensor online shouldn't actually run through everything but i'ld expect an SP? from rstow over-popping the stack.
I'll have to do an "empty" and reload everything to make sure artifacts aren't hanging on from my hacking around.

Thanks again,
craig





 On Saturday, April 3, 2021, 03:24:00 PM EDT, Mikael Nordman <mik...@fl...> wrote:





 I loaded see core math bits asm and you stuff.

wrSHT3x drop 1 ms rdSHT3x rstow rdump
0 0 0 0 0 0  ok<$,ram>
: try wrSHT3x drop 1 ms rdSHT3x rstow rdump ;  ok<$,ram>
try
0 0 0 0 0 0  ok<$,ram>
see try
51a8 df8f      rcall wrSHT3x
51aa 9189      ld r24 y+
51ac 9199      ld r25 y+
51ae 940f f120 call 1
51b2 940f f849 call ms
51b6 dfa0      rcall rdSHT3x
51b8 dfbe      rcall rstow
51ba 940d a8b1 jmp rdump
  ok<$,ram>


On 2021-04-03 21:52, craig bair via Flashforth-devel wrote:
> Fascinating...  Well I just discovered that I haven't got a spare
> arduino here at home, so I'll either have to run back up to work to
> try that or wait till Monday.
> Do you have any special things added on top of the base install?  I
> put in core, arrays, forget, math, bits, and asm (not asm2).
> craig


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

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

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

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

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.

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
  

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

[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

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