PDA

View Full Version : Teensyduino 1.20 Release Candidate #3 Available



Paul
09-18-2014, 01:18 AM
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 (http://forum.pjrc.com/threads/26298-Teensyduino-1-20-Release-Candidate-2-Available):


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....

Paul
09-18-2014, 01:50 AM
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.

Headroom
09-18-2014, 02:01 AM
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-Proposal-for-additions-to-Ethernet-EthernetUDP-library?highlight=Bonjour

Paul
09-18-2014, 02:14 AM
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.

Headroom
09-18-2014, 02:22 AM
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!

PaulStoffregen
09-18-2014, 02:27 AM
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.

Headroom
09-18-2014, 02:42 AM
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 ?

PaulStoffregen
09-18-2014, 07:11 AM
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)

Ira
09-18-2014, 07:35 AM
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?

pawelsky
09-18-2014, 07:57 AM
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?

Nantonos
09-18-2014, 10:50 AM
Paul, there was a thread about ADC glitches if a pin was previously used for digital I/O, then set to INPUT (http://forum.pjrc.com/threads/26143-Teensy-3-1-Analog-to-digital-converter-value-jumps-like-digital-IO-pin-hysteresis). The bug was clearly documented, and reproducible. The cause was identified on post #5 (http://forum.pjrc.com/threads/26143-Teensy-3-1-Analog-to-digital-converter-value-jumps-like-digital-IO-pin-hysteresis?p=50803&viewfull=1#post50803) 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 (http://forum.pjrc.com/threads/26143-Teensy-3-1-Analog-to-digital-converter-value-jumps-like-digital-IO-pin-hysteresis?p=51053&viewfull=1#post51053).

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.

Nantonos
09-18-2014, 11:42 AM
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.

PaulStoffregen
09-18-2014, 11:56 AM
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.

pawelsky
09-18-2014, 12:04 PM
Paul, there was a thread about ADC glitches if a pin was previously used for digital I/O, then set to INPUT (http://forum.pjrc.com/threads/26143-Teensy-3-1-Analog-to-digital-converter-value-jumps-like-digital-IO-pin-hysteresis). The bug was clearly documented, and reproducible. The cause was identified on post #5 (http://forum.pjrc.com/threads/26143-Teensy-3-1-Analog-to-digital-converter-value-jumps-like-digital-IO-pin-hysteresis?p=50803&viewfull=1#post50803) 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 (http://forum.pjrc.com/threads/26143-Teensy-3-1-Analog-to-digital-converter-value-jumps-like-digital-IO-pin-hysteresis?p=51053&viewfull=1#post51053).

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 :)

pawelsky
09-18-2014, 12:21 PM
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).

Nantonos
09-18-2014, 02:08 PM
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.

jbliesener
09-18-2014, 05:03 PM
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-Software-Debugger-Stack?p=52434#post52434)?

PaulStoffregen
09-19-2014, 06:33 PM
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.

drg
09-19-2014, 10:58 PM
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-Best-practice-printing-a-field-on-a-graphics-display-or-spoiled-by-4d-Systems?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:


/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

pawelsky
09-20-2014, 12:45 PM
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?

KurtE
09-20-2014, 02:27 PM
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...


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.

pawelsky
09-20-2014, 02:44 PM
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.

PaulStoffregen
09-20-2014, 03:08 PM
Yes, the SD library now requires SPI.h to be included.

pawelsky
09-20-2014, 03:10 PM
Yes, the SD library now requires SPI.h to be included.

Any way to avoid that (to stay backward compatible)?

PaulStoffregen
09-20-2014, 03:49 PM
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.

pawelsky
09-20-2014, 10:44 PM
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.

I guess I've got no choice. Thanks for your comment Paul.

PaulStoffregen
09-21-2014, 12:18 AM
The days of libraries accessing the SPI port without using the SPI library are thankfully coming to a close.

Long-term, we really need libraries to use the hardware independent APIs and the new SPI transaction functions.

manitou
09-24-2014, 04:27 PM
rc4 didn't have fixes to FreqMeasureCapture.h ...
https://github.com/PaulStoffregen/FreqMeasure/issues

xxxajk
09-29-2014, 05:55 PM
boards.txt needs a std=c99 added, so that c99 code compiles.
Simply adding this to build properties works, but spits out warnings, because the setting is used for g++ too.