Re: "RESET"

On 5/25/2025 1:01 AM, Ian wrote:

Ususally the "reset" button is really "factory reset", which is intended
to revert persistent state back to know values. A typical use for this,
that absolutely must not be done on a power cycle, is setting a login
password to a known value ("1234", or some more secure unique string
printed on a label if the designer is sensible).

That's a user-interface function.  Just like any other key/button.
Pressing it ONLY works when the product is behaving properly-enough
to understand that UI aspect.  A "crashed" program would likely
not see that as the event intended.
I'm talking about something that literally resets the processor.

As a convenience (for who?), a quick press of the reset button usually
just does a POR, and you need to hold the button for some length of time
to reset the configuration. I think this has just become a convention
that every device seems to follow.

But, that still resets the processor.  Encoding the desire to "reset to
factory defaults" in the time domain (i.e., examine the button N seconds
after RESET to determine if you should ALSO reset the defaults) relies
on having first RESET the CPU.
Resetting defaults can happen without the need for a CPU reset.

Yes, a lot of complex devices that really should be able to run forever
sometimes can't, and lock up. I blame lack of understanding of the whole
system by the programmers (and it is usually software that is at fault,
rarely the hardware). It's going to get worse with completely clueless
people throwing together something that barely works with the help of
automated idiots.

I see more and more cases of hardware that isn't up to the task.
No mechanisms for reporting memory errors to the software, spurious
interrupts, glitchy power supplies, etc.
As software gets more complex -- and people naively embrace "undocumented
SOFTWARE components" ("What's this big chip that takes up most of the design?
Do we have a detailed datasheet for it?") for which they have scant
concrete data and little first hand expertise -- there are more opportunities
for "gee, I didn't realize that could happen!"

I write microcontroller code in assembler that runs 24x7x365x∞ (that's
"infinity", for the UTF8-challenged :)

I stopped writing in ASM when my projects got to 250KB binaries.
It's just too hard for others to follow along at that level of
complexity.
But, it's relatively easy to write code that WILL run 24/7/365 -- if
the hardware cooperates.  Sad as hardware is so easy/inexpensive to change
yet the burden always falls on the software.  (look at the DM+DL of a
product.  how many developer hours would that pay for?  multiply by the
number of units sold.  Wouldn't it be cheaper to just replace the hardware
than pay someone man-months to change the software??)