Forum Rule: Always post complete source code & details to reproduce any issue!
Page 135 of 174 FirstFirst ... 35 85 125 133 134 135 136 137 145 ... LastLast
Results 3,351 to 3,375 of 4350

Thread: Teensy 4.0 First Beta Test

  1. #3351
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    9,959
    Did a quick shifting of the back side to suggest. Red Boxes were just to make them stand out for grouping as an addition - black would be right perhaps - with a single arrow to the general area {only 2 of 3 shown}.

    Click image for larger version. 

Name:	t4_BackRev.png 
Views:	25 
Size:	239.8 KB 
ID:	16823

    Also shifted the USB Host and SDIO for locality of reference - need to make sure the USB Host D- / D+ are understood as not device USB pins like prior Teensy models.

    As noted before the Front of the T4 card might benefit from having 'Teensy 4.0 pins are 3.3V only' - where the note about interrupt capability is shown
    Last edited by defragster; 06-20-2019 at 05:58 PM.

  2. #3352
    Senior Member
    Join Date
    Jul 2014
    Posts
    2,366

    USBHost - USB Device

    Q. can the USB Host pads (D+ D-) that are at location of Old USB Device pad also be used vor USB device mode?
    Can a T4 have two USB device ports (one for programming and standard USB activity and one dedicated for own application)?

  3. #3353
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    9,959
    Quote Originally Posted by PaulStoffregen View Post


    Quote Originally Posted by Frank B View Post
    Which signals are on the round testpads between 24-33?
    Here's info on all the other test points....

    ...
    Maybe that's more than anyone might ever want to know about the test procedure, but hopefully it shines some light on why there are so many test points. This iMXRT chip has several power supply voltages. All need to be checked, and the tester needs to be able to fully discharge every capacitor so each individual power up test begins with the T4 fully off.

    ...
    Very cool insight - nice share … how long does a test cycle take?

    That is followed by the usual PJRC 'plug in USB cable' Blink test? When is the Blink sketch loaded? Is a button press done at that point to visually see the 'Bootloader Red' LED function before unplugging?

  4. #3354
    Senior Member+ mjs513's Avatar
    Join Date
    Jul 2014
    Location
    New York
    Posts
    4,213
    Quote Originally Posted by KurtE View Post
    Adafruit_gfx, adafruit_ili9341, adafruit_st7735 and st7735_t3

    None of these compile on T4...

    I did some changes to Adafruit_gfx - https://github.com/KurtE/Adafruit-GF...y/tree/T4_Beta

    That I was able to build and run graphicstest example app on T4 using PJRC ILI9341 display using pins (CS=10, DC=9, reset=23)

    I also was able to get graphicstest example to work on ST7735 SPI display with adafruit_st7735... library.

    Still working on ST7735_t3 as more 32 bit registers... And likewise SPI data different...

    Anyway if anyone wises to try it out before I try issuing a PR to Adafruit that would be great.
    Hi Kurt
    Just gave your changes a try with the T4. Ran graphicstest as you did and worked no problem. Ran a version, for just drawpixels using my budhabrot example and it ran as well no problems.

  5. #3355
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    9,959
    Quote Originally Posted by KurtE View Post
    Adafruit_gfx, adafruit_ili9341, adafruit_st7735 and st7735_t3

    None of these compile on T4...

    I did some changes to Adafruit_gfx - https://github.com/KurtE/Adafruit-GF...y/tree/T4_Beta

    That I was able to build and run graphicstest example app on T4 using PJRC ILI9341 display using pins (CS=10, DC=9, reset=23)

    I also was able to get graphicstest example to work on ST7735 SPI display with adafruit_st7735... library.

    Still working on ST7735_t3 as more 32 bit registers... And likewise SPI data different...

    Anyway if anyone wises to try it out before I try issuing a PR to Adafruit that would be great.
    @KurtE - It works on ili9341.

    I had to grab :: github.com/adafruit/Adafruit_ILI9341

    Using the mock_ili9341 example in the GFX lib it is running with T4 on the PJRC Purple OSH test board.

    Only verbose console warning is:
    In file included from T:\tCode\libraries\Adafruit_GFX\Adafruit_GFX.cpp:3 5:0:

    T:\tCode\libraries\Adafruit_GFX\glcdfont.c:13:0: warning: "PROGMEM" redefined
    #define PROGMEM
    ^

    In file included from T:\Ard186t4b2\hardware\teensy\avr\cores\teensy4/WProgram.h:41:0,
    from T:\TEMP\arduino_build_882294/pch/Arduino.h:6,
    from T:\tCode\libraries\Adafruit_GFX\Adafruit_GFX.h:5,
    from T:\tCode\libraries\Adafruit_GFX\Adafruit_GFX.cpp:3 4:

    T:\Ard186t4b2\hardware\teensy\avr\cores\teensy4/avr/pgmspace.h:28:0: note: this is the location of the previous definition
    #define PROGMEM __attribute__((section(".progmem")))
    ^
    And libs used:
    Multiple libraries were found for "Adafruit_GFX.h"
    Used: T:\tCode\libraries\Adafruit_GFX
    Not used: T:\Ard186t4b2\hardware\teensy\avr\libraries\Adafru it_GFX
    Using library SPI at version 1.0 in folder: T:\Ard186t4b2\hardware\teensy\avr\libraries\SPI
    Using library Adafruit_GFX at version 1.5.5 in folder: T:\tCode\libraries\Adafruit_GFX
    Using library Adafruit_ILI9341 at version 1.5.0 in folder: T:\tCode\libraries\Adafruit_ILI9341
    "T:\\Ard186t4b2\\hardware\\teensy/../tools/arm/bin/arm-none-eabi-size" -A "T:\\TEMP\\arduino_build_296803/mock_ili9341.ino.elf"
    Sketch uses 32448 bytes (1%) of program storage space. Maximum is 2031616 bytes.
    Global variables use 37632 bytes (3%) of dynamic memory, leaving 1010944 bytes for local variables. Maximum is 1048576 bytes.
    Also the Adafruit Touchpaint : T:\tCode\libraries\Adafruit_ILI9341\examples\touch paint
    Works with a quick hack of to replace this - though touch map is rotated 90 degrees when tested - the display works:
    //#include <Adafruit_STMPE610.h>
    #include <XPT2046_Touchscreen.h>

  6. #3356
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    20,684
    Quote Originally Posted by defragster View Post
    Did a quick shifting of the back side to suggest.
    The red boxes are a really interesting idea. But the card really needs to go into printing, at least for the first batch... so I'm really not looking to make much change to the formatting right now. At this point I'm mainly looking to verify the info.

    Another rev of the card definitely will be made shortly after the T4 release, since the first batch will be using photos of a beta board.


    Quote Originally Posted by WMXZ View Post
    Q. can the USB Host pads (D+ D-) that are at location of Old USB Device pad also be used vor USB device mode?
    Can a T4 have two USB device ports (one for programming and standard USB activity and one dedicated for own application)?
    Good question. I have not tried this, so I really can't say for sure. One of the chip errata is about power management when both ports are in device mode. That may or may not be an issue, because we're not breaking out the 2 power pins separately.

    Other that the errata, everything in the reference manual seems to say this should be possible. If you or anyone else really wanted to try, my understanding is it should mostly be a matter of making a copy of usb.c & usb_serial.c and just change all the register names for the other USB controller and USB PHY.



    Quote Originally Posted by defragster View Post
    Very cool insight - nice share how long does a test cycle take?
    About 650 ms, plus a 75 ms "debounce" time from the moment the board is electrically seen on the shorter pogo pins.


    That is followed by the usual PJRC 'plug in USB cable' Blink test? When is the Blink sketch loaded? Is a button press done at that point to visually see the 'Bootloader Red' LED function before unplugging?
    Yup, every board will still get the 2nd test, which checks the pushbutton and USB connector and LEDs, and gives one final visual inspection.

  7. #3357
    Senior Member+ Frank B's Avatar
    Join Date
    Apr 2014
    Location
    Germany NRW
    Posts
    5,679
    For me, the descriptions on the card look good - would be good if the others take a look, too

  8. #3358
    Senior Member+ KurtE's Avatar
    Join Date
    Jan 2014
    Posts
    5,578
    @Paul - Things for the good explanation of all of those other test points... Plus how the boards are tested.

    The Card - Looks good enough to me. I like @defragsters comments but, I would not hold up shipping to spend more time yet.

    @defragster and @Paul plus @all - With Adafruit and GFX and the warning about PROGMEM.

    Not sure of the right fix for the message:
    '
    In file included from T:\tCode\libraries\Adafruit_GFX\Adafruit_GFX.cpp:3 5:0:

    T:\tCode\libraries\Adafruit_GFX\glcdfont.c:13:0: warning: "PROGMEM" redefined
    #define PROGMEM
    ^

    In file included from T:\Ard186t4b2\hardware\teensy\avr\cores\teensy4/WProgram.h:41:0,
    from T:\TEMP\arduino_build_882294/pch/Arduino.h:6,
    from T:\tCode\libraries\Adafruit_GFX\Adafruit_GFX.h:5,
    from T:\tCode\libraries\Adafruit_GFX\Adafruit_GFX.cpp:3 4:

    T:\Ard186t4b2\hardware\teensy\avr\cores\teensy4/avr/pgmspace.h:28:0: note: this is the location of the previous definition
    #define PROGMEM __attribute__((section(".progmem")))
    ^
    First pass was to edit glcdfont.c to not define it in the case of T4:
    Like:
    Code:
    #ifndef FONT5X7_H
    #define FONT5X7_H
    
    #ifdef __AVR__
     #include <avr/io.h>
     #include <avr/pgmspace.h>
    #elif defined(ESP8266)
     #include <pgmspace.h>
    #elif defined(__IMXRT1052__) || defined(__IMXRT1062__)
    // PROGMEM is defefind for T4 to place data in specific memory section
    #else
     #define PROGMEM
    #endif
    
    // Standard ASCII 5x7 font
    
    static const unsigned char font[] PROGMEM = {
    But that gives a compiler error:
    Code:
    C:\Users\kurte\Documents\Arduino\libraries\Adafruit_GFX_Library\glcdfont.c:20:35: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'PROGMEM'
    
     static const unsigned char font[] PROGMEM = {
    
                                       ^
    Obviously I can rid myself of both warning and error like:
    Code:
    #ifdef __AVR__
     #include <avr/io.h>
     #include <avr/pgmspace.h>
    #elif defined(ESP8266)
     #include <pgmspace.h>
    #elif defined(__IMXRT1052__) || defined(__IMXRT1062__)
    // PROGMEM is defefind for T4 to place data in specific memory section
     #undef PROGMEM
     #define PROGMEM
    #else
     #define PROGMEM
    #endif
    But is that what we expect?

    @all Hacked up version (first pass) of ST7735_t3 library that compiles and works with my Adafruit_GFX changes mentioned earlier.

    So far only pass 1, where I use SPI.transfer() to do the transfers... Also I don't yet have code in to handle putting the display on NON SPI (MOSI, SCLK) pins.
    I did however make it work on SPI2 (and probably SPI1, not setup to test yet)...

    Will probably do another pass to make use of the T4's SPI FIFO queues. Maybe does not help as much as T3.x where we can encode DC, CS data, but still may help some...
    Current version up at: https://github.com/KurtE/ST7735_t3/tree/T4_beta

  9. #3359
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    9,959
    Quote Originally Posted by PaulStoffregen View Post
    The red boxes are a really interesting idea. But the card really needs to go into printing, at least for the first batch... so I'm really not looking to make much change to the formatting right now. At this point I'm mainly looking to verify the info.

    Another rev of the card definitely will be made shortly after the T4 release, since the first batch will be using photos of a beta board.
    Indeed the boxes seemed like a good way to contain and group them to make sense of the otherwise disassociated field of 'color blob splatter' and then a single arrow to the proper pin array is meaningful and not messy.

    ...
    About 650 ms, plus a 75 ms "debounce" time from the moment the board is electrically seen on the shorter pogo pins.
    It must take longer than that to pick up the board and get it placed and secured

    Yup, every board will still get the 2nd test, which checks the pushbutton and USB connector and LEDs, and gives one final visual inspection.
    Cool.
    Does that 2nd test load Blink - or is that pushed in on the 1st test?

    @KurtE: I had a 'touchpaint_xpt2046.ino' open and changed:
    //#include <ILI9341_t3.h>
    #include <Adafruit_ILI9341.h>
    And the <Adafruit_ILI9341.h> works - unlike the <ILI9341_t3.h>
    Using library XPT2046_Touchscreen at version 1.3 in folder: T:\Ard186t4b2\hardware\teensy\avr\libraries\XPT2046_Touchscreen
    Using library SPI at version 1.0 in folder: T:\Ard186t4b2\hardware\teensy\avr\libraries\SPI
    Using library Adafruit_ILI9341 at version 1.5.0 in folder: T:\tCode\libraries\Adafruit_ILI9341
    Using library Adafruit_GFX at version 1.5.5 in folder: T:\tCode\libraries\Adafruit_GFX

  10. #3360
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    20,684
    I've added the card image to msg #3.


    Quote Originally Posted by defragster View Post
    It must take longer than that to pick up the board and get it placed and secured
    Yup. Also takes time to get it into the anti-static bag, and the get groups of 25 of those into the larger bags, and go through a process we use to double check the counting of boards at the beginning and end of each work session. It's been a while since we've looked at the total time, but previous it was running about 45 seconds per Teensy. About 2 of those 45 seconds are the actual electrical tests.


    Does that 2nd test load Blink - or is that pushed in on the 1st test?
    LED blink is always loaded in the 2nd test, with an actual USB cable.

  11. #3361
    Senior Member
    Join Date
    Oct 2015
    Location
    Roma (IT, EU)
    Posts
    193
    Just returned from a trip to found the T4 Beta-3 (?) board waiting for me!
    It's a work of art!
    Have to catch up with delayed work, but can't wait to play with the little beast!!!
    Thanks Paul!

  12. #3362
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    9,959
    Msg #3 Card image looks good - the tan for USB Host is nice.

    Using as Ref 'posted text' for 1062 in MSG#3 :: I did a quick scan - Serial pin #'s line up, and the 3 i2c's, and SPI & CAN pins. I suppose the two AUDIO pins on back were not called out due to space limits?

    Did a B&W Laser print of card - all is readable - assume those with limited color vision will get a usable color here or there as needed.

    In MSG#3 the posted text for rear pins has #24 and #26 swapped in the pin order - assuming the card with proper numeric order matches the code linkage.


    The 'Printed' anti-static bag Teensy 4.0 IMXRT1062 Chip from Beta 2 Mod delivery looks very nice! Those A-S bags are no fun to open

    Very cool that the 1st TEST can program the raw bootloader chips. Wanted to assume the USB cable 2nd Test did Blink as final test, but wasn't sure.

  13. #3363
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    20,684
    Quote Originally Posted by defragster View Post
    I suppose the two AUDIO pins on back were not called out due to space limits?
    Which 2 pins?

    Pins 32 and 33 are shown with "OUT1B and MCLK2" with yellow background.


    In MSG#3 the posted text for rear pins has #24 and #26 swapped in the pin order
    I believe that was the (weird) order of the early 1052 boards. Looks like msg #3 hasn't been updated since. Truth is I just randomly connected the 10 remaining pins to those pads at the last minute, even before the decision was made which would be pin 24, 25, etc. Just getting the board routed in only 4 layers and extra size was the main focus, so we could begin the beta test with something.

    The order printed on the final PCB and the card definitely is correct.

  14. #3364
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    9,959
    Quote Originally Posted by PaulStoffregen View Post
    Which 2 pins?

    Pins 32 and 33 are shown with "OUT1B and MCLK2" with yellow background.

    I believe that was the (weird) order of the early 1052 boards. Looks like msg #3 hasn't been updated since. Truth is I just randomly connected the 10 remaining pins to those pads at the last minute, even before the decision was made which would be pin 24, 25, etc. Just getting the board routed in only 4 layers and extra size was the main focus, so we could begin the beta test with something.

    The order printed on the final PCB and the card definitely is correct.
    What I saw was here - Audio on #26 and #27 - whatever they mean or do those TX's aren't on card:
    Code:
    Bottom:
    ---    ----       ----  ------    ---  ---     ---      ---   ----       ----    ------  ------
    Pin    Name       GPIO  Serial    I2C  SPI     PWM      CAN   Audio      XBAR    FlexIO  Analog
    ---    ----       ----  ------    ---  ---     ---      ---   ----       ----    ------  ------
    24/A10 AD_B0_12   1.12  UART1_TX  4_SCL        PWM1_X2                                   A1:1  
    25/A11 AD_B0_13   1.13  UART1_RX  4_SDA        PWM1_X3,GPT1_CLK                          A1:2
    26/A12 AD_B1_14   1.30                 3:MOSI                 1:TX_BCLK          3:14    A2:3  
    27/A13 AD_B1_15   1.31                 3:SCK                  1:TX_SYNC          3:15    A2:4  
    28     EMC_32     3.18  UART7_RX               PWM3_B1
    29     EMC_31     4.31  UART7_TX       1:cs1   PWM3_A1
    30     EMC_37     3.23                         GPT1_3   3_RX  3:MCLK     I-23
    31     EMC_36     3.22                         GPT1_2   3_TX  3:TX_DATA  I-22
    32     B0_12      2.12                                        1:TX1_RX3  IO-10   2:12
    33     EMC_07     4.7                          PWM2_B0        2:MCLK     IO-09   1:7

  15. #3365
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    20,684
    Oh, now I see. Yeah, I decided not to show those on the card, mainly because we don't have BCLK3 and LRCLK3.

  16. #3366
    Senior Member
    Join Date
    Jul 2014
    Posts
    2,366
    On dual USB device:
    Quote Originally Posted by PaulStoffregen View Post
    Good question. I have not tried this, so I really can't say for sure. One of the chip errata is about power management when both ports are in device mode. That may or may not be an issue, because we're not breaking out the 2 power pins separately.
    As I only use the data lines from USB- device, I will try that.

  17. #3367
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    20,684
    Also on my long list of stuff to eventually do is a library to implement USB device on Teensy 3.6's 2nd USB port. If running both ports on T4 in device mode works, would make sense for that library to do both.

  18. #3368
    Senior Member+ KurtE's Avatar
    Join Date
    Jan 2014
    Posts
    5,578
    st7735_t3 library update

    As I mentioned yesterday, I needed to first update Arduino GFX code, to compile on Teensy. Still not sure yet what is best/intended way to use PROGMEM on T4 with existing code... More in #3358.

    Yesterday first pass got the T4 to work with the library, however it was using SPI.transfer calls...

    I updated the graphic test program to get a better idea of the timings...

    So, setup looks like:
    Code:
    ST7735_t3 tft = ST7735_t3(TFT_CS, TFT_DC, TFT_MOSI, TFT_SCLK, TFT_RST);
    
    // Option 2: must use the hardware SPI pins
    // (for UNO thats sclk = 13 and sid = 11) and pin 10 must be
    // an output. This is much faster - also required if you want
    // to use the microSD card (see the image drawing example)
    //ST7735_t3 tft = ST7735_t3(cs, dc, rst);
    float p = 3.1415926;
    
    
    void setup(void) {
      elapsedMillis timer;
      pinMode(SD_CS, INPUT_PULLUP);  // don't touch the SD card
      Serial.begin(9600);
      Serial.print("hello!");
    
      // Use this initializer if you're using a 1.8" TFT
      tft.initR(INITR_BLACKTAB);
      // Use this initializer (uncomment) if you're using a 1.44" TFT
      //tft.initR(INITR_144GREENTAB);
    
      Serial.println("init");
    
      uint16_t time = millis();
      tft.fillScreen(ST7735_BLACK);
      time = millis() - time;
    
      Serial.println(time, DEC);
      delay(500);
    
      // large block of text
      tft.fillScreen(ST7735_BLACK);
      Serial.println("After fill screen");
      testdrawtext("Lorem ipsum dolor sit amet, consectetur adipiscing elit. Curabitur adipiscing ante sed nibh tincidunt feugiat. Maecenas enim massa, fringilla sed malesuada et, malesuada sit amet turpis. Sed porttitor neque ut ante pretium vitae malesuada nunc bibendum. Nullam aliquet ultrices massa eu hendrerit. Ut sed nisi lorem. In vestibulum purus a tortor imperdiet posuere. ", ST7735_WHITE);
      Serial.println("After test draw text");
      delay(1000);
    
      // tft print function!
      timer = 0;
      tftPrintTest();
      Serial.printf("tftPrintTest: %d\n", (int)timer);
      delay(4000);
    
      // a single pixel
      tft.drawPixel(tft.width() / 2, tft.height() / 2, ST7735_GREEN);
      delay(500);
    
      // line draw test
      timer = 0;
      testlines(ST7735_YELLOW);
      Serial.printf("testlines: %d\n", (int)timer);
      delay(500);
    
      // optimized lines
      timer = 0;
      testfastlines(ST7735_RED, ST7735_BLUE);
      Serial.printf("tftPrintTest: %d\n", (int)timer);
      delay(500);
    
      timer = 0;
      testdrawrects(ST7735_GREEN);
      Serial.printf("tftPrintTest: %d\n", (int)timer);
      delay(500);
    
      timer = 0;
      testfillrects(ST7735_YELLOW, ST7735_MAGENTA);
      Serial.printf("tftPrintTest: %d\n", (int)timer);
      delay(500);
    
      timer = 0;
      tft.fillScreen(ST7735_BLACK);
      testfillcircles(10, ST7735_BLUE);
      testdrawcircles(10, ST7735_WHITE);
      Serial.printf("tftPrintTest: %d\n", (int)timer);
      delay(500);
    
      timer = 0;
      testroundrects();
      Serial.printf("testroundrects: %d\n", (int)timer);
      delay(500);
    
      timer = 0;
      testtriangles();
      Serial.printf("testtriangles: %d\n", (int)timer);
      delay(500);
    
      timer = 0;
      mediabuttons();
      Serial.printf("mediabuttons: %d\n", (int)timer);
      delay(500);
    
      Serial.println("done");
      delay(1000);
    }
    Note: I have the code to handle SPI, SPI1 (not tested yet), SP2, on T4. The initial timings were pretty slow: (this is on SPI2)
    Code:
    hello!init
    89
    After fill screen
    After test draw text
    tftPrintTest: 1725
    testlines: 1150
    tftPrintTest: 127
    tftPrintTest: 115
    tftPrintTest: 650
    tftPrintTest: 273
    testroundrects: 312
    testtriangles: 185
    mediabuttons: 1213
    done
    As compared to T3.6
    Code:
    hello!init
    23
    After fill screen
    After test draw text
    tftPrintTest: 1559
    testlines: 300
    tftPrintTest: 33
    tftPrintTest: 30
    tftPrintTest: 169
    tftPrintTest: 71
    testroundrects: 81
    testtriangles: 49
    mediabuttons: 1092
    done
    So today I hacked on it some more. I took some of the stuff from the PR request for ILI9341_t3, and now use the SPI FIFO, I switch to output 16 bit values. To do this I introduced code for beginTransaction/endTransaction. There are still some optimizations I can do, where you put DC on an SPI cs pin... Most of the code for that is in place. But not some initial stuff...

    Current timings are:
    Code:
    ello!Before Commandlist
    After Commandlist
    init
    30
    After fill screen
    After test draw text
    tftPrintTest: 1580
    testlines: 449
    tftPrintTest: 44
    tftPrintTest: 40
    tftPrintTest: 222
    tftPrintTest: 102
    testroundrects: 114
    testtriangles: 70
    mediabuttons: 1106
    done
    Still not as fast as T3.6 ,but pretty good speed ups.

    While I was at it, I added SPI Transaction support for T3.x boards as well. Also add support for SPI1/SPI2 (not tested yet) for T3.5/6. Also should be able to work when CS is NOT a CS pin.
    The timings for this is showing slightly slower... Why? because the older code would return even though the SPI fifo queue might be full, and as such the timings might happen before we finish outputting 4 16 bit values...

    Warning: - I removed the __AVR__ support, plus the Arduino DUE support.

    There is still some code in their that on T3.x if you specify non SPI pins, it will try to do it bit banging... Not sure if we need/want to keep this? I have not yet done the bit banging code for T4.

    I have not updated the TLC code yet. I suspect I need to do some additional support to make it compile. But again wonder why this is in a _t3 library?

    Thoughts?
    Want to try it out? https://github.com/KurtE/ST7735_t3/tree/T4_beta (needs my update Adafruit_gfx as well)

    Minor Update: I tried T3.6 with SPI1 (MOSI(0), SCK(32), DC(31), CS any digital pin) and it works...
    Last edited by KurtE; 06-21-2019 at 09:24 PM.

  19. #3369
    Senior Member+ KurtE's Avatar
    Join Date
    Jan 2014
    Posts
    5,578
    Quick update:

    With T3.6 - As I mentioned in minor update to previous posting I tried:SPI1 (MOSI(0), SCK(32), DC(31), CS any digital pin) and it works...

    Since then I tried on SPI2 with: MOSI(44), SCK(46), CS(54), DC(55) and it works

    I also made changes to make it build on TLC.

    Also put in code to T4, to allow bit bang when not on SPI pins... And it might be faster.

    Again if anyone is interested... it is up on my fork/branch mentioned in previous post.

    Will play a little more and maybe issue PR...

  20. #3370
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    9,959
    Good work KurtE - I confirmed the AdaF_GFX with 9341 - but don't have any 7735's to try.

    I don't have a good answer for re-define of Progmem … bummer T4 needs it back in use …

    <EDIT> … for some reason of course I have one … 128x128 … looks like the pin order matches the ili9341? Just cut the antistatic wrapper off of it

  21. #3371
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    9,959
    @KurtE - I got the github >> ST7735_t3-T4_beta.zip

    Compiled and ran the example 'graphistest' in the lib examples - on T4 plugged into PJRC Purple Test PCB

    Post#3368 sketch code #1 is incomplete and I don't have : various 'test' things like > testdrawtext

    <edit> ran :: "T:\tCode\libraries\ST7735_t3\examples\SpeedTest\S peedTest.ino" no problem

  22. #3372
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    9,959
    @KurtE in speedtest.ino noted above I did this quick - to repeat the intro tests then it dies - gotta run - not sure what is doing this?::

    Note death of locking - requires Button to reprogram:
    T:\Ard186t4b2\hardware\teensy/../tools/teensy_post_compile -file=SpeedTest.ino -path=T:\TEMP\arduino_build_497409 -tools=T:\Ard186t4b2\hardware\teensy/../tools -board=TEENSY40 -reboot -port=usb:0/140000/0/8/7 -portlabel=COM25 Serial -portprotocol=Teensy
    Unable to open COM25 for reboot request
    Windows Error Info: Access is denied.
    more ideas... https://forum.pjrc.com/threads/40632...l=1#post126667
    Previously selected Teensy port is offline.
    5 other Teensy boards found. Please select
    a Teensy from the Tools > Ports menu.
    Unable to open COM25
    Make the end of loop() look like this:
    Code:
    	fps = 1000000.0f/float(end-start);
      delay(500);
      firstset();
      delay(500);
    }
    Split setup() like this::
    Code:
    void setup()
    {
    	pinMode(SD_CS, INPUT_PULLUP);  // keep SD CS high when not using SD card
    
    	// Use this initializer if you're using a 1.8" TFT
    	disp.initR(INITR_BLACKTAB);
    	// Use this initializer (uncomment) if you're using a 1.44" TFT
    	//disp.initR(INITR_144GREENTAB);
      firstset();
    }
    void firstset()
    {
            n = 0;  // Here is the fix - re-running the code ran off array end
    	disp.setRotation(0);
    	disp.setTextWrap(true);
    	disp.setTextColor(RGB(31,31,31), RGB(0,0,0));
    	disp.setCursor(0, 0);
    
    	disp.fillScreen(RGB(0,0,0));
    
    	t[n++] = millis();
    	disp.fillScreen(ST7735_BLACK);
    	t[n++] = millis();
    	testdrawtext("Lorem ipsum dolor sit amet, consectetur adipiscing elit. Curabitur adipiscing ante sed nibh tincidunt feugiat. Maecenas enim massa, fringilla sed malesuada et, malesuada sit amet turpis. Sed porttitor neque ut ante pretium vitae malesuada nunc bibendum. Nullam aliquet ultrices massa eu hendrerit. Ut sed nisi lorem. In vestibulum purus a tortor imperdiet posuere. ", ST7735_WHITE, ST7735_WHITE);
    	t[n++] = millis();
    	tftPrintTest(false);
    	t[n++] = millis();
    	testdrawtext("Lorem ipsum dolor sit amet, consectetur adipiscing elit. Curabitur adipiscing ante sed nibh tincidunt feugiat. Maecenas enim massa, fringilla sed malesuada et, malesuada sit amet turpis. Sed porttitor neque ut ante pretium vitae malesuada nunc bibendum. Nullam aliquet ultrices massa eu hendrerit. Ut sed nisi lorem. In vestibulum purus a tortor imperdiet posuere. ", ST7735_WHITE, ST7735_BLACK);
    	t[n++] = millis();
    	tftPrintTest(true);
    	t[n++] = millis();
    	testlines(ST7735_YELLOW);
    	t[n++] = millis();
    	testfastlines(ST7735_RED, ST7735_BLUE);
    	t[n++] = millis();
    	testdrawrects(ST7735_GREEN);
    	t[n++] = millis();
    	testfillrects(ST7735_YELLOW, ST7735_MAGENTA);
    	t[n++] = millis();
    	disp.fillScreen(ST7735_BLACK);
    	t[n++] = millis();
    	testfillcircles(10, ST7735_BLUE);
    	t[n++] = millis();
    	testdrawcircles(10, ST7735_WHITE);
    	t[n++] = millis();
    	testroundrects();
    	t[n++] = millis();
    	testtriangles();
    	t[n++] = millis();
    	mediabuttons();
    	t[n++] = millis();
    	disp.fillScreen(RGB(0,0,0));
    }
    Last edited by defragster; 06-22-2019 at 03:55 AM.

  23. #3373
    Senior Member+ KurtE's Avatar
    Join Date
    Jan 2014
    Posts
    5,578
    Thanks @defragster.

    I might need to see your whole program to see what is happening. Things like where is the array t defined? And where is n defined... Could it be just walking off the end of an array?

    Likewise where start and end are defined? (i.e. could it be a divide by 0?)

    I updated the graphic test program to do all of the tests in a run_tests function, which is also called in loop and so far it has been running for awhile on T4.

  24. #3374
    Senior Member+ mjs513's Avatar
    Join Date
    Jul 2014
    Location
    New York
    Posts
    4,213
    Quote Originally Posted by KurtE View Post
    @Paul - Things for the good explanation of all of those other test points... Plus how the boards are tested.

    The Card - Looks good enough to me. I like @defragsters comments but, I would not hold up shipping to spend more time yet.

    @defragster and @Paul plus @all - With Adafruit and GFX and the warning about PROGMEM.

    Not sure of the right fix for the message:
    '

    First pass was to edit glcdfont.c to not define it in the case of T4:
    Like:
    Code:
    #ifndef FONT5X7_H
    #define FONT5X7_H
    
    #ifdef __AVR__
     #include <avr/io.h>
     #include <avr/pgmspace.h>
    #elif defined(ESP8266)
     #include <pgmspace.h>
    #elif defined(__IMXRT1052__) || defined(__IMXRT1062__)
    // PROGMEM is defefind for T4 to place data in specific memory section
    #else
     #define PROGMEM
    #endif
    
    // Standard ASCII 5x7 font
    
    static const unsigned char font[] PROGMEM = {
    But that gives a compiler error:
    Code:
    C:\Users\kurte\Documents\Arduino\libraries\Adafruit_GFX_Library\glcdfont.c:20:35: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'PROGMEM'
    
     static const unsigned char font[] PROGMEM = {
    
                                       ^
    Obviously I can rid myself of both warning and error like:
    Code:
    #ifdef __AVR__
     #include <avr/io.h>
     #include <avr/pgmspace.h>
    #elif defined(ESP8266)
     #include <pgmspace.h>
    #elif defined(__IMXRT1052__) || defined(__IMXRT1062__)
    // PROGMEM is defefind for T4 to place data in specific memory section
     #undef PROGMEM
     #define PROGMEM
    #else
     #define PROGMEM
    #endif
    But is that what we expect?

    @all Hacked up version (first pass) of ST7735_t3 library that compiles and works with my Adafruit_GFX changes mentioned earlier.

    So far only pass 1, where I use SPI.transfer() to do the transfers... Also I don't yet have code in to handle putting the display on NON SPI (MOSI, SCLK) pins.
    I did however make it work on SPI2 (and probably SPI1, not setup to test yet)...

    Will probably do another pass to make use of the T4's SPI FIFO queues. Maybe does not help as much as T3.x where we can encode DC, CS data, but still may help some...
    Current version up at: https://github.com/KurtE/ST7735_t3/tree/T4_beta
    Hi @KurtE - @defragster
    Sorry I been missing in action but too much going on right now. Anyway trying to catch up which is always tough. GFX library and PROGMEM has been talked about a few times on the thread - here's one: https://forum.pjrc.com/threads/54711...l=1#post195059.

    I don't have a ST7735 display so can't really be of much use on that one. But did I read right that touch seemed to work with the 9341 display with the Adafruit lib but had a problem with ILI9341_t3n?

  25. #3375
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    9,959
    opps ... I got a call to a neighbor's house as I saw this - made post and jetted over ... now back ...

    It is this included example:: T:\tCode\libraries\ST7735_t3\examples\SpeedTest\Sp eedTest.ino

    Yes - it is n++ going off the end - this fixes it … edit to above
    Code:
    void firstset()
    {
      n = 0;

Posting Permissions

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