PyBoard 1.1 and WIZnet 850io

[kwiley]

I see there is some discussion in the forums about using the WIZnet and the included code in the network module, but I haven't gotten it to work yet. I downloaded the latest stable network firmware, 1.9.4, dated 12/12/19. The WIZnet itself is plugged into a router. It's green link light is on while its amber activity light is periodically blinking, this without applying any code yet. If I make a nic, I don't get encouraging results. Shouldn't ifconfig() show a meaningful IP address and shouldn't isconnected() return True? I'm getting this:

Code: Select all

MicroPython v1.12 on 2019-12-20; PYBv1.1 with STM32F405RG
Type "help()" for more information.
>>> 
MPY: sync filesystems
MPY: soft reboot
MicroPython v1.12 on 2019-12-20; PYBv1.1 with STM32F405RG
Type "help()" for more information.
>>> import network
>>> nic = network.WIZNET5K(pyb.SPI(2), pyb.Pin.board.Y5, pyb.Pin.board.Y4)
>>> print(nic.ifconfig())
('0.0.0.0', '255.255.255.0', '0.0.0.0', '8.8.8.8')
>>> nic.isconnected()
False

I'm particular confused by isconnected(). Should it report a successful physical connection, which I clearly have since the WIZnet's lights are on? And tangentially, even if I could get the code above to work, I haven't found any sample code that shows how to actually use the ethernet connection to transmit or receive data.

Many examples, although not terribly old, seem to be incompatible, relying on functions like active() and passing the string "dhcp" into ifconfig(), neither of which seem to work with the API I installed. So I'm not sure why that so inconsistent either, although I suppose the code may have been evolving quickly.

Any ideas?

Thanks.

[kwiley]

Well, I'm totally perplexed about the WIZnet support. The code shows next to no changes three years (on the 5500), so presumably it is extremely stable. But at the same time, as I said above, fairly recently code examples refer to APIs that clearly don't exist, such as passing the 'dhcp' string or a nonexistent "active()" function. Where did this APIs go if the code hasn't changed in ages?

Furthermore, the setup seems pretty straightforward. I've wired a PyBoard v1.1 up to a WIZnet 850io (which is a 5500 board, not 5100 or 5200) on both of the PyBoard's SPI buses. I configured bus 1 exactly like the docs, using X4 for the reset. I also tried bus 2 with Y4 to no avail.

The green light illuminates immediately and the amber light blinks intermittently (although settles down and stops blinking). The desktop on the other end of the ethernet connection claims to see the connection. I have tried initializing the nic without passing parameters to ifconfig, in hopes of getting a dhcp assignment, and I have also tried passing in four manual strings. I confirmed the correct strings by attaching a laptop to the same ethernet connection and seeing what it got off dhcp. I tested manually putting those same numbers into the laptop and of course it worked, and then proceeded to transfer those same strings over to the PyBoard/WIZnet arrangement. If I don't pass anything in, I get ('0.0.0.0', '255.255.255.0', '0.0.0.0', '8.8.8.8') and if I do, I only get some of the four strings back: ('0.0.0.0', '255.255.255.0', '0.0.0.0', '192.168.2.1'). The DNS is the only one that stuck (and the subnet was the same anyway).

