teensy3 - WIZ820io adapter - And then some

Status
Not open for further replies.
Hi manitou, thanks for posting this!
Rather odd though that the results for 16 vs 24MHz are basically exactly the same!
Also interesting that up to 16MHz the results are very comparable to Fat SPI.

I re-ran the tests for teensy 3.0 and results were the same. I edited the table above to include tests on teensy 3.1. Notice that the 16 and 24mhz times are much better. The teensy 3.1 faster memory would explain some improvement, but I am surprised at the difference ...
 
Not sure I understand how to interpret that table now. What do the values before and after the slash in the T3 and T3.1 column represent ?

We've established that both FatSPI and PaulSPI use SPIFIFO, so one would expect that these afre fairly comparable in performance on the same board so FatSPI on T3 should be cloes to PaulSPI on T3 and equivalently on T3.1.

The way I read the table, for the T3.1 that is actually the case. The values for FatSPI on T3.1 actually are very close to PaulSPI on T3.1.
I dont see the same on T3.
 
Not sure I understand how to interpret that table now. What do the values before and after the slash in the T3 and T3.1 column represent ?

The / is read/write data rates. If they are about the same, I just report one number. The only 3.1 numbers in that table are for the SPIFIFO from Paul's new Ethernet lib -- the other numbers are from 3.0 tests.

you can run the following sketch yourself
https://github.com/manitou48/teensy3/blob/master/wizpaul.ino

you don't even need a WIZ chip -- SPI test can run unconnected (though it will report "errors" when it tries to verify data from read), but data rates are good. The SPIFIFO code was lifted from Paul's Ethernet library. I just hack w5100.cpp to change the SPI data rate in SPIFIFO.begin()
 
