flashforth-devel — FlashForth users and developers

Re: [Flashforth-devel] problems with recent source build (FlashForth 5 PIC18F46K22 13.06.2019)

[craig b. <dab...@ya...>]

 Mike,

Out of sheer annoyance and desperation, I went through my source-text with a fairly large fire-axe and cut out all of the comments, everything ALREADY DEFINED, anything that popped out "?" or a COMPILE ONLY, and the drivers for chips that weren't on this board. Size dropped from over 63k to just under 29k and nothing that wasn't intended to get fed in to be compiled was left. LO-and-BEHOLD it reliably loads consistantly.
Being in a hurry under pressure bit me again, you'ld think I'ld learn (old bears take a while to pick up new tricks).

One of the new things I needed was increment and decrement for double-cell 32-bits. This seems quick on the Pic18 and I haven't found a hole in the logic yet:

$ffeb constant SWrw \ PLUSW0 \ FSR0 + Offset to Sp in W

: d1+ ( d -- d+1 ) \ increment double on stack
 [ $fd movlw, SWrw f, a, incf, ]
 [ $fe movlw, status $0 a, btfsc, SWrw f, a, incf, ]
 [ $ff movlw, status $0 a, btfsc, SWrw f, a, incf, ]
 [ $00 movlw, status $0 a, btfsc, SWrw f, a, incf, ]
;

: d1- ( d -- d-1 ) \ decrement double on stack
 [ $fd movlw, SWrw f, a, decf, ]
 [ $fe movlw, status $0 a, btfss, SWrw f, a, decf, ]
 [ $ff movlw, status $0 a, btfss, SWrw f, a, decf, ]
 [ $00 movlw, status $0 a, btfss, SWrw f, a, decf, ]
;


Thanks once again for your patience and attention,
craig



     On Friday, August 30, 2019, 5:36:39 AM EDT, Mikael Nordman <mik...@fl...> wrote:  
 
 Hi Craig.

If your flash DP grows over $ec00 it will overwrite the system DPs in 
eeprom.

There is no check or warning about this limit.

You can put 'flash here cr u. cr' in your source files to see what 
happens.

BR Mike

On 2019-08-29 23:19, craig bair via Flashforth-devel wrote:
> Am I violating some limit I'm unaware of yet? (It IS a lot of words...)
> Is there an earlier known-stable version of the source that I should be 
> using?
> Could I be puting something into a colon-definition that could trash a
> system pointer?
> 
> Any thoughts and/or suggestions appreciated gratly.
> Thanks.
> craig bair
> 
> 
> _______________________________________________
> 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
  

Re: [Flashforth-devel] problems with recent source build (FlashForth 5 PIC18F46K22 13.06.2019)

[craig b. <dab...@ya...>]

 Thanks, Mike, but I'm guessing that's not my problem... Results aren't necessarily the same sending the same file to the same processor after sending the "empty" word. I emptied it last night before going home, started everything back up this morning, added extended version of immediate free at every marker and loaded the file up. It finished successfully.

Here's the starting point from "empty":

 flash hi dup u. here dup u. - u. cr ebff 2300 c8ff 
 ok<$,flash>
 eeprom hi dup u. here dup u. - u. cr efff ec0c 3f3 
 ok<$,eeprom>
 ram hi dup u. here dup u. - u. cr ff37 f1a1 d96 


Here's the ending stats:

 flash hi dup u. here dup u. - u. cr ebff 640e 87f1 
 ok<$,flash>
 eeprom hi dup u. here dup u. - u. cr efff ec2c 3d3 
 ok<$,eeprom>
 ram hi dup u. here dup u. - u. cr ff37 f22e d09 


I'm still under the half-way point on flash space according to this log.
Also, this same file loaded to a Pic18F45K22 build of the same source behaved just as badly.

If I were to empty the chip and try to load it again at this point, it's highly likely that things would blow up again. instead, I'm going to shut everything down, let it cool off, and try to load the interrupt system words later.

I've added 528 words to the user dictionary beyond the 294 of the system. As I remember, there was a way in the older forths to daisy-chain multiple used dictionaries. That probably isn't as useful in an empeded context, but is it worthwhile to do an "iflush" every once in a while? Will this force the flash dp to a 64-byte boundry or will it carry any already-defined bytes in the buffer over and add on from that point when more comes in?

I'll keep playing with it to see if I can spot more behavioral patterns. If it matters, I'm developing on an old Gateway P3 based laptop running Win-XP Home SP2 using TerraTerm v4.75...

Oh, one thing that struck me as odd with this board is when TeraTerm connects. I routinely plug its onboard FTDI into the computer, start TerraTerm (which is already set to its virtual com port), then apply power to the board. Normally I expect to see the FF5 self-announce at this time, but on this board I see nothing at all until I hit enter. If I hit enter before applying board power, there's a "?" vefore the OK prompt. Odd, and I don't do board design so I have no idea why it acts like that.

Many thanks for your time,
craig


     On Friday, August 30, 2019, 5:36:39 AM EDT, Mikael Nordman <mik...@fl...> wrote:  
 
 Hi Craig.

