Teensyduino 1.36 Beta #4

Status
Not open for further replies.
Paul

Paul

Administrator
Staff member
Here is a fourth 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 1.36-beta3:

  • Support for Arduino 1.8.2
  • Serial.begin() waits up to 1 second for serial monitor open
  • analogWriteFrequency minimum on Teensy LC
  • Fixes in ADC library (KurtE)
  • Fixes in RadioHead library (KurtE)
  • Libraries updated: ADC, Snooze
 
I installed 1.36b4 on my Win_10 IDE 1.81 with No Problem - and The changes to Serial startup are good! The split of the delay across usb_init() before calling setup() combined with Serial.begin() returning when USB is online gets into setup() at <edit> ~420 ms when on USB2 hub, USB3 slower.

Per post for 1.36b3: To see and test this to work run this sketch and post any problems so Paul can evaluate the delay() split.
View attachment TimedStartBlink_MIN.ino

This brings up USB MORE reliably/faster and better than ever in SerMon and TyComm!

Paul - you said you may work on IDE SerMon - One remaining issue I see is SerMon when Teensy unplugged and replugged on Win_10 does not reconnect - must close SerMon and re-open (to same COM# port) to have it reconnect. {TyComm handles this perfectly of course} SerMon does reconnect across Upload as it should.

<edit:> No problem but the above test code needs to be re-written to account for the new Serial.begin() behavior.
To not have the time check fooled by new Serial.begin() behavior setup() needs to start like this for sketch above:
void setup() {
BOOT_on_Time = millis();
pinMode(LED_BUILTIN, OUTPUT);
digitalWriteFast(LED_BUILTIN, HIGH );
Serial.begin(57600);
Serial_on_TimeS = Serial_on_TimeL = millis();
while ( !Serial && millis() < 2000 ) {
Click to expand...
 
Last edited:
I have installed it on Windows 10 machine on the new 1.8.2... Not sure what changes happened with 1.8.2... Hopefully they will update the change listing.

So far so good. Will probably also install on another platform as well.

But I also probably need to move out several of my own local copies (git) of libraries out of my <sketchfolder>/libraries as to test with the current stuff.

Wondering what others do? I often will then sync up my library go back to master branch and compare to the one installed, but alternatively could move these libraries out of the sketch/libraries folder to some other location and update github for windows... Or in some cases my changes were incorporated, could simply delete my fork... But in some cases may still want to make changes in the future...
 
Works well on my MacBook, projects compile as before. Eclipse (Sloeber) and TyQt didn't complain either.

My desired #defines which I posted in the beta3 thread didn't obviously make it into beta4.
 
I'll check that out and look deeper into that.

The only test I did up to now was recompiling my project and I think the compiler should have complained about my local defines if these had been defined before in a header file.
 
Theremingenieur said:
I'll check that out and look deeper into that.

The only test I did up to now was recompiling my project and I think the compiler should have complained about my local defines if these had been defined before in a header file.
Click to expand...

If the #defines are the same, the compiler won't complain. But it may also be you have your own version of the standard files, and the compiler is picking up those.
 
Please accept my apologies for the wrong alert based on my lack of understanding the compiler.

I removed my local defines, recompiled, and everything works still fine!
 
KurtE said:
Wondering what changed in 1.8.2? So far don't see any updated release notes.
Click to expand...

Yeah, I was wondering the same thing. I tracked down this post on the arduino forum:

ARDUINO 1.8.2 2017.03.22

[ide]
* Fix command line: works again with relative paths (regression)
* Fix command line: "--save-prefs" works again (regression)
* AVR toolchain has been updated with a tentative fix for the
ld-returned-5-exit-status bug
* Update arduino-builder to 1.3.25
- avoid name clashing for libraries
- cache core archives to speedup compilation consistently
* Allow BoardManager to fetch FreeBSD tools (thanks @kevans91)
* Serial monitor: the input string box is automatically focused when window
is selected
* Serial monitor: now can not be opened during upload
* Serial monitor: now properly decodes UTF8 characters (thanks @aknrdureegaesr)
* Serial monitor: added 500k, 1M and 2M baudrates (thanks @dsstutts)
* Updated RSyntaxTextArea to 2.6.1 (textarea component)
* Updated jmdsn (mDNS discovery)
* Allow plugins to attach a listener to compile progress (thanks @tomneutens)

[core]
* Add Atmel-ICE and JTAGICE3 programmers for AVR chips (thanks @matthijskooijman)
* AVR: Set unused bits of extended fuse to 1, should remove some avrdude warning
during burn bootloader (thanks @descampsa)
* AVR: USB: send ZLP when needed (allows full 64 bytes packets)
* AVR: USB: use IAD descriptors instead than Generic (thanks @cuitoldfish)

[other]
* SAM platform source code has been moved to its own repository
(https://github.com/arduino/ArduinoCore-sam) - all PRs and issues
have been moved as well
* Update Wifi101 Firmware Updater plugin
Click to expand...
 
I read on another thread an issue with malloc sometimes corrupting the stack. Does the fix for this anomaly appear in 1.36?
 
I have just installed this beta on top of 1.8.2 with no errors. I am using MacOS 10.12.3 and have never had as issue installing or using this on my MacBook Pro.
 
From an earlier 1.36 beta thread:
"...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."

Still looking good for the end of March?
 
twilkers said:
I read on another thread an issue with malloc sometimes corrupting the stack. Does the fix for this anomaly appear in 1.36?
Click to expand...

Yes, fixed.

DaQue said:
.... or at least before the end of March if things slip.

Still looking good for the end of March?
Click to expand...

Yes, I believe it's probably time to just wrap up 1.36.

Last week I started working on this issue and ended up spending a lot of time diving deep into I2C bus arbitration issues. Then over the weekend I attended an Art Hack Day, which was a lot of fun but 3 solid days away from Teensyduino development. Now everything's about a week behind...

I'm probably going to leave the Wire library as-is, and dig into the arbitration & corrupted signal recovery stuff for 1.37.
 
PaulStoffregen said:
Then over the weekend I attended an Art Hack Day, which was a lot of fun but 3 solid days away from Teensyduino development. Now everything's about a week behind...
Click to expand...

I dunno, the last thing we want is for you to burn out. While it is useful to have new releases of Teensydunio when Arduino makes a new release, I would say having to wait a few more days where we have to still use 1.8.1 will be fine for most.
 
If anyone else is willing to help test, I could sure use a hand with testing this beta.

Any testing libraries FastLED, ADC, RadioHead, AccelStepper & TouchScreen would be the most helpful. ;)
 
MichaelMeissner said:
I dunno, the last thing we want is for you to burn out. While it is useful to have new releases of Teensydunio when Arduino makes a new release, I would say having to wait a few more days where we have to still use 1.8.1 will be fine for most.
Click to expand...

Yup I agree. If its end of April I'm fine with that. I think its better for all if I don't beta test. I ask enough dumb questions on the stable releases ;)
 
Possible I2C issue. I installed IDE 1.8.2 with the teensy 1.36 beta 4 teensyduino. I have a Adafruit BNO055 attached to I2C. It seems like every time I upload a sketch to a Teensy 3.5 it does not see the device anymore. If I cycle the power it will see the device but the values that are being read are incorrect for yaw, pitch and roll. The come out on the order of 0.06 or 1 deg for each axis and do not change. If I revert back to 1.8.1 it works fine no problem.
 
@mjs513 :: This may be a side effect of USB serial coming online faster and not allowing the I2C device time to reset/restart. The new code can have USB online some 300-350 ms faster. If the following shows that you would need to add a sufficient wait to make up for that and allow the i2c device to be ready.

You didn't post a working sample - I assume in both cases you have Serial.begin() in some fashion before the _i2c_.begin()? And perhaps a wait of "while( !Serial );"?

Put something like this before the _i2c_.begin() to show the time after boot { in both copies of the IDE } when that code is hit:

Code: 
Serial.begin( 19200 );
Serial.print( "millis here ==" );
Serial.println( millis() );
// _i2c_.begin() code

Based on the comparison - the fix may be "delay(350)" or "while( millis()<900 );" - whatever it takes to make up the time difference before _i2c_.begin().
 
Last edited:
mjs513 said:
I have a Adafruit BNO055 attached to I2C. It seems like every time I upload a sketch to a Teensy 3.5 it does not see the device anymore. If I cycle the power it will see the device but the values that are being read are incorrect for yaw, pitch and roll. The come out on the order of 0.06 or 1 deg for each axis and do not change. If I revert back to 1.8.1 it works fine no problem.
Click to expand...

Can you tell me more about how you're testing? Are you running one of Adafruit's examples, or your own program?

I tried running the Adafruit_BNO055 rawdata example. It seems to work here.

sc.png

I'd like to investigate... but I need find a way to reproduce the issue with my BNO055.
 
Paul. I using a modified example in my robotics project. Let me give @defragster solution a try and see what happens. If I still have problems I can send you the part of the code that I use to initialize the BNO055. Or I can post the whole thing to GITHUB and let you take a look. The BNO055 is in its own tab so it would be easy. let me know. It is the only thing on the I2C bus but I am using some threads, and attaching all kinds of other stuff to the Teensy 3.5.

UPDATE
Using this as the code to measure millis:
Code: 
Serial.print( "millis 0 here ==" );
Serial.println( millis() );
    telem.begin(57600);
Serial.print( "millis here ==" );
Serial.println( millis() );
    //Wire.begin();
    Wire.setClock(400000L);

With 1.8.1: millis0 = 5404, millis = 5404. Almost no delay. (had to put a delay of 5000 in so give me time to open monitor
With 1.8.2: millis0 = 404, millis = 1405. So this is some delay. In this case I did not have to put in the delay.

But now I am noticing I am having problems when I upload an updated sketch even with 1.8.1. By this I mean I load the sketch and the BNO has no problems. I make a mod to the sketch and then the BNO hangs and have to power cycle.

Update 2: put the delay in then I started getting oops no device found for the sensor. Had to toggle again. As a test l loaded up the rawdata sketch and had no problems with it coming on line. Made a change and reloaded and again no problem. Must be something conflicting in my sketch.

Here is a link to the GITHUB for the sketch (not simple). https://github.com/mjs513/Teensy3.5_Obstacle_Avoid_TestBed/tree/master/Teensy35_rover_threaded
 
Last edited:
@mjs513: What TeensyDuino is in use on both IDE's? The current 1.36 beta4 will delay in Serial.begin() for up to 1000ms {where clock is 400 ms at entry to setup()} allowing USB SerMon to connect. TD_1.35 and before never waited - it just happens.

See my post #2 above for what I usually do - with assuring Serial is ready before trying a real time print. In 1.36 with a ready SerMon USB will be online after Serial.begin() before 1.36 it won't be online until after this: "while ( !Serial && millis() < 2000 ) { "

I found setup() here ? :: github.com Teensy35_rover_threaded.ino

That code doesn't look like I expected like above - Serial.print on entry to setup() likely doesn't work 'real time' as the Teensy isn't connected yet. Entry time there is 400 ms after Teensy initialization.

Your problem may be elsewhere - I perhaps wrongly assumed it was pre td_1.36 on IDE 1.8.1 and TD_1.36 on IDE 1.8.2 - I instigated Paul's change to usb_init changes before setup() in TD_1.36 - so I was looking to make sure that wasn't behind your issue.
 
@defroster. In 1.8.1 I am using TeensyDuino 1.35. In 1.8.2 I am using TeensyDuino 1.36 beta 4. Sorry about the timing I was misinterpreted your suggestion. Think I am working too many projects one time. I did find the issue related to the data from the BNO. Its all thread related. Readings for the BNO work fine in the non-threaded application. Think I may have another problem that I am going to check on tomorrow.
 
@defragster. I added the delay just like you recommended and that seemed to resolve the startup issue. I was also able to fix the my data issue by adjusting the thread coding. Thanks very much. Its nice not to have cycle the power anymore.
 
Status
Not open for further replies.
Back
Top