ST7789_t3 (part of ST7735 library) support for displays without CS pin

[KurtE]

@mjs513 - Thanks
Making them Non-static would imply that they are now on the stack and as such get initialized back to their original values each time...

Making all of those data members to be PROGMEM, helps. I was able to reload several time, without USB getting trashed...

Also with DMA updates, there appears to be some timing issue I have not figured out yet... But so far it works if you configure for Terminator eyes... Getting a little over 100 frames per second.

As for where the polar array is used? Not sure did not look yet, just noticed it in the default eye file..

const uint16_t polar[80][80] PROGMEM = {
  0X007F, 0X007F, 0X007F, 0X007F, 0X007F, 0X007F, 0X007F, 0X007F,
  0X007F, 0X007F, 0X007F, 0X007F, 0X007F, 0X007F, 0X007F, 0X007F,
...

[mjs513]

@KurtE

Just converted defaultEye to use PROGMEM and that seemed to clear up the issue with trashing the USB. But here is another data point for you. DragonEye works fine with using PROGMEM but Terminator does not - had to do a 15s restart with that one. So guess the key is to change all those files to PROGMEM.

My setup right now is the default setup - both displays on the same SPI bus.

[mjs513]

@KurtE - @defragster

Here are all the graphic files updated with PROGMEM:

[KurtE]

@mjs513 - Yep I had done that as well. I also updated one structure in the main .ino file as well.

I am also curious about the actual sizes that was crashing... So for example if I build one of the earlier versions of yours that I downloaded awhile ago...
It builds and gives me the following as information at the end of build:

Linking everything together...
"D:\\arduino-1.8.9\\hardware\\teensy/../tools/arm/bin/arm-none-eabi-gcc" -O2 -Wl,--gc-sections,--relax "-TD:\\arduino-1.8.9\\hardware\\teensy\\avr\\cores\\teensy4/imxrt1062.ld" -mthumb -mcpu=cortex-m7 -mfloat-abi=hard -mfpu=fpv5-d16 -o "C:\\Users\\kurte\\AppData\\Local\\Temp\\arduino_build_939326/uncannyEyes0.ino.elf" "C:\\Users\\kurte\\AppData\\Local\\Temp\\arduino_build_939326\\sketch\\uncannyEyes0.ino.cpp.o" "C:\\Users\\kurte\\AppData\\Local\\Temp\\arduino_build_939326\\libraries\\debug_tt\\debugPrint_tt.cpp.o" "C:\\Users\\kurte\\AppData\\Local\\Temp\\arduino_build_939326\\libraries\\debug_tt\\debug_tt.cpp.o" "C:\\Users\\kurte\\AppData\\Local\\Temp\\arduino_build_939326\\libraries\\SPI\\SPI.cpp.o" "C:\\Users\\kurte\\AppData\\Local\\Temp\\arduino_build_939326\\libraries\\Adafruit_GFX\\Adafruit_GFX.cpp.o" "C:\\Users\\kurte\\AppData\\Local\\Temp\\arduino_build_939326\\libraries\\Adafruit_GFX\\Adafruit_SPITFT.cpp.o" "C:\\Users\\kurte\\AppData\\Local\\Temp\\arduino_build_939326\\libraries\\Adafruit_GFX\\glcdfont.c.o" "C:\\Users\\kurte\\AppData\\Local\\Temp\\arduino_build_939326\\libraries\\ST7735_t3\\ST7735_t3.cpp.o" "C:\\Users\\kurte\\AppData\\Local\\Temp\\arduino_build_939326\\libraries\\ST7735_t3\\ST7789_t3.cpp.o" "C:\\Users\\kurte\\AppData\\Local\\Temp\\arduino_build_939326/..\\arduino_cache_675216\\core\\core_7ab3d924210d22e02afbf9266aa5c54d.a" "-LC:\\Users\\kurte\\AppData\\Local\\Temp\\arduino_build_939326" -larm_cortexM7lfsp_math -lm -lstdc++
"D:\\arduino-1.8.9\\hardware\\teensy/../tools/arm/bin/arm-none-eabi-objcopy" -O ihex -j .eeprom --set-section-flags=.eeprom=alloc,load --no-change-warnings --change-section-lma .eeprom=0 "C:\\Users\\kurte\\AppData\\Local\\Temp\\arduino_build_939326/uncannyEyes0.ino.elf" "C:\\Users\\kurte\\AppData\\Local\\Temp\\arduino_build_939326/uncannyEyes0.ino.eep"
"D:\\arduino-1.8.9\\hardware\\teensy/../tools/arm/bin/arm-none-eabi-objcopy" -O ihex -R .eeprom "C:\\Users\\kurte\\AppData\\Local\\Temp\\arduino_build_939326/uncannyEyes0.ino.elf" "C:\\Users\\kurte\\AppData\\Local\\Temp\\arduino_build_939326/uncannyEyes0.ino.hex"
"D:\\arduino-1.8.9\\hardware\\teensy/../tools/stdout_redirect" "C:\\Users\\kurte\\AppData\\Local\\Temp\\arduino_build_939326/uncannyEyes0.ino.lst" "D:\\arduino-1.8.9\\hardware\\teensy/../tools/arm/bin/arm-none-eabi-objdump" -d -S -C "C:\\Users\\kurte\\AppData\\Local\\Temp\\arduino_build_939326/uncannyEyes0.ino.elf"
"D:\\arduino-1.8.9\\hardware\\teensy/../tools/stdout_redirect" "C:\\Users\\kurte\\AppData\\Local\\Temp\\arduino_build_939326/uncannyEyes0.ino.sym" "D:\\arduino-1.8.9\\hardware\\teensy/../tools/arm/bin/arm-none-eabi-objdump" -t -C "C:\\Users\\kurte\\AppData\\Local\\Temp\\arduino_build_939326/uncannyEyes0.ino.elf"
"D:\\arduino-1.8.9\\hardware\\teensy/../tools/teensy_post_compile" -file=uncannyEyes0.ino "-path=C:\\Users\\kurte\\AppData\\Local\\Temp\\arduino_build_939326" "-tools=D:\\arduino-1.8.9\\hardware\\teensy/../tools/" -board=TEENSY40
Multiple libraries were found for "ST7735_t3.h"
 Used: C:\Users\kurte\Documents\Arduino\libraries\ST7735_t3
 Not used: D:\arduino-1.8.9\hardware\teensy\avr\libraries\ST7735_t3
Multiple libraries were found for "Adafruit_GFX.h"
 Used: D:\arduino-1.8.9\hardware\teensy\avr\libraries\Adafruit_GFX
 Not used: C:\Users\kurte\Documents\Arduino\libraries\Adafruit_GFX_Library
Using library debug_tt in folder: C:\Users\kurte\Documents\Arduino\libraries\debug_tt (legacy)
Using library SPI at version 1.0 in folder: D:\arduino-1.8.9\hardware\teensy\avr\libraries\SPI 
Using library Adafruit_GFX at version 1.5.6 in folder: D:\arduino-1.8.9\hardware\teensy\avr\libraries\Adafruit_GFX 
Using library ST7735_t3 at version 1.0.0 in folder: C:\Users\kurte\Documents\Arduino\libraries\ST7735_t3 
"D:\\arduino-1.8.9\\hardware\\teensy/../tools/arm/bin/arm-none-eabi-size" -A "C:\\Users\\kurte\\AppData\\Local\\Temp\\arduino_build_939326/uncannyEyes0.ino.elf"
Sketch uses 214672 bytes (10%) of program storage space. Maximum is 2031616 bytes.
Global variables use 224688 bytes (21%) of dynamic memory, leaving 823888 bytes for local variables. Maximum is 1048576 bytes.

Which does not look scary: BUT... I have no idea of the 224688 bytes includes the actual const data: as I believe that the defaultEye has: 217088 bytes... Although I did not double check that all of the same settings were used. Although I did retry again making sure I said I was using Symetrical... And it still came out 217088... Or only 7600 bytes for everything else...

Note If I take that file and objdump the header information:

:\Users\kurte\AppData\Local\Temp\arduino_build_939326>D:\arduino-1.8.9\hardware\tools\arm\arm-none-eabi\bin\objdump -h uncannyEyes0.ino.elf

uncannyEyes0.ino.elf:     file format elf32-littlearm

Sections:
Idx Name          Size      VMA       LMA       File off  Algn
  0 .text.progmem 00001880  60000000  60000000  00010000  2**3
                  CONTENTS, ALLOC, LOAD, READONLY, CODE
  1 .text.itcm    00009af0  00000000  60001880  00020000  2**6
                  CONTENTS, ALLOC, LOAD, READONLY, CODE
  2 .fini         00000004  00009af0  6000b370  00029af0  2**2
                  CONTENTS, ALLOC, LOAD, READONLY, CODE
  3 .ARM.exidx.text.__aeabi_atexit 00000008  00009af4  6000b374  00029af4  2**2
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
  4 .ARM.exidx    00000000  00009afc  6000b37c  00029afc  2**2
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
  5 .data         00029320  20000000  6000b37c  00030000  2**3
                  CONTENTS, ALLOC, LOAD, DATA
  6 .bss          00003fa0  20029320  20029320  00009320  2**12
                  ALLOC
  7 .bss.dma      00000000  20200000  20200000  00000000  2**0
                  ALLOC
  8 .ARM.attributes 0000002e  00000000  00000000  00059320  2**0
                  CONTENTS, READONLY
  9 .comment      0000006e  00000000  00000000  0005934e  2**0
                  CONTENTS, READONLY
 10 .debug_info   0003bcd4  00000000  00000000  000593bc  2**0
                  CONTENTS, READONLY, DEBUGGING
 11 .debug_abbrev 00006651  00000000  00000000  00095090  2**0
                  CONTENTS, READONLY, DEBUGGING
 12 .debug_line   000087a5  00000000  00000000  0009b6e1  2**0
                  CONTENTS, READONLY, DEBUGGING
 13 .debug_frame  00003220  00000000  00000000  000a3e88  2**2
                  CONTENTS, READONLY, DEBUGGING
 14 .debug_str    0000a184  00000000  00000000  000a70a8  2**0
                  CONTENTS, READONLY, DEBUGGING
 15 .debug_loc    000143f6  00000000  00000000  000b122c  2**0
                  CONTENTS, READONLY, DEBUGGING
 16 .debug_aranges 00000c58  00000000  00000000  000c5628  2**3
                  CONTENTS, READONLY, DEBUGGING
 17 .debug_ranges 00003208  00000000  00000000  000c6280  2**0
                  CONTENTS, READONLY, DEBUGGING

[mjs513]

@KurtE
I just did the same thing with the latest version of UncannyEyes I am using:

Sketch uses 195008 bytes (9%) of program storage space. Maximum is 2031616 bytes.
Global variables use 77968 bytes (7%) of dynamic memory, leaving 970608 bytes for local variables. Maximum is 1048576 bytes.

and with the dump:

C:\Users\Merli\AppData\Local\Temp\arduino_build_427222>F:\arduino-1.8.9\hardware\tools\arm\arm-none-eabi\bin\objdump -h uncannyEyes0.ino.elf

uncannyEyes0.ino.elf:     file format elf32-littlearm

Sections:
Idx Name          Size      VMA       LMA       File off  Algn
  0 .text.progmem 000206d0  60000000  60000000  00010000  2**3
                  CONTENTS, ALLOC, LOAD, READONLY, CODE
  1 .text.itcm    00005dd0  00000000  600206d0  00040000  2**3
                  CONTENTS, ALLOC, LOAD, READONLY, CODE
  2 .fini         00000004  00005dd0  600264a0  00045dd0  2**2
                  CONTENTS, ALLOC, LOAD, READONLY, CODE
  3 .ARM.exidx.text.__aeabi_atexit 00000008  00005dd4  600264a4  00045dd4  2**2
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
  4 .data         00009520  20000000  600264ac  00050000  2**3
                  CONTENTS, ALLOC, LOAD, DATA
  5 .bss          00003da0  20009520  20009520  00009520  2**12
                  ALLOC
  6 .bss.dma      00000000  20200000  20200000  00000000  2**0
                  ALLOC
  7 .ARM.attributes 0000002e  00000000  00000000  00059520  2**0
                  CONTENTS, READONLY
  8 .comment      0000006e  00000000  00000000  0005954e  2**0
                  CONTENTS, READONLY
  9 .debug_info   00034c6f  00000000  00000000  000595bc  2**0
                  CONTENTS, READONLY, DEBUGGING
 10 .debug_abbrev 00005b05  00000000  00000000  0008e22b  2**0
                  CONTENTS, READONLY, DEBUGGING
 11 .debug_line   00007a41  00000000  00000000  00093d30  2**0
                  CONTENTS, READONLY, DEBUGGING
 12 .debug_frame  00002824  00000000  00000000  0009b774  2**2
                  CONTENTS, READONLY, DEBUGGING
 13 .debug_str    00009c6b  00000000  00000000  0009df98  2**0
                  CONTENTS, READONLY, DEBUGGING
 14 .debug_loc    00013630  00000000  00000000  000a7c03  2**0
                  CONTENTS, READONLY, DEBUGGING
 15 .debug_aranges 00000b68  00000000  00000000  000bb238  2**3
                  CONTENTS, READONLY, DEBUGGING
 16 .debug_ranges 00002fd8  00000000  00000000  000bbda0  2**0
                  CONTENTS, READONLY, DEBUGGING

With terminator and no progmem used which trashes the USB:

Sketch uses 194992 bytes (9%) of program storage space. Maximum is 2031616 bytes.
Global variables use 204928 bytes (19%) of dynamic memory, leaving 843648 bytes for local variables. Maximum is 1048576 bytes.

with

C:\Users\Merli\AppData\Local\Temp\arduino_build_858246>F:\arduino-1.8.9\hardware\tools\arm\arm-none-eabi\bin\objdump -h uncannyEyesX.ino.elf

uncannyEyesX.ino.elf:     file format elf32-littlearm

Sections:
Idx Name          Size      VMA       LMA       File off  Algn
  0 .text.progmem 00001820  60000000  60000000  00010000  2**3
                  CONTENTS, ALLOC, LOAD, READONLY, CODE
  1 .text.itcm    00005dc0  00000000  60001820  00020000  2**3
                  CONTENTS, ALLOC, LOAD, READONLY, CODE
  2 .fini         00000004  00005dc0  600075e0  00025dc0  2**2
                  CONTENTS, ALLOC, LOAD, READONLY, CODE
  3 .ARM.exidx.text.__aeabi_atexit 00000008  00005dc4  600075e4  00025dc4  2**2
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
  4 .data         000283d0  20000000  600075ec  00030000  2**3
                  CONTENTS, ALLOC, LOAD, DATA
  5 .bss          00003ef0  200283d0  200283d0  000083d0  2**12
                  ALLOC
  6 .bss.dma      00000000  20200000  20200000  00000000  2**0
                  ALLOC
  7 .ARM.attributes 0000002e  00000000  00000000  000583d0  2**0
                  CONTENTS, READONLY
  8 .comment      0000006e  00000000  00000000  000583fe  2**0
                  CONTENTS, READONLY
  9 .debug_info   00034c6f  00000000  00000000  0005846c  2**0
                  CONTENTS, READONLY, DEBUGGING
 10 .debug_abbrev 00005b05  00000000  00000000  0008d0db  2**0
                  CONTENTS, READONLY, DEBUGGING
 11 .debug_line   00007a47  00000000  00000000  00092be0  2**0
                  CONTENTS, READONLY, DEBUGGING
 12 .debug_frame  00002824  00000000  00000000  0009a628  2**2
                  CONTENTS, READONLY, DEBUGGING
 13 .debug_str    00009c6b  00000000  00000000  0009ce4c  2**0
                  CONTENTS, READONLY, DEBUGGING
 14 .debug_loc    0001365b  00000000  00000000  000a6ab7  2**0
                  CONTENTS, READONLY, DEBUGGING
 15 .debug_aranges 00000b68  00000000  00000000  000ba118  2**3
                  CONTENTS, READONLY, DEBUGGING
 16 .debug_ranges 00002fd8  00000000  00000000  000bac80  2**0
                  CONTENTS, READONLY, DEBUGGING

Looks like its normally under 200k compile - only thing that may have changed are added printf's?

[KurtE]

Oops looks like I may have copied the wrong file into my foo program. The sizes are different:

Lower_Buffer: 2000112c
upper_buffer: 20200000
stack buffer: 20077fd0
Heap Buffer: 20200028
Setup: 7d
UncannyEye sclera: 60001268(80000)
           iris: 60014ae8(32768)
          upper: 6001cae8(16384)
          lower: 60020ae8(16384)
          polar: 60024ae8(12800)
  Total: 158336

So if I take a look at your values: 204928 -77968 = 126,960
So interesting to know what all the differences are?

[mjs513]

@KurtE

Just to get back to the displays. Just ran UncannyEyes using 2 ssd1351s. Interesting things are happening - I think I may have said this before - getting CRS with everything lately;

  //{ 10, 0, 0, 0 }, // LEFT EYE display-select and wink pins, no rotation
  { 5, 0, 0, 0 }, // LEFT EYE display-select and wink pins, no rotation
This selection displays both eyes same if you comment out {5,0,0,0} and uncomment CS 10.

  { 10, 0, 0, 0 }, // LEFT EYE display-select and wink pins, no rotation
  { 5, 0, 0, 0 }, // LEFT EYE display-select and wink pins, no rotation
This selection runs both eyes for a few blinks and the sketch hangs - no more blinks - but it doesn't hang the USB

Just thought you would like to know.

[KurtE]

@mjs513 @defragster ...

Not sure the best place to post this...

But figured out why the update Async (DMA) version one eye was not working....

I figured out that it was always in a blink state. Why when using DMA and not when not using DMA?

Well it turns out that the Eyes were defined like:

eyeInfo_t eyeInfo[] = {
  {0,  2, 26, 27, 3, 0, 0, INITR_144GREENTAB }, // RIGHT EYE display-select and wink pins, no rotation
  {10, 9, 11, 13, 8, 0, 0, INITR_144GREENTAB }, // LEFT EYE display-select and wink pins, no rotation
};

The 0 in RED is the interesting value. It is the pin to use to force a WINK... Well it is Also defined as the CS pin for the first eye...
So it is HIGH when that eye is not updating, and LOW when it is...

Fixed by changing the WINK pins to -1 (no wink pin) and now works in DMA mode...

Now on the ST7735(128x128) it is now showing about 109 frames per second... Using Max stack of 1460...

So far still with the ST7789 boards it is only using a portion of the display. Would not be hard to make work with the CS Challenged displays.
Could either simply add another parameter to the above table for SPI_MODE2 OR, could detect if CS=-1 and do it explicitly.

Will be interesting to see what Lady Ada has done with their version with the larger displays. She could have either used larger images and as such created larger structures, OR should could be doing some scaling.

[mjs513]

@KurtE

Cool that you got it working. Is that using SPI and SPI1?

Does it still work if you have a unused pin for WINK? Just curious.
I did have this in the config:

  { 10, 0, 0 }, // LEFT EYE display-select and wink pins, no rotation
  {  6, 2, 0 }, // RIGHT EYE display-select and wink pins, no rotation

but nothing attached to those pins and it still worked so should still for DMA I hope. But to be on the safe side I changed it to

  { 10, -1, 0 }, // LEFT EYE display-select and wink pins, no rotation
  {  6, -1, 0 }, // RIGHT EYE display-select and wink pins, no rotation

So far still with the ST7789 boards it is only using a portion of the display. Would not be hard to make work with the CS Challenged displays.
Could either simply add another parameter to the above table for SPI_MODE2 OR, could detect if CS=-1 and do it explicitly.

Think I would do it explicitly I you were to go down that path

Oh just as a laugh I changed the screen rotation values for the eye configs - it does work - also looks even creeper.

[MichaelMeissner]

@mjs513 @defragster ...

Not sure the best place to post this...

But figured out why the update Async (DMA) version one eye was not working....

I figured out that it was always in a blink state. Why when using DMA and not when not using DMA?

Well it turns out that the Eyes were defined like:

eyeInfo_t eyeInfo[] = {
  {0,  2, 26, 27, 3, 0, 0, INITR_144GREENTAB }, // RIGHT EYE display-select and wink pins, no rotation
  {10, 9, 11, 13, 8, 0, 0, INITR_144GREENTAB }, // LEFT EYE display-select and wink pins, no rotation
};

The 0 in RED is the interesting value. It is the pin to use to force a WINK... Well it is Also defined as the CS pin for the first eye...
So it is HIGH when that eye is not updating, and LOW when it is...

Fixed by changing the WINK pins to -1 (no wink pin) and now works in DMA mode...

Now on the ST7735(128x128) it is now showing about 109 frames per second... Using Max stack of 1460...

So far still with the ST7789 boards it is only using a portion of the display. Would not be hard to make work with the CS Challenged displays.
Could either simply add another parameter to the above table for SPI_MODE2 OR, could detect if CS=-1 and do it explicitly.

Will be interesting to see what Lady Ada has done with their version with the larger displays. She could have either used larger images and as such created larger structures, OR should could be doing some scaling.

Well, it wasn't Limor Fried (i.e. Lady Ada), but Phillip Burgess, author of the various versions of uncanny eyes (Teensy, Pi, Hallowing, and now Monster M4SK), has a version up for the Monster M4SK or Hallowing:

• Monster M4SK product page: https://www.adafruit.com/product/4343, 2 240x240 displays, Cortex M4, overclocked to 180Mhz, with 512KB Flash, 192KB RAM;
• Hallowing product page: https://www.adafruit.com/product/3900, 1 128x128 display, Cortex M0, 48Mhz, 256KB flash, 32KB RAM;
• Source code: https://learn.adafruit.com/adafruit-...om-source-code

I haven't looked at it in detail, but each screen on the Monster M4SK is on its own SPI bus, and it now does the eye calculation for each eye is done separately, and in parallel with the DMA transfers.

In addition, because the Adafruit Monster M4SK and last year's Hallowing have a bit of flash that looks like a removable drive, you can edit the config.eye file, and put in new eye patterns, without have to download a new version of the code.

I did buy a Monster M4SK, and the default code looks like the old 128x128 displays.

[mjs513]

@MichaelMeissner - @KurtE

Just looked at it after your post and sure enough they did what @KurtE just did, i.e., DMA plus SPI and SPI1. Defined in th globals.

#if defined(ADAFRUIT_MONSTER_M4SK_EXPRESS)
    // name     spi  cs  dc rst wink
    { "right", &SPI , 5,  6,  4, -1 },
    { "left" , &SPI1, 9, 10, -1, -1 } };

