Uncanny Eyes is getting expensive

I found this last night but have not used it.
https://github.com/FrankBoesing/Ard...xamples/Mp3FilePlayerLFS/Mp3FilePlayerLFS.ino

Using the flash memory means having about 3 orders of magnitude less memory for sounds i.e. 1000x.

BTW, if you just want something to play fixed sounds right now, there is always the Dfrobot dfplayer (and the various clones):


Obviously, we do need to make the system robust enough to handle using the full power of the audio system and do eyes at the same time. But if you wanted something immediately, there are options.
 
Hi there, thanks for directing me over to this thread. Would anybody here be interested in helping me with some custom coding for uncanny eyes? I need to replace an escape room puzzle urgently. Happy to pay for your time.
 
Hi there, thanks for directing me over to this thread. Would anybody here be interested in helping me with some custom coding for uncanny eyes? I need to replace an escape room puzzle urgently. Happy to pay for your time.

I would suggest creating a new post in the "Project Guidance" section with a short description of your desired functionality (what your current hardware/software, if any, does, & what your desired hardware/software should/will do).

Mark J Culross
KD5RXT
 
Thanks. I’ll write as detailed description as I can of what I currently have and what I’m trying to change it too. Thanks
 
yield() as Chris suggested was a big improvement but sound was still a little stuttery. I added another fastTouch pin in loop() so I can freeze the eyes and assess the changes in sound A:B a a little more easily. I tried putting a counter into renderEye() so that I could call yield several times as it came down the column. That seemed to slow the eyes too much and not solve the stuttering. I switched the SD card to a UHS-3 card I had gotten for use in a gopro. I checked audio processor usage--it's about 5% with no sound playing and 16-17% with a sound playing.

What struck me was that I should see what all is going on in yield()--maybe I could make that more targeted to release cycles for audio and not for other things. I think this is the code of yield:
Code:
#include <Arduino.h>
#include "EventResponder.h"

#ifdef USB_TRIPLE_SERIAL
uint8_t yield_active_check_flags = YIELD_CHECK_USB_SERIAL | YIELD_CHECK_USB_SERIALUSB1 | YIELD_CHECK_USB_SERIALUSB2; // default to check USB.
extern const uint8_t _serialEventUSB2_default;	
extern const uint8_t _serialEventUSB1_default;	

#elif defined(USB_DUAL_SERIAL)
uint8_t yield_active_check_flags = YIELD_CHECK_USB_SERIAL | YIELD_CHECK_USB_SERIALUSB1; // default to check USB.
extern const uint8_t _serialEventUSB1_default;	

#else
uint8_t yield_active_check_flags = YIELD_CHECK_USB_SERIAL; // default to check USB.
#endif

extern const uint8_t _serialEvent_default;	

void yield(void) __attribute__ ((weak));
void yield(void)
{
	static uint8_t running=0;
	if (!yield_active_check_flags) return;	// nothing to do
	if (running) return; // TODO: does this need to be atomic?
	running = 1;


	// USB Serail - Add hack to minimize impact...
	if (yield_active_check_flags & YIELD_CHECK_USB_SERIAL) {
		if (Serial.available()) serialEvent();
		if (_serialEvent_default) yield_active_check_flags &= ~YIELD_CHECK_USB_SERIAL;
	}
	// Current workaround until integrate with EventResponder.

#if defined(USB_DUAL_SERIAL) || defined(USB_TRIPLE_SERIAL)
	if (yield_active_check_flags & YIELD_CHECK_USB_SERIALUSB1) {
		if (SerialUSB1.available()) serialEventUSB1();
		if (_serialEventUSB1_default) yield_active_check_flags &= ~YIELD_CHECK_USB_SERIALUSB1;
	}
#endif
#ifdef USB_TRIPLE_SERIAL
	if (yield_active_check_flags & YIELD_CHECK_USB_SERIALUSB2) {
		if (SerialUSB2.available()) serialEventUSB2();
		if (_serialEventUSB2_default) yield_active_check_flags &= ~YIELD_CHECK_USB_SERIALUSB2;
	}
#endif
	if (yield_active_check_flags & YIELD_CHECK_HARDWARE_SERIAL) {
		HardwareSerial::processSerialEventsList();
	}
	running = 0;
	if (yield_active_check_flags & YIELD_CHECK_EVENT_RESPONDER) EventResponder::runFromYield();
	
};

