teensy3 - WIZ820io adapter - And then some

[Headroom]

The Brains for my LED Lighting System currently look like this:

To the left is a TP-Link 703 pocket router connected to a WIZ812MJ Ethernet Module which is assembled onto an adapter board together with a Teensy++2. the two ethernet Jacks carry I2C bus signals to the LED shields. This works nicely but for my next project I wanted to use a Teensy3 in conjunction with a WIZ820io. I had some success getting the WIZ820io to "talk" to the Teensy3 on a breadboard so I have started laying out an adapter board similar to the one above. As opposed to the adapter in the image, however I wanted to be able to "stack" the new adapter board onto the LED shield, equivalent to how one does that with a normal Arduino. As the shield really only needs GND, SDA, SCL to connect to the adapter board there were too few traces on the board to justify its existence and the cast majority of the Teesny3 pins went unused. So I decided to try routing these in Arduino fashion and this is the WIP so far:


I have yet to connect the I2C bus signals to the ethernet jack in the lower left part. Here's one question:

Is the I2C hardware on the Teensy3 FM+ compatible ?

I am aware that it can run the I2C bus at frequencies much in excess of 1MHz but FM+ means that they can also drive more current in order to deal with higher bus capacitance. The dual row of 8-pin headers are meant to receive a I2C buffer e.g. a PCA9600 in case one wants to drive the I2C bus over long wires.

The second question: Is the Teensy3 I2C hardware 5V tolerant ?

I've had no problems connection it to the 5V LED shield but not for extended periods of time and I 'd rather not take chances ;-).....

 

[PaulStoffregen]

Is the I2C hardware on the Teensy3 FM+ compatible ?

In theory, probably. The hardware certainly can support 1M clock speeds. You'll need to edit Wire.cpp. Look for the commented out lines to enable a different default speed.

Whether the drivers are capable of discharging the capacitance of longer wires and many devices at that speed is a bigger question. I can tell you I did some experimenting with different pullup resistors. When you go below 1K, the I2C still works, but if you view it on a scope, the driver no longer pulls the line all the way to ground. It still gets within 0.6 volts down to only a few hundred ohms, so with most I2C chips that is very likely to still work. But if you're using this for a production board, I'd highly recommend checking the actual signals with a scope before you make lots of boards.

[/QUOTE]
The second question: Is the Teensy3 I2C hardware 5V tolerant ?
[/QUOTE]

No, none of the pins are 5V tolerant.

However, they can take up to 10 mA of current injected per pin. I2C never drives high, the logic high is always due to a pull resistor, so the injection current spec is what matters. I believe there's also a spec on the total injected current, but you won't hit either of those limits with just 2 pins with pullup resistors. However, the diodes in the chip will prevent the resistors from pulling up more than 3.9 volts. About 1.1 volts will be across the resistor, so if using 470 ohm resistors, you'll be injecting about 2.3 mA per pin. If you need a true 5V I2C signal, you'll have to use a couple mosfet transistors to isolate the 3V and 5V I2C buses.

 

[Headroom]

Paul,

Thanks for the quick answer!

Yes, the hardware seems supports much more at least in terms of frequency. I've done some (very) rough measurements posted in this Threadusing the alternative I2C library that easily allows to use frequencies ip to 2.4 MHz.

There is some good info on the effects of pull-up resistors here at DssCircuits.
My idea with the double row of 8-pin headers was to integrate this I2C Level converter also from Dsscircuits. In that case it actually eliminates the need for Pullup resistors if I understand the description and spec sheet correctly.
Or one can put a "real" bus buffer like the PCA9600 on a little daughter board and extend the I2C bus many meters even at 1MHz bus speed.I've poured over that spec sheen many times.

I thought I remembered the the Teensy I2C was 5V tolerant, but when I measured the signal with a scope it showed only 3.9 V as you mentioned.

 

[Headroom]

Boards for my Teensy3 WIZ820io adapter are ordered. I've included a PCA9600 I2C bus buffer for full FM+ capability, that also does the level shifting between 3.3V on the Teensy3 side and 5V on the LED shield side.

