> What’s New ? <
Hosted Or Tether Part 2¶
See also
Now that my RPI Muforth Host is finished and I’ve had time to run some tethered Forth testing, I now have enough new data to do a Part Two in this series.
Part Two
Small embedded programming languages/systems are available under FLOSS licences for anyone to use; to the best of my knowledge they are :
Compilers¶
C compilers such as Gcc for Cortex-M, MSP430, AVR etc, SDCC for the 8051 and many others for other MCU types. These are not interactive but may utilise a monitor on the target if it doesn’t have JTAG, or the GDB debugger if it does.
Forth compilers like Myforth which are essentially a cross compiler Forth program running on Gforth. They produce a target binary which is then flashed to the target via a ‘bootloader’ previously installed. The bootloader may have some monitor facilities but the Forth itself is no more interactive than C, i.e. not at all.
Specialist language compilers such as JAL for small embedded.
Repl (Interactive)¶
This category involves a hosted operating system on the actual target. This is a old and established category which includes Forth, Basic, Micro Python, Circuit Python, Lisp, Lua etc.
The OS talks to a interface terminal where programming and interactive tests/faultfinding may be done.
Tether¶
These are a specialist sub category of Forth REPL (interactive) OS’s and themselves form sub groups. For some reason tethers seem confined to Forth alone.
Note
These sub groups names are my own and others may use different terms but hardly anyone writes about them.
Talkers¶
These contain a mini Forth kernel, just enough to provide basic functionality to talk to the mainhost Forth which is usually on a PC, but can be a RPI etc. Examples are Muforth (various mcu’s) and Riscy-Pygness (STM32F103).
Talkers ‘chat’ between the mainhost and the target mcu to send and receive data, flash etc.
Advantages¶
The target can be disconnected and will boot into the developed program, so it’s turnkey ready when the tether is cut. Later the target may be reconnected to the tether and the REPL will work the same as before.
Issues¶
My tests have found that the communication stream between target and mainhost may be corrupted at times with the result being a “silent failure” ! This means that the programmer may end up wasting time debugging working source because of a failure of the development system. This has occurred with both Muforth and Riscy Pygness.
If the target is GPL and sold/distributed, the GPL requires that the source be made available, which impacts commercial use, with many companies forbidding it in their products (the honest companies anyway).
Muforth has a Open but non restrictive license, so it’s commercially friendly.
Zombie¶
Mecrisp-Across is a zombie tether in that the target MCU is DEAD as it’s held in reset during the entire development cycle. The target mcu is completely controlled by the host via JTAG and has to do what it’s told. Should JTAG comms be lost, the user knows straight away as Mecrisp-Across will raise an alarm.
This type behaves exactly like the REPL while in development mode, and exactly like the Compiler in turnkey mode.
The best of both worlds !
There is no silent failure with Mecrisp-Across that I have seen. In my opinion, this is a genius design by Matthias Koch!
Advantages¶
Once the target has been turnkeyed, it only runs the compiled program. There is no Forth present on the target, just a machine code image. This is almost mandatory for MSP430 mcus which traditionally have very little flash memory.
The host is a multi pass compiler, so very small and efficient code is generated.
This also means that the target may be licensed anyway the developer wants, there is no GPL compliance required.
Issues¶
Different development and turnkey speed. A software delay during development will be four times slower than on the target when the project is finished and running turnkey.
MSP430 target only.
