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

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 422-6466

 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