More info HERE

 

[PaulStoffregen]

I would recommend conecting the Wiz820io reset to pin 9 on Teensy3.

 

[Headroom]

I see ;-) Thanks Paul!
Looks like I misinterpreted the info on the pinout even though A11 (which it is connected to now) is a pretty strong indication that its an analog and not a digital pin.

 

[PaulStoffregen]

Also, I'm planning to publish a modified version of the Ethernet library which automatically detects W5100 and W5200. It will have pin 9 as the default pin for the W5200 reset. So if you use pin 9, your hardware will be compatible with Teensyduino's future mods to Ethernet.

 

[PaulStoffregen]

One other comment about the PCB would be heat dissipation for that voltage regulator. The W5200 can use quite a bit of current. I'm guessing the bottom side has a copper pour? You might pay attention to how the copper connects to the heatsink tab... with thermal reliefs or as a "flood over"? If you move the nearby traces away, you'll increase the area of copper that's thermally joined.

 

[Headroom]

Thanks for those tips. Pin 9 it is!
Great to hear about the upgraded future library as well.
Yes, the free surfaces on the bottom and the top have a copper pour for that reason. I had thought of distributing a number of thermal vias around the perimeter of the Cooling tab but simply forgot about it. I'll keep a close watch on the thermal behavior.

Now I am really eager to get the first boards in hand see how this behaves in terms of Ethernet throughput. In the OSC thread Adrian already mentioned that they have been getting better throughput using SLIP through a USB cable than with the old W5100 Ethernet chip. It would be ingesting to see what can be achieved wirelessly with the W5200 on the WIZ820io.
The "next" bottleneck I would imagine could be the SPI library. It would be very interesting what can be achieved when consolidating a few efforts that are already going on her on the forum to improve SPI performance.

 

[PaulStoffregen]

I'm curious to hear what sort of real-world performance you see with the W5200.

In terms of the chip's SPI protocol, the W5200 has 4 bytes of overhead per transfer, instead of only 3 on the W5100. But the W5100 transfers are limited to only 1 byte, so W5100 always has 75% low-level protocol overhead. The W5200 chip has 80% overhead for single byte transfers, but you can transfer any amount of data. For large transfers, the overhead becomes much less.

These are just the low-level transfers. Transfers to and from the chip are used both for moving data and for managing packets and other non-data movement. Nearly all of those non-data requirements are 16 bit numbers, but some are 8 bits. Currently, every W5200 adaptation I've seen is a copy of Wiznet's example code, which handles all those 16 bit registers as two single byte transfers. I have a mod in development that will change those to 2-bytes, so the majority of non-data manipulation will become 6 SPI bytes instead of 10, which is probably as efficient at things can get.

Of course, what really matters is moving data in big chunks. Sadly, that's not so easy. For OSC transported over UDP, the very best approach would involve building a complete packet in RAM and then sending it all to the W5200 as a single transfer. Likewise, the fastest reception would bring in an entire packet from the W5200 all at once. But this would require a large buffer in RAM, which isn't a huge problem on Teensy3, but for boards like Arduino Uno it would take far too much of the memory. Nearly all libraries are designed to work with those 2K memories. For example, the OSC library requests data in small chunks as it parses a received packet. Even just a 4 byte transfer (on W5200, 8 SPI bytes) is far better than doing 4 single-byte transfers.

I'm considering also adding a buffering layer into the Ethernet library. The basic idea is to have a modest buffer, perhaps 60 to 100 bytes. When the application requests data, the buffering layer will increase the size of the request to the W5200 chip to fill up the buffer with as much data as possible. Then subsequent requests will come quickly from the buffer. That's extra overhead, but for the common case where data is read in very small chunks, or even 1 byte at a time, the buffer management ought to be far faster than the SPI protocol overhead. I might also try this for transmitting, but that's tricky because there's no easy way to know when to flush the buffer.