If your flash DP grows over $ec00 it will overwrite the system DPs in 
eeprom.

There is no check or warning about this limit.

You can put 'flash here cr u. cr' in your source files to see what 
happens.

BR Mike

On 2019-08-29 23:19, craig bair via Flashforth-devel wrote:
> Am I violating some limit I'm unaware of yet? (It IS a lot of words...)
> Is there an earlier known-stable version of the source that I should be 
> using?
> Could I be puting something into a colon-definition that could trash a
> system pointer?
> 
> Any thoughts and/or suggestions appreciated gratly.
> Thanks.
> craig bair
> 
> 
> _______________________________________________
> 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
  

Re: [Flashforth-devel] problems with recent source build (FlashForth 5 PIC18F46K22 13.06.2019)

[Mikael N. <mik...@fl...>]

Hi Craig.

If your flash DP grows over $ec00 it will overwrite the system DPs in 
eeprom.

There is no check or warning about this limit.

You can put 'flash here cr u. cr' in your source files to see what 
happens.

BR Mike

On 2019-08-29 23:19, craig bair via Flashforth-devel wrote:
> Am I violating some limit I'm unaware of yet? (It IS a lot of words...)
> Is there an earlier known-stable version of the source that I should be 
> using?
> Could I be puting something into a colon-definition that could trash a
> system pointer?
> 
> Any thoughts and/or suggestions appreciated gratly.
> Thanks.
> craig bair
> 
> 
> _______________________________________________
> Flashforth-devel mailing list
> Fla...@li...
> https://lists.sourceforge.net/lists/listinfo/flashforth-devel

-- 
--
Mikael

[Flashforth-devel] problems with recent source build (FlashForth 5 PIC18F46K22 13.06.2019)

[craig b. <dab...@ya...>]

I had been using a kernal build from 2015 source but ran into problems with words that would run if invoked directly from interactive terminal but instantly cause warm reset if used in other words (no cause code shown).
I've assembled the 13.06.2019 Pic18 source in MPLabX and tested my words.  The work as intended and I can include them in bigger things.
The problem comes when I try to load up the several large text files that comprise the application.  It appears that somewhere  between 2/3 and 3/4 of my package the compiler wraps an address and starts over-writing the beginning of the user-dictionary.  I'm trying to get a number close to the address where things blow up, but it isn't always consistant, possibly from wiping out something that it's trying to use/

Here's one post-mortem that I caught (^O stoppes the runaway periods in the word dump):

 FlashForth 5 PIC18F46K22 13.06.2019

  ok<#,ram>
decimal ram  ok<#,ram>
 flash hi here - u. cr 39713
 ok<#,flash>
 eeprom hi here - u. cr 917
 ok<#,eeprom>
 ram hi here - u. cr  3461
 ok<#,ram>
