flashforth-devel — FlashForth users and developers

Re: [Flashforth-devel] Turnkey issues on restart not remembering

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

I recommend that you recompile FF with
the SKIP_MULTITASKING option defined in the p18f-main.cfg
And flash it to the chip.

The Turnkey value in eeprom is at address  hex ec00

BR Mike
On 05/08/2014 11:16 PM, Simon Bradley wrote:
> Mikael Nordman wrote:
>> Simon,
>>
>> Does it failafter turnkey definition immediately in the first warm
>> start ?
> I have just tried both a warm restart with WARM and also power off and on
> It worked this time around. I have an LCD display which I write text to
> when the PIC starts up. I only notice the fault when the display doesn't
> show the expected text and find that turnkey has been changed.
>
> the turnkey I use doesn't loop and exits back to the interpreter after running.
>
>   
>> Otherwise I cannot think about any reason except that your
>> application corrupts the turnkey.
>>
>> One typical error scenario is return stack overflow which will write
>> crap into the bottom of the parameter stack.
>> Thus causing unexpected behaviour.
> Not sure if that happens as programs seem to run correctly
>   
>> Multitasking gives you more opportunities to overflow the return
>> stack.
>> Once in each task.
> I haven't yet got into the multitasking scenario yet, so that probably
> isn't it. (Still learning FORTH using this device :)
>   
>> The PIC HW return stack is written to the user area in PAUSE even if
>> you only run the operator task. Defining SKIP_MULTITASKING before you
>> compile FF excludes this copying.
>>
>> You could also increase the RETURN_STACK_SAVE_SIZE to d'62'.
>> It is a bit on the small side in the FF3.8 !
>>
>> ; Max size is d'62'
>> #define RETURN_STACK_SAVE_SIZE d'30' ; 15 cells return stack save area
> Ok, that's currently beyond me !
>
> Is there a way to check if the turnkey has been corrupted ? Is it stored
> in the EEPROM and copied to RAM ?
>
> Is there a memory map I can refer to to help try and understand what is
> going on?
>   
>> BR Mike
> Thanks for your help,
> Simon.
>
>

Re: [Flashforth-devel] Turnkey issues on restart not remembering

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

Simon,

Does it failafter turnkey definition immediately in the first warm start ?

Otherwise I cannot think about any reason except that your application
corrupts the turnkey.

One typical error scenario is return stack overflow which will write
crap into the bottom of the parameter stack.
Thus causing unexpected behaviour.

Multitasking gives you more opportunities to overflow the return stack.
Once in each task.

The PIC HW return stack is written to the user area in PAUSE even if you 
only
run the operator task. Defining SKIP_MULTITASKING before you compile FF
excludes this copying.

You could also increase the RETURN_STACK_SAVE_SIZE to d'62'.
It is a bit on the small side in the FF3.8 !

; Max size is d'62'
#define RETURN_STACK_SAVE_SIZE d'30' ; 15 cells return stack save area


BR Mike

[Flashforth-devel] Turnkey issues on restart not remembering

[Simon B. <sim...@ho...>]

Hello,

I have a PIC 18F2550 with Flashforth 3.8 and sometimes on restart
the following

' 'lcd-day is turnkey

does not work as it gets stuck in a warm reboot loop

Pressing ESC gets me back in and I then find that the turnkey
vector has changed from the correct one above.

Is there any reason why this vector is being corrupted on cold
power on restarts? It doesn't always occur but it would be nice
to squash this bug.

Thanks,
Simon. 

Re: [Flashforth-devel] draft of revised tutorial guide for FF5

[Peter J. <pe...@me...>]

Thanks Pete.  My quality control takes a dive when I work on programs 
and documents late at night :)


On 06/05/14 11:17, Pete Zawasky wrote:
> Hi Peter,
>
> Still trying to review the tutorial guide properly....things got busy here.
>
> I did notice that in this latest release "The Hitchhiker's...." got
> changed to "The Hitchkiker's..." on page 14.
>
> Will try to finish review tomorrow.  Might even have some technical
> comments......
> Definitely appreciate your work for the FlashForth effort.
>
> Pete
>
> On 5/5/2014 8:28 PM, Peter Jacobs wrote:
>> http://dropbox.eait.uq.edu.au/e4pjacob/flash-forth/ff5-tutorial-guide-2014-05-06.pdf
>>
>> Added the example with bit words that manipulate bits from IO-space.
>> Full speed, as you said.  Also refined a little the description of
>> building for the PIC18F microcontrollers and interaction via gtkterm.
>>
>> I have yet to print it on paper and then check it for errors and
>> inconsistencies but it should be close to final form.
>> Cheers,
>> Peter J.
>>
>>
>>
>
> ------------------------------------------------------------------------------
> Is your legacy SCM system holding you back? Join Perforce May 7 to find out:
> • 3 signs your SCM is hindering your productivity
> • Requirements for releasing software faster
> • Expert tips and advice for migrating your SCM now
> http://p.sf.net/sfu/perforce
> _______________________________________________
> Flashforth-devel mailing list
> Fla...@li...
> https://lists.sourceforge.net/lists/listinfo/flashforth-devel

Re: [Flashforth-devel] draft of revised tutorial guide for FF5

[Pete Z. <pza...@pz...>]

Hi Peter,

Still trying to review the tutorial guide properly....things got busy here.

I did notice that in this latest release "The Hitchhiker's...." got 
changed to "The Hitchkiker's..." on page 14.

Will try to finish review tomorrow.  Might even have some technical 
comments......
Definitely appreciate your work for the FlashForth effort.

Pete

On 5/5/2014 8:28 PM, Peter Jacobs wrote:
> http://dropbox.eait.uq.edu.au/e4pjacob/flash-forth/ff5-tutorial-guide-2014-05-06.pdf
>
> Added the example with bit words that manipulate bits from IO-space.
> Full speed, as you said.  Also refined a little the description of
> building for the PIC18F microcontrollers and interaction via gtkterm.
>
> I have yet to print it on paper and then check it for errors and
> inconsistencies but it should be close to final form.
> Cheers,
> Peter J.
>
>
>

