Anyone used the Wiznet ethernet chips?

[nctnico]

I'm working on a new design which needs network connectivity. The chips from Wiznet which offload dealing with the low level stuff like TCP/IP, UDP, etc look appealing to me. Does anyone have experience with these chips? They seem available from Mouser en Digikey so people must be buying them.

[asgard20032]

Arduino ethernet shield use them. But nowaday, when someone need ethernet, its far more easier/cheaper to use a mcu with an on board ethernet than to buy an extra chip. Look at pic32 and arm cortex, lot of part with ethernet.

[nctnico]

I have been down that road before but the problem is in the TCP/IP stack. In my experience it does take ironing out bugs before the product is really stable. I'd like to avoid that for this project. Besides that the W5500 chip isn't that bad pricewise considering most controllers need an external phy and a microcontroller without ethernet (dealing with the rest of the application) can be extremely cheap.

[lukier]

On the other hand you could fix critical (security) bugs in the network stack as a part of your in field firmware upgrade (i.e. upgrading uIP there).

This chip probably has the same issue that TCP/IP offload engines have - network stack is hardwired and if it has a bug then it becomes serious vulnerability that is impossible to fix.

[JoeN]

On the other hand you could fix critical (security) bugs in the network stack as a part of your in field firmware upgrade (i.e. upgrading uIP there).

This chip probably has the same issue that TCP/IP offload engines have - network stack is hardwired and if it has a bug then it becomes serious vulnerability that is impossible to fix.

Nothing is impossible to fix if your router can apply flexible filters.   O0

[Chris C]

I've used the W5100 and W5200, with driver code written from scratch.  I can share some experiences and opinions on those chips if it would be helpful to you.  But I'm not familiar with the W5500 specifically.

[westfw]

These days, I'd worry about lack of IPv6...

[nctnico]

I've used the W5100 and W5200, with driver code written from scratch.  I can share some experiences and opinions on those chips if it would be helpful to you.  But I'm not familiar with the W5500 specifically.

Since the W5500 seems to be an improved version of those chips I would appreciate every comment on those! Why did you write your own driver code? I have not looked at the code provided by Wiznet yet.

[Chris C]

The Wiznet chips are well supported on Arduino, but I have a PIC.  Searching for PIC code without any dependencies on Microchip peripheral libraries or similar, I came across this first:

http://www.ermicro.com/blog/?p=1773

Which is for AVR (not Arduino), but it was a good tutorial, with simple example code.  Looked easy enough to port, so I had a go at it.  With it and the W5100 datasheet, I had basic TCP/IP working in a few hours.  Then a couple more days experimenting, optimizing, and tying it into my personal programming environment; which ended up being a total rewrite.  Since I do this to learn more than to achieve an end result, for me it was time well spent.  None of it was particularly hard, the chip really does hide most of the complexity.

But there were some issues.  The W5100 has a linear memory space, containing both the control registers, and the circular (ring) buffers for RX/TX data.  Let's say you want to send multiple bytes of payload data over SPI to one of the circular buffers.  You must:

1) Lower the chip select (CS) line.
2) Send the "write memory" command.
3) Send the low and high bytes of the memory address, where you want to place the data byte.
4) Send the data byte.
5) You cannot send another byte, because the address doesn't autoincrement.  Sending another byte will *replace* the one you just sent, at the same memory address.  You have to send a new address, which requires raising CS and going back to #1.

Transferring 4 bytes for every byte of real data is terribly inefficient.  The W5100's speed is limited more severely by this, than by its 10Mbps Ethernet.  Plus it's extra load on the host MCU, since you're recomputing the address for every byte.  And since you're having to toggle CS regularly, you can't even take full advantage of DMA.

The W5100 also doesn't tristate MISO when CS is high.  This non-standard behavior really should be mentioned in the main datasheet, but it's not, only in a separate app note regarding SPI.  If you intend to have it share a bus with other SPI peripherals, you must add an additional buffer IC.

So I upgraded to the W5200.  It has 100Mbps Ethernet, and more memory; neither of which I actually needed.  But it autoincrements, and tristates MISO.  Presumably newer versions include these enhancements as well.  Converting my code was just a matter of putting in new register addresses and buffer ranges, other than the differences I listed it's virtually identical.  I'm happy with this one.