Also looks like eyes are now bitmaps not sure about scaling but probably. Looks like they ditched those progmem blocks

[KurtE]

Yes I took a look as well. For that version, it looks like they are storing the image on SDCard? or the like and using Bitmap files...
They also changed some of the data for the eyelid stuff.

So for the heck of it, I did a quick and dirty and took the defaultEyes image data they have in their main UncannyEyes github project and then brought them all into Photoshop and changed the sizes to be bigger, which had photoshop do the interpolation. I then used their conversion python script, after I figured out how to get all of the pieces. I also edited a copy of their script from 128 to 240...

I then brought that header file into my version of the sketch and added a #define that for ST7789 is 240 else 128 and changed several of places that have hard coded 128 to use this define. And needed to change a few uint8_t to uint16_t... Still a few more issues to go, but at least it shows up. Camera image a little washed out...

[MichaelMeissner]

Yes I took a look as well. For that version, it looks like they are storing the image on SDCard? or the like and using Bitmap files...
They also changed some of the data for the eyelid stuff.

Some of the Adafruit processors have a flash memory system that you can read like a SD card (similar to the 8 megabyte flash memory in the Teensy prop shield, or the flash memory system you can solder onto the audio card). However, the Adafruit system (through Tiny USB?) will export this flash memory when it is attached to a computer with USB, so you can access this directly without having to use Teensy Transfer. In general, I believe this was originally for Circuit Python (the python code would be stored in that flash memory, and you could edit the text with a normal editor).