Re: [Flashforth-devel] draft of revised tutorial guide for FF5

[Peter J. <pe...@me...>]

http://dropbox.eait.uq.edu.au/e4pjacob/flash-forth/ff5-tutorial-guide-2014-05-06.pdf

Added the example with bit words that manipulate bits from IO-space.  
Full speed, as you said.  Also refined a little the description of 
building for the PIC18F microcontrollers and interaction via gtkterm.

I have yet to print it on paper and then check it for errors and 
inconsistencies but it should be close to final form.
Cheers,
Peter J.


On 05/05/14 23:48, Peter Jacobs wrote:
> Thanks.  A new version:
> http://dropbox.eait.uq.edu.au/e4pjacob/flash-forth/ff5-tutorial-guide-2014-05-05.pdf
> with section 3.2 a bit more detailed.
>
> I will have a go at using the bio0: and bio1: words tomorrow. It's a bit
> late at night to get any more done (with reasonable quality).
> Cheers,
> Peter J.
>
>
> On 05/05/14 13:39, Mikael Nordman wrote:
>> Peter,
>> After a quick scan through, I just noticed some small things.
>>
>> Abstract has wrong PIC18 number
>>
>> 3.2 has the wrong filename and USB filename complaint.
>> I have changed the filename in FF5.0
>>
>> References is missing the FF site.
>>
>> On Atmega the there is also the BIO0: BIO1: words that produce
>> faster code (1 cycle) for IO adressess below $20.
>> The BIT0: and BIT1: words use memory adressing (IO address + $20)
>> I think I will merge these words so that the BIT words compile
>> optimal code also for IO adressess below $20.
>>
>> BR Mike
>>
>> ------------------------------------------------------------------------------
>> Is your legacy SCM system holding you back? Join Perforce May 7 to find out:
>> • 3 signs your SCM is hindering your productivity
>> • Requirements for releasing software faster
>> • Expert tips and advice for migrating your SCM now
>> http://p.sf.net/sfu/perforce
>> _______________________________________________
>> Flashforth-devel mailing list
>> Fla...@li...
>> https://lists.sourceforge.net/lists/listinfo/flashforth-devel
>
> ------------------------------------------------------------------------------
> Is your legacy SCM system holding you back? Join Perforce May 7 to find out:
> • 3 signs your SCM is hindering your productivity
> • Requirements for releasing software faster
> • Expert tips and advice for migrating your SCM now
> http://p.sf.net/sfu/perforce
> _______________________________________________
> Flashforth-devel mailing list
> Fla...@li...
> https://lists.sourceforge.net/lists/listinfo/flashforth-devel

Re: [Flashforth-devel] draft of revised tutorial guide for FF5

[Peter J. <pe...@me...>]

Thanks.  A new version:
http://dropbox.eait.uq.edu.au/e4pjacob/flash-forth/ff5-tutorial-guide-2014-05-05.pdf
with section 3.2 a bit more detailed.

I will have a go at using the bio0: and bio1: words tomorrow. It's a bit 
late at night to get any more done (with reasonable quality).
Cheers,
Peter J.


On 05/05/14 13:39, Mikael Nordman wrote:
> Peter,
> After a quick scan through, I just noticed some small things.
>
> Abstract has wrong PIC18 number
>
> 3.2 has the wrong filename and USB filename complaint.
> I have changed the filename in FF5.0
>
> References is missing the FF site.
>
> On Atmega the there is also the BIO0: BIO1: words that produce
> faster code (1 cycle) for IO adressess below $20.
> The BIT0: and BIT1: words use memory adressing (IO address + $20)
> I think I will merge these words so that the BIT words compile
> optimal code also for IO adressess below $20.
>
> BR Mike
>
> ------------------------------------------------------------------------------
> Is your legacy SCM system holding you back? Join Perforce May 7 to find out:
> • 3 signs your SCM is hindering your productivity
> • Requirements for releasing software faster
> • Expert tips and advice for migrating your SCM now
> http://p.sf.net/sfu/perforce
> _______________________________________________
> Flashforth-devel mailing list
> Fla...@li...
> https://lists.sourceforge.net/lists/listinfo/flashforth-devel

Re: [Flashforth-devel] draft of revised tutorial guide for FF5

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

Peter,
After a quick scan through, I just noticed some small things.

Abstract has wrong PIC18 number

3.2 has the wrong filename and USB filename complaint.
I have changed the filename in FF5.0

References is missing the FF site.

On Atmega the there is also the BIO0: BIO1: words that produce
faster code (1 cycle) for IO adressess below $20.
The BIT0: and BIT1: words use memory adressing (IO address + $20)
I think I will merge these words so that the BIT words compile
optimal code also for IO adressess below $20.

BR Mike

[Flashforth-devel] draft of revised tutorial guide for FF5

[Peter J. <pe...@me...>]

Mike, Pete,
    I've put a first full draft of the tutorial document for FF5 at
http://dropbox.eait.uq.edu.au/e4pjacob/flash-forth/ff5-tutorial-guide-2014-05-04.pdf
Comments most welcome.

Towards the end, I've tried out the bit manipulation words and, when 
inlined, they do achieve full machine speed on the PIC18 and PIC24. 
They're a little slower on the ATmega328, however, they do work nicely.

Along the way I fell over the way the AVR version of FF doesn't like tab 
characters in leading whitespace (indentation).  The PIC18 seems to be 
insensitive to whether there is tab character or space characters for 
that indentation.  It took me a while to realize that the compiler was 
upset by the tab character since the message was that it didn't know my 
word (that had been defined and used earlier).
Cheers,
Peter J.

Re: [Flashforth-devel] empty for PIC24 family

[Pete Z. <pza...@pz...>]

Hi Peter,

If you need any PCB layout or boards for the PIC and FF, remember I use  
PROTEL here for the business.

Just got some more PIC24 sample chips to test FF 5.0 on also.  Will 
report what I find.  I am hoping to end up with an application and board 
for the PIC24FJ64GB104 with USB.

