@KurtE
Just did the merge and it now works like a charm with and without frame buffer.
@KurtE
Just did the merge and it now works like a charm with and without frame buffer.
Hello, I tried using the latest update from github (the t4 rewrite branch). I currently have a Teensy 4 and a ST7789 screen wired up. I have tried both the CS and no CS configs, with the only other change being switching pin SCK to 14 instead of 13. So far I get no picture with the uncanny eye example (I get the backlight though). Can I confirm that SDA is MOSI according to this pinout? https://facelesstech.files.wordpress.../13_pinout.jpg
Maybe I'm missing something else, but I'm pretty excited to get this running!
Yes SDA goes to MOSI.
You will need to do some reconfiguration for your display though. The 7789 example is set up to use SPI and SPI1 as well as a 240x240 displat. If you are using only SPI with CS pins specified you will make sure you comment out:
and then in the config file adjust these lines for your display:#define ST77XX_ON_SPI_SPI1
Think you get the idea - let us know if you run into problemsCode:#else //CS DC MOSI SCK RST WINK ROT INIT {0, 2, 26, 27, 3, -1, 0, INITR_144GREENTAB }, // RIGHT EYE display-select and wink pins, no rotation {10, 9, 11, 13, 8, -1, 0, INITR_144GREENTAB }, // LEFT EYE display-select and wink pins, no rotation #endif
Thanks for the reply! I commented out the #define ST77XX_ON_SPI_SPI1 in the main sketch, and updated both pin 13s on the config to be pin 14. I'm still not getting any picture on the screen, although this is the first sketch I'm running since I got my Teensy 4. I have no light on the Teensy when initially plugged in, but when programming, I press the button on the Teensy and get a dim red light. From what I can tell, it appears to be uploading the code right. Also if it's important, I got all the ground and LED Cathode connected together for ground. I also have the power and LED anode paired together in the 3v pin.
Can you post a link to the exact display you are using and maybe a schematic/photo of your wiring to the T4. Have to remember that the T4 is not 5v tolerant. The adafruit display I have uses 3.3v and does not have a LED pin
Also I would try running the graphictest.ino sketch first before trying it with uncanny eyes.
I've been using these:https://www.aliexpress.com/item/3295...chweb201603_52
I've gotten them to work with a raspberry pi before, although this is my first time trying them on other hardware. I don't have anything wired to 5v, except the USB cable powering the teensy. I'll see if I can get a good picture of my wiring shortly.
Edit:
For clarity's sake, wiring is, pins:
1,2,5,6,12 - Ground - Black
3,4 - 3.3v - Red
7 - D/C - White
8 - CS - Blue
9 - SCL - Green
10 - SDA - Yellow
11 - Reset - Orange
Last edited by FroggestSpirit; 10-07-2019 at 02:05 AM.
Ok - never seen any display like that before - where did you find the specs for the pinouts etc?Originally Posted by FroggestSpirit
I believe they're the same as the adafruit ones, just without the board they connect to. This site seems to have a bit more on the wiring, but I usually just google ST7789 pinout to reference. https://facelesstech.wordpress.com/2...-raspberry-pi/
I've updated my last post with pictures and wiring.
(On a side note, is there a way to handle the pictures better? spoiler tags didn't seem to work and the code tag made the section very thin)
Ok - lets start with your wiring:
Also use a volt meter just to check your wiring to make sure you don't have any shorts.Code:Display - Pin Desc - T4 (what you have) - T4 what should be 1,2,5,6,12 - Ground - Black - no problem 3,4 - 3.3v - Red - no problem 7 - D/C - White - Pin 9 --- ok this can be any digital pin 8 - CS - Blue - Pin 10 ---- ok this is typical for CS pin 9 - SCL - Green - Pin 14 ---- SPI CLOCK IS ON PIN 13 not pin 14 10 - SDA - Yellow - Pin 11 - Pin 11 so this is ok. 11 - Reset - Orange - Pin 8 - Pin 8 typical and what I am using
So would say at a minimum you need to fix your clock wire. But I am a little concerned that the red light is on dim when you load the sketch. Just as check load the blink sketch and make sure the T4 blinks after rewiring and checking connections especially gnds and 3.3v lines.
Next I would run the graphicstest sketch to make sure wiring is correct.
Hope this helps
Are you sure you have enough power on the 3.3 volt line? That display may require more power than the Teensy can provide. You may need an external power supply.
I switched the SCLK pin to 13, the UncannyEyes example still did not work (after correcting config to use pin 13 again). However, I ran the scrolltest, and got garbled pixels (every pixel was a random color) This was not animated. The only change I made to the sketch was to switch the screen size to 240x240 (I think it uses ST7789 by default too). I'm sure the screen has enough power, it's a pretty low powered screen, though I tried powering the teensy with a wall port and got the same results. After a few power cycles, the "random" pixels appear to be consistant with what colors are where, giving me the same image each time.
Edit: also forgot to add, I tested for continuity from the ribon cable on the screen to the ports on the teensy, everything seems to be wired good without data pins shorting.
Edit2: got it to work! didn't realize the serial window needed to be up. (commented the while(!Serial) out to bypass this). Thanks for your help!
Scrolltest has issues with the ST7789 probably should delete that function but hoping to figure out how to readpixels from the display. Please try and run the graphicstest.ino sketch.
EDIT: did you check that you don't have any solder bridges - in the photo it looked like maybe you did?
the only bridges i have were for connecting the multiple grounds and the led to the 3v input. is there a separate folder for the graphics test? the only one i seen was for the ILI screen, not the ST ones. though the scroll test did seem to work flawlessly from what i could tell
Sorry - when I posted my question there were no edits in you post #261.
So - glad you got it working
I was doing some runs of uncanny eyes this morning on a Teensy 4.0 using the 240x240 Adafruit displays, one on SPI0 using the default 10 CS pin, and the second display on SPI1 using the default 0 pin for CS1. I'll post numbers later, once I've done tests of the various configurations I've run (Teensy 3.2 on 128x128 TFT displays, Teensy 3.5 on 128x128 OLED displays, Teensy 4.0 on 240x240 TFT IPS displays, Adafruit Hallowing M0 on a single 128x128 display, Adafruit Hallowing M4 on a single 240x240 display, Adafruit Monster M4SK on a pair of 240x240 displays).
I was thinking about adding the audio shield to get the SD drive (which also uses pin 10). So I moved the CS pin from pin 10 to pin 22 to see what the degradation would be, and I was surprised that there was no degradation in using something other than pin 10. I had async updates on and I was using the ST7735_t3 library from the 1.48 release. Does that mean with the T4, that unlike the T3 series, we don't need to pick CS and D/C from favored pins?
Has anybody actually run another SPI device along with the monitor? Do you need to insert the appropriate beginTransaction endTransaction calls in key places in the monitor code? Or do I have to turn off the async support? Obviously if you are sharing the SPI bus, you need good pull-up resistors on the CS/DC pins. Also obviously, you can't use the no-CS pin cheapo displays on a shared SPI bus.
Last edited by MichaelMeissner; 10-10-2019 at 10:03 PM.
Timings for different uncanny eyes
This morning I decided to do timing runs for all of the uncanny eye variants I have setup. Note, these don't necessarily have the same options compiled it, and they are using somewhat different base sources. The only weird thing is the Teensy 4.0 with 1 eye is reporting 15-16fps, while 2 eyes tends to be 30-32 fps.
The T3.2 and T3.5 use the traditional approach of 1 SPI bus with 2 displays on it. I haven't tried using the second SPI bus on the 3.5.
I found I could not use the T3.2 with the original sources and have the display show up, but I used my hacked up sources setting the SPI bus to 24Mhz.
For the Teensy 4.0, I did define USE_ASYNC_UPDATES, and I see from the serial monitor that is using the frame buffer for both displays. I am using the ST7735_t3 from the Teensydunio 1.48 release. I am using 2 separate SPI buses.
Code:Teensy 3.2, MK20DX256VLH7, M4, cpu 96Mhz, spi 24Mhz, TFT, 128x128, ST7735, 2 eyes: 85fps Teensy 3.2, MK20DX256VLH7, M4, cpu 96Mhz, spi 24Mhz, TFT, 128x128, ST7735, 1 eye: 85fps Teensy 3.5, MK64FX512, M4, cpu 120Mhz, spi 18Mhz, OLED, 128x128, SSD1351, 2 eyes: 56fps Teensy 3.5, MK64FX512, M4, cpu 120Mhz, spi 18Mhz, OLED, 128x128, SSD1351, 1 eye: 56fps Teensy 4.0, i.MX RT 1062, M7, cpu 600Mhz, spi 48Mhz, TFT, 240x240, ST7789, 2 eyes: 30-32fps Teensy 4.0, i.MX RT 1062, M7, cpu 600Mhz, spi 48Mhz, TFT, 240x240, ST7789, 1 eye: 15-16fps Hallowing M0, ATSAMD21G18, M0, cpu 48Mhz, spi 12Mhz, TFT, 128x128, ST7735, 1 eye: 22fps Hallowing M4, ATSAMD51G18, M4, cpu 120Mhz, spi 50Mhz, TFT, 240x240, ST7789, 1 eye: 27-31fps Monster M4SK, ATSAMD51G19, M4, cpu 120Mhz, spi 50Mhz, TFT, 240x240, ST7789, 2 eyes: 20-29fps
@KurtE
Was looking at the diffs between my version and Paul's version since my ST7735 lib seems to be 7 commits behind the master (figure they should be close to be even). I did notice a couple of things with DMA that is making me wonder if the master may be missing a update. Simple comparison:
My lib has in the st7735.cpp file
but the master does not have this? Is this right and the master needs to be updated?Code:#if defined(__MK66FX1M0__) DMASetting ST7735_t3::_dmasettings[3][4]; #endif #if defined(__IMXRT1062__) // Teensy 4.x // On T4 Setup the buffers to be used one per SPI buss... // This way we make sure it is hopefully in uncached memory ST7735DMA_Data ST7735_t3::_dma_data[3]; // one structure for each SPI buss... #endif
@mjs513 - Good morning,
I am not sure? If I look at my master branch, it shows those lines in it.
Also I looked up at Paul's version up on github: https://github.com/PaulStoffregen/ST...735_t3.cpp#L38
And it looks like those lines are there.
@KurtE
That's strange - wonder why its showing them as additions when I do a diff: https://github.com/PaulStoffregen/ST.../pull/4/files? Probably me then
@mjs513 - Yep - I run into that at times as well. Sometimes it is because I am not 100% synced up with Paul...
That is when I use my sledgehammer approach to sync... For example in my home directory I have some scripts:
Example to sync up cores
But again this is sledgehammer. That is if you have anything changed and not either git pushed or git stash or ...Code:d: cd d:\GitHub\Cores git fetch upstream git checkout master git reset --hard upstream/master git push origin master --force cd %home% c:
Regardless of your current branch, this will wipe them out!
I ran into a similar issue yesterday when editing master file imxrt.h, it showed another structure changed... So before I uploaded it, I edited my copy to remove those changes...
Now potentially the other GIT issue is that your branch was probably created before those last changes went into master. So GIT is comparing your code to where your branch was "BASED"
I know GIT has the ability to REBASE, but I have never mastered it.
My typical REBASE is again the sledgehammer. I copy away my new stuff to some save folder (example on my desktop).
I use the first sledge hammer above.
After that completes, I create a new branch, which I copy in my changed stuff, and then check the changes, push that one up.... And delete my previous working version... But I know there should be a cleaner way...
Yep - think the sledgehammer will be the way to go for me - to be honest think its cleaner (or easier for me to understand whats going on. That will be the project for when I get back from my errands.
@KurtE - ok - did the "sledgehammer" on the 7735_t3 update PR and now it is looking good with no conflicts.
Posting Permissions
Reply With Quote