There's one other thing worth mentioning.  Neither chip seems to have a power-on reset function, or if it does, it doesn't work well.  Do NOT skip manually asserting the reset signal after power-on.  Do NOT try to be clever like I did, and attempt to conserve an MCU pin by using a RC reset circuit.  Do NOT assume any pre-built module with these chips has a pull-up resistor on reset (mine didn't).  If you fail to reset it after power-on exactly as described in the datasheet, it may confound you by working many times in a row, then failing when you least expect it.  The W5200 can also fail to tristate MISO if not reset, blocking comms with other SPI devices on the same bus.

[nctnico]

Thanks for these remarks! 

[Jeroen3]

I considered wiznet, but since the STM32F family already has ethernet capable devices, it was more compact to choose that with lwip.
Reflecting on the choice, I also would have bought an validated IP stack if I had to do it again.

There is also lantronix who develop IP stacks inside the RJ45 connector.

[westfw]

The much remarked ESP8266 also has an internal TCP stack.  By default, it communicates with the host over serial, which might dramatically slow throughput.  Or not, depending on the complexity of the SPI protocol for the WizNet.

Lantronix I'd be very inclined to trust, but you pay for that!

[Kjelt]

I considered wiznet, but since the STM32F family already has ethernet capable devices, it was more compact to choose that with lwip.
Reflecting on the choice, I also would have bought an validated IP stack if I had to do it again.

From company experience I can tell you that even commercial "validated" IP stacks from small companies needs much debugging for specific purposes like IP6. Sometimes we had more SW engineers working on it then there were in the other company 
For my own hobby I am also interested in LWIP over STM32, since company code is restricted 
 Was your code for yourself or commercial? Are you willing/able to share? Or share the pitfalls/ problems, perhaps in another topic so not to hijack this one, sorry Nico. Still LWIP over STM32 might be a better alternative than a standalone implementation if Jeroen for instance wants to share his work.

[Jeroen3]

The final implementation was commercial. But is was based on Chibios with lwip.
Lwip proved to be a pita because there is no proper documentation. So you're basically required to fully understand lwip before using it. You'll have to look beyond the api, which takes a ginormous amount time.

ChibiOS is great. I strongly recommend everyone to use this at least once.

[nctnico]

The final implementation was commercial. But is was based on Chibios with lwip.
Lwip proved to be a pita because there is no proper documentation. So you're basically required to fully understand lwip before using it. You'll have to look beyond the api, which takes a ginormous amount time.

@Kjelt: I had a similar experience using uIP (I think lwip is based on it). uIP was written with the idea that short code in C also produces short code when compiled; it's complete mess  Unfortunately I had to leave my patched up version (with a BSD socket layer) behind at my previous employer.

[Kjelt]

That's a shame 
I can understand that you are going for a ready set go one chip solution, faulty IP stacks can take a lot of time to debug/fix, there goes the profit.
Also the interaction with the Phy were causing a lot of time to fix.
Weird that such a common interface/protocol is still not mainstream good quality open source available, esp. with the huge trend towards networking small embedded devices 

[Mechanical Menace]

Weird that such a common interface/protocol is still not mainstream good quality open source available, esp. with the huge trend towards networking small embedded devices 

If you asked most OSS devs who actually are low level networking gurus* for a solution their answer would almost certainly be "well you have embedded Linux and BSD options, what more could you want for networking? SOICs and RAM are cheap.**" They also may understand every watt counting but not every milliwatt.


*So not me unfortunately.
**That I believe is actually the approach of many a WiFi module among other things.

[technix]

Since I had experimented with both W5200 and ENC28J60, I would definitely suggest against Wiznet chips unless your MCU is too small to handle the TCP/IP stack. W5200 is all-in-one and can be bug prone, while one serious bug in W5200 you have to call your products back.

ENC28J60 is effectively only a MAC, you have to roll your own IP stack. This will allow simpler bug fixes. And the real balance tipper for me: ENC28J60 already have a fully working Linux kernel driver so if your MCU runs Linux, just compile that driver in and you can use that tested and trusted Linux TCP/IP stack. (hey, with two ENC28J60 you may even able to roll a router out of it.)

[nctnico]

Since I had experimented with both W5200 and ENC28J60, I would definitely suggest against Wiznet chips unless your MCU is too small to handle the TCP/IP stack. W5200 is all-in-one and can be bug prone, while one serious bug in W5200 you have to call your products back.

ENC28J60 is effectively only a MAC, you have to roll your own IP stack. This will allow simpler bug fixes.

If you have some way to update the firmware remotely then a software IP stack is easier to fix. Otherwise you'll have to recall anyway. Then again a software IP stack is more likely to have bugs. To me the Wiznet W5500 chip starts to look better and better. It is a product which has had several years of focussed development (IOW: it's not the first version) and has a large user base. I looked through their forum but I don't see any signs of serious problems. Actually I like the idea of having the IP stack running on a seperate processor. Buffer overruns in the IP stack cannot affect the main application processor in any way. If the connection is lost the main application processor can just reset (or power cycle) the Wiznet chip and try again.

