Re: [Amforth] A project using an AmForth recogniser
I have added parts two and three of the project. https://tjnw.co.uk/limpicprog/ Best wishes, Tristan On 06Jan21 18:56, Tristan Williams wrote: > First part of project to make tinkering in the shed easier. > > https://tjnw.co.uk/limpicprog/ > > Best wishes, > Tristan > > > ___ > Amforth-devel mailing list for http://amforth.sf.net/ > Amforth-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/amforth-devel > ___ Amforth-devel mailing list for http://amforth.sf.net/ Amforth-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/amforth-devel
[Amforth] wordlist tools
I have been using wordlists to store and catalogue information for a different project and found I needed some more tools in addition to those in the distribution Source and more details below https://tjnw.co.uk/wlt/ Kind regards, Tristan ___ Amforth-devel mailing list for http://amforth.sf.net/ Amforth-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/amforth-devel
[Amforth] patch for amforth-shell.py
amforth-shell.py replaces known mcu register names with their
values. This makes it very easy to create a file like this and upload
it to the mcu (in this case avr8)
#include ms.frt
: low ( mask port -- ) dup c@ rot invert and swap c! ;
: high( mask port -- ) dup c@ rot or swap c! ;
: blink ( -- )
#32 DDRB high
begin
#32 PORTB low
1000 ms
#32 PORTB high
1000 ms
key? until
;
connecting via serial and typing blink makes the led on pin 13 of an
uno blink until a key is pressed. However, the Forth system knows
nothing about DDRB or PORTB as these were substituted on-the-fly by
amforth-shell.py during the upload. This does save some flash memory
and does simplify writing code, but it is not always what you want. If
you wanted to use PORTB at the interpreter prompt, you can't as it
does not exist as a constant. Adding
#37 constant PORTB
will not help either, as amforth-shell.py still substitutes on-the-fly
creating a new word $25, as
' $25 execute .
will show. I looked to see if I could turn this behaviour off, but
I couldn't find an option to do this. The patch below changes this,
adding the option
--no-regsub, -X Do NOT replace mcu registers with their values.
The default behaviour remains unchanged, with register names
substituted on-the-fly.
--- ../amforth-6.93/tools/amforth-shell.py 2020-12-03 15:29:07.0
+
+++ ../amforth-6.93/tools/new-shell.py 2020-12-16 17:42:48.0 +
@@ -648,9 +648,12 @@
help="Add Include directory")
parser.add_argument("--uploaded-wl", "-U", action="store_true",
default=False,
help="Keep the list of uploaded filenames in the dictionary.")
+parser.add_argument("--no-regsub", "-X", action="store_true",
default=False,
+help="Do NOT replace mcu registers with their values.")
parser.add_argument("files", nargs="*", help="may be found via the
environment variable AMFORTH_LIB")
arg = parser.parse_args()
+self.noregsub = arg.no_regsub
self.debug = arg.debug_serial
self.max_line_length = arg.line_length
self._serial_port = arg.port
@@ -917,7 +920,7 @@
continue
if w in self._appl_defs:
w = self._appl_defs[w]
-elif w in self._amforth_regs:
+elif w in self._amforth_regs and not self.noregsub :
w = self._amforth_regs[w]
elif w.upper() in self.stdwords:
w = w.lower()
___
Amforth-devel mailing list for http://amforth.sf.net/
Amforth-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/amforth-devel
Re: [Amforth] Newbie with a mega2560
Hi Michael, I hope you got AmForth to build successfully under windows for the atmega2560, but if not, I have built it for my Arduino MEGA using the most recent source (r2457). https://sourceforge.net/p/amforth/code/HEAD/tree/trunk/ I have uploaded the resulting hex files to https://tjnw.co.uk/amforth-bin/ I also loaded marker.frt onto the Arduino MEGA and checked that it does what it should do (see [1]). Best wishes, Tristan [1] http://amforth.sourceforge.net/TG/recipes/Forget.html On 24May21 17:57, Michael Picco wrote: > Hello Martin, > Thank you for responding! > In my work directory, which is aptly named 'amforth-6.9', I don't see a copy > of the template.asm file with "amforth-low.asm" mentioned. The > amforth-low.asm file is referenced in the avr8 subdirectory. Is there > something I am missing? > > Kind regards, > Michael > > > > > On 5/24/2021 10:19 AM, Martin Nicholas via Amforth-devel wrote: > > The crucial file to include for an ATmega is the confusingly named: > > "amforth-low.asm" which needs to be un-commented in template.asm. > > > > All the code is then in low flash memory apart from the flash burning > > routine which should be found at NRWW_START_ADDR (0x01f000). > > > > Often, with a new device, you need to burn the fuses "make write-fuse", > > before flashing (and burning fuses for a second time) with "make > > install". > > > > > > ___ > Amforth-devel mailing list for http://amforth.sf.net/ > Amforth-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/amforth-devel ___ Amforth-devel mailing list for http://amforth.sf.net/ Amforth-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/amforth-devel
Re: [Amforth] Newbie with a mega2560
Hi Michael, I used FUSE : -U lfuse:w:0xff:m -U hfuse:w:0x99:m -U efuse:w:0xff:m Best wishes, Tristan On 02Jun21 07:14, Placerville.me wrote: > Hello Tristan, > Thank you for this! I will give it a try later today. What fuse settings > did you use? > > Kind regards, > > Michael > > Sent from my iPhone > > > On Jun 2, 2021, at 01:18, Tristan Williams wrote: > > > > Hi Michael, > > > > I hope you got AmForth to build successfully under windows for the > > atmega2560, but if not, I have built it for my Arduino MEGA using the > > most recent source (r2457). > > > > https://sourceforge.net/p/amforth/code/HEAD/tree/trunk/ > > > > I have uploaded the resulting hex files to > > > > https://tjnw.co.uk/amforth-bin/ > > > > I also loaded marker.frt onto the Arduino MEGA and checked that it > > does what it should do (see [1]). > > > > Best wishes, > > Tristan > > > > [1] http://amforth.sourceforge.net/TG/recipes/Forget.html > > > >> On 24May21 17:57, Michael Picco wrote: > >> Hello Martin, > >> Thank you for responding! > >> In my work directory, which is aptly named 'amforth-6.9', I don't see a > >> copy > >> of the template.asm file with "amforth-low.asm" mentioned. The > >> amforth-low.asm file is referenced in the avr8 subdirectory. Is there > >> something I am missing? > >> > >> Kind regards, > >> Michael > >> > >> > >> > >> > >>> On 5/24/2021 10:19 AM, Martin Nicholas via Amforth-devel wrote: > >>> The crucial file to include for an ATmega is the confusingly named: > >>> "amforth-low.asm" which needs to be un-commented in template.asm. > >>> > >>> All the code is then in low flash memory apart from the flash burning > >>> routine which should be found at NRWW_START_ADDR (0x01f000). > >>> > >>> Often, with a new device, you need to burn the fuses "make write-fuse", > >>> before flashing (and burning fuses for a second time) with "make > >>> install". > >>> > >> > >> > >> > >> ___ > >> Amforth-devel mailing list for http://amforth.sf.net/ > >> Amforth-devel@lists.sourceforge.net > >> https://lists.sourceforge.net/lists/listinfo/amforth-devel > > > > > > ___ > > Amforth-devel mailing list for http://amforth.sf.net/ > > Amforth-devel@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/amforth-devel > > > > ___ > Amforth-devel mailing list for http://amforth.sf.net/ > Amforth-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/amforth-devel ___ Amforth-devel mailing list for http://amforth.sf.net/ Amforth-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/amforth-devel
Re: [Amforth] Newbie with a mega2560
Hi Michael, Glad it is working. I use amforth-shell.py which is in the tools directory. It needs python3 and pySerial to be installed to work. A basic command line looks like this amforth-shell.py --port DEVICE --speed 38400 FILE_TO_UPLOAD but there are many other options and commands (such as the directive #include). The documentation is in the python3 source. Best wishes, Tristan On 03Jun21 21:43, Michael Picco wrote: > Hi Tristan, > > I've got it up and running; even adding 'marker'. > You have probably mentioned it before, but what is the best interface to use > that will allow me to upload source files? > > Thank you for your patience! > > Kind regards, > > Michael > > On 6/2/2021 8:36 AM, Tristan Williams wrote: > > Hi Michael, > > > > I used > > > > FUSE : -U lfuse:w:0xff:m -U hfuse:w:0x99:m -U efuse:w:0xff:m > > > > Best wishes, > > Tristan > > > > On 02Jun21 07:14, Placerville.me wrote: > > > Hello Tristan, > > > Thank you for this! I will give it a try later today. What fuse > > > settings did you use? > > > > > > Kind regards, > > > > > > Michael > > > > > > Sent from my iPhone > > > > > > > On Jun 2, 2021, at 01:18, Tristan Williams wrote: > > > > > > > > Hi Michael, > > > > > > > > I hope you got AmForth to build successfully under windows for the > > > > atmega2560, but if not, I have built it for my Arduino MEGA using the > > > > most recent source (r2457). > > > > > > > > https://sourceforge.net/p/amforth/code/HEAD/tree/trunk/ > > > > > > > > I have uploaded the resulting hex files to > > > > > > > > https://tjnw.co.uk/amforth-bin/ > > > > > > > > I also loaded marker.frt onto the Arduino MEGA and checked that it > > > > does what it should do (see [1]). > > > > > > > > Best wishes, > > > > Tristan > > > > > > > > [1] http://amforth.sourceforge.net/TG/recipes/Forget.html > > > > > > > > > On 24May21 17:57, Michael Picco wrote: > > > > > Hello Martin, > > > > > Thank you for responding! > > > > > In my work directory, which is aptly named 'amforth-6.9', I don't see > > > > > a copy > > > > > of the template.asm file with "amforth-low.asm" mentioned. The > > > > > amforth-low.asm file is referenced in the avr8 subdirectory. Is there > > > > > something I am missing? > > > > > > > > > > Kind regards, > > > > > Michael > > > > > > > > > > > > > > > > > > > > > > > > > > On 5/24/2021 10:19 AM, Martin Nicholas via Amforth-devel wrote: > > > > > > The crucial file to include for an ATmega is the confusingly named: > > > > > > "amforth-low.asm" which needs to be un-commented in template.asm. > > > > > > > > > > > > All the code is then in low flash memory apart from the flash > > > > > > burning > > > > > > routine which should be found at NRWW_START_ADDR (0x01f000). > > > > > > > > > > > > Often, with a new device, you need to burn the fuses "make > > > > > > write-fuse", > > > > > > before flashing (and burning fuses for a second time) with "make > > > > > > install". > > > > > > > > > > > > > > > > > > > > > ___ > > > > > Amforth-devel mailing list for http://amforth.sf.net/ > > > > > Amforth-devel@lists.sourceforge.net > > > > > https://lists.sourceforge.net/lists/listinfo/amforth-devel > > > > > > > > ___ > > > > Amforth-devel mailing list for http://amforth.sf.net/ > > > > Amforth-devel@lists.sourceforge.net > > > > https://lists.sourceforge.net/lists/listinfo/amforth-devel > > > > > > > > > ___ > > > Amforth-devel mailing list for http://amforth.sf.net/ > > > Amforth-devel@lists.sourceforge.net > > > https://lists.sourceforge.net/lists/listinfo/amforth-devel > > > > ___ > > Amforth-devel mailing list for http://amforth.sf.net/ > > Amforth-devel@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/amforth-devel > > > ___ Amforth-devel mailing list for http://amforth.sf.net/ Amforth-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/amforth-devel
Re: [Amforth] Compiling for a headless target
Hello and welcome Helge, > amForth is an interactive Forth. The compiler runs on the target and > writes to the flash memory of the device. This requires to send all the > source code through the UART interface. This is the usual way AmForth is used. However it is possible to write words in AVR assembler and add them to the build process that creates the two hex files that make up the base AmForth system (these are the two hex files that are initially flashed). Such words would be available to you without having to send Forth code over the UART. > I want to develop a Forth application for a target that uses the > ATmeage256 USART for the application data. By default, AmForth only knows about one UART and is expecting to receive Forth over it. If instead, you want to receive application data over that UART you could write a Forth word(s) to parse that application data received over the UART (write the Forth word to do it, send it over UART, execute the Forth word, disconnect the UART from PC, connect UART to application data source). However, I think this would be painful to develop and (very) limited in terms of rate of data that could be handled. If the UC on which AmForth is running has multiple UARTs then it is possible to use these for application data. This I have done in the past https://tjnw.co.uk/files/uarts/fsm-uart.mp4 but it means writing your own UART handlers (which can be done in Forth). Again, application data rate may be limiting. You mentioned the ATmega256 - were you looking at ATmega256X or the ATmega256RFR2? They all have multiple UARTs I think. Kind regards, Tristan ___ Amforth-devel mailing list for http://amforth.sf.net/ Amforth-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/amforth-devel
Re: [Amforth] Building amForth with Microchip Studio 7
Hi Helge, I don't use studio, but from the command line you give below > avrasm2.exe -fI -o my.hex -e my.eep -S my.tmp -W+ie -I"D:/Program Files > (x86)\Atmel\Studio\7.0\Packs\atmel\ATmega_DFP\1.6.364\avrasm\inc" > -I"amforth-6.9\avr8" -I"amforth-6.9\avr8\devices\atmega32" > -I"amforth-6.9\appl\arduino" -I"amforth-6.9\common" -im32def.inc -d > "Debug\myprog_m32.obj" "main.asm" -I "D:\Program Files > (x86)\Atmel\Studio\7.0\toolchain\avr8\avrassembler\Include" it looks like it is including files from the devices\atmega32 directory and using m32def.inc which are associated with the atmega32 chip rather than the atmega328p. Somewhere the target device needs to be set to an atmega328p. Kind regards, Tristan On 07Sep21 21:32, Helge Kruse wrote: > I am a newby to amForth. I want to use it at ATmega 2560. For the first > steps I want to use the more common board Arduino UNO. > > I flashed the files uno.hex and uno.eep.hex from the directory > amforth-6.9\appl\arduino to my Arduino UNO. This gives me a greeting > > amforth 6.9 ATmega328P Forthduino > > > > I think, the mega328p fuses and the USB/serial connection are verified. > Now I want to build the amForth from the sources. The documentation at > http://amforth.sourceforge.net/UG/quick-windows.html is a bit dated (for > amForth 6.6). The Atmel studio is not available anymore. I found only > the Microchip Studio 7 as the successor of the Atmel studio at the > Microchip website. (Atmel has been purchased by Microchip.) > > I set up a main.asm file as > > .include "preamble.inc" > .equ F_CPU = 1600 > .include "drivers/usart.asm" > .include "amforth.asm" > > and configured the include directories: > $(PackRepoDir)\atmel\ATmega_DFP\1.6.364\avrasm\inc > amforth-6.9\avr8 > amforth-6.9\avr8\devices\atmega328p > amforth-6.9\appl\arduino > amforth-6.9\common > Without these directories some .asm files had not been found. The > Microchip Studio 7 compiles without errors: > > avrasm2.exe -fI -o my.hex -e my.eep -S my.tmp -W+ie -I"D:/Program Files > (x86)\Atmel\Studio\7.0\Packs\atmel\ATmega_DFP\1.6.364\avrasm\inc" > -I"amforth-6.9\avr8" -I"amforth-6.9\avr8\devices\atmega32" > -I"amforth-6.9\appl\arduino" -I"amforth-6.9\common" -im32def.inc -d > "Debug\myprog_m32.obj" "main.asm" -I "D:\Program Files > (x86)\Atmel\Studio\7.0\toolchain\avr8\avrassembler\Include" > > > Segment BeginEnd Code Data UsedSize Use% > - > [.cseg] 0x00 0x007f82 1838 11508 13346 32768 40.7% > [.dseg] 0x60 0x00011f 01911912048 9.3% > [.eseg] 0x00 0x86 01341341024 13.1% > Assembly complete, 0 errors. 8 warnings > > I can also provide the complete assembler stdout stream. But I hesitate > to send such a large mail to the list without request. > > But after flashing my.hex and my.eep to the Arduino UNO I can see > nothing. Therefore I assume something's wrong with my build. > > Can somebody provide an minimum example for a basic amForth project with > the Microchip Studio 7? > Is there any updated documentation for the build process that handles > the Studio 7 environment? > Any hints how I find and remove the problem? > > I hope this can be easily solved. I've seen in the mailing list archive > that a build with mega2560 was successful lately. > > Best regards, > Helge > > > ___ > Amforth-devel mailing list for http://amforth.sf.net/ > Amforth-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/amforth-devel > ___ Amforth-devel mailing list for http://amforth.sf.net/ Amforth-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/amforth-devel
Re: [Amforth] Building amForth with Microchip Studio 7
Hi Helge, Glad you got AmForth to build with an atmega328p. Can you make avrasm2.exe output a list file, re-build and then check the list file for lines containing store-i ? For the atmega2560 I would expect .include "words/store-i.asm" .include "words/store-i_big.asm" For the atmega328p I would expect .include "words/store-i.asm" .include "words/store-i_nrww.asm" Kind regards, Tristan On 08Sep21 10:54, Helge Kruse wrote: > On 08.09.2021 08:06, Tristan Williams wrote: > > Hi Helge, > > > > I don't use studio, but from the command line you give below > > > > > avrasm2.exe -fI -o my.hex -e my.eep -S my.tmp -W+ie -I"D:/Program Files > > > (x86)\Atmel\Studio\7.0\Packs\atmel\ATmega_DFP\1.6.364\avrasm\inc" > > > -I"amforth-6.9\avr8" -I"amforth-6.9\avr8\devices\atmega32" > > > -I"amforth-6.9\appl\arduino" -I"amforth-6.9\common" -im32def.inc -d > > > "Debug\myprog_m32.obj" "main.asm" -I "D:\Program Files > > > (x86)\Atmel\Studio\7.0\toolchain\avr8\avrassembler\Include" > > > > it looks like it is including files from the devices\atmega32 > > directory and using m32def.inc which are associated with the atmega32 > > chip rather than the atmega328p. Somewhere the target device needs to > > be set to an atmega328p. > > This is a good point! With the correct include path I get a working, > self-compiled amForth. Further I removed the -im32def.inc. The file is > included in the amForth sources anyway. > > Thank you. > > Now I want to take the second step, build for ATmega2560. I use nearly > the same avrsam2 command line, but changed the include path from > amforth-6.9\avr8\devices\atmega32 > to > amforth-6.9\avr8\devices\atmega2560 > > avrasm2.exe -fI -o my2560.hex -e my2560.eep -S my2560.tmp -W+ie > -I"amforth-6.9\avr8" -I"amforth-6.9\avr8\devices\atmega2560" > -I"amforth-6.9\appl\arduino" -I"amforth-6.9\common" -d > "Debug\my2560.obj" "main.asm" -I "D:\Program Files > (x86)\Atmel\Studio\7.0\toolchain\avr8\avrassembler\Include" > > Now I get several errors like: > error: Overlap in .cseg: addr=0x1f000 conflicts with 0x1f000:0x1f396 > error: Overlap in .cseg: addr=0x1f001 conflicts with 0x1f000:0x1f396 > ... > error: Overlap in .cseg: addr=0x1f03e conflicts with 0x1f000:0x1f396 > > Shouldn't this compile out of the box? > I am also curious about this range 0x1f000:0xf1396. > > Best regards, > Helge > > > ___ > Amforth-devel mailing list for http://amforth.sf.net/ > Amforth-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/amforth-devel > ___ Amforth-devel mailing list for http://amforth.sf.net/ Amforth-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/amforth-devel
Re: [Amforth] Building amForth with Microchip Studio 7
Hi Helge, A mystery, but given that, as far as I know, every (modern) build eventually uses avrasm2.exe to create the hex files, one that should be solvable. Given that you have an UNO build working, I can only think that your atmega2560 build is not finding all the needed files (or finding some it shouldn't) or that the build target is not actually an atmega2560. I use a Makefile based build (on macos) that is based on the one that is part of the distribution. I can send you an archive with the Makefile, list file, etc. for you to check over. I don't have access to a Windows machine or I would try to replicate what you are doing. Kind regards, Tristan On 08Sep21 19:40, Helge Kruse wrote: > > On 08.09.2021 17:45, Tristan Williams wrote: > > Hi Helge, > > > > Glad you got AmForth to build with an atmega328p. > > > > Can you make avrasm2.exe output a list file, re-build and then check > > the list file for lines containing store-i ? > > > > For the atmega2560 I would expect > > > > .include "words/store-i.asm" > > .include "words/store-i_big.asm" > > > > For the atmega328p I would expect > > > > .include "words/store-i.asm" > > .include "words/store-i_nrww.asm" > > Well, the .lss doesn't show the source lines for the atmega2560. But I see > > atmega2560: > dict/nrww.inc(93): Including file 'words/store-i_big.asm' > > atmega328p: > dict/nrww.inc(95): Including file 'words/store-i_nrww.asm' > > as you expected. Further the core_8k.inc is included for the 256 instead > of the core_4k.inc for 328p. > > Should I send the .lss file (121k) or make it somewhere available? > > > Best regards, > Helge > > > > ___ > Amforth-devel mailing list for http://amforth.sf.net/ > Amforth-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/amforth-devel > ___ Amforth-devel mailing list for http://amforth.sf.net/ Amforth-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/amforth-devel
Re: [Amforth] AmForth 6.9 on Arduino MEGA using ATmega2560- No reponse at console
Hello Christian, Below is a link to AmForth hex files I built for my Arduino MEGA using the (then) most recent source (r2457). The console baud rate is 38400 and build details are in the atmega2560.asm file. https://tjnw.co.uk/amforth-bin/ Some background info is contained in this message thread. https://sourceforge.net/p/amforth/mailman/message/37296323/ Hope this helps and let me know if you get it up and running. Kind regards, Tristan On 16Apr22 07:08, Christian Hinse wrote: > Hi to your support team. > > I have AmForth working properly on an Arduino UNO. > > I am now trying to use it with an Arduino MEGA using the Atmega2560 but I get > no console response after programming the files atmega256.hex and > atmega256.eep.hex from folder \amforth-6.9\appl\atmega2561 of downloaded file > amforth-6.9.zip. > > I still consider myself as a beginner hobbyist and I do not yet have the > ability to assemble my one code from source. > > * Are these Hex file effectively compatible with the Arduino MEGA using > the ATmega2560 ? > * What are the fuses that I should use with the Arduino MEGA.using the > ATmega2560 ? > > I am currently using the followings fuses: > > Reading fuses... > >>>: avrdude -u -c usbasp -p m2560 -P usb -b 115200 -B 1.0 -U hfuse:r:-:h -U > >>>lfuse:r:-:h -U efuse:r:-:h > SUCCESS: Read high fuse > SUCCESS: Read low fuse > SUCCESS: Read extended fuse > > My serial port COM7 is transmitting to the Arduino MEGA because I can see > the RX LED flashing. I don not see an response on the TX LED or the console. > > * Am I using HEX files that are not compatible with the Arduino MEGA > using an ATmega2560 MCU ? > * If not, what can I do to make these files work with the Arduino MEGA > using the ATmega2560. > > I would appreciate your help to resolve this problem. > > Thanks. > > Christian Hinse > > > > > > ___ > Amforth-devel mailing list for http://amforth.sf.net/ > Amforth-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/amforth-devel > ___ Amforth-devel mailing list for http://amforth.sf.net/ Amforth-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/amforth-devel
Re: [Amforth] AmForth 6.9 on Arduino MEGA using ATmega2560- No reponse at console
Hi Christian, Glad it worked. > How much of 256KB flash is effectively usable with AmForth on the 2560? ? Good question. I don't know. The file avr8/words/store-i_big.asm may give some clues. > Will this work as well on a Chinese ATmega2560ProMini (with FTDI USB chip > for terminal input) ? Again, I don't know. However, if the board has an ATmega2560 mcu running at 16 MHz then there is good chance. I think only by flashing the board and testing it will you have a better idea. > If so, may I share your links with a friend who has an ATmega2560ProMini? Yes. Kind regards, Tristan On 16Apr22 16:34, Christian Hinse wrote: > Hi Tristan. > > Your r2457AmForth version is working fine on my Arduino MEGA with > ATmega2560, except for a few garbled character after the reset. But that is > probably normal. It occurs on the UNO as well. > > > amforth 7.0 ATmega2560 16000 kHz > > words > int-trap int@ int! -int +int #int irq[]# postpone (marker) end-code code > forth-wordlist wordlist set-current >body s>d bounds init-ram ee>ram #tib tib > source-tib refill-tib 2swap cmove dnegate dabs j * icompare nfa>cfa > name>string traverse-wordlist search-wordlist (defer) defer@ defer! Udefer! > Udefer@ Rdefer! Rdefer@ Edefer! Edefer@ i-cell+ to unused noop ver ?stack > rectype-null rectype-xt rec-find rec-num rectype-dnum rectype-num recognize > forth-recognizer interpret depth rp0 sp0 warm cold pause quit .input .error > .ready .ok find-xt parse-name /string source parse >number number char refill > accept cscan cskip throw catch handler ' type spaces space cr icount itype s, > digit? ud/mod ud.r ud. . d. .r d.r sign #> #s # <# hold hld tolower toupper > within max min abs mod / negate u/mod /mod turnkey bl hex decimal bin allot > here ehere dp key? key emit? emit pad >in tuck 2drop 2dup cell+ cells base > state f_cpu environment fill s" ." pick words show-wordlist u.r u. dinvert d- > d+ d2/ d2* nr> n>r -1 2 1 = 2literal @i (i!) !i @e !e 2r> 2>r up! up@ >< > cmove> unloop i sp! sp@ rp! rp@ +! rshift lshift ?negate 1- 1+ xor or and 2* > 2/ invert um* um/mod m* + - log2 > < u> u< 0 true d0< d0> 0> 0< 0= <> r@ >r > r> nip rot drop over swap ?dup dup !u @u c@ c! ! @ (value) execute exit > applturnkey nfa>lfa compare cfg-recs cfg-order get-current map-stack > set-stack get-stack ?abort abort abort" [char] immediate recurse user > constant variable [ ] ; :noname : does> reveal wlscope header create lp lp0 > >l l> endloop ?do leave +loop loop do again until repeat while begin then > else if ahead sliteral literal ['] , compile ( \ (create-in) (create) latest > newest 1ms name>flags umin umax ud* m+ sleep !wdc wdr c!@spi bm-toggle > bm-clear bm-set b> >b b!- b!+ nb! b! b@- b@+ nb@ b@ a> >a a!- a!+ na! a! a@- > a@+ na@ a@ +usart ubrr tx?-poll tx-poll rx?-buf rx-buf isr-rx >rx-buf ok > > > > Some question: > > * How much of 256KB flash is effectively usable with AmForth on the 2560? > * Will this work as well on a Chinese ATmega2560ProMini (with FTDI USB > chip for terminal input) ? > * If so, may I share your links with a friend who has an > ATmega2560ProMini? > > Thanks a lot for your help. > > Christian Hinse > > From: Tristan Williams > Sent: 16 April 2022 06:05 > To: amforth-devel@lists.sourceforge.net > Subject: Re: [Amforth] AmForth 6.9 on Arduino MEGA using ATmega2560- No > reponse at console > > Hello Christian, > > Below is a link to AmForth hex files I built for my Arduino MEGA using the > (then) most recent source (r2457). The console baud rate is 38400 and > build details are in the atmega2560.asm file. > > https://tjnw.co.uk/amforth-bin/ > > Some background info is contained in this message thread. > > https://sourceforge.net/p/amforth/mailman/message/37296323/ > > Hope this helps and let me know if you get it up and running. > > Kind regards, > > Tristan > > On 16Apr22 07:08, Christian Hinse wrote: > > Hi to your support team. > > > > I have AmForth working properly on an Arduino UNO. > > > > I am now trying to use it with an Arduino MEGA using the Atmega2560 but I > > get no console response after programming the files atmega256.hex and > > atmega256.eep.hex from folder \amforth-6.9\appl\atmega2561 of downloaded > > file amforth-6.9.zip. > > > > I still consider myself as a beginner hobbyist and I do not yet have the > > ability to assemble my one code from source. > > > > * Are these Hex file effectively compatible with the Arduino MEGA usi
Re: [Amforth] successful compilation with avra
Hello Mark, Brian, Erich, George Thank you! A very welcome set of messages on a bank holiday weekend. For non-windows users having avra as the assembler in the build chain would go along way in making AmForth more approachable and maintainable. I think this is the repo for avra that does not have the macro/ parenthesis issue you mention[1] https://github.com/srtlg/avra/tree/development I downloaded it and built it on macOS (requiring only typing 'make') and updated the AmForth Makefile to run arva. The updated makefile built the hex files for an uno with AmForth 6.9. I did not experience any issues with d0< but I recall there were some changes in that area between 6.8 and 6.9. I've not flashed it yet as I have to dig out an uno from storage but the hex files are the same size and with zero diffs when compared with my previous wine/avrasm32 builds. -rw-r--r-- 1 tw staff 29346 26 Aug 17:53 uno.hex -rw-r--r-- 1 tw staff 29346 26 Aug 16:29 save.hex -rw-r--r-- 1 tw staff239 26 Aug 17:53 uno.eep.hex -rw-r--r-- 1 tw staff239 26 Aug 16:29 save.eep.hex Best wishes, Tristan [1] https://github.com/Ro5bert/avra/issues/54 On 25Aug23 17:12, George Herzog wrote: > Thanks for your efforts. > > People don't often appreciate how much knowledge and effort goes into > successful compilation of code. > > > > On Fri, Aug 25, 2023, 3:15 PM Erich Wälde wrote: > > > Hello Brian and Mark, > > > > very nice to see emails on this list :) > > > > Compiling amforth with avra? > > > > I have made numerous experiments a long time ago and again more > > recently. If memory serves me well: > > - Amforth had been good with avra, at least in the 4.x range. > > - However, avrasm2.exe could do more clever tricks, and Matthias > > started using those. > > - I did make a fork of amForth from Version 5.0, this can be > > assembled with avra, see: > > https://git.sr.ht/~ew/hbv3_am50forth > > - avra received a bit of attention not so long ago (same repo > > you found): > > https://github.com/Ro5bert/avra > > > $ avra --version > > > AVRA: advanced AVR macro assembler (version 1.4.2) > > which among other changes now includes my favourite atmega644p. > > > > So, I am currently dabbling with my fork again in the hope to > > eventually catch that problem of long term stability. There is > > absolutely no reason, why I have to reprogram one or two of my > > controllers a few times per year, because they do not start up > > after a power cycle, which in turn is done, because the > > communication with that controller ceases to work. I went back > > to amforth 5.0 for simplicity reasons. > > > > > > All that being said, I would be very interested to see the > > changes, maybe, just maybe we can fix the amForth source tree > > enough to make avra happy. > > > > > > Cheers, > > Erich > > > > Brian K Navarette writes: > > > > > That is awesome news! > > > Brian-in-ohio > > > > > > > > > On Thu, Aug 24, 2023 at 2:59 PM Mark Roth wrote: > > > > > >> Hello AmForth. It has been some time and quite weird things since last > > I've > > >> been here. I am still using AmForth with my trusty atmega1284p and > > learning > > >> the language as time permits. I remember having heard talk that avra had > > >> gotten (almost) to the point of being able to compile the source tree > > here. > > >> First I tried with 1.3 I think and it failed miserably. Then I found a > > repo > > >> on github (Ro5bert/avra) that seemed to almost but not quite do it. I > > was > > >> getting a pile of errors for macro calls. So looking into the issues I > > saw > > >> that someone had forked that repo and fixed the issue. Something to do > > with > > >> not having a space between the opening parenthesis and the macro name. > > So I > > >> tracked down the fix branch (srtlg/avra -b development-issue54 if I > > >> remember correctly) and built that locally. Then substituted that avra > > >> version with the wine one I had been using to build. > > >> It still didn't build. Very almost, but not quite. > > >> However, the issue was with errors in /avr8/words/d-lesszero.asm about > > the > > >> Y register not being declared and/or able to be used for the adiw call. > > >> Looking into the source tree I found other usages of y in those calls > > but > > >> they were all in lower case. > > >> Yeah, that did fix it. I'm not sure that I can flash my controller here > > >> since I'm on summer break but it does seem promising. Or maybe I did > > pack > > >> my programmer and can give it a go. The file sizes are the same or > > similar > > >> but there are differences. Granted, I've made changes that may not be > > >> represented in my working project and it may just be that. > > >> Time will tell but it would be great to get rid of the need to use wine > > to > > >> build AmForth here. > > >> Well well well. It appears to have worked. I make install'd the whole > > thing > > >> (since for some reason I did pack my usbasp and could try it out. I'm > > sure > > >> mor
Re: [Amforth] Maintainer(s) for AmForth
On 30Sep23 11:35, Keith Amidon wrote: > On 9/30/23 05:25, Mark Roth wrote: > > Hello Keith. I'm glad you mentioned the shell (and that you wrote it in the > > way back when) because it had slipped my mind to get back to trying it. > > I've gotten so used to using e4thcom that the tool in the repo is just > > collecting figurative dust for me. Tristan W brought it up into the python3 > > realm some time back and I think sorted some bug or another after that. > > I get the feeling there are a number of the back in the old days folks > > doing the same and glancing at the mailing list. One would hope anyway. > > Seeing the dates on the really old commits this past week really drove it > > home just how long this project has been around. :) > > Thanks! I'm not familiar with e4thcom. It looks interesting. > > I'm curious if it also solves the primary reason I had for writing > amforth-shell.py in the first place, which had to do with making higher baud > rates work reliably without overrunning the very small serial input buffer > amforth uses. When using a terminal emulator file transfer that just sent at > maximum baud rate I frequently had problems with this on ATMega 328 based > arduinos if the baud rate was greater than 19200 because amforth would fall > behind as it was storing new words. amforth-shell.py solves this problem by > waiting for a positive echo of the character it sent before sending the next > which let me run at 115k and greatly sped up larger file transfers while > ensuring they were reliable. For my project I had 12+ microcontrollers I had > to regularly reprogram with a fairly large forth program and this was > necessary to keep myself going crazy while waiting during updates. :-) > > --- Keith > Hello Keith, Thank you for writing amforth-shell. For me it has been a core part of AmForth and a key part of many of my projects. The combination of its reliability and AmForth recognizers meant I could automate sending both commands and data as Forth words over to an mcu running AmForth. Human readable and with no additional effort on my part to deal with pc-mcu communications :) Kind regards and thanks, Tristan ___ Amforth-devel mailing list for http://amforth.sf.net/ Amforth-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/amforth-devel
Re: [Amforth] avra on a raspi zero v1
Hello Mark, I took a local clone of your repo and the new template built for an uno without issue. Thank you. Are you open to a pull request? Seeing that we are dealing with makefiles, it seemed a good time to address prebuilt binaries. I have blended/amended your template with the existing makefile in appl/arduino to output hex files for the m328 based UNO and the 2561 based mega. Separately, I have written a script to produce a simple html build specific reference-card that lists the words built into the respective pre-built hex files. It searches the .lst file produced by the assembler (in this case avra) for the assembler source files used and then searches them for the documentation. This has been discussed [1] on the mailing list before. However, if there are going to be prebuilt hex files in the repo, then a reference-card for those builds will be helpful for the person trying them out. It is not intended to be a substitute for the reference-card for AmForth as a whole. I have put up the html here as an idea. https://www.mostlymostly.uk/amforthdocs/prebuilt.html The page uses material from the existing site. It is not plumbed into the rst source (but it could be). Best wishes, Tristan [1] https://sourceforge.net/p/amforth/mailman/message/37112236/ On 30Sep23 22:30, Mark Roth wrote: > On Sat, Sep 30, 2023 at 9:46 PM Keith Amidon wrote: > > > On 9/30/23 03:17, Mark Roth wrote: > > > Hello weekend AmForth'ers > > > > > > So, while waiting to see what will happen with the repo I have continued > > to > > > play with a git version for my own use. I have reworked the makefile and > > > made some changes to the repo structure to accommodate for the new avra > > > code (which is still only a placeholder until I get that repository in > > > properly). I think that the new makefile should make it very easy to get > > > started and there is a bit of a long winded readme to explain anything > > that > > > has changed. If anyone wants to take a look and give feedback that would > > be > > > great. > > > > > > https://github.com/CableGuy67/AmForth > > > > I took a quick look at the makefile and related fines in the > > appl/template directory, which I believe is what you're referring to > > here. I have two minor suggestions: > > > > 1. How about renaming "template.asm" as "app.asm" and making the > > corresponding changes to the makefile? I think this would make a > > workflow of copying the template directory to one named for a new > > application without updating names within the template directory > > very natural. I would feel weird leaving around a file called > > "template.asm" because that doesn't communicate well the purpose of > > the file in the ultimate project. But "app.asm" seems like it could > > usually fit. Having a consistent name like this could also simplify > > documentation. > > > > Yeah, that does sound like a good idea. I like the way it implies intent. > > > > 2. This is really just a template for an avr8 project, right? Perhaps > > the directory containing this sub-tree should be named > > "avr8-template" instead of "template"? It seems to me that really > > all the directories under "/appl" are currently templates for > > different targets? Is that right? > > > > Note that I haven't tried anything here, these all come from code > > inspection and may be due to misunderstandings on my part. > > > > Cheers! Keith > > > > You're not wrong in that. Since I only use the avr-8 chips I only recently > even looked into those other appl directories. It seems that it just sort > of grew like mushrooms (appl that is) and never had any cohesiveness. > Indicating that it is the appl template for avr8 is a no brainer. I have to > wonder if the makefile at one point in time was supposed to be more > inclusive with the other platforms but just never got there. > > Thanks for the suggestions. Different eyes and all. > > All the best, > Mark > > > > > > ___ > > Amforth-devel mailing list for http://amforth.sf.net/ > > Amforth-devel@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/amforth-devel > > > > ___ > Amforth-devel mailing list for http://amforth.sf.net/ > Amforth-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/amforth-devel ___ Amforth-devel mailing list for http://amforth.sf.net/ Amforth-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/amforth-devel
[Amforth] AmForth RISC-V
Hi, I managed to get AmForth RISC-V running on a SparkFun RED-V Thing Plus [1] which is based on the same/similar SiFive RISC-V FE310 SoC as on the now discontinued HiFive1 board [2] amforth 7.0 RV32IM RED-V Thing Plus Wed Oct 11 21:25:54 BST 2023 > words forth-wordlist environment riscv-wordlist @cycle dump .8hex .4hex .2hex ?ascii type0 hifive-turnkey rev-info build-info mtimecmp mtime black magenta cyan yellow white blue green red led-init cacheflush inflash? c!i !i serial-emit? serial-emit serial-key? serial-key serial-lastchar +usart ram-wordlist wordlist Udefer! Udefer@ dp >in 0> get-current >body wlscope variable to ; : ] reveal recurse ?abort postpone +loop newest loop latest header endloop do (create) defer! defer@ create constant :noname char ['] [compile] [char] \ abort" abort ' turnkey immediate leave >l l> lp lp0 repeat again else if while until then begin ahead words sliteral s, ." s" itype type count ver init-ram ?do map-stack interpret recognize cfg-recognizer forth-recognizer split rectype-split rec-split rec-num rectype-dnum rectype-num rectype-xt rec-find rectype-null set-base bases number >number digit? toupper within ud* m+ name>flags name>string search-wordlist current show-wordlist traverse-wordlist nfa2cfa nfa>lfa find-xt cfg-order c, , compile literal 2literal /string parse parse-name cskip cscan ?stack source-tib source throw catch handler .ready .ok .input .error ?crlf bs accept refill-tib refill .s ud.r ud. u. d. d.r . sign #> #s # <# hold hld allot here pad hex decimal ( [ spaces space bl cr ms warm false true -1 4 2 1 0 nr> n>r compare 1ms up! up@ aligned j i unloop bounds nop pause emit? emit key? key execute quit cold #tib tib state cells cell+ 2/ 2* 2- 2+ 1- 1+ - + base d0= d0< ud/mod um/mod s>d 2dup d- d+ dnegate dabs d2/ d2* 2r> 2>r 2r@ 2over 2drop 2nip 2swap umax umin max min = <> u> u< u<= u>= > < <= >= 0< 0<> 0= c! c@ +! fill move lshift rshift invert not xor or and rdrop rdepth depth /mod u/mod mod / m* um* * abs negate ! @ sp0 sp sp! sp@ rp rp! rp@ r@ r> >r pick -rot tuck ?dup rot over nip dup swap drop exit ok > I needed to make a few changes to the existing code to get it to run. Flashing AmForth to the SparkFun RED-V Thing Plus is simple, as when plugged in it presents itself as a drive. Copy the hex file to the drive and it flashes itself. On reset a bootloader runs the copied and flashed AmForth hex file, but it sends some AT commands over the usart prior to running the flashed program. It may do other things too. A search suggests this might be related to a WiFi/BT chip on the HiFive1 Rev B. [3] Remaking AmForth for a 115200 uart shows this nicely. ATE0--> Send Flag error: #0 #0 #0 #0 AT+BLEINIT=0--> Send Flag error: #255 #255 #255 #255 AT+CWMODE=0--> Send Flag error: #255 #248 #0 #0 amforth 7.0 RV32IM RED-V Thing Plus Thu Oct 12 21:48:35 BST 2023 > I know next to nothing about risc-v assembly, but Matthias' code/macros look super elegant to me. COLON "hifive-turnkey", APPLTURNKEY .word XT_LED_INIT .word XT_DECIMAL .word XT_INIT_USART .word XT_DOT_VER, XT_SPACE .word XT_ENV_BOARD,XT_TYPE, XT_CR .word XT_BUILD_INFO,XT_TYPE .word XT_SPACE, XT_REV_INFO, XT_TYPE .word XT_EXIT The SparkFun RED-V Thing Plus has a different LED arrangement and location but it was easy enough to cobble together some assembler words to make a proof of blinky. CODEWORD "led-init", LED_INIT li x20, 1 << 5 li x21, GPIO_OUTPUT_EN sw x20, 0(x21) li x20, 1 << 5 li x21, GPIO_PORT sw x20, 0(x21) NEXT CODEWORD "+led", PLUSLED li x20, 1 << 5 li x21, GPIO_PORT sw x20, 0(x21) NEXT CODEWORD "-led", MINUSLED li x20, 1 << 5 li x21, GPIO_PORT sw zero, 0(x21) NEXT I'm glad I started with the SparkFun RED-V Thing Plus board. Whilst it's more expensive than some other offerings, having something close to the board AmForth RISC-V was originally written for, definitely helps a lot. RISC-V is not an "open-source processor" [4] and I'm not able to cope with the variety yet, if ever. Despite the product page "backorder" status, there are quite a few of the SparkFun RED-V Thing Plus still available from the usual sources. Well a lot of fun, plenty to study for the winter, and with a blinky up-and-running there is always the hope of progress. Best wishes, Tristan [1] https://www.sparkfun.com/products/15799 [2] https://www.sifive.com/boards/hifive1 [3] https://www.sifive.com/boards/hifive1-rev-b [4] https://riscv.org/blog/2020/02/risc-v-is-not-an-open-source-processor-krste-asanovic-chairman-of-the-board-risc-v/ ___ Amforth-devel mailing list for http://amforth.sf.net/ Amforth-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/amforth-devel
