UProc Reset / Micro"Processors" vs Micro"Controllers"


Mont Pierce KM6WT
 

I didn't want to hi-jack Syd's thread, so moved this to a new topic.

First, before I forget, one comment on the ATmega328a Reset Pin.

Many microcontrollers have a reset pin.

The reset pin is often on a pin that is shared or could be configured for other purposes.
The ATmegaXXX family has a fuse setting which will disable the reset function of the pin so it can be used as a regular port pin.

What a microcontroller does on Reset varies depending on its Manufacturer's design .  Many ATmegaXXX circuits have this pin hardwired to VCC, as the option described in detail for the VFO/SigGen assembly manual page 7 (click here) and more details on page 12 (click here).

For the ATmegaXXX, if you want to be able to use the "In System Programming" feature, the Reset must be able to be pulled low by the Programmer plugged into the ISP port.

Another feature of the ATmegaXXX is it has a sleep mode, where everything can be shutdown to save battery power.  The Reset pin can be used to awaken it from sleep mode.  (Many microcontrollers have this feature).

In the VFO/SigGen assembly manual, Hans describes the "8) Optional In-circuit programming header" (same as ISP port) on page 9 (click here).   If you install a 2x3 header (as shown in the picture) and a 100K resistor at R3, then you can program or update your VFO's firmware in place.  (also detailed on page 12)

And, finally, for most (all?) of the QL Kits with  the ATmega328 processor, this is the MAIN use of the Reset pin, i.e. to enable the use of the 2x3 header for In-circuit Programming (aka In-System Programming, or ISP for short). 


On Fri, Sep 24, 2021 at 11:39 AM, Arv Evans wrote:
When things go badly...REBOOT sounds like earlier versions of Microsoft
Windows.  There are UNIX and Linux systems out there that have not been
rebooted for years. 
This reminds me of a VCR I owned years ago.  Every few months, it would just Hang.  I swear, it must of had an Embedded MS Windows operating system.  I would have to unplug it to totally power off, let rest for 10-20 minutes, and plug it back in.  Afterwards it would run fine for another few months... and I'd have to repeat the unplug power off sequence.

What this does bring to mind is that with a little bit of free memory it might
be possible to add some self test routines to the startup or run-once part
of microcontroller code so that the bootup self-tests provided indications
of the state of hardware and software during a boot process.  This could
probably be turned on and off via a word in EEPROM (make it a number
so that the value could control the level of test or debug during the next
bootup).
 
On the avr or Arduino system a reset is activated during power-up by
having a capacitor to ground and a 10K to +5V on the RESET pin.  The
cap holds the reset lead close to ground for long enough to effect a
boot (JMP to memory address Zero), while the 10K charges the capacitor
to +5V and holds it there after the reboot has occurred. 
 
What would we want included in a talkative reboot/reset process?  Well,
maybe some basic things like power supply voltage check (displayed or
just a minimum and maximum and light a red LED if out of range. 
Network connection might be interesting to know.  Confirmation of date
and time from an RTC, and other hardware interface confirmations?
 
Lots of possibilities if one wants to add boot time information like the old
Microsoft systems provided. 

A micro"Processor" and a micro"Controller" live in two very different worlds.

A microprocessor, as used in full blown "general" purpose computers like the PC on your desk, has a myriad of optional additional hardware peripheral devices.  At boot up, there are certain peripherals it needs and expects, but for the most part the "boot up" code has to search it's environments to "discover" what's available.  And it loads drivers to communicate with the attached peripherals, and usually runs some diagnostics to make sure these attached peripherals are functioning as expected.

There are several boot steps the processor runs through before finally being ready to be used by a user for an infinite number of various tasks.


The "world" of a microcontroller is Very Different.  There are myriads of variations of microcontrollers for any purpose you can think of under the sun (and beyond). 

The microcontroller usually has many of it's needed peripherals Built In.  And the programmer of a microcontroller already knows the environment the code will be running in, i.e. how much internal ram is available, internal program space available, what port pins are available and if they have internal optional purposes, etc.  It's already a known environment, doesn't have to be "discovered". 

Practically any device you have now has some kind of microcontroller taking the place of what used to be implemented in complex circuits of discreet components.  From  your TV, to the TV Remote, to the Microwave Oven, to the DVD player, and on and on.

Every general purpose full blown personal computer also has many components in the case that have their own specific purpose microcontroller.  The Keyboard has it's own microcontroller, the disk drive, and every card plugged into the PC bus, each one has it's own special purpose or programmed microcontroller to perform it's specific tasks.


Many microcontrollers are design for physical size limitations, manufacturing cost savings, and many many more considerations.

When designing a device, the design engineer has available many choices.  One is what is the minimum capability needed in a microcontroller to perform the task at hand.  This option greatly reduces the cost of the product being engineered, which can influence whether this product will be a success or failure in a very competitive market place...

As a hobbyist, we often will choose a microcontroller by familiarity, features that will exceed our future requirements or at least one that is part of a family of microcontrollers with same/greater features (i.e. least code change, etc).


Anyways, this is just a very small glimpse of the Two Very Different worlds of MicroProcessor VS MicroController...

So, have at it everyone...  let the comments (flames?  hope not...) begin...


Or better yet:  Google   "microcontroller vs microprocessor"   for your own mind blowing edification.   :)  :)


