Pico - issue with interrupts and sleep??

[Mike Scott]

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

[David Taylor]

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

[The Natural Philosopher]

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

[The Natural Philosopher]

On 02/08/2023 17:14, Mike Scott wrote:

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

[Pancho]

On 02/08/2023 17:14, Mike Scott 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.

[Mike Scott]

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?

[Theo]

The Natural Philosopher <t...@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

[Pancho]

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.

[Pancho]

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

[Theo]

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

[Ahem A Rivet's Shot]

On Fri, 4 Aug 2023 15:30:16 +0100
Pancho <Pancho...@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

[The Natural Philosopher]

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

[The Natural Philosopher]

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

[The Natural Philosopher]

On 04/08/2023 19:16, Ahem A Rivet's Shot wrote:
> On Fri, 4 Aug 2023 15:30:16 +0100
> Pancho <Pancho...@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.

[Ahem A Rivet's Shot]

On Sat, 5 Aug 2023 08:53:01 +0100

The Natural Philosopher <t...@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...@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!

[Martin Gregorie]

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

[Ahem A Rivet's Shot]

On Sat, 5 Aug 2023 08:50:40 +0100

The Natural Philosopher <t...@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.

[The Natural Philosopher]

On 05/08/2023 09:29, Ahem A Rivet's Shot wrote:
> On Sat, 5 Aug 2023 08:53:01 +0100
> The Natural Philosopher <t...@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...@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.

[The Natural Philosopher]

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

[Ahem A Rivet's Shot]

On Sat, 5 Aug 2023 17:50:27 +0100

The Natural Philosopher <t...@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.

[The Natural Philosopher]

On 05/08/2023 18:21, Ahem A Rivet's Shot wrote:
> On Sat, 5 Aug 2023 17:50:27 +0100
> The Natural Philosopher <t...@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

[Ahem A Rivet's Shot]

On Sat, 5 Aug 2023 18:50:30 +0100

The Natural Philosopher <t...@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 <t...@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.

[The Natural Philosopher]

On 05/08/2023 19:20, Ahem A Rivet's Shot wrote:
> On Sat, 5 Aug 2023 18:50:30 +0100
> The Natural Philosopher <t...@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 <t...@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.
>

--

[Ahem A Rivet's Shot]

On Sat, 5 Aug 2023 20:31:05 +0100

The Natural Philosopher <t...@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 <t...@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 <t...@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).

[Martin Gregorie]

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.

[The Natural Philosopher]

On 05/08/2023 22:25, Ahem A Rivet's Shot wrote:
> On Sat, 5 Aug 2023 20:31:05 +0100
> The Natural Philosopher <t...@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 <t...@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 <t...@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

[The Natural Philosopher]

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.

[Martin Gregorie]

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

[Mike Scott]

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

[David Taylor]

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

[Mike Scott]

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.

[David Taylor]

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

[Mike Scott]

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]

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?

[David Taylor]

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

[Mike Scott]

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.

[David Taylor]

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!

[The Natural Philosopher]

On 18/08/2023 09:12, Mike Scott wrote:

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