Udp.parsePacket() is too slow

[xseignard]

Hello,

I'm creating an audio reactive wall with Arduino Ethernet and @freetronics DMDs (http://www.freetronics.com.au/collections/all-products/products/dot-matrix-display-32x16-red#.VUl2QHXtlBc).

It works quite OK, but the Udp.parsePacket() is too slow, and then blocks the TimerOne that scans and updates the display on the DMDs. The result of this is that the DMDs flicker, which is a bit annoying.

My question then is : is there any faster way than UDP.parsePacket() to check if an UDP message is incoming?

Here is my sketch https://gist.github.com/xseignard/3b2b8d810122a8235540 nothing fancy, and I'm sure about what I say, since the DMDs flicker even when there is no incoming UDP packets, and if I replace the UDP communication by a Serial one, using Serial.available(), there is no flickering.

I add @projectgus, maintainer of https://github.com/freetronics/DMD to this issue since he might be interested.

Regards

[mschlenker]

Would using raw ethernet packets be an option? This way you are using MAC addresses to communicate, but get rid of the whole IP stuff.

[matthijskooijman]

Using raw ethernet packets limits to the local network only, which might be ok for this application?

When you say "too slow", what does that mean? Did you measure how long it takes? You say it "blocks the TimerOne", what does that mean? Are you running things in an interrupt that gets blocked? Or do you just do processing in your main loop based on that timer?

I've looked at the Ethernet library source a bit, and it doesn't look like there is any longt blocking behaviour in there. The only potential delays I found are here where waits while here is more data coming in, and here where it waits for a command to complete.

Furthermore, it doesn't seem like the Ethernet library disables any interrupts, unless you (or some library) is calling SPI.usingInterrupt() somewhere.

Looking at the DMD library examples, those set up timer1 to do DMD processing, which includes SPI transactions. AFAICS that actually means you should be calling SPI.usingInterrupt(), since without it, the TimerOne interrupt could occur inside an Ethernet SPI transaction. If you then do an DMD SPI transaction, this will mess up the running Ethernet transaction (and perhaps also the DMD one, though I'm not sure about that).

[matthijskooijman]

One option to consider is to use two Arduinos: One for DMD processing and one for Udp, linking them through serial :-)

[mschlenker]

@matthijskooijman Considering the fact that IP packets typically can be as big as 1500 byte (using up to three quarters of the precious memory), using a dedicated MCU for the UDP processing might not be the worst option. BTW: The sketch still uses Serial.begin() although serial is not used.

[xseignard]

Hello @mschlenker and @matthijskooijman, thanks for your comments, it lead me to a fix.

I wrapped the Upd.parsePacket() with noInterrupts() and interrupts() like this

noInterrupts();
int packetSize = Udp.parsePacket();
interrupts();

And the flickering disappeared.

I must confess I'm not enough expert with Arduino internals to understand why it solved my issue, but still, the issue is solved.

Any explanation for my personal enlightment would be welcome :)

Thanks for your precious comments,

Regards

[matthijskooijman]

I suspect that my previous analysis was correct: The TimerOne interrupt interrupts an SPI transfer going on inside the Ethernet library, leading to some kind of breakage. The fix you have now is a bit rough, but it works. The SPI library has some code to handle this problem in a more fine-grained way (by disabling only interrupts whose handlers use SPI, instead of disabling all interrupts as you do now), but that only supports the "external interrupts", configured by "attachInterrupt".

If you want a bit more subtle approach, you could try only disabling the TimerOne interrupt instead of all interrupts when calling parsePacket. That way, other interrupts (like the millis() interrupt) still work as normal.

[xseignard]

Thanks @matthijskooijman, indeed it seems a better solution. I try it and let you know.

[xseignard]

As expected it works as fine as my fix, but smarter!

Thanks @matthijskooijman for your quick and clear answers, I can close the issue.