The Quest to Liberate FlashForth
FlashForth is a FORTH for microcontrollers, coded in assembly. It supports AVR and PIC MCs, though I use it exclusively for AVR.
FlashForth
I'm fond of it for several reasons:
- Provides a (mostly) traditional FORTH, with most of the expected words and behavior.
- Provides a functionally complete FORTH with the ability to do both the interpreting and compiling on the MC.
- Provides stable operation across repeated power cycles.
- Provides project assembly code under the GPLv3 license.
- Provides read/write access to flash, eeprom, and ram memory areas, including I/O ports.
The big problem I have with FlashForth is it is coded for the XC8 compiler, part of the MPLAB suite. Although these programs are available as freeware, they are proprietary and not free software ("free as in freedom"). To the best of my knowledge, no source code is available for them, except for the parts of AVR-GCC which they have reused or modified. I tried to download the XC8 compiler, to see what came with the download, but in fact I could not even download the program without first running and downloading a black-box installer application, and I was not okay with that.
I've been using the official builds of FlashForth, but my principles will never be satisfied until I either switch to a different FORTH for AVR, or I figure out a way to compile FlashForth with only free software tools. As to the first option, I have not yet found another satisfactory FORTH for AVR. I have been looking into avrforth:
avrforth
This FORTH is worthy of more attention, but there are a few issues I have had so far with it:
- It is not a traditional forth, but something similar to colorforth.
- I built it successfully for 328P MC, but the interpreter is broken when I try to run it on the chip. Possibly an issue with fuse settings. The author has been helpful, but I have not got this figured out yet.
- avrforth is released as "public domain" software. I prefer if possible to use software with a strong copyleft.
As far as compiling FlashForth with only free software tools, in principle this should be doable. The FlashForth source code is available as assembly code, with a syntax mostly compatible with AVR-GAS, and XC8 is using avr-gcc for a lot of the backend processing. So I should be able to get it to compile with AVR-GCC.
I met several hurdles quickly:
- There is no helpful FlashForth documentation to assist in figuring this out.
- Some of the FlashForth include files have to be modified to use AVR-GCC include files.
- The XC8 compiler has some kind of extension built-in, used by FlashForth, which compiles code to the NRWW section of the MC flash memory. AVR-GCC doesn't have this, which is probably a good thing. On the surface, it seems like a violation of the compiler<->linker boundary.
The author has provided me with log files from his own compiling on XC8, which has been helpful. I believe I figured out how to work around the NRWW issue using a custom AVR-GCC linker script.
I was able to get the code to compile, and uploaded it to a 328P. The MC boots up as expected, and I can view the word list. However, most other activities, like defining words or using the stack, cause the MC to reset. So it is unusable, and my efforts have failed so far.
I was able to get an XC8 build from the FF author, and I compared the object dumps, and they are almost exactly identical in regards to instructions and memory addresses. The very few minor differences seem insignificant, but I am still looking them over. Hopefully I can get this figured out.
It would be helpful if I had access to a good 328P simulator. Of course, I do not want to use a proprietary simulator from Microchip. There are a few AVR simulator packages in Guix, but I have not even been successful yet in getting any of them to run correctly a known good build of FlashForth. I am looking into
Gerd's AVR simulator
but I only just downloaded the source code today. I thought I read somewhere that there is a simulator included with AVR-GCC, but I had yet not come across any more information on that.
Alaskalinuxuser, 2021-07-06
Have you tried simavr, I've heard of it recently while dabbling with other chip related things. A plus for me is that it is in the Ubuntu repositories.
https://github.com/buserror/simavr
LibreHacker, 2021-07-07
I do not recall having used it before, though I see on my file system that I once did check out the repository. I will take a closer look at that.