From Newsgroup: comp.os.linux.misc

On 2/6/26 20:12, Lawrence DrCOOliveiro wrote:

On Fri, 6 Feb 2026 22:32:14 +0000, Pancho wrote:

I was assuming the hardware stack was more than just a register, and
memory. i.e. I assumed there were specific pop/push instructions
which were optimised to get data and adjust a register stack pointer
as a single instruction.

Some common architectures have no hardware stack: the stack convention
comes purely from the software ABI. E.g. POWER/PowerPC.

So there would be a performance hit in a software stack where
multiple instructions would be needed.

I remember, back in the days of the VAX, which was the classic machine
with the rCLkitchen-sinkrCY instruction set in the 1980s -- an instruction for just about everything, including pushing and popping stack
elements. You could save the lowest 6 general-purpose registers with
just one PUSHR instruction (2 bytes), or you could do it with 6
separate PUSHL instructions (2 |u 6 = 12 bytes). Guess which was
faster?

The TMS-9900 had a couple of similar instructions
so you could shove ALL the registers onto a stack
before branching or whatever. Odd chip - sort of
a hardware solution to multiple users.

--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: comp.os.linux.misc

Pancho <Pancho.Jones@protonmail.com> writes:

On 2/5/26 16:03, Richard Kettlewell wrote:

Pancho <Pancho.Jones@protonmail.com> writes:

On 2/5/26 14:14, The Natural Philosopher wrote:

The first is of course implementation specific. C can specify a data
stack separate from a program stack and avoid code corruption,
leaving only data corruption...

Can it? Naively, I would have thought C was normally built on top of
native assembler function calls, which dictates a shared stack.
Obviously you could implement a function call independent of
assembler, but does anyone, in practice?

YourCOd leave the call stack as it is (i.e. CALL and RET, on x86) and
use another register to manage the data stack (maybe rbp on
x86). IrCOve never heard of anyone doing it for C but I donrCOt think
thererCOs any fundamental obsctacle to it. ItrCOd be a distinct ABI, so
not particularly convenient to integrate into existing systems.

I was assuming the hardware stack was more than just a register, and
memory. i.e. I assumed there were specific pop/push instructions which
were optimised to get data and adjust a register stack pointer as a
single instruction. So there would be a performance hit in a software
stack where multiple instructions would be needed.

The call stack _does_ have specialized instructions: CALL and RET on
x86. If you wanted to build your own call stack, replacing CALL would
mean:
- get return address into a register
- decrement call stack pointer
- store it to your call stack
- jump to call target

Four instructions instead of one, with dependencies on the first two.
Emulating RET would take three instructions.

For the data stack the situation is different. On x86 PUSH and POP
exist, but even with the regular stack you donrCOt have to use them: you
can adjust the stack pointer by the maximum amount needed on entry and
exit and then use normal load/store instructions with relative
addressing modes. That works just as well with any register. Compilers generally mix this strategy with PUSHes and POPs to some degree.

As an example, https://godbolt.org/z/ac1rj9aGe:
- PUSH/POP are used to preserve callee-saved registers (L2-5 and L31-34)
- it directly modifies ESP to create/discard a stack frame (L6, L30)
- it uses ESP-relative indirect addressing to store/retrieve d (L19,
L26)
- it also uses ESP-relative addressing to set the argument to report
(L23, L28), rather than using PUSH, perhaps because it removes the
need for a POP after the call.

The above is quite x86-centric.

- Some architectures have pre-increment and post-decrement address
modes, in which case the emulated CALL/RET are each one instruction
shorter and there are no special PUSH/POP instructions. Essentially
you can use any register (or at least, any address register) as a
stack pointer, although there is usually a platform convention about
which you choose.

- Some architectures use a link register for the most recent return
address, meaning that calls to rCyleafrCO functions donrCOt touch call stack
memory at all.
--
https://www.greenend.org.uk/rjk/
--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: comp.os.linux.misc

On 06/02/2026 22:32, Pancho wrote:

On 2/5/26 16:03, Richard Kettlewell wrote:

Pancho <Pancho.Jones@protonmail.com> writes:

On 2/5/26 14:14, The Natural Philosopher wrote:

The first is of course implementation specific. C can specify a data
stack separate from a program stack and avoid code corruption,
leaving only data corruption...

Can it?-a Naively, I would have thought C was normally built on top of
native assembler function calls, which dictates a shared stack.
Obviously you could implement a function call independent of
assembler, but does anyone, in practice?

YourCOd leave the call stack as it is (i.e. CALL and RET, on x86) and use
another register to manage the data stack (maybe rbp on x86). IrCOve never >> heard of anyone doing it for C but I donrCOt think thererCOs any fundamental >> obsctacle to it. ItrCOd be a distinct ABI, so not particularly convenient
to integrate into existing systems.

I was assuming the hardware stack was more than just a register, and
memory. i.e. I assumed there were specific pop/push instructions which
were optimised to get data and adjust a register stack pointer as a
single instruction. So there would be a performance hit in a software
stack where multiple instructions would be needed.

Probably.
Depends on the architecture

"In Motorola 68000 (68k) assembly,
Address Register Indirect with Pre-decrement is a powerful addressing
mode used to point to data and automatically decrease the address
pointer before access. This is commonly used for stack operations or
iterating backward through memory (e.g., from end to beginning). "

8086 doesn't have such a feature: you would do a specific move register
to address location and decrement address pointer.
Or to be excessively arcane, swap the stack pointer with another
register, push every thing into the data stack,m and then swap the
pointer back before issuing a call.

Or use the stack pointer as the data pointer using another register to
store return addresses,

Nothing about the C language itself specifies intermixing of the code
space with the data space.

Looking at Google, it appears my simplistic view of pushing arguments
onto the stack is wrong anyway. There seems to be optimisations
involving using registers for the first few arguments (x86/64), more so
with RISK_V, only using the stack when necessary. I guess there are also parallel instructions to push multiple registers onto a hardware stack
in one go.

Indeed. Gcc and pals will use all registers first and often avoid
creating intermediate variables at all,

If optimising for code space you can create subroutine stubs like

STUB: POP CX
STUB1: POP BX
STUB2: POP AX
RET

and finish subroutines with a JMP to one of those labels.

i,e have the compiler look for any sequence of the same instructions preceding a RET and replace then with a JMP ...

But I take your point about the protection of execute permission on
memory areas etc.

Hardware is something most coders do not really understand and that's
why they make mistakes.
--
Religion is regarded by the common people as true, by the wise as
foolish, and by the rulers as useful.

(Seneca the Younger, 65 AD)


--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: comp.os.linux.misc

On 07/02/2026 02:59, c186282 wrote:

On 2/6/26 20:12, Lawrence DrCOOliveiro wrote:

On Fri, 6 Feb 2026 22:32:14 +0000, Pancho wrote:

I was assuming the hardware stack was more than just a register, and
memory. i.e. I assumed there were specific pop/push instructions
which were optimised to get data and adjust a register stack pointer
as a single instruction.

Some common architectures have no hardware stack: the stack convention
comes purely from the software ABI. E.g. POWER/PowerPC.

So there would be a performance hit in a software stack where
multiple instructions would be needed.

I remember, back in the days of the VAX, which was the classic machine
with the rCLkitchen-sinkrCY instruction set in the 1980s -- an instruction >> for just about everything, including pushing and popping stack
elements. You could save the lowest 6 general-purpose registers with
just one PUSHR instruction (2 bytes), or you could do it with 6
separate PUSHL instructions (2 |u 6 = 12 bytes). Guess which was
faster?

-a The TMS-9900 had a couple of similar instructions
-a so you could shove ALL the registers onto a stack
-a before branching or whatever. Odd chip - sort of
-a a hardware solution to multiple users.

Yes indeed. A context switch was enormously efficient.

It wasn't so much (IIRC) a question of having all the registers pushed
into a stack so much as not having registers in the first place - these
being instead locations in memory pointed to by a master register, which
you could change and thereby have a completely new context.
Thus general instructions were slow, but context switches were
blindingly fast. a real minicomputer architecture

I may be wrong about that., Its been a long time.
--
rCLIt is not the truth of Marxism that explains the willingness of intellectuals to believe it, but the power that it confers on
intellectuals, in their attempts to control the world. And since...it is futile to reason someone out of a thing that he was not reasoned into,
we can conclude that Marxism owes its remarkable power to survive every criticism to the fact that it is not a truth-directed but a
power-directed system of thought.rCY
Sir Roger Scruton

--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: comp.os.linux.misc

On 07/02/2026 02:31, c186282 wrote:

Proper coding and nobody will over-write yer buffer.