73
km6wt


wa8yan.radio
 

Hi Mont.  Enjoyed reading about microprocessors vs microcontrollers.  I learned just enough to know (again) that I know very little, but really enjoyed reading what you had to say.  This is one of the messages on this group that I will definitely keep for the day i know more than i do now.... if that day ever comes !  Thanks
73 Phil WA8YAN



Sent from my Verizon, Samsung Galaxy smartphone


-------- Original message --------
From: Mont Pierce KM6WT <de.km6wt@...>
Date: 9/25/21 11:40 AM (GMT-05:00)
To: QRPLabs@groups.io
Subject: [QRPLabs] UProc Reset / Micro"Processors" vs Micro"Controllers"

I didn't want to hi-jack Syd's thread, so moved this to a new topic.

First, before I forget, one comment on the ATmega328a Reset Pin.

Many microcontrollers have a reset pin.

The reset pin is often on a pin that is shared or could be configured for other purposes.
The ATmegaXXX family has a fuse setting which will disable the reset function of the pin so it can be used as a regular port pin.

What a microcontroller does on Reset varies depending on its Manufacturer's design .  Many ATmegaXXX circuits have this pin hardwired to VCC, as the option described in detail for the VFO/SigGen assembly manual page 7 (click here) and more details on page 12 (click here).

For the ATmegaXXX, if you want to be able to use the "In System Programming" feature, the Reset must be able to be pulled low by the Programmer plugged into the ISP port.

Another feature of the ATmegaXXX is it has a sleep mode, where everything can be shutdown to save battery power.  The Reset pin can be used to awaken it from sleep mode.  (Many microcontrollers have this feature).

In the VFO/SigGen assembly manual, Hans describes the "8) Optional In-circuit programming header" (same as ISP port) on page 9 (click here).   If you install a 2x3 header (as shown in the picture) and a 100K resistor at R3, then you can program or update your VFO's firmware in place.  (also detailed on page 12)

And, finally, for most (all?) of the QL Kits with  the ATmega328 processor, this is the MAIN use of the Reset pin, i.e. to enable the use of the 2x3 header for In-circuit Programming (aka In-System Programming, or ISP for short). 


On Fri, Sep 24, 2021 at 11:39 AM, Arv Evans wrote:
When things go badly...REBOOT sounds like earlier versions of Microsoft
Windows.  There are UNIX and Linux systems out there that have not been
rebooted for years. 
This reminds me of a VCR I owned years ago.  Every few months, it would just Hang.  I swear, it must of had an Embedded MS Windows operating system.  I would have to unplug it to totally power off, let rest for 10-20 minutes, and plug it back in.  Afterwards it would run fine for another few months... and I'd have to repeat the unplug power off sequence.

What this does bring to mind is that with a little bit of free memory it might
be possible to add some self test routines to the startup or run-once part
of microcontroller code so that the bootup self-tests provided indications
of the state of hardware and software during a boot process.  This could
probably be turned on and off via a word in EEPROM (make it a number
so that the value could control the level of test or debug during the next
bootup).
 
On the avr or Arduino system a reset is activated during power-up by
having a capacitor to ground and a 10K to +5V on the RESET pin.  The
cap holds the reset lead close to ground for long enough to effect a
boot (JMP to memory address Zero), while the 10K charges the capacitor
to +5V and holds it there after the reboot has occurred. 
 
