FlashForth: for PIC and Atmega Activity
Brought to you by:
oh2aun
Activity for FlashForth: for PIC and Atmega
-
Mikael Nordman committed [dca4ca] on Code
RXNEW
-
RXNEW
-
A small TIB is needed if your task formats numbers (. U. D. # HOLD). The size should be as large as the longest formatted number string. See https://sourceforge.net/p/flashforth/code/ci/master/tree/pic18/l-meter/l-meter.fs A TIB is also needed if the task uses ACCEPT. It should be as long as the longest input line plus the area needed for number formatting. See https://sourceforge.net/p/flashforth/code/ci/master/tree/pic18/forth/task-bgio.fs The task variables are needed if you use the same word...
-
Amt posted a comment on discussion Open Discussion
Thanks Mikael! This helps, I'll learn more by experimentation.
-
A small TIB is needed if your task formats numbers (. U. D. # HOLD). The size should be as large as the longest formatted number string. See https://sourceforge.net/p/flashforth/code/ci/master/tree/pic18/l-meter/l-meter.fs A TIB is also needed if the task uses ACCEPT. It should be as long as the longest input line plus the area needed for number formatting. See https://sourceforge.net/p/flashforth/code/ci/master/tree/pic18/forth/task-bgio.fs. The task variables are needed if you use the same word...
-
A small TIB is needed if your task formats numbers (. U. D. # HOLD). The size should be as large as the longest formatted number string. See https://sourceforge.net/p/flashforth/code/ci/master/tree/pic18/l-meter/l-meter.fs A TIB is also needed if the task uses ACCEPT. It should be as long as the longest input line plus the area needed for number formatting. See https://sourceforge.net/p/flashforth/code/ci/master/tree/pic18/forth/task-bgio.fs. The task variables are needed if you use the same word...
-
A small TIB is needed if your task formats numbers (. U. D. # HOLD). The size should be as large as the longest formatted number string. See https://sourceforge.net/p/flashforth/code/ci/master/tree/pic18/l-meter/l-meter.fs A TIB is also needed if the task uses ACCEPT. It should be as long as the longest input line plus the area needed for number formatting. See https://sourceforge.net/p/flashforth/code/ci/master/tree/pic18/forth/task-bgio.fs. The task variables are needed if you use the same task...
-
Hi, The parameter and return stack sizes in task creation makes sense but I'm not very clear on the other two parameters. Can't tasks use variables that are declared normally? what is the benefit of allocation variable address for a task? I also do understand how to allocate space for the TIB. When is it useful and how to decide on the size. -amt
-
Frans-Pieter Vonck modified a comment on discussion Open Discussion
I have found a solution with socat (linux) socat -,raw,echo=0 TCP4:[address]:23 That works. The only disadvantage is that closing the connection with Ctrl-D does not work in raw mode. ' Pkill socat' will solve that, but for that you need to open another terminal window. Another interesting challenge is to send files to the telnet server. I use the following procedure First define a function that slows down the reading of the text-file function slowcat() { while read; do sleep .20; echo "$REPLY";...
-
I have found a solution with socat (linux) socat -,raw,echo=0 TCP4:[address]:23 That works. The only disadvantage is that closing the connection with Ctrl-D does not work in raw mode. ' Pkill socat' will solve that, but for that you need to open another terminal window. Another interesting challenge is to send files to the telnet server. I use the following procedure First define a function that slows down the reading of the text-file function slowcat() { while read; do sleep .20; echo "$REPLY";...
-
I have found a solution with socat (linux) socat -,raw,echo=0 TCP4::23 That works. The only disadvantage is that closing the connection with Ctrl-D does not work in raw mode. ' Pkill socat' will solve that, but for that you need to open another terminal window. Another interesting challenge is to send files to the telnet server. I use the following procedure First define a function that slows down the reading of the text-file function slowcat() { while read; do sleep .20; echo "$REPLY"; done; } And...
-
FF recognizes the following end of line sequences * CR (Mac) * CR LF (Windows) * LF (Linux) The problem is the CRLF. ACCEPT interprets that a line is complete by CR and then discards the the following LF in the next call to ACCEPT. But if the next word that call KEY?/KEY is not ACCEPT, then KEY? and KEY will receive the LF as an extra character. You could just check if there is an extra character in the input before you start the blinky loop.
-
Via an wifi-serial bridge (esp-link) I can start a telnet session and communicate with flashforth. I tried out blinky, toggle a led until a key is hit, I noticed that key? is consuming the return that is typed in after typing a word. Therefore the loop is only done once. Do i need to write another word for reading keys or is there a setting in telnet in linux that i can adjust? Grts, F.P.
-
Hi Guy. At least I am interested. Just today I made an adjustment to my homebrew HF receiver. I have come to the conclusion that the most efficient way of making a LO is to use the high quality SI5351 board from SV1AFN that has minimal birdies and a quite stable XTAL. The "standard" SI5351 boards have a lot worse level of spurious responses due to inferior ground plane design. Minimizing the current output from SI5351 reduces the spurious levels a bit further, so today I added a J310 source follower...
-
Guy Mengel posted a comment on discussion Open Discussion
Hi Folks, First post. First, thanks for the work to put together flashforth. Second, i know there are other hams or amateur radio ops here from my reading. Even the developer. I am a ham N1GMM and have always loved to build my own transcievers and modules for them. VFO's for instance. Several have already used assembler (very old asm from Microchip) and I have no interest to rework 5000 lines of assembler (.asm) to the newer assembler .as ... Since I needed a project, and have always wanted to use...
-
PIC18: Safer EEPROM handling
-
FF6: Safer EEPROM handling
-
PIC18: Trampoline CREATE DOES> USER
-
James Whyte posted a comment on discussion Open Discussion
Thanks Mikael. Already in the process of translating, so I'll post my results here when I'm finished in case they're needed in future. It's mostly just calling other subroutines in any case. FREEZE sounds like a good idea - even better if it could be used on specific user-defined words rather than the entire user-defined dictionary
-
Hi. You will have to translate it yourself. SEE helps. I was thinking of making a word FREEZE that would configure the current compiled dictionary as the new base dictionary. That could then be dumped to a hex file and programmed to other chips. Or there could even be a Forth program to clone the current chip to another chip.
-
Hi again Mikael, Does there exist an AVR assembly implementation of the words defined in task.fs or will I have to translate the implementation myself? Thanks again :)
-
FF6: DMA1 for RX1
-
FF6: interrupt dispatch fix
-
PIC18: RX yet another design
-
Merge branch 'master' of ssh://git.code.sf.net/p/flashforth/ff6
-
FF6: remove TMR 0,2,3,4,5,6 use
-
FF6: remove TMR 01,2,3,4,5,6 use
-
FF6: USB works
-
FlashForth: for PIC and Atmega updated /ff5.0.zip
-
ATMEGA: Faster DOES> code using trampoline
-
ATMEGA: Faster DOES> code using trampoline
-
Fred modified a comment on discussion Open Discussion
I can confirm that 32u4-16MHz-UART38400.hex and 32u4-8MHz-USB are working on my board. I'm flashing using this command : avrdude -p m32u4 -c avrisp2 -e -U flash:w:32u4-8MHz-USB.hex:i -U efuse:w:0xff:m -U hfuse:w:0xdf:m -U lfuse:w:0xff:m It can be used for Sparkfun pro micro : https://www.sparkfun.com/products/12587 but I'm using it right now on a linkit smart duo 7688 thanks!
-
I can confirm that 32u4-16MHz-UART38400.hex and 32u4-8MHz-USB are working on my board. It can be used for Sparkfun pro micro : https://www.sparkfun.com/products/12587 but I'm using it right now on a linkit smart duo 7688 thanks!
-
I uploaded 8 MHz hex files. I could not test, and I hope they work.
-
-
ATMEGA: 8MHz hex files
-
Check the PLLCSR register description. Did you compile FORGET ?
-
I managed to get it to work by compiling with MPLAB X. I'm able to get the UART to work but not the USB CDC, maybe 8MHz is not fast enough... by the way, I try to do forget on a constant but it does not work. I get forget bit5 forget ?
-
is it possible to make it work on 3.3V 8MHz Atmega32u4? could we get a .hex in the folder? :)
-
Sure James. Just use it or loose it.
-
Thanks for the help Mikael. I should probably ask, too - is it okay with you if I do use FlashForth as the base for this college project?
-
This should work XSQUOTE puts the address and length of the inline string on the data stack. The asm push instruction pushes to return stack. In forth you must push to the data stack. HELLO_L: .byte NFA|5 .ascii "hello" .align 1 HELLO: call XSQUOTE .byte 11 ; String length .ascii "Hello World" .align 1 call TYPE return Your example could be written also like this. HELLO_L: .byte NFA|5 .ascii "hello" .align 1 HELLO: m_dup ; push top of stack registers r24,r25 to memory ldi tosl,lo8(HELLO_STR+PFLASH)...
-
I used Moving Forth as tutorial originally when I wrote FF. It could give you some insight.
-
I wrote the whole thing in assembly. This how it looks when compiling over the serial. : hello ." Hello World" ; ok<#,ram> hello Hello World ok<$,ram> see hello 3904 940e call (s" Hello World 3914 940c jmp type ok<$,ram> ' hello 20 dump 3904 :0e 94 47 03 0b 48 65 6c 6c 6f 20 57 6f 72 6c 64 ..G..Hello World 3914 :0c 94 39 03 64 65 08 95 08 39 87 22 61 62 62 64 ..9.de...9."abbd ok<$,ram>
-
This should work XSQUOTE puts the address and length of the inline string on the data stack. The asm push instruction pushes to return stack. In forth you must push to the data stack. HELLO_L: .byte NFA|5 .ascii "hello" .align 1 HELLO: call XSQUOTE .byte 11 ; String length .ascii "Hello World" .align 1 call TYPE return Your example could be written also like this. HELLO_L: .byte NFA|5 .ascii "hello" .align 1 HELLO: m_dup ; push r24,r25 to memory ldi tosl,lo8(HELLO_STR) ; load in R24 ldi tosh,hi8(HELLO_STR)...
-
This should work XSQUOTE puts the address and length of the inline string on the data stack. The asm push instruction pushes to return stack. In forth you must push to the data stack. HELLO_L: .byte NFA|5 .ascii "hello" .align 1 HELLO: call XSQUOTE .byte 11 ; String length .ascii "Hello World" .align 1 call TYPE return Your example could be written also like this. HELLO_L: .byte NFA|5 .ascii "hello" .align 1 HELLO: m_dup ldi tosl,lo8(HELLO_STR) ldi tosh,hi8(HELLO_STR) m_dup ldi tosl, 11 clr tosh...
-
I wrote the whole thing in assembly. This how it looks when compiling over the serial. : hello ." Hello World" ; ok<#,ram> hello Hello World ok<$,ram> see hello 3904 940e call (s" Hello World 3914 940c jmp type ok<$,ram> ' hello 20 dump 3904 :0e 94 47 03 0b 48 65 6c 6c 6f 20 57 6f 72 6c 64 ..G..Hello World 3914 :0c 94 39 03 64 65 08 95 08 39 87 22 61 62 62 64 ..9.de...9."abbd ok<$,ram>
-
This should work XSQUOTE puts the address and length of the inline string on the data stack. The asm push instruction pushes to return stack. In forth you must push to the data stack. HELLO_L: .byte NFA|5 .ascii "hello" .align 1 HELLO: call XSQUOTE .byte 11 ; String length .ascii "Hello World" .align 1 call TYPE return You example could be written also like this. HELLO_L: .byte NFA|5 .ascii "hello" .align 1 HELLO: m_dup ldi tosl,lo8(HELLO_STR) ldi tosh,hi8(HELLO_STR) m_dup ldi tosl, 11 clr tosh call...
-
Thanks Mikael. When you wrote flashforth, did you write directly in assembly or in some higher level language like C or Forth itself before compiling? I'm looking to take a similar approach if possible. Also, if it's not too bothersome, can you spot what's wrong with this assembly code? It's basic, but I still can't get it to work, even though all it's doing is pushing the parameters "type" expects to the stack before calling it: HELLO_L: .byte NFA|5 .ascii "hello" .align 1 HELLO: ldi r16, lo8(HELLO_STR)...
-
Thanks Mikael. When you wrote flashforth, did you write directly in assembly or in some higher level language like C or Forth itself before compiling? I'm looking to take a similar approach if possible. Also, if it's not too bothersome, can you spot what's wrong with this assembly code? It's basic, but I still can't get it to work, even though all it's doing is pushing the parameters "type" expects to the stack before calling it: HELLO_L: .byte NFA|5 .ascii "hello" .align 1 HELLO: ldi r16, lo8(HELLO_STR)...
-
There is no documentation about the assembly code structure, except what you can find at flashforth.com. The assembly source code is the best documentation :-) You could compile your code via serial and then read out the flash and the eeprom to a hex file and then try to program that hexfile into another chip. I think someone tried that and failed. To get your application code frozen so that it cannot be modified any longer would need some new functionality.
-
Hi, Apologies if these questions are silly - I'm very new to this. I'm working on a project that involves using ff5 as a base and my starting point is to define some new, custom words. I'm running ff5 on an Arduino Uno, so rather than using the serial connection and defining the words via forth, I've been trying to define them in assembly. The nature of the project requires that it can be written to the microcontroller, custom words and all, similar to flashforth. Is writing in assembly the only...
-
Like this. : 'r@ rp@ #8 - @ ; : ''r@ rp@ #10 - @ ; : test $dead >r $5555 >r $aaaa >r 'r@ ''r@ r> r> r> ; ok test .s 5555 dead aaaa 5555 dead ok
-
Jan Kromhout posted a comment on discussion Open Discussion
Version 5.32 on a scam3
-
FF6: vocs(new tcb)
-
FF6: small task.fs(new tcb)
-
FF6:small
-
ronny suy posted a comment on discussion Open Discussion
Hi Mikael Tried it in tx0_loop , and it works now :-) Thanks for your info.
-
I will try it again , I originally used to do this , but discovered my fault with the lds instead of in instruction in the emit routine.
-
Which version of FF ?
-
This where I would have put it. TX0_LOOP: rcall PAUSE PUT TEST AND LOOP to TX0_LOOP HERE sbrs t0, 5 ; UDRE0, UDRE USART Data Register Empty rjmp TX0_LOOP m_out UDR0_, tosl m_drop ret
-
Found the solution myself ! I used the EMIT label to add my busy signal check. I also had to use lds instead of in to read pinb . Ronny.
-
Hi , I succesfully build and programmed FF5 on an atmega1284P. I've also build a terminal myself with dvi output and usb keyboard. Problem is that when the screeen scrolls it takes some time because the scrolling is graphics based , not char based. Therefore I used a 'busy' signal from the picodvi to the atmega1284 on pinb0. I want to test this pinb0 just before or just after the sending of a char. I tried it in the label TX0 , but that doesn't seems to work (tried it on both places where the uart...
-
When I wont to copy the first item on the returnstack I can use r@. How to acces the second or the third value? Thanks for any help. Cheers Jan
-
I tested it on a Scamp 3. Worked just fine.
-
-
ALL: COMPARE 2TO
-
-
ALL: TRANSIENT and BEHEAD
-
I've tested this on the Atmega328p and it works well. I'll try testing on a PIC24F256GA704 in a few days. Need to set up the circuit.
-
Got rid of the variable all together. This should work also on PIC24 without eeprom. : transient ( size -- ) flash align latest @ here >r >r ( size ) aligned hi 1+ swap - dp ! latest @ , here $2081 , latest ! r> , r> , ram ; : tfind ( -- xt flag ) ram hi 1- $2001 over ! find ; : permanent ( -- ) tfind ?abort? flash cell+ @ dp ! latest @ , here $2000 , latest ! ram ; : discard ( -- ) tfind ?abort? 2@ ! ;
-
I've tested the latest code and it works well. Thank you! I also tried power-cycling the chip between the transient word calls. Using the EEPROM to store it is a good move in hindsight. This way random crashes during development won't mess things up.
-
I cleaned it up a bit more. Could you test it please. tlnk was put in eeprom to survive restarts while compiling the permanent code. -trans marker -trans eeprom 2variable tlnk ram : transient ( size -- ) aligned latest @ align flash here tlnk 2! hi 1+ swap - dp ! ram ; : permanent ( -- ) flash tlnk cell+ @ dp ! latest @ , here $2000 , latest ! \ dummy def for discard ram ; : discard ( -- ) tlnk 2@ ! ;
-
I tested the transient-definitions feature and it works perfectly on an Atmega328p. Could you add this to the Flashforth forth directory, please? Here's the (slightly cleaned) tested code: \ Transient definitions. Load TRANSient code in high memory \ (e.g. assembler) and DISCARD when no longer needed. -tdf marker -tdf 2variable tmplnk \ Call this before defining the temporary defines \ Size tells how big the transient region is : trans ( size -- ) aligned latest @ align ihere tmplnk 2! flash hi ram...
-
Thank you! The Transient definitions seems perfect for this. It seems to be a very elegant solution because all the benefits of Forth can be used while assembling. I'll try this approach first. The interpret mode solution is what I was originally looking for. It'd be quite feasible to have Python automate the assembly transparently.
-
You can do it like this. Just write the code in MPLABX and copy the numbers from the listing file. Atmega: : i dup \ st -y, r2 \ st -y, r24 [ $b7ed i, ] \ in r30, 3d [ $b7fe i, ] \ in r31, 3e [ $9633 i, ] \ adiw r30, 3 [ $9191 i, ] \ ld r25, z+ [ $9181 i, ] \ ld r24, z+ fetch xfactor [ $018a i, ] \ movw r16, r20 fetch index [ $1b08 i, ] \ sub r16, r24 [ $0b19 i, ] \ sbc r17, r25 index-xfactor [ $01c8 i, ] \ movw r24, r16 ; compileonly PIC24: : i ( -- i R: xfactor -- xfactor ) \ i = index - xfactor...
-
I want to create a new word where all the instructions are inline assembly and then unload asm.fs to save space. Is there a way to create a new word with the contents being filled with opcodes manually?
-
Thanks. I merged it.
-
GitHub committed [c80eb8] on Code
Merge pull request #20 from leStoppe/master
-
Fixed exception when the history file is missing. Added help for quitting the terminal
-
GitHub committed [7db263] on Code
Merge pull request #1 from oh2aun/master
-
Hi Mikael, Initially I couldn't get ff-shell3.py to work on my Linux system. After some debug, it was found to be due to a missing ff-history file. I've updated the script to avoid this issue and raised a pull request at github. Could you review it please and add if you approve. -lestoppe
-
FF6: No wordlist fixes
-
FF6: wordlist bug fix
-
FF6: VOCS
-
FF6: VOCABULARY ASSEMBLER WORDLIST
-
FF6: VOCABULARY ASSEMBLER WORDLIST
-
FF6: Task and other updates
-
FF6: wordlists WIP
-
FF6: SINGLE 3BLINK
-
FF6: wordlists WIP
-
FF6: wordlists pre-alfa
-
FF6: New DOT words
-
FF6: BG task. Refactoring
-
ALL: EXECUTE-PARSING
-
FF6: EXECUTE-PARSING
-
FF6: bg tasks like polyforth
-
FF6: bg tasks like polyforth
-
FF6: bg tasks like polyforth
1 >