The problem comes when you interface to TheRealWorldrao and some nasty
little bugger sends you e.g. an Ethernet packet that is completely
illegal in a creative sort of way.

Or halfway through a sequence of instructions referencing a variable,
your code gets interrupted and that variable changes value.

Or as was done in military code. a massive EMP pulse scrambles the CPU
and you have to reboot from ROM...just separate code fragments with
hundreds of JMP REBOOT instructions...

The idealised world of the computer scientist does not occur in practice.
My friend who was involved with the ACORN boys tells of a time when
random crashes would occur every few hours. They are unable to eliminate
the cause, but by adding wait states they increased the interval to
every few hundred years, which was good enough for PFYs in the parents basement.
--
Karl Marx said religion is the opium of the people.
But Marxism is the crack cocaine.

--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: comp.os.linux.misc

On 07/02/2026 02:44, c186282 wrote:

On 2/6/26 05:45, The Natural Philosopher wrote:

On 06/02/2026 01:51, c186282 wrote:

On 2/5/26 14:27, The Natural Philosopher wrote:

On 05/02/2026 15:09, Pancho wrote:

On 2/5/26 14:14, The Natural Philosopher wrote:

The first is of course implementation specific. C can specify a
data stack separate from a program stack and avoid code
corruption, leaving only data corruption...

Can it?-a Naively, I would have thought C was normally built on top >>>>> of native assembler function calls, which dictates a shared stack.
Obviously you could implement a function call independent of
assembler, but does anyone, in practice?

You simply use-a a register as a second stack [data] pointer.

Assign all your mem variables on that stack, and increment it at
function end.

The assembler is trivial. Making C do it that way would not be hard,
either..

-a-a I actually searched on that a little, could
-a-a not see any civil way to specify a stack in
-a-a a new segment in 'C'.

Oh sure. You would have to modify the compiler

-a Ah .... no problems then .......

But IIRC the first PDP I worked on had 64k data and 64k code in
entirely different bits of RAM.

-a Works.

-a Of course actual 'segments' are kind of
-a passe' these days - an olde-dayz artifact
-a everyone hated.

Isn't it all handled by a memory manager?

-a-a ASM, yea, easier - you have total control (and
-a-a total responsibility).

Of course. That's what it teaches you....

-a Gen X/Y/Z/A2 "programmers" - have any EVER done
-a a thing in ASM ? Even microcontrollers are now
-a normally done in 'C' or MicroPython.

Precisely.

But at least inveterate tinkerers are leaning about things like response times...

My Picos will not output anything to the USB port for quite a few
milliseconds after it has been initialised.

Juts be patient and use the sleep function
--
Religion is regarded by the common people as true, by the wise as
foolish, and by the rulers as useful.

(Seneca the Younger, 65 AD)


--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: comp.os.linux.misc

On 2/7/26 07:15, The Natural Philosopher wrote:

On 07/02/2026 02:59, c186282 wrote:

On 2/6/26 20:12, Lawrence DrCOOliveiro wrote:

On Fri, 6 Feb 2026 22:32:14 +0000, Pancho wrote:

I was assuming the hardware stack was more than just a register, and
memory. i.e. I assumed there were specific pop/push instructions
which were optimised to get data and adjust a register stack pointer
as a single instruction.

Some common architectures have no hardware stack: the stack convention
comes purely from the software ABI. E.g. POWER/PowerPC.

So there would be a performance hit in a software stack where
multiple instructions would be needed.

I remember, back in the days of the VAX, which was the classic machine
with the rCLkitchen-sinkrCY instruction set in the 1980s -- an instruction >>> for just about everything, including pushing and popping stack
elements. You could save the lowest 6 general-purpose registers with
just one PUSHR instruction (2 bytes), or you could do it with 6
separate PUSHL instructions (2 |u 6 = 12 bytes). Guess which was
faster?

-a-a The TMS-9900 had a couple of similar instructions
-a-a so you could shove ALL the registers onto a stack
-a-a before branching or whatever. Odd chip - sort of
-a-a a hardware solution to multiple users.

Yes indeed. A context switch was enormously efficient.

It wasn't so much (IIRC) a question of having all the registers pushed
into a stack so much as not having registers in the first place - these being instead locations in memory pointed to by a master register, which
you could change and thereby have a completely new context.
Thus general instructions were slow, but context switches were
blindingly fast. a real minicomputer architecture

