rp2: Add Wiznet W5100S-EVB-Pico board. #8540
Conversation
1fc2cf6 to
60c1c50
Compare
|
The stm32 CI build failures prompted me to update all the wiznet drivers to a current consistent state. The formatting of these C files is very inconsistent. @dpgeorge do you have a preference with regard to either: |
|
Does it make sense to have wiznet ioLibrary_Driver as a git submodule? |
|
Thank you for your efforts to give these w5100s boards some attention. |
|
{Disclaimer: I may not know what I am talking about. I have a 'standalone' Pico and a separate WIZnet Ethernet 'Hardware Attached Underneath' It doesn't work for me as released. Attempting to build from the linked commit results in a I tried resolving this by 'Brute Force' as a change to the declaration in the .h file - With that change the firmware build runs to completion and creates a .uf2 with these properties - Q: Should I expect MicroPython v1.9.4? The MicroPython firmware can be flashed to ny Pico and is correctly detected and reported by the Thonny REPL: But when connected to the Wiznet hardware it does not perform as expected - Retrying with explicit creation arguments - (Note that the LAN to which the module is connected operates its DHCP server in subnet 192.168.1.n, But the Good News, of sorts, is that if I create the network.WIZNET5K() and SPI instances with A lot of words there, hope it is of some use. Content to get polite feedback if I have tl;dr: It works after manual patching, although it looks as though it shouldn't. And only |
|
Thanks for the testing reports @DeeJay !
Good catch.... I broke this in my latest commits to bring the wiznet driver closer to the upstram published version. They don't have the
Not sure why you're getting this, perhaps the git tags aren't all fetched on your repo?
This is really interesting, I hadn't seen it earler. There's something a bit strange going on here, not sure what yet. but when it fails; So sometimes the auto configuration is grabbing the wrong pins, somehow. Haven't got to the root cause yet.
Good catch - I actually hadn't realised the 192.168.0.18 was a hardcoded default myself - turns out this is shared with the original stm32 driver too. This should also probably be abstracted out to defines, or perhaps the default should be a I also didn't know about / hadn't tried the
Quite helpful thanks! I also hadn't done more than ping tests yet - certainly will be important to check socket does indeed work correctly! |
d2edbbd to
b1d3e04
Compare
|
Well that was daft - I was never actually configuring the sck/miso/mosi pins on the auto-created spi object. Fixed now. |
|
Thanks for the acknowledgement and prompt fixes. I'll retest later today (UK time.) Re: "Version 1.9.4" - I was testing against your GH repo which I got by - Is that the right starting point? |
|
I'm very happy that someone is trying to make this work, so I tought I could try to help by testing at least. As i understand it this should also work with the W5500. I cloned with: The make then failed with: I added the */ that seemed to be missing, and it then compiled sucessfully. But trying to start the interface gives just the defaults, same as @DeeJay :
So DHCP is definitely not working. Just to be sure i also downloaded the firmware to a bare Pico, not connected to anything and tried to intitialise the non existing interface. It gives no errors, but everything is 255.
So atleast there is some communication between the RP2040 and W5500. I also get the 1.9.4 version: |
|
Another issue is that there doesn't appear to be any way to set the MAC address. The comment says "// set some sensible default values; they are configurable using ifconfig method". But there does not seem to be any way to set the MAC with ifconfig. And I would argue that a "default MAC" is in no way "sensible" MAC address should probably be a mandatory parameter when instancing the NIC. (Ideally you would read a unique MAC from something like a Microchip 24AA025E48 first.) But this seems to be the same in the STM port. I can't understand that anyone can ever have used this successfully if they have more than one unit running the same firmware on the same network. |
|
Feedback on commit b1d3e04 MicroPython v1.9.4-4262-gb1d3e04a9-dirty on 2022-04-19; W5100S-EVB-Pico with RP2040
$ ping 192.168.1.84 Default constructors appear to work as expected. Ping works. An attempt to create an mqtt client publish script failed - hung at mqtt.connect(). Further investigation needed. Higher-level (socket) protocols are unproven at the time of writing. Still builds as v1.9.4 |
|
Still puzzled by the failure of network.WIZNET5K,regs() to return any result. It is an apparently valid function reported by HELP - It seems the only place it can be implemented is in ports/rp2/modnwwiznet5k.c (This where your new spi function is implemented, so is clearly part of the build process.) The relevant declaration begins - I am not a C programmer, but I don't see how this can fail to emit that "Wiz CREG:" message. |
|
Andrew. You have probably done your own background research, but just to pass on what I have picked up... Wiznet carried on working on an independent vendor-provided version of uPy firmware after their PR 8021 'stalled' Their most recent release, v1.0.4 was in mid-March 2022 and is available here - https://github.com/Wiznet/RP2040-HAT-MicroPython (this is not the same GH account or Repo as the one that promoted the PR.) If I run that firmware on my Pico + W5100S combo the MQTT Publish (modules +script) Test is successful, so there might be lessons to be learned from that version of their codebase? In that version there is an additional function WIZNET5K.active() which invokes a DHCP client attempt to get and apply the 4 config items needed by the WIZNET5K.ifconfig([]) Setter function. |
Ah, yes I wouldn't normally clone direct from my fork, I guess the "correct" method is to cover this main repo, then there's a button near top of this PR to check out the PR. Compiling from my fork will get a comparable / working build but I don't have the release tags so that explains the version issue. As far as testing the wiznet feature though you can safely continue with what you're doing and ignore the version. |
That must be about error I just added while trying to clean up some inconsistent / ugly commenting in those files, I'll fix it.
Yep I don't think DHCP is designed to be built in at all, there's presumably a separate DHCP client application / driver that could be run to handle this - I haven't looked into that yet though. |
This does appear to be quite an oversight in the existing / current driver. I will need to look into options for this - certainly bring able to set it at least will be important, regardless of whether or not a "default" is provided. |
Yeah this one has me puzzled currently too. C |
Thanks for the suggestion! While I'd seen this previously I didn't reference it during development so far - I'd initially assumed the existing driver here was stable / complete enough.
I actually think wiznet supply a C DHCP driver which could be built in, I'm guessing that's what they're doing in their fork here. Certainly sounds like it's worth using, would be simpler to have it built in. |
So I've definitely learnt something about git/GitHub here.. That code button at the head of this PR page required me to install the gh CLI tool, and get a GH access token to authenticate it, Once I had done that I could do - That concludes with - When I now build from the resulting checkout I get a firmware that reports the 'right' MP version - This doesn't affect any of the functional issues, but it means I can be more confident that I am accurately testing |
|
I have a proposed trivial patch to enable network.WIZNET5K.regs() to produce output - (Only the first #define is significant - the other changes just hard-code the IP config for my LAN.) Having done so, a call to nic.regs() produces output. But the output is wrong. Every byte is reported For comparison, this is the output from the WizNet v1.0.4 firmware - I don't know how to interpret this, other than the fact that the MAC address is present in the first line. And CREG Byte 0x3C appears to be an indication of whether the Ethernet Link is Up/Down. |
|
@DeeJay I actually found exactly the same today, worked on this a bit this afternoon. I manually merged in pretty much everything from the other wiznet repo and saw that same define which enables printf, fixing regs. Once that's working, I'll probably try to separate out any changes in the wiznet driver into a new PR on their repo, if/when it's merged we can simply include it here as a submodule rather than a patched copy. |
|
#8021 |
This original PR is not yet in a state ready to merge:
Don't get me wrong, it was a fantastic piece of work which was a great starting point for me here - indeed I've kept most of your changes in commits authored by you (with cleanups I've made along the way). I hope you're happy with me keeping your name on these modified commits @irinakim12 ? I've also been referencing your other patch fork/repo to bring in your more recent changes such as dhcp support, which is certainly a worthy addition (not pushed here yet). Once I've fixed the incompatibility issues between the official wiznet driver and th copy of them here I think this PR will be in a quite good state. |
fe62f5b to
f05cd6a
Compare
Signed-off-by: Andrew Leech <andrew@alelec.net>
This works if your network is pre-configured in boot.py as an object called: nic Without this multitests expects to access the WLAN class which isn't always correct. Signed-off-by: Andrew Leech <andrew@alelec.net>
This exercises the inclusion of a number of libraries in the rpi2 port including mbed and lwip. Signed-off-by: Andrew Leech <andrew@alelec.net>
4c8d929 to
e58596f
Compare
|
I rebased this and merged it in 9bd6169 through b92e51e, with some minor changes to formatting and removal of unnecessary header includes. @andrewleech would be great if you could re-test it on hardware with master. |
|
{to avoid confusion - I am NOT @andrewleech the PR author. But I have been following this PR with interest} Please find below a test report based on my experience; Test conducted using a classic 'standalone' RPi PICO with a separate Using this Build from Master - Network initialisation - Standard Ping - Flood Ping - IPERF - uRequests - MQTT Publish + Subscribe Client - In summary - I have found nothing of concern to report about this implementation. Thanks to Andrew and Damien for their efforts. |
|
@DeeJay Three points about the tests that I would like to know:
Thank you! |
|
I started some tests running on friday which were looking good, but then computer restarted before I could copy the results here. Basically Also:
and
|
SSL mode in both mqtt and https should work in a standard way, mbedtls for ssl support is integrated with the standard micropython ssl interfaces. Most testing here has only been done on the W5100S-EVB-Pico board. The W5500 chip should work and has had a little testing in the past (#8540 (comment)), but I don't know of any testing on other wiznet chips on the final merged version of the PR. |
|
@andrewleech Thank you for the reply and for the amazing work on the Wiznet5k driver for the rp2. Just curious about some points: 1. Is this ethernet driver for the Thank you in advance! |
With the unit test suite, the
If you look through the earlier messages on this thread where these unit tests were run previously, the fails were seen there and discussed briefly. I think they fail on multiple platforms currently so possibly relate to common code, not just this board.
This PR incldued a new consolidated wiznet driver in the extmod directory. The stm32 port already supposed the same two modes of wiznet interface through a pair of drivers in the stm32 port folder, however the new one has more features. The stm32 port can be updated to use this new driver, however I don't have any immediate plans to do this myself as I don't have any stm32 boards with wiznet (and too many other projects on the go).
As above, yes this is a new common driver that could be used for any port, if anyone else wants to add support.
In mac raw mode the hardware sockets limit won't apply at all, you'll only be limited by available ram on the micro I believe. If instead you build in the external stack mode, then it's stlightly faster in most cases, uses less ram, but has less features and yes the limit will apply. |
|
I also want to test this on a custom RP2040 board with W5100S controller. Do i simply need to pick the last nightly build or it require manual compilation? Thanks, |
You should be able to use the nightly builds for the W5100S-EVB-Pico board. If you connect the wiznet chip on the same pins as the official board it should just work, else you can specify all the pins used during initialisation in python. To use a different wiznet controller chip though recompilation would be needed. |
|
My board is similar with W5100S-EVB-Pico, only with PoE ethernet made it specially for my home. Was very disappointed when i test it with Wiznet oficial firmware and HomeAssistant. In Home Assistant i declared a switch for every GPIO pin, but because of the sockets limit just the first declared switch was added, all others where considered offline (probing http requests are send simultaneous by homeassistant and this cannot be changed). With the firmware you made i set 7 switches and all where added. I did not test with a bigger number since i don't think i will need more than this. Overall i think you did a great job. Thank you very much! |
|
Is there any chance to use this driver on ESP32 ports? That would be a great thing to add to other ports. |
The commits in this PR that handle bringing in the wiznet driver should be straightforward for someone to port to esp32 - it's already got tls & lwip I believe so those other commits shouldn't be needed. Considering both this PR and esp32 use cmake it should transfer pretty easily. I don't have hardware (or time) to handle this myself but would be happy to assist anyone else trying to do it via slack etc. |
|
Yes I am very interested! I'm not very good with git so I could use some help. I have cloned micropython and micropython-libs to my computer and pulled the latest master. I've built micropython firmware before and I've used IDF for some time. but when it comes to what it takes to get this driver, I could use some help. slack would be great! |
If anyone is interested W5500 seems to still work in Micropython 1.19.1. |
@Lobo-T Which build have you tested separate W5500 board to be working with RP2 ? Further, did it require any change in option or compile time flag ? I have made a build but it stalls at active(True) |
|
I think I pretty much copied the mpconfigboard.cmake and mpconfigboard.h files for the W5100S_EVB_PICO and just changed set(MICROPY_PY_NETWORK_WIZNET5K W5100S) in mpconfigboard.cmake to set(MICROPY_PY_NETWORK_WIZNET5K W5500) I seem to remember that I had some problems with it hanging and not timing out if there were no network cable attached. But this does not seem to be a problem with the latest build (v1.19.1-129). |
|
Ok, Thanks @Lobo-T Interestingly, this setup had worked with default binary build of 18th March 2022 as provided by the manufacturer. I shall update the outcome. |
Yes, it's working for preliminary tests. Any further issues, I shall communicate back |
Hello @liudr Did you have progress to port this driver to run on the ESP32? I'm very interested as well to use the W5100S on the ESP32-S3. Thank you in advance! |
I never got any help from anyone. If someone is willing to help me get this started, that'd be great. I need some help to do this. |
|
Hi @liudr
Did you tried to call the @andrewleech on the I see that you (at least with nick @liudr) are not in the I hope that you can get appropriate help, because to have this driver ported to Please, let me know if you got the help :) Thank you. |
|
Hello @liudr Any news about to use this PR driver Just to notice you: the I would like as well so much to use the Thank you! |
This PR builds on and extends the prior work done in #8021 to provide the Wiznet Ethernet driver on Raspberry Pi Pico port, cleaning this up and pre-configuring it on the board for
W5100S_EVB_PICO.This board config should also work on the regular Pico with the Wiznet RP2040-HAT-C module attached, I believe the same pinouts are used.
Build
cd ports/rp2 make submodules make clean BOARD=W5100S_EVB_PICO make BOARD=W5100S_EVB_PICOFlash the normal way for rpi pico as per https://github.com/micropython/micropython/blob/master/ports/rp2/README.md
Usage
The HW configuration for W5100S_EVB_PICO has been pre-configured, so to enable the network access you can simply do something like:
This was done with the board network interface connected to a local router supplying DHCP.
The pinouts can alternatively be configured at runtime:
The older Wiznet drivers in micropython/drivers have been left untouched for now. Changes added to them in the micropython repo since they were first brough in have been rebased/refactored into a new MR on the (now available) official driver repository: Wiznet/ioLibrary_Driver#120
The exported function name fix commit in this in particular is essential to allow usage of the upstream driver here in micropython.
The branch in the wiznet driver repo PR has been brought in here as a submodule in the micropython/lib folder for use with this PR.
In #8021, @irinakim12 ported
stm32/modnwwiznet5k.cintorp2/modnwwiznet5k.c, updating it to use machine.pin and machine.spi interfaces rather than the original stm32 HAL interfaces. I've now taken this further, migratingmodnwwiznet5k.cto extmod with appropriate updates to use global definitions where possible.Further updates to
rp2/modnwwiznet5k.cmade in https://github.com/Wiznet/RP2040-HAT-MicroPython have also been selectively merged in, particularly the dhcp support. I've renamednetwork.WIZNET5K().active()function tonetwork.WIZNET5K().dhcp()however to better reflect its functionality.I've also ported the
network_wiznet5k.cdriver from stm to extmod/rp2 and brought LwIP support into rp2. This driver is now the default one as it has broader compatibility with other network features, and includes things such as a user api for mac address. For more details see https://docs.micropython.org/en/latest/library/network.htmlThe updates made here to use the extmod machine interfaces to SPI & allow defining the default wizmac pintouts in the board config have also been ported into
network_wiznet5k.c.This extmod version includes a default MAC address generated in the "random" address space, but statically defined by the individual chip unique ID.
These updated extmod interfaces should work on the stm32 port with little effort. I'd like to migrate the stm32 usage of wiznet drivers over to this new lib & extmod interface in a follow up PR, at which point the legacy drivers/wiznet folder will be ready for removal.