Code Errors, Detecting

Forth is quite unique in that unlike other systems your source code is compiled, or interactively debugged on the target MCU.

With non Forth systems such as Arduino or Atollic TrueStudio, your source is compiled on a PC, code errors are announced by the compiler (GCC) you fix them, then Flash them to the MCU for testing. You may also have GDB for interactive debugging.

Note

Basic and some other operating systems such as Micropython also run on the MCU, but as far as I know, the source is interpreted and not compiled like Forth.

Whilst Forth sends error messages to you as they occur, a general purpose serial terminal won’t do anything about them and will keep uploading the source code long after the error has disappeared up the screen, and left you wondering why your shiny new code isn’t working …

Traditionally the upload speed was quite slow and the programmer watched for any errors.

To deal with this situation, some special purpose Forth Terminals have been created, which halt source code uploads when a error occurs. In my opinion the best of these is the e4thcom terminal by Manfred Mahlow, (other terminals of this kind are listed on the same page).

These special serial terminals for Forth also wait for the Forth end of line “OK” before sending the next line of code lest the MCU compiler choke up trying to compile code faster than it can. They also remove any comments so the MCU doesn’t have to waste time ignoring them and they offer #include statements to allow a ordered upload of source code files.

Sourcecode Errors

Detection and Action

I have been experimenting with a custom Mecrisp-Stellaris Kernel, running on a STM32F0 Discovery Board. When a Source Code Error (SCE) is detected by the Forth Compiler, it raises GPIOC-7, which in turn is connected to the STM32F0 Discovery Board’s CTS hardware handshaking pin.

This causes the STM32F0 Discovery Board serial communication to freeze, displaying the error at the user terminal so the programmer can say DOH!.

This system allows the use of general purpose serial terminals such as Picocom, Minicom, Gnu-Screen etc all running at higher speeds such as 460800 Baud.

In the picture below, a SCE has been detected. The SCE in this case is a “;” entered in the terminal manually and causing the error “ ; is compile only”. This in turn raises GPIOC-7, which is connected to the STM32F0 Discovery Board CTS pin, freezing the upload at this exact point.

Kernel Mod Features

This Kernel :-

1. Raises a GPIO pin on a source code error and turns on the STM32F0 Discovery Board BLUE LED.

2. Requires a board reset to clear the LED, but this is my usual development method because code is compiled into RAM and only moved to Flash when it is considered tested and stable. Ram is fast to reset, reboot and won’t wear out.

3. Uses RTS hardware handshaking to halt the communications when a SCE occurs so it can be seen and fixed.

4. Communicates at 460800 Baud (8,N,1) to a USB 6 pin serial dongle with RTS and CTS on your pc. Because the comms faithfully halts on a SCE, you don’t need to see your code uploading, so it may as well be as fast as possible.

5. Uses CTS hardware handshaking to the USB serial dongle to halt uploaded data while the MCU is compiling. This removes any requirement to add upload delaying end of line delays that are normally required with standard serial terminals such as Picocom.

6. Adds a carriage return after the Mecrisp-Stellaris line feed, so you don’t have to do that in your terminal as is normally required with Picocom .

7. Sets GPIOC 7,8 and 9 as OUTPUTS, so if you want to blink the LEDS connected to GPIOC 8 and 9, you don’t have to do this in your sourcecode.

8. The Kernel will run on any STM32F0 with at least 20K Flash, and uses USART1.

Note

Try it at a system clock speed of 48 MHz, I’m sure you will be impressed.

Running Picocom

Hardware handshaking is required and this example worked fine when I tested it.

picocom -f h -b 460800 /dev/<your usb-3.3v serial device>  --omap delbs,crlf --send-cmd "ascii-xfr -sv"

F0 Disco Hardware Handshaking Connections

F0 Disco Signal	F0 Disco Port	USB Dongle
TX	PA10	RX
RX	PA9	TX
RTS	PA12	CTS

Note

See the schematic below for how a normally closed (NC) pushbutton switch is connected, so that communications is HALTED on a SCE, yet resumes when the button is pressed.

Schematic Diagram

This shows pin functions, and should be straightforward, please let me know if it’s not.

My STM32F0 Discovery Board ‘part’ shows on-board parts, such as the User Push Button circuitry inside it.

Kernel

Grab it here, it’s only 20KB. Flash using your usual method.

Note

This kernel is a slightly modified mecrisp-stellaris-2.4.2-RA

DOWNLOAD: discof0-rtscts-480600-nlcr-green-blue-pc7cerror.bin