Forum Rule: Always post complete source code & details to reproduce any issue!
Results 1 to 11 of 11

Thread: Teensyduino 1.36 Beta #2

Hybrid View

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

    Teensyduino 1.36 Beta #2

    Here is a second beta test for Teensyduino 1.36.

    Linux 32 bit:
    https://www.pjrc.com/teensy/td_136-b...nstall.linux32

    Linux 64 bit:
    https://www.pjrc.com/teensy/td_136-b...nstall.linux64

    Linux ARM:
    https://www.pjrc.com/teensy/td_136-b...stall.linuxarm

    Mac OS-X:
    https://www.pjrc.com/teensy/td_136-b...inoInstall.dmg

    Windows:
    https://www.pjrc.com/teensy/td_136-b...inoInstall.exe

    Changes since version 1.36-beta1:

    • 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

  2. #2
    Senior Member defragster's Avatar
    Join Date
    Feb 2015
    Posts
    4,793
    sticky current "Beta/Release" posts while active would keep them from getting bumped down when an older announcement gets pinged.

  3. #3
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    15,398
    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:

    Code:
    TwoWire Wire(KINETIS_I2C0, TwoWire::i2c0_hardware);
    void i2c0_isr(void) { Wire.isr(); }
    Code:
    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!

  4. #4
    Senior Member KurtE's Avatar
    Join Date
    Jan 2014
    Posts
    2,970
    Quote Originally Posted by PaulStoffregen View Post
    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:

    Code:
    TwoWire Wire(KINETIS_I2C0, TwoWire::i2c0_hardware);
    void i2c0_isr(void) { Wire.isr(); }
    Code:
    TwoWire Wire3(KINETIS_I2C3, TwoWire::i2c3_hardware);
    void i2c3_isr(void) { Wire3.isr(); }
    Is the first one correct? Looks more like Wire0...

  5. #5
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    15,398
    Quote Originally Posted by KurtE View Post
    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.


    Quote Originally Posted by KurtE View Post
    Is the first one correct? Looks more like Wire0...
    Opps, yes, that's the wrong one. For Wire1 it should be:

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

  6. #6
    Senior Member KurtE's Avatar
    Join Date
    Jan 2014
    Posts
    2,970
    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)

  7. #7
    Senior Member defragster's Avatar
    Join Date
    Feb 2015
    Posts
    4,793
    FOR CONSIDERATION:: Paul put in my suggestion to split the delay(400) 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: TimedStartBlinkMin.ino
    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
    Last edited by defragster; 03-16-2017 at 05:02 PM.

  8. #8
    Senior Member KurtE's Avatar
    Join Date
    Jan 2014
    Posts
    2,970
    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:
    Code:
    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
    Last edited by KurtE; 03-16-2017 at 03:56 PM.

  9. #9
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    15,398
    Quote Originally Posted by KurtE View Post
    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....

  10. #10
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    15,398
    Quote Originally Posted by KurtE View Post
    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/Wi...ffe979ff9c0a5b

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

Posting Permissions

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