The main thing that's currently missing is a set of benchmarks to actually measure the performance. So as you work with the W5200, I hope you'll consider turning some of your measurements into reproducible benchmarks. I'm definitely planning to do a nice unified W5100+W5200 with optimizations for W5200. Benchmarks will help.

 

[stevech]

On an AVR, as I recall, I did a '5100 chip SPI interface at 4MHz.
IIRC, the AVR limited the SPI clock rate to 1/4 the CPU clock rate which was 16MHz in my case.
What's the max SPI rate on the M4 CPU?

A gotcha on the '5100 is that the TCP stack did not implement dynamic TCP window sizes. This was a huge problem for my app- where I had dozens of 5100 chip based devices on 3G cellular. In the busy hour, the delays got so large that TCP ACK timeouts were too frequent- because the window size was fixed. I had to use the disable-windowing option in the 5100 to get cellular IP to work reliably for FTP. It was OK for low volume traffic.
I wonder if the 5200 added dynamic window sizing (also called adaptive window size). You can google 'tcp adaptive window size' to learn more.

 

[PaulStoffregen]

The Arduino Ethernet library defaults to 4 MHz because some older versions of the Ethernet Shield used resistor dividers instead of buffer chips. The resistance and capacitance of the input pins on the W5100 + SD card was too slow for 8 MHz.

Even if you use 8 MHz, there's considerable overhead between each byte. The AVR SPI port lacks buffering or any other mechanism for the next transfer to be queued up and begin immediately without software delay. Using the SPI library (polling SPCR), it's difficult to achieve faster than about 5 Mbit/sec. This same software limit applies to Teensy3 when using the AVR SPI library or AVR register emulation.

For native code, Teensy3 is capable of 24 Mbit/sec SPI. It also has a 4 word FIFO, which makes it possible to queue up the next few bytes, so you don't get software delay gaps.

But how fast that really works with a W5200, taking all the other software issues and the W5200 protocol into account, is a good question. That's why some good benchmarks really need to be developed.....

 

[stevech]

I would be surprised if the WS5200 can run at 8+MHz SPI. If I recall correctly, it too is an 8051 and may not have DMA on SPI.
But of course, very few if any small-micro TCP applications need such speed.

 

[Headroom]

Well...in that case be ready to be surprised!
You may want to give this thread a good read.

That's what I meant when I talked about consolidating efforts in one of my posts above. There are some incredibly talented and experienced people on this forum doing some great work. It would be great if that could be funneled into creating some libraries , like a Teensy3 optimized SPI and Ethernet library. I personally don't mind for a library not being 100% compatible to a given Arduino.

The i2c_t3 library written by user nox71 (IIRC) would be a very good example of such a thing. You can use it with an Atmel based board but it also provides special functions that allow you to really take advantage of the much more capable hardware I2C of the Teensy3. Arduino compatibility is a nice thing, but not at the expense of performance ;-)

 

[Headroom]

The Frankenduino or Frankie is ready to play.

Here are a top an bottom view of the unpopulated boards from OSC park. You get what you pay for. When looking closer at the boards from Itead, which I used to prototype my LED shields it is easy to see that they sacrificed drill precision for speed. Drilling the vias is one of the more time consuming thus expensive processes in PCB manufacturing.

The vias in the OSH park boards are one mil larger (13mil vs 12mil) but they are dead center in the pad. Aside from that, the OSH park boards generally being gorgeous enough to work as jewelry :


Here is Franky fully populated :



While I have not tested out the I2C buffer functionality, Ethernet with the WIZ820io seems to work fine. It takes 3 seconds after power-up to register an OSC server service per Bonjour on the network through a TP-Link WR703n WiFi pocket router. TouchOSC picks it up nicely.
While I reflowed the components onto the main board in my toaster oven (due to the Inductor) I was a bit nervous about hand soldering the small 0603 resistors and other components onto the I2C buffer board. However, that turned out to work surprisingly well. I think the trick is to have some good, small solder wick, but the real secret weapon is a good flux pen.

 

[Headroom]

