A Tour through the intial Software

A project log for DevTerm EXT Cartridge System

An EXT module for plug&play cartridge extensions powered by a Teensy4.0.

flipflip 09/09/2022 at 20:570 Comments

Lua Interpreter

As stated previously, the firmware features a Lua 5.4 interpreter.
The configuration has been hammered down more or less to be able to run under Zephyr and the Teensy4.0.
Here's the key things to make it happen:

There are some things that I forgot to document, but if you happen to want to embed Lua into the Teensy4.0 in PIO's Zephyr than just drop me a message and I'll send over the code.
But Lua is only as exciting as the functions it comes with, here's a list of them:

Bytecode currently is compiled using an emulator on a developer machine, which can later be incorporated into a cartridges I2C EEPROM to be loaded on plugging in.

SPI Protocol

Meanwhile, the SPI communication between the DevTerm and the DTC Module is coming along well. Slave configuration was really easy by using the MCUXpresso library. As with all peripherals that are used during runtime in Zephyr on the Teensy4.0, the pinmux has to be adjusted before usage. On the topic of pinmux, I found out that on my version, the configuration for LPSPI3 seems incorrect. It is easily fixable tough.

The SPI protocol utilized is simple, featuring a start byte and end CRC8 for both validation of the frame and detection of the frame end. There are two types of frames utilized: Basic and Data.

Basic Frames are fixed width and is the go-to for exchanging. Basic frames contain a command and argument from the master, and a status code and return value from the slave. Then, there's Data Frames which are utilized currently by one command: the buffer exchange. By issuing a buffer exchange command, a local all-purpose buffer can be read and written to. This all purpose data buffer is where the the data for peripheral commands such as for SPI and I2C is. A basic frame beforehand will contain the neccesary length information for a following data frame.

Types of frames
The types of frames used. The magic byte at the start consists of the frame type (FT, basic or data) and a transaction number (TN) which increments with basic commands.

An example exchage is illustrated in the following diagram, outlining the neccesary transactions for one I2C read of up to 128 bytes.

Big thanks to @yatli for all the valuable input on the ClockworkPi forums regarding the protocol among other things.

Linux Driver

Currently, a cheap python script is used to test the protocol during development, but a fully fledged Linux driver is in the works that exposes the IO as GPIO, as well as the I2C buses. I currently have no idea to implement an SPI or CAN driver on Linux, but it is definitely on the todo-list.
A wiring-pi like Python library would be nice to have on top, but I'm unsure if it will be necessary at all.