Pete


On 4/30/2014 1:41 AM, Peter Jacobs wrote:
> Coincidentally, I was drawing the schematic for the home-built board in
> the tutorial when your note arrived.
>
> For an almost no-solder option, I think that the Microstick for 5V PIC24
> K-series (DM240013-2) is convenient.  It includes the programmer, built
> onto the board, so you don't need a pickit3. There are pads to mount a
> 6-pin header at the other end of the board that can be used with a
> FTDI-232 cable.
>
> Thanks for looking at empty.  I'll try the fix later tonight.
>
> Cheers,
> Peter J.
>
>

Re: [Flashforth-devel] empty for PIC24 family

[Peter J. <pe...@me...>]

Mike,
With your EEPROM fix, EMPTY now works as advertised on the 
PIC24FV16KM202.  Thank you.

I have a couple of other small changes to your current source file that 
deal with feature differences of the 16KM202.

peterj@helmholtz ~/pic_work/flash-forth/ff5p0-pic24fv32ka-apr-2014/src $ 
diff ff-pic24-30-33.s ../../gitrepo/flashforth-code/PIC24-30-33/src/
804,805d803
< ; PJ 2014-04-19: PIC24FV16KM202 doesn't have the T3MD module disable bit.
< .ifdef T3MD
807d804
< .endif
834,837d830
< .endif
< .ifdecl ANSB
<         ; PJ 2014-04-19: on FV32KA302 and FV16KM202, want digital 
input on U1RX pin
<         clr     ANSB
peterj@helmholtz ~/pic_work/flash-forth/ff5p0-pic24fv32ka-apr-2014/src $

Cheers,
Peter J.



On 30/04/14 15:19, Mikael Nordman wrote:
> There was actually a bug in EMPTY for eeprom devices.
> I need to buy a board for those new PIC24 chips.
> Any recommendations?
> I quess a pickit3 is needed also.
>
> Change empty to this and it should work. /Mike
>
> .ifdef PEEPROM
>           mlit    handle(COLDLIT)+PFLASH
>           mlit    dp_start
>           mlit    coldlitsize
>           rcall   WMOVE
>           clr     intcon1dbg
> .else
>           rcall   DP_COLD
> .endif
>           rcall   DP_TO_RAM
>           return
>
>
>
> ------------------------------------------------------------------------------
> "Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
> Instantly run your Selenium tests across 300+ browser/OS combos.  Get
> unparalleled scalability from the best Selenium testing platform available.
> Simple to use. Nothing to install. Get started now for free."
> http://p.sf.net/sfu/SauceLabs
> _______________________________________________
> Flashforth-devel mailing list
> Fla...@li...
> https://lists.sourceforge.net/lists/listinfo/flashforth-devel

Re: [Flashforth-devel] empty for PIC24 family

[Peter J. <pe...@me...>]

Coincidentally, I was drawing the schematic for the home-built board in 
the tutorial when your note arrived.

For an almost no-solder option, I think that the Microstick for 5V PIC24 
K-series (DM240013-2) is convenient.  It includes the programmer, built 
onto the board, so you don't need a pickit3. There are pads to mount a 
6-pin header at the other end of the board that can be used with a 
FTDI-232 cable.

Thanks for looking at empty.  I'll try the fix later tonight.

Cheers,
Peter J.


On 30/04/14 15:19, Mikael Nordman wrote:
> There was actually a bug in EMPTY for eeprom devices.
> I need to buy a board for those new PIC24 chips.
> Any recommendations?
> I quess a pickit3 is needed also.
>
> Change empty to this and it should work. /Mike
>
> .ifdef PEEPROM
>           mlit    handle(COLDLIT)+PFLASH
>           mlit    dp_start
>           mlit    coldlitsize
>           rcall   WMOVE
>           clr     intcon1dbg
> .else
>           rcall   DP_COLD
> .endif
>           rcall   DP_TO_RAM
>           return
>
>
>
> ------------------------------------------------------------------------------
> "Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
> Instantly run your Selenium tests across 300+ browser/OS combos.  Get
> unparalleled scalability from the best Selenium testing platform available.
> Simple to use. Nothing to install. Get started now for free."
> http://p.sf.net/sfu/SauceLabs
> _______________________________________________
> Flashforth-devel mailing list
> Fla...@li...
> https://lists.sourceforge.net/lists/listinfo/flashforth-devel

Re: [Flashforth-devel] empty for PIC24 family

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

There was actually a bug in EMPTY for eeprom devices.
I need to buy a board for those new PIC24 chips.
Any recommendations?
I quess a pickit3 is needed also.

Change empty to this and it should work. /Mike

.ifdef PEEPROM
         mlit    handle(COLDLIT)+PFLASH
         mlit    dp_start
         mlit    coldlitsize
         rcall   WMOVE
         clr     intcon1dbg
.else
         rcall   DP_COLD
.endif
         rcall   DP_TO_RAM
         return

Re: [Flashforth-devel] empty for PIC24 family

[Peter J. <pe...@me...>]

Mike,
    EMPTY works fine on the PIC18 family but I have yet to try the it on 
any of the other PIC24/dsPIC33 MCUs.

I've put a tarfile of my work area at 
http://dropbox.eait.uq.edu.au/e4pjacob/flash-forth/ff5p0-pic24fv32ka-30-apr-2014.tar.gz

I see the listing file in there as 
ff5p0-pic24fv32ka-apr-2014/FF.X/build/default/production/_ext/1360937237/ff-pic24-30-33.lst
Peter J.


