Teensyduino 1.37 Beta #1

Status
Not open for further replies.
Paul

Paul

Administrator
Staff member
Here is a first beta test for Teensyduino 1.37.


Old beta download links removed. Please use the latest version:
https://www.pjrc.com/teensy/td_download.html


Changes since Teensyduino 1.36:

SD lib, handle larger than 64K read/write
SPI lib - unified SPIClass, constexpr
Wire lib - constexpr
Use gnu++11 for 32 bit Teensy
MTP fixes
add MTP Disk to USB Type menu
Print, Stream, Serial, Serial# constexpr
analogWriteResolution returns prior setting
add missing kinetis.h register defines
availableForWrite & flush in Print class
map() improvements
fix exp10 and stricmp
Audio: improved envelope, added TDM, Waveshaper, PWM Synth, CS42448, fix I2S slave
FastLED fixes
Update MIDI to latest version
Fix PS2Keyboard
Tlc5940 fixes
XPT2046_Touchscreen interrupt fix on non-Teensy boards
Fix auto-reboot on Windows 10 rev 1703 (Creator's Update)
 
Had to CLOSE MALWAREBYTES to get install to run

w/1.37b1 Now able to upload under Win 10 Creator's Update winver=1703 and IDE 1.81

Used MSFT Win10 ISO DVD to get Creator's Update on my Win 10 Pro box - TyCommander okay - but Teensy.exe only did any upload with button press - even when IDE 'port' saw "COM7 (Teensy)".

So decided to put the 1.37b1 on this machine with IDE 1.81 and got this ERROR stoppage:
td_1.37b1err.png

This persisted with the following::
Unblocked the "TeensyduinoInstall_1.37b1.exe", and ran as ADMIN.
Closed IDE and SubLimeText with Stino - already UN-Integrated TyCommander and it was closed.
Nothing relevant in TaskMan

FOUND IT - Had to CLOSE MALWAREBYTES.
This is the first new TeensyInstall since Malwarebytes went hard core in upgrade from 2.x to 3.x and added anti ransom ware and other new stuff.

<edit>: BTW
> Malwarebytes slows compiles horribly unless RansomWare is turned off.
> If Win 10 machine is SLOW and Net freaky - the Creators Update may be failing - my four are and some customer machines. I make a disk from here - do 'Upgrade from within Windows': Create Windows 10 installation media
 
Last edited:
I have to turn off MCAfee real time scanning when I install Teensyduino... Have had to do this for sometime now....
 
Installed well on macOS Sierra 10.12.6 beta.

Motivated by the ongoing "templating" (apparently, the Teensy community woke up), I optimized some of my classes successfully by using templates. Part of this is my ftmCapture stuff which I wanted to wrap into non-templated more Arduino-ish classes, for example for a new and more performant release of the freqMeasureMulti library. But I ran into a weird issue:
Code: 
../libs/dVoxControl.h:68:27: warning: variable templates only available with -std=c++14 or -std=gnu++14
  static reData<pinA,pinB> d;
                           ^
Thus I have two choices: 1) Wrapping a whole templated class into non-templated classes (immediate workaround, but less efficient), or 2) wait for gnu++14 to be able to use partly templated members in non-templated classes
Is there a timeline for the c++14/gnu++14 transition?
 
Last edited:
I've just installed 1.37 b1 as administrator over 1.3.6 without any problems. Win 10 Creator Pro x64.
BTW I'm using Kaspersky for a/v

Pete
 
17 TD releases since IDE 1.6.0 28 months back and TD 1.20 and the dream of a 3-4 month release cycle still keeps popping up as NORMAL :)
 
Here's the release dates I see:

