Teensyduino 1.17 Release Candidate #1 Available

Status
Not open for further replies.

Paul

Administrator
Staff member
Here is a first release candidate for Teensyduino 1.17:



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!


Here's a list of the changes since Teensyduino 1.16:

  • Ethernet library support for W5200 chip
  • Print speedup for Teensy2
  • analogRead is now thread safe on Teensy3
  • keep USB & serial working in Teensy3 fault condition
  • support interrupt priority levels on Teensy3
  • Serial1 on Teensy3 to transmit even if interrupt blocked
  • fix Teensy3 USB buffer memory leak with re-enumeration
  • USB Mouse on Teensy3 now uses absolute cursor positioning,
    Mouse.moveTo(x, y) and Mouse.screenSize(width, height)
  • USB Keyboard on Teensy3 supports media keys (Mac & Linux only)
  • add missing AVR string _P functions on Teensy3
  • add missing AVR eeprom functions on Teensy3
  • improve buffer size configuration on Teensy3
  • minor fix to Teensy3 Makefile
  • USB MIDI example improved
 
Probably the most significant change for Teensy3 as a development platform is using the ARM nested interrupt priorities. Previously, all interrupts ran at level 0, which is the highest non-fault priority (lower numbers are higher priority). So except for faults, interrupts couldn't interrupt each other.

Now all the interrupts default to priority 128. The chip supports 16 different prorities: 0,16,32,48,64,80,96,112,128,144,160,176,192,208,224,240. When ordinary non-interrupt code is running, it's effectively priority level 256. You can configure what priority an interrupt uses with NVIC_SET_PRIORITY(irqnum, priority). Currently, the USB and hardware serial increase their priority. Most interrupts will probably be fine with the defaults.

I'm curious if anyone has any feedback about this priority scheme, and especially how it relates to Arduino and the commonly used libraries? For example, libraries like Servo that are really sensitive to latency from other libraries probably want higher priority.

Another significant change, which is somewhat experimental, is in Serial1. Inside Serial1.write(), which is called by Serial1.print(), it now checks to see if interrupts are blocked (by looking at priority levels). Normally, this would cause Serial.print() to never return if you try to print more than fits into the transmit buffer. Anybody who's worked on interrupts know you normally need to be careful what you do inside interrupt code. But my goal is to make Serial1 (and eventually much more) "just work", even when used inside an interrupt. So if Serial1 detects the interrupt is blocked while it's waiting for space in the transmit buffer, it will revert to polling the hardware and transmitting the data while the interrupt can't run. Of course, Serial1.print() can't return until the remainder of the data it wants to transmit can fit into the buffer, but that's a lot better than it never returning at all. My goal is to eventually make as much as possible "just work" in as many situations as I can. This is just the start, and before I try extending this to USB virtual serial and other things, I'm hoping for some feedback about how well it works (or doesn't work)? Or even any theoretical arguments about deadlocks, thread safety, etc.

I also changed the default fault handler so the USB and serial ports are polled while in fault mode. This hasn't been tested much, but it does allow the Upload button to auto-reboot Teensy3 when it's stuck it the fault handler. For normal Arduino programming, faults should be very rare, but if you've ever fiddled with accessing hardware directly, it's pretty easy to get a fault condition if you read or write registers on disabled peripherals or make other mistakes. Not having to physically press the button is always nice.

It's perfectly fine to discuss these changes here (even through it's the announcement forum). I'm really curious to hear any thoughts or feedback, especially about the use of priority levels and ways to make more Arduino functionality interrupt safe?
 
It's perfectly fine to discuss these changes here (even through it's the announcement forum). I'm really curious to hear any thoughts or feedback, especially about the use of priority levels and ways to make more Arduino functionality interrupt safe?

Hi Paul,

I see you added a software IRQ defined in mk20dx128.h and i was wondering how this is to be used? Could this be used for setting priority of user defined interrupt's with attachInterrupt?

Thanks,

duff
 
The software interrupt has always been there. It's only possible to trigger it from software.

The upcoming audio library uses it. The high priority DMA interrupt, which responds very briefly to the automatic movement of audio data, triggers the software interrupt to perform the processing of data at a low priority.
 
oh ok i guess i over looked that it was always there, so can I set the priority of attachInterrupt function?
 
