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

Thread: Teensyduino 1.20 Release Candidate #3 Available

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

    Teensyduino 1.20 Release Candidate #3 Available

    Here is a third^H^H^H^H^H fourth release candidate for Teensyduino 1.20:


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



    Please give this a try and report any bugs. Try to include a sample program that reproduces the problem!

    These are the changes since Teensyduino 1.20-rc2:

    • Support Arduino 1.0.6
    • Fixes in DMAChannel
    • Use Serial2 FIFO on Teensy 3.1
    • Add transmitterEnable() on Serial2 & Serial3
    • Fix analogWriteFrequency on Teensy 3.1 pins 25 & 32
    • Update Time library
    • Add Installer Directory Help Button


    A mistake was discovered in -rc3, where some libraries where not included when installing to Arduino 1.0.6. How embarrassing....
    Last edited by Paul; 09-18-2014 at 07:01 AM. Reason: Opps....

  2. #2
    Administrator Paul's Avatar
    Join Date
    Oct 2012
    Posts
    338
    I debated simply releasing this as 1.20, but I think a few days for feedback is probably wise.

    At this point, I'm only going to consider bug fixes. I want to make 1.20 official by early next week.

  3. #3
    Senior Member
    Join Date
    Jan 2013
    Posts
    966
    Well, I have not actually checked if it's included in TD 1.2 RC3 but...

    It would be nice if the suggestions I posted in the following post would be able to make it into 1.2:
    http://forum.pjrc.com/threads/25561-...hlight=Bonjour

  4. #4
    Administrator Paul's Avatar
    Join Date
    Oct 2012
    Posts
    338
    Well, I have not actually checked if it's included in TD 1.2 RC3 but...
    Nope, it's not in 1.20-rc3.

    Is there a working beginMulti() function somewhere? Could you submit it as a pull request to this repository?

    https://github.com/PaulStoffregen/Ethernet

    The one issue which concerns me is having a fallback implementation, as is done with Stream::write(array, length), so other code which inherits from EthernetUDP.h without implementing beginMulti() still compiles.

  5. #5
    Senior Member
    Join Date
    Jan 2013
    Posts
    966
    The required modifications are posted in the thread I linked to in the post above, including a beginMulti()

    I'll see if I can do a pull request. My GitHub knowledge is rather rudimentary though ;-)

    I agree with your fallback concern but at the moment I don't know how to provide that. I am unfamiliar with the example you posted. Thanks for the consideration!

  6. #6
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    20,601
    I know this has been sitting for many months, but without a well tested implementation, I'm pretty reluctant to slip it at the last minute. Changing base class definitions risks breaking other libraries that depend on them.

  7. #7
    Senior Member
    Join Date
    Jan 2013
    Posts
    966
    While in general I agree, the only library I know of that depends on this small addition to the Ethernet library is the EthernetBonjour library and only because I updated it. There is not much of a chance of breaking anything else.

    I know through feedback from a few people that the EthernetBonjouor works for them when these suggested changes were applied to the Ethernet library, however I would not call that well tested.

    However, that still does not address your well taken concern with the fallback solution. I'd like to address that before submitting it as a pull request. Would you have pointer so I can start investigating what it would take to do that ?
    Last edited by Headroom; 09-18-2014 at 02:45 AM.

  8. #8
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    20,601
    Opps, rc3 was missing some library files when installing to a fresh copy of 1.0.6.

    I've replaced the links to -rc4, with (hopefully) all the missing files now properly included in the installer.

    (yes, I'm human and I sometimes make silly mistakes.... it's been a very long day here)

  9. #9
    Member
    Join Date
    Sep 2014
    Location
    California
    Posts
    22
    I just installed 1.6 and then Teensyduino 1.20 Release Candidate #3.

    It seems to work fine but during the Teensyduino install I said to install all libraries and now my builds are much slower as if it's trying to link them all in. Is there someplace I can say I don't want that?

  10. #10
    Senior Member
    Join Date
    Jan 2014
    Posts
    105
    Quote Originally Posted by Paul View Post
    Here is a third^H^H^H^H^H fourth release candidate for Teensyduino 1.20:
    Any chance to have the FlexCAN library also included in 1.20?

  11. #11
    Senior Member
    Join Date
    Nov 2012
    Location
    Boston, MA, USA
    Posts
    1,108
    Paul, there was a thread about ADC glitches if a pin was previously used for digital I/O, then set to INPUT. The bug was clearly documented, and reproducible. The cause was identified on post #5 and I proposed a fix (a new value INPUT_ANALOG which sets PORT_PCR_MUX(0), same as an unused pin and different to INPUT which sets PORT_PCR_MUX(1) ) in post #8.

    This should not have any knock-on effect on any other code. Did you see it and is it possible for 1.20? It is a bugfix.
    Last edited by Nantonos; 09-18-2014 at 11:43 AM.

  12. #12
    Senior Member
    Join Date
    Nov 2012
    Location
    Boston, MA, USA
    Posts
    1,108
    I was previously using arduino 1.0.5-r2, teensyduino 1.20-rc2 with teensy cores overwritten with the github version (to get the DMA changes, plus any other changes as well). I tested some of my audio-related sketches with a fresh arduino 1.0.6 and teensyduino 1.20-rc3 and they compiled and ran correctly. Windows 7 pro /64bit.

  13. #13
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    20,601
    Let me answer these last few posts with another question....

    If I post -rc5 with FlexCAN, INPUT_ANALOG and perhaps even UDP multicast, probably sometime this weekend (I'm going to rest a couple days....), can you guys give it a pretty good test over the next few days? The reality is we're all busy, and the other truth is relatively few people are interested to install the riskier release candidate versions, which together add up to quite a challenge to get substantial testing by more than just me to happen on a time scale shorter than 2+ weeks.

    I really do want to DO ALL THE THINGS, but my gut feeling says it's about time to cut off development and get a stable 1.20 released. So much already done and pretty well tested over the last few months.

    Adding FlexCAN seems pretty low risk for 1.20.

    Edits in the core lib, no matter how beneficial, seem risky to publish with only a brief testing period. I believe a far better strategy would be shooting for a quicker release cycle for 1.21. I'm going to publish Audio 1.0 "soon" and OctoWS2811 version 1.2 not long after that, so those will also provide motivation to make a 1.21 release with the newest libraries.

  14. #14
    Senior Member
    Join Date
    Jan 2014
    Posts
    105
    Quote Originally Posted by Nantonos View Post
    Paul, there was a thread about ADC glitches if a pin was previously used for digital I/O, then set to INPUT. The bug was clearly documented, and reproducible. The cause was identified on post #5 and I proposed a fix (a new value INPUT_ANALOG which sets PORT_PCR_MUX(0), same as an unused pin and different to INPUT which sets PORT_PCR_MUX(1) ) in post #8.

    This should not have any knock-on effect on any other code. Did you see it and is it possible for 1.20? It is a bugfix.
    That would be nice to have as well

  15. #15
    Senior Member
    Join Date
    Jan 2014
    Posts
    105
    Quote Originally Posted by PaulStoffregen View Post
    Adding FlexCAN seems pretty low risk for 1.20.
    I would agree with that. I've shipped around 50 of my CAN shields around the world within last 2 months so it has been tested by a number of people for quite a while - not a single problem reported for the FlexCAN library so far (well done teachop).

  16. #16
    Senior Member
    Join Date
    Nov 2012
    Location
    Boston, MA, USA
    Posts
    1,108
    Quote Originally Posted by PaulStoffregen View Post
    Edits in the core lib, no matter how beneficial, seem risky to publish with only a brief testing period. I believe a far better strategy would be shooting for a quicker release cycle for 1.21. I'm going to publish Audio 1.0 "soon" and OctoWS2811 version 1.2 not long after that, so those will also provide motivation to make a 1.21 release with the newest libraries.
    Agreed the timescale is too short for a core change. 1.21 would be fine.

  17. #17
    Senior Member
    Join Date
    Dec 2013
    Location
    Brasilia, Brazil
    Posts
    164
    Quote Originally Posted by PaulStoffregen View Post
    Edits in the core lib, no matter how beneficial, seem risky to publish with only a brief testing period. I believe a far better strategy would be shooting for a quicker release cycle for 1.21. I'm going to publish Audio 1.0 "soon" and OctoWS2811 version 1.2 not long after that, so those will also provide motivation to make a 1.21 release with the newest libraries.
    And, when talking about 1.21, will it have the C_DEBUGEN fix that would allow me to run a software debugger (http://forum.pjrc.com/threads/26358-...2434#post52434)?

  18. #18
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    20,601
    Has anyone used 1.20-rc4 yet? Everything working?

    I'm going to do quite a bit more testing this weekend, and probably make a final 1.20 release Sunday or Monday.

  19. #19
    Hi Paul,

    I tried it on a couple of my projects, a T2 with not much in the way of external libraries, and a T3.1 using your 2.2" ILI display. This is not a deep test at all, but you wanted a data point.

    Everything works fine for me except that I am still seeing the character drawing bug that KurtE and I discussed in this thread: http://forum.pjrc.com/threads/26498-...1_t3#post53654

    Not a show-stopper, but a bug nonetheless. You can probably grab or diff to Kurt's version of the library, (https://github.com/KurtE/ILI9341_t3) which is on GitHub, though I wouldn't call those edits heavily vetted either, particularly as regards the SPI transaction code... I'd think someone may want to try the code with other SPI devices on the bus, like SD or Ethernet. Of course I can't speak to what Kurt may have tested.

    Also, one minor warning I'm receiving during the T2.0 compile:

    Code:
    /Applications/Arduino 1.20RC2.app/Contents/Resources/Java/hardware/teensy/cores/teensy/Print.cpp: In member function 'size_t Print::print(const __FlashStringHelper*)':
    /Applications/Arduino 1.20RC2.app/Contents/Resources/Java/hardware/teensy/cores/teensy/Print.cpp:90: warning: '__progmem__' attribute ignored
    [Yes, it says 1.20RC2... That was an Arduino.app v1.0.5 that I installed just for Teensyduino 1.20rc2, and I just installed RC4 over the top.]

    Cheers,
    Dave

  20. #20
    Senior Member
    Join Date
    Jan 2014
    Posts
    105
    Quote Originally Posted by PaulStoffregen View Post
    Has anyone used 1.20-rc4 yet? Everything working?
    Quick question - why does one have to explicitly include SPI.h now when using SD.h?

  21. #21
    Senior Member+ KurtE's Avatar
    Join Date
    Jan 2014
    Posts
    5,440
    Has anyone used 1.20-rc4 yet? Everything working?
    I have installed it on both windows and ubuntu 14.04 with Arduino 1.0.6 and both working. But having some strange stuff going on with my version of Phoenix code base converting to to FreeRTOS. Where once I download my program, the USB serial port for the Teensy is no longer working properly and the Arduino IDE can not see it. Shows up as Com8 under device manager but won't show up in IDE. I can still download a program like blink to it, but only by pressing the program button. But the comm port still does not show up under IDE...

    was able to program it again on Linux box with 1.05 which has earlier teensyduino and then bring back to windows and shows up as com port... Again 99% sure it is my issues of not really knowing freeRTOS. Especially what I can/should do at program init time.

    I am now in process of debugging/changing my code base to see if I can avoid the issue. Should know more the next few days...

    Quote Originally Posted by pawelsky View Post
    Quick question - why does one have to explicitly include SPI.h now when using SD.h?
    Standard Arduino IDE stuff. the include search path is created by what libraries are included in the main sketch. Several threads have talked about this.

  22. #22
    Senior Member
    Join Date
    Jan 2014
    Posts
    105
    Quote Originally Posted by KurtE View Post
    Standard Arduino IDE stuff. the include search path is created by what libraries are included in the main sketch. Several threads have talked about this.
    Not quite, as this was not necessary with earlier version of Teensyduino, and is it not required by a clean install of Arduino IDE. Note that the original examples for SD lib do not include SPI.h (only SD.h) and compile fine.

    I believe this is due to the inclusion of SPI transactions, but would love hear Paul's comment on that.

  23. #23
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    20,601
    Yes, the SD library now requires SPI.h to be included.

  24. #24
    Senior Member
    Join Date
    Jan 2014
    Posts
    105
    Quote Originally Posted by PaulStoffregen View Post
    Yes, the SD library now requires SPI.h to be included.
    Any way to avoid that (to stay backward compatible)?

  25. #25
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    20,601
    Quote Originally Posted by pawelsky View Post
    Any way to avoid that (to stay backward compatible)?
    Not really. I considered a couple really ugly kludges, but decided against them. In Arduino's 1.5.X branch, SD always requires SPI, so you might as well just put #include <SPI.h> into your sketch now.

Posting Permissions

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