So for the heck of it, I did a quick and dirty and took the defaultEyes image data they have in their main UncannyEyes github project and then brought them all into Photoshop and changed the sizes to be bigger, which had photoshop do the interpolation. I then used their conversion python script, after I figured out how to get all of the pieces. I also edited a copy of their script from 128 to 240...

I then brought that header file into my version of the sketch and added a #define that for ST7789 is 240 else 128 and changed several of places that have hard coded 128 to use this define. And needed to change a few uint8_t to uint16_t... Still a few more issues to go, but at least it shows up. Camera image a little washed out...

Cool. Note, in the zip file, they have the larger images in BMP format in the eyes/hazel directory. This is the image that you need to put into the flash memory system and it gives the standard hazel image. On my Monster M4SK, the flash memory is 8 megabytes and the eyes take about 450K.

[mjs513]

@KurtE - @MichaelMeissner

Not 100% sure which way I prefer the eye data to be set up. Bitmaps or const data. Guess with Bitmap files you don't run into the problems we are/were having.

@KurtE - you are amazing getting it converted already. Wonder if instead of using flash you could use the T4 MSC to read the files from a memory or stick or external SD card so you don't have to worry about the SD Card on the display working or having a SD card attached to the T4?

I do have a image resizer sketch for bmp RGB data if you are interested - haven't really tested too. know for going from 32x32 to 64x64 don't work to well but for larger images may work out if you are interested.

