I’ve written 695 lines of uLisp code for an Adafruit M4 Metro Express with an Adafruit model #802 TFTv2 color LCD 3.3 volt compatible arduino shield. Its amusing to think the C++ code accomplishes less while it must be one hundred times longer. LISP is fun, but its also fast…
It mostly works at a minimal level, so I’ve flipped five gitlab repositories of ulisp code from private to public mode. Take a look, do what you want with it, its all MIT freely licensed.
Demonstrates the other four libraries. Draw funny things on the LCD screen, etc.
Wraps some lower level functions enabling code like this:
(tft2:button-b-p) returns T if button B is pressed, nil otherwise. Makes UI code a little simpler.
Inspired by the adafruit library of the same name, it eats abstract geometrical requests such as
(gfx:rectangle-filled 10 20 40 30 #x00 #xff #x00) and emits pixels on the screen, in this case providing a nice green rectangle on any screen, when paired up with an abstract Graphics API. I plan to flesh this out such that all the functions actually work. I also have a font / text renderer that isn’t working, and a widget library that I’m experimenting with. They all talk the abstract Graphics API provided by the driver.
This is the LCD driver chip. Most C++ libraries ship with a “binary firmware blob” of raw hex to initialize and control it, and if you don’t like the compiled configured Vcom voltage you get to manually disassemble the firmware blob, patch it, and upload a new binary, much as I was doing in 1981 with Z80 assembly code. I vastly prefer a 2019 era experience (or a 1958 LISP experience?) where if I don’t like the visible results of the LCD Vcom voltage being -0.800 volts, I can issue a REPL command of (st7735:command-vmctr1 -0.775) and the Vcom voltage magically changes to -0.775 volts in real time. Its just astounding how fast and easy it is to develop with uLisp compared to C++. It just works! I plan to clean up the API completely eventually. Also I have a ST7735 driver (some subtle differences in power control) and a SSD1306 and some other drivers in process.
I am currently achieving write rates around 340 pixels per second, which would have been stunning for a 1980s home computer but is somewhat slow compared to the theoretical maximum SPI bandwidth. Its good enough but I would not mind it being faster. Note that 340 pixels per second is fast enough for a UI, even a pretty active real time UI, but clearing a large LCD screen takes quite a few seconds.
The “seesaw” is a I2C expander chip by Adafruit used on the TFT shield and in many other places. It costs like five bucks on a breakout board. Onboard the TFTv2 arduino shield, it controls some pins of the LCD controller, the backlight, and the UI buttons and joystick, etc. Again, much like developing for the ST7735R driver chip, C++ code tends to be unpleasant, whereas in the uLisp REPL I can run things like (seesaw:digital-read-p 'PA10) and get a t or nil based on the voltage on pin PA10. uLisp really is life on easy mode! The seesaw is a nifty little chip capable of all kinds of interesting things, imagine the on-chip peripherals of a fancy microcontroller, accessible via I2C. I plan to flesh this library out, eventually, to fully support all features of the seesaw both embedded on the TFTv2 board and the stand alone boards.
Ironically I started all this graphics stuff because I wanted to make a distributed “swarm-like” realtime magnetometer gradiometer, for no reason other than because I think I can, probably, anyway, so naturally I needed a UI so I started there and I haven’t even begun to mess with the magnetometer code yet, LOL. I’ll get there eventually.
Anyways have fun!