@MichaelMeissner
Hi,
thank you for your support!
Do the MISO pins need to be connected?
I don't think so, because in the old projects with the teensy 3.2 and the TFT displays with 128x128 there was a MISO pin at the TFT, but they wasn't connected either.
If you notice, many of the 128x128 displays have a micro SD card reader, and a separate pin that is the CS pin for the SD card. Those displays need to MISO so you can read data from the SD card.
Some of the 240x240 displays have a SD card reader, and they need MISO plus the 2nd CS (i.e. the Adafruit 240x240 display). Other 240x240 displays don't have a SD card slot, and they generally don't have a pin for MISO (i.e. the round 240x240 displays, but likely other displays not from Adafruit).
Some of the 240x240 displays also don't have a CS pin for the display. On those displays, you HAVE to connect the displays to separate SPI buses. Basically the CS pin is used for the Teensy to say which SPI device it is talking to (all of the SPI devices on a SPI bus are on a party line, but if the CS is not set appropriately, then the display ignores the stuff on the SPI bus). If there is no CS pin, then in config.h you have to put -1 for the pin number.
I think (but I honestly don't know), that some displays use CS being high to be active, while others might use CS being low to be active. If there is only on device on the SPI bus, you could potentially tie that CS pin high (3.3v) or low (ground).
There is only one pin left on the current TFTs (marked BL).
And what's with the blink?
On the displays that have it, if the pin is connected to ground, it turns off the display. In theory, the BL pin has a pull-up resistor so if you don't connect it, it reads high. I generally just always wire the BL pin to 3.3v.
However, if you want, you could connect the BL pin to a pin that is capable of doing PWM (pulse width management). By blinking the pin, you could achieve a dimming of the display. However, there are some people out there that are sensitive to blinking, and it might be a good idea not to try an dim the eyes via PWM. I could imagine that if you want the eye to go to sleep and use less power, you might want to connect BL to a pin that is in the low state.
Do I need that?
Where is this connected to the TFT’s?
When doing my wiring, I tried to connect the displays each on one side of the teensy 4.1 and also followed, how they were connected to the teensy 4.0.
Overall, my wiring is nearly the same as yours.
For Teensy 4.0/4.1, it does not matter what digital pin you use for CS, RST, and DC. Pick whatever pins you aren't using for something else. For Teensy 3.1/3.2/3.5/3.6 (and maybe 3.0) there were special optimizations done if CS and DC were both among the special pins.
I personally go down the rabbit hole of trying to make pin assignments so I can mix a bunch of things together, so I sometimes go with pin assignments to avoid other uses (for example, I might not use pins 7, 8, 20, 21, and 23 which are used by the audio adapter, even if I don't have audio in this particular build).
I also tend to have a few favorite pins that I use over and over. Pin 3 is typically used as a momentary button, since it didn't have much fixed use in the past. I use 17 as the first neopixel pin because the Teensy LC had a voltage shifter for pin 17.
Can I assume, that my wiring is OK as shown?
I don't want to destroy another teensy.
If the wiring is now ok.
What should the program folder look like and which files do I have to download for it?
If you are using my sources, you should down load the whole tree, and within the src directory is (note, this is how Chris set it up, I just tweaked it):
- src dirctory -- main files
- src/util -- logging sub-files. The build-logging.cpp file includes these (Arduino can't handle build files in a sub-directory, so I have build-*.cpp files that include the stuff in sub-directories).
- src/sensors -- code for the light sensor and the person sensor, included by build-LightSensor.cpp and build-PersonSensor.cpp.
- src/displays -- abstraction for the 2 different 240x240 displays, included by build-GC9A01A.cpp and build-ST7789.cpp.
- src/eyes -- place to put all of the various eyes (at present we only have 240x240 eyes)
- src/eyes/240x240 -- the 240x240 eyes. The rest of the build-*.cpp as well as config.h includes these files
This is what the folder structure looks like for the project with my teensy 3.2:
Main folder „Uncanny_Eyes-master"
View attachment 33353
Yep, one of the thing that I hated about the 3.2 setup is every time I made a different configuration for the eyes (i.e. whether I had 1 eye or 2, which display was used, etc.) I had to clone the whole directory. Before Chris had come on the scene, I had re-orgranized the code so all of the stuff was in a library, and each .ino file in a separate directory just changed which defaults to use.
Unfortunately, you can't have the two different displays (GC9A01A and ST7789) in the same library, because there are bits common between the two (since GC9A01A was cloned from ST7789, and the person doing the cloning didn't try to abstract things, and get the ST7789 folk to use that abstraction). And while the linker will throw out things (like different eyes) that aren't used, unfortunately you run into some limits before it removes the unused code. I also didn't want to stray too far from Chris's code in case they/he/she came back to do more work.
