Forum Rule: Always post complete source code & details to reproduce any issue!
Page 1 of 2 1 2 LastLast
Results 1 to 25 of 34

Thread: Teensyduino 1.36 Beta #4

  1. #1
    Administrator Paul's Avatar
    Join Date
    Oct 2012
    Posts
    305

    Teensyduino 1.36 Beta #4

    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

  2. #2
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    6,752
    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.
    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 ) {
    Last edited by defragster; 03-23-2017 at 04:56 AM.

  3. #3
    Senior Member+ KurtE's Avatar
    Join Date
    Jan 2014
    Posts
    3,636
    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...

  4. #4
    Senior Member+ Theremingenieur's Avatar
    Join Date
    Feb 2014
    Location
    Colmar, France
    Posts
    1,769
    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.

  5. #5
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    18,153
    Quote Originally Posted by Theremingenieur View Post
    My desired #defines which I posted in the beta3 thread didn't obviously make it into beta4.
    I put them in.

    https://github.com/PaulStoffregen/co...15fe9147abe974

    Maybe I made a mistake somewhere?

  6. #6
    Senior Member+ Theremingenieur's Avatar
    Join Date
    Feb 2014
    Location
    Colmar, France
    Posts
    1,769
    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.

  7. #7
    Senior Member+ MichaelMeissner's Avatar
    Join Date
    Nov 2012
    Location
    Ayer Massachussetts
    Posts
    2,770
    Quote Originally Posted by Theremingenieur View Post
    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.
    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.

  8. #8
    Senior Member+ Theremingenieur's Avatar
    Join Date
    Feb 2014
    Location
    Colmar, France
    Posts
    1,769
    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!

  9. #9
    Senior Member+ KurtE's Avatar
    Join Date
    Jan 2014
    Posts
    3,636
    Wondering what changed in 1.8.2? So far don't see any updated release notes.

  10. #10
    Senior Member+ MichaelMeissner's Avatar
    Join Date
    Nov 2012
    Location
    Ayer Massachussetts
    Posts
    2,770

    Cool

    Quote Originally Posted by KurtE View Post
    Wondering what changed in 1.8.2? So far don't see any updated release notes.
    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

  11. #11
    Senior Member
    Join Date
    Jun 2016
    Posts
    122
    I read on another thread an issue with malloc sometimes corrupting the stack. Does the fix for this anomaly appear in 1.36?

  12. #12
    Junior Member
    Join Date
    Mar 2017
    Location
    Colorado Springs, CO
    Posts
    8
    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.

  13. #13
    Senior Member
    Join Date
    May 2015
    Posts
    338
    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?

  14. #14
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    18,153
    Quote Originally Posted by twilkers View Post
    I read on another thread an issue with malloc sometimes corrupting the stack. Does the fix for this anomaly appear in 1.36?
    Yes, fixed.

    Quote Originally Posted by DaQue View Post
    .... or at least before the end of March if things slip.

    Still looking good for the end of March?
    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.

  15. #15
    Senior Member+ MichaelMeissner's Avatar
    Join Date
    Nov 2012
    Location
    Ayer Massachussetts
    Posts
    2,770
    Quote Originally Posted by PaulStoffregen View Post
    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 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.

  16. #16
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    18,153
    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.

  17. #17
    Senior Member
    Join Date
    May 2015
    Posts
    338
    Quote Originally Posted by MichaelMeissner View Post
    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.
    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

  18. #18
    Senior Member
    Join Date
    Jul 2014
    Location
    New York
    Posts
    1,805
    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.

  19. #19
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    6,752
    @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 by defragster; 03-30-2017 at 04:36 AM.

  20. #20
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    18,153
    Quote Originally Posted by mjs513 View Post
    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.
    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.

    Click image for larger version. 

Name:	sc.png 
Views:	151 
Size:	95.8 KB 
ID:	10154

    I'd like to investigate... but I need find a way to reproduce the issue with my BNO055.

  21. #21
    Senior Member
    Join Date
    Jul 2014
    Location
    New York
    Posts
    1,805
    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_...rover_threaded
    Last edited by mjs513; 03-30-2017 at 06:50 PM.

  22. #22
    Junior Member
    Join Date
    Mar 2017
    Posts
    12
    Not much of a beta tester, but it works for me:

    * Ubuntu 16.04, 64bit.
    * Teensy LC
    * Using it with nRF24L01with https://github.com/nRF24/RF24 and ESP8266 with https://github.com/bportaluri/WiFiEsp and https://github.com/knolleary/pubsubclient

  23. #23
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    6,752
    @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.

  24. #24
    Senior Member
    Join Date
    Jul 2014
    Location
    New York
    Posts
    1,805
    @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.

  25. #25
    Senior Member
    Join Date
    Jul 2014
    Location
    New York
    Posts
    1,805
    @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.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •