PDA

View Full Version : Teensyduino 1.17 Release Candidate #1 Available



Paul
10-18-2013, 02:25 PM
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 (http://forum.arduino.cc/index.php?topic=167414.0) 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

PaulStoffregen
10-18-2013, 02:55 PM
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,22 4,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?

duff
10-18-2013, 06:21 PM
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

PaulStoffregen
10-18-2013, 07:01 PM
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.

duff
10-18-2013, 09:11 PM
oh ok i guess i over looked that it was always there, so can I set the priority of attachInterrupt function?

duff
10-19-2013, 01:52 PM
oh ok i guess i over looked that it was always there, so can I set the priority of attachInterrupt function?

I guess not? though it would be pretty cool if i could!

duff
10-20-2013, 07:18 PM
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?

stevech
10-20-2013, 08:01 PM
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.

Headroom
10-23-2013, 12:08 AM
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 ;-)

PaulStoffregen
10-23-2013, 01:00 AM
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....

fsk
10-23-2013, 01:34 AM
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.

stevech
10-23-2013, 01:48 AM
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.

Headroom
10-24-2013, 01:39 AM
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 (http://gkaindl.com/software/arduino-ethernet).

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.

spanner888
10-24-2013, 01:57 AM
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 :)

PaulStoffregen
10-24-2013, 07:20 PM
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.