[KurtE]

Good morning,

Thanks Michael, maybe at some point someone could setup a Teensy with a small memory system like that. It would be nice if one could copy files to and from PC without having to reprogram the Teensy....

This morning I fixed the color issue of the mirrored eye... Different MADCTL values for ST7789 versus ST7735. Still don't have the Iris and maybe pupil scaling correctly... Not sure how far to take this.

I was mainly continuing as to figure out why certain things were appearing to crash the T4 or DMA appeared not to work.

Which helped fix some issues in st7735/89 library: issued PR yesterday: https://github.com/PaulStoffregen/ST7735_t3/pull/3

DMA issue turned out to be reuse of same pin... May work a little more just to see if I quickly figure out that scale issue.


@defragster (and others) with ST7789 displays without CS pins, I put in maybe correct init (if you set cs = -1) in the eyeinfo structure. If you want to give it a try, I can post now, or will play a little longer
and see if I figure out the scale issue...

[mjs513]

Hi Kurt

Yeah - it would be nice but it all depends on how complicated. Probably could set something up to read in a config file for the sketch setting the values of some variables etc. But making it like active memory - that would be a challenge.

This morning I fixed the color issue of the mirrored eye... Different MADCTL values for ST7789 versus ST7735. Still don't have the Iris and maybe pupil scaling correctly... Not sure how far to take this.

