Forum Rule: Always post complete source code & details to reproduce any issue!
Page 2 of 2 FirstFirst 1 2
Results 26 to 40 of 40

Thread: Teensyduino 1.30 Beta #2 Available

  1. #26
    Senior Member
    Join Date
    Jan 2013
    Location
    Dallas, TX USA
    Posts
    106
    Paul,
    I'm curious as to how you intend to handle the IDE 1.6.10 AVR PIN_A0 to PIN_A7 names that collide with existing Teensy++ defines.
    There is no way to fully resolve this to support both the new 1.6.10 IDE analog pin defines and and be fully backward compatible with Teensy PORTA pin defines.
    One or the other "wins".

    While you won't have actual collisions from #define redeclarations since the names come from the variant files which you control for teensy++, there will be the issue that if someone uses something like PIN_A0 and expects it to be the same as using A0, their code will break.

    And it has the potential to create some confusion since An and PORT_An are not the same pin like all the other arduino boards.
    i.e. A0 will be PORTF0 and PIN_A0 will PORTA0 whereas on all other Arduinos PIN_A0 and A0 are the same physical pin.

    In my avrio code I also have this same issue and have decided to take the unfortunate 1 time hit to change the raw port pin define names
    from PIN_Pb notation to AVRPIN_Pb notation. It REALLY sucks as it breaks all the existing code that happened to use PIN_Pb but I never want to deal wit this again
    and it will also allow users to use the new PIN_An names to indicate the analog ports - well except on Teensy++, unless you also make some kind of change.
    It also has a nice benefit in that the name tends to reflect that it is AVR specific.

    I came to the conclusion that it becomes a documentation and support issue or you get shafted with a backward compatibility hit.
    It sucks either way.

    I went round and round before I finally decided to just take the backward compatibility hit,
    and unlike some of the arduino.cc core developers, I take backward compatibility very seriously.


    --- bill

  2. #27
    Junior Member
    Join Date
    Sep 2013
    Posts
    7
    Quote Originally Posted by PaulStoffregen View Post
    Can you save me some time by posting the code to reproduce this problem?
    Yep sorry for being vague.

    I used OctoWS2811Demo (Examples->FastLED->Multiple->OctoWS2811Demo) most of the time but also tried a few others such as OctoWS2811->Rainbow and BasicTest I think. They all showed the same problem of barely lighting up the first few LEDs, if at all.

    Patched OctWS2811Demo code that blinks LED for sanity check. It fails on 1.6.10 + beta teensyduino and worked right away on 1.6.9 and stable teensyduino.

    AND!!! Huge cheers for helping us make cool stuff Paul



    Code:
    #define USE_OCTOWS2811
    #include<OctoWS2811.h>
    #include<FastLED.h>
    
    #define NUM_LEDS_PER_STRIP 100
    #define NUM_STRIPS 8
    
    CRGB leds[NUM_STRIPS * NUM_LEDS_PER_STRIP];
    int led = 13;
    int on = 0;
    
    // Pin layouts on the teensy 3:
    // OctoWS2811: 2,14,7,8,6,20,21,5
    
    void setup() {
      LEDS.addLeds<OCTOWS2811>(leds, NUM_LEDS_PER_STRIP);
      LEDS.setBrightness(32);
      pinMode(led, OUTPUT); 
    }
    
    void loop() {
      static uint8_t hue = 0;
      for(int i = 0; i < NUM_STRIPS; i++) {
        for(int j = 0; j < NUM_LEDS_PER_STRIP; j++) {
          leds[(i*NUM_LEDS_PER_STRIP) + j] = CHSV((32*i) + hue+j,192,255);
        }
      }
    
      // Set the first n leds on each strip to show which strip it is
      for(int i = 0; i < NUM_STRIPS; i++) {
        for(int j = 0; j <= i; j++) {
          leds[(i*NUM_LEDS_PER_STRIP) + j] = CRGB::Red;
        }
      }
    
      hue++;
    
      LEDS.show();
      LEDS.delay(10);
      
      on++;
      digitalWrite(led, (on % 40) ? LOW : HIGH);
    }
    Last edited by Zekiel; 08-16-2016 at 02:59 AM.

  3. #28
    Senior Member Wozzy's Avatar
    Join Date
    Jan 2013
    Location
    Philadelphia, Pennsylvania USA
    Posts
    341
    Quote Originally Posted by Wozzy View Post
    I'll reload a fresh Arduino 1.6.10, then try to "verify" before and after applying the Teensyduino 1.30B2 update.
    Following up from earlier.

    So I did the following:
    • Restored Windows to an earlier date (just prior to the first Arduino1.6.10 install)
    • Re-download and installed Arduino 1.6.10 from the Windows installer.
    • Compiled (using verify) Blink with Board set to Arduino Uno - Program compiled quickly and without errors
    • Compiled Blink with Board set to Arduino Due - Program compiled quickly and without errors
    • Re-downloaded Teensyduino 1.30B2 and applied it to the Arduino 1.6.10 installation
    • Compiled Blink with Board set to Arduino Uno - Program compiled quickly and without errors
    • Compiled Blink with Board set to Arduino Due - Program compiled quickly and without errors
    • Compiled Blink with Board set to Teensy 2.0 - Program compiled quickly and without errors
    • Compiled Blink with Board set to Teensy 3.1/3.2 - Program compiled very slowly and rebuilt the Core as discussed above.
    • Re-download the K66 Boards.txt file and copied it to ~Arduino1610/hardware/teensy/avr/
    • Compiled Blink with Board set to Teensy 3.6 - Program compiled very slowly and rebuilt the Core as discussed above.
    • Using Arduino 1.6.9, compiled Blink with Board set to Teensy 3.1/3.2 - Program compiled quickly and without errors


    I'm not sure what to try next. Is anyone else having this problem with 64 bit Windows 10?
    I have a bunch of older Arduino installations (each in a separate directory), They seem to work fine, and I'm hesitant to remove them as some are modified for special projects.

    Thanks

    Update: Problem Solved by disabling Trend Micro Internet & Micro Security Version 10.0.1288 (see #38)
    Last edited by Wozzy; 08-25-2016 at 10:07 PM.

  4. #29
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    7,066
    Wozzy - with the note that 1.6.10 should be short lived I never left 1.6.9 [on win10x64] as time was too short to play with beta hardware already without asking for grief, like you all is well in 1.6.9. Even a rebuild full compile under a minute on my slow i5.

    Odd and bad behavior - what do you have in the Boards Manager section? That is GLOBAL across IDE right? Maybe something there is treated oddly in the 1.6.10?

  5. #30
    Senior Member+ KurtE's Avatar
    Join Date
    Jan 2014
    Posts
    3,696
    I have 1.6.10 plus 1.30.beta2 W10 64 bit... And I build Blink, I tried for T3.6 as well as T3.2 and the verify takes under a minute. About 5 year old I7..

    Have you tried running Task manager.

    Warning, however I am running a modified 1.6.10 after Paul mentioned that there was a test version of arduino-builder.exe which hopefully tried to keep from rebuilding everything...
    But Can not find that posting anymore...

  6. #31
    Senior Member Wozzy's Avatar
    Join Date
    Jan 2013
    Location
    Philadelphia, Pennsylvania USA
    Posts
    341
    defragster- The boards managers seem similar between my 1.6.9 and 1.6.10 Arduino installations.
    Just for grins I rolled back the Uno and Due versions defaulted in my 1.6.10 installation to be the same as 1.6.9, but that didn't solve the problem.

  7. #32
    Senior Member Wozzy's Avatar
    Join Date
    Jan 2013
    Location
    Philadelphia, Pennsylvania USA
    Posts
    341
    Quote Originally Posted by KurtE View Post
    Have you tried running Task manager.
    Warning, however I am running a modified 1.6.10 after Paul mentioned that there was a test version of arduino-builder.exe which hopefully tried to keep from rebuilding everything...
    But Can not find that posting anymore
    Hmmm... This modified arduino-builder intrigues me.

    Task manager shows no unusual activity... actually I use Process Explorer from Microsoft TechNet - Highly recommended!

    Thanks
    --Wozzy

  8. #33
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    7,066
    KurtE - I lost track of that compile speedup posting too?? Almost considered 1.6.10 to try it.
    Wozzy - that was the only 'innocent'/simple but global thing that came to mind - hoped it might inspire something. Otherwise 1.6.10 seems like it might be double plus ungood. Is it the CORE recompile that runs the time toward 10 minutes? After the LONG Teensy compile - do the Uno/Due compile again normally or did it break the tree they use too?

  9. #34
    Senior Member Wozzy's Avatar
    Join Date
    Jan 2013
    Location
    Philadelphia, Pennsylvania USA
    Posts
    341
    defragster,
    Yes almost all the time is spent with compiling core.
    Even after compiling for 3.1/3.2/3.6 it still works normally for Uno/Due/T2.0.

    I guess it's time to punt back to Arduino 1.6.9 until 1.6.11 is ready,
    Other than the K66 Boards.txt change, are there any other must-do's required for Teensy 3.6 under Arduino 1.6.9?
    Last edited by Wozzy; 08-16-2016 at 09:18 PM.

  10. #35
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    7,066
    Reading that I wonder if the 1.6.10 issue WRT default tools /processor {Paul linked to} is getting confused now with the ARM is AVR placement Paul does is getting confused?

  11. #36
    Senior Member+ KurtE's Avatar
    Join Date
    Jan 2014
    Posts
    3,696
    Wozzy, you probably already tried this, but have you:

    Removed install of 1.6.10, reinstall, Install Teensyduino stuff. Rename your Arduino sketch folder to something else (or at least the libraries) and tried building?
    i.e. maybe there is some form of conflict between libraries installed by this beta and other stuff you have installed?

  12. #37
    Senior Member Wozzy's Avatar
    Join Date
    Jan 2013
    Location
    Philadelphia, Pennsylvania USA
    Posts
    341

    Still Recompiling Core S-L-O-W-L-Y

    Sorry, I was out of town for several days.
    Update: Problem Solved by disabling Trend Micro Internet & Micro Security Version 10.0.1288 (see #38)


    I updated to Arduino 1.6.11 and Teensyduino 1.30 b3 and I'm still having the same problem as noted above.
    I restored my PC to a date before I loaded 1.6.10 + 1.30 b2 then installed a freshly downloaded Arduino 1.6.11 and Teensyduino 1.30 b3.
    I let the installer use all default locations this time.

    It still works fine with Uno and Teensy 2.0, But rebuilds the core (very slowly) every time with the ARM boards.

    I noted two possible clues.

    1) is that I also see it doing the following processes (verbose) with 1.6.11 but not 1.6.9:
    These processes happen very quickly with Uno and Teensy 2.0, but very slowly with the ARM boards
    • Detecting libraries used...
    • Generating function prototypes...
    • Compiling sketch...
    • Compiling libraries...
    • Compiling core...


    2) is that if I swap in the 1.6.9 C:\Program Files (x86)\Arduino\hardware\tools directory to 1.6.11, then the Uno and T2.0 boards also compile very slowly.

    Everything is still working as normal with 1.6.9

    This is becoming very frustrating as I'm unable to try all the updated Teensy 3.6 modifications.
    Last edited by Wozzy; 08-25-2016 at 10:07 PM.

  13. #38
    Senior Member Wozzy's Avatar
    Join Date
    Jan 2013
    Location
    Philadelphia, Pennsylvania USA
    Posts
    341
    OK... I finally solved the problem by Disabling Trend Micro Security Version 10.0.1288.
    It's very odd that it only affects compiling for ARM devices with Arduino versions after 1.6.9.
    With the virus scanner disabled, I'm back to 4 to 5 second compile times with Arduino 1.6.11 with Teensyduino 1.30 B3.

    I have to completely disable the Trend Micro Virus scanner.
    I tried to add the following folders to the exception list, but It doesn't help. I couldn't find any info about if the Trend Micro program handles subfolders recursively.
    • C:\Arduino1611Teensyduino130B3
    • C:\Users\Bob\AppData\Local\Arduino15
    • C:\Users\Bob\AppData\Roaming\Arduino15
    • C:\Users\Bob\AppData\Local\Temp\builda44fb12b0eba7 c0e7e6f3fadbd5c9e7e.tmp
    • C:\Users\Bob\Documents\Arduino


    Anyway... I'm happy now and can move on to trying out the Teensy 3.6
    Thanks to all who helped along the way.
    Last edited by Wozzy; 08-25-2016 at 10:20 PM.

  14. #39
    Senior Member+ Frank B's Avatar
    Join Date
    Apr 2014
    Location
    Germany NRW
    Posts
    4,755
    Quote Originally Posted by PaulStoffregen View Post
    Let's do this as a library from source. Here's a first attempt...

    https://github.com/PaulStoffregen/CryptoAccel
    I had some trouble to use it, because it wants the *.s files to be *.S (uppercase) and i had to rename it (?!).

    Then, i guess we need some additional functions. Today, i played a bit with MD5. It needs a special padding (see wikipedia md-5 page) which is not trivial to do fast in a potential library since it is needed to extend the last block with padding bytes.
    Last edited by Frank B; 08-29-2016 at 09:52 PM.

  15. #40
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    18,664
    Quote Originally Posted by WMXZ View Post
    My hunch is, that teensy_reboot.exe, needs upgrade.
    Yes, it doesn't know about many of the newer USB Types.

    1.31-beta3 will have fully updated teensy_reboot. I just tested it (and teensy_gateway) on all 3 systems with all Tools > USB Type settings.

Posting Permissions

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