Headroom
10-30-2013, 02:17 AM
It currently coexists quite nicely with the modern versions of the ethernet library and functions fine with the Teensy3 and WIZ820io/W5200 (http://forum.pjrc.com/threads/23904-teensy3-WIZ820io-adapter-And-then-some?p=36926&viewfull=1#post36926)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 (http://forum.pjrc.com/threads/23904-teensy3-WIZ820io-adapter-And-then-some?p=33113&viewfull=1#post33113).

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.

PaulStoffregen
10-30-2013, 08:13 AM
It currently coexists quite nicely with the modern versions of the ethernet library and functions fine with the Teensy3 and WIZ820io/W5200 (http://forum.pjrc.com/threads/23904-teensy3-WIZ820io-adapter-And-then-some?p=36926&viewfull=1#post36926)and should also work fine with the W5100 based ethernet Modules/Shields.

Can you give me a direct link to the version that works?

Headroom
11-03-2013, 02:11 PM
Hi Paul,

Here is a LINK (https://www.dropbox.com/s/gfr77de8r17lsch/Teensy3-only_Ethernet_and_EthernetBonjour.zip) 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.

ausserirdischegesund
11-05-2013, 08:21 PM
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

el_supremo
11-05-2013, 08:35 PM
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:


int counter = 0;
void loop() {
digitalWrite(led, HIGH);
delay(100);
digitalWrite(led, LOW);
delay(500);
Serial.println(counter++);
}

Pete

ausserirdischegesund
11-05-2013, 09:00 PM
Thanks, Pete. Hangs somewhere between 3 and 7 reproducibly in several runs. Maybe my board is broken?

el_supremo
11-05-2013, 11:04 PM
Does the LED still flash when the output stops?

Pete

PaulStoffregen
11-06-2013, 08:53 AM
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().



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.

ausserirdischegesund
11-08-2013, 01:30 AM
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.

PaulStoffregen
11-08-2013, 04:47 AM
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).

bperrybap
11-09-2013, 05:14 PM
I know this comment is a bit late, but here is some feedback on the interrupt priorities.
I think it is great as I've always believed in the ability to take advantage of nested interrupts and the
power of interrupt prioritization.
One thing that may be of value, and I've used this in the past is a set of BSD type spl() functions for interrupt masking/restoring.
These are very handy and are sometimes necessary when doing certain types of atomicity
it also allows masking only the interrupts that you need vs all of them.
i.e:
http://www.gsp.com/cgi-bin/man.cgi?topic=splx

--- bill

bperrybap
11-09-2013, 05:27 PM
Another comment, but a general comment on Teensyduino.
Maybe I've missed it, but how does a user tell which version teensyduino that they have installed?
Maybe you could do something to make it more obvious?

- patch the title bar?
- patch the [Help]-[About Arduino] dialog?
- patch the drop down menu that shows up in the [Help] to show the Teensyduino version and link back to your site?

(kind of like what the "Visist Arduino.cc" entry does)

- Maybe add a "Teensyduino XX.XX Reference" entry to the [Help] drop down?

that shows the teensyduino version number and links back to your site

--- bill

ausserirdischegesund
11-09-2013, 05:48 PM
I just checked, with the "right" udev rules no problem, even with modemmanager running.

PaulStoffregen
11-09-2013, 10:11 PM
Sorry about those old udev rules.

When Redhat added ID_MM_DEVICE_IGNORE to modem manager a couple years ago, I just added it to the existing udev rule and it worked perfectly, until Ubuntu 12. At the time, I breathed a great sigh of relief, believing the terrible legacy of modem manager troubles had finally come to an end.

This time, I got a confirmation directly from one of the modem manager devs that this new udev rule is the way they intend to support. If only I'd known that a couple years ago! In theory, this new udev rule file is supposed to remain compatible with modem manager.... unless of course they decide to redesign everything all over again, which sadly they seem to do every couple years.

PaulStoffregen
11-09-2013, 10:24 PM
One thing that may be of value, and I've used this in the past is a set of BSD type spl() functions for interrupt masking/restoring.


The ARM hardware has a "primask" register for this. I've put this on my (very long) to-do list.



Maybe I've missed it, but how does a user tell which version teensyduino that they have installed?


As of 1.15, the simplest way is to use "About" in the Teensy Loader. Of course, it's possible to have multiple copies installed. The only way to be sure you're looking at the correct one is to quit Teensy Loader before you click Upload or Verify. Then Arduino will launch it again, using the internal copy in harware/tools. That one's Help > About dialog will have the version number.



Maybe you could do something to make it more obvious?

- patch the title bar?
- patch the [Help]-[About Arduino] dialog?
- patch the drop down menu that shows up in the [Help] to show the Teensyduino version and link back to your site?



I've also put this on my to-do list. For 1.17, I'm not adding any new IDE patches. Maybe in 1.18....

bperrybap
11-13-2013, 11:05 PM
As of 1.15, the simplest way is to use "About" in the Teensy Loader. Of course, it's possible to have multiple copies installed. The only way to be sure you're looking at the correct one is to quit Teensy Loader before you click Upload or Verify. Then Arduino will launch it again, using the internal copy in harware/tools. That one's Help > About dialog will have the version number.

Thanks for that tip. I thought that there must be something. I have 15 different versions of Arduino IDE on my machine
and I was needing a way to just see which teensyduino was in use for the one I'm testing on.




I've also put this on my to-do list. For 1.17, I'm not adding any new IDE patches. Maybe in 1.18....
I've patched the Arduino supplied version in {installdir}/lib/version.txt
to reflect patched IDEs that I've patched by adding more text to the end of that number.
At least for now, it appears to only be used for the title bar.

OR
It would be a bit heavy handed but, you could patch/replace the Arduino supplied jpg image in {installdir}lib/about.jpg
to replace what is shown when using [help]->About Arduino
It wouldn't require any IDE code patches.


--- bill

birk
06-12-2016, 03:11 PM
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.


Hey Paul,

how could I partition the memory for 4 times the amount of packet bufferung per socket with just 2 MAX_SOCK_NUM ??

PaulStoffregen
06-12-2016, 05:46 PM
how could I partition the memory for 4 times the amount of packet bufferung per socket with just 2 MAX_SOCK_NUM ??

Edit the ethernet lib to change things like SSIZE, SMASK and maybe other stuff.

https://github.com/PaulStoffregen/Ethernet/blob/master/w5100.cpp#L75