Forum Rule: Always post complete source code & details to reproduce any issue!
Page 149 of 172 FirstFirst ... 49 99 139 147 148 149 150 151 159 ... LastLast
Results 3,701 to 3,725 of 4287

Thread: Teensy 4.0 First Beta Test

  1. #3701
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    9,302
    I got this to repro following what @mjs513 reported with uncannyeyes from noted thread above.

    Something odd in linking or run time loading? There are multiple pieces to load as noted.

    Update:: post #3710 has two ZIP files that should hold all the needed parts as I have them

    I have gotten it to Fail and then Unfail and it hinges on FaultHandler code being local or the 'weak' version in the Teensy4.

    No displays are needed just a T4 on a USB cable.

    UPDATE :: In case it holds some info without needing to do a full setup/build/repro - here are the Hex/Lst/Elf contents of working and not working build directory in the ZIP as named:
    T:\TEMP\arduino_build_159521>dir /b
    build.options.json
    FAILS_T4_build.options.zip :: FAILS_T4_build.options.zip << these files for FAILS
    includes.cache
    uncannyEyes0.ino.eep
    uncannyEyes0.ino.elf
    uncannyEyes0.ino.hex
    uncannyEyes0.ino.lst
    uncannyEyes0.ino.sym
    WORKS_T4_uncannyEyes0.ino.zip :: WORKS_T4_uncannyEyes0.ino.zip << these files for WORKS
    Did a CodeCompare Diff of the two LST files and tons of changes not surprising.

    One BIG glaring chunk of stuff MISSING in the FAILS case { .lst is 982 KB ) that is present in the WORKS case { .lst is 1,232 KB } is:
    Code:
    00006320 <_vfprintf_r>:
        6320:	e92d 4ff0 	stmdb	sp!, {r4, r5, r6, r7, r8, r9, sl, fp, lr}
        6324:	ed2d 8b06 	vpush	{d8-d10}
        6328:	b0b9      	sub	sp, #228	; 0xe4
        632a:	461c      	mov	r4, r3
        632c:	468a      	mov	sl, r1
    // there are 60+ pages for this item missing in the FAILS case.
    <edit> vfprintf is its own thing:
    ...\hardware\teensy\avr\cores\teensy4\avr\pgmspace .h:
    70 #define strstr_P(a, b) strstr((a), (b))
    71 #define sprintf_P(s, ...) sprintf((s), __VA_ARGS__)
    72: #define vfprintf_P(fp, s, ...) vfprintf((fp), (s), __VA_ARGS__)
    73 #define printf_P(...) printf(__VA_ARGS__)
    74 #define snprintf_P(s, n, ...) snprintf((s), (n), __VA_ARGS__)
    Here is a copy of the post #361 from the other thread with links and parts needed - if it isn't clear @mjs513 should be able to repro and explain:

    Lots of pieces from https://forum.pjrc.com/threads/55735...l=1#post210182 ::
    https://github.com/PaulStoffregen/cores
    https://github.com/KurtE/Adafruit-GFX-Library
    https://github.com/PaulStoffregen/SPI

    Here is the UnCannyEyes as used here - with local copy of HardFault_HandlerC(): Attachment 16981

    from post >>uncannyEyes0.Zip

    … link to st7735 … https://github.com/KurtE/ST7735_t3/t...ct_reset_delay

    Time to gather …
    NOT NEEDED :: from post >>debug_tt.zip

    NOTE: Once it compiles to upload a failed repro build - to get back to working SerMon USB seems to take a SECOND Button push to get working SerMon back from USB. The SPI LED will blink - but USB stays corrupted until a second Button Push upload.

    <edit> debug_tt - not required if this is placed in the sketch - just toggle: #if 0 and 1.
    NOTE: It is not because the HardFault_HandlerC() is truncated - the copy in debug_tt is a full copy - and instead of the minimal copy below I did another FULL copy of the current version from CORES and the repro is the same. The problem seems to be in the linking or code placement in memory - even though in these cases the T4 is never faulting - so the code is never called or executed.
    Code:
    #if 1  // TOGGLE 0 to exclude and cause BAD USB - set back to 1 and recompile to correct.
    #ifdef __cplusplus
    extern "C" {
    #endif
    
    #if defined(__IMXRT1052__) || defined(__IMXRT1062__)
    void HardFault_HandlerC(unsigned int *hardfault_args) {
      digitalWriteFast( 13, HIGH );
      while (1);
    }
    #endif
    #ifdef __cplusplus
    } // extern "C"
    #endif
    #endif
    >> Running with BARE T4 on USB cable - white wire T4B2.
    OKAY - I get REPRO when this is changed per note above when this line uncommented:
    Code:
    T:\tCode\t4\uncannyEyes0\config.h:
      136    #define BLINK_PIN         1 // Pin for manual blink button (BOTH eyes)
      137    #define LIGHT_PIN      A2 // Photocell or potentiometer (else auto iris)
      138:   //#define LIGHT_PIN_FLIP    // If defined, reverse reading from dial/photocell
    NOTE: it fails, then Button upload when debug_tt active in sketch by uncommenting or recommenting - when the local copy of "HardFault_HandlerC" comes or goes - just the change in config.h causes the code to recompile and that brings the failure back.
    Note from @mjs513 above:
    To duplicate load up the sketch on a clean install and then just comment/uncomment the line
    Code:
      //#define LIGHT_PIN_FLIP    // If defined, reverse reading from dial/photocell
    In this case uncomment it. You don't even need to have displays attached. To duplicate it though you can't use your debug_tt. If you include it, it some how fixes the problem.
    BUT:: IDE SerMon shows Garbage after first upload - it comes online properly with a second Button Upload. It looks like this:
    >> This is a telling PIC of bad USB Garbage from other post <<
    Click image for larger version. 

