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