Forum Rule: Always post complete source code & details to reproduce any issue!
Page 2 of 11 FirstFirst 1 2 3 4 ... LastLast
Results 26 to 50 of 266

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

  1. #26
    Senior Member+ KurtE's Avatar
    Join Date
    Jan 2014
    Posts
    5,414
    Actually the github is newer than that: https://github.com/KurtE/ST7735_t3/t...ct_reset_delay

    It is just that I had github merge 4 changes into 1 and it chose the time stamp from the first one.

  2. #27
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    9,672
    Okay - I wondered how sometimes files are newer than 'lastest commit' … I see that now files show 2 hours.

    Anyhow I just got what was there and I see backlighting signs of life - but no display after compile and some sermon notes: init, 49, done.

    in GraphicsTest … Changes:
    Code:
    #define TFT_SCLK 13  // SCLK can also use pin 14 // SCL
    #define TFT_MOSI 11  // MOSI can also use pin 7 // SDA
    #define TFT_CS   -1 //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
    #define SD_CS     4  // CS for SD card, can use any pin
    
    // For 1.54" TFT with ST7789
    ST7789_t3 tft = ST7789_t3(TFT_CS, TFT_DC, TFT_MOSI, TFT_SCLK, TFT_RST);
    and :: tft.init(240, 240); // initialize a ST7789 chip, 240x240 pixels

    Then wires to labels match those T4 pin #'s? … no signs of life - other than the light behind the blacked tft layer.

    I have 1.3 Inch IPS Hd Tft St7789 Drive Ic 240 x 240 :: > Not 1.54, 1.44 or 1.8" TFT

  3. #28
    Senior Member+ KurtE's Avatar
    Join Date
    Jan 2014
    Posts
    5,414
    with the CS challenged displays, you need to change the init call, to be something like: tft.init(240, 240, SPI_MODE2);

    That is there is the optional SPI mode and for some reason these work better at Mode 2...

  4. #29
    Senior Member+ KurtE's Avatar
    Join Date
    Jan 2014
    Posts
    5,414
    Quote Originally Posted by KurtE View Post
    Example: with the st7735 example the 128x128 one could enable the frame buffer support: 128x128x2= 32768 which is < 64K memory so that would fit...
    Even the 128x160*2 would fit 40960... But obviously not the st7789 ones...
    So not sure if it would ever make sense to enable it?
    Oops - it works (GH updated )

  5. #30
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    9,672
    Awesome work KurtE!

    Quote Originally Posted by KurtE View Post
    with the CS challenged displays, you need to change the init call, to be something like: tft.init(240, 240, SPI_MODE2);

    That is there is the optional SPI mode and for some reason these work better at Mode 2...
    THAT DID IT !!!!

    And mine sits wires/silkscreen rightways up and this corrects :: tft.setRotation(2);

    Looks great - under magnification … 1.3 inches is rather small area for 53,760 dots even nice clear ones.

    Works with :: ST7789_t3 tft = ST7789_t3(TFT_CS, TFT_DC, TFT_RST);
    or :: ST7789_t3 tft = ST7789_t3(TFT_CS, TFT_DC, TFT_MOSI, TFT_SCLK, TFT_RST);

  6. #31
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    9,672
    Speedtest running at 13.93 FPS -

    Here it is with edits making the NO_CS 1.3" work here:SpeedTest.ino

    opps : line #228 is copy paste leftover

    <edit>: Display has BLK:Backlight pin - I left disconnected. Connected to 3.3V seems the same - Amazon page says 'floating' is normal and 'LOW' is off
    Working voltage: 3.3V
    GND:Power ground
    VCC:3.3-5.0V(DC)
    SCL :SPI clock line
    SDA :SPI data line
    RES :Reset interface
    DC :SPI data/command selection
    BLK :Backlight control,default floating,low level off
    <Edit2> - moving to pinnable T4 on DIY breakout so I can run the MultiSerial# test and print to display - and do FreqCnt. Shifted two pins and it works:
    #define TFT_DC 10 //9 // but certain pairs must NOT be used: 2+10, 6+9, 20+23, 21+22
    #define TFT_RST 12 //8 // RST can use any pin
    Last edited by defragster; 07-28-2019 at 05:38 AM.

  7. #32
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    9,672
    I just tried prior settings changing SCLK from 13 to 14 and using the long form of : ST7789_t3 tft = ST7789_t3(TFT_CS, TFT_DC, TFT_MOSI, TFT_SCLK, TFT_RST);

    I lost visible display?

    Wanted to use FrqCnt on LED_BUILTIN to measure loop speed. Merging sketches and the LED breaks display …

    Moved to #15 for toggle to get FreqCnt - very close to counted frequency.

    <added>
    @KurtE - The tft.print and tft.printf are nice - with it filling background color - no need to clear text. And tft.setTextWrap(true); works for wrapping!
    Using long pinned T4 on DIY breakout … Sketch starts with GraphicsTest {shorted delay()'s} - then instead of MediaButton loop() doing a 5 Serial# port pass through and doing a pin#15 toggle for FreqCnt, also the colorFade bar from SpeedTest.ino each data pass.
    > Adds tft lag and messes with timing so having to adjust and clean stuff up that 'passed okay before' - better now
    > And because lines can get shorter I do a fillRect() - after the string end - so some chars flash. Just shorted passed/printed Serial print text and got rid of that
    > magnifying glass is very handy - - way too needed

    But very nice to have FreqCnt print on display in one spot - not scroll by at one line of other text every 5ms … updated to 3ms and working with tft on 1 sec update when new FreqCnt.avail.

    Using lots of pins 10 for Serial#, 2 for FreqCnt,, 4 for tft ST7789, 3,3V, GND ... turned off anaologWrite() to #2 so pins 8 left +GND&5V.

    Got loop() cnt's to drop to about 127K with 2ms repeat - but only making 479 passes/sec with time slippage needed for limited tft updates.
    Got loop() cycles back up over 7Million by reducing the 3 pixel wide colorFade bar update rate
    T4 is amazing with USB output - checked the other day when PC was getting wacky with so much to display and stopping it from Teensy didn't speed up the Teensy loop() cnt.

    This is with reduced yield() calls 1/100 loops() - plus 5 last minute calls before showing what was received - the ~16 Serial# chars transfer in under 100us. Will let it run next few hours and put a note on T4_Beta thread

    Again tft ST7789 240x240 1.3" is very usable @KurtE
    Last edited by defragster; 07-28-2019 at 10:42 AM.

  8. #33
    Senior Member+ mjs513's Avatar
    Join Date
    Jul 2014
    Location
    New York
    Posts
    4,098
    @KurtE - knew you weren't to be able to resist not incorporating FB/Async . Maybe need to be a note in the example for the NO_CS pin tft.init - probably would have forgot that myself

    @defragster - nice you got everything running with the display - the 2" 240x320 is even nicer than the 1.3".

  9. #34
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    9,672
    Quote Originally Posted by mjs513 View Post
    @KurtE - knew you weren't to be able to resist not incorporating FB/Async . Maybe need to be a note in the example for the NO_CS pin tft.init - probably would have forgot that myself

    @defragster - nice you got everything running with the display - the 2" 240x320 is even nicer than the 1.3".
    Very nice KurtE got the code where it is! If only the KeDei had been as easy and rewarding when done.

    I saw the TAB_TYPE changed the Mode - but not to MODE2 - I recall seeing that go by - but not in context when I was figured even double + double checking the wires and other commented switches must be the problem.

    Yikes - higher resolution yet? I don't recall seeing that one - this one for $4 is worth finding my glasses or a magnifier - that one would take both. What was the link? An Adafruit? I'd like to find a similar OLED that would have outdoor viewability. Though this one with out the extra touch laminate layers will be better than those with them.

    ONE NOTE - this one is not feeling warm to touch at all - actually closer to room temp than body temp it feels cool and has been powered some time - unlike the KeDei that had the hot spot running from 5V. The color and contrast is good - not overblown with LED like the KeDei

    137 mA to power : DIY Breakout (LED etc), 1.3" TFT, and the T4 running the sketch - onboard LED #13 with 5 Serial#'s at 5Mbaud.

    What is the color depth? 2 bytes/pixel - 16 bit?

    Just opened lib folder - I see SPI speed at :: #define ST7735_SPICLOCK 24000000

    Bumping that to 48M dropped 400us off the 950 us update on the screen update with new 1 sec FreqCnt down to 566. Added another 30,000 loop() cycles/sec and pushed Serial# string transfers up a few as well with less time slippage on longer updates. Going to 64M made no added difference. Again - awesome to have perf/output numbers in a fixed screen location - not scrollingSPEW - and not really need SerMon at all. Looks like about 15 vertical lines of about 20 chars with tft.setTextSize(2)?

    Any reason not to have at least the T4 use :: #define ST7735_SPICLOCK 48000000 and 32M on most other T_3.x's? I have only tested on T4.


    This is something for the Beta T4 thread - a couple times after Upload USB Serial to TyComm has gone offline - with tft active and running? Quite possibly PC USB and TyComm tired of so much fast SPEW. Push Button Upload again and it comes back - anyone else seeing this? Using TyComm for SerMon as the IDE seemed Faulty - so Button to upload as I disabled TyComm upload to test PJRC stuff. Still had to restart the IDE as it was even failing on compile - with 9 sketches open and a bazillion recompiles.

    If multiple Serial# and TFT and FreqCnt seems like fun - here is the sketch:
    gt7789SerFrC.ino
    ~line 464 added spaces when smaller numbers display:
    Code:
    if ( gotFreqC ) {
    				tft.setCursor(10, 168);
    				tft.printf( "xus=%u  ",lastXfer - firstXfer );
    				tft.setCursor(120, 168);
    				tft.printf( "HZ:%u ", passHz );
    			}
    It is not pretty - two sketches in one - refined only to function, same notes as before when posted for Serial crossover and Array of Serial# pointer and 'ACTIVE_SER'.

  10. #35
    Senior Member+ KurtE's Avatar
    Join Date
    Jan 2014
    Posts
    5,414
    Quote Originally Posted by mjs513 View Post
    @KurtE - knew you weren't to be able to resist not incorporating FB/Async . Maybe need to be a note in the example for the NO_CS pin tft.init - probably would have forgot that myself

    @defragster - nice you got everything running with the display - the 2" 240x320 is even nicer than the 1.3".
    I pushed up an edit of the graphictest with some additional/modified comments. Tell me what you think.

    Yes could not resist But did not take much to do, it is using the same code as T3.5 does for SPI object. I remember 3.5 had DMA scatter/gather issues, which this one avoids, by outputting the display in a couple of dma operations, which interrupt between instead of trying to link DMA things... I don't remember if 3.2 had the same issue or not, but did have some of the issues, like losing the upper word of PUSHR register, so you have to hack CTAR0 to be 16 bit writes and you have to convert CS pin to be IO pin and not controlled by upper word....

    And on the examples side, I am thinking about cleaning up (a little) my ST7735_t3_multiple example (included if you wish to play)
    Which so far I have hooked up 2, but will try 3 (one on each buss) that run most of the graphic test areas without much delay between and use the Frame buffer and
    updateDisplayAsnych....ST7735_t3_multiple-190728a.zip

    Mainly need to cleanup the comments like the previous one...

  11. #36
    Senior Member+ mjs513's Avatar
    Join Date
    Jul 2014
    Location
    New York
    Posts
    4,098
    @KurtE

    I pushed up an edit of the graphictest with some additional/modified comments. Tell me what you think
    Just took a look and the changes look good for the different displays - a lot clearer.

    Have a bunch of errands to do but took a quick look at the attached sketch think the initialization process is going to get confusing for multiple displays. Anyway some of that can be moved to a library? For instance:
    Code:
    ST7735_t3 * tfts[] =
    {
    #if 0
    //  & tft,
      & tft1
    #else
      & tft
    
    #if SPI_INTERFACES_COUNT > 1
      , & tft1
    
    #if SPI_INTERFACES_COUNT > 2
      , & tft2
    #endif
    #endif
    #endif
    
    };
    
    uint8_t tft_which_test[] =
    {
      0, 0, 0
    };
    
    uint32_t last_test_start_time[] =
    {
      0, 0, 0
    };
    
    uint32_t next_test_start_time[] =
    {
      0, 0, 0
    };
    Other stuff as well but at least maybe you can start thinking about it. Promise I am going to play later - oh - looks like you can have different resolution displays as well.

  12. #37
    Senior Member+ KurtE's Avatar
    Join Date
    Jan 2014
    Posts
    5,414
    @mjs513 - Thanks,

    Note: I just pushed up a version of the multiples with lots more comments and the like, I probably need to retest the T4 stuff,
    But I just ran it on: T3.6 with two displays on it, plus T3.2 with one display, plus T-LC with two displays.

    In the case of T-LC it disables the Asynch support so each display updates as the other sits... But it at least gives examples of pins for both busses.

  13. #38
    Senior Member+ KurtE's Avatar
    Join Date
    Jan 2014
    Posts
    5,414
    Note: There is still at least one more display that we have not tried on it yet, and I know probably needs changes
    https://www.adafruit.com/product/3533 it is a .96" 160x80 display...

    Looks like I could order one from Mouser... (ordered)

  14. #39
    Senior Member+ mjs513's Avatar
    Join Date
    Jul 2014
    Location
    New York
    Posts
    4,098
    Think I will pass on that one - way too small for me Maybe....

  15. #40
    Senior Member+ KurtE's Avatar
    Join Date
    Jan 2014
    Posts
    5,414
    Quote Originally Posted by mjs513 View Post
    Think I will pass on that one - way too small for me Maybe....
    Probably me too, BUT

    a) Need to integrate the init code differences in and have a way to test...

    b) I am thinking maybe on my T4 Robot controller board, maybe add a connector that has the pinout of several of these smaller displays, and I can maybe choose to have one on board... For a lot of these projects having a small display that maybe just shows a few things, maybe just right. Could run these off of the SDCARD connection of T4, and have both the display and use their SD card.

    Maybe might also have alternative connections for CS challenged displays...

    Just a thoughts now... More likely they well end up in my display and sensors box

    EDIT: I did the edits to hopefully allow these smaller displays to work. Displays should arrive Wed, will probably pick up Thursday.

    May check in before then if someone else wishes to test it out.
    Last edited by KurtE; 07-28-2019 at 06:58 PM.

  16. #41
    Senior Member+ mjs513's Avatar
    Join Date
    Jul 2014
    Location
    New York
    Posts
    4,098
    @KurtE

    First - I downloaded your latest lib and ran the multiple sensor sketch with the 7789 240x320 on SPI and the 240x240 on SPI.

    First pass the 240x320 only used about the first rows of pixels but the 240x240 worked fine - I did do a setrotation(2) on the 240x240 since it has different rotation than the 320 display.

    Second pass I disabled the framebuffer and the 240x320 came to life and displayed whole screen no problem and yes the 240x240 display worked as well. Looks like there may be a problem with the framebuffer for the 240x320 ST7789 display.

    Now back to errands.

    No comment on the robot controller board = you are going to get me distracted

  17. #42
    Senior Member+ KurtE's Avatar
    Join Date
    Jan 2014
    Posts
    5,414
    @mjs513 - Which Teensy did you test to 320x240 on for the Async?

    You might try the the simple test that I have setup to try FB...st7735_t3_simpletest_FB-190728a.zip

    It is setup to be able to try different SPI busses like the other...

    If you hit <CR> it will do cycle through the rotations.

    but: the interesting test is to see if Asynch works:
    a<cr>

    Which should show same screen but different background color.

    Also then:
    c<cr> goes through several screens async...

    As for distractions :lol:

    Edit: I am pretty sure I know what is going on... 320x240x2=153600/2=76800 > 64K
    as I am currently setup for chaining two DMA transfers, so need to in this case have 3 dmaSettings...

    But time to enjoy Sunday Brunch and ...

  18. #43
    Senior Member+ mjs513's Avatar
    Join Date
    Jul 2014
    Location
    New York
    Posts
    4,098
    @KurtE

    Sorry - just got a chance to get back to this. I am using the T4B2 board

    Ok - first tried the sketch on the 240x240 display on SPI1 and it worked as you described. Hit 'a' got a yellow background, hit 'c' screen background goes through a couple of screen color backgrounds.

    Now, the bad news for the 240x320 when I hit 'a' I it only shows yellow on the top few rows of the display - maybe 240x4. When I hit 'c' it draws red-yellow-blue bars at the bottom of the screen (looks like 240x80).

    Edit - just saw your edit - hope you are enjoying your Sunday. Nice lazy day here as well

  19. #44
    Senior Member+ KurtE's Avatar
    Join Date
    Jan 2014
    Posts
    5,414
    Yep - enjoyed nice fresh home made pasta in cold salad, nice bottle of wine ...

    Just pushed up change that hopefully fixes DMA for 240x320 display. Would be great if you by chance could test it on a few displays/boards.

    Like on T4 and 3.6.... If really brave try out on 3.5, maybe on both SPI and SPI1 or 2... But that is only if you are brave

    I tried a few things on T4, T3.6 3.2 and LC ... on this round

  20. #45
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    9,672
    Got the 'AM' new ST7789 lib - works the same - only have the 1.3" 240x240 - so testing it with 'normal' user code and seeing it work properly and well - only on T4 - except the NICE localized 'Spew in a Spot' prints seem attractive - but really take time.

    Seems I need new github zip and to start the ASYNC code up to test that and have less overhead.

    doing :: #define ST7735_SPICLOCK 48000000
    and :: #define DISABLE_ST77XX_FRAMEBUFFER

    Faster SPI clock looks good and significantly faster.

    I do have a second st7789 - and two POGO pins - what do I need for that beside pins #26/MOSI1 and #27/SCK1 ?
    LIKE THIS ? >> ST7789_t3 tft2 = ST7789_t3(TFT_CS==-1, TFT_DC==3, TFT_MOSI==26, TFT_SCLK==27, TFT_RST==4);
    > This DIY with T4 has no SDIO pins connected

    Robot Base board with Display: That is what I noted the other day for mjs513 - put i2c pins for a simple OLED - one of these in color same cost and not much bigger though 4 not 2 pins - either would be handy for feedback. Got that free Azure Sphere board and it has i2c pins for such a display - though GND/VCC swapped from my older units - ordered new that have it in the 'i2c grove Order' also used on the TinyPICO shield.

  21. #46
    Senior Member+ mjs513's Avatar
    Join Date
    Jul 2014
    Location
    New York
    Posts
    4,098
    Cool glad you enjoyed the pasta - haven't made homemade pasta in years

    Any on T4 still not working same behavior as before for the 240x320

    On T3.5 even worse - yes I am a glutton for punishment:
    1. DELETED. See edit
    2. 240x320 - only tried it on SPI. Rotation works but nothing for asynch or framebuffer.

    EDIT: My bad forgot to change the pin number for DC on the 240x240 for SPI1. Just retested and works fine on SPI1 = deleted note 1.

  22. #47
    Senior Member+ KurtE's Avatar
    Join Date
    Jan 2014
    Posts
    5,414
    Darn!

    You might try turning on the debug printing:
    near the top of st7735_t3.cpp is the line: //#define DEBUG_ASYNC_UPDATE

    (uncomment and it should print out the generated dma setting structures, which might give me some clues, especially on T4 and 3.6...

    I did not change anything with 3.5, as I thought it might handle it... There is also two completely different sets of code on 3.5 for SPI and SPI1/2...

    Also I think I screwed up: st7735_t3.cpp line 1367: if (COUNT_WORDS_WRITE >= 65536) {
    change 65536 to 32768


    On T3.5 next thing I would probably try is to edit the line in header st7735_t3 about line 401, the T3.2 has a copy of this, which probably need to worry about as it does not have enough memory for these displays anyway...

    and change: uint16_t _dma_count_remaining;

    to uint32_t and see if that helps.

  23. #48
    Senior Member+ mjs513's Avatar
    Join Date
    Jul 2014
    Location
    New York
    Posts
    4,098
    Morning @Kurte

    Made the changes you suggested in previous post.

    On the T4 Async seems to now work no issue. See below. After I hit 'a' you can see the dump below. I then did screen rotation to make sure it still was working and then I hit 'c' for framebuffer, while it worked to change the screen colors the sketch froze after it completed, i.e., screen rotation no longer worked.

    Code:
    hello!CS:10 DC:9 MOSI:11 SCLK:13 RST:8
    ST7789_t3::init mode: 0
    init CS:10 DC:9 MOSI:11 SCLK:13 RST:8
     Row Start:0  Col Start: 0
    Set Rotation: 0 width: 240 height: 320
    Hit any key to continue
    20002400 400e9020:SA:20200020 SO:2 AT:101 NB:2 SL:-51200 DA:403a0064 DO: 0 CI:6400 DL:200023a0 CS:10 BI:6400
    20002340 20002360:SA:20200020 SO:2 AT:101 NB:2 SL:-51200 DA:403a0064 DO: 0 CI:6400 DL:200023a0 CS:10 BI:6400
    20002380 200023a0:SA:2020c820 SO:2 AT:101 NB:2 SL:-51200 DA:403a0064 DO: 0 CI:6400 DL:200023e0 CS:10 BI:6400
    200023c0 200023e0:SA:20219020 SO:2 AT:101 NB:2 SL:-51200 DA:403a0064 DO: 0 CI:6400 DL:20002360 CS:1a BI:6400
    After Async Update
    Async completed 69
    Set Rotation: 1 width: 320 height: 240
    Hit any key to continue
    Set Rotation: 2 width: 240 height: 320
    Hit any key to continue
    Set Rotation: 3 width: 320 height: 240
    Hit any key to continue
    Set Rotation: 0 width: 240 height: 320
    Hit any key to continue
    Start Continuous update test
    20002400 400e9020:SA:20200020 SO:2 AT:101 NB:2 SL:-51200 DA:403a0064 DO: 0 CI:6400 DL:200023a0 CS:10 BI:6400
    20002340 20002360:SA:20200020 SO:2 AT:101 NB:2 SL:-51200 DA:403a0064 DO: 0 CI:6400 DL:200023a0 CS:10 BI:6400
    20002380 200023a0:SA:2020c820 SO:2 AT:101 NB:2 SL:-51200 DA:403a0064 DO: 0 CI:6400 DL:200023e0 CS:10 BI:6400
    200023c0 200023e0:SA:20219020 SO:2 AT:101 NB:2 SL:-51200 DA:403a0064 DO: 0 CI:6400 DL:20002360 CS:12 BI:6400
    After updateScreenAsync
    Finished all frames
    After call to endUpdateAsync
    Ok, now on to a T3.5. Good news - it works perfectly.
    Code:
    DMA dump TX:0 RX:1
    1fff12b0 40009000:SA:1fff1762 SO:2 AT:101 NB:2 SL:0 DA:4002c034 DO: 0 CI:63ff DL:0 CS:8 BI:63ff
    1fff12b8 40009020:SA:4002c038 SO:0 AT:101 NB:2 SL:0 DA:1fff12d8 DO: 0 CI:6400 DL:0 CS:a BI:6400
    After Async Update
    Async completed 67
    Set Rotation: 3 width: 320 height: 240
    Hit any key to continue
    Start Continuous update test
    DMA dump TX:0 RX:1
    1fff12b0 40009000:SA:1fff1762 SO:2 AT:101 NB:2 SL:0 DA:4002c034 DO: 0 CI:63ff DL:0 CS:8 BI:63ff
    1fff12b8 40009020:SA:4002c038 SO:0 AT:101 NB:2 SL:0 DA:1fff12d8 DO: 0 CI:6400 DL:0 CS:a BI:6400
    After updateScreenAsync
    Frame count: 7
    Finished all frames
    After call to endUpdateAsync
    Test completed
    The T3.6 does exactly the same thing as the T4. Async works but after executing framebuffer with 'c' the sketch freezes:
    Code:
    hello!CS:10 DC:9 MOSI:11 SCLK:13 RST:8
    ST7789_t3::init mode: 0
    init CS:10 DC:9 MOSI:11 SCLK:13 RST:8
     Row Start:0  Col Start: 0
    Set Rotation: 0 width: 240 height: 320
    Hit any key to continue
    DMA dump TCDs 1
    1fff1400 40009020:SA:1fff18c2 SO:2 AT:101 NB:2 SL:-51198 DA:4002c034 DO: 0 CI:63ff DL:1fff1360 CS:10 BI:63ff
    1fff1300 1fff1320:SA:1fff18c2 SO:2 AT:101 NB:2 SL:-51198 DA:4002c034 DO: 0 CI:63ff DL:1fff1360 CS:10 BI:63ff
    1fff1340 1fff1360:SA:1fffe0c0 SO:2 AT:101 NB:2 SL:-51200 DA:4002c034 DO: 0 CI:6400 DL:1fff13a0 CS:10 BI:6400
    1fff1380 1fff13a0:SA:2000a8c0 SO:2 AT:101 NB:2 SL:-51200 DA:4002c034 DO: 0 CI:6400 DL:1fff1320 CS:1a BI:6400
    1fff13c0 1fff13e0:SA:1fff18c0 SO:2 AT:101 NB:2 SL:-2 DA:4002c034 DO: 0 CI:1 DL:1fff1320 CS:10 BI:1
    After Async Update
    Async completed 67
    Set Rotation: 1 width: 320 height: 240
    Hit any key to continue
    Set Rotation: 2 width: 240 height: 320
    Hit any key to continue
    Set Rotation: 3 width: 320 height: 240
    Hit any key to continue
    Set Rotation: 0 width: 240 height: 320
    Hit any key to continue
    Start Continuous update test
    DMA dump TCDs 1
    1fff1400 40009020:SA:1fff18c2 SO:2 AT:101 NB:2 SL:-51198 DA:4002c034 DO: 0 CI:63ff DL:1fff1360 CS:90 BI:63ff
    1fff1300 1fff1320:SA:1fff18c2 SO:2 AT:101 NB:2 SL:-51198 DA:4002c034 DO: 0 CI:63ff DL:1fff1360 CS:10 BI:63ff
    1fff1340 1fff1360:SA:1fffe0c0 SO:2 AT:101 NB:2 SL:-51200 DA:4002c034 DO: 0 CI:6400 DL:1fff13a0 CS:10 BI:6400
    1fff1380 1fff13a0:SA:2000a8c0 SO:2 AT:101 NB:2 SL:-51200 DA:4002c034 DO: 0 CI:6400 DL:1fff13e0 CS:10 BI:6400
    1fff13c0 1fff13e0:SA:1fff18c0 SO:2 AT:101 NB:2 SL:-2 DA:4002c034 DO: 0 CI:1 DL:1fff1320 CS:12 BI:1
    After updateScreenAsync
    Frame count: 7
    Finished all frames
    After call to endUpdateAsync

  24. #49
    Senior Member+ KurtE's Avatar
    Join Date
    Jan 2014
    Posts
    5,414
    @mjs513 - Thanks,

    The information says that the main DMA stuff was working, but that I forgot to update the endUpdateAsync function, that the item in the chain that needed to be disabled, may be different.

    Which I now updated to:
    Code:
    void ST7735_t3::endUpdateAsync() {
    	// make sure it is on
    	#ifdef ENABLE_ST77XX_FRAMEBUFFER
    	if (_dma_state & ST77XX_DMA_CONT) {
    		_dma_state &= ~ST77XX_DMA_CONT; // Turn of the continueous mode
    #if defined(__MK66FX1M0__) 
    		_dmasettings[_cnt_dma_settings].disableOnCompletion();
    #elif defined(__IMXRT1052__) || defined(__IMXRT1062__)  // Teensy 4.x
    		_dmasettings[_cnt_dma_settings-1].disableOnCompletion();
    #endif
    	}
    	#endif
    }
    I pushed these change up to github, now to keep fingers crossed

  25. #50
    Senior Member+ mjs513's Avatar
    Join Date
    Jul 2014
    Location
    New York
    Posts
    4,098
    @KurtE

    Glad it was a simple fix. I just tested on a T3.6 and the T4. Got some good news and some minor bad news.

    The good news is that it works, asynch and framebuffer on both boards.

    The bad news is on the T4. On the T3.6 framebuffer shows a nice smooth transition between changing the screen colors. However, on the T4 when the screen updates there are blotches of the previous color on the screen as the screen updates but they go away once update is complete.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •