• Re: Pico - issue with interrupts and sleep??

    From David Taylor@3:770/3 to Mike Scott on Wed Aug 2 18:55:20 2023
    On 02/08/2023 17:14, Mike Scott wrote:
    Hi all. I've been pottering trying to get to understand use of a Pico. I
    hope this is on-topic for the group.

    Yes, I think it's on-topic, and I very much look forward to the answers!

    I have been playing with Pico Badger and one which uses Wi-Fi will hang (sleeps for 30 minutes, but USB powered), and the other with no Wi-Fi just hangs - sometimes using a 60 second timer). I'm hoping to make both of these battery operated, although with the non-Wifi one which has a CO2 sensor that may not be possible. I'm using MicroPython.
    --
    Cheers,
    David
    Web: https://www.satsignal.eu

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Dennis Lee Bieber@3:770/3 to All on Wed Aug 2 16:21:12 2023
    On Wed, 2 Aug 2023 17:14:47 +0100, Mike Scott <usenet.16@scottsonline.org.uk.invalid> declaimed the following:



    Changing the one line to
    time.sleep_us(100*1000)
    runs, but the lines come out in groups of 10 every second


    Any thoughts please?

    Add a call to .flush() for the I/O stream after every write?

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Pancho@3:770/3 to Mike Scott on Thu Aug 3 12:01:56 2023
    On 02/08/2023 17:14, Mike Scott wrote:
    Hi all. I've been pottering trying to get to understand use of a Pico. I
    hope this is on-topic for the group.

    It looks as though timer interrupts and the sleep functions don't mix
    too well. I've programmed an elementary clock using the tm1637 module
    and using a 1 second timer interrupt to update the display. Noddy stuff, except it runs for a while and then hangs completely.

    If I rejig the code to not be interrupt driven, it seems to run OK.

    The tm1637 module makes extensive use of time.sleep_us(), and rather
    sparse comments on the web suggest that this method and the interrupt
    don't play well together.

    Can anyone confirm there's an issue and whether there's any resolution
    of it?


    Also, there seems to be something odd in that for example
    time.sleep_ms(1000) works, while time.sleep_us(1000000) does wrong
    things and hangs.

    so while

    import time
    count = 0

    while(True):
        print(count)
        time.sleep_ms(1000)
        count = 1+count

    behaves as expected, the following:

    import time
    count = 0

    while(True):
        print(count)
        time.sleep_us(1000*1000)
        count = 1+count

    prints just a 0, and then needs power disconnection to recover.

    Changing the one line to
        time.sleep_us(100*1000)
    runs, but the lines come out in groups of 10 every second


    Any thoughts please?



    Use time.sleep(1) instead of time.sleep_us(). I really can't see any
    reason for sleep_us() to exist? In my python, it doesn't exist. Perhaps sleep_us() expects a high precision clock, which doesn't exist.

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Mike Scott@3:770/3 to Pancho on Thu Aug 3 17:04:42 2023
    On 03/08/2023 12:01, Pancho wrote:
    ....

    Use time.sleep(1) instead of time.sleep_us(). I really can't see any
    reason for sleep_us() to exist? In my python, it doesn't exist. Perhaps sleep_us() expects a high precision clock, which doesn't exist.

    Thanks for the comment.

    I reran the original offending program today. It ran for around 9 hours
    before locking up.

    It's just a simple clock program using a tm1637, really to let me have a
    potter with some simple things. A 1 second timer interrupt updates a
    counter and the display; the main program just sleep's in a loop.

    The tm1637 module uses sleep_us internally to clock data into the tm1637
    chip, so I'm a bit stuck with that. It looks very much as though the
    sleep_us calls eventually disable the timer interrupt system somehow: in
    one incarnation of the code, the interrupts updated the clock, while a
    main loop flashed the on-board led. Clock updates stopped yet the led
    kept flashing, so the pico wasn't completely stopped.

    I can't, surely, be the only one to have tried this combination?


    --
    Mike Scott
    Harlow, England

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Theo@3:770/3 to The Natural Philosopher on Fri Aug 4 15:01:12 2023
    The Natural Philosopher <tnp@invalid.invalid> wrote:
    Well, bare metal programming is what it is. Now if someone wrote a
    software emulator for a PICO we could debug the thing...

    https://github.com/wokwi/rp2040js

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Pancho@3:770/3 to Mike Scott on Fri Aug 4 15:29:22 2023
    On 03/08/2023 17:04, Mike Scott wrote:
    On 03/08/2023 12:01, Pancho wrote:
    ....

    Use time.sleep(1) instead of time.sleep_us(). I really can't see any
    reason for sleep_us() to exist? In my python, it doesn't exist.
    Perhaps sleep_us() expects a high precision clock, which doesn't exist.

    Thanks for the comment.


    I don't know anything, so I wouldn't thank me that much :-).

    I reran the original offending program today. It ran for around 9 hours before locking up.

    It's just a simple clock program using a tm1637, really to let me have a potter with some simple things. A 1 second timer interrupt updates a
    counter and the display; the main program just sleep's in a loop.

    The tm1637 module uses sleep_us internally to clock data into the tm1637 chip, so I'm a bit stuck with that. It looks very much as though the
    sleep_us calls eventually disable the timer interrupt system somehow: in
    one incarnation of the code, the interrupts updated the clock, while a
    main loop flashed the on-board led. Clock updates stopped yet the led
    kept flashing, so the pico wasn't completely stopped.

    I can't, surely, be the only one to have tried this combination?


    From a quick Google, I picked up a couple of things. sleep() may block
    (soft) interrupts. Using sleep(), sleep_us() is discouraged.

    The preferred method being using a callback and timer. <https://docs.micropython.org/en/latest/esp32/quickref.html#timers>

    That kind of sounds less blocking, your timer lambda callback goes onto
    a queue and politely waits its turn.

    But as I said, I know nothing :-).

    In general, I want to like Python, I'm curious, but whenever I look at
    it, it makes me angry.

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Pancho@3:770/3 to Theo on Fri Aug 4 15:30:16 2023
    On 04/08/2023 15:01, Theo wrote:
    The Natural Philosopher <tnp@invalid.invalid> wrote:
    Well, bare metal programming is what it is. Now if someone wrote a
    software emulator for a PICO we could debug the thing...

    https://github.com/wokwi/rp2040js

    What are the chances an emulator would model a race condition accurately?

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Theo@3:770/3 to Pancho on Fri Aug 4 17:11:28 2023
    Pancho <Pancho.Jones@proton.me> wrote:
    On 04/08/2023 15:01, Theo wrote:
    The Natural Philosopher <tnp@invalid.invalid> wrote:
    Well, bare metal programming is what it is. Now if someone wrote a
    software emulator for a PICO we could debug the thing...

    https://github.com/wokwi/rp2040js

    What are the chances an emulator would model a race condition accurately?

    Depends if it's cycle accurate or not. The above does keep track of cycles, but I don't know whether it matches the hardware.

    Theo

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Ahem A Rivet's Shot@3:770/3 to Pancho on Fri Aug 4 19:16:30 2023
    On Fri, 4 Aug 2023 15:30:16 +0100
    Pancho <Pancho.Jones@proton.me> wrote:

    What are the chances an emulator would model a race condition accurately?

    Minimal I would think. Way back using a bit-slice based Z80 in
    circuit emulators we had no end of issues caused by timing variances
    between the real chip and the emulation.

    --
    Steve O'Hara-Smith
    Odds and Ends at http://www.sohara.org/
    Host: Beautiful Theory meet Inconvenient Fact
    Obit: Beautiful Theory died today of factual inconsistency

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From The Natural Philosopher@3:770/3 to Pancho on Sat Aug 5 08:50:40 2023
    On 04/08/2023 15:29, Pancho wrote:
    On 03/08/2023 17:04, Mike Scott wrote:
    On 03/08/2023 12:01, Pancho wrote:
    ....

    Use time.sleep(1) instead of time.sleep_us(). I really can't see any
    reason for sleep_us() to exist? In my python, it doesn't exist.
    Perhaps sleep_us() expects a high precision clock, which doesn't exist.

    Thanks for the comment.


    I don't know anything, so I wouldn't thank me that much :-).

    I reran the original offending program today. It ran for around 9
    hours before locking up.

    It's just a simple clock program using a tm1637, really to let me have
    a potter with some simple things. A 1 second timer interrupt updates a
    counter and the display; the main program just sleep's in a loop.

    The tm1637 module uses sleep_us internally to clock data into the
    tm1637 chip, so I'm a bit stuck with that. It looks very much as
    though the sleep_us calls eventually disable the timer interrupt
    system somehow: in one incarnation of the code, the interrupts updated
    the clock, while a main loop flashed the on-board led. Clock updates
    stopped yet the led kept flashing, so the pico wasn't completely stopped.

    I can't, surely, be the only one to have tried this combination?


    From a quick Google, I picked up a couple of things. sleep() may block (soft) interrupts. Using sleep(), sleep_us() is discouraged.

    The preferred method being using a callback and timer. <https://docs.micropython.org/en/latest/esp32/quickref.html#timers>

    That kind of sounds less blocking, your timer lambda callback goes onto
    a queue and politely waits its turn.

    But as I said, I know nothing :-).

    In general, I want to like Python, I'm curious, but whenever I look at
    it, it makes me angry.

    its BASIC made to look like C
    I cant be arsed to learn any more languages than I have to.

    I am still being dragged kicking and screaming into the dark and fœtid
    bowels of javaScript.

    A loathsome melange obviously written by Computer Scientists who were
    told that Object Orientation Was The Coming Thing, but finally realised
    it wasnt.

    --
    Climate is what you expect but weather is what you get.
    Mark Twain

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From The Natural Philosopher@3:770/3 to Pancho on Sat Aug 5 08:51:24 2023
    On 04/08/2023 15:30, Pancho wrote:
    On 04/08/2023 15:01, Theo wrote:
    The Natural Philosopher <tnp@invalid.invalid> wrote:
    Well, bare metal programming is what it is. Now if someone wrote a
    software emulator for a PICO we could debug the thing...

    https://github.com/wokwi/rp2040js

    What are the chances an emulator would model a race condition accurately?

    As good as the person who wrote it chose to make it.
    --
    For in reason, all government without the consent of the governed is the
    very definition of slavery.

    Jonathan Swift

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From The Natural Philosopher@3:770/3 to Ahem A Rivet's Shot on Sat Aug 5 08:53:00 2023
    On 04/08/2023 19:16, Ahem A Rivet's Shot wrote:
    On Fri, 4 Aug 2023 15:30:16 +0100
    Pancho <Pancho.Jones@proton.me> wrote:

    What are the chances an emulator would model a race condition accurately?

    Minimal I would think. Way back using a bit-slice based Z80 in
    circuit emulators we had no end of issues caused by timing variances
    between the real chip and the emulation.

    Odd. My 8086 Ices were actually pinpoint accurate.


    --
    For in reason, all government without the consent of the governed is the
    very definition of slavery.

    Jonathan Swift

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Ahem A Rivet's Shot@3:770/3 to The Natural Philosopher on Sat Aug 5 09:29:16 2023
    On Sat, 5 Aug 2023 08:53:01 +0100
    The Natural Philosopher <tnp@invalid.invalid> wrote:

    On 04/08/2023 19:16, Ahem A Rivet's Shot wrote:
    On Fri, 4 Aug 2023 15:30:16 +0100
    Pancho <Pancho.Jones@proton.me> wrote:

    What are the chances an emulator would model a race condition
    accurately?

    Minimal I would think. Way back using a bit-slice based Z80 in
    circuit emulators we had no end of issues caused by timing variances between the real chip and the emulation.

    Odd. My 8086 Ices were actually pinpoint accurate.

    There were two kinds of ICE.

    One used a bit slice emulation of the processor to directly drive
    the pins. The other used a real processor and monitored the pins with a bit slice emulation to track the internal registers. The latter worked!

    --
    Steve O'Hara-Smith
    Odds and Ends at http://www.sohara.org/
    Host: Beautiful Theory meet Inconvenient Fact
    Obit: Beautiful Theory died today of factual inconsistency

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Martin Gregorie@3:770/3 to The Natural Philosopher on Sat Aug 5 12:14:38 2023
    On Sat, 5 Aug 2023 08:50:40 +0100, The Natural Philosopher wrote:

    I am still being dragged kicking and screaming into the dark and fœtid bowels of javaScript.

    A loathsome melange obviously written by Computer Scientists who were
    told that Object Orientation Was The Coming Thing, but finally realised
    it wasnt.

    I quite agree: I see no use whatsoever for Javascript. So far I haven't
    found anything it can do that can't be done better and faster with awk
    and/or Perl.

    --

    Martin | martin at
    Gregorie | gregorie dot org

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Ahem A Rivet's Shot@3:770/3 to The Natural Philosopher on Sat Aug 5 14:30:38 2023
    On Sat, 5 Aug 2023 08:50:40 +0100
    The Natural Philosopher <tnp@invalid.invalid> wrote:

    I am still being dragged kicking and screaming into the dark and fœtid bowels of javaScript.

    A loathsome melange obviously written by Computer Scientists who were

    In fact it was written at Netscape by people who wanted a client
    side language like Java. Of course since then Java has gone off into the "Enterprise" world and grown all sorts of "design pattern" based cruft
    designed to make it possible for complete incompetents to produce code that works to spec - provided the spec isn't too complex.

    told that Object Orientation Was The Coming Thing, but finally realised
    it wasnt.

    JavaScript is more of a Functional style language than it is OO. It
    is also hideous - but that might be my bias against Functional languages.

    Object oriented design has been an enormously successful paradigm
    for modelling complex structures in software and is extensively used
    throughout the software industry. Almost everything I have written in the
    last few decades has been OO - the rest has been short scripts.

    As for Python being BASIC made to look like C - if you think that
    you have completely missed the point of the language. Python has replaced
    Perl as a language of choice for everything from sysadmin scripting to
    complex IO bound applications for a very good reason - it is *extremely* efficient! Not in CPU cycles of course (why bother being efficient in
    CPU cycles when the slowest, cheapest embedded computer outperforms a
    1980s supercomputer) but in that most expensive commodity - programmer time both in writing and in maintenance.

    Well written Python is extremely clear and intentional with a
    minimum of boilerplate and syntactic cruft obscuring the intent of the programmer.

    Using Python and OO has enabled me to create frameworks that
    replace great swathes of repetitive code full of boilerplate cruft by
    simple declarative modules with no code in them at all.

    --
    Steve O'Hara-Smith
    Odds and Ends at http://www.sohara.org/
    Host: Beautiful Theory meet Inconvenient Fact
    Obit: Beautiful Theory died today of factual inconsistency

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From The Natural Philosopher@3:770/3 to Ahem A Rivet's Shot on Sat Aug 5 17:48:04 2023
    On 05/08/2023 09:29, Ahem A Rivet's Shot wrote:
    On Sat, 5 Aug 2023 08:53:01 +0100
    The Natural Philosopher <tnp@invalid.invalid> wrote:

    On 04/08/2023 19:16, Ahem A Rivet's Shot wrote:
    On Fri, 4 Aug 2023 15:30:16 +0100
    Pancho <Pancho.Jones@proton.me> wrote:

    What are the chances an emulator would model a race condition
    accurately?

    Minimal I would think. Way back using a bit-slice based Z80 in
    circuit emulators we had no end of issues caused by timing variances
    between the real chip and the emulation.

    Odd. My 8086 Ices were actually pinpoint accurate.

    There were two kinds of ICE.

    One used a bit slice emulation of the processor to directly drive
    the pins. The other used a real processor and monitored the pins with a bit slice emulation to track the internal registers. The latter worked!

    Both worked for me. Or at least the bit slice one built of ECL did until
    the lab temperature exceeded 30°C.

    We had been pleading with Management for air con, but only when the kit suffered did we finally get it.

    And I pointed out the small print in the manual (operating temperature
    range 0-29°C).


    --
    "When a true genius appears in the world, you may know him by this sign,
    that the dunces are all in confederacy against him."

    Jonathan Swift.

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From The Natural Philosopher@3:770/3 to Martin Gregorie on Sat Aug 5 17:50:26 2023
    On 05/08/2023 13:14, Martin Gregorie wrote:
    On Sat, 5 Aug 2023 08:50:40 +0100, The Natural Philosopher wrote:

    I am still being dragged kicking and screaming into the dark and fœtid
    bowels of javaScript.

    A loathsome melange obviously written by Computer Scientists who were
    told that Object Orientation Was The Coming Thing, but finally realised
    it wasnt.

    I quite agree: I see no use whatsoever for Javascript. So far I haven't
    found anything it can do that can't be done better and faster with awk
    and/or Perl.

    ??? You cant get a browser to run PERL. If you want to use your browser
    as an almost real time interactive control interface for a remote device
    you have no choice BUT to run javaScript. It's the only language a
    browser understands.


    --
    "When a true genius appears in the world, you may know him by this sign,
    that the dunces are all in confederacy against him."

    Jonathan Swift.

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Ahem A Rivet's Shot@3:770/3 to The Natural Philosopher on Sat Aug 5 18:21:20 2023
    On Sat, 5 Aug 2023 17:50:27 +0100
    The Natural Philosopher <tnp@invalid.invalid> wrote:

    ??? You cant get a browser to run PERL.

    Oh yes you can :)

    There's a JavaScript PC emulation that can boot Linux. Now that's a real tour-de-farce.

    --
    Steve O'Hara-Smith
    Odds and Ends at http://www.sohara.org/
    Host: Beautiful Theory meet Inconvenient Fact
    Obit: Beautiful Theory died today of factual inconsistency

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From The Natural Philosopher@3:770/3 to Ahem A Rivet's Shot on Sat Aug 5 18:50:30 2023
    On 05/08/2023 18:21, Ahem A Rivet's Shot wrote:
    On Sat, 5 Aug 2023 17:50:27 +0100
    The Natural Philosopher <tnp@invalid.invalid> wrote:

    ??? You cant get a browser to run PERL.

    Oh yes you can :)

    There's a JavaScript PC emulation that can boot Linux. Now that's a real tour-de-farce.

    but that is using javaScript..

    --
    "An intellectual is a person knowledgeable in one field who speaks out
    only in others...”

    Tom Wolfe

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Ahem A Rivet's Shot@3:770/3 to The Natural Philosopher on Sat Aug 5 19:20:10 2023
    On Sat, 5 Aug 2023 18:50:30 +0100
    The Natural Philosopher <tnp@invalid.invalid> wrote:

    On 05/08/2023 18:21, Ahem A Rivet's Shot wrote:
    On Sat, 5 Aug 2023 17:50:27 +0100
    The Natural Philosopher <tnp@invalid.invalid> wrote:

    ??? You cant get a browser to run PERL.

    Oh yes you can :)

    There's a JavaScript PC emulation that can boot Linux. Now
    that's a real tour-de-farce.

    but that is using javaScript..

    Sure JavaScript to run the X86 PC emulator which boots Linux running
    in x86 code to run a shell and a Perl interpreter (all written in C) to run
    (OK waddle) Perl code all inside the browser.

    IT makes an emulated PC running on a Pi look really fast.

    --
    Steve O'Hara-Smith
    Odds and Ends at http://www.sohara.org/
    Host: Beautiful Theory meet Inconvenient Fact
    Obit: Beautiful Theory died today of factual inconsistency

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From The Natural Philosopher@3:770/3 to Ahem A Rivet's Shot on Sat Aug 5 20:31:04 2023
    On 05/08/2023 19:20, Ahem A Rivet's Shot wrote:
    On Sat, 5 Aug 2023 18:50:30 +0100
    The Natural Philosopher <tnp@invalid.invalid> wrote:

    On 05/08/2023 18:21, Ahem A Rivet's Shot wrote:
    On Sat, 5 Aug 2023 17:50:27 +0100
    The Natural Philosopher <tnp@invalid.invalid> wrote:

    ??? You cant get a browser to run PERL.

    Oh yes you can :)

    There's a JavaScript PC emulation that can boot Linux. Now
    that's a real tour-de-farce.

    but that is using javaScript..

    Sure JavaScript to run the X86 PC emulator which boots Linux running
    in x86 code to run a shell and a Perl interpreter (all written in C) to run (OK waddle) Perl code all inside the browser.

    Yebbut the whole point was that the person I responded to said that they
    didn't NEED JAVASCRIPT to run in a *browser*. They could run PERL *instead*.

    Your example is a straw man. Because it needs Javascript to run.


    IT makes an emulated PC running on a Pi look really fast.


    --
    “It is hard to imagine a more stupid decision or more dangerous way of
    making decisions than by putting those decisions in the hands of people
    who pay no price for being wrong.”

    Thomas Sowell

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Ahem A Rivet's Shot@3:770/3 to The Natural Philosopher on Sat Aug 5 22:25:40 2023
    On Sat, 5 Aug 2023 20:31:05 +0100
    The Natural Philosopher <tnp@invalid.invalid> wrote:

    On 05/08/2023 19:20, Ahem A Rivet's Shot wrote:
    On Sat, 5 Aug 2023 18:50:30 +0100
    The Natural Philosopher <tnp@invalid.invalid> wrote:

    On 05/08/2023 18:21, Ahem A Rivet's Shot wrote:
    On Sat, 5 Aug 2023 17:50:27 +0100
    The Natural Philosopher <tnp@invalid.invalid> wrote:

    ??? You cant get a browser to run PERL.

    Oh yes you can :)

    Yebbut the whole point was that the person I responded to said that they didn't NEED JAVASCRIPT to run in a *browser*. They could run PERL
    *instead*.

    Ah well that's the important missing word - you can have it as well
    but not instead. Unless you want to write a browser (perhaps in perl).

    --
    Steve O'Hara-Smith
    Odds and Ends at http://www.sohara.org/
    Host: Beautiful Theory meet Inconvenient Fact
    Obit: Beautiful Theory died today of factual inconsistency

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Martin Gregorie@3:770/3 to The Natural Philosopher on Sat Aug 5 21:46:38 2023
    On Sat, 5 Aug 2023 17:50:27 +0100, The Natural Philosopher wrote:

    ??? You cant get a browser to run PERL. If you want to use your browser
    as an almost real time interactive control interface for a remote device
    you have no choice BUT to run javaScript. It's the only language a
    browser understands.

    True enough. Call That a brain fart: I don't feed a browser anything
    except 100% HTML that's occasionally augmented with bits of PHP.

    Other than that, these days I mainly write programs in C and Java,
    Spamassassin extensions in Perl (not a favourite language) and use AWK for heavy duty text manipulation and almost everything else that isn't plain Linux/UNIX shell script.

    I used to know a few assemblers: PLAN (ICL 1900 mainframes), TAL (Tandem Nonstop systems) MC6809 and 68000 but haven't used them for years), I used
    to write a lot of SQL, COBOL, RPG3 (UGH!!) and PL/1. I also wrote a tiny
    bit of Algol 68 and liked that a lot - IMO a sadly neglected language.


    --

    Martin | martin at
    Gregorie | gregorie dot org

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From The Natural Philosopher@3:770/3 to Ahem A Rivet's Shot on Sun Aug 6 07:42:48 2023
    On 05/08/2023 22:25, Ahem A Rivet's Shot wrote:
    On Sat, 5 Aug 2023 20:31:05 +0100
    The Natural Philosopher <tnp@invalid.invalid> wrote:

    On 05/08/2023 19:20, Ahem A Rivet's Shot wrote:
    On Sat, 5 Aug 2023 18:50:30 +0100
    The Natural Philosopher <tnp@invalid.invalid> wrote:

    On 05/08/2023 18:21, Ahem A Rivet's Shot wrote:
    On Sat, 5 Aug 2023 17:50:27 +0100
    The Natural Philosopher <tnp@invalid.invalid> wrote:

    ??? You cant get a browser to run PERL.

    Oh yes you can :)

    Yebbut the whole point was that the person I responded to said that they
    didn't NEED JAVASCRIPT to run in a *browser*. They could run PERL
    *instead*.

    Ah well that's the important missing word - you can have it as well
    but not instead. Unless you want to write a browser (perhaps in perl).

    Oh, please don't say that. someone is sure to try to do it. And make it
    run JavasShit as well.

    --
    If you tell a lie big enough and keep repeating it, people will
    eventually come to believe it. The lie can be maintained only for such
    time as the State can shield the people from the political, economic
    and/or military consequences of the lie. It thus becomes vitally
    important for the State to use all of its powers to repress dissent, for
    the truth is the mortal enemy of the lie, and thus by extension, the
    truth is the greatest enemy of the State.

    Joseph Goebbels

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From The Natural Philosopher@3:770/3 to Martin Gregorie on Sun Aug 6 08:09:58 2023
    On 05/08/2023 22:46, Martin Gregorie wrote:
    On Sat, 5 Aug 2023 17:50:27 +0100, The Natural Philosopher wrote:

    ??? You cant get a browser to run PERL. If you want to use your browser
    as an almost real time interactive control interface for a remote device
    you have no choice BUT to run javaScript. It's the only language a
    browser understands.

    True enough. Call That a brain fart: I don't feed a browser anything
    except 100% HTML that's occasionally augmented with bits of PHP.

    Other than that, these days I mainly write programs in C and Java, Spamassassin extensions in Perl (not a favourite language) and use AWK for heavy duty text manipulation and almost everything else that isn't plain Linux/UNIX shell script.

    I used to know a few assemblers: PLAN (ICL 1900 mainframes), TAL (Tandem Nonstop systems) MC6809 and 68000 but haven't used them for years), I used
    to write a lot of SQL, COBOL, RPG3 (UGH!!) and PL/1. I also wrote a tiny
    bit of Algol 68 and liked that a lot - IMO a sadly neglected language.


    All of that is probably admirable for what you do.

    But not for what I want to do.

    I want to control my central heating remotely via a browser interface,
    in great detail and in a highly configurable way , yet with an elegant
    and simple user interface.

    To make it simple to use, it gets to be fiendishly complex to program.

    I *could* use the hooks that are in basic HTML - the input statements
    and the GET and POST methods plus refreshing the pages via submit
    buttons, but that is even worse than the existing box on the wall with
    its fading 20 year old LCD display and its complex and time consuming
    button presses.

    It's so much easier to use GUI type tools - mouse movements and scroll
    wheel and button presses or drag and drop type techniques to configure
    things, and these techniques simply didn't exist when HTML was first
    invented. Now they are accessible, but only as JavaScript events, so I
    have to use the bloody language.

    And let me tell you, it's AWFUL.

    I learnt SQL because I wanted to do some stuff with databases. SQL is remarkably sane. At least for simple stuff. When it got complex I
    dragged out a compiler or PHP to do the clever stuff. Because even when
    I could figure out the exact SQL command to get the result I wanted with
    nested joins and what have you, it took me longer to figure it out than
    write C code to do it with multiple simple queries, and the C code ran
    50 times faster than, at least MySQL. I cant answer for e.g. Oracle etc.

    My coding career was always driven by *result* targets. I wanted to
    achieve an end, what do I have to learn to do it? And I learnt enough to
    do it, and *not a penny more*.

    What I want to do here, requires javaScript. And some sort of server
    side scripting. That could be C, C++, or PHP or almost any language
    that runs on a linux server. I am sure that you could write it all in
    perl or assembler, too.

    But the shortest route that appeared to me some years back was PHP,
    which is a hacked together POS, but its fairly simple if you don't ask
    it to do huge tricks, just like MySQL. In the past I have interfaced it
    with C code when it proved incapable of handling large data objects
    without crashing, but it's fine for simple jobs, like taking a
    javaScript Ajax requests and updating a file on the server for example.

    So I have no religion about any of these languages at all. They are
    just the least effort route to what I wanted to do, then and now. All of
    them suck to some extent, but for me, C sucks the least. As a friend
    once said 'the end result is always just bits, in silicon' and how you
    get there is a choice.

    I guess I could in this instance, have avoided JavaScript by
    constructing a network GUI that wasn't HTML based and constructing a
    custom server that wasn't Apache, to talk to it. But that would mean
    compiling up what amounts to a custom 'browser' for android, OSX, IOS, Windows...and Linux.

    Nope. I'll let Firefox, et al, handle that, thank you!

    So I have to use what they come with.



    --
    "When a true genius appears in the world, you may know him by this sign,
    that the dunces are all in confederacy against him."

    Jonathan Swift.

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Martin Gregorie@3:770/3 to The Natural Philosopher on Sun Aug 6 14:16:42 2023
    On Sun, 6 Aug 2023 08:09:58 +0100, The Natural Philosopher wrote:

    I want to control my central heating remotely via a browser interface,
    in great detail and in a highly configurable way , yet with an elegant
    and simple user interface.

    I'd use Java for that. Its standard library classes for handling control panels, menus etc are much nicer to write the GUI in (Provided you use the generic Window/Controller/Model program structure) than anything available
    in C or C++.

    One of the most satisfying small personal projects I've done in Java was
    to write an editor for CSV data files. Yes, I know that you can use a spreadsheet, but they have stupid limits such as 16K rows per file and apparently (I don't use M$ software) no warning to a user exceeding that
    limit that data is being lost. Also, spreadsheets and have almost no
    decent tools for search and display within a large file, let alone any
    ability to search for rows containing specified value(s) and convert them
    to or from comment lines. When I was roster manager at my gliding club I
    needed to edit CSV files with 5000+ lines and up to 30 columns, I wrote my
    own CSV editor in Java. This provides several editing features I needed
    that are not available in spreadsheets and for giggles included a
    scripting facility as well. It all went together much faster than I
    expected, does exactly what I need and does it quickly.

    The only other way to handle these edits rapidly would be to use bash:
    this would be equally fast to use but would it take longer to write the
    various scripts than it does to run a CSV file through my editor.

    Some of the 4GL systems come close, but (a) who uses then now and (b)
    there's no way they can be a front end for your sort of controller. Anyway
    they get tiresome if you try to do anything with them except what they're designed for: maintaining data in related sets of indexed files, though I
    did write a Sculptor 4GL system to handle scoring for the British National
    Free Flight Champs and the Stonehenge Cup. This ran on a bog standard
    80286 PC in the back of a covered van and was powered by a portable
    generator.


    To make it simple to use, it gets to be fiendishly complex to program.

    I *could* use the hooks that are in basic HTML - the input statements
    and the GET and POST methods plus refreshing the pages via submit
    buttons, but that is even worse than the existing box on the wall with
    its fading 20 year old LCD display and its complex and time consuming
    button presses.

    That sounds nasty. For HTML pages that will be displayed by a web server I generally stick to vanilla HTML pages with bits of PHP thrown in if I want
    to accept data from an HTML page. The O'Reilly "Programming PHP" book is
    pretty straight forward and is well organised, and some of the things yo
    might want to do may require an HTML server (I run an Apache server at
    home on my LAN).

    If you'd rather stick to C, have you considered using Curses to display a control panel and manage both status display and input of control
    settings? Its a while since I've used it, but I seem to recall that it
    will also accept input from on screen windows. O'Reilly have a decent
    guide to it.

    It's so much easier to use GUI type tools - mouse movements and scroll
    wheel and button presses or drag and drop type techniques to configure things, and these techniques simply didn't exist when HTML was first invented. Now they are accessible, but only as JavaScript events, so I
    have to use the bloody language.

    I tried Javascript: I tried it once and found both it and the book on it
    to be poorly organised, badly written, and lacking in any overall
    description of how the bloody language works and how its various parts interact.

    And let me tell you, it's AWFUL.

    Couldn't agree more.

    But seriously, as a C man it would be worth your while at least looking at either Curses for laying out and painting the display if its directly
    attached to the MPU (i.e. is running on an RPi, and combining PHP and HTML (they work well together) if you need anything that Curses can't handle.

    I learnt SQL because I wanted to do some stuff with databases. SQL is remarkably sane. At least for simple stuff. When it got complex I
    dragged out a compiler or PHP to do the clever stuff. Because even when
    I could figure out the exact SQL command to get the result I wanted with nested joins and what have you, it took me longer to figure it out than
    write C code to do it with multiple simple queries, and the C code ran
    50 times faster than, at least MySQL. I cant answer for e.g. Oracle etc.

    That's generally true. I like SQL and have used it on several different databases and data warehouses. Its particularly well integrated into both
    C and Java.

    Mind you, I also liked IDMS, the CODASYL database. Its so well integrated
    into COBOL that its effective a language extension.

    My coding career was always driven by *result* targets. I wanted to
    achieve an end, what do I have to learn to do it? And I learnt enough to
    do it, and *not a penny more*.

    I thought that was a fairly general approach, at least in the better
    software houses. Certainly I was used to be asked what I knew about 'x'
    and,if my answer was 'heard of but not used' and it was within my
    skillset, getting a heal of manuals dumped on my desk and told 'You're on
    the project starting week after next' and also knowing that, if I was struggling, somebody I could talk to about 'x' would be in the pub on
    Friday.

    What I want to do here, requires javaScript. And some sort of server
    side scripting. That could be C, C++, or PHP or almost any language
    that runs on a linux server. I am sure that you could write it all in
    perl or assembler, too.

    See above except that, assuming that your application drives the display directly, I'd look at Java or C plus Curses, and PHP if absolutely
    necessary - I've used PHP and quite like it, combined with HTML, for pages managed by an Apache server..

    But the shortest route that appeared to me some years back was PHP,
    which is a hacked together POS, but its fairly simple if you don't ask
    it to do huge tricks, just like MySQL. In the past I have interfaced it
    with C code when it proved incapable of handling large data objects
    without crashing, but it's fine for simple jobs, like taking a
    javaScript Ajax requests and updating a file on the server for example.

    I suspect its not meant to work that way, which is why I suggested using
    Curses for output to the screen and PHP only to read user input to the
    screen.

    Of course, Java does both pretty much seamlessly, but seeing that you
    prefer C,...


    --

    Martin | martin at
    Gregorie | gregorie dot org

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From David Taylor@3:770/3 to Mike Scott on Thu Aug 10 10:16:28 2023
    On 09/08/2023 11:19, Mike Scott wrote:
    I'd be interested whether others get the same results from the test
    program (on a picoW to be precise). It needs to run for an extended
    period. Mind the line wrap.

    In another context, I needed to run a physical Pico-W but with the Wi-Fi disabled (to get more memory). I can test your program, but have you tried running the plain Pico firmware, rather than the Pico-W one?
    --
    Cheers,
    David
    Web: https://www.satsignal.eu

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Mike Scott@3:770/3 to David Taylor on Mon Aug 14 14:12:20 2023
    On 10/08/2023 10:16, David Taylor wrote:
    On 09/08/2023 11:19, Mike Scott wrote:
    I'd be interested whether others get the same results from the test
    program (on a picoW to be precise). It needs to run for an extended
    period. Mind the line wrap.

    In another context, I needed to run a physical Pico-W but with the Wi-Fi disabled (to get more memory).  I can test your program, but have you
    tried running the plain Pico firmware, rather than the Pico-W one?

    I have now.

    I was running rp2-pico-w-20230422-unstable-v1.19.1-1019-g9e6885ad8.uf2
    which I've replaced with rp2-pico-20230426-v1.20.0.uf2 which seems to be
    the latest for the plain pico.

    That fails as well.

    Likewise rp2-pico-w-20230426-v1.20.0.uf2 (the latest picoW) fails.


    Is there anywhere to report this sort of bug? I'm hoping it's a
    micropython software issue, not a board fault.


    --
    Mike Scott
    Harlow, England

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Mike Scott@3:770/3 to David Taylor on Wed Aug 16 18:44:16 2023
    On 14/08/2023 15:56, David Taylor wrote:
    On 14/08/2023 14:12, Mike Scott wrote:
    I have now.

    I was running rp2-pico-w-20230422-unstable-v1.19.1-1019-g9e6885ad8.uf2
    which I've replaced with rp2-pico-20230426-v1.20.0.uf2 which seems to be
    the latest for the plain pico.

    That fails as well.

    Likewise rp2-pico-w-20230426-v1.20.0.uf2 (the latest picoW) fails.


    Is there anywhere to report this sort of bug? I'm hoping it's a
    micropython software issue, not a board fault.

    I have these:

      pimoroni-picow-v1.20.3-micropython.uf2
      pimoroni-pico-v1.20.3-micropython.uf2

    ...
    Thanks for the info.

    I've now tried pimoroni-picow-v1.20.4-micropython - that's worse than
    ever, crashing much sooner for the problem range. (I notice the file is significantly larger than 1.19.1 or 1.20.0)

    On the bright side, it does suggest the issue is in the micropython
    rather than being a chip problem.

    I've found the following; the number indicates the number of loops of my
    test rig recorded either at failure or when my patience ran out.
    # these times for firmware 1.19.0 or 1.20.0 (mixed)
    # no dlay good to 138200
    # 1 us good to 188000
    # 5 us good to 395200
    # 7 us good to 335146
    # 10 us fails 14410
    # 15 us fail 14010
    # 20 us fails 26600
    # 30 fails 261893
    # 32 fails 42430
    # 35 us good to 421110
    # 40 us good to 378478
    # 50 good to 572000
    # 100 us good to 372000

    There really does seem to be a window when sleeping from just under 10
    to just under 35 us where interrupts seem to fail eventually.

    Weird.

    I'll see if I can get to grips with the github bug reporting.

    --
    Mike Scott
    Harlow, England

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Mike Scott@3:770/3 to Mike Scott on Thu Aug 17 14:34:42 2023
    On 16/08/2023 18:44, Mike Scott wrote:
    ....
    There really does seem to be a window when sleeping from just under 10
    to just under 35 us where interrupts seem to fail eventually.

    Weird.

    What's more, it only seems to affect the picoW.

    I've tried two W's now, and one without the wifi.

    Both W's fail the same way; I've not seen the plain one fail.

    Can anyone replicate this please?



    I'll see if I can get to grips with the github bug reporting.

    --
    Mike Scott
    Harlow, England

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From David Taylor@3:770/3 to Mike Scott on Thu Aug 17 19:19:42 2023
    On 17/08/2023 14:34, Mike Scott wrote:
    On 16/08/2023 18:44, Mike Scott wrote:
    ....
    There really does seem to be a window when sleeping from just under 10
    to just under 35 us where interrupts seem to fail eventually.

    Weird.

    What's more, it only seems to affect the picoW.

    I've tried two W's now, and one without the wifi.

    Both W's fail the same way; I've not seen the plain one fail.

    Can anyone replicate this please?



    I'll see if I can get to grips with the github bug reporting.


    Can you point to some test code, and brief instructions, please?
    --
    Cheers,
    David
    Web: https://www.satsignal.eu

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Mike Scott@3:770/3 to David Taylor on Fri Aug 18 09:12:48 2023
    On 17/08/2023 19:19, David Taylor wrote:
    On 17/08/2023 14:34, Mike Scott wrote:
    On 16/08/2023 18:44, Mike Scott wrote:
    ....
    There really does seem to be a window when sleeping from just under 10
    to just under 35 us where interrupts seem to fail eventually.

    Weird.

    What's more, it only seems to affect the picoW.

    I've tried two W's now, and one without the wifi.

    Both W's fail the same way; I've not seen the plain one fail.

    Can anyone replicate this please?



    I'll see if I can get to grips with the github bug reporting.


    Can you point to some test code, and brief instructions, please?

    Test code is two articles up-thread.

    I've also posted to the raspberry pi forum. Thread is at https://forums.raspberrypi.com/viewtopic.php?t=355111

    (which also includes the test code minus the python indents)

    with another's notes at
    https://forums.raspberrypi.com/viewtopic.php?t=312874
    (including his test rig)

    It seems a problem in micropython has been known about for a couple of
    years, but hasn't been fixed.

    For completeness though, I've tried again running the code on a plain
    pico. It did fail this morning, but ran for maybe 20x more interrupts
    than the picoW before hanging.

    Frankly, I'm saddened. So much promise. The board is great, but firmware
    that "usually works" is IMO broken and not to be trusted. So I guess
    it's the bin for micropython, and I'll have to see about a replacement, probably C++, SDK. Maybe more luck there.


    --
    Mike Scott
    Harlow, England

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From David Taylor@3:770/3 to Mike Scott on Fri Aug 18 10:13:24 2023
    On 18/08/2023 09:12, Mike Scott wrote:
    Test code is two articles up-thread.

    I've also posted to the raspberry pi forum. Thread is at https://forums.raspberrypi.com/viewtopic.php?t=355111

    (which also includes the test code minus the python indents)

    with another's notes at
    https://forums.raspberrypi.com/viewtopic.php?t=312874
    (including his test rig)

    It seems a problem in micropython has been known about for a couple of
    years, but hasn't been fixed.

    For completeness though, I've tried again running the code on a plain
    pico. It did fail this morning, but ran for maybe 20x more interrupts
    than the picoW before hanging.

    Frankly, I'm saddened. So much promise. The board is great, but firmware
    that "usually works" is IMO broken and not to be trusted. So I guess
    it's the bin for micropython, and I'll have to see about a replacement, probably C++, SDK. Maybe more luck there.

    Downloaded and testing with firmware 1.20.4 from:

    https://github.com/pimoroni/pimoroni-pico/releases/tag/v1.20.4

    With a 15 us sleep delay, the program stopped running at 3902. LED continuously lit, no error message printed.

    Second run: 5203, LED dark. Device warmer, perhaps?

    Third run: 2601, LED dark.

    All these are near multiples of 1300, aren't they. Chance, or....

    Fourth run: 3601, LED lit, so not 1300!

    --
    Cheers,
    David
    Web: https://www.satsignal.eu

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From The Natural Philosopher@3:770/3 to Mike Scott on Fri Aug 18 10:43:04 2023
    On 18/08/2023 09:12, Mike Scott wrote:
    On 17/08/2023 19:19, David Taylor wrote:
    On 17/08/2023 14:34, Mike Scott wrote:
    On 16/08/2023 18:44, Mike Scott wrote:
    ....
    There really does seem to be a window when sleeping from just under 10 >>>> to just under 35 us where interrupts seem to fail eventually.

    Weird.

    What's more, it only seems to affect the picoW.

    I've tried two W's now, and one without the wifi.

    Both W's fail the same way; I've not seen the plain one fail.

    Can anyone replicate this please?



    I'll see if I can get to grips with the github bug reporting.


    Can you point to some test code, and brief instructions, please?

    Test code is two articles up-thread.

    I've also posted to the raspberry pi forum. Thread is at https://forums.raspberrypi.com/viewtopic.php?t=355111

    (which also includes the test code minus the python indents)

    with another's notes at
    https://forums.raspberrypi.com/viewtopic.php?t=312874
    (including his test rig)

    It seems a problem in micropython has been known about for a couple of
    years, but hasn't been fixed.

    For completeness though, I've tried again running the code on a plain
    pico. It did fail this morning, but ran for maybe 20x more interrupts
    than the picoW before hanging.

    Frankly, I'm saddened. So much promise. The board is great, but firmware
    that "usually works" is IMO broken and not to be trusted. So I guess
    it's the bin for micropython, and I'll have to see about a replacement, probably C++, SDK. Maybe more luck there.



    You do eliminate at least one more layer of uncertainty with C, in that
    you can see (sic!) exactly what the assembler code is doing.
    I know from experience it is all to easy to write a bit of 'code that
    must not be interrupted' and not realise it needs to be surrounded by a
    pair of 'disable/enable interrupt' instructions...and it is just things
    like timers that get interrupted by timer interrupts that are likely to
    blow things up.



    --
    In a Time of Universal Deceit, Telling the Truth Is a Revolutionary Act.

    - George Orwell

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