Embedded Command Line with Scripting

While not currently a common development approach ZedTech has used a command line / device scripting approach based on the Forth programming language.

In nearly all projects I have done for the last 25 years I have used Forth as an on device scripting language. While it is generally not a good idea to implement large projects in Forth, having a Forth interpreter/compiler as a means of interacting with the target system tends to be beneficial.

The reasons why:

• There is a need to be able to run commands on the device itself. Good reasons range from being able to do read-modify-write cycles quickly (without sending data back and forth to another computer) and being able to synchronize things (e.g. take some action in response to some event or interrupt) which would be too complicated to do remotely.
• If you need a command interpreter it should be something that can be implemented and run with limited resources as limitations on processing power, memory, etc. are common in small embedded systems
• The command interpreter should be simple with as little opportunity to make mistakes as possible. Ad hoc script interpreters with proprietary syntax are just asking for trouble.
• Access to hardware (e.g. reading and writing registers) should be simple and straight forward.
• Manipulating integers which may represent bit patterns for hardware control should be simple. I do not want to second guess what comes out of some arithmetic or logic operation. Thus languages that e.g. always use floating point are not the best choice when dealing with low level hardware.
• While it is desirable that the script should be human readable, they do not need to be especially convenient. While many people dislike postfix notation it has the advantage that any sequence of symbols has only one possible interpretation and there is no possibility to read it wrong due to operate presence rules and the like. Most operations are going to be performed with “canned” scripts and snippets anyway, so reliability is more important than a false sense of familiarity.
• If the compiler part is included a Forth system (or even certain subsets of it) is Turing complete while an ad hoc command interpreter may not be without adding various control structures. It simply gives more flexibility to use a real programming language than some made up application specific one.

In general having a reasonably feature rich command interpreter on the target platform provides a lot of flexibility e.g. when dealing with system bring up, manufacturing and calibration. E.g. Calibration procedures can be adjusted and changed just by changing some scripts without changing the firmware image that was released for production. Also having the ability to script things makes it easier to experiment during the development phase, especially in teams where some of the team members do not have the ability to compile test versions of the firmware.