I may be wrong about that., Its been a long time.

Ditto.

The 9900 kept all the working registers in RAM (which
was about as fast as on-chip at the time. Context
switches were just re-pointing the "right now"
register to another set of in-RAM registers. In
principle it's not SO different from what is done
now to support concurrent users, however putting
it into a chip that small so long back was unique.

--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: comp.os.linux.misc

On 2/7/26 07:29, The Natural Philosopher wrote:

On 07/02/2026 02:44, c186282 wrote:

On 2/6/26 05:45, The Natural Philosopher wrote:

On 06/02/2026 01:51, c186282 wrote:

On 2/5/26 14:27, The Natural Philosopher wrote:

On 05/02/2026 15:09, Pancho wrote:

On 2/5/26 14:14, The Natural Philosopher wrote:

The first is of course implementation specific. C can specify a >>>>>>> data stack separate from a program stack and avoid code
corruption, leaving only data corruption...

Can it?-a Naively, I would have thought C was normally built on top >>>>>> of native assembler function calls, which dictates a shared stack. >>>>>> Obviously you could implement a function call independent of
assembler, but does anyone, in practice?

You simply use-a a register as a second stack [data] pointer.

Assign all your mem variables on that stack, and increment it at
function end.

The assembler is trivial. Making C do it that way would not be
hard, either..

-a-a I actually searched on that a little, could
-a-a not see any civil way to specify a stack in
-a-a a new segment in 'C'.

Oh sure. You would have to modify the compiler

-a-a Ah .... no problems then .......

But IIRC the first PDP I worked on had 64k data and 64k code in
entirely different bits of RAM.

-a-a Works.

-a-a Of course actual 'segments' are kind of
-a-a passe' these days - an olde-dayz artifact
-a-a everyone hated.

Isn't it all handled by a memory manager?

These days, yes.

Anyway, having to cope with those registers, which
weren't that wide way back, was a pain in the ass.
The 68000 looked like blue heaven by comparison.

-a-a ASM, yea, easier - you have total control (and
-a-a total responsibility).

Of course. That's what it teaches you....

-a-a Gen X/Y/Z/A2 "programmers" - have any EVER done
-a-a a thing in ASM ? Even microcontrollers are now
-a-a normally done in 'C' or MicroPython.

Precisely.

But at least inveterate tinkerers are leaning about things like response times...

My Picos will not output anything to the USB port for quite a few milliseconds after it has been initialised.

Hardware doesn't come up instantly. USB ports are
a sub-DEVICE and it has to be started and warmed
up so to speak and then takes x-time to get from
zero to sixty.

Dealing with flash memory on a uC is educational,
takes x-number of cycles before anything is actually
written so you can't really proceed with anything
using the data for a little while. 'sleep' delays
are the standard fix.

This prompted me to try ferroelectric memory, which
is much much faster. Built a dozen field-project
boards using that. Could save a bunch of relevant
vars and values into that mem more often without
slowing down the rest of the app.

Juts be patient and use the sleep function

The latter gens don't seem to understand the
underlying hardware very well. As fast as it
is these days that usually doesn't matter,
software complexity is what's dragging down
performance.

Bought a 'Pico starter kit' recently. Still in
the box. A Pico2w and some little dev boards and
jumper wires and what looks to be a super-tiny
LCD display of some kind. Gotta check to see if
I have a compatible power supply. Have the
instructions for adding the 'C' dev junk to
my system (and there's always MicroPython).

Also came across a "BreadVolt" - a 2-output
regulator with a tiny backup battery inside
to deal with brief power blinks - a teeny
weenie UPS :-)

Now for a not-quite-so-small I2C display ...

--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: comp.os.linux.misc

On 07/02/2026 21:31, c186282 wrote:

Bought a 'Pico starter kit' recently. Still in the box. A Pico2w and
some little dev boards and jumper wires and what looks to be a
super-tiny LCD display of some kind. Gotta check to see if I have a compatible power supply.

I think anything from 3 to 5.5V. Draws a couple of hundred mA max when shouting radio.

Have the instructions for adding the 'C' dev junk to my system (and
there's always MicroPython).

Took me a long time to figure out the C toolkit. And cmake.

Scream for help if you get stymied.
--
"Strange as it seems, no amount of learning can cure stupidity, and
higher education positively fortifies it."

- Stephen Vizinczey


--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: comp.os.linux.misc

On Sun, 8 Feb 2026 10:25:30 +0000, The Natural Philosopher wrote:

On 07/02/2026 21:31, c186282 wrote:

Bought a 'Pico starter kit' recently. Still in the box. A Pico2w and
some little dev boards and jumper wires and what looks to be a
super-tiny LCD display of some kind. Gotta check to see if I have a
compatible power supply.

Does the display look something like

amazon.com/dp/B0CDWXFCN2/

They're a little classier than the old two line LCDs, particularly the
ones that don't have the I2C module and need most of the GPIO lines.
--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: comp.os.linux.misc

On 2/8/26 05:25, The Natural Philosopher wrote:

On 07/02/2026 21:31, c186282 wrote:

Bought a 'Pico starter kit' recently. Still in the box. A Pico2w and
some little dev boards and jumper wires and what looks to be a
super-tiny LCD display of some kind. Gotta check to see if I have a
compatible power supply.

I think anything from 3 to 5.5V. Draws a couple of hundred mA max when shouting radio.

Have the instructions for adding the 'C' dev junk to my system (and
there's always MicroPython).

Took me a long time to figure out the C toolkit.-a And cmake.

Scream for help if you get stymied.

I'll see what the online docs can do for me, there
are a fair number, maybe they'll do it. Alas there
always seem to be weird syntax traps in some of
the utilities.

Would rather not use MicroPython and degrade the
performance.

This IS one place where the Arduino team has a
big advantage. Their IDE takes care of all that
twiddly background shit transparently, you just
compile and xfer. Pico has better/more performance
than most Ard products however, and for cheaper,
so it looks worth learning.

Now to find that perfect I2C video display. Looking
to make an all new weather center, so one PicoW out
of doors to gather the data and one indoors to
capture and display. I've done these before with
Ards, but none were doing wireless.

Yea, you can buy canned solutions cheap enough,
but where's the fun in that ? :-)

--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: comp.os.linux.misc

On Sun, 8 Feb 2026 22:39:06 -0500, c186282 wrote:

I'll see what the online docs can do for me, there are a fair number,
maybe they'll do it. Alas there always seem to be weird syntax traps
in some of the utilities.

I would suggest VS Code with the Raspberry Pi Pico extension.

https://vscodium.com/
https://github.com/microsoft/vscode

Codium and Code-OSS may not have some of the Microsoft extensions but you won't need that for the Pi. 'New C/C++ Project' will set up the build environment or you can select from the examples. It also handles
MicroPython projects. I haven't tried Rust or Zephyr.

If you expect to print to the console make sure you select 'Console over
USB'. If you miss it you can fix it in CMakeLists.txt. Make sure you
select the right board. Pico and Pico 2 aren't the same and the W variants require a different approach for the Blinky test.
--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: comp.os.linux.misc

On Fri, 6 Feb 2026 21:44:45 -0500
c186282 <c186282@nnada.net> wrote:

Gen X/Y/Z/A2 "programmers" - have any EVER done a thing in ASM ? Even microcontrollers are now normally done in 'C' or MicroPython.

Depends on the person - the urge to tinker will probably always drive
*some* folks to get hands-on with the bare metal. The retrogaming home-
brew community f'rinstance has a number of young or not-so-old folks
playing around with systems where assembly language is a practical
choice, if not the *only* choice.

(Though I have seen at least one homebrew NES game where some eccentric whippersnapper decided it'd be easier to get a 6502 LISP running and
write it in that!)

--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: comp.os.linux.misc

On Sat, 7 Feb 2026 16:31:24 -0500
c186282 <c186282@nnada.net> wrote:

This prompted me to try ferroelectric memory, which is much much
faster. Built a dozen field-project boards using that. Could save a
bunch of relevant vars and values into that mem more often without
slowing down the rest of the app.

Been meaning to poke around with that for ages. Obviously the intended application is as an alternative to flash memory for persistent storage
of firmware and/or settings, but it's interesting to consider a small
homebrew system where it's used as main memory, directly analogous to
core - free and indefinite-ish "suspend" with no battery drain!

(Volatility of main memory is such a baked-in assumption to every form
of computing post-mini era...of course mobile devices have had suspend/
resume for ages, but our OSes are still designed around the assumption
that the computer starts with a blank slate and every process starts by
getting loaded from disk. It'd be interesting to seriously re-examine
that way of thinking...)

--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: comp.os.linux.misc

On 2/9/26 13:04, John Ames wrote:

On Sat, 7 Feb 2026 16:31:24 -0500
c186282 <c186282@nnada.net> wrote:

This prompted me to try ferroelectric memory, which is much much
faster. Built a dozen field-project boards using that. Could save a
bunch of relevant vars and values into that mem more often without
slowing down the rest of the app.

Been meaning to poke around with that for ages. Obviously the intended application is as an alternative to flash memory for persistent storage
of firmware and/or settings, but it's interesting to consider a small homebrew system where it's used as main memory, directly analogous to
core - free and indefinite-ish "suspend" with no battery drain!

(Volatility of main memory is such a baked-in assumption to every form
of computing post-mini era...of course mobile devices have had suspend/ resume for ages, but our OSes are still designed around the assumption
that the computer starts with a blank slate and every process starts by getting loaded from disk. It'd be interesting to seriously re-examine
that way of thinking...)

Ferro is FAST.

Alas it's not 'dense' ... ie the chips don't hold THAT
much info in comparison to typical flash. I think you
can find 512kb ferro chips, and that's about it.

GREAT for lower-end/microcontroller/field devices.
But yer not gonna be buffering video frames.

Anyway, look on Mouser and DigiKey ... I2C examples
are most common but there do seem to be a few more,
maybe faster, options.

Could ferro BE 'dense' ? Maybe. However that takes
R&D money which may not exist.

--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: comp.os.linux.misc

On Mon, 9 Feb 2026 23:39:05 -0500
c186282 <c186282@nnada.net> wrote:

Alas it's not 'dense' ... ie the chips don't hold THAT much info in comparison to typical flash. I think you can find 512kb ferro chips,
and that's about it.

GREAT for lower-end/microcontroller/field devices. But yer not gonna
be buffering video frames.

Anyway, look on Mouser and DigiKey ... I2C examples are most common
but there do seem to be a few more, maybe faster, options.

Actually have a coupla parts hanging around, from the period where it
was new enough they'd hand out samples to anyone passing themselves off
as a researcher ;) Think I've got a meg or two of the second-generation
stuff (and another 64KB of first-gen, but the read/rewrite life on that
is specced an order or two of magnitude lower.)

Had the notion to use old cache SRAMs as a 1:1 write-through cache to
keep wear to a minimum; just haven't gotten around to *doing* it yet.
Well, oneathesedays...

--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: comp.os.linux.misc

On 2/10/26 11:00, John Ames wrote:

On Mon, 9 Feb 2026 23:39:05 -0500
c186282 <c186282@nnada.net> wrote:

Alas it's not 'dense' ... ie the chips don't hold THAT much info in
comparison to typical flash. I think you can find 512kb ferro chips,
and that's about it.

GREAT for lower-end/microcontroller/field devices. But yer not gonna
be buffering video frames.

Anyway, look on Mouser and DigiKey ... I2C examples are most common
but there do seem to be a few more, maybe faster, options.

Actually have a coupla parts hanging around, from the period where it
was new enough they'd hand out samples to anyone passing themselves off
as a researcher ;) Think I've got a meg or two of the second-generation
stuff (and another 64KB of first-gen, but the read/rewrite life on that
is specced an order or two of magnitude lower.)

Had the notion to use old cache SRAMs as a 1:1 write-through cache to
keep wear to a minimum; just haven't gotten around to *doing* it yet.
Well, oneathesedays...

Well, we all have Great Ideas ... but not enough
time/energy to actually implement :-)