On 30/04/14 05:10, Mikael Nordman wrote:
> Does EMPTY work on the other chips with eeprom that you seem to use ?
>
> Can you post the compilation listing and map files for the not working
> case ?
>
> BR Mike
>
> On 04/28/2014 03:47 PM, Peter Jacobs wrote:
>
>       A small problem that I'm having tonight is that "empty" does not
> seem to reset the dictionary back to its original state of the
> PIC24FV16KM202.  If I put in a marker, I can take the dictionary back to
> the state before that marker, however, I forgot to do that before
> defining a few words and now I don't seem to be able to remove those
> words (short of reprogramming the chip).
>
>
>
>
> ------------------------------------------------------------------------------
> "Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
> Instantly run your Selenium tests across 300+ browser/OS combos.  Get
> unparalleled scalability from the best Selenium testing platform available.
> Simple to use. Nothing to install. Get started now for free."
> http://p.sf.net/sfu/SauceLabs
> _______________________________________________
> Flashforth-devel mailing list
> Fla...@li...
> https://lists.sourceforge.net/lists/listinfo/flashforth-devel

Re: [Flashforth-devel] empty for PIC24 family

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

Does EMPTY work on the other chips with eeprom that you seem to use ?

Can you post the compilation listing and map files for the not working 
case ?

BR Mike

On 04/28/2014 03:47 PM, Peter Jacobs wrote:

     A small problem that I'm having tonight is that "empty" does not
seem to reset the dictionary back to its original state of the
PIC24FV16KM202.  If I put in a marker, I can take the dictionary back to
the state before that marker, however, I forgot to do that before
defining a few words and now I don't seem to be able to remove those
words (short of reprogramming the chip).

Re: [Flashforth-devel] empty for PIC24 family

[Peter J. <pe...@me...>]

Oops... went and read the Hitachi data sheet and implemented the 
initialization by instruction more carefully.  So, just in case someone 
tries to use the code, here is an updated definition.

: lcd-init ( -- )
   data-port-in
   Elo RWlo RSlo
   %00001110 trisa mclr \ RS, RW and E as output
   30 ms \ power-on delay
   \ Begin "initialization by instruction"
   \ Presumably, the LCD is in 8-bit interface mode.
   %0011 put-nibble Estrobe 5 ms
   %0011 put-nibble Estrobe 1 ms
   %0011 put-nibble Estrobe 1 ms
   \ Function set for 4-bit interface; it is still in 8-bit mode.
   %0010 put-nibble Estrobe 1 ms
   \ Now, we should be in 4-bit interface mode.
   \ Function set for 4-bit interface, 2 display lines 5x7 font.
   wait-for-lcd
   %00101000 lcd-putc
   \ Increment cursor after each byte, don't shift display.
   wait-for-lcd
   %00000110 lcd-putc
   \ Display off
   wait-for-lcd
   %00001000 lcd-putc
   \ Display clear
   %00000001 lcd-putc
   5 ms
   \ End of "initialization by instruction"
   \ Enable cursor and display, no blink.
   wait-for-lcd
   %00001110 lcd-putc 1 ms
   wait-for-lcd
;


On 29/04/14 17:25, Peter Jacobs wrote:
> Mike,
>      You're most welcome to the tutorials.  Your FF program has been a
> pleasure to work with.  How did your preparations for introducing FF to
> Finnish children go?
>
>      I see your notes to Pete Zawasky, so I'll try to experiment with the
> PIC24 again, once I have the tutorial sections complete for the PIC18.
> Checking that the eeprom is erased when first flashing the chip might be
> a good start.
>
>     I've used your bit0: and bit1: words in the LCD demo that I built
> today.  (See below.)  They seem to work nicely (on a PIC18F46K22).
> Cheers,
> Peter J.
>
> \ Exercise LCD on PICDEM2+ board.
> \ Remember to load bit.txt before this file.
> -xlcd
> marker -xlcd
>
> $ff80 constant porta
> $ff89 constant lata
> $ff92 constant trisa
> $ff83 constant portd
> $ff8c constant latd
> $ff95 constant trisd
>
> \ The LCD is operated in nibble mode.
> \ RA1 = Enable (E) pin
> \ RA2 = Read/Write (RW) pin
> \ RA3 = Register Select (RS) pin
> \ RD0 = DB4 on LCD
> \ RD1 = DB5
> \ RD2 = DB6
> \ RD3 = DB7
>
> portd constant dataport
> lata #1 bit0: Elo
> lata #1 bit1: Ehi
> lata #2 bit0: RWlo
> lata #2 bit1: RWhi
> lata #3 bit0: RSlo
> lata #3 bit1: RShi
>
> : data-port-in ( -- )
>     trisd c@ $0f or trisd c!
> ;
>
> : data-port-out ( -- )
>     trisd c@ $f0 and trisd c!
> ;
>
> : put-nibble ( c -- )
>     \ Make lower 4 bits of c appear on data port pins.
>     $0f and
>     dataport c@ $f0 and
>     or
>     dataport c!
> ;
>
> : short-delay ( -- )
>     18 for r@ drop next ;
>
> : Estrobe ( -- )
>     Ehi short-delay Elo
> ;
>
> : lcd-getc ( -- c )
>     \ Read the LCD register in two nibbles.
>     \ Remember to select the register line before calling this word.
>     data-port-in
>     RWhi short-delay
>     Ehi short-delay dataport c@ #4 lshift Elo short-delay \ high nibble
>     Ehi short-delay dataport c@ Elo short-delay \ low nibble
>     or \ assemble full byte and leave it on the stack
>     RWlo short-delay
> ;
>
> : lcd-ready? ( -- f )
>     \ Read the command register and check busy bit.
>     RSlo short-delay
>     lcd-getc $80 and 0=
> ;
>
> : wait-for-lcd ( -- )
>     begin lcd-ready? cwd until
> ;
>
> : lcd-putc ( c -- )
>     \ Write the LCD register in two nibbles.
>     \ Remember to select the register line before calling this word.
>     dup $f0 and #4 rshift \ high nibble left on top of stack
>     data-port-out
>     RWlo short-delay
>     put-nibble short-delay Estrobe short-delay
>     $0f and \ low nibble now left on top of stack
>     put-nibble short-delay Estrobe short-delay
>     data-port-in
> ;
>
> : lcd-clear ( -- )
>     wait-for-lcd
>     RSlo short-delay
>     %00000001 lcd-putc
> ;
>
> : lcd-home ( -- )
>     wait-for-lcd
>     RSlo short-delay
>     %00000010 lcd-putc
> ;
>
> : lcd-goto ( c -- )
>     \ Set the specified 7-bit data memory address.
>     wait-for-lcd
>     RSlo short-delay
>     $80 or \ sets the highest bit for the command
>     lcd-putc
> ;
>
> : lcd-init ( -- )
>     data-port-in
>     Elo RWlo RSlo
>     %00001110 trisa mclr \ RS, RW and E as output
>     30 ms \ power-on delay
>     %0010 put-nibble Estrobe 5 ms
>     %0010 put-nibble Estrobe 1 ms
>     %0010 put-nibble Estrobe 1 ms
>     data-port-in
>     \ Set LCD for 4-bit interface, 2 display lines 5x7 font.
>     wait-for-lcd
>     %00101000 lcd-putc 5 ms
>     \ Increment cursor after each byte, don't shift display.
>     wait-for-lcd
>     %00000110 lcd-putc 5 ms
>     \ Enable cursor and display, no blink.
>     wait-for-lcd
>     %00001110 lcd-putc 5 ms
>     lcd-clear 5 ms
>     wait-for-lcd
> ;
>
> : lcd-emit ( c -- ) \ Write the byte into data memory.
>     wait-for-lcd
>     RShi short-delay
>     lcd-putc
> ;
>
> : lcd-type ( c-addr n -- ) \ send string
>     for c@+ lcd-emit next
>     drop
> ;
>
> : main
>     ." Begin..."
>     lcd-init
>     cr ." lcd-init done."
>     s" Hello from" lcd-type
>     $40 lcd-goto
>     s" FlashForth 5.0" lcd-type
>     cr ." exercise done."
> ;
>
>

