Teensyduino 1.20 Release Candidate #3 Available

Status
Not open for further replies.
Paul

Paul

Administrator
Staff member
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:
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.
 
Well, I have not actually checked if it's included in TD 1.2 RC3 but...
Click to expand...

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.
 
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!
 
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.
 
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:
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)
 
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?
 
Last edited:
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.
 
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.
 
Nantonos said:
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.
Click to expand...

That would be nice to have as well :)
 
PaulStoffregen said:
Adding FlexCAN seems pretty low risk for 1.20.
Click to expand...

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).
 
PaulStoffregen said:
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.
Click to expand...

Agreed the timescale is too short for a core change. 1.21 would be fine.
 
PaulStoffregen said:
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.
Click to expand...

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-Software-Debugger-Stack?p=52434#post52434)?
 
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.
 
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...ystems?p=53654&highlight=ili9341_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
 
Has anyone used 1.20-rc4 yet? Everything working?
Click to expand...
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...

pawelsky said:
Quick question - why does one have to explicitly include SPI.h now when using SD.h?
Click to expand...
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.
 
KurtE said:
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.
Click to expand...

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.
 
pawelsky said:
Any way to avoid that (to stay backward compatible)?
Click to expand...

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.
 
Status
Not open for further replies.
Back
Top