flashforth-devel Mailing List for FlashForth: for PIC and Atmega (Page 31)
Brought to you by:
oh2aun
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...@pp...> - 2014-05-08 21:01:06
|
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. > > |
From: Mikael N. <mik...@pp...> - 2014-05-08 19:27:49
|
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 |
From: Simon B. <sim...@ho...> - 2014-05-08 18:45:09
|
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. |
From: Peter J. <pe...@me...> - 2014-05-06 12:29:06
|
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 |
From: Pete Z. <pza...@pz...> - 2014-05-06 01:16:25
|
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. > > > |
From: Peter J. <pe...@me...> - 2014-05-06 00:28:23
|
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 |
From: Peter J. <pe...@me...> - 2014-05-05 13:48:36
|
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 |
From: Mikael N. <mik...@pp...> - 2014-05-05 03:39:49
|
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 |
From: Peter J. <pe...@me...> - 2014-05-04 13:01:28
|
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. |
From: Pete Z. <pza...@pz...> - 2014-05-02 16:16:49
|
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. > > |
From: Peter J. <pe...@me...> - 2014-04-30 22:51:58
|
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 |
From: Peter J. <pe...@me...> - 2014-04-30 05:42:08
|
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 |
From: Mikael N. <mik...@pp...> - 2014-04-30 05:19:42
|
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 |
From: Peter J. <pe...@me...> - 2014-04-29 21:55:42
|
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 |
From: Mikael N. <mik...@pp...> - 2014-04-29 19:11:02
|
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). |
From: Peter J. <pe...@me...> - 2014-04-29 12:48:03
|
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." > ; > > |
From: Peter J. <pe...@me...> - 2014-04-29 07:25:44
|
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 |
From: Mikael N. <mik...@pp...> - 2014-04-29 04:51:11
|
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 |
From: Pete Z. <pza...@pz...> - 2014-04-28 20:59:28
|
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 |
From: Mikael N. <mik...@pp...> - 2014-04-28 19:25:18
|
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 > |
From: Peter J. <pe...@me...> - 2014-04-28 12:47:19
|
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, ] ; |
From: Peter J. <pe...@me...> - 2014-04-19 03:41:01
|
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 |
From: Mikael N. <mik...@pp...> - 2014-04-18 20:48:23
|
Peter, I just pushed a FlashForth without UART TX buffering. Could you test how it works ? BR Mike |
From: Peter J. <pe...@me...> - 2014-04-18 07:34:46
|
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 |
From: Mikael N. <mik...@pp...> - 2014-04-18 06:42:54
|
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 |