Re: [Flashforth-devel] empty for PIC24 family

[Peter J. <pe...@me...>]

Mike,
    You're most welcome to the tutorials.  Your FF program has been a 
pleasure to work with.  How did your preparations for introducing FF to 
Finnish children go?

    I see your notes to Pete Zawasky, so I'll try to experiment with the 
PIC24 again, once I have the tutorial sections complete for the PIC18.  
Checking that the eeprom is erased when first flashing the chip might be 
a good start.

   I've used your bit0: and bit1: words in the LCD demo that I built 
today.  (See below.)  They seem to work nicely (on a PIC18F46K22).
Cheers,
Peter J.

\ Exercise LCD on PICDEM2+ board.
\ Remember to load bit.txt before this file.
-xlcd
marker -xlcd

$ff80 constant porta
$ff89 constant lata
$ff92 constant trisa
$ff83 constant portd
$ff8c constant latd
$ff95 constant trisd

\ The LCD is operated in nibble mode.
\ RA1 = Enable (E) pin
\ RA2 = Read/Write (RW) pin
\ RA3 = Register Select (RS) pin
\ RD0 = DB4 on LCD
\ RD1 = DB5
\ RD2 = DB6
\ RD3 = DB7

portd constant dataport
lata #1 bit0: Elo
lata #1 bit1: Ehi
lata #2 bit0: RWlo
lata #2 bit1: RWhi
lata #3 bit0: RSlo
lata #3 bit1: RShi

: data-port-in ( -- )
   trisd c@ $0f or trisd c!
;

: data-port-out ( -- )
   trisd c@ $f0 and trisd c!
;

: put-nibble ( c -- )
   \ Make lower 4 bits of c appear on data port pins.
   $0f and
   dataport c@ $f0 and
   or
   dataport c!
;

: short-delay ( -- )
   18 for r@ drop next ;

: Estrobe ( -- )
   Ehi short-delay Elo
;

: lcd-getc ( -- c )
   \ Read the LCD register in two nibbles.
   \ Remember to select the register line before calling this word.
   data-port-in
   RWhi short-delay
   Ehi short-delay dataport c@ #4 lshift Elo short-delay \ high nibble
   Ehi short-delay dataport c@ Elo short-delay \ low nibble
   or \ assemble full byte and leave it on the stack
   RWlo short-delay
;

: lcd-ready? ( -- f )
   \ Read the command register and check busy bit.
   RSlo short-delay
   lcd-getc $80 and 0=
;

: wait-for-lcd ( -- )
   begin lcd-ready? cwd until
;

: lcd-putc ( c -- )
   \ Write the LCD register in two nibbles.
   \ Remember to select the register line before calling this word.
   dup $f0 and #4 rshift \ high nibble left on top of stack
   data-port-out
   RWlo short-delay
   put-nibble short-delay Estrobe short-delay
   $0f and \ low nibble now left on top of stack
   put-nibble short-delay Estrobe short-delay
   data-port-in
;

: lcd-clear ( -- )
   wait-for-lcd
   RSlo short-delay
   %00000001 lcd-putc
;

: lcd-home ( -- )
   wait-for-lcd
   RSlo short-delay
   %00000010 lcd-putc
;

: lcd-goto ( c -- )
   \ Set the specified 7-bit data memory address.
   wait-for-lcd
   RSlo short-delay
   $80 or \ sets the highest bit for the command
   lcd-putc
;

: lcd-init ( -- )
   data-port-in
   Elo RWlo RSlo
   %00001110 trisa mclr \ RS, RW and E as output
   30 ms \ power-on delay
   %0010 put-nibble Estrobe 5 ms
   %0010 put-nibble Estrobe 1 ms
   %0010 put-nibble Estrobe 1 ms
   data-port-in
   \ Set LCD for 4-bit interface, 2 display lines 5x7 font.
   wait-for-lcd
   %00101000 lcd-putc 5 ms
   \ Increment cursor after each byte, don't shift display.
   wait-for-lcd
   %00000110 lcd-putc 5 ms
   \ Enable cursor and display, no blink.
   wait-for-lcd
   %00001110 lcd-putc 5 ms
   lcd-clear 5 ms
   wait-for-lcd
;

: lcd-emit ( c -- ) \ Write the byte into data memory.
   wait-for-lcd
   RShi short-delay
   lcd-putc
