Pico - issue with interrupts and sleep??

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.

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.

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

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.

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

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

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.

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

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.

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.

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.

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.

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.

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

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

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

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.

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:

To add to the confusion there's a new MicroPython out, but I don't know whether it's tested/approved for Pimoroni stuff....

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

On 16/08/2023 18:44, Mike Scott wrote: ....

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?

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

with another's notes at

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:

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!

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.