This is an energy meter reference design guide I found in microchip's website. In a microcontroller how come the registers are specific to the project?Please explain.
3 answers
You are accessing this answer with a direct link, so it's being shown above all other answers regardless of its score. You can return to the normal view.
Calling those "registers" might be technically correct, but rather misleading in my opinion. These are really RAM locations. Probably for historical reasons, Microchip refers to RAM bytes in some of its microcontrollers as "registers" sometimes.
Change "Complete Register List" to "Complete Variables List", and "Register Name" to "Variable Name", and I think the confusion disappears. It should also be obvious in another way that these are not registers with specific hardware meaning, because those are all in bank 15. Since the addresses are explicitly given, we can see these variables are all in Bank 0.
They aren't specific to the project, but to the MCU. As long as you use the same MCU for multiple projects, they will be code compatible. Some hardware peripherals are even code compatible between different MCU families by the same manufacturer.
Generally, registers are different in each and every MCU because:
-
No standardization exists. Each company design their hardware as they like, with no consensus or standardization. (Or rationale, for that matter...)
-
Different hardware requires different registers. And a newer version of the hardware by the same manufacturer is not necessarily backwards-compatible.
Take a timer hardware peripheral as one example: there's so many different features that such hardware could have, from case to case. Input capture, synchronized outputs, PWM abilities, external triggers, down counters, different resolution, numerous different clock sources etc etc.
-
Marketing reasons. Different manufacturers compete by providing the best peripherals. This is especially true since ARM Cortex became industry de-facto standard - those who make ARM CPUs can no longer compete over having the best core, so having the best hardware peripherals have become more important.
-
Core data bandwidth. It makes sense to provide 8 bit registers for a 8 bit MCU, but for a 32 bit MCU it might be more convenient to make them 32 bit. So the register width could be changed for this purpose, no matter what the underlying hardware actually requires.
0 comment threads
While the terminology is similar to that of microcontrollers, and of CPUs in general, the "register" term here is specific to energy meters. Essentially, this board is a very basic version of a smart electric meter. The "register" term has been used for many years in Modbus (which is used for all sorts of devices, not just electric meters) and similar embedded/process control environments.
There is a lot that goes on behind the scenes to populate the registers - these are not your standard 8/16/32/64-bit CPU registers. They may be implemented in RAM, but often (I don't know about this specific implementation) also in Flash or other non-volatile memory to allow for remembering data past a power cycle. The registers often have a quirky mix of:
- Static data - e.g., METER_VERSION_ID - can't be changed by normal programs.
- Status - e.g., METER_STATUS - typically a bunch of boolean bit fields thrown together, sometimes read-only, sometimes read-write
- Instantaneous values - e.g., FREQUENCY - updated every 'n'th of a second.
- Accumulated ("totalizer") values - not sure if there are any in the page shown in the question, but typically total kWh.
- Configuration values - sometimes read-only, sometimes read-write
- History - this is all over the place - some meters have a rolling block (register 0 = most recent, register 1 = 15 minutes prior, etc.) others have a 2-step process - write to one register to say "I want history 'x'" and then read another register to get the values, etc. And many other variants.
Source: Personal experience with GE, ION and many other smart meters. Most with incomplete/inconsistent documentation.
0 comment threads
0 comment threads