;

: lcd-type ( c-addr n -- ) \ send string
   for c@+ lcd-emit next
   drop
;

: main
   ." Begin..."
   lcd-init
   cr ." lcd-init done."
   s" Hello from" lcd-type
   $40 lcd-goto
   s" FlashForth 5.0" lcd-type
   cr ." exercise done."
;



On 29/04/14 05:04, Mikael Nordman wrote:
> Hi Peter,
> I have been meaning to thank you for tutorials.
>
> Thank you !
>
> I have not run the PIC24 code for a while on a chip with eeprom.
> Probably the empty values are wrong somehow.
> This could be related to some compile time configuration issue.
> I cannot check it right now.
>
> I don't remember why bit parameters between PIC24 and PIC18 are reversed.
> Pure happenstance and sloppy thinking from my part...
>
> You could also test the new BIT0: and BIT1: words while you are at it.
> These are the same on all three architectures.
> The speed when inlined should be the same as for pure assembly.
>
> BR Mike
>
> On 04/28/2014 03:47 PM, Peter Jacobs wrote:
>> Mike,
>>       I'm having a bit of fun updating the tutorials and extending them (a
>> little) to the other architectures to which you've ported FF.
>>
>>       A small problem that I'm having tonight is that "empty" does not
>> seem to reset the dictionary back to its original state of the
>> PIC24FV16KM202.  If I put in a marker, I can take the dictionary back to
>> the state before that marker, however, I forgot to do that before
>> defining a few words and now I don't seem to be able to remove those
>> words (short of reprogramming the chip).
>>
>>       Also, for the assembler words bset, and bclr, the order of bit and
>> register-address arguments seem to be the reverse of the PIC18 family.
>> Why is that?  (Just asking out of curiosity and, since I know almost
>> nothing about the assembly language of these machines, I don't mind
>> being told to read the docs.)
>>
>> Regards,
>> Peter J.
>>
>> -speed-test
>> marker -speed-test
>> \ For the PIC24FV16KM202, waggle RB15 as quickly as we can,
>> \ in both high- and low-level code.
>>
>> $02c8 constant trisb
>> $02ca constant portb
>> $02cc constant latb
>> $02ce constant odcb
>>
>> 1 #15 lshift constant bit15
>>
>> : initRB15
>>      bit15 trisb mclr \ RB15 as output
>>      bit15 latb mclr \ initially known state
>> ;
>>
>> \ high-level bit fiddling, presumably slow
>> : blink-forth ( -- )
>>      initRB15
>>      begin
>>        bit15 latb ! 0 latb ! \ one cycle, on and off
>>        bit15 latb ! 0 latb !
>>        bit15 latb ! 0 latb !
>>        bit15 latb ! 0 latb !
>>        cwd \ We have to kick the watch dog ourselves.
>>      again
>> ;
>>
>> \ low-level bit fiddling, via assembler
>> : blink-asm ( -- )
>>      initRB15
>>      [
>>      begin,
>>        #15 latb bset,  #15 latb bclr, \ one cycle, on and off
>>        #15 latb bset,  #15 latb bclr,
>>        #15 latb bset,  #15 latb bclr,
>>        #15 latb bset,  #15 latb bclr,
>>        ] cwd [ \ kick the watch dog
>>      again,
>>      ]
>> ;
>>
>>
>>
>> ------------------------------------------------------------------------------
>> "Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
>> Instantly run your Selenium tests across 300+ browser/OS combos.  Get
>> unparalleled scalability from the best Selenium testing platform available.
>> Simple to use. Nothing to install. Get started now for free."
>> http://p.sf.net/sfu/SauceLabs
>> _______________________________________________
>> Flashforth-devel mailing list
>> Fla...@li...
>> https://lists.sourceforge.net/lists/listinfo/flashforth-devel
>>
>
> ------------------------------------------------------------------------------
> "Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
> Instantly run your Selenium tests across 300+ browser/OS combos.  Get
> unparalleled scalability from the best Selenium testing platform available.
> Simple to use. Nothing to install. Get started now for free."
> http://p.sf.net/sfu/SauceLabs
> _______________________________________________
> Flashforth-devel mailing list
> Fla...@li...
> https://lists.sourceforge.net/lists/listinfo/flashforth-devel

Re: [Flashforth-devel] FF 5.0 and the DM300027 Demo Board with PIC24FJ64GA002

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

The reason you cannot see MARKER initially must be
that LATEST has the wrong value.
Since EMPTY works I believe that you do not
erase the flash before programming the hex file to the device.

The start routine checks if TURNKEY in the 4K flash sector
is $ffff. If it is $ffff, EMPTY is executed.

The 4K flash area is used for eeprom emulation for
- latest
- flash dp
- ram dp
- turnkey

The 4K flash area (6K with the upper byte) is there only on devices 
without eeprom.
It's a bit large, but it was the simplest implementation with one flash 
sector used per variable.

On eeprom devices, correct initialisation depends on that the eeprom has 
been
erased to $ffff before burning the hex file.

The alternative is to execute EMPTY  to correct the system pointers.

It is really bad that Microchip has not fixed the listing bug in XC16.
They fixed it in ASM30 on my request.

BR Mike

[Flashforth-devel] FF 5.0 and the DM300027 Demo Board with PIC24FJ64GA002

[Pete Z. <pza...@pz...>]

Hi Mikael and Peter,

FF 5.0 is looking very good here on a 16-bit PIC with no eeprom.

So far I have noticed:
   1. Could not assemble successfully with MPLAB X ver 2.05 until I 
remembered your (Mikael's) comment on the WIKI regarding the enable of 
the listing output.  OK now.

   2. The word marker does not show up in the words list after loading 
FF to the mcu, whether or not power was cycled to the board, until after 
the first empty is executed.  The first empty does however remove any 
newly defined words on this device and then marker shows up in the words 
list.

Mikael...Could you comment on the use of the 4K flash space between 
marker and the first user defined word?  Is it there on all the 16-bit 
devices or just the no-eeprom devices?

Looking forward to staying with the 16-bit PIC chips for FF for a while. 
Excellent combination.

Pete

Re: [Flashforth-devel] empty for PIC24 family

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

Hi Peter,
I have been meaning to thank you for tutorials.

Thank you !

I have not run the PIC24 code for a while on a chip with eeprom.
Probably the empty values are wrong somehow.
This could be related to some compile time configuration issue.
I cannot check it right now.

I don't remember why bit parameters between PIC24 and PIC18 are reversed.
Pure happenstance and sloppy thinking from my part...

You could also test the new BIT0: and BIT1: words while you are at it.
These are the same on all three architectures.
The speed when inlined should be the same as for pure assembly.

BR Mike

On 04/28/2014 03:47 PM, Peter Jacobs wrote:
> Mike,
>      I'm having a bit of fun updating the tutorials and extending them (a
> little) to the other architectures to which you've ported FF.
>
>      A small problem that I'm having tonight is that "empty" does not
> seem to reset the dictionary back to its original state of the
> PIC24FV16KM202.  If I put in a marker, I can take the dictionary back to
> the state before that marker, however, I forgot to do that before
> defining a few words and now I don't seem to be able to remove those
> words (short of reprogramming the chip).
>
>      Also, for the assembler words bset, and bclr, the order of bit and
> register-address arguments seem to be the reverse of the PIC18 family.
> Why is that?  (Just asking out of curiosity and, since I know almost
> nothing about the assembly language of these machines, I don't mind
> being told to read the docs.)
>
> Regards,
> Peter J.
>
> -speed-test
> marker -speed-test
> \ For the PIC24FV16KM202, waggle RB15 as quickly as we can,
> \ in both high- and low-level code.
>
> $02c8 constant trisb
> $02ca constant portb
> $02cc constant latb
> $02ce constant odcb
>
> 1 #15 lshift constant bit15
>
> : initRB15
>     bit15 trisb mclr \ RB15 as output
>     bit15 latb mclr \ initially known state
> ;
>
> \ high-level bit fiddling, presumably slow
> : blink-forth ( -- )
>     initRB15
>     begin
>       bit15 latb ! 0 latb ! \ one cycle, on and off
>       bit15 latb ! 0 latb !
>       bit15 latb ! 0 latb !
>       bit15 latb ! 0 latb !
>       cwd \ We have to kick the watch dog ourselves.
>     again
> ;
>
> \ low-level bit fiddling, via assembler
> : blink-asm ( -- )
>     initRB15
>     [
>     begin,
>       #15 latb bset,  #15 latb bclr, \ one cycle, on and off
>       #15 latb bset,  #15 latb bclr,
>       #15 latb bset,  #15 latb bclr,
>       #15 latb bset,  #15 latb bclr,
>       ] cwd [ \ kick the watch dog
>     again,
>     ]
> ;
>
>
>
> ------------------------------------------------------------------------------
> "Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
> Instantly run your Selenium tests across 300+ browser/OS combos.  Get
> unparalleled scalability from the best Selenium testing platform available.
> Simple to use. Nothing to install. Get started now for free."
> http://p.sf.net/sfu/SauceLabs
> _______________________________________________
> Flashforth-devel mailing list
> Fla...@li...
> https://lists.sourceforge.net/lists/listinfo/flashforth-devel
>

[Flashforth-devel] empty for PIC24 family

[Peter J. <pe...@me...>]

Mike,
    I'm having a bit of fun updating the tutorials and extending them (a 
little) to the other architectures to which you've ported FF.

    A small problem that I'm having tonight is that "empty" does not 
seem to reset the dictionary back to its original state of the 
PIC24FV16KM202.  If I put in a marker, I can take the dictionary back to 
the state before that marker, however, I forgot to do that before 
defining a few words and now I don't seem to be able to remove those 
words (short of reprogramming the chip).

    Also, for the assembler words bset, and bclr, the order of bit and 
register-address arguments seem to be the reverse of the PIC18 family.  
Why is that?  (Just asking out of curiosity and, since I know almost 
nothing about the assembly language of these machines, I don't mind 
being told to read the docs.)

Regards,
Peter J.

-speed-test
marker -speed-test
\ For the PIC24FV16KM202, waggle RB15 as quickly as we can,
\ in both high- and low-level code.

$02c8 constant trisb
$02ca constant portb
$02cc constant latb
$02ce constant odcb

1 #15 lshift constant bit15

: initRB15
   bit15 trisb mclr \ RB15 as output
   bit15 latb mclr \ initially known state
;

\ high-level bit fiddling, presumably slow
: blink-forth ( -- )
   initRB15
   begin
     bit15 latb ! 0 latb ! \ one cycle, on and off
     bit15 latb ! 0 latb !
     bit15 latb ! 0 latb !
     bit15 latb ! 0 latb !
     cwd \ We have to kick the watch dog ourselves.
   again
;

\ low-level bit fiddling, via assembler
: blink-asm ( -- )
   initRB15
   [
   begin,
     #15 latb bset,  #15 latb bclr, \ one cycle, on and off
     #15 latb bset,  #15 latb bclr,
     #15 latb bset,  #15 latb bclr,
     #15 latb bset,  #15 latb bclr,
     ] cwd [ \ kick the watch dog
   again,
   ]
;

Re: [Flashforth-devel] FF5.0 on PIC24FV32KA302 -- a couple of issues

[Peter J. <pe...@me...>]

It works very nicely, thank you Mike.

The PIC24FV32KA302 rev 4 chip transmits reliably only with the 
unbuffered option.

The PIC24FV16KM202 works with the default buffered option, however, I've 
had to make a small edit to the include ff30.inc file to get the 
assembler to include the p24f16ka_config file. Surprisingly to me, this 
KM chip seems to be assigned to the __PIC24F family by the assembler.  
The most changes went into the p24f16ka_config file so that I could 
select the different chips via the MPLABX project properties, however, 
these don't amount to much.

