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?


--
Mike Scott
Harlow, England

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

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)

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)

On 02/08/2023 18:55, David Taylor wrote:

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!

+1

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.

--
"Anyone who believes that the laws of physics are mere social
conventions is invited to try transgressing those conventions from the
windows of my apartment. (I live on the twenty-first floor.) "

Alan Sokal

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

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?

Can't help yet as I haven't even plugged my PICO in, but it reminds me
of a job I did years ago writing a BIOS for an 8088 single board machine. Occasionally - every few hours - it would hang.
Took a very expensive CPU emulators to spot the problem, There as just
one sequence in the bios, which if interrupted by a timer interrupt,
would cause all hell to break loose.

I simply disabled interrupts round the three opcodes and the problem
never reoccurred.

My impression is FWIW, that the Picos support software is racing to keep
up with it - it's nowhere near as stable and bug free as raspios.

Well, bare metal programming is what it is. Now if someone wrote a
software emulator for a PICO we could debug the thing...



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

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

On 05/08/2023 08:51, The Natural Philosopher wrote:

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.

[OP]
On which note, I'll add where I've got to, as it looks like a race
condition somewhere although whether in the micropython system or the
chip, I have no idea.

I'm including a little test program that has a 10ms timer interrupt
within which time.sleep_us() is called to provide a short delay. The
main part of the code does a sleep for a second and checks an
appropriate number of interrupts has occurred, printing the count. A
couple of led's are toggled so I can see it's still running.

For delays < 5usec or > 100usec, no problem and it seems to run forever.
For delays in the range 10..20 usec, the program will eventually hang -
no interrupts and main loop stuck.

The tm1637 module uses delays of 10usec when clocking the chip, right in
the 'hang' range. Changing that 10 usec delay for two 5 usec delays
seems to work round the issue, and I've since had my clock program run
for nearly 24 hours without issue.


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.


import machine
import time

mainLoopTime = 1000 # msec
interruptPeriod = 10 # msec (must be same units as mainlooptime) usleepDelay = 5 # microsec
# no dlay good to 138200
# 1 us good to 188000
# 5 us good to 395200
# 10 us fails
# 15 us fail 14010
# 20 us fails 26600
# 100 us good to 372000

interruptCounter = 0

led = machine.Pin("LED", machine.Pin.OUT)
xled = machine.Pin(0, machine.Pin.OUT)

def update(timer):
global interruptCounter

interruptCounter += 1
if usleepDelay != 0:
time.sleep_us(usleepDelay)
if interruptCounter % 32 == 0:
xled.toggle()

timer = machine.Timer(mode=machine.Timer.PERIODIC,
period=interruptPeriod, callback=update)

lastCounter = interruptCounter
while(True):
time.sleep_ms(mainLoopTime)
led.toggle()
copyIC = interruptCounter
expectedCounter = lastCounter + mainLoopTime//interruptPeriod
print(expectedCounter, copyIC)
if abs(copyIC - expectedCounter) > 5:
print(copyIC, expectedCounter, lastCounter, " delay", usleepDelay)
raise Exception("**** problem ****")
lastCounter = copyIC


--
Mike Scott
Harlow, England

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

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)

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)

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

which sound later than yours, and I see 120.4 is out:

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

You could report an issue here:

https://github.com/pimoroni/pimoroni-pico/issues

or on their forums:

https://forums.pimoroni.com/

I've found them quite helpful.

To add to the confusion there's a new MicroPython out, but I don't know whether it's tested/approved for Pimoroni stuff....
--
Cheers,
David
Web: https://www.satsignal.eu

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

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)

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)

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)

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)

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)

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)