I just bought a Pico2w "starter kit". Dunno if I
really NEED a Pico for anything but it does look
to be good cool tech so I'm gonna put in the
effort. Ards are also good, have used them for
many things and the IDE really makes stuff easier,
but they're not as zippy as a Pico and adding
wi-fi, or even wired networking, do NOT expect
any useful speed.

Oddly, I did make a very minimal web page - linked
to a reserve company domain - using a basic Ard
and wired-net add-on. Slow as shit, don't try to
move much, but DID get it to work for a few years
and even do some VERY rough character graphics.
Basically it showed a little page and a link to
the REAL web site. Not bad for the slow CPU and
very minimal mem !

One advert for Ards ... the 2560 esp ... the
low-power library works very well - makes it
easy to do solar-powered field projects with
just a 5W panel and lipo charger (Seeed !).

--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: comp.os.linux.misc

On Tue, 10 Feb 2026 23:02:15 -0500, c186282 wrote:

I just bought a Pico2w "starter kit". Dunno if I really NEED a Pico
for anything but it does look to be good cool tech so I'm gonna put
in the effort. Ards are also good, have used them for many things and
the IDE really makes stuff easier,
but they're not as zippy as a Pico and adding wi-fi, or even wired
networking, do NOT expect any useful speed.

If you haven't found them yet...