There are also another couple of small edits needed to the main 
ff-pic24-30-33.s file to accommodate these chips.

I've put a complete copy of my current work tree at
http://dropbox.eait.uq.edu.au/e4pjacob/flash-forth/ff5p0-pic24fv32ka-apr-2014.tar.gz
if you would like to pick the changes out.  Alternatively, should I make 
a patch against your git repository?

I'm still doing something wrong with the PLL, but that is for another 
day.  The unbuffered TX option allows me to continue at the moment.
Cheers,
Peter J.



On 19/04/14 06:48, Mikael Nordman wrote:
> Peter,
> I just pushed a FlashForth without UART TX buffering.
>
> Could you test how it works ?
>
> BR Mike
>
> ------------------------------------------------------------------------------
> Learn Graph Databases - Download FREE O'Reilly Book
> "Graph Databases" is the definitive new guide to graph databases and their
> applications. Written by three acclaimed leaders in the field,
> this first edition is now available. Download your free book today!
> http://p.sf.net/sfu/NeoTech
> _______________________________________________
> Flashforth-devel mailing list
> Fla...@li...
> https://lists.sourceforge.net/lists/listinfo/flashforth-devel

Re: [Flashforth-devel] FF5.0 on PIC24FV32KA302 -- a couple of issues

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

Peter,
I just pushed a FlashForth without UART TX buffering.

Could you test how it works ?

BR Mike

Re: [Flashforth-devel] FF5.0 on PIC24FV32KA302 -- a couple of issues

[Peter J. <pe...@me...>]

Yes, the delay works nicely. Nothing missed in the following transcript, 
I believe.
Thank you.
Peter J


BPE FlashForth PIC24 5.0

2 3 * . 6  ok<#,ram>
   ok<#,ram>
   ok<#,ram>
words
true    false    Fcy    dump    allot    .s    words ms
ticks    r0    s0    latest    rhere    state    bl rdrop
endit    next    for    repeat    while    again until    begin
else    then    if    until,    again,    begin, else,    then,
if,    not,    nc,    z,    un,    in,    inline    [']
;i    ;    :noname    :    ]    [    does>    postpone
create    [char]    (    char    '    abort"    ?abort ?abort?
abort    prompt    quit    >dp    dp>    .st inlined    immediate
shb    interpret    in?    'source    >in    tiu tib    ti#
number?    >number    sign?    digit?    find immed?    (f)    c>n
n>c    @+    c@+    place    wmove    cmove    fill blanks
erase    word    parse    \    /string    source base    pad
hp    task    ssave    rsave    ulink    bin    hex decimal
hi    d.    ud.    .    u.r    u.    sign    #>
#s    #    >digit    <#    hold    up    min    max
?negate    tuck    nip    ud/mod    ud*    /    */ */mod
u*/mod    u/    *    u>    u<    d>    > d<
<    d=    =    <>    within    +!    ."    ,"
s"    (s")    type    >pr    .id    accept    1    0
umax    umin    spaces    space    cr    2dup    2drop 2!
2@    chars    char+    cells    cell+    aligned align    cell
c,    ,    here    dp    ram    eeprom    flash    xa>
 >xa    pfl    2constant    constant    co: 2variablevariable    >body
to    is    defer    value    user    mod    /mod u/mod
sm/rem    um/mod    m*    um*    s>d    p++    p2+ p+
pc!    p!    pc@    p@    @p    r>p    !p>r    !p
d0<    0<    d0=    0=    d2/    2/    d2*    2*
2-    1-    2+    1+    ?dnegate    dnegate    negate dinvert
invert    xor    or    and    d-    -    d+    m+
+    dabs    abs    r@    r>    >r    rot    over
swap    drop    rp0    rp@    sp@    sp!    (d)    (c)
exit    @ex    execute    dup    rx1?    rx1    tx1? tx1
u1rxq    u1txq    cq:    cq0    cq>?    cq> >cq?    >cq
'key?    'key    'emit    key?    key    emit    scan skip
n=    rshift    lshift    btst    bclr    bset    mtst mclr
mset    c@    @    c!    !    u1-    u1+    fl-
fl+    iflush    cf,    as,    cf@    cf!    btss, btsc,
btst,    bset,    bclr,    as0    bra,    retfie, return,    rcall,
operator    ei    di    i]    [i    aivt    ivt    int!
cwd    pause    turnkey    warm    empty    load busy    idle
a>    >a    literal
marker     ok<#,ram>



On 18/04/14 16:42, Mikael Nordman wrote:
> To verify that the UART errata is the problem
> insert a 1 or 2 millisecond delay in EMIT.
>
> EMIT:
>           mlit    2
>           rcall   MS
>           rcall   UEMIT
>           goto    FEXECUTE
>
> If it works, then it is clear that the UART TX interrupts cannot be
> trusted on  your chip.
>
> This can also be used as a simple workaround.
>
> I will also write polling TX routines that do not use interrupts.
> It only checks the TRMT flag. I think that should work with the UART bug.
>
> BR Mike
>
>
>
> ------------------------------------------------------------------------------
> Learn Graph Databases - Download FREE O'Reilly Book
> "Graph Databases" is the definitive new guide to graph databases and their
> applications. Written by three acclaimed leaders in the field,
> this first edition is now available. Download your free book today!
> http://p.sf.net/sfu/NeoTech
> _______________________________________________
> Flashforth-devel mailing list
> Fla...@li...
> https://lists.sourceforge.net/lists/listinfo/flashforth-devel

Re: [Flashforth-devel] FF5.0 on PIC24FV32KA302 -- a couple of issues

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

To verify that the UART errata is the problem
insert a 1 or 2 millisecond delay in EMIT.

EMIT:
         mlit    2
         rcall   MS
         rcall   UEMIT
         goto    FEXECUTE

If it works, then it is clear that the UART TX interrupts cannot be 
trusted on  your chip.

This can also be used as a simple workaround.

I will also write polling TX routines that do not use interrupts.
It only checks the TRMT flag. I think that should work with the UART bug.

BR Mike