Teensyduino 1.41 Released

Status
Not open for further replies.

Paul

Administrator
Staff member
Teensyduino 1.41 has been released.

https://www.pjrc.com/teensy/td_download.html


Changes made since 1.40-beta4:

Drop support for Arduino 1.9.0-beta34
Libs updated: FastLED, Adafruit_NeoPixel, Adafruit_GFX
Libs removed: NewPing
Add USB MIDI Many_Knobs_Buttons example (oddson)
USBHost_t36 minor Joystick fix (KurtE)
Minor updates to various USB MIDI examples
 
This is the full list of changes, from 1.40 to 1.41:


  • Add IntervalTimer update()
  • Ethernet fix socket receive state caching bug
  • Ethernet improve handling of unexpected remote server disconnect
  • SD fix timeouts
  • SPI pin changes kept in sync with AVR SPI emulation
  • SPI avoid interfere with pin 45
  • Wire force recovery from stuck slave devices
  • Wire improve detection of arbitration loss to other bus masters
  • Add AudioConnection disconnect() (thanks b0rg3rt)
  • Update platform.txt for compatibility with Arduino 1.9 beta
  • Fix serial stall if higher than maximum baud rate configured
  • Improve delayMicroseconds on Teensy 2.0 (Graham)
  • Fix SERIAL_8N2 mode on Teensy LC
  • Update sample Makefile
  • Add abort() function, needed for Pozyx library
  • Update keywords for Serial formats & USB Keyboard special keys
  • Improve AVR SPI register emulation, speed bits
  • Fix tone() issue when 0 Hz requested, minimum is 1 Hz
  • Fix Teensy LC DMAChannel bug (thanks kbob)
  • Audio add ADAT output (thanks Ernstjan Freriks)
  • Audio fix RMS analysis when no data
  • Audio ToneSweep improvements (thanks Pio)
  • Audio design tool custom name bug fixed (thanks neurofun)
  • Audio modulated sine amplitude when no mod signal fix (thanks neurofun)
  • Audio library documentation updated, several minor errors fixed
  • FastLED updated to support WS2812Serial
  • Time library minor updates & fixes
  • i2c_t3 library updated
  • OctoWS2811 fix on Teensy 3.5
  • OctoWS2811 remove unnecessary delay
  • OctoWS2811 improve setPixel speed (thanks sgorsh)
  • USBHost_t36 support for CDC-ACM, PL2303 & CH341 serial (thanks KurtE)
  • USBHost_t36 support for RawHID (thanks KurtE)
  • USBHost_t36 support for Xbox One controller (thanks KurtE)
  • USBHost_t36 improve keyboard & joystick support (thanks KurtE)
  • USBHost_t36 fix USB MIDI fast data input
  • USBHost_t36 Ant+ wireless adaptor support (adapted from Michael McElligott)
  • USBHost_t36 access to device ID and name (thanks KurtE)
  • XPT2046_Touchscreen detect touch by interrupts (thanks Donziboy2 & Defragster)
  • Accept String in Stream find() and findUntil()
  • Update LedDisplay library
  • USBHost_t36 Fix device status functions usage in polling loops
  • USBHost_t36 Clean up bandwidth usage info when deleting a pipe
  • USB MIDI support for virtual cables (select from Tools > USB Type menu)
  • USB MIDI updated with most functions of Arduino MIDI lib 4.3.1
  • USB MIDI getType() now returns same as MIDI 4.3.1 -- NOT BACKWARDS COMPATIBLE
  • Support for compatibility with Arduino's MIDIUSB.h
  • Added more examples in File > Examples > Teensy > USB_MIDI
  • USBHost_t36 MIDI support for virtual cables
  • USBHost_t36 MIDI updated with most functions of Arduino MIDI lib 4.3.1
  • USBHost_t36 MIDI returns same as MIDI 4.3.1 -- NOT BACKWARDS COMPATIBLE
  • USBHost_t36 MIDI fix for devices using interrupt endpoints
  • USBHost_t36 MIDI workaround for devices sending improperly coded sysex message
  • XPT2046_Touchscreen add setRotation()
  • FreqMeasureMulti fixed on Teensy LC (thanks Manitou)
  • USB MIDI & USBHost_t36 MIDI pitch bend using signed integer -- NOT BACKWARDS COMPATIBLE
  • USB MIDI & USBHost_t36 Fix receiving some MIDI sysex messages
  • USB MIDI add Interface_3x3 example
  • USBHost_t36 fix MIDI getType for note off messages
  • USBHost_t36 add MIDI Interface_16x16 example
  • Adafruit_SSD1306 uses 400 kHz in I2C mode
  • USBHost_t36 Joystick improvements, More Axis, Rumble, LEDs (KurtE)
  • Libs updated: FastLED, Adafruit_NeoPixel, Adafruit_GFX
  • Libs removed: NewPing
  • Add USB MIDI Many_Knobs_Buttons example (oddson)
 