I wrote SPIFIFO (a.k.a. "PaulSPI") with a different set of trade-offs than Bill Greiman used in his SdFat library (a.k.a. "FastSPI", even though there's an excellent Arduino library with that same name, written by Daniel Garcia, so perhaps that's not the best name to call Bill's SPI implementation...)

Both should be similar, but it's not surprising that Bill's code would be slightly faster at 24 MBit/sec on large transfer sizes, since it has less CPU overhead.

SPIFIFO is optimized for small transfers. It supports bidirectional data flow and is intended to be far more general-purpose. It uses the SPI port's hardware to generate the CS signal, which gives a nice speed improvement for tiny transfers.

While working on SPIFIFO, I did a lot of high-level benchmarking on the Ethernet library, and similar testing with an Adafruit SPI-based LCD. But I did not do much of this low-level benchmarking. I probably should have. I'm glad you're looking into this stuff. I really do care about improving performance, so this testing is really helpful.

But please do keep in mind these benchmarks are for really large transfers, which are not the norm with the Ethernet library. Even for UDP, the library makes several small transfers to read and update W5200 registers before actually doing the one (or two if wrapping around the circular socket buffer) large transfers to move the data.
 
Worth considering:
UDP sessions are most always packet-oriented, in applications.
TCP sessions are (arguably) most often stream-oriented, where the app does not want to know about packet boundaries.

IP stack off-load modules like the Wiznet 5x00 chips, esp. the 5200, have an onboard buffer per socket per direction that's larger than the MTU size. Thus, there's an opportunity to let data sit in that buffer even when 2+ packets are in that onboard RAM buffer. Apps, esp. for TCP, should do a read for as large of amount of data as they wish to have an app buffer for - ideally MTU size or more. The 5xxx chips update the count of data in the buffer only at the end of a received packet (not intra-packet data). That is, the I/O driver need not have intermediate buffers, for an embedded system where RAM is scarce.

For UDP, I think that most often the data size in the UDP header (unlike TCP) has to be parsed by the app and so UDP may tend to be less streaming oriented.
 
Actually, on my long-term to-do list is improving the Ethernet library for TCP, pretty much by doing the opposite of what you described.

The problem is most Arduino sketches request data in small chunks, or even 1 byte at a time. The Arduino Ethernet library works more or less as you described. By not buffering anything in Teensy's RAM, there's incredible overhead when reading in small chunks or single bytes. A small buffer on the Teensy side, even 100 bytes, could dramatically speed up those cases.
 
Is the reason that some Arduino sketches read a tiny few bytes from the enthernet interface, in TCP, because of the small RAM in the AVRs?
Would most of those apps be web client apps? I'd think most HTML responses would be hundreds of bytes and more than one packet.
If web server apps, the TCP reads would, I suppose, be mostly HTML get requests which tend to be 100 or so bytes.

Reading an HTML GET response which is say, 2,000 bytes, one at a time, is just bad software. Even on the AVR.

I'd vote for the app to provide the CPU buffer pointer/size before the socket is opened. And have "none" as an option if the app wants to use only the buffer onboard the 5xxx. The app knows what it expects and how much RAM it can afford to allocate, vs. exploiting the buffer on the NIC.

The situation is different for hardware like the Microchip products which tend to have less onboard RAM.
 
Last edited:
Reading an HTML GET response which is say, 2,000 bytes, one at a time, is just bad software. Even on the AVR.

It may be bad, but it's also incredibly common.

Perhaps there are efficiently written Arduino sketches out there, but nearly all the ones I've seen read in small chunks or 1 byte at a time. It's simply the way people using Arduino tend to do these things.
 
I suppose. Here's a parallel thought:

As I recall, the Arduiono hardware serial library didn't have buffered and interrupt driven serial output (TX) for a very long time. This led the typical Arduino user to waste large amounts of time and effort on their part, as they didn't realize there was/is a busy-loop in the TX library and that hosed up their program's timing. At some point, too-crude has to go, for the sake of the user who is not cognizant of such things and shouldn't have to be.
 
As I recall, the Arduiono hardware serial library didn't have buffered and interrupt driven serial output (TX) for a very long time.

True, but Teensy had this feature pretty much all of that time. Lots of things that worked easily on Teensy would stall on regular Arduino.

Likewise, with Ethernet and other libraries, I try to optimize for how people actually use them. Someday I'm going to put much more optimization work into the Ethernet library. It's just terribly slow the way it's designed now.

On serial interrupts, by the way, i believe Arduino Due still has non-buffered hardware serial....
 
I've assumed that the majority of the Teensy and esp. Teennsy 3 users are "advanced" as compared to the average Arduino user.
 
While this is getting somewhat off topic, it think that it's OK if I help in hijacking my own thread :cool:

My main intention when building this adapter board (or mutated Arduino) was to integrate it into my lighting systems. I remotely control these via WiFi using The Open Sound Protocol, which in turn uses UDP. One of my ideas is to expose all functions of the LED driver boards (see signature) through OSC so in theory a user can connect LEDs and connect to the Frankenduino per WiFi and then can control it through OSC from e.g. maxMSP or Pure Data without having to program A single line of Arduino code.
That would require speedy OSC/UDP streaming I'd assume.

I think what is advanced is in the eye of the beholder. My projects tend to be advanced as they attempt to resemble fully integrated systems with the technology behind it not being the main focus point but rather working in the background. Products rather than prototypes. Most people that have seen my lighting systems in person and on occasion are fascinated by them really don't care that there is a micro-controller in there nor do they know what a micro-controller is. That is exactly what I am aiming at! It just works ;-)

However, when it comes to programming micro controllers I am not so advanced. The only thing I programmed after finishing my Mechatronics degree 25 years ago was Excel macros and don't have decades of experience with programming micro-controllers. I am entirely self taught and started getting back Ito electronics about 3 years ago to realize an idea. I prefer to use C++ and easy to use libraries. They are just the means to an end. I wanted for example the functionality of a Bonjour library have gotten it to work somehow and carried it along for almost two years painfully updating it through numerous Teensyduino iterations and from Teensy++2 to Teensy 3 to Teensy 3.1.

So what exactly would one call advanced ?
 
I'd say that making PCBs, designing/adding Eternet/WiFi, and so on is advanced for the Arduino world.
More than just buying/using a "shield" and a library.
 
I2C Expander questions

The I2C buffer as shown in the configuration in the last post also works like a charm. Driving one of my LED shield on 5m (16ft) CAT 5 cable at 1MHz was no problem. Scope showed crisp signal without having ideal termination/pull-up resistors (did not have the right values at hand). Signals looked still crisp at 1.5MHz, even though the PCA9600 and the FM+ components on the LED shield not specified at that frequency and I would not use this in an installation.

This suggests that there is a good bit of headroom when using the correct pull-up resistors and set-up, so I am somewhat confident I can use this at 1MHz I2C Bus frequency in the system in the image that uses five of the LED shields and is currently driven by the equipment shown in the first post in this thread:
View attachment 881

I came across your work while searching for I2C expander. Its very informative and thanks for sharking your work.

I have few questions on I2C expander.
1) "CAT5" cable, does it carry power. Can you please post the wiring
2) On the slave side, i see I2C slave devices directly dropped on cable bus(twisted wire). Does the slave device has the ESD capability?

Thanks for your help
 
Status
Not open for further replies.
Back
Top