ok i see that attachInterrupt priority can be set by setting IRQ_PORTA, IRQ_PORTB, IRQ_PORTC, IRQ_PORTD, IRQ_PORTE priorities respectively. So i think I'm pretty good on that.

One thing I noticed is that I can not use software IRQ because it's tied up in the new Audio Class. I was able to circumvent this by defining the Audio Class IRQ handler as -> "__attribute__ ((weak)) void software_isr(void)". Im not sure if this is acceptable way of doing this? I would really like to be able to use this but not in audio application, any thoughts?
 
also, task schedulers such as FreeRTOS try to use the software interrupt to create a stack frame when changing tasks (non-ISR).
Software interrupt is most often used by the operating system or equivalent thereof on behalf of many types of applications.
 
Paul, I see you've done some work in the Ethernet Library to make it work with W5100 and W5200 chip based ethernet hardware. Great!

I see that in it's current form only 4 of the eight ports on the W5200 are available (#define MAX_SOCK_NUM 4).

Anyway, I'll start working on making similar changes to the Bonjour library. Maybe I can convince you to integrate it into Teensyduino one day ;-)
 
I see that in it's current form only 4 of the eight ports on the W5200 are available (#define MAX_SOCK_NUM 4).

Yes, this was a decision I made. It seems unlikely anyone will use more than 2. So I decided to partition the memory for double the amount of packet buffering per socket, rather than double the number of sockets.

Anyway, I'll start working on making similar changes to the Bonjour library. Maybe I can convince you to integrate it into Teensyduino one day ;-)

Does it build on top of the Ethernet library, or access the hardware itself?

Please post a link. I'll add it to my list of libraries to look at....
 
I was hoping that the serial stuff you did would somehow fix the problem im having while using u8glib. For some reason any time I draw something to the display, Serial1 can't send anymore until i call Serial1.begin(). I can manage with this workaround but i wonder why that is.
 
Yes, this was a decision I made. It seems unlikely anyone will use more than 2. So I decided to partition the memory for double the amount of packet buffering per socket, rather than double the number of sockets.
Funny! Last project I did was with the '5100 chip and 4 sockets. I had to mickey-mouse a lot of code (retries, etc) for lack of enough sockets.
1 always open with a connection to a server (live sensor data, TCP).
1 always open for web server
1 always open for telnet server
1 used briefly by agreement, for things like NTP server, FTP client (which could be lengthy).

I originally intended to send sensor data via UDP - but firewall security issues in enterprise systems' policy prohibited use of UDP and port forwarding.

Wiznet told me that my problems using the '5100 on cellular was that they didn't implement TCP window sizing - it's not negotiated; it's fixed. The only work-around for that, when talking to Windows TCP stacks, is to disable windowing entirely, thus every packet has to get an ACK. Slowed the thing down a lot in FTP. Probably not an issue with HTTP. If long delays like cellular aren't needed (600mSec not uncommon- and that causes TCP ACK timeouts with Wiz's windowing enabled) - then you needn't disable windowing.
They told me that the 5200 doesn't implement dynamic window sizes either.
Just a heads up.
 
Last edited:
The original Arduino Bonjour library was written by Georg Kaindl in 2010 with the latest revision being from 2011. This was before DHCP was integrated into the Arduino Ethernet library. It's available for download HERE.

It only uses:
#include <utility/socket.h>
#include <utility/w5100.h>

So it accesses the hardware itself. It uses its own /utility folder that masks ( or whatever the technically correct term is ) many existing functions in EthernetCompat.h
That file had to undergo most of the changes to make it work with the Teensy++2 and Teensy3. I actually have not tested after I made the Teensy3 changes if it still works with the Teensy++2.
 
Just got my Teensy3's .. short story is that v1.1.7RC1 EEPROM does work and I need add some error checking to my eeprom code.

another BIG thanks for great hardware and support :)
 
The original Arduino Bonjour library was written by Georg Kaindl in 2010 with the latest revision being from 2011. This was before DHCP was integrated into the Arduino Ethernet library.

I would love to include an updated EthernetBonjour library with Teensyduino. It would need to be reworked to use #include <EthernetUdp.h> from the modern versions of the Ethernet library.
 
It currently coexists quite nicely with the modern versions of the ethernet library and functions fine with the Teensy3 and WIZ820io/W5200 and should also work fine with the W5100 based ethernet Modules/Shields. It did before I applied changes to make it work with the WZ820io. In its previous version it is currently doing it's duty on a Teensy++2 with a WIZ812MJ.

