-
Notifications
You must be signed in to change notification settings - Fork 4
Firmware Overview
This page contains information on the overall architecture and themes of the official firmware. Basic information about the subsystems is presented here as well.
Ehm, poor.
- The firmware is a massive knot of globals, timers, and complexity.
- Hardware is always accessed through the STM32 HAL.
- The official STM32 FAT middleware is used to access the SD card.
- TIM2 is the major source of forward progress. The interrupt routine sets flags when various timers expire, which are then acted on by the main loop.
- The HY3131's interrupts are checked and acted upon every main loop. It's the only other source of forward progress.
The HAL source code is most easily obtained through STM32CubeMX, by setting up a project with the meter's chip and configuring the peripherals appropriately. From there, it's fairly easy to match routines in the source to those in the disassembly. This is useful when figuring out how hardware is used, though important ones should have already been annotated.
After control is transferred to the firmware by the bootloader and the very basics are initialized, the real firmware begins at main_loop(). After most of the hardware and state is initialized, a boot main loop is entered in finish_sys_init_and_handle_boot_buttons(). This handles reading the buttons to e.g. enter calibration mode and sets various flags appropriately. Once finished, the main loop begins.
The main loop handles the meter's four major subsystems. The first and most important is measurement and display, along with the second one, calibration. The third is Bluetooth, and the fourth is logging.
While there are too many particulars to list here, the basic measurement flow is as follows.
- The HY3131 signals an interrupt that a new measurement is available.
- The main loop checks the interrupt flag and notices this. It then calls a specific processor depending on the interrupt and mode.
- The processor uses the new measurement to update the bargraph, and also averages 16 measurements to generate the display value.
- The processor applies offset and gain calibration to the display value, applies a further rolling average filter, stores it in a display variable, then sets a flag that a new measurement was made.
- The main loop notices the new measurement and applies its own processing based on the display value, such as min/max and autoranging.
- The display updater notices that a new display value is available and writes it to the display.
The meter applies basic calibration to all modes and ranges, though some values are shared. Basic calibration consists of a zero offset and full-scale gain value that is applied to the screen digits directly. The power ranges have two separate pairs of factors for their current and voltage ranges, and the AC current and voltage ranges have additional factors for applying a frequency-dependent offset correction. There are also standalone calibration factors for the internal thermistor, the 50M range, and the frequency range.
The Bluetooth addition is pretty simple. The PC or phone connecting to the meter can send two types of message: a new date and time to change the meter to, or a button press/hold. If it's time to send a Bluetooth packet, the current meter state is packed up and transmitted.
Logging is somewhat less simple. Periodically, a new sample is 'prepared' by packing the current meter state and saving it in RAM. Once the logging interval has elapsed, the most recently prepared sample is written to EEPROM. Once 60 samples have been saved in EEPROM (or logging has ended for any reason besides SD failure), the samples are read from EEPROM and written out as CSV to the SD card.
The only functionality storing samples in EEPROM (as opposed to RAM) has given the firmware is (seemingly) the ability to play back the last 60 samples of the most recent logging session even after the meter has been restarted. Other than that, it's damaging to the ROM and probably pretty power-hungry. Why did they do it this way?