I was mainly continuing as to figure out why certain things were appearing to crash the T4 or DMA appeared not to work.

Think the challenge is going to be once you demo uncannyEyes with the different displays you know you we are all going to use it so might as well fix it once. Also, with the new M4 version of uncanny eyes might as well if you are already half there.

In terms of T4 crashing with 2 displays on one - really for best to leave that now - just make sure its noted that the eyes need to be updated to progmem.

[mjs513]

@KurtE

Ok ran into a problem For my NN classification test on the T4 had to swap out the ILI9341 with the Adafruint 240x320 display . Oh well. Anyway a couple of questions that I am stuck on;

1. The ST7735/ST7789 lib doesn't have a set origin so do I setRowColStart?
2. Color conversion challenged (that's me that's challenged!)
a. Got the image to display with the normal writeRect function so the uint16 color is good.
b. To convert to RGB I used:

      r = (color>>8)&0x00F8;
      g = (color>>3)&0x00FC;
      b = (color<<3)&0x00F8;

Think that's right
c. to make sure that worked I converted back to color using:

#define CL(_r,_g,_b) ((((_r)&0xF8)<<8)|(((_g)&0xFC)<<3)|((_b)>>3))

d. When I dump the image again its now on the reddish side (whites are like pinks)

Can you seen anything I am doing wrong?

