flashforth-devel Mailing List for FlashForth: for PIC and Atmega (Page 15)
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: Pete Z. <pza...@pz...> - 2017-03-12 17:30:07
|
Hi Mikael, Hope all is well. Thank you for continuing to update FF for the PICs. I am working on another project for the p24f23ka302 and need some advice. The current development tool is MPLABX v3.51 with XC16 v1.31. The latest src file is ff_pic24-30-33.s (03/11/2017). Since you changed ibase to ibasel and ibaseh and iaddr to iaddrl and iaddrh, I get successful builds and generate HEX files that load successfully into the p24f23ka302 with a PICkit 3. However, FF starts and the kernel words seem to run fine except that I can not define new words. Any new definition (e.g. : test ; ) returns AS and reboots FF . If I return all words using ibasel, ibaseh, iaddrl, and iaddrh to their original definitions using ibase and iaddr then all seems OK with all your other changes to date. Any thoughts? Pete |
From: Peter J. <pe...@me...> - 2017-02-06 12:13:38
|
Mikael, I've put a PDF document up at https://outbox.eait.uq.edu.au/e4pjacob/flash-forth/elements-of-flash-forth-5-2017-02-06.pdf It should be up to date for FlashForth 5 but I have not yet printed it and checked it carefully. That will be tomorrow's job. Cheers, Peter J. |
From: Peter J. <pe...@me...> - 2017-02-06 11:27:40
|
Oh, very good to know (and be reminded). Thanks. Peter J. On 06/02/17 20:31, Mikael Nordman wrote: > You need to consider that the interpreter and number conversion uses the > missing 6 or 7 cells. > > That's why get the behaviour. > > BR Mikael > > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, SlashDot.org! http://sdm.link/slashdot > _______________________________________________ > Flashforth-devel mailing list > Fla...@li... > https://lists.sourceforge.net/lists/listinfo/flashforth-devel |
From: Mikael N. <mik...@fl...> - 2017-02-06 10:32:05
|
You need to consider that the interpreter and number conversion uses the missing 6 or 7 cells. That's why get the behaviour. BR Mikael |
From: Peter J. <pe...@me...> - 2017-02-06 06:59:02
|
OK, but I expected a few (6) more cells before overflow. warm S FlashForth 5 PIC18F26K22 11.11.2016 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 ok<#,ram>0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 ? Peter J. On 06/02/17 15:45, Mikael Nordman wrote: > It is not a bug, > The parameter stack overflows into the terminal input buffer. > That happens on PIC18 and PIC24. > On Atmega the parameter stack overflows into the return stack. > > BR Mikael > > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, SlashDot.org! http://sdm.link/slashdot > _______________________________________________ > Flashforth-devel mailing list > Fla...@li... > https://lists.sourceforge.net/lists/listinfo/flashforth-devel |
From: Mikael N. <mik...@fl...> - 2017-02-06 05:46:02
|
It is not a bug, The parameter stack overflows into the terminal input buffer. That happens on PIC18 and PIC24. On Atmega the parameter stack overflows into the return stack. BR Mikael |
From: Peter J. <pe...@me...> - 2017-02-05 23:11:44
|
Mikael, I was updating the Elements of FlashForth document (after a long pause) and was checking to see what would happen as I filled up the parameter stack to the maximum of 26 elements for FF5 on a PIC18. I get to the 20th element and the behaviour surprises me. I had expected to be able to accumulate 26 elements because of the line #define PARAMETER_STACK_SIZE d'52' ; 26 cells parameter stack in p18f-main.cfg. 0 ok<#,ram>0 1 ok<#,ram>0 1 2 ok<#,ram>0 1 2 3 ok<#,ram>0 1 2 3 4 ok<#,ram>0 1 2 3 4 5 ok<#,ram>0 1 2 3 4 5 6 ok<#,ram>0 1 2 3 4 5 6 7 ok<#,ram>0 1 2 3 4 5 6 7 8 ok<#,ram>0 1 2 3 4 5 6 7 8 9 ok<#,ram>0 1 2 3 4 5 6 7 8 9 10 ok<#,ram>0 1 2 3 4 5 6 7 8 9 10 11 ok<#,ram>0 1 2 3 4 5 6 7 8 9 10 11 12 ok<#,ram>0 1 2 3 4 5 6 7 8 9 10 11 12 13 ok<#,ram>0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 ok<#,ram>0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 ok<#,ram>0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 ok<#,ram>0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 ok<#,ram>0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 ok<#,ram>0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 123456781518 ? 19 ok<#,ram>19 Is this a bug? Should there be a message to say that the stack has overflowed along with the "?" ? Regards, Peter Jacobs |
From: Joe E. <je...@bo...> - 2017-02-02 05:25:07
|
Indeed, thankyou. On Wed, 01 Feb 2017 18:42:34 +0100 zd...@al... wrote: > "bset" is not equal to "bset," > > > > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, SlashDot.org! http://sdm.link/slashdot > _______________________________________________ > Flashforth-devel mailing list > Fla...@li... > https://lists.sourceforge.net/lists/listinfo/flashforth-devel > |
From: <zd...@al...> - 2017-02-01 18:37:01
|
"bset" is not equal to "bset," |
From: Joe E. <je...@bo...> - 2017-02-01 14:56:38
|
On Wed, 01 Feb 2017 11:14:38 +0200 Mikael Nordman <mik...@fl...> wrote: > I removed those, there is still mset mclr mtst bset, bclr, btst, > btsc, btss, available. but: ok<#,ram> $0242 8 bset bset ? words shows that bset is in the dictionary as you say. -- joe |
From: Mikael N. <mik...@fl...> - 2017-02-01 09:14:51
|
I removed those, there is still mset mclr mtst bset, bclr, btst, btsc, btss, available. -- Mikael |
From: Joe E. <je...@bo...> - 2017-02-01 00:28:02
|
I updated to FlashForth 5 PIC24 07.01.2017 and: bset, bclr do not work anymore. ---- ok<#,ram> $0242 8 bset bset ? -- joe |
From: Joe E. <je...@bo...> - 2017-01-19 18:14:39
|
Yep, should have known I couldn't move straight across from 18f to 33e. I'm having gobs of fun w/ 5.0 on 33e! Thanks Mike. -- joe On Thu, 19 Jan 2017 07:30:08 +0200 Mikael Nordman <mik...@fl...> wrote: > You need to ALIGN the flash dictionary pointer after you've created > the list in flash. > > HERE would have shown you an uneven address after the last C, > > The 16-bit PIC throws an hardware address exception for an > unaligned word write to the flash buffer in ram. > > Mike > > > On 2017-01-19 02:21, Joe Ennis wrote: > > Came up against one that has me puzzled: > > > > Say I create a char list in flash with > > > > hex flash create foo 1b c, f2 c, 57 c, ram > > > > then if I try to define some word > > > > : bar .s ; > > > > I get "warm" with an address and software reset error. > > > > All this works fine if I substitute ram for flash above. > > Is it not possible to create a list in flash? > > > > Or is there a better way to create a read only list that > > is available across power cycles? > > > > -- > > joe > > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, SlashDot.org! http://sdm.link/slashdot > _______________________________________________ > Flashforth-devel mailing list > Fla...@li... > https://lists.sourceforge.net/lists/listinfo/flashforth-devel |
From: Mikael N. <mik...@fl...> - 2017-01-19 05:30:18
|
You need to ALIGN the flash dictionary pointer after you've created the list in flash. HERE would have shown you an uneven address after the last C, The 16-bit PIC throws an hardware address exception for an unaligned word write to the flash buffer in ram. Mike On 2017-01-19 02:21, Joe Ennis wrote: > Came up against one that has me puzzled: > > Say I create a char list in flash with > > hex flash create foo 1b c, f2 c, 57 c, ram > > then if I try to define some word > > : bar .s ; > > I get "warm" with an address and software reset error. > > All this works fine if I substitute ram for flash above. > Is it not possible to create a list in flash? > > Or is there a better way to create a read only list that > is available across power cycles? > > -- > joe |
From: Joe E. <je...@bo...> - 2017-01-19 00:41:03
|
Came up against one that has me puzzled: Say I create a char list in flash with hex flash create foo 1b c, f2 c, 57 c, ram then if I try to define some word : bar .s ; I get "warm" with an address and software reset error. All this works fine if I substitute ram for flash above. Is it not possible to create a list in flash? Or is there a better way to create a read only list that is available across power cycles? -- joe |
From: Eugene <en...@ni...> - 2017-01-17 20:43:13
|
I did try 9600, same results. I should have replied last night to Mikael's e-mail from a couple days ago, changing the clock to 16000000 worked, I had overlooked it. Thanks On 01/17/2017 02:28 PM, Colin Tree wrote: > > 9600 > > > On 01/15/2017 08:39 AM, Eugene wrote: >> Hello all, >> >> I have downloaded and installed FlashForth on a PIC18f45k20 (on the >> Microchip 44 pin demo board). It appears to work as its responding >> but appears like its at the wrong baud rate. I'm trying with cutecom >> (Linux) and get output like: >> >> \0x1c\0x1c >> >> \0x1c\0x1c >> >> \0x1c\0x1c >> >> \0xffü >> >> \0x1c\0x1c >> >> \0x1c\0x1c >> >> \0x1c\0x1c >> >> \0xffü >> >> \0x1c\0x1c >> >> \0x1c\0x1c >> >> \0x1c\0x1c >> >> \0x1c\0x1c >> >> \0x1c\0x1c >> >> \0x1c\0x1c >> >> \0x1c\0x1c >> >> \0x1c\0x1c >> >> àüààà\0x1c >> >> àüàü\0x1c >> >> I'm set at 38400 8N1 like the doc says. Am I missing something else? >> >> Thanks >> >> >> >> >> ------------------------------------------------------------------------------ >> Developer Access Program for Intel Xeon Phi Processors >> Access to Intel Xeon Phi processor-based developer platforms. >> With one year of Intel Parallel Studio XE. >> Training and support from Colfax. >> Order your platform today.http://sdm.link/xeonphi >> >> >> _______________________________________________ >> Flashforth-devel mailing list >> Fla...@li... >> https://lists.sourceforge.net/lists/listinfo/flashforth-devel > |
From: Mikael N. <mik...@fl...> - 2017-01-15 09:19:15
|
One problem could be that you have the wrong clock setting in the p18f-main.cfg file. You need decide which clock you use (internal or external) Then you need to set the correct value in p18f2x4xk20.cfg FOSC parameter and in p18f-main.cfg clock parameter For example these values should work with your chip. It is using the chip internal oscillator. config FOSC = INTIO67 clock = 16000000 -- -- Mikael On 2017-01-15 00:39, Eugene wrote: > Hello all, > > I have downloaded and installed FlashForth on a PIC18f45k20 (on the > Microchip 44 pin demo board). It appears to work as its responding > but appears like its at the wrong baud rate. I'm trying with cutecom |
From: Eugene <en...@ni...> - 2017-01-14 22:48:57
|
Hello all, I have downloaded and installed FlashForth on a PIC18f45k20 (on the Microchip 44 pin demo board). It appears to work as its responding but appears like its at the wrong baud rate. I'm trying with cutecom (Linux) and get output like: \0x1c\0x1c \0x1c\0x1c \0x1c\0x1c \0xffü \0x1c\0x1c \0x1c\0x1c \0x1c\0x1c \0xffü \0x1c\0x1c \0x1c\0x1c \0x1c\0x1c \0x1c\0x1c \0x1c\0x1c \0x1c\0x1c \0x1c\0x1c \0x1c\0x1c àüààà\0x1c àüàü\0x1c I'm set at 38400 8N1 like the doc says. Am I missing something else? Thanks |
From: Joe E. <w7...@bo...> - 2016-10-30 17:13:39
|
Bingo! Go figure, joy was just a checkbox away. :\ Hi Mike, been a long time. Hope you are well. FlashForth has really turned into a remarkable piece of work. Thank you again. I'm looking forward to lots of fun with FlashForth while the snow flies this winter. ciao joe On Sun, 30 Oct 2016 07:47:18 +0200 Mikael Nordman <mik...@fl...> wrote: > Hey Joe, what you're doing with that FlashForth in your hand ? :-) > > Probably you have hit the old ASM30 and XC16 bug. > Enabling the listing file for the assembler usually makes the > compiler behave. > > BR Mike > > ------------------------------------------------------------------------------ > The Command Line: Reinvented for Modern Developers > Did the resurgence of CLI tooling catch you by surprise? > Reconnect with the command line and become more productive. > Learn the new .NET and ASP.NET CLI. Get your free copy! > http://sdm.link/telerik > _______________________________________________ > Flashforth-devel mailing list > Fla...@li... > https://lists.sourceforge.net/lists/listinfo/flashforth-devel |
From: Mikael N. <mik...@fl...> - 2016-10-30 06:32:44
|
Hey Joe, what you're doing with that FlashForth in your hand ? :-) Probably you have hit the old ASM30 and XC16 bug. Enabling the listing file for the assembler usually makes the compiler behave. BR Mike |
From: Joe E. <w7...@bo...> - 2016-10-29 22:03:27
|
Hello list, I wanted to rekindle my FlashForth passion after a *long* hiatus and transition from 18Fxxxx to a 16bit chip for a motor controller project. Wow Mike, this thing has really matured, hat tip. I've downloaded V5.0, built with MPLABX, flashed and running on a dsPICEP256MC502 with a warm message of "FlashForth 5 PIC24 14.5.2016". EXCEPT: I have access to only about half of the kernel dictionary. For example words " + " and " c@ ", and many others, are not found. Executing " words " produces and output like: -- ok<#,ram> words trisb portb true false Fcy ... ... ... ... ... ... ... ... >body to is defer value . marker -- Somehow, kernel dictionary searching is bumped from " value " to " . ", then begins searching the operator dictionary with " marker " being found. New words defined by operator are found just fine. Only changes I made to the p33e_config.inc file are: Increased RX1_BUF_SIZE to 63 bytes Using fixed Baudrate of 38400 with Xon/Xoff Although, I have verified the issue exists with vanilla settings. I was secretly pleased to have an excuse to get into and learn to ride this new bronc but, holy smoke, this is not the FlashForth I used to mercilessly hack back at V2x and V3x. It's much better (and complex)! But, I'm wondering if users might have any insight to what I might be facing here and willing to share some guidance. - ciao joe aka w7net |
From: Peter J. <pe...@me...> - 2016-09-16 18:07:23
|
Just pushed the bare ff-shell.tcl repository onto bitbucket. https://paj...@bi.../pajacobs/ff-shell Cheers, Peter J. On 16/09/16 19:38, Peter Jacobs wrote: > Pete, > That's a mistake that I have made before. Mike picked it up last > time. To fix, we don't want to allow the entryFrame to expand. So, on > line 342, we want "-expand 0" as the option when packing the frame. (A > single character change from "1" to "0".) > Cheers, > Peter J. > > > On 16/09/16 18:00, Pete Zawasky wrote: >> Hi Peter, >> >> The command history looks very good. I am running it on Linux Mint >> 17.3 32-bit and LMDE 2 64-bit. >> Glad it did not take a large effort to implement. >> >> The gray area above and below the command widget box expands and does >> create a lot of empty space as you expand the ff-shell screen. >> >> Thanks, >> Pete >> >> On 9/15/2016 5:01 PM, Peter Jacobs wrote: >>> Pete, >>> >>> Attached is a version of ff-shell.tcl that includes the command >>> history. It turned out easy to keep the text widget interaction and >>> add a command widget below it. You can choose how you send text by >>> setting the input focus to the command widget or the text widget. At >>> start-up, the focus is first given to the command widget. Let me >>> know if this does as you wish or if I should change it further. >>> >>> I should put the repository up on bitbucket, but that will be a job >>> for tomorrow. >>> >>> Cheers, >>> >>> Peter J. > > ------------------------------------------------------------------------------ > _______________________________________________ > Flashforth-devel mailing list > Fla...@li... > https://lists.sourceforge.net/lists/listinfo/flashforth-devel |
From: Peter J. <pe...@me...> - 2016-09-16 17:38:45
|
Pete, That's a mistake that I have made before. Mike picked it up last time. To fix, we don't want to allow the entryFrame to expand. So, on line 342, we want "-expand 0" as the option when packing the frame. (A single character change from "1" to "0".) Cheers, Peter J. On 16/09/16 18:00, Pete Zawasky wrote: > Hi Peter, > > The command history looks very good. I am running it on Linux Mint > 17.3 32-bit and LMDE 2 64-bit. > Glad it did not take a large effort to implement. > > The gray area above and below the command widget box expands and does > create a lot of empty space as you expand the ff-shell screen. > > Thanks, > Pete > > On 9/15/2016 5:01 PM, Peter Jacobs wrote: >> Pete, >> >> Attached is a version of ff-shell.tcl that includes the command >> history. It turned out easy to keep the text widget interaction and >> add a command widget below it. You can choose how you send text by >> setting the input focus to the command widget or the text widget. At >> start-up, the focus is first given to the command widget. Let me >> know if this does as you wish or if I should change it further. >> >> I should put the repository up on bitbucket, but that will be a job >> for tomorrow. >> >> Cheers, >> >> Peter J. > |
From: Pete Z. <pza...@pz...> - 2016-09-16 16:00:18
|
Hi Peter, The command history looks very good. I am running it on Linux Mint 17.3 32-bit and LMDE 2 64-bit. Glad it did not take a large effort to implement. The gray area above and below the command widget box expands and does create a lot of empty space as you expand the ff-shell screen. Thanks, Pete On 9/15/2016 5:01 PM, Peter Jacobs wrote: > Pete, > > Attached is a version of ff-shell.tcl that includes the command > history. It turned out easy to keep the text widget interaction and > add a command widget below it. You can choose how you send text by > setting the input focus to the command widget or the text widget. At > start-up, the focus is first given to the command widget. Let me know > if this does as you wish or if I should change it further. > > I should put the repository up on bitbucket, but that will be a job > for tomorrow. > > Cheers, > > Peter J. |
From: Conrado S. <con...@gm...> - 2016-09-16 12:08:13
|
I didn’t have Windows until last week either (and would prefer not to have it) but customers seem to have their our opinion … Anyway, found out that in Windows 10 the whole serialcdc.inf file installation can be ignored. Just plug it in, find out which COM port was assigned and use it. Thanks to all. ––––––––– Conrado Seibel con...@gm... <mailto:con...@se...> 0176 81288597 > On 15 Sep 2016, at 19:04, Mikael Nordman <mik...@fl...> wrote: > > I do not have Windows... > > Anyway, Google returns a heap of results for your problem. > > None of those helped ? > > BR Mike > > On 2016-09-15 16:42, Conrado Seibel wrote: >> Hi guys, >> >> Is anyone running ff-shell or a terminal emulator on Windows 10 to >> interface to a PIC18F running the console over the USB port ? How did >> you get it to work ? >> >> I’m using FF on a PIC18F2455 to control a led matrix display that >> interfaces over the serial port to a measurement instrument. The Forth >> console is implemented on the USB port of the PIC. I’m using two >> background tasks and things work very nicely. Congrats to all people >> involved in this amazing piece of code. >> >> What I would like to do is use the USB console as a ‘service’ port for >> the instrument. I’ve implemented and tested the functionality and it >> works as intended. In our team we only use Linux and Mac OSX and >> interfacing to with the PIC over USB using a terminal emulator >> (picocom) worked pretty well. However, the end users will probably run >> Windows. >> >> I’ve tried connecting the PIC to a Windows 10 machine but it wasn’t >> recognised. I applied for a VID/PID using the Microchip sub-licensing >> program, changed the corresponding values in the ASM source code and >> also in the serialcdc.inf file and tried to install it in Windows, >> only to get a “The third party INF does not contain digital signature >> information” error (which is true). >> >> I’m not familiar with Windows and a two-hour google session on >> self-signing inf files didn’t result in me getting any smarter. >> Searching for how to disable signature checking in Windows 10 didn’t >> bring me any further either. >> >> Thanks in advance for any pointers. >> >> >> ------------------------------------------------------------------------------ >> _______________________________________________ >> 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 |