PDA

View Full Version : Teensyduino 1.36 Beta #2



Paul
03-15-2017, 07:53 PM
Here is a second beta test for Teensyduino 1.36.


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


Changes since version 1.36-beta1 (https://forum.pjrc.com/threads/41568-Teensyduino-1-36-Beta-1-(ARM-Toolchain-Update)):


Link Time Optimization (LTO) no longer default
Ethernet socketBeginMulticast (manitou)
Fix IntervalTimer on Teensy 3.5
Wire library supports Wire1, Wire2
Wire library timeouts for error conditions
Libraries updated: AccelStepper, Audio, FastLED, ShiftPWM, LedDisplay, TouchScreen
Minor improvements to AVR emulation
Hardware serial write() compatibility fix
Fix pin config on Serial6
Add extreme joystick, disabled by default, edit usb_desc.h
Fix String test as boolean
Faster installation, especially on Mac

defragster
03-15-2017, 08:13 PM
sticky current "Beta/Release" posts while active would keep them from getting bumped down when an older announcement gets pinged.

PaulStoffregen
03-15-2017, 08:43 PM
Probably the biggest change, the thing most in need to beta testing, is the Wire library. I did quite a lot of testing over the weekend, but I can't try every program using I2C communication with Wire!

Now you can use Wire1, Wire2, Wire3 to access the other ports on Teensy LC, 3.2, 3.5, 3.6, and of course the usual Wire accesses the main I2C port. The library now uses a thin abstraction layer, rather than just hard-coding everything for the main port. I also added timeouts for various error conditions, like the bus stuck busy or a slave device clock stretching for a ridiculously long time.

To save memory, by default Wire1 on Teensy LC and Wire3 on Teensy 3.6 are not instantiated. To use these, put these lines near the top of your program:



TwoWire Wire(KINETIS_I2C0, TwoWire::i2c0_hardware);
void i2c0_isr(void) { Wire.isr(); }



TwoWire Wire3(KINETIS_I2C3, TwoWire::i2c3_hardware);
void i2c3_isr(void) { Wire3.isr(); }


I'm considering just making Wire3 instantiated by default on Teensy 3.6, since it has so much RAM. Then again, with the pins only accessible on the bottom side and with 3 other ports easily available, widespread use of Wire3 seems pretty unlikely.

If you get a chance to do any testing with Wire on any boards, please reply here, even if only "tried XYZ, worked fine". Thanks!

KurtE
03-15-2017, 08:53 PM
Looks good - At some point you might want to take a look at some of the other Pull requests like SPI (faster output with transfer of a buffer)

KurtE
03-15-2017, 08:55 PM
To save memory, by default Wire1 on Teensy LC and Wire3 on Teensy 3.6 are not instantiated. To use these, put these lines near the top of your program:



TwoWire Wire(KINETIS_I2C0, TwoWire::i2c0_hardware);
void i2c0_isr(void) { Wire.isr(); }



TwoWire Wire3(KINETIS_I2C3, TwoWire::i2c3_hardware);
void i2c3_isr(void) { Wire3.isr(); }


Is the first one correct? Looks more like Wire0...

PaulStoffregen
03-16-2017, 07:07 AM
Looks good - At some point you might want to take a look at some of the other Pull requests like SPI (faster output with transfer of a buffer)

Done. I've merged several other fixes and improvements today. Will probably make another beta by the weekend.

I'd like to "freeze" features for 1.36 by this weekend and finalize 1.36 sometime next week, or at least before the end of March if things slip.



Is the first one correct? Looks more like Wire0...

Opps, yes, that's the wrong one. For Wire1 it should be:



TwoWire Wire1(KINETIS_I2C1, TwoWire::i2c1_hardware);
void i2c1_isr(void) { Wire1.isr(); }

defragster
03-16-2017, 08:52 AM
FOR CONSIDERATION:: Paul put in my suggestion to split the delay(400) (https://github.com/PaulStoffregen/cores/commit/da92eda747fe7b65d7898401410c221b385b3c92) before setup() is called.

<edit>: If you'd like to see Teensy Serial online some part of 350 ms faster (depending on hardware and Serial Monitor)please Beta test this as USB can be finicky and without decent testing it (or if odd cases show up) won't get released. Code below shows a simple set of time checks and prints for setup. Code change is in the github link above - but seems like it may be committed and coming out in 1.36b3 for test. Whatever your setup this shouldn't be slower and setup() entry time is the same - though as noted I've found TyCommander to be faster and picking up the Teensy with this change than IDE SerMon.

Without that change T_3.0 and T-3.6 shows Serial online between 800ms and 950 ms with TyComm depending on USB port type. Times after Upload and Reset can vary.


Made those changes to my 1.36b2 install. T_3.6 boots to setup in 400ms as expected.

Using TyComm as SerMon Serial USB is seen online and printing at 414-433 ms. IDE SerMon when I was testing improved - but not as fast. Same for both of these tested on my Amazon Basics USB2 hub, my DELL monitor hub (FrankB said his similar has some slowness?)

Front panel USB3 shows Serial at ~550ms. USB3 Hub USB3 and its USB2 ports shows ~450ms

Also tested T_3.0 on same ports with same sketch and got same results

Sketch for test reference: 9989
Shows setup entry time then millis when while(!Serial) exits - then blinks LED and shows millis each 10 seconds:

BOOT_on_Time=400
Serial_on_Time=411
millis() =10412

where that comes from this in the attached code:

setup(){
BOOT_on_Time=millis(); // print 400
while(!Serial);
Serial_on_Time=millis(); // print 411

KurtE
03-16-2017, 02:15 PM
Hi Paul,

I am trying out the new Wire library and converting my Well monitor program back from i2c_t3 to wire... (Modified version of Adafruit_SHT31 library)

Running into a few issues in conversion back, like I was using I2C_STOP, which I locally defined as 1... Also was using timeout... in requestFrom.

Looking over the new requestFrom:

Wondering: What the proper behavior should be if you ask for 6 bytes and times out after 3 bytes.
Current code in the SHT31 library was doing:


boolean Adafruit_SHT31::completeReadTempHum(void) {
uint8_t readbuffer[6];

Wire.requestFrom(_i2caddr, (uint8_t)6, I2C_STOP, I2C_T3_TIMEOUT);
if (Wire.available() != 6)
return false;
...
So conversion is to remove the TIMEOUT parameter as there is no template for 4 parameters...

Looking over the code it looks like if I get a timeout condition, the code now will return how bytes were actually received. However rxBufferLength is not updated so will will be zero, and so Wire.available will return 0. Also the read method checks for rxBufferIndex and rxBufferLength so it will not allow you to retrieve any of the values that was read before timeout. Not sure if that is the intended behavior? In my case it does not matter as I want all or nothing...

Edit: I finished compiling for T3.6 and tested on the two boards one with the SHT31 and one without and it properly timed out on the one without (used to hang)... And it reads OK on the one with the sensor. Currently tested on Wire object

Theremingenieur
03-17-2017, 11:17 AM
Install on my MacBook Pro took much less time than before. Like it!!!

What I would still like now, is an auto-update feature. That means that at startup, it would look for a new version (configurable beta or only full releases) and suggest to install it. Eclipse has that, and it's very comfortable.

PaulStoffregen
03-17-2017, 12:30 PM
However rxBufferLength is not updated so will will be zero, and so Wire.available will return 0. Also the read method checks for rxBufferIndex and rxBufferLength so it will not allow you to retrieve any of the values that was read before timeout. Not sure if that is the intended behavior?

Oh, that's a good point....

PaulStoffregen
03-20-2017, 09:27 AM
Looking over the code it looks like if I get a timeout condition, the code now will return how bytes were actually received. However rxBufferLength is not updated so will will be zero, and so Wire.available will return 0.

Fixed.

https://github.com/PaulStoffregen/Wire/commit/db6faf319bd9ba962b5e87284bffe979ff9c0a5b