PicoLisp in addition supports an integrated database system. This is a huge advantage for embedded system applications that require a convenient facility to perform data transactions.
Overall logical software structure for running full-fledged PicoLisp on the MCU is shown in Fig. 2. It shows the communication between PicoLisp VM and various other modules in code base.
The code base remains highly portable across various platforms and architectures simply by using the following key principles:
1. Code that is platform-independent is common code and should be written in portable ANSI C as much as possible. PicoLisp itself is a part of the common code section and is written in this way.
2. Code that is not generic (mostly peripheral and CPU-specific code) must still be made as portable as possible by using a common interface that must be implemented by all platforms on which PicoLisp runs. This interface is called platform interface.
3. Platforms vary greatly in capabilities. The platform interface tries to group only common attributes of different platforms.
Platform interface is declared in inc/platform.h header file from source distribution. It is a collection of various components like UART, SPI and timers. Each component has an identifier, which is a number that identifies that component in PicoLisp. Generally, numbers are assigned to components in their natural order. For example, Port A will have identifier value 0, Port B will have 1 and so on.
Similarly, second SPI interface (SPII) of the MCU will probably have an identifier value of 1. Pin 0 in Port 1 on Infineon XMC4500 will be called ‘P1_0 in PicoLisp. Similarly, pin 27 in Port B on Atmel AT32UC3A0256 will be called ‘PB_27 (notice the single opening quote).
PicoLisp cannot be directly compiled for a 32-bit RISC machine. There are many issues to address before one can use PicoLisp REPL over UART or TCP/IP interface on the MCU. For instance, supporting programs such as memory allocators are required for PicoLisp to function correctly. We use Newlib C library and implement stubs of code for the memory allocator. We have to deal with issues like routing plain I/O over UART or TCP/IP interface of the MCU.
We also require support for a multimedia card memory interface to store PicoLisp programs. We can then load PicoLisp programs at runtime. This implies a requisite for a file system. We also need to implement stubs of code for file I/O support over SPI protocol. For the file system, we use FatFs FAT file system module.
Once all supporting programs are in place, getting PicoLisp to run on the MCU is then fairly straightforward. On account of its small size, it can be easily embedded on an MCU in less than 256kB of flash. It can also be easily compiled for a given architecture with a toolchain like GNU gcc. Currently, a Python based build system called SCons is being used to compile the code base.