Lan.status() show the state of the previous connection

marcoind · May 31, 2021, 7:30am

Hi,
I’m using a portenta with a vison shield with ethernet module.
I’m a bit confuse with the lan.status()
It suppose to show the status of the lan interface:

0: Link Down
1: Link Join
2: Link No-IP
3: Link Up
It’s actually show the status of the previous lan connection.
If i connect the lan cable and connect to the network it show 0 but i got an ip adress from my dhcp.
then If i disconnect the lan cable it show 3 but i have a timeout error (which is expected.)
There is no deinit() function like the wlan.
My goal is to check if there is a cable connected to the ethernet module and if not to fall back on the wifi connection.
I could wait for the timeout with try: error: but i would prefer to check the status of the lan and act accordingly.
Am i doing something wrong ?

kwagyeman · May 31, 2021, 2:46pm

No, it’s just new code that’s not well debugged.

@iabdalkader

iabdalkader · May 31, 2021, 6:42pm

I definitely don’t see this issue, with the cable connected I get 2 before DHCP, and then 3 after an IP as expected, I tried it a few times. If the link status is stuck from last connection you could try active(False) before active(True)…The only issue I see is there’s no way to check for link status before actuve(True) which times out if there’s no link, you’re just going to have to handle the exception.

marcoind · June 1, 2021, 1:16am

Hi,
Thanks for your reply.
So i can’t use lan.status() prior the lan.active(True)
Which is useless to detect the presence of the cable.
I can deal with the exception but i will have to wait for the timeout of the lan.active() to fall back to the wifi which increase considerably the network connection time.
Why do we need to have a cable connected to activate the lan? It doesn’t make sense in network point of view. I can have an activated network interface without cable and connect the cable only when needed ( at least in C++).
do you think the micropython firmware will have future improvement regarding this issue ?

iabdalkader · June 1, 2021, 6:49pm

I don’t know and yes I agree it doesn’t make sense, but again you’re asking in the wrong place these are standard Micropython drivers (for WLAN and LAN) we use them as they are without any changes. You should ask them about it on their forums or github:

https://forum.micropython.org/

If something gets fixed it will be automatically fixed in our firmware when we update Micropython.

marcoind · June 2, 2021, 4:07am

Hi,
Sorry but I’m discovering micro python through openmv, not by choice but by customer requirement. i’m a C++ developer and try to do my best with the very steep learning curve of openmv and micropython. Lot of ref in micropython doc say “depend on which port your are working with” some function available in mycropython are not available in openmv. how can i guess ?

kwagyeman · June 2, 2021, 4:33am

Hi, if you can compile the C code then you can just change this behavior. The firmware guide is here:

Once you have the ability to compile the PORTENA firmware with “make TARGET=PORTENTA” then you can just edit the file in question:

github.com

openmv/micropython/blob/e439f36bc8551c38086ecac8bc2d052e8a30d813/ports/stm32/eth.c#L774


      
                          pbuf_free(p);
                      }
                  }
              }
          }
          
          
struct netif *eth_netif(eth_t *self) {
              return &self->netif;
          }
          
          
int eth_link_status(eth_t *self) {
              struct netif *netif = &self->netif;
              if ((netif->flags & (NETIF_FLAG_UP | NETIF_FLAG_LINK_UP))
                  == (NETIF_FLAG_UP | NETIF_FLAG_LINK_UP)) {
                  if (netif->ip_addr.addr != 0) {
                      return 3; // link up
                  } else {
                      return 2; // link no-ip;
                  }
              } else {
                  int s = eth_phy_read(0) | eth_phy_read(0x10) << 16;

Which is called from:

github.com

openmv/micropython/blob/e439f36bc8551c38086ecac8bc2d052e8a30d813/ports/stm32/network_lan.c#L63


      
                  );
          }
          
          
STATIC mp_obj_t network_lan_make_new(const mp_obj_type_t *type, size_t n_args, size_t n_kw, const mp_obj_t *args) {
              mp_arg_check_num(n_args, n_kw, 0, 0, false);
              const network_lan_obj_t *self = &network_lan_eth0;
              eth_init(self->eth, MP_HAL_MAC_ETH0);
              return MP_OBJ_FROM_PTR(self);
          }
          
          
STATIC mp_obj_t network_lan_active(size_t n_args, const mp_obj_t *args) {
              network_lan_obj_t *self = MP_OBJ_TO_PTR(args[0]);
              if (n_args == 1) {
                  return mp_obj_new_bool(eth_link_status(self->eth));
              } else {
                  int ret;
                  if (mp_obj_is_true(args[1])) {
                      ret = eth_start(self->eth);
                  } else {
                      ret = eth_stop(self->eth);
                  }

kwagyeman · June 2, 2021, 4:34am

Apologizes for the steep learning curve. We didn’t design that to be the case. It’s more of that the product is just missing features people want since it’s new.

marcoind · June 2, 2021, 4:46am

Hi, thanks for your reply.
i’m dealing with portenta and multiple OpnMVh7 camera for this project and don’t want to tailor firmware for the 2 different hardware because of time development constrain that’s why i prefer to ask to the community and then turn around the problem by using the state of the art of your firmware which i understand (no problem with that) is in constant evolution.
The steep learning curve is because of my lack of skills in pyhton and micropython more than your product

kwagyeman · June 2, 2021, 5:00am

I see. Well, if you look at the code being called it’s pretty straight forwards in behavior. I can’t see any clear error with it.

kwagyeman · June 2, 2021, 5:01am

I guess the netip struct is not getting zeroed on lab disconnect. I don’t know though it’d that’s a feature of the Ethernet PHY to detect that and interrupt the main CPU.

iabdalkader · June 2, 2021, 10:42am

We enable all the features available in the stm32 port (which is the port you’re using) and we add extra built-in drivers, libraries and modules plus all the OpenMV specific modules (image library, drivers, tensorflow, image sensors etc…). The Micropython documentation (on which we base our own docs) does Not specify which functions or arguments are available for which ports, or how they differ between ports, but if something is not available in the stm32 port you’ll get an exception when calling it.

iabdalkader · June 2, 2021, 1:06pm

This doesn’t look right, the link status register is 1, registers 0 and 16 are not relevant… I’m not sure if there’s a reason it’s done like that, but could be a bug will report it upstream. However, you still need to activate the lan to read any registers.

iabdalkader · June 6, 2021, 7:57pm

@marcoind I’ll be able to fix this issue for you in the next release.

marcoind · June 7, 2021, 7:37am

Thanks so much.
I’ll try it as soon it’s available.