https://pip-assets.raspberrypi.com/categories/610-raspberry-pi-pico/ documents/RP-008276-DS-1-getting-started-with-pico.pdf?

https://pip-assets.raspberrypi.com/categories/609-microcontroller-boards/ documents/RP-009085-KB-1-raspberry-pi-pico-c-sdk.pdf

The first one describes setting up VS Code and the Pico extension. The
second gets into more detail. Beware the DHT-11 in the appendix. If you
want a temperature/humidity sensor get the DHT-20. The DHT-11 requires
very time sensitive bit-banging and the DHT-20 is I2C. The Arduino and MicroPython DHT-11 libraries work, the Pico C/C++ example code not so
much. I finally did find something that worked on github.

www.toptechboy.com has some decent videos. He digs into how the sensors
work and the math behind it rather than copypasta.
--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: comp.os.linux.misc

On Wed, 11 Feb 2026 20:22:32 -0500, c186282 wrote:

There have become a large selection of really sophisticated sensors
out there - multi-axis super-precise position/motion sensors, multi-
axis magnetometers with impressive sensitivity,
those kinds of things. They're aimed mostly at the mobile bot/drone
markets. The prices are impressively good now too. But they are SO
capable, SO many options, so many relevant factors, that you really
need a 'sensor nerd' to lay it all out in a comprehensible manner.

