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