[KurtE]

@mjs513 - Sorry been MIA today.

Doing exciting things like: Had a company come out and power clean out the dryer vents, plus replace the roof cap as was damaged when I tried to clean it from inside the attic. Also add another roof vent so our bathroom fans are not sharing the same roof vent... Plus some estimates on some gutter repairs... Now waiting for Washer/Dryer to arrive as the older washer the main bearing went out....

1) We never implemented the setOrigin in this library, which works nicely with clip rectangles. The setRowColStart was something suggested by Lady Ada to help resolve an issue, where for example the ST7735 has memory for 128x160. Where in this memory do people use for a 128x18? Some started at the first row, some started at row 32... And if I remember it more like 132x162 or some such thing, so some may start at col 0 other at 1 or 2...

2) Color conversion probably is correct, I can be challenged that way as well. As I get confused on which display I am working on. I believe this is a 5x5 color scheme. and then have to remember where when you do the conversion of the 5 bits to 8, bits where the bits go... So: RRRRRGGG | GGGBBBBB
So with: r = (color>>8)&0x00F8; gives us RRRRR000
G: GGGGGGBB & FC = GGGGGG00
B: BBBBB000 & F8 = BBBBB000

So again sort of looks correct..

Right now I am doing something completely random and seeing about making a SSD1351_t3 library off of the ST7735_t3 library...

