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.

--

Martin | martin at
Gregorie | gregorie dot org

On 05/08/2023 22:25, Ahem A Rivet's Shot wrote:
> 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).
>
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

On 05/08/2023 22:46, Martin Gregorie wrote:
> 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.
>
>
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.

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

--

Martin | martin at
Gregorie | gregorie dot org

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

[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

--
Mike Scott
Harlow, England

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

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.

--
Mike Scott
Harlow, England

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....
--
Cheers,
David
Web: https://www.satsignal.eu

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
Harlow, England

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.

--
Mike Scott
Harlow, England

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?
--
Cheers,
David
Web: https://www.satsignal.eu

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.

--
Mike Scott
Harlow, England

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!

--
Cheers,
David
Web: https://www.satsignal.eu

On 18/08/2023 09:12, Mike Scott wrote:
> 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.
>
>

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