Hi all. I've been pottering trying to get to understand use of a Pico. I
hope this is on-topic for the group.
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?
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.
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?
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.
Well, bare metal programming is what it is. Now if someone wrote a
software emulator for a PICO we could debug the thing...
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?
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 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?
What are the chances an emulator would model a race condition accurately?
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?
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.
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.
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 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.
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 +0100Odd. My 8086 Ices were actually pinpoint accurate.
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.
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!
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œtidI quite agree: I see no use whatsoever for Javascript. So far I haven't
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.
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.
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.
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..
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 +0100but that is using javaScript..
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.
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.
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*.
??? 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.
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).
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 browserTrue enough. Call That a brain fart: I don't feed a browser anything
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.
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.
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.
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.
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.
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.
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
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:
....
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.
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.
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.
| Sysop: | Xerxes |
|---|---|
| Location: | Azle, Texas |
| Users: | 119 |
| Nodes: | 10 (0 / 10) |
| Uptime: | 138:13:53 |
| Calls: | 3,028 |
| Calls today: | 4 |
| Files: | 156 |
| U/L today: |
0 files (0K bytes) |
| D/L today: |
0 files (0K bytes) |
| Messages: | 294,145 |
| Posted today: | 0 |