A recent post in the MicroSD guide thread caught my attention. The one thing that my "Adapter" board still needed was a form of non-volatile data storage. The main aim of my board is to be used in my lighting systems and being able to store a configuration for example the last used brightness and fading speed was needed, so I integrated the same Micro-SD card socket that is used on the one in the PJRC store. There was no space on the board for the complete PJRC adapter board, but the card socket should fit underneath the Teensy3:



The PCA9600 based I2C bus buffer also works at least as a level converter as I have only tested it on a LED shield directly connected to Frankie. I have not tested it on any cable length and am waiting for some boards to come in from OSH Park. These plug directly into the LED shield for plug-and-play solution.



The whole I2C bus configuration follows this schematic:

 

[Headroom]

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:

 

[Headroom]

To somewhat conclude this thread, here is a picture of the upgraded version of the brains for a next LED lighting system as a direct comparison with the 1st post in this thread.
This uses a Teensy3 and WIZ820io Ethernet module.



Same functionality as above, fully remote controllable through WiFi using any iDevice (iPhone, iPad) and many Android devices using TouchOSC and the OSC protocol.
Soon I will add a simple IR remote control through a paired Apple Aluminum remote control.

Naturally performance is much higher than using the equipment as posted in the beginning of this thread. I've given some thought to exposing all the functions of the LED Shield (and perhaps more) through OSC. This would enable people to generate light shows directly from MaxMSP to Pure Data without having to program a micro controller

 

[manitou]

...

But how fast that really works with a W5200, taking all the other software issues and the W5200 protocol into account, is a good question. That's why some good benchmarks really need to be developed.....

Just revisiting W5200 and I have not used your new Ethernet lib mods yet, but a year ago I had done some benchmarks of W5200 and W5100 using fast SPI on various MCU's, including teensy 3.0. Thread was
http://forum.pjrc.com/threads/17951-WIZ820io-Ethernet-and-2nd-power-supply-with-teensy-3-0

and the UDP/TCP numbers are in
https://github.com/manitou48/DUEZoo/blob/master/wizperf.txt

 

[Headroom]

It would be very interesting if you could repeat these tests with the new Ethernet library. Paul's new mods to the Ethernet library for Teensyduino 1.18RC2 use SPIFIFO and should be a good bit faster.

 

[manitou]

It would be very interesting if you could repeat these tests with the new Ethernet library. Paul's new mods to the Ethernet library for Teensyduino 1.18RC2 use SPIFIFO and should be a good bit faster.

In the wizperf.txt results, there is a teensy column using (a year ago) the SDfat fast SPI which is close to SPI clock speed. With teensy 3.0 I was reading the WIZnet SRAM at 21mbs with 24mhz SPI clock. But I do intend to test the new Ethernet library.

 

[manitou]

It would be very interesting if you could repeat these tests with the new Ethernet library. Paul's new mods to the Ethernet library for Teensyduino 1.18RC2 use SPIFIFO and should be a good bit faster.

Here are first numbers on using Paul's SPIFIFO from the Ethernet lib to just read/write the W5200 SRAM -- guaranteed not to exceed. Tested on teensy 3.0 @ 96mhz. UDP and TCP test results coming soon ....

    w5200 buffer rd/wrt 1000 bytes (mbs = megabits/second)
            SPI         FatSPI          paulSPI 3.0         3.1
 1MHz       0.92mbs       1.02 mbs
 2MHz       1.55          2.05
 4MHz       2.85          4.02          3.98             3.98
 8MHz       4.06          7.94          7.87/7.79      7.88/7.79
12MHz       4.88         11.52         11.55/8.67      11.55/11.22
16MHz       5.45         15.17         14.65/8.67      15.23/14.65
24MHz       6.15         21.61         14.63/8.68      21.67/16.55

 

[Headroom]

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.

 

[stevech]

Does the FatSPI code use the SPI FIFO?

 

[manitou]

Does the FatSPI code use the SPI FIFO?

Yes FIFO with 16-bit frames. The SPI is lifted from SDfat library. The spi4teensy3 library is very similar to the SDfat implementation.