Forum Rule: Always post complete source code & details to reproduce any issue!
Page 150 of 175 FirstFirst ... 50 100 140 148 149 150 151 152 160 ... LastLast
Results 3,726 to 3,750 of 4361

Thread: Teensy 4.0 First Beta Test

  1. #3726
    Senior Member+ Frank B's Avatar
    Join Date
    Apr 2014
    Location
    Germany NRW
    Posts
    5,679
    Ok, I can reproduce that now.

    Creepy!

  2. #3727
    Senior Member+ Frank B's Avatar
    Join Date
    Apr 2014
    Location
    Germany NRW
    Posts
    5,679
    It does not happen with GCC 6 - so simplest assumption is: Compiler/Linker Bug.
    GCC 8: Does not compile because of WireIMXRT.cpp (see above...)
    GCC7: Don't have a installation at the moment.

    So, I will not dig deeper.. makes not much sense

    Edit: "Our" gcc (5.4.1 from 2016) is quite old..but with coremark, it's the fastest so far. Maybe we should do more benchmarks with newer versions? Maybe the newer versions just don't like coremark.
    Last edited by Frank B; 07-16-2019 at 08:21 PM.

  3. #3728
    Senior Member+ mjs513's Avatar
    Join Date
    Jul 2014
    Location
    New York
    Posts
    4,271
    Quote Originally Posted by Frank B View Post
    Ok, I can reproduce that now.

    Creepy!
    Isn't it though . Wonder if it shows the same behavior with other optimizations? Oh - it does work on a T3.6 last I looked.

  4. #3729
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    10,061
    Quote Originally Posted by Frank B View Post
    Ok, I can reproduce that now.

    Creepy!
    Quote Originally Posted by Frank B View Post
    It does not happen with GCC 6 - so simplest assumption is: Compiler/Linker Bug.
    GCC 8: Does not compile because of WireIMXRT.cpp (see above...)
    GCC7: Don't have a installation at the moment.

    So, I will not dig deeper.. makes not much sense
    Yes, it is some confusion in the build>linker dropping out some needed code shown comparing the LST files.

    - thought for sure I assembled the libs from the right place … where I used them from …

    As far as the PULL request for (used) - I only mentioned that as not yet done - but ODDLY it comes from the same place in the code to some degree and wondering if that is where the dropping of this code is from.

    AFAIK @mjs513 ran into a few issues in his beta work that were similarly ODD if not the same - but it didn't hit many others that made mention.

    re @mjs crosspost - yes many other compile options not yet tried - or failed when tried … I noted that the other day as something to have tested.

  5. #3730
    Senior Member+ Frank B's Avatar
    Join Date
    Apr 2014
    Location
    Germany NRW
    Posts
    5,679
    Quote Originally Posted by mjs513 View Post
    Isn't it though . Wonder if it shows the same behavior with other optimizations? Oh - it does work on a T3.6 last I looked.
    Not sure what it would be good for. I'd just accept that it is an old bug which seems to be fixed in the "newer" GCC 6
    I'd just switch to GCC 6


    p.s. I suspect that the GCC 8 problem from above("side-effects") is also just a (new) bug...

  6. #3731
    Senior Member+ Frank B's Avatar
    Join Date
    Apr 2014
    Location
    Germany NRW
    Posts
    5,679
    I'm uploading my working GCC 6 directory to my google-drive- Takes a few minutes. Willl post the link here.

    Edit:
    - Download arm6.zip,
    - extract zip to Arduino/hardware/tools/arm6,
    - edit boards.txt: teensy4b2.build.toolchain=arm6/bin/ for use with T4b2 only.

    https://drive.google.com/drive/folde...2xIYUR4MU1rdzg
    Last edited by Frank B; 07-16-2019 at 08:54 PM.

  7. #3732
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    10,061
    Quote Originally Posted by Frank B View Post
    I'm uploading my working GCC 6 directory to my google-drive- Takes a few minutes. Willl post the link here.

    Edit:
    - Download arm6.zip,
    - extract zip to Arduino/hardware/tools/arm6,
    - edit boards.txt: teensy4b2.build.toolchain=arm6/bin/ for use with T4b2 only.

    https://drive.google.com/drive/folde...2xIYUR4MU1rdzg
    Yikes, that is a Big ZIP - 3X TeensyDuino! Will see if it fixes my repro too.

  8. #3733
    Senior Member+ Frank B's Avatar
    Join Date
    Apr 2014
    Location
    Germany NRW
    Posts
    5,679
    Oh, i see.. there is a big 5.4.1 folder inside - remaining from a test I did some months ago.. sry
    I think you can delete the 5.4.1 folder inside \arm6\lib\gcc\arm-none-eabi

  9. #3734
    Senior Member+ mjs513's Avatar
    Join Date
    Jul 2014
    Location
    New York
    Posts
    4,271
    @Frank B and @defragster @KurtE

    Hope you don't mind but I just downloaded and installed your GCC 6. Ok don't get the that error anymore but without debug_tt the eyes on the two screens are distorted. Yes you can make changes with it crashing and loosing usb but:
    Click image for larger version. 

