adafruit / uncanny_eyes

Uncanny_Eyes

'Uncanny eyes' for Adafruit 1.5" OLED (product #1431) or 1.44" TFT LCD (#2088). Works on PJRC Teensy 3.x and on Adafruit M0 and M4 boards (Feather, Metro, etc.). This code uses features specific to these boards and WILL NOT work on normal Arduino or other boards!

How-to guide with parts list and 3D models is here: https://learn.adafruit.com/animated-electronic-eyes-using-teensy-3-1/overview

Teensy 3.x w/OLED screens: use 72 MHz board speed -- 96 MHz requires throttling back SPI bitrate and actually runs slower!

Directory 'uncannyEyes' contains Arduino sketch for PJRC Teensy 3.1 & Adafruit M0 & M4. 'graphics' subfolder has various eye designs, as #include-able header files.

Folder 'convert' contains Python sketch for generating graphics header files. Requires Python Imaging Library. Example images are also in this directory.

uncanny_eyes's Issues

Sketch freezes waiting for last bit out if interrupted

I've modified the uncannyEyes.ino sketch to take eye positional information over I2C communications with the Teensy acting as an I2C slave. I've been running into issues with the sketch freezing. I've narrowed down the issue to this wait loop:

  KINETISK_SPI0.SR |= SPI_SR_TCF;         // Clear transfer flag
  while((KINETISK_SPI0.SR & 0xF000) ||    // Wait for SPI FIFO to drain
       !(KINETISK_SPI0.SR & SPI_SR_TCF)); // Wait for last bit out

https://github.com/adafruit/Teensy3.1_Eyes/blob/master/uncannyEyes/uncannyEyes.ino#L198

When the program is interrupted near this loop then !(KINETISK_SPI0.SR & SPI_SR_TCF)); // Wait for last bit out never resolves to true and the sketch is stuck in an infinite loop.

This can also be reproduced by putting a Serial.print() before the loop (as Serial comms causes interrupts).

  Serial.print("hello"); // This also causes the sketch to freeze
  Serial.println();
  KINETISK_SPI0.SR |= SPI_SR_TCF;         // Clear transfer flag
  while((KINETISK_SPI0.SR & 0xF000) ||    // Wait for SPI FIFO to drain
       !(KINETISK_SPI0.SR & SPI_SR_TCF)); // Wait for last bit out

When I remove the "Wait for last bit out" condition from the loop the sketch no longer freezes when interrupted and appears to run normally.

What is the significance of waiting for the last bit out? Is it really needed? I haven't had much lucking digging up any information. I'd also tried wrapping the SPI transaction in noInterrupts(); <SPI transaction>; interrupts(); but this kills the performance such that the sketch is not usable.

Latest commit does not work on Teensy 3.2

I get no screen activity with the latest commit, as compared to an old pull of the project that works fine. (downloaded as a zip, unfortunately, so I'm not sure the commit value, but before 3bb8251 which added the user.cpp file). I'm not able to cross-verify with other boards, unfortunately, but it occurs for me 100% of the time and with any combination of configuration settings.

Support 90 deg rotation

If possible. Seems to be a desired feature:
https://forums.adafruit.com/viewtopic.php?f=19&t=149836

Understood as being low priority:
adafruit/Adafruit-GFX-Library#208

Hallowing supported?

Sorry if this is a bad place to ask, but I'm trying to compile and upload this to a Hallowing board. I have blink working, this code downloaded, and all the required libraries (I think) installed. I am getting this compile error... any suggestions?

Arduino: 1.8.7 (Windows Store 1.8.15.0) (Windows 10), Board: "Adafruit Hallowing M0"

C:\Users\adams\Documents\Arduino\libraries\Adafruit_Zero_DMA_Library\Adafruit_ZeroDMA.cpp: In member function 'void Adafruit_ZeroDMA::setPriority(dma_priority)':

C:\Users\adams\Documents\Arduino\libraries\Adafruit_Zero_DMA_Library\Adafruit_ZeroDMA.cpp:258:8: error: 'struct Dmac' has no member named 'Channel'

DMAC->Channel[channel].CHPRILVL.bit.PRILVL = pri;

    ^

exit status 1
Error compiling for board Adafruit Hallowing M0.

OLED setup missing SPI start/end transaction commands

Ref this thread:
https://forums.adafruit.com/viewtopic.php?f=8&t=146745

This section of code is missing the SPI transaction start and end commands:

Uncanny_Eyes/uncannyEyes/uncannyEyes.ino

Lines 234 to 239 in c99cf44

	for(e=0; e<NUM_EYES; e++) {
	eye[e].display->writeCommand(SSD1351_CMD_SETREMAP);
	eye[e].display->spiWrite(e ?
	rotateOLED[eyeInfo[e].rotation & 3] :
	mirrorOLED[eyeInfo[e].rotation & 3]);
	}

Compilation error: size of array 'sclera' is too large

Have a brand new Trinket M0. Using Arduino IDE 2.0. Only doing a single eye. Verifying the code is giving me this error. Attached error log. This is without modifying the code. These libs installed:
Adafruit_GFX, Adafruit_BusIO, Adafruit_ZeroDMA, and Adafruit_ST7735.

I had no troubles with an older version of this code (maybe 5-6 yrs ago - using an ItsyBitsy). Am I missing anything?

compile_log.txt

Thanks in advance,
Aubrey

Can't use buttons on HalloWing as BLINK_PIN

I wanted to use the capacitative buttons on the HalloWing M0 to control the blinking, or use it like a joystick, but these require a more complicated API than just digitalRead. I hacked a working version for myself using the Adafruit_FreeTouch library, but I'm not sure the best way to make it more generic.

Are Red and Blue swapped?

I noticed on my build that the default sclera does not appear like the PNG file. The PNG file shows the edges and the veins as reddish while my display shows blueish. Full disclosure - I have made quite a few modifications. I am showing two eyes (each one is 120x120) on one AdaFruit 480x320 TFT display. This display uses a HX8357 rather than any of the display boards the library currently supports. Because of the hardware device differences I thought this blueish characteristic must be my problem, so I set out to find it. I came across the 4 MADCTL settings. I realized each one of the 4 settings were such that the display was set to expect GBR rather than RGB. Once I cleared bit 3 in the mirrorTFT control the colors as shown on my build appeared as I expected.

Thing is, I checked one of the other controllers the library software is designed for (the ST7735) and I discovered that its MADCTL register is the same way that is it is in the HX8357. So it seems displays using the ST7735 would also have the Red and Blue swapped. I do not have such a display so I cannot confirm.

Issue is - am I right about the colors being off of is my head screwed on backwards? If the latter I truly apologize for opening this issue.