Any interest in graphics commands on ESP uLisp?


I’m starting work on bring the ESP32/ESP8266 version of uLisp up to date with the latest features in the 3.2 Beta.

Does anyone have an interest in graphics commands on the ESP version of uLisp? They could support boards such as this Wemos ESP32 OLED board, with a 128x64 monochrome display:

The commands would be these: Graphics extensions.


Interest? Sure! — A board to test that? No, sorry. 😊 If you are unsure, perhaps better leave it to some future 3.3. While graphics in uLisp are a great idea, they will not be entirely its main use case, I imagine. (The main use-case I truly see for uLisp “in practice” is the ability to dynamically reprogram microcontrollers with nothing but a serial connection to them. But also mega geeky stuff like your lisp badge, so in the end, graphics ARE nice, too.) And, if you do not mind, I might post here the foolery I would subject your graphic functions to, because testing, in the end, is truly more or less “playing human fuzzer”.


I am definitely interested in graphical commands. For example for the M5Stack, or M5Stick, or a DSTIKE Deauther Board. That is what I have on hand.


Thanks! As far as I can tell they have the following screens:

  • M5 Stack: 0.96 inch, 80 x 160 Colour TFT LCD, ST7735S

  • M5 Stick: 1.3 inch, 64 x 128, SH1107

  • DSTIKE: 128 x 64 Monochrome OLED

I assume the M5 Stick is monochrome? Do you know whether the DSTIKE uses the SH1106 or SSD1306?


Hi, here some information:

That would be really funny to have uList on the DSTIKE watch…


OK, a few testing ideas for you, as I have no such boards at hand…

{Typo: in the example to “draw-round-rect” you have omitted the “-rect”-part:

“draw-round-rect function
Syntax: (draw-rect x y w h radius [colour])”}

Now, these here are just a few “considerations” of mine and might not be correct. Following them are my commands, grouped together for easier copy-pasting. If my “negativity-assumptions” are wrong, then just consider the examples the same, but with positive numbers only.

Negative co-ordinates should not generate errors, but let the letter disappear - which would be useful e.g. in connecting displays and letting things scroll “across” multiple displays.

A “line” should also be able to be a “dot”, and it should also be possible to have it “off-image” (invisible, but not error).

A “negative” rectangle might be drawn “the other” direction. A height or width of 0 should make it just a line.

A circle with a “negative” radius should really just be a circle.

A filled-round-rect with a NEGATIVE radius would be interesting - would then the roundings point inward?

(draw-char -2 -2 #\O)
(draw-char 0 0 #))
(draw-line -1 -1 -1 -1)
(draw-line 3 3 3 3)
(draw-pixel -1 3)
(draw-rect 10 10 -8 0)
(draw-rect 30 30 -15 20 -5)
(draw-rect 30 30 5 5 10)
(draw-rect 30 30 0 0 -10)
(fill-circle 20 20 -15)
(fill-triangle 17 17 17 17 17 17)
(draw-triangle -4 -4 1000000 1000000 1000000 1000000)
(set-cursor -5 -5)
(set-cursor 5 5)

What I would also suggest you to try to do is to see how the various mirroring and rotation elements would interplay, like, set mirroring, then rotate the display, then see where the writing ends up.


Thanks for the comments. In fact I was just thinking that I need to write a test program that uses every drawing command when I read your post!

Your suggestions are good, but I’m really just implementing calls to Adafruit’s GFX library, so I’m constrained by what that does. In general its policy is to ignore plotting outside the display area.

Although I was tempted to change some features, I think there’s a benefit in keeping consistent with the GFX library, because users who have experience of drawing graphics with that library will already know how to use the uLisp graphics extensions.

I may implement some extensions to the library in a future release, but for the moment I plan to keep to the commands I’ve already documented for RISC-V.


I think it would be interesting, yes. I have an ESP32-based mobile phone kit that I haven’t assembled yet, but which it might be interesting to have that capability on.


I’ve got the graphics library working with the Wemos ESP32 OLED board shown at the beginning of this thread, but I can’t easily get it working with SH1106-based displays, because the Adafruit GFX library doesn’t directly support them. Perhaps someone will be able to solve this for a future release.


The ESP version of uLisp should work on the watch - have you tried it?


The ESP Version 3.2 of uLisp supports the graphics extensions on SSD1306 OLED displays, such as on the Wemos ESP32 OLED board. For example, this program draws the sine wave at the start of this thread:

(defun test ()
  (dotimes (x 128)
    (draw-pixel x (round (- 31 (* 31 (sin (* x (/ (* 2 3.14) 128)))))))))