[Chris C]

W5200 is all-in-one and can be bug prone, while one serious bug in W5200 you have to call your products back.

Anything can be bug prone.  But did you actually find a bug, or are you just speaking generally?

Originally I'd intended to use USB as the interface for my project, not Ethernet.  Spent two weeks trying to get a USB stack working on ARM, it kept crashing at random, looked in vain for the bug in the stack... only to eventually find it was a compiler bug.

Then decided my project was better done with a PIC.  So prior work on ARM stack was useless, and spent another two weeks tracking down actual bugs in Microchip USB stack.

Then discovered that too was useless.  The Windows USB drivers were so horribly inefficient, that transferring a mere 36K/sec, in frequent small packets, was consuming over half the CPU on the host PC.

Before these experiences, the ENC28J60 would have been my first choice.  But wasn't too keen on the possibility that another MCU-hosted stack might lead to another two weeks' frustration.  Not for a personal project, anyway.  For a product, maybe.

[Kjelt]

@nctnico: just took a glance at the datasheet, unsure but looks like its only IPv4 not 6 and you don,t get a MAC adress so you have to get a range for your company. Unsure so check 

[technix]

W5200 is all-in-one and can be bug prone, while one serious bug in W5200 you have to call your products back.

Anything can be bug prone.  But did you actually find a bug, or are you just speaking generally?

Originally I'd intended to use USB as the interface for my project, not Ethernet.  Spent two weeks trying to get a USB stack working on ARM, it kept crashing at random, looked in vain for the bug in the stack... only to eventually find it was a compiler bug.

Then decided my project was better done with a PIC.  So prior work on ARM stack was useless, and spent another two weeks tracking down actual bugs in Microchip USB stack.

Then discovered that too was useless.  The Windows USB drivers were so horribly inefficient, that transferring a mere 36K/sec, in frequent small packets, was consuming over half the CPU on the host PC.

Before these experiences, the ENC28J60 would have been my first choice.  But wasn't too keen on the possibility that another MCU-hosted stack might lead to another two weeks' frustration.  Not for a personal project, anyway.  For a product, maybe.

As I said before ENC28J60 have a relatively good Linux driver. You can just go ahead and use Linux on your MCU, or if you are willing to GPL your code, lift the Linux ENC28J60 driver and Linux network stack code. That one is well tested and trusted.

[nctnico]

Using Linux or the Linux TCP/IP stack isn't an option on a microcontroller. There are not enough resources on a microcontroller to run that software. Besides that the Linux kernel source code is a complete mess so getting the TCP/IP stack out in one piece will be a large amount of work.

[Kjelt]

Depends on your definition of microcontroller  , I totally agree that on a typical Arm Cortex M3/4 microcontroller (72-120Mhz, 128-512kB Flash and 64-128kB RAM) Linux is absolutely a no go.
On a dual core A7 micro with 800MHz and 512MB DDR RAM it is very feasible as the raspberri's show.

[nctnico]

A SoC or Raspberry PI would triple/quadruple the BOM cost for the circuit I have in mind and the CPU would be 99.99999% idle.