What would we want included in a talkative reboot/reset process?  Well,
maybe some basic things like power supply voltage check (displayed or
just a minimum and maximum and light a red LED if out of range. 
Network connection might be interesting to know.  Confirmation of date
and time from an RTC, and other hardware interface confirmations?
 
Lots of possibilities if one wants to add boot time information like the old
Microsoft systems provided. 

A micro"Processor" and a micro"Controller" live in two very different worlds.

A microprocessor, as used in full blown "general" purpose computers like the PC on your desk, has a myriad of optional additional hardware peripheral devices.  At boot up, there are certain peripherals it needs and expects, but for the most part the "boot up" code has to search it's environments to "discover" what's available.  And it loads drivers to communicate with the attached peripherals, and usually runs some diagnostics to make sure these attached peripherals are functioning as expected.

There are several boot steps the processor runs through before finally being ready to be used by a user for an infinite number of various tasks.


The "world" of a microcontroller is Very Different.  There are myriads of variations of microcontrollers for any purpose you can think of under the sun (and beyond). 

The microcontroller usually has many of it's needed peripherals Built In.  And the programmer of a microcontroller already knows the environment the code will be running in, i.e. how much internal ram is available, internal program space available, what port pins are available and if they have internal optional purposes, etc.  It's already a known environment, doesn't have to be "discovered". 

Practically any device you have now has some kind of microcontroller taking the place of what used to be implemented in complex circuits of discreet components.  From  your TV, to the TV Remote, to the Microwave Oven, to the DVD player, and on and on.

Every general purpose full blown personal computer also has many components in the case that have their own specific purpose microcontroller.  The Keyboard has it's own microcontroller, the disk drive, and every card plugged into the PC bus, each one has it's own special purpose or programmed microcontroller to perform it's specific tasks.


Many microcontrollers are design for physical size limitations, manufacturing cost savings, and many many more considerations.

When designing a device, the design engineer has available many choices.  One is what is the minimum capability needed in a microcontroller to perform the task at hand.  This option greatly reduces the cost of the product being engineered, which can influence whether this product will be a success or failure in a very competitive market place...

As a hobbyist, we often will choose a microcontroller by familiarity, features that will exceed our future requirements or at least one that is part of a family of microcontrollers with same/greater features (i.e. least code change, etc).


Anyways, this is just a very small glimpse of the Two Very Different worlds of MicroProcessor VS MicroController...

So, have at it everyone...  let the comments (flames?  hope not...) begin...


Or better yet:  Google   "microcontroller vs microprocessor"   for your own mind blowing edification.   :)  :)


73
km6wt


Rob Giuliano
 

Good commentary.
I will add something that fits along the original thread:
   "... Since I will want to do a UProc reset to get back to the diagnostic mode, ..."
In a sense, the expectation was that shoringt the RESET pin to ground to get back to the "factory settings" and get back to "Diagnostic Mode".

Neither the RESET pin on a microcontroller, nor the reboot sequence of a microprocessor (as in PC) should take your system back to a "factory reset".

For a computer, this would mean uninstalling all of the users applications on the hard drive that were not installed at the factory.
   Can you image if Microsoft or motherboard manufacturers ever decided to reset to factory settings with a <Ctrl><Alt><Del>?
For the microcontroller, this would be clearing EEPROM and setting the bit for (what I will call) initial startup.

Hans' has a menu item to do that, in the same way your PC has ways of factory resetting to a known state - typcially on a separate hard drive partition.
Once you have started to configure the device, you probably don't really want to go back to "factory settings", except under certain conditions.




--
Rob KB8RCO


 

Exactly right.
Some consumer devices with embedded microcontrollers have a special purpose "reset" button which, if held for some number of seconds, initiates some form of "return to factory configuration", but that is vastly more than simply resetting the microprocessor/microcontroller which "merely" restarts code execution at the reset vector, which is the same vector that is used at power-on.

As Mont correctly says, microcontrollers have built-in peripherals which have their own control and configuration registers, and those built-in devices are returned to a default state by activation of the processor reset input too (again, different from the multi-function pin on many devices). Peripheral devices in a microprocessor based device such as a personal computer may or may not share access to the processor reset line, so it may be up to the processor to properly configure those devices and bring them to a known operating state.

As Rob says, the "return to factory configuration" - or "ground zero reset" as one might call it in Hans' QCX products is a very non-accidentally triggerable menu item.
--
Julian, N4JO.