Using Pi PICO W flash

For the actual task you might like to consider MQTT:

I do recall reading something recently about auto-configuration, but I don't recall where. Don't worry about Python - it's easy and there are lots of examples out there.

Something like Thonny would enable you to add the appropriate configuration file to the Pico - it works over USB so Wi-Fi isn't needed at that stage. For example, look here for WIFI_CONFIG.py:

Thanks for all that. I will look into it.

I have been thinking more, and have decided that it really doesn't matter if the pico C libraries can understand file systems or not, as it would be entirely possible to scan the *whole* flash memory for strings like $SSID="MYWIFI" and $PASSWORD="rats.vomit" and $LOCATION="Kitchen" etc etc

My ignorance here derives from a comment I found online that 'invoking BOOTSEL by powering the Pico on with the button pressed erases files from the Pico's flash'.

And yet there is another piece of info describing how you need to run a program on the pico to erase it's flash!

I think I will risk the very few pence a Pico costs, plug it in, and see...

Yes, but basic solution with Wi-Fi could easily be extended. Use Thonny to write a file with the details you need, and get the Python app to read those details. Works well for Wi-Fi.

You don't need to either read, or erase, the whole flash. Get the basic Python loaded (likely it will already be there) and use Thonny to look at the Pico W contents. Thonny works on Windows, Linux, and the Mac.

I dont want to use python

I didn't /want/ to use Python, but it's fast enough for the job, it's already provided on the Pico, it's easy to use, there are plenty of examples, and it's well supported.

For me, by far the easiest and quickest solution.

For you it may at least provide an source of ideas about customising a setup without the need to read the whole flash memory.

The problem - as I now understand it - is that the only easy use of the flash memory is to store the program code. At least all my research so far shows that its a total bitch to access from the code stored in it. With lots of gotchas.

My tentative conclusion, since the PICO Ws will be clients to a Pi Zero W server, is to store the binary (UF2) files on the Pi Zero W, and have a web interface to a web server on the Zero W to take user supplied values and *patch* the binary for downloading on to a USB attached PICO W.

So each PICO W will run *unique* code in terms of hostname, SSID, WIFI password, possibly static IP address, and so on.

There is an another advantage to this, to, in that at the time of creating the patched UF2, each side will 'know' the others IP address, and so the clients could be preconfigured to know the server's address, as well. And vice versa, if needed.

This makes the client code extremely simple indeed...connect to wifi, read a sensor or three, connect to server and transmit data over, and sleep for a minute or two. Rinse and repeat. Possibly, if battery voltage sensor shows 'low', flash the onboard LED...

This is, at least, the first solution where I can see a way through to do *everything* needful, fairly simply.

If you are in control of where the picos are deployed, You could get the unique id of the pico, and look up the config for that device. Rhymes bad with 'keeping source code constant'. However if you put it in a separate c/h file, it's not that far from a config file.

A colleague once said that "source code is also configuration, just process it with a compiler first"

I note your proposed solution.

Using Python, the flash contains a program named main.py which will run automatically when the Pico starts. You can add (using Thonny) a file such as config.py which the program can read, so that's two files on the flash. It looks like a standard file system, and there can even be sub-directories. So one program, and a custom config file for each Pico.

Good luck!

Dana Sat, 22 Jul 2023 09:33:47 +0100, The Natural Philosopher snipped-for-privacy@invalid.invalid napis'o:

Have you looked at:

How did you come to that conclusion?

I should be possible to have a flash filesystem (littlefs or similar) after the flash area used by cour code:

Providing that configuration information is a separate topic: a menu or CLI on a serial port can easily be implemented in your code.

I tend to use a mixed approach (on ESP32, which is my go-to solution if I need WiFi): the default WiFi parameters that allow initial connection to my network are compiled into the firmware. The device then requests an IP address via DHCP and starts a web server that allows configuration of all relevant parameters (including WiFi SSID, password, static IP if needed plus parameters for the specific task, like MQTT server and credentials).

You could also use the unique ID of the board to request configuration data from a server - that way, no board-specific configuration storage is necessary.

cu Michael

By doing internet research, The flash is accessible after its been booted for read and write, but it seems that no file placed in it prior to booting that isn't a .utf or whatever doesn't survive. This is something I will try when the pico arrives.

But actually I will still go the 'get the code from server to burn into the board' approach because that way the server knows the board data and vice versa and it's still a file to be download onto the PICO before booting.

Unfortunately the chief configuration required is the SSID & password of the wifi, and the address of the server, all of which are needed before you can ask the server for configuration data.

Once its done that the rest is as trivial as you indicate.

Which should all be constant across all boards in your network, so no problem to compile into the code.

If you don't want to do that, you can do the initial setup that configures these variables by hand (eg. via a serial port and terminal program on a PC) on each board. The saved configuration on the device *should* survive a firmware upgrade (it does on ESP32, and a quick google search indicates that the RP2040 upload via BOOTSEL does *not* completely erase the flash - you need to upload a special binary do do a full erase).

cu Michael

I just cannot get out of the habit of designing things for production. So arbitrary networks and dumb users is the order of the day.

That is more complicated for the user than the way I am adopting They don't know what a serial port is, but they are familiar with usb sticks and transferring files into them and downloading files via a web browser etc...

And you've figured this out... which way? This is the whole system. You want to do just a part of it. So, use just a part of it.

It uses one server that holds all the configurations for your sensors and compiles the firmware for each of the systems you need.

This is a subsystem. And it is not coded by you.

This is also a subsystem for home assistant. Everything is done throught the same way. Configuration -> compile -> upload -> flash -> report back to the server.

Am I missing something or are you trying to redo the same thing?

I am building something for my own interest, for my own application. That's why I run l,inux and play with raspberry Pis.

Otherwise I would be hanging out in farcebook on an apple fondleslab