Even more confusingly, regardless of whether the network "works" I certainly expect isconnected() to report True under almost any circumstances since it is document to merely detect a physical connection, which seems confirmed by both the lights and the fact that the desktop sees the connection (if I unplug the ethernet from the WIZnet, the desktop's status changes!) but isconnected() always returns False anyway, which makes no sense to me.

I'm using the latest stable network build: pybv11-network-20191220-v1.12.dfu

I admit, the one discussion I found that seemed fairly clear about all of this (viewtopic.php?f=6&t=2515) is relatively consistent in claims that the 5500 doesn't work (suggesting only the 5200 instead). But that discussion is from three years ago. Is there any hope of getting the 5500 to work? What would that involve?

Thanks.

[Roberthh]

I have tried again with my Pyboard 1.1 and a W5500 breakout, and it works. The initialization sequence is:

Code: Select all

import pyb
import network
nic = network.WIZNET5K(pyb.SPI(1), pyb.Pin.board.X5, pyb.Pin.board.X4)
nic.active(1)
nic.ifconfig((IP,  NETMASK, GATEWAY, GATEWAY))

What I regularly forgot is this "nic.active(1)".

[kwiley]

I appreciate your attempt to assist me, but like I said above, that function doesn't even exist:

Code: Select all

>>> import network
>>> nic = network.WIZNET5K(pyb.SPI(1), pyb.Pin.board.X5, pyb.Pin.board.X4)
>>> nic.active(1)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
AttributeError: 'WIZNET5K' object has no attribute 'active'

I recognize that the API must be evolving out from under me in some fashion, but I don't know which firmware is the correct firmware. I downloaded the latest stable network firmware for the PYBv1.1, which is v1.12, or more precisely pybv11-network-20191220-v1.12.dfu, as listed on https://micropython.org/download/pybv1/ . I'm happy to try a different firmware version, but there's 13 different versions available, 4 unstable and 9 stable. Instead of downloading and flashing them all over one by one, it would be helpful to know which one actually works.

Would you mind telling me which firmware version you are running in your example that shows the active() function? That would be very helpful to me.

Thanks.

[kwiley]

Well, my confusion is getting worse. The function STATIC mp_obj_t wiznet5k_active(size_t n_args, const mp_obj_t *args) has been in the ports/stm32/network_wiznet5k.c file from the beginning and is still there. So I don't understand the behavior I demonstrated above, in which I can't access the active() function.

[Roberthh]

I cannot tell for the pre-built images form the web site. I compile the firmware with:

MICROPY_PY_WIZNET5K = 5500
MICROPY_PY_LWIP ?= 1

Since the body of ports/stm32/network_wiznet5k.c f is only compiled if these two flags are set.

[kwiley]

Well, I suppose I could delve into building my own firmware. However, when you say "the body of ports/stm32/network_wiznet5k.c f is only compiled if these two flags are set" I presume the fact that I can build a WIZNET5K object, as shown in my code above, demonstrates that those flags are, indeed, set in the network firmware I downloaded and installed. Otherwise the call to build the nic, in my code above, would have failed. Right?

I remain confused as to why I am having this problem when the module and device are claimed to work by other people. I'm not doing anything unusual. My setup consists of precisely two things: a PyB1.1 and a WIZ850io. I downloaded the most recent stable nework firmware and didn't mess with anything. The connections are clearly right since the WIZnet lights and the desktop end of the ethernet connection confirm the connection status. So it seems to me that if this is going to work for anyone, then it ought to work for my setup. I don't get it.

I appreciate your input, but I wish other people would chime in here and confirm that the v1.12 firmware either works or doesn't work with an 850io. Surely other people have attempted this minimal setup.

I would love for someone -- anyone -- to install the v1.12 firmware and confirm whether a PyB1.1/WIZ850io works. That's my request, if anyone has time to attempt it and report their results.

Thanks.

[Roberthh]

Not sure. But you could try the firmware image I have built, which works with my set-up:
https://github.com/robert-hh/Shared-Stu ... ZNET5K.dfu

[kwiley]

Thank you! I will do that

[kwiley]

Your firmware is definitely behaving differently (and more hopefully) than the 1.12 build on the website. The mysterious isactive() function is finally accessible, isconnected() reports True for the first time, and ifconfig() reports meaningful values even without manually configuring those values. None of that worked with the official firmware. I haven't tried a socket or any actual data transfer yet, but this all seems very inspiring so far.

So, bottom line, the official stable network firmware listed on the website -- at least the most recent version, 1.12, appears to be broken. I have no idea what the difference is. I will either have to rely on your binary image for the foreseeable future, avoiding the official release, or I will have to delve into building and debugging my own firmware images to get to solve the mystery.

For the time being, I think this will move my work forward considerably. Thank you for your help.

Nudge nudge: someone ought to look into fixing the PyB1.1 network firmware available for download on the website. Admittedly, it could be me, but I confess that I haven't bitten off the role of being a firmware developer and contributer for MicroPython yet. The OpenMV folks were hoping I could become a contributer to that project over a year ago too and I just didn't have time I'm afraid. Life gets in the way.

Cheers!