Pico - issue with interrupts and sleep??

Aug 02, 2023 Last reply: 2 years ago 38 Replies

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?



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.

On Wed, 2 Aug 2023 17:14:47 +0100, Mike Scott snipped-for-privacy@scottsonline.org.uk.invalid> declaimed the following:

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

+1

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

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

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?

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

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.

formatting link

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.

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

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.

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.

As good as the person who wrote it chose to make it.

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!

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.

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.

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.

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

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

Join the Discussion

Have something to add? Share your thoughts — no account required.

Didn't find your answer?

Ask the community — no account required