Libs removed: NewPing.
Is there a substitute for those wanting a "NewPing" function?
I am in the process of building a 2WD Arduino rover with an Ultrasonic sensor. I'm currently planning to use an Arduino UNO (came with the kit) but could upgrade to a Teensy 3.6 in the future since I have one.
 
No need for FOMO (fear of missing out). ;)

Is there a substitute for those wanting a "NewPing" function?

In Arduino, click Sketch > Include Library > Manage Libraries. Then type "newping" into the "Filter your search..." box. Arduino's library manager will give you version 1.9 (the latest).

Tim changed the license to disallow forks. In conversations on Arduino's issue tracker, he requested distribution via his repository (and presumably Arduino's library manager). Apparently he was suffering quite a lot of extra support burden by several forks people had made.

Even though version 1.8 was GPL license, which allows us to distribute, I removed it from Teensyduino when I saw Tim's conversation.
 
Thanks, Paul.
I thought that it might have been removed due to some incompatibility with the new Lib, meaning that "NewPing" couldn't be used.
 
Someday Arduino will probably do more to detect missing libraries and maybe install them automatically, or in a semi-automated way, or at least advise users how install the libs they need alongside the compiler errors. When/if that day comes, and assuming it actually works well, I'll probably remove several of the libs from Teensyduino. Long ago they all needed patches. Some still do, but now that Teensy is pretty well established in the Arduino world, most of the patches have been merged into the libraries. The only point to keeping them in Teensyduino is so programs "just work" rather than giving you a compiler error about missing .h files, and no clear instructions or clickable button to automatically install the missing lib.
 
Thank you very much for all the great new MIDI stuff!

I've installed this version and got my DAW midi controller (Teensy 3.6) up and running. Receiving SysEx messages (up to 119 bytes) on two cables is working perfectly. I'm using the Serial + MIDI x 4 setting.

Kind regards,

Gerrit
 
That is a LOT of hard work, Paul. Thank you! I've had a rough time over the last few weeks with a high-pressure project and albeit with a few hiccups(https://forum.pjrc.com/threads/49196-PJRC-store-corrections) the teensy platform hasn't let me down, including some after-sales support with shipping etc. I like the way your products are usually well-documented and supported, make things easy and are of high-quality. Please keep up the good work and thank you(& Robin).
 
I tried to install it (1.41 as downloaded today) with an installed Arduino "1.9.0-beta", but it didn't want to. What am I doing wrong?

Host: MBP with macOS 10.12.6.
 
OK, thanks.

The download page didn't mention this, just that support for the beta was introduced. I'm using the beta because 1.8.5 loads very slowly. Guess I'll go install that now.

Again, thanks.
 
I dropped support for Arduino 1.9-beta based on the very negative feedback we heard during 1.41-beta3 and 1.41-beta4.

Turns out 1.9-beta has some pretty bad bugs, including a memory leak that causes lockups on Windows and annoying problems with keyboard focus in the search/replace dialog box.

If you *really* want to try 1.9-beta anyway, you could download the files from that 1.41-beta4 thread. They're still on the server, at least for now. Relatively few changes were made between 1.41-beta4 and 1.41 release. If you want those minor changes, just grab the latest versions of those libraries which were updated.
 
Indeed I'm still using the 1.90 beta and TD_1.41b4 combo - but thinking of reverting to 1.85 because the slightest code error is hard to find as the pre-processor mangles line numbers and never points close to where I dropped a semi-colon or whatever. And additionally the Ctrl-F focus is really annoying when not using external editor. Both make for interrupted work flow. And the big win of parallel compile is only BIG the first time when the whole core is compiled.
 