I'm not sure what part of that relates to audio and I don't see how
Code:
if (yield_active_check_flags & YIELD_CHECK_EVENT_RESPONDER) EventResponder::runFromYield();
can ever execute since I don't see a YIELD_CHECK_EVENT_RESPONDER item included in the flags when they're set up.

What I envision is not changing yield but adding a function called maybe miniYield() that checks just whether audio/SD needs cycles. That might be called, say, 5 times per column rather than once per column. That might allow sound to play and eyes to move realistically.

 
The screens I ordered arrived yesterday and they worked first go using the default set of pins in the uncanny eyes code. Very cool!

View attachment 29484


Good morning, I'm a teacher here in Brazil and I'm enthusiastic about technology. I like arduino and works related to esp8266, esp32. I recently saw on aliesxpress the display with 7 pines and I saw a picture that I think is yours. I need help getting two 7-pin displays from aliexpress to work. I have ESP8266 and I have arduino. I have an esp32 board but I don't know if it works. What do I need to make the two eyes work on these displays???parts, wiring diagram and everything, coded in the arduino IDE???help me....thank you

https://pt.aliexpress.com/item/10050...yAdapt=glo2bra this is the seven pin display i have

alerogeriob@gmail.com email TANKS FOR YOU
 
Good morning, I'm a teacher here in Brazil and I'm enthusiastic about technology. I like arduino and works related to esp8266, esp32. I recently saw on aliesxpress the display with 7 pines and I saw a picture that I think is yours. I need help getting two 7-pin displays from aliexpress to work. I have ESP8266 and I have arduino. I have an esp32 board but I don't know if it works. What do I need to make the two eyes work on these displays???parts, wiring diagram and everything, coded in the arduino IDE???help me....thank you

https://pt.aliexpress.com/item/10050...yAdapt=glo2bra this is the seven pin display i have

alerogeriob@gmail.com email TANKS FOR YOU

This is a hard question to answer.

This particular forum is dedicated to the Teensy processors. While some of us also program other microprocessors, almost all of the links and such will entail fixes and such to run on Teensys. A lot of the work involves processor specific modifications to optimize these utilities for a particular board or processor, and these changes aren't that portable.

In terms of ease of use, for the links in this thread, you want a Teensy 4.1. You can run a Teensy 4.0 if you are willing to solder at least 2 wires to solder pads under the Teensy. These Teensys will support the round 240x240 eyes like in the picture, but also the square 240x240 displays. The older 3.x Teensys can't run the code, as I believe they don't have enough memory to hold both eyes in ram.

Also, note Arduino is not a specific platform, there are several different microprocessors released under the Arduino board, so it matters what is under the covers.