https://docs.arduino.cc/hardware/nano-33-ble-sense/

The Harvard TinyML series used these so I have a couple plus the expansion board to a camera for image recognition that was in their kit. Saves you a
lot of Dupont wires :)

https://www.adafruit.com/product/3333

I bought one of these 6 years ago and it was my introduction to
CircuitPython and ARM Cortex M0. Not a bad package to play with.
CircuitPython can be a little friendlier that MicroPython but the last
time I looked it didn't do interrupts. I don't think it has the decorator
that MircoPython uses to do the weird little GPIO assembler stuff either.

So many toys, so little time. I'm starting to miss the old toys though.
When you dig into the guts of the Pico 2's processor it gets gnarly. 4
cores, 2 ARM and 2 RISC-V plus all the wiring to bridge to the GPIOs. Lot
of registers with a lot of bits is you got deep into the C stuff.
--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: comp.os.linux.misc

On 2/11/26 23:48, rbowman wrote:

On Wed, 11 Feb 2026 20:22:32 -0500, c186282 wrote:

There have become a large selection of really sophisticated sensors
out there - multi-axis super-precise position/motion sensors, multi-
axis magnetometers with impressive sensitivity,
those kinds of things. They're aimed mostly at the mobile bot/drone
markets. The prices are impressively good now too. But they are SO
capable, SO many options, so many relevant factors, that you really
need a 'sensor nerd' to lay it all out in a comprehensible manner.

https://docs.arduino.cc/hardware/nano-33-ble-sense/

The Harvard TinyML series used these so I have a couple plus the expansion board to a camera for image recognition that was in their kit. Saves you a lot of Dupont wires :)

https://www.adafruit.com/product/3333

I bought one of these 6 years ago and it was my introduction to
CircuitPython and ARM Cortex M0. Not a bad package to play with. CircuitPython can be a little friendlier that MicroPython but the last
time I looked it didn't do interrupts. I don't think it has the decorator that MircoPython uses to do the weird little GPIO assembler stuff either.

Interrupts are very important for buttons and some
sensors ! Otherwise you have to waste vast CPU
*polling*.

So many toys, so little time. I'm starting to miss the old toys though.
When you dig into the guts of the Pico 2's processor it gets gnarly. 4
cores, 2 ARM and 2 RISC-V plus all the wiring to bridge to the GPIOs. Lot
of registers with a lot of bits is you got deep into the C stuff.

Yeek !

Oh well, I'll give it a try. Not an expensive
experiment, so what the hell ...

