Re: [Flashforth-devel] building larger program words -- arduino mega2560 FF5
Brought to you by:
oh2aun
Menu
▾
▴
Re: [Flashforth-devel] building larger program words -- arduino mega2560 FF5
|
From: craig b. <dab...@ya...> - 2021-04-03 17:51:06
|
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
|
