Riscy Pygness is a 32-bit multitasking Pygmy Forth for the ARM. It includes full source code for both the host (your desktop PC) and target (your ARM development board). The license is MIT-like so you can do (nearly) anything you like with it.
It is aimed at relatively small embedded systems rather than desktop systems or large embedded systems running an operating system (OS). Riscy Pygness is a stand-alone system that is its own multitasking OS. It can run in less than 7 K bytes of flash. The size can be reduced further depending on your needs. This makes it suitable for use in even the smaller ARM variants such as the NXP lpc2101, lpc2102, and lpc2103. It can address the full 4 GB address space, so it can take advantage of all the flash and RAM available in even the larger variants.
During development, the host communicates with the target via a serial port. The host provides the smart terminal and the compiling services. The host can generate a new, customized Forth image for the target.
The Forth itself runs on the target but you interact with it by typing commands on the host, much as you would with a Forth running locally on the host.
As you type each word (command) at the terminal, the word is looked up on the host which then sends a request to the target to execute the word. Numbers typed at the terminal are sent to the target to be put on the target's data stack. Word headers are kept on the host, not the target, and all compilation work is done on the host.
The host and the target, by working together this way, provide the effect of a fully interactive Forth running on the target while conserving the possibly limited resources of the target.
Riscy Pygness is built upon Pygmy Forth for the PC (a 16-bit DOS Forth), which itself was built upon Charles Moore's cmFORTH.
However, Riscy Pygness is quite different from Pygmy Forth for the PC, not just because it is a 32-bit Forth for an entirely different processor, but also because it borrows a few ideas from Charles Moore's ColorForth.
Riscy Pygness should be easy to port to any ARM processor. So far, I have run it on the NXP lpc family of ARM processors. It currently runs on the lpc2106, lpc2103, and the lpc2378. The modifications necessary for other lpc processors should be minimal.
Riscy Pygness currently works on the following ARM CPU and board variants (so I believe).
It should therefore work on lpc2368 and other lpc23xx variants, and all or most other NXP lpc chips.
The following includes some specific support information for several variants.
Here are some thumbnails (just click on them to see the full size images) of the Olimex LPC-P2106 board and my MMC/SD interface to it.
The Philips NXP LPC2106 ARM chip.
Riscy Pygness works well on this chip. The main Riscy Pygness download also includes led1-2103.asm as a small test program to flash the Olimex board's LED, as a way of verifying the board and your connections to it.
Small, simple example assembly language programs for the LPC2378. These illustrate flashing an LED, changing the clock source, setting up and using a timer in polling mode, and using the serial port.
Also, the main Riscy Pygness download includes led1-2378.asm as a small test program to flash the Olimex board's LED.
Pin-out diagrams for the connectors on the Olimex LPC P2378 development board.
I have attempted to isolate the CPU-specific and/or development board-specific part of the code in separate files. See custom-lpc2106.asm, custom-lpc2103.asm, and custom-lpc23xx.asm in the distribution. The main assembly language file, riscy.asm, contains one conditional directive which includes the appropriate CPU-specific file based on a symbol defined near the top of riscy.asm. Be sure to edit that symbol to match the particular processor you are working with.
The file equates-lpc2xxx.asm holds register definitions that apply to all of the NXP lpc2000 family members. In addition, there are board-specific equates files: olimex-lpc2106-equates.asm, olimex-lpc2106-equates.asm, and olimex-lpc2378-equates.asm. When switching processors, edit riscy.asm to define the correct symbol and edit the list of equate files in arm.lisp so the proper symbols will be available in the smart terminal.
To port to a different processor, copy whichever of the above files are most similar to your processor, and modify them. The goal, of course, is to keep the parts that do not change isolated from that parts that do change, without cluttering the main source code with tons of conditional directives.
Porting to other manufacturers' ARM chips should be straightforward. I think the main task will be adjusting for differences in how I/O and perhaps peripherals are handled, setting the clock speed, noting which pin (if any) connects to an LED, etc.
Riscy Pygness is a member of the Pygmy Forth family but is quite different from the 16-bit DOS Pygmy Forth. It takes a number of ideas from Charles Moore's ColorForth, yet uses conventional Forth-style notation, rather than using color.
There are many possible ways of threading the words within a higher-level word. The method in this version is token-threaded code with 16-bit tokens. This is a compromise between speed and conciseness that favors conciseness. By using 16-bit tokens, a lot of code can be packed into the available flash (and RAM). See implementations for a further discussion of the possibilities. We could modify the threading to favor speed or even to favor greater conciseness. Generally, though, I lean toward the usual Forth philosophy of ignoring performance until the application is working and then convert just the bottlenecks to CODE words (i.e. Forth words written in assembly language).
The Forth image that is burned into flash consists of the primitives (which are written in assembly language and assembled by the GNU ARM assembler) and the high-level Forth (which is compiled by a Lisp program). The Lisp program takes the binary image and a list of symbols and addresses produced by the assembler and merges them into an in-memory image on the host, along with the higher-level Forth, then writes that image to a file named combo.bin. It is combo.bin that is burned into flash on the target.
Typical development style is interactive, running combo.bin and exercising the words in its dictionary and extending the dictionary on the fly to test and experiment. From time to time, the high-level Forth that will go into flash is extended, based on these interactive sessions, and a new flash image is created. This cycle is repeated until the application is finished and all of it is in flash.
In other words, you start with a base image in flash and do most of your work interactively (with extensions going into RAM). Periodically, you generate a new base image to be burned into flash that includes your new work.
For the assembler and gdb, see Installing the GNU Toolchain.
The binutils package provides the assembler and related programs. The assembler is necessary to assemble the Forth primitives.
Sometimes the GNU debugger (gdb) can be useful for debugging the primitives, which are written in assembly language. Insight is a GUI front end to gdb. I usually use gdb directly from Emacs.
CLISP is a particular implementation of Common Lisp. It is available for just about every platform (including Linux and Microsoft Windows) at http://sourceforge.net/project/showfiles.php?group_id=1355. It is easy to install. If you are running Debian Linux or one of its variants such as Ubuntu, you should be able to install CLISP either through your package manager program (such as synaptic) or directly from the command line, as root, with
# apt-get install clisp
It should be nearly as easy with any of the other Linux distributions. For Windows, see the CLISP web site for the installation file.
The smart terminal on the host is provided by a Common Lisp program.
This program also does the compiling of the high-level Forth, whether
all at once to produce an image for the target's flash or
incrementally during interactive development of your application.
CLISP is also necessary for preasm.lisp which does some preprocessing
on the assembly source code.
Any Common Lisp would probably work, but you might need to make minor adjustments to the code. Since Riscy Pygness is working well with CLISP, that is the best version to start with.
There are several ways to burn the Forth image into the target's flash.
The NXP lpc ARM (and other manufacturers') chips contain a serial bootloader. An alternative is to use a JTAG cable.
A serial bootloader is a program residing in the target chip's flash that allows a flash utility on the host (the desktop PC) to burn a program into the target's flash memory.
The host-side program is often called a flash utility or a downloader.
See the bootloader page for more details.
Make is a program for executing commands based on declared dependencies. It allows you to say, e.g.
make riscy.bin
and have the appropriate commands executed automatically to
However, make checks the timestamps on the files and only does the above steps that need doing.
See the makefile in the distribution for the details. You will need to check the settings and adjust them for your environment. For example, you will need to set the correct path to your arm-elf-as file.
You can run the smart terminal directly from a terminal shell (a command line prompt) but it is often more convenient to run it from within Emacs. Emacs provides command history and command completion. Emacs even provides a text editor. See emacs for some details about how to learn and use it.
To do it without Emacs,
clisp(load "arm")(interp) in the inferior lisp bufferIf you are familiar with a version of Riscy Pygness prior to July, 29 2007, please note some important changes. The current version
For more details, see the history.
See Downloads.
Feel free to email me at frank@pygmy.utoh.org.
Main Riscy Pygness page: http://pygmy.utoh.org/riscy