Activity for Mikael Nordman
-
Mikael Nordman posted a comment on discussion Open Discussion
Did some updates to the PIC24 part. - Less writes to flash on chips that do not have eeprom (almost all chips). A smarter algorithm compares the highest written flash address with the xt to be executed. - DOES> fixed to work also with an empty DOES> part. - Unknown words do not cause INTERPRET to ABORT. This allows that unknown (marker words) words do not abort the loading from blocks or from Pere's file system. This was needed to let MARKER words to be used in those scenarios. - 64 by 64-bit unsigned...
-
PIC24:Less flash writes,UQ/,fix DOES>
-
PIC24: improved flash write algorithm
-
PIC24: PIC24F32KA302
-
PIC24: PIC24F32KA302
-
PIC24: dsPIC33FJ128GP802 alpha
-
PIC24: dsPIC33FJ128GP802 alpha
-
PIC24: dsPIC33FJ128GP802 alpha
-
PIC24: dsPIC33FJ128GP802 alpha
-
PIC24: dsPIC33FJ128GP802 alpha
-
PIC24: dsPIC33FJ128GP802 alpha
-
PIC24: dsPIC33FJ128GP802 alpha
-
PIC24: dsPIC33FJ128GP802 alpha
-
PIC24: dsPIC33FJ128GP802 alpha
-
FF6: PIC24 initial
-
I actually found a simple solution to change INTERPRET to continue interpreting when a error is encountered. Not much tested, but it works with my block system. So now when a -marker word is encountered, interpret will continue with the next word. You can try and patch your FF with this, unless of course you are using Scamp words. IUNKNOWN: ; a f dec2 W14, W14 rcall CFETCHPP rcall TYPE rcall XSQUOTE .byte 2 .byte '\?',NAK_ .align 2 rcall TYPE ; rcall FALSE_ ; rcall QABORTQ bra INTER1 INTER6:
-
I quess the only solution for now is to use -marker from the command line and then load the file(s).
-
Yes. That's a problem with EVALUATE. A proper solution would be to implement CATCH/THROW in FF, so that EVALUATE could catch the error and continue. With a simple ABORT that is not possible.
-
last : why buf c@+ evaluate buf2 c@+ evaluate doesn't work? and : test2 buf c@+ evaluate buf2 c@+ evaluate ; works.? It does not work because after the first evaluate the system is in compilation state so interpret will try to compile the phrase " buf2 c@+ evaluate" instead of executing it. The word test2 only executes so there is no dependence on state.
-
last : why buf c@+ evaluate buf2 c@+ evaluate doesn't work? and : test2 buf c@+ evaluate buf2 c@+ evaluate ; works.? It does not work because after the first evaluate the system is in compilation state so interpret will try to compile the phrase " buf2 c@+ evaluate" instead of interpreting it. The word test2 only executes so there is no dependence on state.
-
Using evaluate like this does not work. ram create buf 20 allot ram create buf2 20 allot s" : test 1 2" buf place s" + . ;" buf2 place buf c@+ evaluate buf2 c@+ evaluate
-
This works for me ram create buf 20 allot ram create buf2 20 allot : test2 buf c@+ evaluate buf2 c@+ evaluate ; s" : test 1 2" buf place s" + . ;" buf2 place test2 test 3
-
last : why buf c@+ evaluate buf2 c@+ evaluate doesn't work? and : test2 buf c@+ evaluate buf2 c@+ evaluate ; works.? It does not work because after the first evaluate the system is in compilation state so interpret will try to compile the phrase " buf2 c@+ evaluate" instead of interpreting it.
-
Added words to temporarily compile code and execute it. Handy for timing tests or for compile-only words. Look in ARCH/forth/compile-execute.fs. [[ 10 for r@ . next ]] 9 8 7 6 5 4 3 2 1 0 ok<$,ram>
-
ALL: [[ ]]
-
When I was writing the block words I found that FF should be restructured to accept input from a large buffer using REFILL. But I never did that restructuring. Anyway it is easiest to have a line buffer that can accept a whole line, and evaluate one line at a time. If you take in only part of a line you may cut off some words in the middle which again a more difficult thing to handle. So LOAD has the restriction that one line is always 64 bytes and a word is not allowed to be split across a 64 byte...
-
When I was writing the block words I found that FF should be restructured to accept input from a large buffer using REFILL. But I never did that restructuring. Anyway it is easiest to have a line buffer that can accept a whole line, and evaluate one line at a time. If you take in only part of a line you may cut of some words in the middle which again a more difficult thing to handle. So LOAD has the restriction that one line is always 64 bytes and a word is not allowed to be split across a 64 byte...
-
Using evaluate like this does not work. ram create buf 20 allot ram create buf2 20 allot s" test 1 2" buf place s" + . ;" buf2 place buf c@+ evaluate buf2 c@+ evaluate
-
Having CR LF inside the buffer also works. All control bytes ( <32) are interpreted as white space.
-
This works for me ram create buf 20 allot ram create buf2 20 allot : test2 buf c@+ evaluate buf2 c@+ evaluate ; s" test 1 2" buf place s" + . ;" buf2 place test2 test 3
-
WHAT ?
-
Yes, no P register is FF6, but I don't know if it will ever go further than alpha state.
-
The advantage comes from the associated words, and by having a kind of consistency. Advantages compared to a variable is that the P register is multitasking safe and also re-entrant, and the associated words are more efficient than if you define them yourself. Myself I have had very little use of those P words, so in FF6 I removed them. They are mostly cute and an attempt to mimic pointers in C.
-
Your code does not match the result in FF. Maybe in gforth ? This is correct. What do you think it was supposed to do ? : tt 10 for i . 10 for i . next cr next ; ok tt 9 9 8 7 6 5 4 3 2 1 0 8 9 8 7 6 5 4 3 2 1 0 7 9 8 7 6 5 4 3 2 1 0 6 9 8 7 6 5 4 3 2 1 0 5 9 8 7 6 5 4 3 2 1 0 4 9 8 7 6 5 4 3 2 1 0 3 9 8 7 6 5 4 3 2 1 0 2 9 8 7 6 5 4 3 2 1 0 1 9 8 7 6 5 4 3 2 1 0 0 9 8 7 6 5 4 3 2 1 0 ok
-
Your code does not match the result. This is correct. What do you think it was supposed to do ? : tt 10 for i . 10 for i . next cr next ; ok tt 9 9 8 7 6 5 4 3 2 1 0 8 9 8 7 6 5 4 3 2 1 0 7 9 8 7 6 5 4 3 2 1 0 6 9 8 7 6 5 4 3 2 1 0 5 9 8 7 6 5 4 3 2 1 0 4 9 8 7 6 5 4 3 2 1 0 3 9 8 7 6 5 4 3 2 1 0 2 9 8 7 6 5 4 3 2 1 0 1 9 8 7 6 5 4 3 2 1 0 0 9 8 7 6 5 4 3 2 1 0 ok
-
You need J when you in the inner loop want to use the index of the outer loop. : test3 10 0 do 10 0 do ." i" ii . ." j" j . loop cr loop ; ok test3 i0 j0 i1 j0 i2 j0 i3 j0 i4 j0 i5 j0 i6 j0 i7 j0 i8 j0 i9 j0 i0 j1 i1 j1 i2 j1 i3 j1 i4 j1 i5 j1 i6 j1 i7 j1 i8 j1 i9 j1 i0 j2 i1 j2 i2 j2 i3 j2 i4 j2 i5 j2 i6 j2 i7 j2 i8 j2 i9 j2 i0 j3 i1 j3 i2 j3 i3 j3 i4 j3 i5 j3 i6 j3 i7 j3 i8 j3 i9 j3 i0 j4 i1 j4 i2 j4 i3 j4 i4 j4 i5 j4 i6 j4 i7 j4 i8 j4 i9 j4 i0 j5 i1 j5 i2 j5 i3 j5 i4 j5 i5 j5 i6 j5 i7 j5 i8 j5...
-
curiously if i use only i . the nested loop runs ok........ Why ? That is normal. I accesses the current loop index, J the outer loop index, K 2 levels up.
-
gforth Gforth 0.7.9_20250321 Authors: Anton Ertl, Bernd Paysan, Jens Wilke et al., for more type `authors' Copyright © 2025 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <https://gnu.org/licenses/gpl.html> Gforth comes with ABSOLUTELY NO WARRANTY; for details type `license' Type `help' for basic help : test1 10 0 do ." i" i . 10 0 do ." j" j . loop cr loop ; ok test1 i0 j0 j0 j0 j0 j0 j0 j0 j0 j0 j0 i1 j1 j1 j1 j1 j1 j1 j1 j1 j1 j1 i2 j2 j2 j2 j2 j2 j2 j2 j2 j2 j2 i3 j3...
-
(a) is correct. You need to think about what the function of the word J is. J gets you the value of the index of the outer loop.
-
How did you define J for the FOR NEXT? You cannot use J defined for DO LOOP in the FOR NEXT LOOP.
-
It is difficult to answer a question if you do not show the real code that you are using. If you use Ix then write it in the code. For me the do loop works just fine on the scamp 3e. : test1 10 0 do ." i" ii . 10 0 do ." j" j . loop cr loop ; ok i0 j0 j0 j0 j0 j0 j0 j0 j0 j0 j0 i1 j1 j1 j1 j1 j1 j1 j1 j1 j1 j1 i2 j2 j2 j2 j2 j2 j2 j2 j2 j2 j2 i3 j3 j3 j3 j3 j3 j3 j3 j3 j3 j3 i4 j4 j4 j4 j4 j4 j4 j4 j4 j4 j4 i5 j5 j5 j5 j5 j5 j5 j5 j5 j5 j5 i6 j6 j6 j6 j6 j6 j6 j6 j6 j6 j6 i7 j7 j7 j7 j7 j7 j7 j7...
-
So what was your problem ?
-
It does not work because the Scamp has used I for the FOR NEXT. Defining I again for DO LOOP is not allowed in FlashForth. So, in Scamp I can only be used by FOR NEXT, there I is just an alias for R@. I asked John not to do that, but he did, so now there is this mess with I and DO LOOP.
-
There is a small trick to get 1536 ($600) bytes of extra ram on the Scamp. You can use the flash buffer in ram to store data as long as you do not attempt to write anything to flash. Just be sure to empty the flash buffer with IFLUSH before using the buffer. With the latest Scamp version the buffer starts at $84a.
-
That kind of use looks fine to me. Mileage may vary. Do you mean that "array buffer u cmove" does not keep the data in flash after a power cycle ?
-
That kind of use looks fine to me. Mileage may vary. Do you mean that "array buffer u cmove" keep the data in flash after a power cycle ?
-
By the way. If you write your code so that the ram buffer will flush to flash for each cell or byte, it will quickly wear out the flash, since for each char/cell the whole 1 kbyte block is erased and rewritten.. A buffer in flash sounds suspect to me. Flash data should really contain just static or almost static data.
-
When writing data to flash, the data is gathered in a aligned 1 Kbyte ram buffer (Scamp). That buffer is written to flash if it gets full, or if 300 milliseconds has passed after the last write to flash. The timeout is handled inside PAUSE by calling IFLUSH. So if you call PAUSE often like the normal interpreter does, the data should find it's way into flash. Just now I tried it on a Scamp2e and it works just fine. flash create array 100 allot ram 1234 array ! \ Wait for 300 ms before disconnecting...
-
It should work using the debugger USB port (unless you cut some connections on the board). Did you check the instructions in the board User Guide about the serial CDC connection.
-
These config changes could work. I do not have the board. // Define if USB or which UART is used for the operator task // 0=USB 1=UART1 2=UART2 3=UART3 #define OPERATOR_UART 2 #define WANT_UART2 ENABLE // ENABLE or DISABLE CONFIG FEXTOSC = OFF CONFIG RSTOSC = HFINTOSC_64MHZ CONFIG BOREN = ON CONFIG BORV = VBOR_2P85 ; Define UART2 TX pin #if WANT_UART2 == ENABLE #define TX2_TRIS TRISD #define TX2_ANSEL ANSELD #define TX2_BIT 0 #define TX2_PPS RD0PPS #define TX2_LAT LATD #define TX2_CODE 0x16 ; Define...
-
Do you have a problem ? At least the UART pins have to be configured to match the nano board design. Have you done that ?
-
John has made a small copy-paste error in the USB descriptor. I asked him to fix it.
-
PIC24: In endpoint size 8 for Windows
-
Yes, there seems to be a problem with windows. It refuses to handle different sizes of in(16) and out(8) end points. Works fine on Linux and I suppose on OSX since John is an Apple guy. I will update the end points to be the same size.
-
Is your data stack balanced? Does it grow or shrink?
-
PIC18: terminal in background task
-
PIC24: transient workaround
-
I though about a solution to make older versions of FF to work with the transient feature. Here the transient words are located below the $8000 flash real address. : transient ( size -- ) flash latest @ align here >r >r ( size ) aligned $8000 pfl + swap - dp ! latest @ , here $2081 , latest ! r> , r> , ram ;
-
I though about a solution to make older version of FF to work with the transient feature. There the transient words are located below the $8000 flash real address. : transient ( size -- ) flash latest @ align here >r >r ( size ) aligned $8000 pfl + swap - dp ! latest @ , here $2081 , latest ! r> , r> , ram ;
-
I tried a few hours to get the background io-switch to work, but it did not want to. Giving the >terminal or >wifi from the currently active port works. Giving a command to the BG task to make switch using a global variable works. But not with rx1? and rxu? . -wifi marker -wifi : to-wifi ['] rx1 operator 'key his ! ['] rx1? operator 'key? his ! ['] tx1 operator 'emit his ! ; : to-term ['] rxu operator 'key his ! ['] rxu? operator 'key? his ! ['] txu operator 'emit his ! ; 0 40 40 0 task: io-switch-task...
-
I tested a bit the background interpreter that uses ABORT. It seems to work quite well, except for the multitasking words which are hard coded to only run from the operator task. These are TASK: TINIT SINGLE END RUN TASKS. Hopefully all other words can be executed in the background and operator tasks in the interpretation state. When compiling new definitions or appending data to the dictionary only one of the terminal at a time can be used. There is only one dictionary so if two tasks write to it...
-
What about this ? It would automatically switch the operator task to the I/O that sends in characters. Not tested. : >wifi ['] rx1 operator 'key his ! ['] rx1? operator 'key? his ! ['] tx1 operator 'emit his ! ; : >terminal ['] rxu operator 'key his ! ['] rxu? operator 'key? his ! ['] txu operator 'emit his ! ; 0 40 40 0 task: io-switch-task \ TODO: implement TERMINAL? and WIFI? : io-switch begin pause rx1? terminal? and if >wifi then rxu? wifi? and if >terminal then again ; : run-io-switch ['] io-switch...
-
I find it hard to understand what you mean by 'control' ? Control of the interpreter in the operator task ? You can do that without any BG tasks. Just use your >terminal and >wifi in the operator task as you have already defined. This is how to switch the I/O of the operator task from any task. : >terminal ['] rxu operator 'key his ! ['] rxu? operator 'key? his ! ['] txu operator 'emit his ! ; : >wifi ['] rx1 operator 'key his ! ['] rx1? operator 'key? his ! ['] tx1 operator 'emit his ! ;
-
With the word HIS you can access the user variables of a specific task.
-
I think that if you do not compile simultaneously in the tasks, there is actually a chance that using the interpreter works just fine. You could try putting just ABORT in the end of the BG task. it will enter the infinite QUIT loop that drives the interpreter.
-
I think that if you do not compile simultaneously in the tasks, there is actually a chance that using the interpreter works just fine.
-
Regarding PAUSE it is only needed before RX1? because RX1? itself does not call PAUSE. RX1, RXU, TX1, TXU will call PAUSE so there will be enough PAUSES. A certain amount is needed for the USB interface not to freeze, because PAUSE is also driving the basic USB state machine. Making RXn? call PAUSE is actually a change that should be done, because there has been many questions about this earlier.
-
Regarding PAUSE it is only needed before RX1? because RX1? itself does not call PAUSE. RX1, RXU, TX1, TXU will call PAUSE so there will be enough PAUSES. A certain amount is needed for the USB interface not to freeze, because PAUSE is also driving the basic USB state machine. Making RXn? call PAUSE is actually a change that should be done.
-
Regarding PAUSE it is only needed before RX1? because RX1? itself does not call PAUSE. RX1, RXU, TX1, TXU will call PAUSE so there will be enough PAUSES. A certain amount is needed for the USB interface not to freeze, because PAUSE is also driving the basic USB state machine.
-
Hi, FlashForth has a limitation that INTERPRET, EVALUATE, and QUIT does not work in a background task. I don't remember exactly why. They may work, but can not be relied on to work fully because the interpreter is not re-entrant. It uses global variables and flags for many things so the operator task and the background task will interfere with each other. Have a look at https://sourceforge.net/p/flashforth/code/ci/master/tree/forth/task-bgio.fs and its comments. There you can see how to use KEY with...
-
The fix has been published. Henceforth RCALL, can only be used with 16-bit unsigned offsets that are always used as a backwards relative reference. This is also the case for normal FF code.
-
PIC24: negative rel.addr > 7ffe fix
-
I have a fix for the RCALL problem and will release it soon.
-
There seems to be a serious bug in FlashForth for PIC24. Any code compiled at an absolute flash address greater than $8000 ($8000 + PFL virtual address) in the) can be corrupt. I guess this has not surfaced earlier because no-one has made so large programs. The transient code is compiled to the end of flash, so the problem appears. The problem is in the calculation of the negative RCALL offset address when the offset is greater than $8000. The PIC18 and Atmega does not have the problem because it...
-
The seems to be a serious bug in FlashForth for PIC24. Any code compiled at an absolute flash address greater than $8000 ($8000 + PFL virtual address) in the) can be corrupt. I guess this has not surfaced earlier because no-one has made so large programs. The transient code is compiled to the end of flash, so the problem appears. The problem is in the calculation of the negative RCALL offset address when the offset is greater than $8000. The PIC18 and Atmega should not have the problem because it...
-
Hard to say. At least the area reserved by TRANSIENT must be large enough to fit all the transient words. I have not used it myself except doing some simple tests. Those words manipulate LATEST which is a eeprom emulated variable, and it is cached in ram. There is a delayed update of ram to emulated eeprom in flash. Maybe there are some problems in that area, depending on execution timing of those words. The transient words were first developed on Atmega. It has real eeprom and it updates the eeprom...
-
Hard to say. At least the area reserved by TRANSIENT must be large enough to fit all the transient words. I have not used it myself except doing some simple tests. Those words manipulate LATEST which is a eeprom emulated variable, and it is cached in ram. There is delayed a update of ram to emulated eeprom in flash. Maybe there are some problems in that area, depending on execution timing of those words. The transient words were first developed on Atmega. It has real eeprom and it updates the eeprom...
-
The scamp3e is not needed specifically. The block/edit code works the same on any scamp board.
-
Are you sure? All words are present on my scamp3e. You have to load the files core.fs case.fs vt100.fs yourself first. Then you can load block24.fs and edit.fs. There is a hint about it edit.fs and block24.fs. \ #sendm forth/core forth/case forth/vt100 xxxx/forth/block forth/edit sendm is the command in ff-shell.py for sending multiple files to the serial line. What terminal program are you using to send files to the FF serial line ?
-
Are you sure? All words are present on my scamp3e. You have to load the files core.fs case.fs vt100.fs yourself first. Then you can load block24.fs and edit.fs
-
I published it. block.fs for PIC18 and Atmega, block24.fs for PIC24 and edit.fs. You can play with it, but it is experimental, so don't expect too much. The editor requires a VT100 capable terminal. Only tested with minicom on Linux.
-
ALL: Experimental block, editor
-
I have some initial code written, that works somehow. Don't exactly remember. I think there was problems with loading blocks in case an error is encountered. The interpreter aborts on a missing marker word and the loading is prevented, making marker unusable with blocks. Just tried to use it. It uses some special words, that I have since deleted from FF. Need to check what it was supposed to do.
-
Updated the PIC24 USB code to a 16 byte packet size for TXU. RXU has a 8 byte packet size like before. The transfer speed is now approx. 120000 characters per second. That is approx. 1 Mbit/s. This has been measured with Linux and with Windows 11.
-
Updated the PIC24 USB code to a 16 byte packet size for TXU. RXU has a 8 byte packet size like before
-
PIC24: Faster USB transfer
-
So the TXU is too slow to swallow the input from RX1@115200 baud. I will update FF to transmit 8 or 16 bytes at a time over USB. I removed that functionality 2 years ago because I thought it would be fast enough with just one byte per USB transaction. But obviously not with Windows, which I never use myself.
-
I have two Scamps connected together over UART1 and using the bridge on one scamp to use as terminal of the other Scamp and there is no data lost. So there appears not to be any speed problem at 115200. Your problem is a mystery. Actually I had no problems when using Linux. But when I use Windows I get some character loss on the bridge but not much, less than 1%.
-
I have two Scamps connected together over UART1 and using the bridge on one scamp to use as terminal of the other Scamp and there is no data lost. So there appears not to be any speed problem at 115200. Your problem is a mystery.
-
What is the serial speed and can you lower the serial speed on the ESP01 ?
-
How long are the messages and how much is lost ?
-
I did some tests like this : test2 ticks swap for $30 emit next ticks swap - cr u. ; On Windows and teraterm the speed is 124 Kbit/s. 10000 chars prints out in 643 milliseconds. On Linux and ff-shell the speed is 506 Kbit/s. 10000 chars prints out in 158 milliseconds. OSX I do not know how that behaves. So if the data from the ESP01 comes in with 115.2 Kbit/s and the local echo is in use and you are using Windows, then there could be a problem. One possible improvement could be to remove the echo...
-
I did some tests like this : test2 ticks swap for $30 emit next ticks swap - cr u. ; On Windows and teraterm the speed is 124 Kbit/s. 10000 chars prints out in 643 milliseconds. On Linux and ff-shell the speed is 506 Kbit/s. 10000 chars prints out in 158 milliseconds. OSX I do not know how that behaves.
-
It could be that the local echo increases the traffic on the USB interface so that incoming traffic from the serial line is not read out fast enough and as a consequence the serial line interrupt buffer throws away some characters. What is the speed towards ESP01 ? 9600? 115200? The USB TXU routine is not very fast. It sends only one character per USB transaction.
-
You mean something like this ? https://sourceforge.net/p/flashforth/code/ci/master/tree/pic18/forth/bridge.fs It should work transparently. Once I used it as a bridge to a dsPIC. But I do not remember any problems. I have no idea what the problem could be. I'll test it some day.
1 >
