Qstr strangeness in network_wlan

C programming, build, interpreter/VM.
Target audience: MicroPython Developers.
Post Reply
envirocoder
Posts: 4
Joined: Tue Nov 30, 2021 5:49 pm

Qstr strangeness in network_wlan

Post by envirocoder » Tue Nov 30, 2021 6:37 pm

This feels like it should be something simple but I'm baffled, so hoping someone can help please

I've modified network_wlan.c to get the number of clients connected in AP mode.
I've added the following code into network_wlan_config function here:
https://github.com/micropython/micropyt ... lan.c#L537

Code: Select all

 case QS(MP_QSTR_connected_clients):
            req_if = WIFI_IF_AP;
            val = MP_OBJ_NEW_SMALL_INT(ap_connected_client_count);
 
If I use in in the REPL all works well.

Code: Select all

>>> import network
>>> ap = network.WLAN(network.AP_IF)
>>> ap.config('connected_clients')
0
However if I run the same code on boot in _boot.py, I get ValueError: unknown config param i.e. the case statement doesn't match the connected_clients string passed in.

To try and debug things, I also added a line that prints the value of the qsrt passed in:

Code: Select all

ESP_LOGI("wifi", "got param %d", (uintptr_t)args[1]);
When I call it from the REPL I get:

Code: Select all

I (16557) wifi: got param 2074
but from _boot.py

Code: Select all

I (947) wifi: got param 1061406248
For comparison I tried
ap.config('mac')
and this works both in the REPL and from _boot.py. In both cases I log:

Code: Select all

I (307417) wifi: got param 6738
So, it looks like `connected_clients` in _boot.py isn't being interned properly? Any thoughts gratefully received!

[edit -- additional]
Just compiled latest esp32 from micropython github repo and added the following under _boot.py

Code: Select all

import network
ap = network.WLAN(network.AP_IF)
print(ap.config('mac'))
print(ap.config('dhcp_hostname'))
result is:

Code: Select all

b'\xd8\xa0\x1deh\x1d'
Traceback (most recent call last):
  File "_boot.py", line 18, in <module>
ValueError: unknown config param
MicroPython v1.17-217-gde7e3cd79-dirty on 2021-11-30; ESP32 module with ESP32
Type "help()" for more information.
So `mac` works but not `dhcp_hostname`!

User avatar
karfas
Posts: 193
Joined: Sat Jan 16, 2021 12:53 pm
Location: Vienna, Austria

Re: Qstr strangeness in network_wlan

Post by karfas » Tue Nov 30, 2021 10:56 pm

Maybe your strings are too long ?
In https://docs.micropython.org/en/latest/ ... /qstr.html I find:
Also, when compiling Python code, identifiers and literals need to have QSTRs created. Note: only literals shorter than 10 characters become QSTRs.
In my opinion, already-existing QSTRs (from the precompiled table) should be used anyway, regardless of their length. Perhaps a Bug ?
A few hours of debugging might save you from minutes of reading the documentation! :D
My repositories: https://github.com/karfas

envirocoder
Posts: 4
Joined: Tue Nov 30, 2021 5:49 pm

Re: Qstr strangeness in network_wlan

Post by envirocoder » Wed Dec 01, 2021 10:40 am

karfas wrote:
Tue Nov 30, 2021 10:56 pm
Maybe your strings are too long ?
Yes, works fine with short strings.
karfas wrote:
Tue Nov 30, 2021 10:56 pm
In my opinion, already-existing QSTRs (from the precompiled table) should be used anyway, regardless of their length. Perhaps a Bug ?
Yes, definitely a bug on some level -- I assumed the same. If this isn't the case, then the long strings in network_wlan need to be shortened or used differently. Or this is how it's supposed to work, then it's a bug with freezing/qstrs. I've lost track in the later CMAKE toolchain builds, how the freezing process works, whether it's the cross-compiler, mpy-tool or something else that's responsible for matching up the source and the qstrs.

I've filled an issue: https://github.com/micropython/micropython/issues/8052

Post Reply