• Re: Using Pi PICO W flash

    From The Natural Philosopher@3:770/3 to David Taylor on Sat Jul 22 10:47:10 2023
    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)
  • From The Natural Philosopher@3:770/3 to David Taylor on Sat Jul 22 19:57:18 2023
    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)
  • From The Natural Philosopher@3:770/3 to David Taylor on Sun Jul 23 08:51:06 2023
    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)
  • From =?UTF-8?Q?Bj=c3=b6rn_Lundin?=@3:770/3 to The Natural Philosopher on Sun Jul 23 10:48:46 2023
    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)
  • From David Taylor@3:770/3 to The Natural Philosopher on Sun Jul 23 10:48:24 2023
    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)
  • From Nikolaj Lazic@3:770/3 to All on Mon Jul 24 01:21:10 2023
    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)
  • From The Natural Philosopher@3:770/3 to Nikolaj Lazic on Mon Jul 24 14:29:54 2023
    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)
  • From Michael Schwingen@3:770/3 to The Natural Philosopher on Mon Jul 24 18:13:16 2023
    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)
  • From The Natural Philosopher@3:770/3 to Michael Schwingen on Tue Jul 25 08:31:04 2023
    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)
  • From Michael Schwingen@3:770/3 to The Natural Philosopher on Wed Jul 26 13:07:06 2023
    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)
  • From The Natural Philosopher@3:770/3 to Michael Schwingen on Wed Jul 26 17:18:24 2023
    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)
  • From Nikolaj Lazic@3:770/3 to All on Fri Jul 28 13:01:38 2023
    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)
  • From The Natural Philosopher@3:770/3 to Nikolaj Lazic on Sat Jul 29 06:07:56 2023
    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)