Name:	UnCannyE0.png 
Views:	1 
Size:	37.0 KB 
ID:	16988
    Then it clears up showing the 64's and is running???


    Edit: I am seeing two kinds of fail - the obvious one I removed debug_tt and made the config.h change - T4 not running - no SPI LED and this on SerMon:
    Code:
    T:\tCode\T4\uncannyEyes0\uncannyEyes0.ino Jul 14 2019 20:57:03
    ********
     T4 connected Serial_tt ******* debug_tt port
    
    T:\tCode\T4\uncannyEyes0\uncannyEyes0.ino Jul 14 2019 20:57:03InitCreate display #Create display #Reset displaysCall init/begin func for each display
    The less obvious case it seemed to start and print normally - and had to observe the LED stayed OFF - with no SPI activity.

    --- This text from WIP - before I had clean repro steps ---
    <EDIT UPDATE> I am not getting "REPRO / NO REPRO /REPRO / … " by reverting the code?
    @mjs513 - is your note saying any change to 'LIGHT_PIN' ? I did get a hang now with it commented - before it was when uncommented?
    It does seem to take 'Clean Build' - once it works it seems to persist? Maybe it is a change from change to '\uncannyEyes0\config.h' ?
    Last edited by defragster; 07-15-2019 at 09:20 PM. Reason: Added BUILD zips and note about LST file shortage

  2. #3702
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    9,302
    Paul: There is an outstanding PULL request : https://github.com/PaulStoffregen/cores/pull/358

    In the PULL request that 'weak' HardFault_HandlerC() is getting dropped with LTO.

    In post #3701 above printf { aka: <_vfprintf_r> ?? } is getting dropped

    I just added pull request line ((used) to my local CORES and it did not stop this failure and the smaller LST file - but not sure if it points to anything to help?

    @Frank B {@others} - does the above look like anything to you?

    NOTE: In above post this is NOT LTO compiled - just the normal default.

    Where with LTO build Frank B found this 'weak' code prototype in startup.c was needed:
    Code:
    void HardFault_HandlerC(unsigned int *hardfault_args) __attribute__((used));
    __attribute__((weak))
    void HardFault_HandlerC(unsigned int *hardfault_args) {
      volatile unsigned int stacked_r0 ;
    Also Note - when this is removed "#define PRINT_DEBUG_STUFF" - that printf usage in the HardFault_...() code gives warnings - so there may be some linker confusion about it being needed? But this error repro's the same with or without 'Print_debug_stuff' - as I tried that first before putting it back and making the local HardFault_Handler() as tested above.

    In the three cases where a SKETCH based {not weak} version of HardFault_HandlerC() is included it either doesn't include printf, or in the ZIP above it is explicit and not 'weak'

  3. #3703
    Senior Member+
    Join Date
    Jul 2014
    Location
    New York
    Posts
    3,914
    @PaulStoffregen (@KurtE, @defragster)

    If you look at the scenario's from what I was doing as well as @KurtE and @defragster, I am seeing the following if I load uncanyeyes on a clean T4 (did a 15s restart) first and with debug_tt not included in sketch. Note: This is probably just a rehash of previous info on the USB lose. The pin issue was not described above

    On first load the sketch runs as advertised for me displaying eyes on both ST7735's. Now the problems starts....

    Test 1 - if I try to change the pin select from pin 6 to pin 23 for the right eye. Sketch says done uploading and get the familiar ping and Teensyduino uploading the sketch but it doesn't change to using pin 23. To make the change you have to do a 15 sec reboot. After reloading sketch using pin 23 it works using pin 23. If you do include debug_tt changing from pin 6 to pin 23 will work on reload without a 15s restart.

    Test 2 - seems very repeatable is commenting and uncommenting this line as @KurtE and @defragster described:
    Code:
                 //#define LIGHT_PIN_FLIP    // If defined, reverse reading from dial/photocell
    Everytime you will loose USB port for the T4 - testing with the white wire on bottom since I can take that one out of the breakout board and put it on a breadboard. To recover I have to the 15sec restart again if I want to try something else with the sketch. Note that I tested this scenario with all 3 of the T4B2s that I have including on the breakout board with the ribbon cable.

    <edit> Forgot. When this occurs gibberish is also printed out on serial4.

    For the scenario with the lost USB if I load the sketch with debug_tt it will print gibberish and the eyes look like newspaper eyes but it runs. If I hit the reload it will recover --- @defragster described this in previous posts.
    Last edited by mjs513; 07-15-2019 at 12:20 PM.

  4. #3704
    Senior Member+ Frank B's Avatar
    Join Date
    Apr 2014
    Location
    Germany NRW
    Posts
    5,679
    @MichaelMeissner

    Hi Michael, I have a question:
    GCC8 (Compiler version : 8.3.1 20190703 (release) [gcc-8-branch revision 273027]) complains about the xxx.offsetyyy mechanism in imxrt.h.
    (Edit: Just copy the zipfile to .. /hardware/tools/arm8 and modify this line in boards.txt: teensy4b2.build.toolchain=arm8/bin/ - that's all)
    Test:
    Code:
    #include <Wire.h>
    
    void setup() {}
    void loop() {}
    Errormessages:
    Code:
    C:\Arduino\hardware\teensy\avr\cores\teensy4/imxrt.h:1141:32: error: expression '((IMXRT_REGISTER32_t*)1074774016)->IMXRT_REGISTER32_t::offset070' has side-effects
     #define CCM_CCGR2   (IMXRT_CCM.offset070)
                         ~~~~~~~~~~~^~~~~~~~~~
    C:\Arduino\hardware\teensy\avr\libraries\Wire\WireIMXRT.cpp:307:9: note: in expansion of macro 'CCM_CCGR2'
             CCM_CCGR2, CCM_CCGR2_LPI2C1(CCM_CCGR_ON),
             ^~~~~~~~~
    C:\Arduino\hardware\teensy\avr\cores\teensy4/imxrt.h:1141:32: error: expression '((IMXRT_REGISTER32_t*)1074774016)->IMXRT_REGISTER32_t::offset070' has side-effects
     #define CCM_CCGR2   (IMXRT_CCM.offset070)
                         ~~~~~~~~~~~^~~~~~~~~~
    C:\Arduino\hardware\teensy\avr\libraries\Wire\WireIMXRT.cpp:316:9: note: in expansion of macro 'CCM_CCGR2'
             CCM_CCGR2, CCM_CCGR2_LPI2C3(CCM_CCGR_ON),
             ^~~~~~~~~
    C:\Arduino\hardware\teensy\avr\cores\teensy4/imxrt.h:1145:32: error: expression '((IMXRT_REGISTER32_t*)1074774016)->IMXRT_REGISTER32_t::offset080' has side-effects
     #define CCM_CCGR6   (IMXRT_CCM.offset080)
                         ~~~~~~~~~~~^~~~~~~~~~
    C:\Arduino\hardware\teensy\avr\libraries\Wire\WireIMXRT.cpp:325:9: note: in expansion of macro 'CCM_CCGR6'
             CCM_CCGR6, CCM_CCGR6_LPI2C4_SERIAL(CCM_CCGR_ON),
    In imxrt.h, we have:
    Code:
    typedef struct {
        volatile uint32_t offset000;
        volatile uint32_t offset004;
        volatile uint32_t offset008;
    ....
    
    } IMXRT_REGISTER32_t;
    
    ...
    
    #define CCM_CCGR2            (IMXRT_CCM.offset070)
    The code in WireIMXRT which the produces the error is:
    Code:
    PROGMEM
    constexpr TwoWire::I2C_Hardware_t TwoWire::i2c1_hardware = {
            CCM_CCGR2, CCM_CCGR2_LPI2C1(CCM_CCGR_ON),
            {{18, 3 | 0x10, &IOMUXC_LPI2C1_SDA_SELECT_INPUT, 1}, {0xff, 0xff, nullptr, 0}},
            {{19, 3 | 0x10, &IOMUXC_LPI2C1_SCL_SELECT_INPUT, 1}, {0xff, 0xff, nullptr, 0}},
            IRQ_LPI2C1
    };
    TwoWire Wire(&IMXRT_LPI2C1, TwoWire::i2c1_hardware);
    i2c1_hardware is:
    Code:
        typedef struct {
            volatile uint32_t &clock_gate_register;
            uint32_t clock_gate_mask;
            pin_info_t sda_pins[cnt_sda_pins];
            pin_info_t scl_pins[cnt_scl_pins];
            IRQ_NUMBER_t irq;
        } I2C_Hardware_t;
        static const I2C_Hardware_t i2c1_hardware;
    Do you know, what the errors are, or what exactly the side-effect is?
    Is there a simple workaround, or shall we remove the .offsetyyy machanism? Edit: I think it is there, because GCC can use the optimized THUMB register+offset adressing (more efficient with >1 subsequent device accesses) if it is defined this way.

    @all: I preferred a more simple solution for SPI.h
    https://github.com/PaulStoffregen/SP...6a488a06eb1b8a
    Last edited by Frank B; 07-15-2019 at 07:37 PM.

  5. #3705
    Senior Member+ Frank B's Avatar
    Join Date
    Apr 2014
    Location
    Germany NRW
    Posts
    5,679
    Quote Originally Posted by defragster View Post
    @Frank B {@others} - does the above look like anything to you?
    Well, it's needed(unless there is a better solution) otherwise it does not compile with LTO.

  6. #3706
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    9,302
    Quote Originally Posted by Frank B View Post
    Well, it's needed(unless there is a better solution) otherwise it does not compile with LTO.
    Yes, that is needed for LTO to prevent it being discarded.

    I was wondering about the issue in the post above where printf is not showing in the .lst file for the case where USB and the T4 fails. Somehow in this case it seems to be related to the same code but not an LTO compile and adding that 'used' declaration is not making the difference.

  7. #3707
    Senior Member+ Frank B's Avatar
    Join Date
    Apr 2014
    Location
    Germany NRW
    Posts
    5,679
    @defragster: Can you post a short Arduino-Sketch that helps to reproduce the problem?

  8. #3708
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    9,302
    Quote Originally Posted by Frank B View Post
    @defragster: Can you post a short Arduino-Sketch that helps to reproduce the problem?
    I'm not sure how Frank … This came from efforts by @mjs513 - as posted is the only way it has been seen and reproduced.

    In my efforts I have not seen this that seems to be a failure to 'compile/link'. Those linked libs on current PJRC github CORES was the first I could get to see it.

    It was always failing for @mjs513 and I offered debug_tt at some point - and adding it only changed the 'Fault_Handler' by adding a non-(weak) version and in the process a usable HEX is built.

    Assuming the only issue was the non-weak 'Fault_Handler' code as posted I dropped debug_tt and put a local "C" copy of HardFault_HandlerC() in the sketch as posted either a complete copy of the PJRC version - or a minimal version. When that was done it worked.


    Even that took some time as the build works once it works to some degree - and takes some change to a very trivial piece of code that gets recompiled:
    Code:
    #ifdef LIGHT_PIN_FLIP
      v = 1023 - v;                            // Reverse reading from sensor
    #endif
    Changing that #define in the header leads to a failed build when using the (weak) Fault_Handler - and that is the only effect of that config.h edit.

    In my case at no point did I have to do a 15s Restore - but as noted once it had a failed HEX installed - it takes not one but two Button uploads to get proper operation without the USB being messed up as pictured.

  9. #3709
    Senior Member+ Frank B's Avatar
    Join Date
    Apr 2014
    Location
    Germany NRW
    Posts
    5,679
    The reason for the needed "attribute((used))" is that HardFault_HandlerC is referenced in ASM only (I think), here: https://github.com/PaulStoffregen/co...startup.c#L290
    The used attribute ensures that it gets compiled in, because (I think) otherwise the linker thinks it is not needed and removes it. As a consequence, printf may be removed, too, if not used anywhere else.
    Perhaps, this printf needs a attribute((used)), too?

    Again, a short testsketch would be great - or a zipfile (and instructions how to use it) that contains everything needed (and it should be independend of extra hardware)

  10. #3710
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    9,302
    The p#3701 above list of libs and update cores is what is needed - including the uncannyEyes sketch. No hardware but a T4 is needed.

    As for instructions that should be in #3701 this thread - or in the thread that caused this where I figured out how to recreate what @mjs513 ran into and posted here.

    This should replicate those files - It is a 1.5 MB Zip of Three LIBRARIES and the SKETCH folder.

    Here is the github\pjrc\CORES ZIP I used :: In all my builds - and every one else's on the Beta this has not been any sort of recurring trouble - there is something about this it seems.

    Note: I updated the above post - the missing piece I see in the .lst file is a unique :: vfprintf

    And yes, it seems that the hidden ASM ref to Fault_Handler hides from the LTO code the need - so marking that USED is not the question - only came across the fact that that PULL request is still outstanding - and somewhat ODD that this non LTO build has what seems to be similar trouble in the same code area where according to the LST file - a needed and large section of CODE is being excluded that seems to be related to the HEX not being usable.
    Last edited by defragster; 07-16-2019 at 06:57 PM.

  11. #3711
    Senior Member+
    Join Date
    Jul 2014
    Location
    New York
    Posts
    3,914
    Quote Originally Posted by el_supremo View Post
    In order to compare Teensy processor speeds I ported a couple of CPU-intensive programs to T4b2.
    The first is a ray-tracing program which does a *lot* of single precision floating point calculations to generate a 512x512 PPM-format image on the audio board's uSD card. I originally had it running on a T3.1 which took all night to generate one image. I have now run it on T3.6 and T4b2.
    Code:
     96MHz T3.1 took 8 hours and 53 minutes.
    180MHz T3.6 took 42.6 minutes
    396MHz T4b2 took 3.5 minutes
    ..

    Pete
    Ok you peaked my interest - starting to play with 3d graphics and ray tracing for the T4 - what lib did you port? Started discussing here: https://forum.pjrc.com/threads/55735...l=1#post210250

  12. #3712
    Senior Member+ Frank B's Avatar
    Join Date
    Apr 2014
    Location
    Germany NRW
    Posts
    5,679
    @defragster: I downloaded the files, maybe I'll look tomorrow. Again after midnight here..

  13. #3713
    Senior Member+ Frank B's Avatar
    Join Date
    Apr 2014
    Location
    Germany NRW
    Posts
    5,679
    @MichaelMeissner: Have you noticed my question in Post #3704?

  14. #3714
    Senior Member+ MichaelMeissner's Avatar
    Join Date
    Nov 2012
    Location
    Ayer Massachussetts
    Posts
    3,145
    Quote Originally Posted by Frank B View Post
    @MichaelMeissner: Have you noticed my question in Post #3704?
    Yes, but I'm at work right now (with no Teensy stuff). I would need to recompile the code using the -save-temps=obj option to see what is really going on when I get home.

  15. #3715
    Senior Member
    Join Date
    Nov 2012
    Posts
    1,148
    @mjs513: I used the minray code which is at various places on the internet. I've attached a zip of the code and an image.

    Pete
    Attached Thumbnails Attached Thumbnails Click image for larger version. 

Name:	AEK.gif 
Views:	11 
Size:	90.1 KB 
ID:	17002  
    Attached Files Attached Files

  16. #3716
    Senior Member+
    Join Date
    Jul 2014
    Location
    New York
    Posts
    3,914
    @el_supremo
    Thanks for the code - I was looking at this one to port - but much more complicated: https://github.com/marczych/RayTracer/tree/master/src

  17. #3717
    Senior Member Wozzy's Avatar
    Join Date
    Jan 2013
    Location
    Philadelphia, Pennsylvania USA
    Posts
    350
    I can confirm that Teensy 4.0 works with VL53L1X i2c LASER time of flight distance sensor using this Pololu library.
    Click image for larger version. 

Name:	DSC02463.jpg 
Views:	4 
Size:	132.9 KB 
ID:	17005

  18. #3718
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    9,302
    Marked TimeAlarms as working in Post #4

    Quote Originally Posted by pictographer View Post
    The TimeAlarm library appears to work. I ran the TimeAlarmExample.pde from Paul's github repo. Here's the output:
    Code:
    14:23:02.018 -> 8:29:0014:23:02.952 -> 8:29:01
    14:23:03.944 -> 2 second timer
    14:23:03.944 -> 8:29:02
    14:23:04.970 -> 8:29:03
    14:23:05.962 -> 2 second timer
    
    ...

  19. #3719
    Senior Member+ MichaelMeissner's Avatar
    Join Date
    Nov 2012
    Location
    Ayer Massachussetts
    Posts
    3,145
    Quote Originally Posted by Frank B View Post
    @MichaelMeissner

    Hi Michael, I have a question:
    GCC8 (Compiler version : 8.3.1 20190703 (release) [gcc-8-branch revision 273027]) complains about the xxx.offsetyyy mechanism in imxrt.h.
    (Edit: Just copy the zipfile to .. /hardware/tools/arm8 and modify this line in boards.txt: teensy4b2.build.toolchain=arm8/bin/ - that's all)
    Note, I am a back-end person, and I only minimally use C++ in the compiler code and Arduino/Teensy scripts. I don't know why the compiler is issuing the message. Sorry.

    On my Linux Fedora system, the arm-none-eabi-gcc compiler is 7.x and it works. If I download the 8.x version, it fails.

  20. #3720
    Senior Member+ Frank B's Avatar
    Join Date
    Apr 2014
    Location
    Germany NRW
    Posts
    5,679
    Ok, thank you for looking

  21. #3721
    Senior Member+ Frank B's Avatar
    Join Date
    Apr 2014
    Location
    Germany NRW
    Posts
    5,679
    @Defragster, I tried your zip-files.
    Does not compile - I get
    Code:
    uncannyEyes0: In function 'void drawEye(uint8_t, uint16_t, uint8_t, uint8_t, uint8_t, uint8_t)':
    uncannyEyes0:523: error: 'displayType {aka class ST7735_t3}' has no member named 'writeRect'
         eye[e].display->writeRect(0, screenY, SCREEN_WIDTH, 1, colors);

  22. #3722
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    9,302
    @mjs513 - any ideas?

    Quote Originally Posted by Frank B View Post
    @Defragster, I tried your zip-files.
    Does not compile - I get
    ...
    Odd, There were three libraries in there that needed to be used and then the sketch folder for uncannyEyes0. Seems the ST7735_t3 library might not be the right one if it was updated? I know nothing about this code ...

    Those are the ones I got from the prior post off of github and I just put them together - they should work. Here is what my build console shows using three libraries - all are in there as shown below - in my SKETCHBOOK\libraries folder:
    Multiple libraries were found for "SPI.h"
    Used: T:\tCode\libraries\SPI
    Not used: T:\Ard186t4b2\hardware\teensy\avr\libraries\SPI
    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
    Multiple libraries were found for "ST7735_t3.h"
    Used: T:\tCode\libraries\ST7735_t3
    Not used: T:\Ard186t4b2\hardware\teensy\avr\libraries\ST7735 _t3
    Using library SPI at version 1.0 in folder: T:\tCode\libraries\SPI
    Using library Adafruit_GFX at version 1.5.5 in folder: T:\tCode\libraries\Adafruit_GFX
    Using library ST7735_t3 at version 1.0.0 in folder: T:\tCode\libraries\ST7735_t3

  23. #3723
    Senior Member+ KurtE's Avatar
    Join Date
    Jan 2014
    Posts
    5,283
    Think it needs my fork branch, not at computer, but probably https://github.com/KurtE/ST7735_t3/t...ct_reset_delay

    Has pr...

  24. #3724
    Senior Member+
    Join Date
    Jul 2014
    Location
    New York
    Posts
    3,914
    Yes - writeRect was added later so definitely need KurtE's fork branch that he referenced in post3723.

  25. #3725
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    9,302
    oppps - somehow what I got was earlier version - intended to grab what was working for me and got crossed up ...:
    Repacked with the one with writeRect as "B" version

    Also updated link in above post.

Posting Permissions

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