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

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

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?

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

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

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.

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

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

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.

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?

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

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

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

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

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

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

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

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

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.

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.

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

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

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

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

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