Name:	20190716_172955.jpg 
Views:	14 
Size:	60.9 KB 
ID:	17016

  10. #3735
    Senior Member+ Frank B's Avatar
    Join Date
    Apr 2014
    Location
    Germany NRW
    Posts
    5,679
    Quote Originally Posted by mjs513 View Post
    @Frank B and @defragster @KurtE

    Hope you don't mind but I just downloaded and installed your GCC 6.
    It's there to be downloaded I'll leave it there.

    I don't know where the distortions come from. Maybe a bug somewhere else.. the picture looks like overflows or memory corruption.
    I don't have the displays.

  11. #3736
    Senior Member+ KurtE's Avatar
    Join Date
    Jan 2014
    Posts
    5,690
    @mjs513 - Maybe we should try selecting a lower SPI speed and see if that makes a difference there?

  12. #3737
    Senior Member+ mjs513's Avatar
    Join Date
    Jul 2014
    Location
    New York
    Posts
    4,271
    Quote Originally Posted by KurtE View Post
    @mjs513 - Maybe we should try selecting a lower SPI speed and see if that makes a difference there?
    @KurtE Tried several SPI freq lowering it down to 8Mhz but no change to the distorted image.

    Note that if I do and include debug_tt it the eyes on both screens display normally.

    It looks almost like a memory issue

  13. #3738
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    10,061
    Quote Originally Posted by mjs513 View Post
    @KurtE Tried several SPI freq lowering it down to 8Mhz but no change to the distorted image.

    Note that if I do and include debug_tt it the eyes on both screens display normally.

    It looks almost like a memory issue
    instead of debug_tt - do the prior posted sketch local copy of the Fault_Handler:
    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
    The code isn't being called - though that should run - but it shows it is a simple linkage {code movement or memory setup?} issue going to smaller code if that affects it.

    My effort to switch to arm6 doesn't work?

    It exists here as indicated?:
    "T:\arduino_1.8.9_146\hardware\tools\arm6\bin\ arm-none-eabi-g++.exe"

    But with change in boards.txt stops with this after closing and re-opening the IDE::
    "T:\\Ard186t4b2\\hardware\\teensy/../tools/arm6/bin/arm-none-eabi-g++" -E -CC -x c++ -w -g -Wall -ffunction-sections -fdata-sections -nostdlib -std=gnu++14 -fno-exceptions -fpermissive -fno-rtti -fno-threadsafe-statics -felide-constructors -Wno-error=narrowing -mthumb -mcpu=cortex-m7 -mfloat-abi=hard -mfpu=fpv5-d16 -D__IMXRT1062__ -DTEENSYDUINO=147 -DARDUINO=10809 -DF_CPU=600000000 -DUSB_SERIAL -DLAYOUT_US_ENGLISH "-IT:\\Ard186t4b2\\hardware\\teensy\\avr\\cores\\tee nsy4" "T:\\TEMP\\arduino_build_226809\\sketch\\uncannyEy es0.ino.cpp" -o nul
    exec: "T:\\Ard186t4b2\\hardware\\teensy/../tools/arm6/bin/arm-none-eabi-g++": file does not exist
    Error compiling for board Teensy 4-Beta2.

  14. #3739
    Senior Member+ mjs513's Avatar
    Join Date
    Jul 2014
    Location
    New York
    Posts
    4,271
    @defragster

    Change "arm6" to arm and it will run. I zipped the present toolchain and then copied arm6 over and renamed it to "arm". I also deleted the 5.3.1 folder.

  15. #3740
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    10,061
    There is an arm folder there already?

  16. #3741
    Senior Member+ mjs513's Avatar
    Join Date
    Jul 2014
    Location
    New York
    Posts
    4,271
    Yep - replaced it with the contents of arm6

    EDIT = make sure you back it up first

  17. #3742
    Senior Member+ mjs513's Avatar
    Join Date
    Jul 2014
    Location
    New York
    Posts
    4,271
    @defragster - @Frank B

    Running into problem with GCC6 - Eigen library that runs fine under GCC7 is now throwing errors so sketch can not compile. Not sure if there will be an impact to anything else - at least for the T4B2

  18. #3743
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    10,061
    Quote Originally Posted by mjs513 View Post
    @defragster - @Frank B

    Running into problem with GCC6 - Eigen library that runs fine under GCC7 is now throwing errors so sketch can not compile. Not sure if there will be an impact to anything else - at least for the T4B2
    Odd Frank B thought the new 'arm6' path with edit would make it work to use new compiler … except for the part before " … " the last part should have found the .exe?

    Doesn't sound like a good solution without more work. Not sure if Paul has any thoughts of replacing tools now? It might have seemed sensible up front with Beta to add new libs/features or updated 1062 type support . . .

    … Uncanny eyes I don't have hardware and it was noted the resultant EXE has odd but functional behavior I wouldn't see.
    … Eigen or other not working?

    Seems like the .ld and segmentation or build flags or func() decorations may need tweeked?

    Though maybe UncannyEyes just has a fault or code issue in it somewhere - though why that would exhibit as it did is odd.

    Will be interesting as the other optimize/build choices get used more.

  19. #3744
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    10,061
    I just undid boards.txt back to arm\bin with unchanged TD version of gcc. I did a build without local Hard_Fault and the LST MASM file is SMALL - but AUTO Upload works, the SerMon shows proper text and the LED is blinking. The below line was commented.

    Then uncommented this and rebuilt:
    #define LIGHT_PIN_FLIP // If defined, reverse reading from dial/photocell
    the LST MASM file is still the same size and now it is failing. So that obvious difference isn't behind the issue?
    T:\tCode\T4\uncannyEyes0\uncannyEyes0.ino Jul 16 2019 17:02:07
    ********
    T4 connected Serial_tt ******* debug_tt port

    T:\tCode\T4\uncannyEyes0\uncannyEyes0.ino Jul 16 2019 17:02:07InitCreate display #Create display #Reset displaysCall init/begin func for each display
    Note: debug_tt not in use - that is just a print line in setup()

    Something very odd … but not apparently indicated by just the small lst file.

    <EDIT>
    This code is expecting 10 bit analog 1023 max value? Is this resolving to a fatal value without the #define of LIGHT_PIN_FLIP?:
    Code:
    void loop() {
    
    #if defined(LIGHT_PIN) && (LIGHT_PIN >= 0) // Interactive iris
    
      int16_t v = analogRead(LIGHT_PIN);       // Raw dial/photocell reading
    #ifdef LIGHT_PIN_FLIP
      v = 1023 - v;                            // Reverse reading from sensor
    #endif
      if (v < LIGHT_MIN)      v = LIGHT_MIN; // Clamp light sensor range
      else if (v > LIGHT_MAX) v = LIGHT_MAX;
      v -= LIGHT_MIN;  // 0 to (LIGHT_MAX - LIGHT_MIN)
    #ifdef LIGHT_CURVE  // Apply gamma curve to sensor input?
      v = (int16_t)(pow((double)v / (double)(LIGHT_MAX - LIGHT_MIN),
                        LIGHT_CURVE) * (double)(LIGHT_MAX - LIGHT_MIN));
    #endif
      // And scale to iris range (IRIS_MAX is size at LIGHT_MIN)
      v = map(v, 0, (LIGHT_MAX - LIGHT_MIN), IRIS_MAX, IRIS_MIN);
    #ifdef IRIS_SMOOTH // Filter input (gradual motion)
      static int16_t irisValue = (IRIS_MIN + IRIS_MAX) / 2;
      irisValue = ((irisValue * 15) + v) / 16;
      frame(irisValue);
    #else // Unfiltered (immediate motion)
      frame(v);
    #endif // IRIS_SMOOTH

  20. #3745
    Senior Member+ mjs513's Avatar
    Join Date
    Jul 2014
    Location
    New York
    Posts
    4,271
    This code is expecting 10 bit analog 1023 max value? Is this resolving to a fatal value without the #define of LIGHT_PIN_FLIP?:
    I have a optoresitor in the loop attached to pin A2 but I've run the sketch with one display with and without it attached.... besides on compile/upload it should be an issue until it runs - so it doesn't even get that far.

  21. #3746
    Senior Member+ Frank B's Avatar
    Join Date
    Apr 2014
    Location
    Germany NRW
    Posts
    5,679
    Quote Originally Posted by mjs513 View Post
    @defragster - @Frank B

    Running into problem with GCC6 - Eigen library that runs fine under GCC7 is now throwing errors so sketch can not compile. Not sure if there will be an impact to anything else - at least for the T4B2
    Of course, it's quite possible that there are incompatibilities.
    Which errors do you get? We should fix them (if in the core), for the future. Paul will surely want to use a newer toolchain sometime later.
    The default GCC 5.4 is quite old.

  22. #3747
    Senior Member+ mjs513's Avatar
    Join Date
    Jul 2014
    Location
    New York
    Posts
    4,271
    Quote Originally Posted by Frank B View Post
    Of course, it's quite possible that there are incompatibilities.
    Which errors do you get? We should fix them (if in the core), for the future. Paul will surely want to use a newer toolchain sometime later.
    The default GCC 5.4 is quite old.
    @Frank B
    Really don't remember the errors but would definitely need to be fixed if Paul updated from GCC 5.4 - not sure if he wants to do this at this point in time - a lot of regression testing would probably have to be done not only for the T4 but for the T3.x's but....

  23. #3748
    Senior Member
    Join Date
    Feb 2015
    Posts
    100
    I hope it's okay to ask this here, as I'm not a beta tester...

    Is there a general idea of when the T4 might be released? I have an application which could really use the CPU and RAM of the T4.

    Thanks to all those contributing their expertise to the beta testing, you're making things easy for us mere mortals who use the finished products.

  24. #3749
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    10,061
    Quote Originally Posted by wcalvert View Post
    ...
    Is there a general idea of when the T4 might be released? …
    Only Paul can answer specifically - but general from prior posts plan was IIRC July 2019 - may still make it - but last post noted delivery of production PCB's was not 100% on schedule and production was starting with smaller initial batching to test the building of the little Monsters.

  25. #3750
    Senior Member
    Join Date
    Feb 2015
    Posts
    100
    That's awesome, thank you for the info.

Posting Permissions

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