Cosa
Cosa copied to clipboard
mikaelpatel
W5X00: Support W5200 and W5500 Wiznet ethernet chip based shields/modules
Not sure if this is the best way to provide a way of discussing this desire publically but for now it seems the best I can find and therefore perhaps adequate :smile:
I have created 2 branches off my fork of Cosa that should illustrate the changes required to the W5100 driver to alter for:
- W5200 https://github.com/dansut/Cosa/tree/W5100-W5200 have been rebasing to try to stay on top of origin Cosa, tested with a Wiz820io module. Has a couple of known issues: nRESET seems to need longer than normal for AVR so been doing manually, TCP client socket works once and then always times out (CosaWebClient example illustrates).
- W5500 https://github.com/dansut/Cosa/tree/W5100-W5500 based off the W5200 branch, tested with Microduino-W5500. No known issues, does not exhibit known W5200 issues.
There is no intention for these branches to be merged into Cosa core (W5100 support is broken), they are purely for illustrative purpose to show what support takes and thus changes have been kept to minimal to keep patches clean. The idea is that they may stimulate discussion as how best to add support for varied types of NIC within Cosa, considering potential of rolling existing CC3000 driver (and even considering ENC28J60, ESP826, or similar longer term). Most other AVR based drivers for these chipsets seem to take the route of completely separate files and lots of duplicate code but seeing the conciseness of changes needed it would seem desirable to avoid this route if only for maintainability and DRY principals. It could be done using #ifdef blocks but my feeling is there is an elegant OOP solution here more inline with the rest of Cosa's code.
My current project requirement was for Cosa support of the Microduino-W5500 and with this satisfied my time is very limited in the short term so I do not intend to look into the W5200 issues, or work on producing mergeable Cosa branch, until after this projects deadlines. I do want to be involved in this in the longer term if it happens, it just can't be my priority right now. I shall attempt to keep the above branches rebased to the HEAD of Cosa master, will fix any issues I find whilst working with the W5500 driver, and will engage in as much discussion as I can find time to relating to this matter :wink:
Cheers /dan
@dansut Great job, Dan! I will have to take a deeper look at what you have been up to. I fully understand your design concerns. This is a tough question as sharing of code base is very much a compromise between different factors. There might be a common class to be "found" between the different NICs. I think the Cosa Serial class is a good example of this type of development even though much simpler. NICs is somewhat more complex especially with the limited amount of SRAM and internal buffer design of the NICs. The CC3000 and W5100 device drivers have totally different buffer strategies due to this.
Unfortunately I do not have shields/boards with the two devices you have been working on. This makes contributing a bit difficult right now.
Cheers! Mikael
See commit https://github.com/mikaelpatel/Cosa/commit/4036628b9327d849000364f760176bdeb8e0106a.
I have not looked at this thoroughly yet, basically just scrolled through the above commit, but it seems you have got code for the W5200 in place, but not the W5500. Did you base this entirely off my fork for the W5200, and if so are you seeing similar issues to those I mentioned earlier here?
- reset needs more time
- sockets only work once
Are you testing using the wiz820io for hardware or something else?
I'm going to attempt to follow your lead with the w5500, my goal is specifically for use with the Microduino W5500 module used with their Core+ (Atmega644), but I have other hardware I can test with. If we can coordinate on this it would be great as it would minimize any duplication of effort.
Cheers /dan
@dansut
I basically merged the updates into an "include" level reuse variant (due to the change of the register map). The W5100 and W5200 have a common source but only on source code level (not class/object code). The W5200 worked fine and I did not see any of the issues you described though it required a lot of power. Tested with the wiz820io module.
Have not yet come around to looking at the W5500. Will have to read a bit more before I can say anything about this.
Cheers! Mikael
When I get the chance I'll make a branch on my fork that follows your W5200 lead with the W5500 then it is easy for you to pull in if you desire.
I shall have to give your merge in of the W5200 stuff a try to see if I can reproduce the issues I was having.
Cheers /dan
Found this thread looking for support for W5500, we are now using the W5200 on the WIZ820io module. Its need for a hardware reset is well-known. I am using the PJRC optimized library w5100 which uses the hardware SPI support in the ARM3 Freescale chips used in Teensy3.X. There is no such Teensy support for the W5500 or its module and it's not clear to me that the W5500 has a lot better performance. Although it is less expensive and doesn't have the ARP errata of the W5200. I'm starting with the DHCP test example in the Arduino examples. I changed the lease time of my Asus RT-N56U router to 120 sec, and it allows a renew() every 60 seconds. So I can get about 3 years of typical DHCP renewal in a 24 hour test. Guess what? It fails periodically, usually with a client address of 0.0.0.0, which is not legal... and should not have been issued by the DHCP server. The Arduino library reports no error on this "assignment" and there is no error on Ethernet.maintain() though such a request (to renew an invalid client IP address) makes no sense. So it gets stuck in a stable, jammed state. I've patched my app code for now to check for a zero IP and call Ethernet.begin() and log all failures to renew, rebind or restart. But getting the IP of zeros points to either a bug in the Arduino library (most likely) or the router (not likely). But it will take Wireshark and a SPI analyzer to nail this down.
So what is my point in relating all this? To express my interest in the library work you are doing. My goal is to make a high-reliability Ethernet library, starting with the (presumably well-tested and widely-used) Arduino libraries... so I need to take a closer look at what you are doing. I agree with @dansut's comments in the first posting here.
best regards Bruce Boyes
Any further progress on this? I have a W5500 (AdaFruit Feather) and could assist.
@jeditekunum Support for W5500 was unfortunately queued during this summer/fall; no progress. The initial refactoring for W5100 and W5200 was completed. I need to go back to my notes to see what the next step was. Support and assistance is always appreciated :)
@mikaelpatel @dansut I've started to see what I can do to bring both of your code bases together to add support for the W5500. My opinion at the moment is that the current code is not (yet?) conducive to this.
At the lowest level, the SPI interface, the W5500 has followed a different approach. dansut's code deals with this by passing around an extra argument to write/read. The macros M_CREG/M_SREG generate this extra argument. Which makes it incompatible with the attempt to separate common code in W5X00.
Roughly, the W5X00 directory has around 500 lines. Each of W5100 and W5200 have around 800 as would a future W5500.
So my question is one of direction. Is it worth continuing to mold these to achieve some common code? I suspect our best effort could easily end up having to change significantly again when the next model comes out.
This dilemma is one that I faced awhile back with my OLED driver. It ended up supporting three similar parts with either I2C or SPI and was very successful at code sharing. Not sure it was worth the effort.
@dansut @jeditekunum I think the current Cosa W5100 and W5200 is just a stepping stone. There is some history to the code base that I think is high time to try and explain. I started off with the W5100 class and used my normal coding style with register structs and bit-fields when possible. The W5200 was added as a quick fix. Basically making common code included as the major difference is the SPI protocol change. There are only a very limited change to the registers so that same struct was more or less possible. With W5500 the necessary changes are larger. My original idea was to simple make separate classes for each driver. This might be the direction to take (again).
PS: Sorry for the late reply. Busy with holidays :) and winter sports. BW have been playing around with Forth Virtual Machines again. Forth is really nice to have around when hacking hardware. My latest variant allows multi-tasking and easy integration with the Arduino core. Easy to port to Cosa (any day now).
@mikaelpatel @dansut https://github.com/jeditekunum/Cosa/tree/w5500 is my first pass at integration.
Changes to W5100 & W5200 files are only reference document & page numbers plus a bit of consistency improvement.
I copied W5X00.inc into W5500/W5X00_W5500.inc for first pass. Changes should all have #if surrounding.
It compiles. Not run/tested.
In a nutshell the way registers/memory is accessed is different with the W5500. There are now "control" flags, with a socket # embedded if a socket-related address, that effectively resolve the "base" address upon which the first addr argument is added. The driver no longer has base addresses hard coded.
I will look at it some more tomorrow. If anyone has any suggestions on how to proceed with this, please chime in.
@mikaelpatel @dansut Please see PR https://github.com/mikaelpatel/Cosa/pull/495
A quick post just to let you guys know I am listening and hoping to find some time to look at what you have been up to in the coming weeks. The project I was using the W5500 in slipped several notches down the priority ladder in the latter half of last year, but it looks like I'll be taking it off the shelf and dusting it down soon.
Great to have other people working on it as it can only lead to more stabile code - I don't have a Feather but may get one for testing, are there any other new W5x00 based boards that it might be desirable to make this effort support while I'm shopping?