[mjs513]

@KurtE

You've had a real busy day today I see. Good thing you are getting things done before the cold weather sets in - no fun doing things when its cold out.

Thanks for the explanation. Maybe we need to do a setOrgin for the libraries - really comes in handy at times - on list of things to do. Well as for the SSD1351_t3 library - won't get an argument out of me - already have 2 set up for uncanny eyes yes that thing again.

Forgot - was just getting ready to post - figured out what I did wrong that caused me so much grief - stupid c++ array indexing problem. Got it working now - but I did manage to get a nice image resizer function working

[KurtE]

@KurtE

You've had a real busy day today I see. Good thing you are getting things done before the cold weather sets in - no fun doing things when its cold out.

Thanks for the explanation. Maybe we need to do a setOrgin for the libraries - really comes in handy at times - on list of things to do. Well as for the SSD1351_t3 library - won't get an argument out of me - already have 2 set up for uncanny eyes yes that thing again.

Forgot - was just getting ready to post - figured out what I did wrong that caused me so much grief - stupid c++ array indexing problem. Got it working now - but I did manage to get a nice image resizer function working

Glad you figured it out...

Actually right now I have 3 uncanny eyes setups 8)
Still need to debug the Iris size issue with ST7789 eyes...
But have:
2 ST7735 on SPI And SPI1
2 Adafruit ST7789 on SPI and SPI1
2 CS challenged ST7789 son SPI and SPI2 (using Pauls breakout and Sparkfun SDCard breakout board...) - So if someone like Tim or ... with these challenged displays wish to play along:
All post up the current async version of the code with a large eye defined...

Would also probably post my current python conversion script (edited from the one in unc... project to allow bigger files)...


Yes - trying to get a few things done... The gutter cleaning and gutter guards are likely be sometime near October before they will have time...

[mjs513]

Yeah

Now have to figure out why the NN classification isn't working. Probably coded something wrong -have some debugging to do.

You are worse than me with the different setups. I only have one for SST7735's for UncannyEyes, one setup for SSD1351's, 1 setup for CANFD, and my Arducam/ST7789 display.