Currently there are at quite a few versions of the source floating around (plus versions before the Teensy version that I haven't used). All of them in some sense run the eyes programs, though the details matter.

  • There is the original Uncanny Eyes sketch that showed around up September 2015 at Adafruit (https://learn.adafruit.com/animated-electronic-eyes). Originally, this was specific to the Teensy 3.1 (and later the 3.2, 3.5, and 3.6). It would only run on Teensy 3.x microprocessors (and not the Teensy 4.x microprocessors). The Uncanny Eyes project used code from a Teensy specific display driver to optimize the code for the displays. The only displays it supported was the 128x128 TFT and 128x128 OLED screens.
  • Some time afterward, the Uncanny Eyes sketch was enhanced to work on other microprocessors, specifically the Arm M0/M4 processors at Adafruit. It will not work on AVR microprocessors like the 328p (in the Uno) and 32u4 (in the Leonardo) . If you are not building on a Teensy 3.x, I believe the code uses the normal display driver instead of doing the graphics itself, and likely would be slower.
  • Adafruit released a board with a single built-in 128x128 display (Hallowing M0. https://www.adafruit.com/product/3900) that runs the adapted Uncanny Eyes. At the moment, Adafruit itself does not have any stock of the Hallowing M0, and digikey only has 8 on hand.
  • Also if you have the Playground Express (https://www.adafruit.com/product/3333) with the TFT gizmo (128x128 display, https://www.adafruit.com/product/4367) it will run this app. Adafruit is currently sold out of the Playground Express but has the TFT gizmo. Digikey has about 330 Playground Expresses and 50 TFT Gizmos on hand. I don't know if the enhanced Playground Express with Bluefruit (https://www.adafruit.com/product/4333) will run with the eye program.
  • In 2017, the author rewrote the code from the Teensy to run on a Rasberry Pi (https://learn.adafruit.com/animated-snake-eyes-bonnet-for-raspberry-pi/software-installation). I don't know anything about this.
  • In 2019, the author rewrote the code another time, this time to run on a new board, the Monster M4SK (https://www.adafruit.com/product/4343). This board has 2 240x240 displays built-in, plus a speaker, etc. The new software requires a higher class processor with more memory, and is targeted towards 240x240 displays. The software is much more configurable than the original code, but it requires support for running Circuit Python (it reads/write config files from flash memory). The software is at: https://learn.adafruit.com/adafruit-monster-m4sk-eyes/building-from-source-code.
  • Adafruit also has a single display version, the Halloween M4 (https://www.adafruit.com/product/4300)
  • Whether this software runs on other systems, I don't know.
  • When the Teensy 4.0 came out, some of the people in this forum worked together to get the original Uncanny Eyes code (not the Monster M4SK code) ported to the Teensy 4.0 and use the new 240x240 displays. This is the original 128x128 display code modified to run on the Teensy 4.0. One eye pattern has been ported to run with the 240x240 display. This code is in the examples of the ST7789_t3 directory in the release. The ST7789 display is a square display. Adafruit sells on variant, and there were a bunch of clones.
  • This port of Uncanny Eyes was also modified to run on the GC9A01A display and it is in the examples of the GC9A01A_t3n driver on github. All of the round displays seem to be GC9A01A displays, so if you have one of those displays, this code would run on it.
  • Recently Chris.nz took up the gauntlet. He/she/they have taken the new source (for the Monster M4SK) and moved them back to the Teensy environment. I haven't looked too much under the covers. I suspect it may be doable to run this code on other platforms, but you likely will need to be adapt at iterating the changes to work in this environment.
 
I have unsuccessfully tried various things since my last post here. I converted audio files to mono (.mp3), since I have just one speaker. That reduced file size by 1/2 and let me simplify the chain for audio--eliminate mixers. Not much improvement. I increased the disk read buffer in Frank B's mp3 routines to some large size--at least 4k, maybe 64K, which did not really help. So I concluded a.) that mp3 processing might be slow and b.) that putting the files into LFS would probably not do much since with the big buffer I should have heard a big improvement if reading data was the issue.

Then I converted the mono files to .WAV which increased the file sizes by about 10x and modified the Audio WAV SD routine to use a 32K buffer for read. When that didn't do much I put it away, hoping something would come to me in the shower or that I would get inspired to delve much more deeply into a half dozen topics that I don't understand well enough.
 
This isn't related to Teensys, but I've been watching this seasons Battlebots on Discovery+ (battlebots are 250 pound fighting robots). One of the stronger teams in the last few years has been the team Witch Doctor. The team all wear spooky type costumes and the co-captain (and founder if memory serves) Andrea always wears a single eye. In the early years, it looked like the 128x128 version (either Teensy or perhaps Hallowing M0). Now, they have moved to the round eye with GC9A01A powered by the RP2040. Evidently they had a custom shop fabricate the PCB and they now sell it in their shop:

 
Looks like "Pit Cap with LCD Animated Eye From Andrea's Top Hat $95.00" uses an RP2040:
Code:
This is the same LCD Eye Circuit Board that Andrea uses on her Top Hat on BattleBots! It features a 1.28" Round 240x240 Pixel LCD, powered by included RP2040 (Raspberry Pi Processor).

Also available:
Code:
Standalone LCD Animated Eye Circuit Board from Andrea's Top Hat
From $60.00
 
Looks like "Pit Cap with LCD Animated Eye From Andrea's Top Hat $95.00" uses an RP2040:

Yes. Witch Doctor sells the round eyes in their shop. As I've watched Witch Doctor over the years, I've wondered which eye they were using, but not to the point of using freeze frame to identify exactly what variant they are using.

I did a google search, and I suspect this site gives the pointers to the code used:


A brief glance makes me think they are using the original Teensy code (i.e. not the Monster Mask code), but perhaps with the one eye pattern that was ported from 128x128 to 240x240. Fortunately with Chris's work, we now have a larger selection of eyes that run on 240x240 displays.
 
I just noticed that Adafruit is coming out with a new round display that has 480x480 pixels. They don't list the chipset used, but it is supposed to be similar to the good old ST7735:


Now, if I had to guess, Adafruit has stalled their adaboxes for the last couple of years. Originally they were supposed to resume shipment in March 2023, but that didn't seem to happen. Several of the Adaboxes came out around Spooky season (i.e. Halloween in October), and I suspect the display will be part of a new version of the eyes, now with more pixels.

Lets see, the spooky adaboxes include:
  • Adabox 20: Eyelights LED glasses (eyeglass frame with neopixels)
  • Adabox 16: Matrix Portral (64x32 RGB display, which includes a creature eye display)
  • Adabox 13: Monster M4SK (2 240x240 displays with a built-in processor, basis for Chris'nz's latest eyes)
  • Adabox 9: Hallowing M0 with a single 128x128 eye, using a modification of the Teensy uncanny eyes code.

So if adabox is actually ship and a round display in one of the new Adafruit items, I suspect it might be yet another version of the eyes code. I'm curious if it is, whether Paint Your Dragon has rewritten the code again (there was the Teensy version, the Raspberry Pi version, and the version in Monster M4SK and Hallowing M4) and/or if there are new eye patterns with the larger display.

I've found a few 480x480 displays on fleabay, including:

 
Last edited:
I've had my eyes on these From AliExpress for a while. The 480x480 display controller is the ST7701S.
Example: https://www.aliexpress.com/item/1005005560190736.html
And the actually Adafruit display: https://www.aliexpress.com/item/2033638379.html

I hadn't seen the 480x480 eyes before, but it looks nice, particularly with touch support.

Lets see, if you need to keep the whole bitmap in memory, that is 112K bytes (480 * 480 * 2). A Teensy 4.x could hold two eyes without using PSram, but it might be tight. Of course, you don't have to have the whole display memory.

And if you are using SPI, it is going to make it even slower to update the screen because you have more bits to update.
 
I hadn't seen the 480x480 eyes before, but it looks nice, particularly with touch support.

Lets see, if you need to keep the whole bitmap in memory, that is 112K bytes (480 * 480 * 2). A Teensy 4.x could hold two eyes without using PSram, but it might be tight. Of course, you don't have to have the whole display memory.

And if you are using SPI, it is going to make it even slower to update the screen because you have more bits to update.


You divided the 2. The Ram footprint is 460,800 bytes per frame. But yes tight, with one eye in each memory type. We're looking at around 25-27fps with a 100mhz SPI clock at full frame updates, which is still decent enough. Or 30fps with a 110Mhz clock.
 
Note, they've added more information:

The TFT driver is ST7701S and uses both SPI and TTL RGB 'dot clock' data. The SPI is only for configuring the display - you cannot draw pixels over SPI! Also, despite having a 40-pin connector, it does not have the same pinout as standard 'rectangular' 800x480 (4.3", 5" or 7") or 480x272 (4.3") displays. It's a new kind of beast for sure.

To make stuff light up you'll need a chip that can perform TTL RGB TFT driving, which means a powerful microcontroller such as the ESP32-S3 with octal PSRAM or a computer like a Raspberry Pi (with either direct-DPI connection or an intermediary chip like the ICN6211). Either way, it's not something you can wire up to your Feather or Arduino!

Though a Teensy 4.1 with 8 megabyte PSram should be able to hold two eyes.

And Adafruit added an even bigger 720x720 4" display:


Lets see, it should take about 1 megabyte per eye (figuring 2 bytes for color). I suspect that you might not want to do two eyes with a single Teensy (i.e. dedicate 1 Teensy per eye, and add communication to sync the eyes).

You divided the 2. The Ram footprint is 460,800 bytes per frame. But yes tight, with one eye in each memory type. We're looking at around 25-27fps with a 100mhz SPI clock at full frame updates, which is still decent enough. Or 30fps with a 110Mhz clock.
I was assuming that each pixel needs 2 bytes to hold the 3 colors (i.e. 450K for a single eye or 900K for 2 eyes for the 480x480 display).
 
And Adafruit added an even bigger 720x720 4" display:


Here is that display: https://www.aliexpress.com/item/1005005580201302.html
These displays support both MIPI and RGB interface. If RGB, the other required lines will be: DE, PCLK, HSYNC and VSYNC. Wee buns for the T4.1.
Teensy should be capable of a MIPI interface using FlexIo, but it may require someone with the appropriate digital lab equipment to get this going.
 
While I do put an dragon uncanny eye display on a 23" monitor (with a raspberry pi driving it) in the window at Halloween, a 4 inch display is enough bigger than a realistic eye that it loses appeal.
 
Hello, I tried to use the larger eyes default_lager from https://github.com/PaulStoffregen/S...async_st7789_240x240/graphics/default_large.h with an esp32c3 board (seeeduino xiao), but whe I use this file all I got was a blank display. It compiled without errors an was uploaded but no display at all. With other eyes it worked fine.
Did I miss something - do I have to change something else to use the bigger eyes?
Thanks for any help in advance, Kai
PS: I have a Teensy LC floating around - would the 4.0 code run on it?
 
While I do put an dragon uncanny eye display on a 23" monitor (with a raspberry pi driving it) in the window at Halloween, a 4 inch display is enough bigger than a realistic eye that it loses appeal.

The exception might be for stage props, where you need it bigger so the audience can see it. It depends on what you are doing, how far back you get, etc. I do think the 2.1" 480x480 display may too large for a human sized monster outside of a stage with a large audience..
 
Last edited:
Hello, I tried to use the larger eyes default_lager from https://github.com/PaulStoffregen/S...async_st7789_240x240/graphics/default_large.h with an esp32c3 board (seeeduino xiao), but whe I use this file all I got was a blank display. It compiled without errors an was uploaded but no display at all. With other eyes it worked fine.
Did I miss something - do I have to change something else to use the bigger eyes?
Thanks for any help in advance, Kai
PS: I have a Teensy LC floating around - would the 4.0 code run on it?

This question perhaps should be asked on the Adafruit forums. In general, for the larger eyes, you want the M4_Eyes program, not the Uncanny Eyes (M4_Eyes is the code for the Monster M4SK and Hallowing M4, Uncanny Eyes is the original Teensy 3.2 port with some support for M0 boards like the Hallowing M0 -- both of which employ internal processor specific stuff to run faster). The port in the ST7735_t3 code is to allow people to use the 240x240 eyes on a Teensy 4.0/4.1, but still using the Uncanny Eyes framework except for the low level display. It may be a simple fix, or it may be a complex fix, but since I don't use that hardware, I can't say.

In terms of the Teensy LC, I suspect the memory is too small to hold even the 128x128 eye. For the large eye (240x240), you really want a Teensy 4.0 or 4.1. I suspect the Teensy 3.2 does not have enough memory for the 240x240 eye (the 128x128 eye takes up most of the flash space). I dunno about the Teensy 3.5 and 3.6.
 
I've finally managed to spend a little more time on https://github.com/chrismiller/TeensyEyes and have added four new eyes today (they might be useful for Halloween!) using iris textures I found here. I also tweaked a few of the existing eyes to fix some things that were bugging me. Enjoy!

Note, if you use Teensy 1.59 beta 3 with Arduino 1.8.19 or Arduino 2.2.1, you get the following warning:

Code:
In file included from /home/meissner/Arduino/meissner/TeensyEyes-st7789-2eye/config.h:72,
                 from /home/meissner/Arduino/meissner/TeensyEyes-st7789-2eye/main.cpp:9:
/home/meissner/Arduino/meissner/TeensyEyes-st7789-2eye/eyes/EyeController.h: In instantiation of 'std::pair<float, float> EyeController<numEyes, Disp>::computeEyelids(Eye<Disp>&) const [with unsigned int numEyes = 2; Disp = ST7789_Display]':
/home/meissner/Arduino/meissner/TeensyEyes-st7789-2eye/eyes/EyeController.h:663:43:   required from 'bool EyeController<numEyes, Disp>::renderFrame() [with unsigned int numEyes = 2; Disp = ST7789_Display]'
/home/meissner/Arduino/meissner/TeensyEyes-st7789-2eye/main.cpp:190:20:   required from here
/home/meissner/Arduino/meissner/TeensyEyes-st7789-2eye/eyes/EyeController.h:252:27: note: parameter passing for argument of type 'std::pair<float, float>' when C++17 is enabled changed to match C++14 in GCC 10.1
  252 |   std::pair<float, float> computeEyelids(Eye<Disp> &eye) const {
      |                           ^~~~~~~~~~~~~~

If you go back to Teensydunio 1.58.1 with either Arduino, you don't get the warning (which uses an older GCC).

I do like the new eyes.
 
Back
Top