words
p2+ p++ pc@ @p hi d. ud. d> d< d= d0< d0= dinvert d2* d2/ d- d+ dabs ?dnegate dnegate s>d rdrop endit next for in, inline repeat while again until begin else then if until, again, begin, else, then, if, not, nc, nz, z, br? dump .s words >pr .id ms ticks s0 latest state bl 2- ['] -@ ; :noname : ] [ lst does> postpone create cr [char] ( char ' abort" ?abort ?abort? abort prompt quit true false .st inlined immediate shb interpret 'source >in tiu tib ti# number? >number a> >a ud/mod ud* sign? digit? find immed? (f) c>n n>c @+ c@+ place cmove word parse \ /string source user base pad hp task ulink bin hex decimal . u.r u. sign #> #s # digit <# hold up min max ?negate tuck nip / u*/mod u/ * u/mod um/mod um* 'key? 'key 'emit p+ pc! p! p@ r>p !p>r !p u> u< > < = 0< 0= <> within +! 2/ 2* >body 2+ 1- 1+ negate invert xor or and - m+ + abs dup r@ r> >r rot over swap drop allot ." ," s" (s" type accept 1 umax umin spaces space 2swap 2dup 2drop 2! 2@ cf, chars char+ cells cell+ aligned align cell c, , here dp ram eeprom flash c@ @ c! ! sp@ 2constant constant co: 2variable variable @ex execute key? key emit ver warm empty btfss, btfsc, bsf, bcf, bra, rcall, call, goto, br3 br2 as3 as1 rshift lshift ic, i, operator Fcy mtst mclr mset iflush pause turnkey is to defer value cwd u1- u1+ fl+ fl- >tblp literal int! ;i di ei scan skip n= rx1? rx1 tx1 i] [i andlw, movf, w, a, load busy idle exit

?R2 R2: ?R1 R1: ?T2 T2: ?T1 T1: ch# adcal _adcal N2m N1m R2 R1 R2m R1m T2 T1 adc@ xring adcinit .dp2 .dp1 1sectst maxtmr0 t6if? t6if0 t5if? t5if0 t4if? t4if0 t3if? t3if0 t2if? t2if0 t1if? t1if0 t0if? t0if0 t0ie0 -FUNCTION -STOP2 tstch adcmanual cvttrig adcreset adc!cfr adc@dat adc@cfr adcdfalt adcwakeup adchansel spib_19 spib_4 -ADS8332 spibinit RSTd RSTb, RSTb| RSTb> INTb, INTb| INTb> CVTb, CVTb| CVTb> SSb, SSb| SSb> SDIb, SDIb| SDIb> SDOb, SDOb| SDOb> SCKb, SCKb| SCKb> -SPIb_BANG slowspi spi@F/64 spi@F/16 spinit ssp1con2 SSP1M, CKP, SSPEN, SSPOV, WCOL, ssp1con1 BF, CKE, SMP, ssp1stat ssp1add ssp1buf ssp1msk BOEN, ssp1con3 SS1, _ENA, LDAC, SDI1, SDO1, SCK1, -SPI1 getpercent %heat heatoff heaton maxheat pwms analogoff ccp1init ccp2init t6init t6pwms v#hex s#Lo s#Hi heatset bump cnt nbuf adcy adcx gledoff gledon yledoff yledon 2.5/ 2.5* Splus ccptmrs1 ccptmrs0 t6con pr6 t4con pr4 t2con pr2 t5con tmr5l tmr5h t3con tmr3l tmr3h t1con tmr1l tmr1h t0con tmr0l tmr0h ccp5con ccpr5l ccpr5h ccp4con ccpr4l ccpr4h ccp3con ccpr3l ccpr3h ccp2con ccpr2l ccpr2h ccp1con ccpr1l ccpr1h -H385SYS ansela anselb anselc ansele trise trisc trisb trisa late latc latb lata porte portc portb porta -PORTS 2array type2 tx2 tx2dis tx2ena u2cfg. setu2baud u2init u1init tx2ip1 tx2ip0 tx2ip? rc2ip1 rc2ip0 rc2ip? tx2if? rc2if. tx2ie1 tx2ie0 tx2ie? rc2ie1 rc2ie0 rc2ie? rx2, tx2, anseld portd latd trisd 460.8K 230.4K 115.2K 57.6K 38.4K 19.2K 9.6k baudcon2 rcsta2 txsta2 txreg2 rcreg2 spbrg2 spbrgh2 pie3 pir3 ipr3 rcsta1 txsta1 txreg1 rcreg1 spbrg1 spbrgh1 baudcon1 pie1 pir1 ipr1 \dbar \hln2 \ulf2 \llf2 \lrg2 \urg2 \vln2 \hbar \ulft \lrgt \cros \hlin \lfmi \lmdn \lmup \llft \urgt \rgmi \vlin \hlf3 \hlf2 \hlf1 \ohm \deg \bs \c- \c+ \hid \rev \bli \unl \bri \res \attr \t \cp \cbn \cb \cfn \cf \cdn \cd \cun \cu \nl \eel \esl \el \clsh \cls \h \; .n esc[ -VT100 .Y......n.j.. . B.v .....R3.f ...............  ..... ...............  ..... ...............

It appears to have over-written these words previously written:

-VT100 darray carray array f.4 f.3 f.2 f.1 $. %. #. crev p_hi p_lo splitword swapbytes uq* qm+ d>q uq/mod tmp dcnt divisor dividend -QMATH m*/ um*/ ut/ ut* */ */mod mod /mod fm/mod sm/rem m* d1- d1+ -MATH bit?: bit^: bit1: bit0: (bit) -BIT ov, mi, cc, tblwt+*, tblwt*-, tblwt*+, tblwt*, tblrd+*, tblrd*-, tblrd*+, tblrd*, nop, sleep, return, retlw, retfie, reset, push, pop, daw, clrwdt, xorlw, sublw, mullw, movlw, movlb, lfsr, iorlw, addlw, btg, xorwf, tstfsz, swapf, subwfb, subwf, subfwb, setf, rrncf, rrcf, rlncf, rlcf, negf, mulwf, movwf, movff, iorwf, infsnz, incfsz, incf, dcfsnz, decfsz, decf, cpfslt, cpfsgt, cpfseq, comf, clrf, andwf, addwfc, addwf, as2 as0 Tp plusT Tminus Treg status Sp Srw SWrw plusS Sminus Sreg b, f, -AS default| | jumptable -JMPTBL endcase endof default of case (of) -CASE .heres .free pick 2literal count in? ?dup blanks erase fill forget evaluate -CORE marker

Am I violating some limit I'm unaware of yet? (It IS a lot of words...)
Is there an earlier known-stable version of the source that I should be using?
Could I be puting something into a colon-definition that could trash a system pointer?

Any thoughts and/or suggestions appreciated gratly.
Thanks.
craig bair

[Flashforth-devel] typo in asm.txt: cli, clh, are the same.

[John H. <jo...@mi...>]

94d8 op: clh,                  \ --
94d8 op: cli,                  \ --


should be

94f8 op: cli,                  \ --

Regards,
Dad

[Flashforth-devel] PIC32

[Matthias K. <m....@gm...>]

Dear Flashforth team,

in the archive of the mail list, there have been requests for support of PIC32 chips with MIPS architecture. I took the challenge and wrote Mecrisp-Quintus for RISC-V and MIPS; its first PIC32 targets are pic32mx270f256b and pic32mx570f512l. Adventurous Forthers are welcome for testing !

You'll find Mecrisp-Quintus here:
https://sourceforge.net/projects/mecrisp/files/

Best wishes,
Matthias Koch
http://mecrisp.sourceforge.net/

Re: [Flashforth-devel] Assembling ff-pic18 with MPLabX problem

[craig b. <dab...@ya...>]

I downloaded & built  FlashForth 5 PIC18F46K22 13.06.2019
There's an appearant typo in line :
2535	        bcf     ANSELCNSC7, BANKED   ; Enable digital RC7 for RX
... which I edited to:
2535	        bcf     ANSELC, ANSC7, BANKED   ; Enable digital RC7 for RX
... to get it to assemble.  This build works although the PLL probably isn't running because it communicates at 9600 rather than 38400.

FlashForth 5 PIC18F46K22 13.06.2019

empty  ok<#,ram>
words
p2+ p++ pc@ @p hi d. ud. d> d< d= d0< d0= dinvert d2* d2/ d- d+ dabs ?dnegate dnegate s>d rdrop endit next for in, inline repeat while again until begin else then if until, again, begin, else, then, if, not, nc, nz, z, br? dump .s words >pr .id ms ticks s0 latest state bl 2- ['] -@ ; :noname : ] [ lst does> postpone create cr [char] ( char ' abort" ?abort ?abort? abort prompt quit true false .st inlined immediate shb interpret 'source >in tiu tib ti# number? >number a> >a ud/mod ud* sign? digit? find immed? (f) c>n n>c @+ c@+ place cmove word parse \ /string source user base pad hp task ulink bin hex decimal . u.r u. sign #> #s # digit <# hold up min max ?negate tuck nip / u*/mod u/ * u/mod um/mod um* 'key? 'key 'emit p+ pc! p! p@ r>p !p>r !p u> u< > < = 0< 0= <> within +! 2/ 2* >body 2+ 1- 1+ negate invert xor or and - m+ + abs dup r@ r> >r rot over swap drop allot ." ," s" (s" type accept 1 umax umin spaces space 2swap 2dup 2drop 2! 2@ cf, chars char+ cells cell+ aligned align cell c, , here dp ram eeprom flash c@ @ c! ! sp@ 2constant constant co: 2variable variable @ex execute key? key emit ver warm empty btfss, btfsc, bsf, bcf, bra, rcall, call, goto, br3 br2 as3 as1 rshift lshift ic, i, operator Fcy mtst mclr mset iflush pause turnkey is to defer value cwd u1- u1+ fl+ fl- >tblp literal int! ;i di ei scan skip n= rx1? rx1 tx1 i] [i andlw, movf, w, a, exit
marker  ok<#,ram>
  ok<#,ram>
  ok<#,ram>
-1.  ok<#,ram>65535 65535
+  ok<#,ram>65534
. -2  ok<#,ram>

Much better.  I'll continue testing.  It looks like I just had a bad copy of that older version.
Thanks again for your attention.
craig

Re: [Flashforth-devel] Assembling ff-pic18 with MPLabX problem

[craig b. <dab...@ya...>]

An interesting result, and unexpected...


  ok<#,ram>
empty
 FlashForth 5 PIC18F46K22 20.03.2018
 ok<#,ram>
words
p2+ p++ pc@ @p hi d. ud. d> d< d= d0< d0= dinvert d2* d2/ d- d+ dabs ?dnegate dnegate s>d rdrop endit next for in, inline repeat while again until begin else then if until, again, begin, else, then, if, not, nc, nz, z, br? dump .s words >pr .id ms .K ...............  .....#.6..w ...............  .....#.6..w ...............  .....#.6..w ...............  .....#.6..w ...............  .....#.6..w ...............  .....#.6..w ...............  .....#.6..w ...............  .....#.6..w ...............  .....#.6..w ...............  .....#.6..w ...............  .....#.6..w ...............  .....#.6..w ...............  .....#.6..w ...............  .....#.6..w ...............  .....#.6..w ...............  .....#.6..w ...............  .....#.6..w ...............  .....#.6..w ...............  .....#.6..w ...............  .....#.6..w ...............  .....#.6..w ...............  .....#.6..w ...............  .....#.6..w ...............  .....#.6..w ...............  .....#.6..w ...............  .....#.6..w ...............  .....#.6..w ...............  .....#.6..w ...............  .....#.6..w ...............  .....#.6..w ...............  .....#.6..w ...............  .....#.6..w ...............  .....#.6..w ...............  .....#.6..w ...............  .....#.6..w ...............  .....#.6..w ...............  .....#.6..w ...............  .....#.6..w ...............  .....#.6..w ...............  .....#.6..w ...............  .....#.6..w ...............  .....#.6..w ...............  .....#.6..w ...............  .....#.6..w ...............  .....#.6..w ...............  .....#.6..w ...............

I had to power-cycle it to stop it probably because I still have ^O disabled.  Tried a few of the words that did show:

  ok<#,ram>
-1. dabs
 FlashForth 5 PIC18F46K22 20.03.2018
 ok<#,ram>
hi  ok<#,ram>65335
hi  ok<#,ram>65335 65335
dnegate  ok<#,ram>201 200
+
 FlashForth 5 PIC18F46K22 20.03.2018
 ok<#,ram>


Just out of curiosity, I'm going to pull the current master source and see if it does anything different.
Thanks for that suggestion.

craig

Re: [Flashforth-devel] Assembling ff-pic18 with MPLabX problem

[Mikael N. <mik...@fl...>]

Try
empty <enter>
words <enter>

Mike

[Flashforth-devel] Assembling ff-pic18 with MPLabX problem

[craig b. <dab...@ya...>]

I've been playing with, and building small test equipment based on Pic18F|4,2|6K22 chips running FlashForth 3.8 and 5.0 for some time now.  A while back I settled in on a HEX file (Ver.FlashForth PIC18F46K22 07.06.2015) with the math extensions, assembler, vt100, and a few other things that I routinely call on included and protected from the "empty" word.  This was built in MPLab-IDE 8.92 and hand edited with my trusty PICKit-3 and has served well for years.

I find myself needing to do a bit of tweaking to the ff-pic18.asm file (I need a 32-bit systick counter and access to it at the timer-interrupt level for some RT things).  This probably wouldn't be a problem if I had migrated to MPLabX back when it started getting serious, but my day-job has become ARM-core intensive and I have 4 other IDE-s for various chip makers to try to keep straight...

I dug out my old MPLab and tried assembling a relatively recent release of the source (FlashForth 5 PIC18F46K22 20.03.2018).  After a little futzing I got it to assemble and load.  Unfortunately it just sat there restarting every 2 seconds after the TURNKEY_DELAY.

I installed MPLabX v4.15 and got a coworker who gets to program DisPIC33-s to show me how to get it to deal with a project and compiled the FF_UART.X.  This compiled up fine after setting things the way I use them in the config files.  Loaded, it even came to the familiar "ok<#,ram>" prompt and waited for input.  Unfortunately, no matter what is input, upon pressing "enter" FlashForth does a cold restart.

I tried again after installing MPLabX v5.05 with the same results.  Is there a specific version I need to use? (I remember having to find AS 4.0 to assemble FF for Arduino.)  Could I be setting something wrong in a config?  I'm running it at 64Mhz from the internal osc with PLL soft-control and that seems ok to USART1. I upped the Rx buffer from 32 to 64 bytes and that didn't seem to matter. I've changed the MS_TMR from 1 to 3 and back.  I've ENABLEed and DISABLEed the CTRL_O_WARM_RESET, IDLE_MODE, and CPU_LOAD.  Size of stacks, etc. are unchanged, UADDSIZE is still 0, and XSTORE is DISABLEed.

If I had to guess, I'ld say the inner interpreter is blowing up because it accepts RETURNS but nothing else.  I haven't gotten really serious about Forth internals since re-writing FIG-Forth 6502 to run in the Apple][ language card back in the early 80-s so I'm a bit rusty at trouble-shooting this.  I feel I have to get through this because I'm going to need to migrate to the K42-s or something newer as the K22-s get phased out.

Any thoughts will be appreciated.


craig bair

Re: [Flashforth-devel] K42 problem

[Mikael N. <mik...@fl...>]

Thanks for the feedback.

I need to rearrange the config file accordingly.

None of my uses of FlashForth has been actually using any extra 
interrupts.
Polling has been fast enough.

So maybe a fully polling version could be made where also the UART RX is 
polled.
At least for code compilation that should be possible to make work with 
end-of-line flow control.

The K83 family has the same core as the K42, and sadly the same 
interrupt problem.

BR Mikael


On 2019-06-24 23:19, Attila Herman wrote:
> Hi Mike,
> 
> Thanks for your suggestion.
> The flash_write_inner_loop modification has solved the problem at 
> 25K42.
> In this case, the interrupt was not the reason of the trouble.
> I will try FF also with larger K42 controllers.
> With the elimination of the interrupt problems, the K42 family could
> become the best alternative of K22.
> 
> BR   Attila
> 
> 
> 
> _______________________________________________
> Flashforth-devel mailing list
> Fla...@li...
> https://lists.sourceforge.net/lists/listinfo/flashforth-devel

-- 
--
Mikael

Re: [Flashforth-devel] K42 problem

[Attila H. <exp...@vn...>]

Hi Mike,

Thanks for your suggestion.
The flash_write_inner_loop modification has solved the problem at 25K42.
In this case, the interrupt was not the reason of the trouble.
I will try FF also with larger K42 controllers.
With the elimination of the interrupt problems, the K42 family could 
become the best alternative of K22.

BR   Attila

Re: [Flashforth-devel] K42 problem

[Mikael N. <mik...@fl...>]

Try changing this
  constant flash_write_inner_loop = d'128'
to this
  constant flash_write_inner_loop = d'64'

The 25K42 has a smaller flash block size than the larger K42's

BR Mikael

On 2019-06-24 08:49, Mikael Nordman wrote:
> Hi Attila.
> 
> The K42 is a bit problematic.
> 
> Interrupts do not work with FlashForth on K42.
> It seems that just a simple TMR2 interrupt that only resets the 
> interrupt flag,
> occasionally corrupts the main program flow. Causing the effect you 
> mention...
> I have looked for a long time to find the problem in the code, but
> could not find it.
> I suspect it is a fault in the K42 silicon that its HW context 
> interrupt saving
> does not work with some code sequence in FlashForth.
> 
> Therefore I decided to have the system ticks to be incremented by
> polling in PAUSE.
> That works reasonably well.
> With the code in git, I can compile any code and it works on my 26K42.
> 
> So I am bit surprised that you have this problem.
> The UART interrupts could cause a problem if they occur in the middle 
> of the
> compilation, but during compilation of your one liner
> there is normally no UART RX activity.
> 
> I use the ff-shell.py which has end-of-line flow control so that during 
> the
> interpreting/compilation of a line there is no UART RX activity.
> 
> Maybe the 25K42 has some difference to the 26K42 that I have not 
> noticed.
> 
> BR Mikael
> 
> 
> _______________________________________________
> Flashforth-devel mailing list
> Fla...@li...
> https://lists.sourceforge.net/lists/listinfo/flashforth-devel

-- 
--
Mikael

Re: [Flashforth-devel] K42 problem

[Mikael N. <mik...@fl...>]

Hi Attila.

The K42 is a bit problematic.

Interrupts do not work with FlashForth on K42.
It seems that just a simple TMR2 interrupt that only resets the 
interrupt flag,
occasionally corrupts the main program flow. Causing the effect you 
mention...
I have looked for a long time to find the problem in the code, but could 
not find it.
I suspect it is a fault in the K42 silicon that its HW context interrupt 
saving
does not work with some code sequence in FlashForth.

Therefore I decided to have the system ticks to be incremented by 
polling in PAUSE.
That works reasonably well.
With the code in git, I can compile any code and it works on my 26K42.

So I am bit surprised that you have this problem.
The UART interrupts could cause a problem if they occur in the middle of 
the
compilation, but during compilation of your one liner
there is normally no UART RX activity.

I use the ff-shell.py which has end-of-line flow control so that during 
the
interpreting/compilation of a line there is no UART RX activity.

Maybe the 25K42 has some difference to the 26K42 that I have not 
noticed.

BR Mikael

[Flashforth-devel] K42 problem

[Attila H. <exp...@vn...>]

Hello Mikael,

I would like to try the FF with 18FxxK42 controllers, but I have a 
trouble. In interpreter mode everything is ok, but compilation of any 
word definition results reboot.:

: try1 123 . ;
BWS FlashForth 5 PIC18F25K42 13.06.2019

variable asd
BWS FlashForth 5 PIC18F25K42 13.06.2019

I can't find that is why. I get BWS restart indicators independently of 
the controller config.
What is I made wrong?

BR
  Attila

[Flashforth-devel] DS3231 support

[Phoenix R. <pho...@pl...>]

Hello,

I am now attempting to get FF (on a mega2560) to speak with the DS3231.

Rather than reinvent the wheel, I thought it better to ask the community 
if this hasn't already been done?

Is there code already written?  I've tried and haven't gotten it working.

Thanks in advance!

PHX

Re: [Flashforth-devel] mega2560 Serial port problems

[Mikael N. <mik...@fl...>]

What about this solution.

$31 tx1 <enter>

Usart 1 is setup by default on the 2560,

BR Mike

Re: [Flashforth-devel] FlashForth 2-Dimensional arrays?

[<dab...@ya...>]

 Very Nice Thought! 
(As the War College replied to Grace Murray Hopper about her answer on the problem of refueling a battle group at sea, "An interesting solution.")
I'm going to have to give that one a try once this project is wrapped up. Much cleaner than anything I came up with. Glad I'm not the only one who couldn't see a way back to the DOES>... (grin)
Thanks Again!
Keep up the good work. Stephen's warnings aside, it pays to know the underlying system.

     On Monday, June 3, 2019, 9:35:57 AM EDT, Mikael Nordman <mik...@fl...> wrote:  
 
 Sorry Craig,

I cannot think of any good way to do that in FF.

Once you are executing in the DOES> part, which part of the 2ARRAY word,
I cannot think of any way to get back to defined array word to fetch a 
size from flash.
That address is gone from the return stack.
Storing the size in flash can be done in the CREATE part with I, or 
FLASH , RAM
But when the DOES> part is executing, there is no link to the array 
word.

The only way I can think of is to initialize the size of each array in 
ram after every warm start.

Except, there is a way :-) Not tested or complete, but you get the idea.

: 2array ( col, row -- addr )
  \ create a word which points to a data area in flash
  flash create
  \ append the row size in flash
  dup ,
  \ append the start of the ram buffer in flash
  ram here flash ,
  \ allot the the ram buffer
  cells * ram here allot
  does>
    \ Fetch the row size from flash
    @+
    \ Fetch the ram buffer address flash
    @
    \ etcetera
  ;

BR Mike

On 2019-06-02 16:55, craig bair via Flashforth-devel wrote:
> I've run into an interesting problem with FF-5 on Pic18F46K22 chips.
> 2-Dimensional arrays are really handy things.  I'm setting up a
> rolling-average filter for the output of a multi-channel A/D chip to
> take a reading from a different channel each millisecond and average
> the reading I need from the correct ring-buffer whenever needed.  The
> control routine works perfectly with a 2D-array in Forth to the limits
> that I can test it... until I shut the system down or do a reset.
> Suddenly the 2array word stops returning addresses other than for row
> Zero.
> 
> Here's the word I use, derived from Stephen Pelc's (cleaned up so it
> doesn't crash when accessed):
> \ WORD ARRAY CREATION -- 2-Dimensional ( col, row -- addr )
> \ x0y0 x1y0 x2y0 ... xny0 x0y1 x1y1 ... xny1 x0y2 ... xnym
> : 2array    \ x1 y2 -- ; [child] n1 n2 -- addr ; 2-D array
>        \ make name word, save width, calculate size, allocate
>    create over , cells * here over erase allot
>        \ run time gives address of data
>    does> dup @ rot * rot + 1+ cells +
> ;
> 
> My best initial guess is that the COMMA is storing the row length into
> a ram location so a reset clears it to zero from that point on (in a
> Harvard Architecture processor).
> 
> I can work around it by doing a specific address calculation routine
> with a 1D-array, but fixing "2array" for embedded controller would be
> better.  Any suggestions or insights?
> 
> craig
> 
> 
> 
> 
> _______________________________________________
> 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
  

Re: [Flashforth-devel] FlashForth 2-Dimensional arrays?

[Mikael N. <mik...@fl...>]

Sorry Craig,

I cannot think of any good way to do that in FF.

Once you are executing in the DOES> part, which part of the 2ARRAY word,
I cannot think of any way to get back to defined array word to fetch a 
size from flash.
That address is gone from the return stack.
Storing the size in flash can be done in the CREATE part with I, or 
FLASH , RAM
But when the DOES> part is executing, there is no link to the array 
word.

The only way I can think of is to initialize the size of each array in 
ram after every warm start.

Except, there is a way :-) Not tested or complete, but you get the idea.

: 2array ( col, row -- addr )
   \ create a word which points to a data area in flash
   flash create
   \ append the row size in flash
   dup ,
   \ append the start of the ram buffer in flash
   ram here flash ,
   \ allot the the ram buffer
   cells * ram here allot
   does>
     \ Fetch the row size from flash
     @+
     \ Fetch the ram buffer address flash
     @
     \ etcetera
   ;

BR Mike

On 2019-06-02 16:55, craig bair via Flashforth-devel wrote:
> I've run into an interesting problem with FF-5 on Pic18F46K22 chips.
> 2-Dimensional arrays are really handy things.  I'm setting up a
> rolling-average filter for the output of a multi-channel A/D chip to
> take a reading from a different channel each millisecond and average
> the reading I need from the correct ring-buffer whenever needed.  The
> control routine works perfectly with a 2D-array in Forth to the limits
> that I can test it... until I shut the system down or do a reset.
> Suddenly the 2array word stops returning addresses other than for row
> Zero.
> 
> Here's the word I use, derived from Stephen Pelc's (cleaned up so it
> doesn't crash when accessed):
> \ WORD ARRAY CREATION -- 2-Dimensional ( col, row -- addr )
> \ x0y0 x1y0 x2y0 ... xny0 x0y1 x1y1 ... xny1 x0y2 ... xnym
> : 2array	\ x1 y2 -- ; [child] n1 n2 -- addr ; 2-D array
>         \ make name word, save width, calculate size, allocate
>     create over , cells * here over erase allot
>         \ run time gives address of data
>     does> dup @ rot * rot + 1+ cells +
> ;
> 
> My best initial guess is that the COMMA is storing the row length into
> a ram location so a reset clears it to zero from that point on (in a
> Harvard Architecture processor).
> 
> I can work around it by doing a specific address calculation routine
> with a 1D-array, but fixing "2array" for embedded controller would be
> better.  Any suggestions or insights?
> 
> craig
> 
> 
> 
> 
> _______________________________________________
> Flashforth-devel mailing list
> Fla...@li...
> https://lists.sourceforge.net/lists/listinfo/flashforth-devel

-- 
--
Mikael

Re: [Flashforth-devel] FlashForth 2-Dimensional arrays?

[<dab...@ya...>]

Oh, by the way...
Here's my simple-minded, not terribly portable workaround:

    $4 $3 * array adbox
    : adbox: 4 * + adbox ;

The 2D-array is flattened to a linear array then the "adbox:" word is used as if adbox was defined as a 2array structure.
It tests fine with a minimum of code change but fails to emotionally satisfy (grin).

craig

[Flashforth-devel] FlashForth 2-Dimensional arrays?

[<dab...@ya...>]

I've run into an interesting problem with FF-5 on Pic18F46K22 chips.
2-Dimensional arrays are really handy things.  I'm setting up a rolling-average filter for the output of a multi-channel A/D chip to take a reading from a different channel each millisecond and average the reading I need from the correct ring-buffer whenever needed.  The control routine works perfectly with a 2D-array in Forth to the limits that I can test it... until I shut the system down or do a reset.  Suddenly the 2array word stops returning addresses other than for row Zero.

Here's the word I use, derived from Stephen Pelc's (cleaned up so it doesn't crash when accessed):
\ WORD ARRAY CREATION -- 2-Dimensional ( col, row -- addr )
\ x0y0 x1y0 x2y0 ... xny0 x0y1 x1y1 ... xny1 x0y2 ... xnym
: 2array	\ x1 y2 -- ; [child] n1 n2 -- addr ; 2-D array
        \ make name word, save width, calculate size, allocate
    create over , cells * here over erase allot 
        \ run time gives address of data
    does> dup @ rot * rot + 1+ cells +
;

My best initial guess is that the COMMA is storing the row length into a ram location so a reset clears it to zero from that point on (in a Harvard Architecture processor).

I can work around it by doing a specific address calculation routine with a 1D-array, but fixing "2array" for embedded controller would be better.  Any suggestions or insights?

craig

[Flashforth-devel] mega2560 Serial port problems

[Phoenix R. <pho...@pl...>]

Hello,

I'm having a problem getting a character to be transmitted using USART1.

Here's what I've tried:

bit3 UCSR1B mset \ TXEN1 enabled

bit7 UCSR1C mclr \ set for Asynch mode

bit6 UCSR1C mclr \ set for Asynch mode

\ set for 9600 baud

0 UBRR1H c!

$67 UBRR1L c!

\ 8N1

bit5 UCSR1C mclr

bit4 UCSR1C mclr

Then I send a character to UDR1, expecting to see the data on my scope 
attached to TX1: $31 UDR1 c!

Nothing happens on the scope.  What am I missing?

Many thanks!

Re: [Flashforth-devel] write to BPP-420 from mega2560?

[Mikael N. <mik...@fl...>]

Hi,
I don't think so. There is no setting in mega2560 for the UART to invert 
the voltages.

There was no link to in your message.
Some of the Scott Edwards displays support both polarities of the 
voltages.

BR Mike


On 2019-05-20 06:25, Phoenix Rising wrote:
> Hello,
> 
> I'm having trouble figuring out how to invert the serial data in order
> to write to this Scott Edwards display.  All that comes out is
> gibberish.  Is there a method using Flashforth that will yield a
> similar result that 'softwareserial' does with its 'invert' bit?
> 
> Thanks!
> 
> PHX

[Flashforth-devel] write to BPP-420 from mega2560?

[Phoenix R. <pho...@pl...>]

Hello,

I'm having trouble figuring out how to invert the serial data in order 
to write to this Scott Edwards display.  All that comes out is 
gibberish.  Is there a method using Flashforth that will yield a similar 
result that 'softwareserial' does with its 'invert' bit?

Thanks!

PHX

Re: [Flashforth-devel] Help

[craig b. <dab...@ya...>]

On my Pic18-s I think the ESC usually indicates that the turnkey vector is set and execution is being passed to it...
craig
--------------------------------------------
On Sun, 2/24/19, Mikael Nordman <mik...@fl...> wrote:

 Subject: Re: [Flashforth-devel] Help
 To: fla...@li...
 Date: Sunday, February 24, 2019, 2:02 AM
 
 Probably the flash or eeprom is
 corrupted.
 
 Maybe you did
 not erase the eeprom when you programmed the chip.
 
 Reprogram the FF to the chip,
 with your programmer set  to erase flash 
 and eeprom.
 
 BR
 Mikael
 
 On 2019-02-23 17:02,
 craig bair via Flashforth-devel wrote:
 >
 Welcome in, Martin.
 > If it gets that
 far, the system is usually good.  I'm used to seeing
 > that on power-up, but a prompt comes back
 for me after hitting <ret>.
 > I run
 the PIC18 and Arduino versions of FlashForth 5.0, what are
 you 
 > using?
 > craig
 bair
 > 
 >
 --------------------------------------------
 > On Tue, 2/19/19, Martin Mainka <ma...@ma...>
 wrote:
 > 
 >  Subject:
 [Flashforth-devel] Help
 >  To: fla...@li...
 >  Date: Tuesday, February 19, 2019, 4:49
 AM
 > 
 >  Hi, i am new
 to flashforth
 > 
 > 
 What to do if the system is only
 > 
 responding ESC after the Flashforth
 > 
 text, but no prompt? I did reset and
 > 
 disconnect from power. No commands
 > 
 are accepted.
 > 
 > 
 many thanks in advance
 > 
 >  Martin
 > 
 > 
 > 
 > 
 _______________________________________________
 >  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
 
 -- 
 --
 Mikael
 
 
 _______________________________________________
 Flashforth-devel mailing list
 Fla...@li...
 https://lists.sourceforge.net/lists/listinfo/flashforth-devel