I do everything via serial and GnuScreen for automated remote source uploads, error detection etc.
Can you tell me more about this?
Love to
Traditional Forth uses a serial terminal to interactively command (in real time) and upload source to the MCU. The Forth I use on Cortex-M is a traditional but modern Forth which I use traditionally making use of modern applications.
Forth serial Terminal use has a few variations not limited to my description below because
anything is possible with Forth.
1. A terminal such as Minicom, Picocom, even Hyperterm in Windows is used to interactively command in real time and to upload source to the MCU making use of the ASCII serial upload capability of the terminal or a 'helper' program called by the terminal for uploading.
In these cases the source code comments are read but rejected by the on-mcu Forth compiler and End Of Line delays are inserted by the terminal (where supported) to prevent the on-mcu Forth compiler choking on long or complex source. There is usually no handshaking of any kind to use as a alternative to the EOL delays and speeds are often 9600 Baud so that errors and warnings from the on-mcu Forth compiler can be read by the programmer as they occur.
2. A purpose made terminal with on board smarts and file upload capability such as eforthcom is used instead. This special terminal is made especially to suit Forth, and strips the comments from the source, recognizes errors and colors them and/or stops the upload completely at the error , plus waits for the "OK," return from the on-mcu Forth compiler giving the fastest possible upload speed without EOL delays or traditional hardware handshaking.
3. What I use.
I use gnuscreen in my own IDE (which is designed for the fastest possible speed) to do the following:
a. Interactively command the on-mcu Forth in the gnu screen window.
b. upload source to the mcu when I click my editor 'make button'. It does this by opening a remote connection to gnu screen and uploading commands and source via a Makefile. I do all this from the editor window but I see the upload as it occurs in the gnu screen window ... sort off, because at 460800 baud with hardware handshaking its hard to read anything as it flashes up the screen.
c. all comments are stripped from the source by SED before being uploaded in b. above
d. Any errors
from the on-mcu Forth compiler are highlighted in RED in gnu screen using a sub-process involving configurable SED keywords and ANSII escape codes inserted into the RX stream. Warnings are coloured BLUE.
Warnings and errors RING the gnu screen terminal bell as they occur. This is all needed because the uploads are to fast to read.
e. Stop the upload at the error if desired. This can be done with a toggle switch at the development hardware. I don't use this nowadays as color errors and the beep of the terminal bell are all I need. Gnu screen has a long history buffer and I can easily scroll back to look for the colored error after hearing a beep.
f. Suck the entire Dictionary from the MCU in IntelHex and build a complete binary image of everything including user Words from a project. This image can then be flashed to another mcu which is then a 100% clone.
Personally I find traditional Forth such as 1. above far,far,far too slow and I wouldn't blame anyone who tries Forth in this way from thinking it was a load of ancient crap compared to using arm.none.eabi and GDB via SWD on a Cortex-M.
I developed my system until it was faster than arm.none.eabi and GDB via SWD on a Cortex-M using the usual write code, try, fix, repeat development cycle.
Only then was I happy.
My system is far more than just gnu screen above as it involves:
1. a project builder
2. integrated Fossil SCM with webserver
3. integrated configurable CMSIS-SVD memory map and bitfield generator for any STM32 Cortex-M mcu. This means I can easily write Forth code as I have every peripheral memory mapped automatically. I
never have to refer to the documentation for memory locations or register bitfields.Doing this manually is tedious, error prone and incredibly slow. No one should ever have to do this and I'm amazed by Forth people who still do this manually on Cortex-M.