The only reason why it would be beneficial to replace the direct hardware access to the W5100/W5200 chip through functions defined in w5100.h/w5100.cpp, is to eliminate it's direct dependency on these two chips. But then, the whole Ethernet library relies on these functions so that may be a futile attempt.

I think I will open a separate thread once I've made some progress on what I think needs to be done and have a functioning version to present.
 
Bonjour Library

Hi Paul,

Here is a LINK to a zipped file that contains a modified Ethernet Library and the EthernetBonjour library that work together. The example folder contains currently only one Arduino 1.0.5 sketch that registers an OSC (open Sound Control) service.

These libraries reflect my current work-in-progress and as such currently only work with the Teensy3.
the modifications to the Ethernet library are exclusively in the /utilities folder and contain some additions to be able to change the SPI bus frequency and some changes for the W5200 chip. Most of these changes came from files provided in another thread my user manitou. the W5200 specific thing are the same as in the Teesnyduino 117 libraries, obviously without the very nifty auto detect mechanism. Nice work BTW!

The biggest thorn-in-my-eye in the EthernetBonjour library are two files in its /utility folder, namely EthernetCompat.h and EthernetCompat.cpp. there is some duplicate code in thee that comes from the W5200h and W5200.cpp and is duplicated in the aforementioned flew that these functions declared private in the W5200. files.

As I am using the Eclipse and the Arduino Eclipse plugin it is very convenient to switch between different versions of the Ethernet and EthernetBonjour library. I've tried to compile for a Teensy3 using the Etehrent Library from the 1.17 Teensyduino. It compiles without warnings and after upload reports in the serial monitor to have registered the OSC service, but never does register it properly. I usually use the Bonjour browser on my Mac and it takes about 3-5 seconds for the service to pop up on the list of services after reprogramming the Teensy3. As additional verification I use a network scanner on my iPhone to check if it works. The last verification step is usually to see if the service appears int TouchOSC on the iPhone, or iPad.
 
Last edited:
Serial hangs for me

Don't know if this is related to 1.17RC1, but the following sketch hangs on the serial port while it continues to run (blink). Teensy 3


int led = 13;

void setup() {
pinMode(led, OUTPUT);
Serial.begin(9600);
}

void loop() {
digitalWrite(led, HIGH);
delay(100);
digitalWrite(led, LOW);
delay(500);
Serial.print("Blink " );
}

It writes just a few "Blink" and then hangs:
Terminal ready
Blink Blink Blink Blink (hangs)

Is this something stupid in my sketch, or something related to 1.17?

/ralph
 
It works for me with 1.17 RC1. If you have the serial monitor window set fairly narrow you'll only see a few "Blink" before it is writing beyond the edge of the screen and it might not be obvious that it is still going. Change loop() to this and try again:
Code:
int counter = 0;
void loop() {
digitalWrite(led, HIGH);
delay(100);
digitalWrite(led, LOW);
delay(500);
Serial.println(counter++);
}

Pete
 
Thanks, Pete. Hangs somewhere between 3 and 7 reproducibly in several runs. Maybe my board is broken?

It's very unlikely to be a bad Teensy. When a Teensy fails, it's usually completely dead.

Software and driver problems are pretty common, especially on Windows. Which operating system are you using? Are you viewing the data with the Arduino Serial Monitor, or some other program?

Here's another crazy guess (probably only an issue if using other non-Arduino software): can you try adding this into your loop().

Code:
  while (Serial.available()) {
    Serial.read();
  }

That's just a blind guess on my part, on the theory that maybe something on your PC (or Mac???) might be transmitting data to Teensy, or maybe echoing what Teensy is sending. That might be filling up all the USB buffers, if you never read the data.
 
Thanks Paul, that helped a lot. When I inserted a debug print statement I saw writing activity to the port. It was the Gnome modemmanager, I think, that I had removed before but must have been come back in an upgrade. Removing it makes the serial port work again- Thanks for your help, and certainly no problem of 1.17, sorry.
 
Could you check your udev rules? Are they the same as this file?

http://www.pjrc.com/teensy/49-teensy.rules

Several months ago, the udev rules were updated to deal with newer version of Gnome's modem manager.

I'd really like to know if you have the older udev rules, or this is yet another new problem with the modem manager (it's struck many times over the years).
 
Status
Not open for further replies.
Back
Top