1.25 Sep 18 2015 (Arduino 1.6.5-r5 on Aug 28)
1.26 Nov 11 2015 (Arduino 1.6.6 on Nov 3)
1.27 Jan 5 2016 (Arduino 1.6.7 on Dec 17)
1.28 Apr 10 2016 (Arduino 1.6.8 on Mar 9)
1.29 Jul 9 2016 (Arduino 1.6.9 on May 10)
1.30 Sep 6 2016 (Arduino 1.6.11 on Aug 17)
1.31 Nov 8 2016 (Arduino 1.6.12 on Sep 21)
1.32 Dec 9 2016 (Arduino 1.6.13 on Nov 22)
1.33 Dec 14 2016
1.34 Dec 27 2016
1.35 Jan 17 2017 (Arduino 1.8.1 on Jan 9)
1.36 Mar 31 2017 (Arduino 1.8.2 on Mar 22)

We did have a rapid release of 1.33 and 1.34 due to new bugs, entirely my fault, when I rewrote the communication between Arduino and Teensy Loader.

The plan has been every 3 months, but of course when Arduino releases faster we have to track their releases.
 
Last edited:
I don't think that Paul needs to explain himself (though he did it) - it's his business.

I can imagine that his balancing act is not always easy.
On one side, he tries to maximize compatibility with the 8bit AVR world and wants his products to be accessible even to self declared noobs who want just to put together 2 shields and 5 breakouts (without soldering!), copy/paste some code from 2007 found via Google, and want that "project" to run without even asking how and why it works. Most times it doesn't work and these people seek for help and support on the internet instead of learning/studying everything systematically.
On the other side there are the power users who push the Teensy towards or even beyond its limits, be it because they have true complex projects, or be it out of scientific curiosity, or a combination of both. These users are able to write "true" constructors and destructors without begin() and end(), there are public const pointers towards private class members (to make these read only) instead of read(). They would like to have always bleeding edge technology and nightly builds of Teensyduino, and most of them would probably be happy to see all that old fashioned 8bit AVR stuff and Arduino compatibility disappear once for all, and they, after years long study and practice, wouldn't care about the copy/paste noobs cited above and their problems.

