Teensyduino 1.30 Beta #2 Available

Status
Not open for further replies.
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
 
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:
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:
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?
 
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...
 
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.
 
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
 
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?
 
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:
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?
 
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?
 
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:
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\builda44fb12b0eba7c0e7e6f3fadbd5c9e7e.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:
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:
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.
 
Status
Not open for further replies.
Back
Top