RLaxmanrao
commented
4 years ago @ethanjli Created following methods for Power module, Power module consist of two classes one is LTC4421 for power path control and Battery class related to charge control. In LTC4421 class contains LTC4421::readPwrSource method to read active power source in ventilator which will report external or internal or no power source. LTC4421::fault method will report related to power. In Battery Battery::readVoltage method to read Battery voltage by converting ADC samples to Battery voltage. BatteryVoltage = 4.2(TBD) 3.3 inputvoltage / 65536. Here 4.2 is offset value which will give battery voltage rage 0V to 13.8V. Battery::enBatteryCharge method for enabling and disabling Battery charger.
Regarding battery charge levels are depending on the soc pct, so it's better will send below structure to the UART for UI. struct Profile { float batteryVoltage; float batteryTemperature; float soc_pct; bool socMaximum; bool socMedium; bool socLow; bool socCritical; };
ethanjli
deepakkrishnamurthy
We would like to write a lower-level driver for the power management system. This will just be a thin layer which abstracts away the details of GPIO read/write calls and exposes an interface for higher layers operating at the level of measurements and signals. This lower-level driver will need to provide a somewhat abstracted interface for all microcontroller pins assigned to power management functionalities. This abstracted interface will be used by a higher-level power management driver (which will be written after this low-level driver is written) for telemetry, monitoring, and control of the power management electronics. Some examples of what the interface of this lower-level will need to provide:
The implementation of this driver should mostly just be making calls using classes from
firmware/ventilator-controller-stm32/Core/Inc/Pufferfish/HAL/STM32/DigitalInput.handfirmware/ventilator-controller-stm32/Core/Inc/Pufferfish/HAL/STM32/DigitalOutput.h, and, once #21 is completed,firmware/ventilator-controller-stm32/Core/Inc/Pufferfish/HAL/STM32/AnalogInput.h. I would suggest implementing this lower-level driver as one or more classes, each corresponding to some aspect of the power management electronics.This lower-level driver can be prototyped before @RLaxmanrao and @deepakkrishnamurthy have finished putting together a set of design specifications for the firmware's complete power management functionality from the regulatory requirements for the power management subsystems. We can have someone start prototyping immediately based on the above list of examples and some additional documentation - @deepakkrishnamurthy, could you please post links to the various pieces of documentation on this thread?
The first step will be for someone to review our meeting notes and the documentation which @deepakkrishnamurthy will post; then ask questions for clarification about the task described here and about the documentation; and then make a pull request with a proposed interface and implementation for this lower-level driver.