When the make process barfs with : /opt/pico-sdk/lib/cyw43-driver/src/cyw43_lwip.c: In function 'cyw43_cb_tcpip_init':
/opt/pico-sdk/lib/cyw43-driver/src/cyw43_lwip.c:209:5: warning: implicit declaration of function 'netif_set_hostname'; did you mean
'netif_set_down'? [-Wimplicit-function-declaration]
209 | netif_set_hostname(n, CYW43_HOST_NAME);
| ^~~~~~~~~~~~~~~~~~
| netif_set_down
/opt/pico-sdk/lib/cyw43-driver/src/cyw43_lwip.c: In function 'cyw43_cb_tcpip_deinit': /opt/pico-sdk/lib/cyw43-driver/src/cyw43_lwip.c:252:32: error:
'netif_list' undeclared (first use in this function); did you mean 'netif_find'?
252 | for (struct netif *netif = netif_list; netif != NULL; netif
= netif->next) {
| ^~~~~~~~~~
| netif_find /opt/pico-sdk/lib/cyw43-driver/src/cyw43_lwip.c:252:32: note: each
undeclared identifier is reported only once for each function it appears in /opt/pico-sdk/lib/cyw43-driver/src/cyw43_lwip.c:252:72: error: 'struct
netif' has no member named 'next'
252 | for (struct netif *netif = netif_list; netif != NULL; netif
= netif->next)
Blah blah blah.
Clearly its not finding a header file,(netif.h) but it's there and on
the path.
The Natural Philosopher <tnp@invalid.invalid> wrote:
When the make process barfs with :
/opt/pico-sdk/lib/cyw43-driver/src/cyw43_lwip.c: In function
'cyw43_cb_tcpip_init':
/opt/pico-sdk/lib/cyw43-driver/src/cyw43_lwip.c:209:5: warning: implicit
declaration of function 'netif_set_hostname'; did you mean
'netif_set_down'? [-Wimplicit-function-declaration]
209 | netif_set_hostname(n, CYW43_HOST_NAME);
| ^~~~~~~~~~~~~~~~~~
| netif_set_down
/opt/pico-sdk/lib/cyw43-driver/src/cyw43_lwip.c: In function
'cyw43_cb_tcpip_deinit':
/opt/pico-sdk/lib/cyw43-driver/src/cyw43_lwip.c:252:32: error:
'netif_list' undeclared (first use in this function); did you mean
'netif_find'?
252 | for (struct netif *netif = netif_list; netif != NULL; netif
= netif->next) {
| ^~~~~~~~~~
| netif_find
/opt/pico-sdk/lib/cyw43-driver/src/cyw43_lwip.c:252:32: note: each
undeclared identifier is reported only once for each function it appears in >> /opt/pico-sdk/lib/cyw43-driver/src/cyw43_lwip.c:252:72: error: 'struct
netif' has no member named 'next'
252 | for (struct netif *netif = netif_list; netif != NULL; netif
= netif->next)
Blah blah blah.
Clearly its not finding a header file,(netif.h) but it's there and on
the path.
It's failing building the Pico library (specifically LWIP), not your code.
So the #include in your code doesn't make any difference.
I decided to have a PICO day today. Well that's 8 hours of my life I
wont get back struggling with the appalling lack of documentation for
the PICO W and its toolkit, and for a piece of software that Poettering
would be proud of in terms of its utterly unnecessary complexity, bugs
and lack of documentation.
On 29/08/2023 17:40, The Natural Philosopher wrote:
I decided to have a PICO day today. Well that's 8 hours of my life I
wont get back struggling with the appalling lack of documentation for
the PICO W and its toolkit, and for a piece of software that Poettering
would be proud of in terms of its utterly unnecessary complexity, bugs
and lack of documentation.
You might like to try MicroPython instead.
I don't think you read my original post.
"Anyone who suggests Python will be treated with the contempt that they deserve." 😄
The problem with Python is that by and large it has bugs that no one can
fix.
On 30/08/2023 07:59, The Natural Philosopher wrote:
I don't think you read my original post.
"Anyone who suggests Python will be treated with the contempt that they
deserve." 😄
The problem with Python is that by and large it has bugs that no one can
fix.
Ah, no, I missed that. Too near the end of the post?
Ys, there are bugs, but I treat the Pico as a relatively new device with
new software, and not as a device I would expect to run 24x7 without
error. What I have found is that the Pico is sometimes supplied
pre-mounted on some other board, further reducing the reach of the
already small Wi-Fi antenna, and I read that 2xAA batteries may not be
enough to power the Wi-Fi hardware.
On the other hand, the RPi Zero (2) W is something which will run 24x7 reliably. Perhaps that might suit your project better?
BTW: even though I haven't used MicroPython before, I have found
development rapid and easy due to the large number of examples and the
easy of using the IDE - no need to make and upload uf2 files after every change.
On 30/08/2023 07:59, The Natural Philosopher wrote:
I don't think you read my original post.
"Anyone who suggests Python will be treated with the contempt that they
deserve." 😄
The problem with Python is that by and large it has bugs that no one can
fix.
Ah, no, I missed that. Too near the end of the post?
On 30/08/2023 08:44, David Taylor wrote:
On 30/08/2023 07:59, The Natural Philosopher wrote:
I don't think you read my original post.
"Anyone who suggests Python will be treated with the contempt that they
deserve." 😄
The problem with Python is that by and large it has bugs that no one can >>> fix.
Ah, no, I missed that. Too near the end of the post?
I missed it, too!
TNP, have you considered using Python?
It's the old old story, Online are a hundred articles citing the same examples, and a programmers mumblings that contain the truth that is
however unfortunately only comprehensible to other people 100% familiar
with the code. There is *nothing in between*. Just the odd hint here and there that you have to piece together to reveals the truth.
The Natural Philosopher <tnp@invalid.invalid> wrote:
It's the old old story, Online are a hundred articles citing the same
examples, and a programmers mumblings that contain the truth that is
however unfortunately only comprehensible to other people 100% familiar
with the code. There is *nothing in between*. Just the odd hint here and
there that you have to piece together to reveals the truth.
For the record, this is a pretty standard 'embedded' development experience. Every vendor has some degree of proprietary libraries and/or toolchain, and each vendor has a relatively small community of users. Some of whom have a hotline to the vendor's support staff which the rest of us don't.
So the platform is much less well tested than the standard Linux/glibc/gcc flow. Troubles like this aren't unusual in this environment.
Arduino on Atmega is probably the most beaten path in the embedded space - but less popular Arduino platforms suffer from similar creakiness.
Pico seems like it has devs who care about the user experience, rather than the typical vendor throwing things over the wall. But no doubt it will take time to mature (like first few years of the RPi 1), especially if you're using a less popular language.
Theo
On 30/08/2023 16:33, The Natural Philosopher wrote:
But a bit of second guessing now has a PICO W that starts up. connects
to wifi, with a unique hostname, reads a thoroughly useless temperature
from its chip, and sends its IP address, its hostname and location plus
temperature and a voltage to a remote server on the PI Zero W.
I added an external temperature sensor for that very reason!
For the messaging I used MQTT with a NodeRED server running an a
RasPi-3B. I would have preferred to use SNMP but couldn't find a satisfactory implementation for the Pico.
But a bit of second guessing now has a PICO W that starts up. connects
to wifi, with a unique hostname, reads a thoroughly useless temperature
from its chip, and sends its IP address, its hostname and location plus temperature and a voltage to a remote server on the PI Zero W.
..what is MOTT?
On 30/08/2023 18:43, The Natural Philosopher wrote:
I wrote an utterly trivial daemon to run under Xinetd on the PI zero W
that listens for the data, and just puts it in a file. Where the web
server and the background daemon can read it.
I am strictly old school. As few 3rd party tools as possible, because,
as I found with the SDK and cmake, you spend longer learning how to use
the darned things than writing a low level piece of code.
I still cannot believe that with the TCP/IP, the code is 650kB+
It's pushing towards the limit of the PICO.
Oh and by the way for other people considering using the pico
- the uf2 file vanishes once its booted,
- placing a uf2 file in the pseudo usb drive causes it to reboot
- but not always as cleanly as one would like. I have found strange
things in the serial buffer unless its rebooted cleanly with a
subsequent power down.
- the only way to configure the damn thing is to patch the uf2 file, it
seems. I haven't tried this yet. I hope they have not checksummed it.
Agreed on third-party tools and needing to learn and find bugs. I've
also had to work round the size limits on the Pico, and it would be nice
if the 2041 (or whatever) had greater limits.
BTW, I've not seen any issues with uf2 files when using MicroPython and Thonny. Loading the uf2 is typically a one-off operation when you first
get the Pico (or the firmware is updated), and any changes are simply
editing Python plain text files and copying to/from the Pico to your
host. Configuring can be just editing an include file which is read by
your program. The simplicity of this over using C/C++ appealed to me.
Mm. Thats ok for a hobbyists. It would be trivial to plug the PICO into
a USB port and generate a menu on the serial port. Execept do the
changes persist through a reboot?
I am still not clear where the code goes after the boot loader has
installed it.
No doubt I will find out, in time.
Every vendor has some degree of proprietary libraries and/or toolchain, and each vendor has a relatively small community of users. Some of whom have a hotline to the vendor's support staff which the rest of us don't.
So the platform is much less well tested than the standard Linux/glibc/gcc flow. Troubles like this aren't unusual in this environment.
Arduino on Atmega is probably the most beaten path in the embedded space - but less popular Arduino platforms suffer from similar creakiness.
Theo <theom+news@chiark.greenend.org.uk> wrote:
Every vendor has some degree of proprietary libraries and/or toolchain, and >> each vendor has a relatively small community of users. Some of whom have a >> hotline to the vendor's support staff which the rest of us don't.
So the platform is much less well tested than the standard Linux/glibc/gcc >> flow. Troubles like this aren't unusual in this environment.
Arduino on Atmega is probably the most beaten path in the embedded space - >> but less popular Arduino platforms suffer from similar creakiness.
I've had pretty good luck with VSCodium and PlatformIO. They manage to abstract away most of the unpleasantness involved in dealing with yet
another toolchain. With it, I've been able to wrangle different bits of
code targeting microcontrollers with AVR, ARM, and RISC-V cores. Some have been a little easier to set up than others (the programmer dongle for some
of the RISC-V dev boards I have needed its firmware updated with another
tool first), but once it's sorted, writing code for any of them isn't too much different.
| Sysop: | Coz |
|---|---|
| Location: | Anoka, MN |
| Users: | 2 |
| Nodes: | 4 (0 / 4) |
| Uptime: | 190:46:18 |
| Calls: | 184 |
| Calls today: | 1 |
| Files: | 5,413 |
| Messages: | 222,750 |