Turns out 1.9-beta has some pretty bad bugs, including a memory leak that causes lockups on Windows and annoying problems with keyboard focus in the search/replace dialog box.
Even 1.8.5 has some bug, too. My program would not build with 1.8.5, but it builds just fine with 1.8.4 and either 1.39, 1.40, or 1.41.
That could be because I'm #including .cpp files, but still.
 
My program would not build with 1.8.5, but it builds just fine with 1.8.4

If you want me or anyone else to take a look, possibly investigating the bug to the point of a useful issue report for Arduino... you've got a show us the complete code so we can click Verify and get the error.

If the code isn't a proprietary secret, please don't be shy. Many bugs in Arduino have been reported due to investigation that started on this forum. The Arduino devs usually do fix bugs pretty well when they get a well written issue report.
 
Even 1.8.5 has some bug, too. My program would not build with 1.8.5, but it builds just fine with 1.8.4 and either 1.39, 1.40, or 1.41.
That could be because I'm #including .cpp files, but still.

Using #include literally? Or placing them in the same sketch directory and having the IDE include them? I've seen/used the 2nd way some - odd the newer IDE doesn't accept the same as the old though perhaps the sketch processor is getting confused if they are altering it - though it sounds like it worked under the 1.90 beta?

Can you make a header of prototypes for them so they look like a library in the sketchbook\libraries folder to better effect?
 
Using #include literally?
Yup...
Or placing them in the same sketch directory and having the IDE include them? I've seen/used the 2nd way some - odd the newer IDE doesn't accept the same as the old though perhaps the sketch processor is getting confused if they are altering it - though it sounds like it worked under the 1.90 beta?
No, I do the inclusion explicitly. The additional files are in a "Module" directory, so I just have a few "#include Module\[some-name].cpp" in the .ino file. Works fine under 1.8.4... ;)

Can you make a header of prototypes for them so they look like a library in the sketchbook\libraries folder to better effect?
I'm not fully sure what you're asking for. I have all the function prototypes declared before setup(), otherwise the code wouldn't compile.
The reason I'm doing this strange inclusion because I really hate files longer than a few hundred lines or so. I do know that it's a somewhat (?!) peculiar approach, but as long as it works...
 
If you want me or anyone else to take a look, possibly investigating the bug to the point of a useful issue report for Arduino... you've got a show us the complete code so we can click Verify and get the error.
Will look into creating a simple, pared down code that exhibits the same issue. I also have another issue (probably programmer error :( ) that may need another set of eyes.
 
... not sure how the IDE concept of Library is fully realized - but if ...\'sketchbook'\libraries\"Module" were a folder with the module.h and associated .cpp files in it - Putting #include module.h in the sketch - the IDE could follow through and compile those external files as needed to get the needed code included in the end - without stuffing it into the .ino file where confusion reigns. There are likely rules about names and organization to make that work - but that is what a library is made to provide. And it seems the IDE may need to be restarted to scan that libraries folder to identify target code. Maybe this would be contrary to how you want to maintain the "Module" code - but it is how the IDE can provide it as a generic library ... AFAIK
 
That could be because I'm #including .cpp files, but still.

When I break up my code in that way, I simply put my cpp code into a .h file and call it from my main application code.

I should note that my ino file is completely empty (no setup, loop functions) and I have an own Main.cpp file where setup, loop and all other main code resides.
This way Arduino can do what it wants with the .ino file, I don't care. Obviously all cpp file are constructed following the common programming rules.
I call then 'external' code via include from main.
when I'm happy with code and need re-usability then I generate private library.

(caveat: I still use 1.83)
 
I also went the route @WMXZ did for some projects, like my Phoenix In Parts project for hexapods...

Where the main.ino you simply have a local header file with options and your main ino file that just includes everything like:
Code:
#define DEFINE_HEX_GLOBALS
#include <Arduino.h>
#include <EEPROM.h>
#include <ax12.h>
#include <BioloidEx.h>

#include "Hex_Cfg.h"

#include <Phoenix.h>
#include <Phoenix_Input_Commander.h>
#include <Phoenix_Driver_AX12.h>
#include <Phoenix_Code.h>
The init and setup functions are in the <Phoenix_Code.h> file... And there are different header files to include depending on which IO device you are using to control the hexapod and which Servo driver you need to drive your servos or the like...

At that time I gave up trying to figure out how to get the necessary configuration information into the different libraries, where I might have several different robots with completely different configurations and did not want to keep different versions of the code...
 
Status
Not open for further replies.
Back
Top