--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: comp.os.linux.misc

On 12/02/2026 06:04, c186282 wrote:

On 2/11/26 23:48, rbowman wrote:

On Wed, 11 Feb 2026 20:22:32 -0500, c186282 wrote:

-a-a-a There have become a large selection of really sophisticated sensors >>> -a-a-a out there - multi-axis super-precise position/motion sensors, multi- >>> -a-a-a axis magnetometers with impressive sensitivity,
-a-a-a those kinds of things. They're aimed mostly at the mobile bot/drone >>> -a-a-a markets. The prices are impressively good now too. But they are SO >>> -a-a-a capable, SO many options, so many relevant factors, that you really >>> -a-a-a need a 'sensor nerd' to lay it all out in a comprehensible manner. >>

https://docs.arduino.cc/hardware/nano-33-ble-sense/

The Harvard TinyML series used these so I have a couple plus the
expansion
board to a camera for image recognition that was in their kit. Saves
you a
lot of Dupont wires :)

https://www.adafruit.com/product/3333

I bought one of these 6 years ago and it was my introduction to
CircuitPython and ARM Cortex M0. Not a bad package to play with.
CircuitPython can be a little friendlier that MicroPython but the last
time I looked it didn't do interrupts. I don't think it has the decorator
that MircoPython uses to do the weird little GPIO assembler stuff either.

-a Interrupts are very important for buttons and some
-a sensors ! Otherwise you have to waste vast CPU
-a *polling*.

So many toys, so little time. I'm starting to miss the old toys though.
When you dig into the guts of the Pico 2's processor it gets gnarly. 4
cores, 2 ARM and 2 RISC-V plus all the wiring to bridge to the GPIOs. Lot
of registers with a lot of bits is you got deep into the C stuff.

-a Yeek !

-a Oh well, I'll give it a try. Not an expensive
-a experiment, so what the hell ...

Most of the above is hidden by the language libraries.
I had more trouble getting to grips with 'Cmake'

Most people who use a PIco, myself included, don't need anything like
its full power or memory..
One core and 32k RAM would be fine...
--
A lie can travel halfway around the world while the truth is putting on
its shoes.

--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: comp.os.linux.misc

On Thu, 12 Feb 2026 01:04:33 -0500, c186282 wrote:

Interrupts are very important for buttons and some sensors !
Otherwise you have to waste vast CPU *polling*.

It all depends. Interrupts add complexity. For many applications the CPU doesn't have anything better to do than poll.
--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: comp.os.linux.misc

On 2026-02-12, rbowman <bowman@montana.com> wrote:

On Thu, 12 Feb 2026 01:04:33 -0500, c186282 wrote:

Interrupts are very important for buttons and some sensors !
Otherwise you have to waste vast CPU *polling*.

It all depends. Interrupts add complexity. For many applications the CPU doesn't have anything better to do than poll.

I take a hybrid approach. I set a timer to wake me up
every so often, then poll everything once. If there's
no activity, I go back to sleep again.
--
/~\ Charlie Gibbs | Growth for the sake of
\ / <cgibbs@kltpzyxm.invalid> | growth is the ideology
X I'm really at ac.dekanfrus | of the cancer cell.
/ \ if you read it the right way. | -- Edward Abbey
--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: comp.os.linux.misc

On Fri, 13 Feb 2026 00:02:34 GMT, Charlie Gibbs wrote:

I take a hybrid approach. I set a timer to wake me up every so
often, then poll everything once. If there's no activity, I go back
to sleep again.

PythonrCOs asyncio support allows you to create concurrent coroutine
tasks that each do their own thing as they need to do it, without you
having to worry about managing the main event loop.
--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: comp.os.linux.misc

On 12/02/2026 21:36, rbowman wrote:

On Thu, 12 Feb 2026 01:04:33 -0500, c186282 wrote:

Interrupts are very important for buttons and some sensors !
Otherwise you have to waste vast CPU *polling*.

It all depends. Interrupts add complexity. For many applications the CPU doesn't have anything better to do than poll.

Exactly.
In many cases it is in essence the foreground task anyway - the
background data processing being done in real time under interrupts

Tale say audio processing. You are running processing code at 48KHz, and
its time critical.

Reading the buttons and knobs can be done far far slower
--
Climate Change: Socialism wearing a lab coat.

--- Synchronet 3.21b-Linux NewsLink 1.2