On 22/07/2023 10:08, David Taylor wrote:

On 22/07/2023 09:33, The Natural Philosopher wrote:

Ive been reading up a bit on the PICO W with a possible use for it as a
set of networked domestic temperature sensors.

All seems possible with the usual input of hard work and head
scratching, but in order to do this each PICO W would need to be
uniquely identified and configured to connect to the nearest wifi access
pint.

Now obviously this could be done in the source code itself, but really
I'd prefer to keep the source code constant and instead use the ability
of the flash RAM to appear as a USB storage device to drop a simple
configuration file into that, and read it from the pico, but it seems
this is not as easy as it sounds.

  From my limited research it appears that only the boot loader
understands the Flash file format.

Once booted you are on your own, so to speak.

There do seem to be some basic tools in Python, but I prefer to use C if
possible.

Anyone played with this at all?

For the actual task you might like to consider MQTT:

https://www.tomshardware.com/how-to/send-and-receive-data-raspberry-pi-pico-w-mqtt

Played with that and it does work.

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:

  https://learn.pimoroni.com/article/getting-started-with-badger-2040

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...

--
Those who want slavery should have the grace to name it by its proper
name. They must face the full meaning of that which they are advocating
or condoning; the full, exact, specific meaning of collectivism, of its
logical implications, of the principles upon which it is based, and of
the ultimate consequences to which these principles will lead. They must
face it, then decide whether this is what they want or not.

Ayn Rand.

--- SoupGate-Win32 v1.05
* Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)

On 22/07/2023 18:20, David Taylor wrote:

On 22/07/2023 10:47, The Natural Philosopher wrote:

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.

I dont want to use python

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.

--
“Puritanism: The haunting fear that someone, somewhere, may be happy.”

H.L. Mencken, A Mencken Chrestomathy

--- SoupGate-Win32 v1.05
* Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)

On 23/07/2023 05:27, David Taylor wrote:

On 22/07/2023 19:57, The Natural Philosopher wrote:

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.


--
Canada is all right really, though not for the whole weekend.

"Saki"

--- SoupGate-Win32 v1.05
* Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)

On 2023-07-22 10:33, The Natural Philosopher wrote:

All seems possible with the usual input of hard work and head
scratching, but in order to do this each PICO W would need to be
uniquely identified and configured to connect to the nearest wifi access pint.

Now obviously this could be done in the source code itself, but really
I'd prefer to keep the source code constant and instead use the ability
of the flash RAM to appear as a USB storage device to drop a simple configuration file into that, and read it from the pico, but it seems
this is not as easy as it sounds.

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"


<https://www.raspberrypi.com/documentation/pico-sdk/high_level.html#pico_unique_id>




--
/Björn

--- SoupGate-Win32 v1.05
* Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)

On 23/07/2023 08:51, The Natural Philosopher wrote:

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.

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!
--
Cheers,
David
Web: https://www.satsignal.eu

--- SoupGate-Win32 v1.05
* Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)

Dana Sat, 22 Jul 2023 09:33:47 +0100, The Natural Philosopher <tnp@invalid.invalid> napis'o:

Ive been reading up a bit on the PICO W with a possible use for it as a
set of networked domestic temperature sensors.

All seems possible with the usual input of hard work and head
scratching, but in order to do this each PICO W would need to be
uniquely identified and configured to connect to the nearest wifi access pint.

Now obviously this could be done in the source code itself, but really
I'd prefer to keep the source code constant and instead use the ability
of the flash RAM to appear as a USB storage device to drop a simple configuration file into that, and read it from the pico, but it seems
this is not as easy as it sounds.

From my limited research it appears that only the boot loader
understands the Flash file format.

Once booted you are on your own, so to speak.

There do seem to be some basic tools in Python, but I prefer to use C if possible.

Anyone played with this at all?

Have you looked at:
https://www.home-assistant.io/
https://esphome.io/index.html
https://esphome.io/components/rp2040.html

--- SoupGate-Win32 v1.05
* Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)

On 24/07/2023 02:21, Nikolaj Lazic wrote:

Dana Sat, 22 Jul 2023 09:33:47 +0100, The Natural Philosopher <tnp@invalid.invalid> napis'o:

Ive been reading up a bit on the PICO W with a possible use for it as a
set of networked domestic temperature sensors.

All seems possible with the usual input of hard work and head
scratching, but in order to do this each PICO W would need to be
uniquely identified and configured to connect to the nearest wifi access
pint.

Now obviously this could be done in the source code itself, but really
I'd prefer to keep the source code constant and instead use the ability
of the flash RAM to appear as a USB storage device to drop a simple
configuration file into that, and read it from the pico, but it seems
this is not as easy as it sounds.

From my limited research it appears that only the boot loader
understands the Flash file format.

Once booted you are on your own, so to speak.

There do seem to be some basic tools in Python, but I prefer to use C if
possible.

Anyone played with this at all?

Have you looked at:
https://www.home-assistant.io/

