flashforth-devel Mailing List for FlashForth: for PIC and Atmega (Page 8)
Brought to you by:
oh2aun
Menu
▾
▴
flashforth-devel — FlashForth users and developers
You can subscribe to this list here.
| 2011 |
Jan
|
Feb
(22) |
Mar
(3) |
Apr
(4) |
May
(6) |
Jun
(8) |
Jul
|
Aug
(6) |
Sep
|
Oct
(20) |
Nov
(9) |
Dec
(4) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2012 |
Jan
(4) |
Feb
|
Mar
(5) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(5) |
Oct
(14) |
Nov
(1) |
Dec
|
| 2013 |
Jan
(4) |
Feb
(5) |
Mar
(4) |
Apr
(2) |
May
|
Jun
(29) |
Jul
(7) |
Aug
|
Sep
(20) |
Oct
(9) |
Nov
(2) |
Dec
(7) |
| 2014 |
Jan
|
Feb
(23) |
Mar
(113) |
Apr
(25) |
May
(31) |
Jun
(9) |
Jul
(47) |
Aug
(15) |
Sep
(1) |
Oct
(4) |
Nov
(8) |
Dec
(3) |
| 2015 |
Jan
(21) |
Feb
(1) |
Mar
(18) |
Apr
(16) |
May
(100) |
Jun
(33) |
Jul
|
Aug
(10) |
Sep
(8) |
Oct
(7) |
Nov
(5) |
Dec
|
| 2016 |
Jan
(12) |
Feb
(9) |
Mar
|
Apr
(7) |
May
(5) |
Jun
(9) |
Jul
(1) |
Aug
(2) |
Sep
(17) |
Oct
(3) |
Nov
|
Dec
|
| 2017 |
Jan
(6) |
Feb
(12) |
Mar
(9) |
Apr
(3) |
May
(7) |
Jun
|
Jul
(12) |
Aug
|
Sep
(13) |
Oct
|
Nov
|
Dec
(10) |
| 2018 |
Jan
(1) |
Feb
|
Mar
(7) |
Apr
(4) |
May
|
Jun
|
Jul
(3) |
Aug
|
Sep
(21) |
Oct
(3) |
Nov
|
Dec
|
| 2019 |
Jan
(5) |
Feb
(4) |
Mar
|
Apr
|
May
(3) |
Jun
(11) |
Jul
(4) |
Aug
(6) |
Sep
(3) |
Oct
|
Nov
(9) |
Dec
(7) |
| 2020 |
Jan
(2) |
Feb
(3) |
Mar
(2) |
Apr
|
May
|
Jun
|
Jul
|
Aug
(3) |
Sep
|
Oct
|
Nov
(4) |
Dec
|
| 2021 |
Jan
|
Feb
|
Mar
(8) |
Apr
(40) |
May
(12) |
Jun
|
Jul
|
Aug
(3) |
Sep
(3) |
Oct
(4) |
Nov
(10) |
Dec
(4) |
| 2022 |
Jan
(29) |
Feb
(7) |
Mar
(10) |
Apr
|
May
(3) |
Jun
(3) |
Jul
|
Aug
|
Sep
(1) |
Oct
|
Nov
(1) |
Dec
(6) |
| 2023 |
Jan
(8) |
Feb
|
Mar
(5) |
Apr
(9) |
May
(6) |
Jun
|
Jul
(1) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2024 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(3) |
Jun
|
Jul
(9) |
Aug
(7) |
Sep
(1) |
Oct
|
Nov
|
Dec
|
|
From: Mikael N. <mik...@fl...> - 2021-04-05 03:38:31
|
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. |
|
From: craig b. <dab...@ya...> - 2021-04-04 23:25:22
|
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 |
|
From: craig b. <dab...@ya...> - 2021-04-03 19:51:46
|
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 |
|
From: Mikael N. <mik...@fl...> - 2021-04-03 19:23:48
|
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 |
|
From: craig b. <dab...@ya...> - 2021-04-03 18:53:07
|
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 |
|
From: Mikael N. <mik...@fl...> - 2021-04-03 18:38:11
|
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 |
|
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
|
|
From: Mikael N. <mik...@fl...> - 2021-04-03 16:19:18
|
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 |
|
From: craig b. <dab...@ya...> - 2021-04-03 14:27:38
|
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"?
|
|
From: Mikael N. <mik...@fl...> - 2021-03-30 06:48:52
|
XC8 is based on the Gnu Compiler toolchain. There is a free licence with the MPLABX and XC8 toolchains. These are the binaries you get. $ ls /opt/microchip/xc8/v2.32/avr/bin avr-addr2line avr-as avr-c++filt avr-elfedit avr-gcc avr-gcc-ar avr-gcc-ranlib avr-gcov-tool avr-gdb-py avr-ld avr-man avr-objcopy avr-ranlib avr-size avr-strip avr-ar avr-c++ avr-cpp avr-g++ avr-gcc-5.4.0 avr-gcc-nm avr-gcov avr-gdb avr-gprof avr-ld.bfd avr-nm avr-objdump avr-readelf avr-strings I have not looked for the source code. I do not need it. If you do not want to use XC8 you can find prebuilt Gnu Compiler toolchains on the internet. For example here https://gnutoolchains.com/avr/ BR Mikael On 2021-03-29 23:28, Christopher Howard wrote: > I'm a little confused -- I'm not seeing anything by way of source code > or free software licensing for these projects. Is that something you > get access to after getting the installers to run on your system...? > > -----Original Message----- > From: Mikael Nordman <mik...@fl...> > > Inspired by this question, I started to re-write FlashForth for Atmega > > to compile with the Microchip MPLABX and XC8 compiler. |
|
From: Christopher H. <chr...@li...> - 2021-03-29 20:29:16
|
I'm a little confused -- I'm not seeing anything by way of source code or free software licensing for these projects. Is that something you get access to after getting the installers to run on your system...? -----Original Message----- From: Mikael Nordman <mik...@fl...> To: fla...@li... Subject: Re: [Flashforth-devel] building flashforth with avra? Date: Sun, 28 Mar 2021 12:36:05 +0300 Hi, Inspired by this question, I started to re-write FlashForth for Atmega to compile with the Microchip MPLABX and XC8 compiler. It is still coded in assembler. It already compiles. Need to sort out some linking details before it is ready. Getting FF working with XC8 would also enable use of FF in the new Atmega parts from Microchip. BR Mikael On 2021-03-25 23:27, Christopher Howard wrote: > Hi, is there anybody who has been able to build flashforth with avra > (https://github.com/Ro5bert/avra/tree/master/includes)? _______________________________________________Flashforth-devel mailing lis...@li... https://lists.sourceforge.net/lists/listinfo/flashforth-devel |
|
From: Christopher H. <chr...@li...> - 2021-03-29 17:06:45
|
I played around with it for about 2 hours last week, but haven't
figured it out. It seems that flashforth is expecting different
included files than what is provided by avra - with FF referencing
m328def.inc and m328pdef.inc, and avra providing only m328Pdef.inc. If
I edit file names on one side or the other I end up with strings of
errors like below. Some of the error messages are a bit confusing.
christopher@theoden ~/Repos/flashforth$ ../avra/src/avra -D ffm328 -D
op0 -I ../avra/includes/ -I avr/src/ -o avr/hex/328-16MHz-38400.hex -fI
avr/src/ff-atmega.asm AVRA: advanced AVR macro assembler (version
1.4.2)Pass 1...avr/src/config.inc(115) : Error : Found no
label/variable/constant named avr/src/macros.inc(39) : Warning : r26 is
already assigned to 'XL'!avr/src/macros.inc(40) : Warning : r27 is
already assigned to 'XH'!avr/src/macros.inc(41) : Warning : r30 is
already assigned to 'ZL'!avr/src/macros.inc(42) : Warning : r31 is
already assigned to 'ZH'!avr/src/ff-atmega.asm(38) : Error : Found no
label/variable/constant named avr/src/ff-atmega.asm(99) : Error :
Found no label/variable/constant named TX0_avr/src/ff-atmega.asm(100) :
Error : Found no label/variable/constant named RX0_avr/src/ff-
atmega.asm(101) : Error : Found no label/variable/constant named
RX0Qavr/src/ff-atmega.asm(463) : Error : Unknown mnemonic/macro:
fdw(exit_l)avr/src/ff-atmega.asm(471) : Error : Unknown
mnemonic/macro: fdw(idle_l)avr/src/ff-atmega.asm(4226) : Error :
[Macro: avr/src/macros.inc: 56:] Found no label/variable/constant named
UCSR1Aavr/src/ff-atmega.asm(4229) : Error : [Macro:
avr/src/macros.inc: 64:] Found no label/variable/constant named
UDR1avr/src/ff-atmega.asm(4254) : Error : [Macro: avr/src/macros.inc:
56:] Found no label/variable/constant named UCSR1Aavr/src/ff-
atmega.asm(4254) : [Macro: avr/src/macros.inc: 58:] Maximum error count
reached. Exiting...
-----Original Message-----From: Stefan <fli...@gm...>To:
Christopher Howard <chr...@li...>Subject: Re:
[Flashforth-devel] building flashforth with avra?Date: Sun, 28 Mar 2021
14:51:26 +0200
Hi Christopher,
could you solve your problem?
I cannot help you with avra-problem, 'cause I'm using AVR Studio
4.19.
But I am pretty sure, that there is no difference in definition
between ATmega328 and ATmega328p - the p(ico power)-version just
uses less energy.
greets
bitflipser
Am 25.03.2021 um 22:27 schrieb
Christopher Howard:
> Hi, is there anybody who has been able to build flashforth
> with avra (
> https://github.com/Ro5bert/avra/tree/master/includes)?
> If so, can you share your command line calls, and any source
> edits you had to make? In trying to build flashforth for
> m328p
> (or, i guess, m328...?), I'm running into some confusion.
> avra
> has a m328p definition file but not a m328. And the avr
> config.inc with FF is a bit confusing to me as it seems to
> include m328pdef.inc in all builds but only m328def.inc if
> ffm328 is definied. As I try to work it out on the command
> line
> I end up with basic stuff like portd not defined.
>
>
>
> I was trying to build FF without using any proprietary
> avrstudio components, and avra seemed the easiest path. I
> couldn't find any source for avrasm2 anywhere, but
> information
> on the internet was confusing, so maybe I missed something.
>
>
>
> Christopher
>
>
>
>
>
>
>
>
>
>
> _______________________________________________Flashforth-devel
> mailing lis...@li...
> https://lists.sourceforge.net/lists/listinfo/flashforth-devel
>
>
|
|
From: Peter J. <pe...@me...> - 2021-03-28 11:10:28
|
Mikael, It would be interesting to have FF running on Atmega4809. I bought a few of those thinking that I would come back to doing some FF-related work this year (2021). It has been a while since I have had any time to play, so part of my plans included a refresh of the tutorial documents, possibly into ASCIIDOC source form. I expect that such a form would allow them to be more easily included on your web site and, also, that it would be easier to copy and paste code from them. Cheers, Peter J. On 28/3/21 7:36 pm, Mikael Nordman wrote: > Hi, > > Inspired by this question, I started to re-write FlashForth for Atmega > to compile with the Microchip MPLABX and XC8 compiler. > > It is still coded in assembler. > > It already compiles. Need to sort out some linking details before it > is ready. > > Getting FF working with XC8 would also enable use of FF in the new > Atmega parts from Microchip. > > BR Mikael > > On 2021-03-25 23:27, Christopher Howard wrote: > >> Hi, is there anybody who has been able to build flashforth with avra >> (https://github.com/Ro5bert/avra/tree/master/includes)? > > > _______________________________________________ > Flashforth-devel mailing list > Fla...@li... > https://lists.sourceforge.net/lists/listinfo/flashforth-devel |
|
From: Mikael N. <mik...@fl...> - 2021-03-28 09:36:21
|
Hi, Inspired by this question, I started to re-write FlashForth for Atmega to compile with the Microchip MPLABX and XC8 compiler. It is still coded in assembler. It already compiles. Need to sort out some linking details before it is ready. Getting FF working with XC8 would also enable use of FF in the new Atmega parts from Microchip. BR Mikael On 2021-03-25 23:27, Christopher Howard wrote: > Hi, is there anybody who has been able to build flashforth with avra > (https://github.com/Ro5bert/avra/tree/master/includes)? |
|
From: Christopher H. <chr...@li...> - 2021-03-25 21:27:52
|
Hi, is there anybody who has been able to build flashforth with avra ( https://github.com/Ro5bert/avra/tree/master/includes)? If so, can you share your command line calls, and any source edits you had to make? In trying to build flashforth for m328p (or, i guess, m328...?), I'm running into some confusion. avra has a m328p definition file but not a m328. And the avr config.inc with FF is a bit confusing to me as it seems to include m328pdef.inc in all builds but only m328def.inc if ffm328 is definied. As I try to work it out on the command line I end up with basic stuff like portd not defined. I was trying to build FF without using any proprietary avrstudio components, and avra seemed the easiest path. I couldn't find any source for avrasm2 anywhere, but information on the internet was confusing, so maybe I missed something. Christopher |
|
From: Mikael N. <mik...@fl...> - 2021-03-23 05:01:26
|
Hi Christopher. You need to use hfuse 0xdc. That should do it. Like your experimenter web pages ! BR Mikael On 2021-03-22 23:45, Christopher Howard wrote: > Is there something I need to be doing different for the 2560? Different > fuse bit settings...? Has anybody run FF lately on 2560? |
|
From: Christopher H. <chr...@li...> - 2021-03-22 22:04:28
|
Hi, I've been able to install flashflorth on 328P, running on an Uno board, using avrdude to upload the 328-16MHz-38400.hex file. I was wanting to put flashforth also on a 2560 running on a Mega 2560 arduino board. I adapted the avrdude command I used for the 328P, to this command for the 2560: avrdude -c stk500v1 -p m2560 -P /dev/ttyUSB0 -b 19200 -e -u -U flash:w:2560-16MHz-38400.hex:i -U efuse:w:0xff:m -U hfuse:w:0xda:m -U lfuse:w:0xff:m avrdude seems to upload the code, and set all the fuses, without any trouble. However, when I connect to UART with ff-shell or with picocom, there seems to be no response from the chip. I can see on RX LED that the characters I'm sending are making it to the board, but nothing comes back on the TX LED. Is there something I need to be doing different for the 2560? Different fuse bit settings...? Has anybody run FF lately on 2560? Christopher |
|
From: <mik...@fl...> - 2020-11-22 20:01:26
|
<div dir='auto'>Hi Pete.<div dir="auto">Glad to hear you are still on it.</div><div dir="auto"><br></div><div dir="auto">I am going to update < and d<</div><div dir="auto">to work with the full range.</div><div dir="auto"><br></div><div dir="auto">BR Mike</div></div><div class="gmail_extra"><br><div class="gmail_quote">On 22 Nov 2020 19:10, Pete Zawasky <pza...@pz...> wrote:<br type="attribution" /><blockquote class="quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><p dir="ltr">Hi Mikael,<br> Hope all is well.  Just a quick note to let you know I still program <br> PIC18s with FF.<br> The 2020-11-18 latest release is working fine for my PIC18F6527 based <br> LCD boards.<br> Even assembled it with MPLAB IDE v8.92.<br> Thanks again for keeping FF up to date and available.<br> Pete<br></p> <p dir="ltr">_______________________________________________<br> Flashforth-devel mailing list<br> Fla...@li...<br> https://lists.sourceforge.net/lists/listinfo/flashforth-devel<br> </p> </blockquote></div><br></div> |
|
From: Pete Z. <pza...@pz...> - 2020-11-22 17:21:37
|
Hi Mikael, Hope all is well. Just a quick note to let you know I still program PIC18s with FF. The 2020-11-18 latest release is working fine for my PIC18F6527 based LCD boards. Even assembled it with MPLAB IDE v8.92. Thanks again for keeping FF up to date and available. Pete |
|
From: Mikael N. <mik...@fl...> - 2020-11-16 16:01:53
|
Hi Stefan. Thanks for your nice feedback. See my inline comments below. Great to hear about OptiForth. Is it on github ? BR Mikael On 2020-11-16 10:21, Stefan wrote: > a) '<', '>', 'min', 'max', 'd<' and 'd>' deliver wrong results, when > the > (signed) space overflows e.g. > 20.000 -20.000 < ok<#,ram> 65535 Do you have working code for this to share ? > b) 'digit?' accepts : ; < = > ? X Y Z [ \ ] ^ _ ` as regular digits > e.g. > 1[ ^ ` ok<#,ram> 14 7 9 Yes. I simplfied digit? a bit too much. In practice it works for legal number conversion. > c) 'ms' (u -- ) is counting u+1 milliseconds, e.g. 100 loops of 1 ms > last 200 ms > : testms ticks #100 begin 1 ms 1- dup 0= until drop ticks swap - ; > testms ok<#,ram> 200 Seems like a bug. I will check this. > > d) it's not a bug, but ... > by initializing all registers and RAM to zero the internal > oscillator (as the time basis > for FLASH and EEPROM programming) is set to the slowest possible > frequency, thereby almost > doubling the programming time, this can be avoided by saving the > value of OSCCAL > This was actually changed in the commit 4.11.2020. Now it only initializes RAM. Not the registers. > e) also not a bug, but ... > DP_TO_EEPROM is done wordwise, in many cases half the EEPROM writes > could be saved by > doing it bytewise, because the hi-bytes of the pointers are > unchanged > Good catch. I will change that. > with best regards > bitflipser > > PS: If you want to test my OptiForth328 called version, please let me > know. > > > > _______________________________________________ > Flashforth-devel mailing list > Fla...@li... > https://lists.sourceforge.net/lists/listinfo/flashforth-devel -- -- Mikael |
|
From: Stefan <fli...@gm...> - 2020-11-16 08:22:22
|
Hi Mikael,
FlashForth on Arduino Uno was my entry into the world of Forth and the
interactive programming and testing of microcontrollers. When comming
from assembler only (as I did) its a pleasure to have the direct access
and the modular building and testing capabilities. Well done. Many
thanks for that!
I'm working with FlashForth for a bit more than a year now, changed some
things to make it work faster and merged it with an OptiBoot-like
bootloader. Meanwhile I have some minor bugs to report:
a) '<', '>', 'min', 'max', 'd<' and 'd>' deliver wrong results, when the
(signed) space overflows e.g.
20.000 -20.000 < ok<#,ram> 65535
b) 'digit?' accepts : ; < = > ? X Y Z [ \ ] ^ _ ` as regular digits e.g.
1[ ^ ` ok<#,ram> 14 7 9
c) 'ms' (u -- ) is counting u+1 milliseconds, e.g. 100 loops of 1 ms
last 200 ms
: testms ticks #100 begin 1 ms 1- dup 0= until drop ticks swap - ;
testms ok<#,ram> 200
d) it's not a bug, but ...
by initializing all registers and RAM to zero the internal
oscillator (as the time basis
for FLASH and EEPROM programming) is set to the slowest possible
frequency, thereby almost
doubling the programming time, this can be avoided by saving the
value of OSCCAL
e) also not a bug, but ...
DP_TO_EEPROM is done wordwise, in many cases half the EEPROM writes
could be saved by
doing it bytewise, because the hi-bytes of the pointers are unchanged
with best regards
bitflipser
PS: If you want to test my OptiForth328 called version, please let me know.
|
|
From: craig b. <dab...@ya...> - 2020-08-11 15:07:40
|
Mikael,
If you've got a good mailing address, I've got a spare SNAP I could send you. They've got mostly the same capabilities as the PICkit-4 except for the plastic case and the high-voltage programming feature. They run the same firmware (and every version of MPLabX has its own).
A nice thing about these little boards is that they're laid out with 0.1" vias to match up with our old bread-boards. They're basically break-out boards for chips that might not have pdips available with a usb power supply (not quite thrilled with the debugger or the C compiler myself). What can I say, they're fun little toys and quick to try ideas with. Do you have any interest in the ATmega-4809 for porting work?
craig
On Tuesday, August 11, 2020, 10:02:08 AM EDT, Mikael Nordman <mik...@fl...> wrote:
Hi Craig,
I (almost) never used any evaluation boards from Mchip.
These are made by folks whose business is to sell evaluation boards and
demo apps.
I have own boards where I can plug in 20 and 28 pin PIC18/24/30/33 DIP
chips.
Glad I (FF) still has users.
Many go down the ARM and MeCrisp lane,
but I had never had the need for so much embedded processing power.
I like the simplicity of the PIC18 and PIC24 architectures.
Well, at least they are simple to me since I know them :-)
And I still build one off boards where DIP rules (bad eyesight).
Never tried MplabX 5.40 and from the sound of it seems I will not need
to either.
Or maybe one can use older mpasmx versions with it ?
I have not got around to supporting the PIC18Q43 chips yet. They require
changes in FF.
The flash writing is different, and the registers are moved to the
beginning of ram.
I have some of those chips, but PICKIT4 is required and I don't have one
(yet).
When I was looking for PICKIT4 it was in short supply due to COVID19.
BR Mike
_______________________________________________
Flashforth-devel mailing list
Fla...@li...
https://lists.sourceforge.net/lists/listinfo/flashforth-devel
|
|
From: Mikael N. <mik...@fl...> - 2020-08-11 14:01:38
|
Hi Craig, I (almost) never used any evaluation boards from Mchip. These are made by folks whose business is to sell evaluation boards and demo apps. I have own boards where I can plug in 20 and 28 pin PIC18/24/30/33 DIP chips. Glad I (FF) still has users. Many go down the ARM and MeCrisp lane, but I had never had the need for so much embedded processing power. I like the simplicity of the PIC18 and PIC24 architectures. Well, at least they are simple to me since I know them :-) And I still build one off boards where DIP rules (bad eyesight). Never tried MplabX 5.40 and from the sound of it seems I will not need to either. Or maybe one can use older mpasmx versions with it ? I have not got around to supporting the PIC18Q43 chips yet. They require changes in FF. The flash writing is different, and the registers are moved to the beginning of ram. I have some of those chips, but PICKIT4 is required and I don't have one (yet). When I was looking for PICKIT4 it was in short supply due to COVID19. BR Mike |
|
From: craig b. <dab...@ya...> - 2020-08-10 19:16:51
|
To anyone out there concerned (or amused), At the risk of sounding like a Microchip Shill, I've been collecting toys from their monthly Dev-Tool-Deals. Their Curiosity Nano Evaluation Kits retail at $15 and the MPLAB(R) Xpress Evaluation Boards go for $12, but the loss-leader deals knock 20-50% off. It tends to be enough to pay for the shipping or a little more. The boards have Microchip’s version of the Atmel debugger (from the X-plained series) and are designed to plug into a USB port and go. A couple of things to watch out for are your machine set-up and the version of MPLabX that you run. My work machine is set up for supporting legacy hardware and runs Python v2.7 and Win-7… It won’t talk to the DM320119 - SAMD21 Board because MPLAB runs with Python 3. I spent a few weeks in daily contact with Microchip Support without either side thinking that this might be a problem. I haven’t been able to determine if this is why I can’t get MPLabX to recognize the Xpress boards (I’m sincerely not interested in doing development out in the cloud!). As a result, I decided just to toss Flash-Forth onto the DM182026 - PIC18F46K42 and was horrified at the list of errors. Looking into the Project Properties, it would appear that Version 5.40 is even more of a departure for MPLabX than they advertised. Mpasm is gone so the assembler in XC8 probably needs to be hooked and a whole new can of worm spills out. I cheated. I went back to MPLabX 5.35 and everything assembled fine. I used the board’s USB to power it, jacked my trusty PICkit-3 into the appropriate pins, attached an FTDI-basic to UART1 and everything worked. I’m hoping to be able to use the onboard USB to talk to Terra-Term for me, but I’m not holding my breath. Excluding the PIC16 based and the 32-bit processors, there are 2 Xpress boards of potential interest for running FlashForth: Part Number: DM182026 - PIC18F46K42 MPLAB(R) Xpress Evaluation Board Part Number: DM182027 - PIC18F47K40 MPLAB(R) Xpress Evaluation Board 7 Curiosity Nano offerings may work although I really don’t know much about the formerly Atmel lineup: Part Number: DM164150 - PIC18F57Q43 Curiosity Nano Evaluation Kit Part Number: DM182029 - PIC18F47Q10 Curiosity Nano Evaluation kit Part Number: DM182028 - PIC18F47K42 Curiosity Nano Evaluation kit Part Number: DM164151 - AVR128DA48 Curiosity Nano Evaluation Kit Part Number: DM320115 - ATmega4809 Curiosity Nano Evaluation kit Part Number: DM080103 - ATtiny1607 Curiosity Nano Evaluation Kit Part Number: EV50J96A - ATtiny3217 Curiosity Nano Evaluation Kit The AVR128DA48 in particular appears to be fairly new and may have come out since the merger. I’m trying to catch up to the PIC18F4xK42 before tackling these “Q” things (grin). Peter? Mikael? Anyone? I’m curious if I’m the only one crazy enough to be banging my head against these (big grin). craig bair |
|
From: Mikael N. <mik...@fl...> - 2020-03-18 08:01:07
|
Hi, You can compile FORGET from source code. When you give the IDLE command, sleep 0 is entered each time PAUSE is executed. BUSY will disable the above. Other sleep modes you need to implement yourself. $53 constant smcr : sleep ( sleepmode -- ) smcr c! $9588 i, ; On 2020-03-18 06:59, tur bine wrote: > Hi I am new to flashforth and forth. I seem to be making some progress but seem to be missing sleep and forget in my words list. Both return sleep? etc when used, can I use sleep in assembly? I can set the register, but I am unsure how to call it in assembly, is it [sleep]?. I have burnt the hex file in the avr folder, thoroughly enjoying interacting with it so far, any help would be appreciated. > _______________________________________________ > Flashforth-devel mailing list > Fla...@li... > https://lists.sourceforge.net/lists/listinfo/flashforth-devel |
17 messages has been excluded from this view by a project administrator.