I admire Paul's diplomacy and his ability to satisfy (more or less) both camps. I think that this is part of the PRJC company's success. Thus we all (independent of each one's individual camp) should accept that there are "the others", and that these are needed too to make the Teensy products available and evolve in the long term.
 
PaulStoffregen said:
Here's the release dates I see:

1.25 Sep 18 2015 (Arduino 1.6.5-r5 on Aug 28)
...
1.36 Mar 31 2017 (Arduino 1.8.2 on Mar 22)
Click to expand...

Thanks Paul - I hit the "Teensyduino History" page and it didn't show dates - it slowed down more than I realized from 1.20 in Feb 2015 - of course multiple betas make it seem like even more. Driven indeed mostly by the onslaught of IDE updates . . .
 
Something is wrong with my ILI9341 DMA Display code with this version :-(
I have strange display effects every few seconds with 1.37 (only with 1.37)
I had'nt time to follow the forum during the last weeks. Which change/update can possible influence SPI or DMA ?
 
Hi Frank,

The SPI code has changed, but not sure how that would impact your code. Unless you changed it, doesn't your code simply use a single update of the whole screen the normal way (in order to get the SPI into data mode) and then you start of a DMAChain which cycles through, so at that point the default SPI code is not doing anything?

We now have the beginnings where all of the SPI objects are now of one class.
 
Hm. Not sure, but now it seems to be a wrong alarm... maybe a bad connection on the pinheaders (?) or something like that.
it works now..

big sorry.
 
ok. Gave 1.37-beta1 a whirl with a BNO055, Adafruit Motor Shield and a VL53L0X on I2C and no issues. The sketch is using the following libraries:
Code: 
#include <Wire.h>
#include <EEPROM.h>
#include <StopWatch.h>
#include <elapsedMillis.h>
#include <Streaming.h>
#include <StopWatch.h>
#include <Servo.h>
//#include <vector>
#include <Adafruit_MotorShield.h>
#include "utility/Adafruit_MS_PWMServoDriver.h"
#include <Adafruit_Sensor.h>
#include <Adafruit_BNO055.h>
#include <utility/imumaths.h>
#include <VL53L0X.h>

Everything compiled fine and ran. Even using a RC controller to move the rover manually and no issues with that either. I also have a openmv camera sending info over Serial3 and no issues. The only issue is with including "vector" which is throwing an error which I mentioned in the Arduino 1.8.3 thread.

Mike
 
Just tried to run a simple example for using cout and cin and receiving the following errors which is the same as I received for vector:
Code: 
In file included from c:\local programs\arduino-1.8.2\hardware\tools\arm\arm-none-eabi\include\c++\5.4.1\bits\char_traits.h:39:0,
                 from c:\local programs\arduino-1.8.2\hardware\tools\arm\arm-none-eabi\include\c++\5.4.1\ios:40,
                 from c:\local programs\arduino-1.8.2\hardware\tools\arm\arm-none-eabi\include\c++\5.4.1\ostream:38,
                 from c:\local programs\arduino-1.8.2\hardware\tools\arm\arm-none-eabi\include\c++\5.4.1\iostream:39,
                 from C:\Users\CyberPalin\Desktop\sketch_jun04a\sketch_jun04a\sketch_jun04a.ino:3:

c:\local programs\arduino-1.8.2\hardware\tools\arm\arm-none-eabi\include\c++\5.4.1\bits\stl_algobase.h:243:56: error: macro "min" passed 3 arguments, but takes just 2

     min(const _Tp& __a, const _Tp& __b, _Compare __comp)

                                                        ^

c:\local programs\arduino-1.8.2\hardware\tools\arm\arm-none-eabi\include\c++\5.4.1\bits\stl_algobase.h:265:56: error: macro "max" passed 3 arguments, but takes just 2

     max(const _Tp& __a, const _Tp& __b, _Compare __comp)

                                                        ^

Error compiling for board Teensy 3.5.

Here is sketch that threw the error:
Code: 
// i/o example
#include <iostream>

void setup() {
  //
}

void loop() {
  int i;
  cout << "Please enter an integer value: ";
  cin >> i;
  cout << "The value you entered is " << i;
  cout << " and its double is " << i*2 << ".\n";
  
}

Mike
 
Never knew that one, but then again never gave it a try before. Always used the Streaming library before because I was always using Arduino's, primarily Mega's, until recently. Moved over to the teensy 3.5 only because it 5v tolerate, easier for my robot projects.

Thanks
Mike
 
Please let me know if there are any issues with the Streaming lib on Teensy 3.5. As far as I know, it should "just work". I don't personally use the Streaming syntax for printing, so I'm depending on feedback for that library....
 
Been using Streaming with the 3.5 from day one and through 1.37-beta1 with absolutely no issues so far. All works well. The sketches I use for my robotics projects I pretty much listed in message #16 above. The only one I have not tested yet is NeoGPS which seems to give me better results that TinyGPS.
 
I know this thread is old, but, just had to respond to this... :)

PaulStoffregen said:
As far as I know, C++ cin & cout have never worked in any version. Likewise, bare printf() is also unsupported.

You do get Serial.printf(), and there is a Streaming library by Mikal Hart that adds the C++ streaming syntax.
Click to expand...

That is kind of funny, especially since I have used printf(); on Arduino and Teensyduino and on many other platforms that integrate into Arduino, for many, many years. You just need to know the special sauce to do it across all platforms.

I have actually included this support in UHS3.0 because serial.print and all the other fluff simply is not normal or natural to me, besides, there is a lot of RAM on these Freescale chips, so malloc really has never been an issue, once you protect it from ISRs, which UHS3.0 also does. This allows you to use printf from within an ISR, which is more informative than blinking an LED or watching on your scope for a pin to change levels. I can even redirect STDERR and STDOUT to two different hardware serial ports, thus I get debug and no corrupted data, and a normal API.
 
@xxxajk sounds interesting, care to give some details about "the special sauce"?
 
Status
Not open for further replies.
Back
Top