No. Nothing to do with what I want to do is it?

https://esphome.io/index.html

Inst using rapsberry PI and isnt coded by me

https://esphome.io/components/rp2040.html

Nothing to do with a Raspberry PI either.


--
"I guess a rattlesnake ain't risponsible fer bein' a rattlesnake, but ah
puts mah heel on um jess the same if'n I catches him around mah chillun".

--- SoupGate-Win32 v1.05
* Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)

On 2023-07-23, The Natural Philosopher <tnp@invalid.invalid> wrote:

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.

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:

https://arduino-pico.readthedocs.io/en/latest/fs.html

Even when not using the arduino libraries, setting up a flash filesystem
uses the same concepts. Your code can then store configuration information
in a file in the filesystem.

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
--
Some people have no respect of age unless it is bottled.

--- SoupGate-Win32 v1.05
* Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)

On 24/07/2023 19:13, Michael Schwingen wrote:

On 2023-07-23, The Natural Philosopher <tnp@invalid.invalid> wrote:

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.

How did you come to that conclusion?

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.

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

https://arduino-pico.readthedocs.io/en/latest/fs.html

Even when not using the arduino libraries, setting up a flash filesystem
uses the same concepts. Your code can then store configuration information
in a file in the filesystem.

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.

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.





--
All political activity makes complete sense once the proposition that
all government is basically a self-legalising protection racket, is
fully understood.

--- SoupGate-Win32 v1.05
* Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)

On 2023-07-25, The Natural Philosopher <tnp@invalid.invalid> wrote:

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.

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
--
Some people have no respect of age unless it is bottled.

--- SoupGate-Win32 v1.05
* Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)

On 26/07/2023 14:07, Michael Schwingen wrote:

On 2023-07-25, The Natural Philosopher <tnp@invalid.invalid> wrote:

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.

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

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.

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).

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...

cu
Michael

--
"Nature does not give up the winter because people dislike the cold."

― Confucius

--- SoupGate-Win32 v1.05
* Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)

Dana Mon, 24 Jul 2023 14:29:55 +0100, The Natural Philosopher <tnp@invalid.invalid> napis'o:

On 24/07/2023 02:21, Nikolaj Lazic wrote:

Dana Sat, 22 Jul 2023 09:33:47 +0100, The Natural Philosopher <tnp@invalid.invalid> napis'o:

Ive been reading up a bit on the PICO W with a possible use for it as a
set of networked domestic temperature sensors.

All seems possible with the usual input of hard work and head
scratching, but in order to do this each PICO W would need to be
uniquely identified and configured to connect to the nearest wifi access >>> pint.

Now obviously this could be done in the source code itself, but really
I'd prefer to keep the source code constant and instead use the ability
of the flash RAM to appear as a USB storage device to drop a simple
configuration file into that, and read it from the pico, but it seems
this is not as easy as it sounds.

From my limited research it appears that only the boot loader
understands the Flash file format.

Once booted you are on your own, so to speak.

There do seem to be some basic tools in Python, but I prefer to use C if >>> possible.

Anyone played with this at all?

Have you looked at:
https://www.home-assistant.io/

No. Nothing to do with what I want to do is it?

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.

https://esphome.io/index.html

Inst using rapsberry PI and isnt coded by me

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

https://esphome.io/components/rp2040.html

Nothing to do with a Raspberry PI either.

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?

--- SoupGate-Win32 v1.05
* Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)

On 28/07/2023 14:01, Nikolaj Lazic wrote:

Dana Mon, 24 Jul 2023 14:29:55 +0100, The Natural Philosopher <tnp@invalid.invalid> napis'o:

On 24/07/2023 02:21, Nikolaj Lazic wrote:

Dana Sat, 22 Jul 2023 09:33:47 +0100, The Natural Philosopher <tnp@invalid.invalid> napis'o:

Ive been reading up a bit on the PICO W with a possible use for it as a >>>> set of networked domestic temperature sensors.

All seems possible with the usual input of hard work and head
scratching, but in order to do this each PICO W would need to be
uniquely identified and configured to connect to the nearest wifi access >>>> pint.

Now obviously this could be done in the source code itself, but really >>>> I'd prefer to keep the source code constant and instead use the ability >>>> of the flash RAM to appear as a USB storage device to drop a simple
configuration file into that, and read it from the pico, but it seems
this is not as easy as it sounds.

From my limited research it appears that only the boot loader
understands the Flash file format.

Once booted you are on your own, so to speak.

There do seem to be some basic tools in Python, but I prefer to use C if >>>> possible.

Anyone played with this at all?

Have you looked at:
https://www.home-assistant.io/

No. Nothing to do with what I want to do is it?

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.

https://esphome.io/index.html

Inst using rapsberry PI and isnt coded by me

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

https://esphome.io/components/rp2040.html

Nothing to do with a Raspberry PI either.

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


--
“Progress is precisely that which rules and regulations did not foresee,”

– Ludwig von Mises

--- SoupGate-Win32 v1.05
* Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)