I'll pull down the latest versions to see what it gives me - guess I have to breakout the other breakout board and maybe solder up another one.

[KurtE]

An FYI, I just pushed up a new library to my github: https://github.com/KurtE/SSD1351_t3

I have tried a few of the demos and updated some... More go to...

All because someone asked how many frame per second

Simple sketch, that runs either Adafruit library or new one...

#define USE_ADAFRUIT_SSD1351
#include <Adafruit_GFX.h>    // Core graphics library
#include <SPI.h>
#define TFT_SCLK 13  // SCLK can also use pin 14
#define TFT_MOSI 11  // MOSI can also use pin 7
#define TFT_CS   10  // CS & DC can use pins 2, 6, 9, 10, 15, 20, 21, 22, 23
#define TFT_DC    9  //  but certain pairs must NOT be used: 2+10, 6+9, 20+23, 21+22
#define TFT_RST   8  // RST can use any pin

#ifdef USE_ADAFRUIT_SSD1351
#include <Adafruit_SSD1351.h>
Adafruit_SSD1351 tft = Adafruit_SSD1351(TFT_CS, TFT_DC, TFT_MOSI, TFT_SCLK, TFT_RST);
#define SSD1351_BLACK   0x0000
#define SSD1351_BLUE    0x001F
#define SSD1351_RED     0xF800
#define SSD1351_GREEN   0x07E0
#define SSD1351_CYAN    0x07FF
#define SSD1351_MAGENTA 0xF81F
#define SSD1351_YELLOW  0xFFE0
#define SSD1351_WHITE   0xFFFF

#else
#include <SSD1351_t3.h> // Hardware-specific library
SSD1351_t3 tft = SSD1351_t3(TFT_CS, TFT_DC, TFT_MOSI, TFT_SCLK, TFT_RST);
#endif

void setup(void) {
  pinMode(TFT_CS, INPUT_PULLUP);

  while (!Serial && millis() < 5000) ;
  Serial.begin(9600);
  Serial.print("Start simple Frames Per Second test");

  Serial.printf("CS:%d DC:%d MOSI:%d SCLK:%d RST:%d\n", TFT_CS, TFT_DC, TFT_MOSI, TFT_SCLK, TFT_RST);
  tft.begin() ;  //
}

uint16_t color_list[] = {SSD1351_RED, SSD1351_GREEN, SSD1351_BLUE, SSD1351_WHITE, SSD1351_BLACK,
                         SSD1351_YELLOW, SSD1351_MAGENTA, SSD1351_CYAN
                        };
void loop() {
  uint16_t color_index = 0;
  uint16_t frame_count = 0;
  elapsedMillis em = 0;

  // How many frames per second? 
  while (em < 1000) {
    tft.fillScreen(color_list[color_index++]);
    if (color_index >= (sizeof(color_list)/sizeof(color_list[0]))) color_index = 0;
    frame_count++;
  }
  Serial.printf("Frames: %d in %d ms\n", frame_count, (uint32_t)em);  
}

Adafruit reports about 48 frames per second:

Frames: 48 in 1019 ms
Frames: 48 in 1019 ms
Frames: 48 in 1019 ms

New one

Frames: 72 in 1005 ms
Frames: 72 in 1005 ms
Frames: 72 in 1006 ms

[mjs513]

An FYI, I just pushed up a new library to my github: https://github.com/KurtE/SSD1351_t3

I have tried a few of the demos and updated some... More go to...

All because someone asked how many frame per second

…..

Adafruit reports about 48 frames per second:

Frames: 48 in 1019 ms
Frames: 48 in 1019 ms
Frames: 48 in 1019 ms

New one

Frames: 72 in 1005 ms
Frames: 72 in 1005 ms
Frames: 72 in 1006 ms

How sweet it is - you just couldn't resist

[mjs513]

@KurtE

Since I am now using the ST7789 more and more I think I am going to add some more features to it like you have in the other libs if you don't mind. Came across this one that might be of interest (https://github.com/Bodmer/TFT_ST7735) and since it reminds me so much of your the ili9341/9488 libraries it has inspired - da..n - going to add a bunch more functions just because we can. Reason - I want to place text and make it larger so.....

Well that's tomorrows project.

[KurtE]

@mjs513 (@PaulStoffregen) - Sounds good to me... Paul owns the library... So he will be the one who needs to take in the PR's.

Hopefully Paul will grab the current PR for fixing DMA issues when the objects are created in the heap space, before the next teensduino release/beta...

And then you will obviously need to add it now to the SSD1351 stuff