dgfirmware

Clone Tools
  • last updated a few seconds ago
Constraints
Constraints: committers
 
Constraints: files
Constraints: dates
Merge branch 'DEN-13946-certain-temperature-sensors-trigger-wrong-alarm' into staging

Bamboo Commit: Updated DGCommon.h with build versions from Bamboo

Merge branch 'DEN-13676-bicarb-low-alarm-threshold-incorrect' into develop

Bamboo Commit: Updated DGCommon.h with build versions from Bamboo

Merge branch 'DEN-13946-certain-temperature-sensors-trigger-wrong-alarm' into develop

    • -24
    • +24
    /firmware/App/Controllers/LoadCell.c
Bamboo Commit: Updated DGCommon.h with build versions from Bamboo

RESOLVED IN CODE WALKTHROUGH

RESOLVED IN CODE WALKTHROUGH

RESOLVED in CODE WALKTHROUGH.

RESOLVED in CODE WALKTHROUGH.

RESOLVED IN CODE WALKTHROUGH

RESOLVED IN CODE WALKTHROUGH

DEN-13946 Code review correction

    • -6
    • +1
    /firmware/App/Controllers/Thermistors.c
Seems like there are several variables missing.

Seems like there are several variables missing.

DG-DEN-14604_DG HD Dev HD DG Dvt Update Part 9
DG-DEN-14604_DG HD Dev HD DG Dvt Update Part 9
Updated comment

Updated comment

Removed

Removed

DEN-13676 Correction per code review

DEN-13946 Corrections per code review

    • -4
    • +4
    /firmware/App/Controllers/Thermistors.c
    • -4
    • +5
    /firmware/App/Controllers/Thermistors.h
This looks strange. Why is TD2 temp usually 0.0, but read if using TPo?

This looks strange. Why is TD2 temp usually 0.0, but read if using TPo?

Prefer doing this kind of thing with a loop iterating through the enum in case we add/remove a reservoir.

Prefer doing this kind of thing with a loop iterating through the enum in case we add/remove a reservoir.

Does hasAlarmBeenTriggered need to be set here too? If not, need to clarify what that flag really means.

Does hasAlarmBeenTriggered need to be set here too? If not, need to clarify what that flag really means.

Need to be careful with these. These functions are currently resetting the POST functions to start at beginning, but also need to reset ANY variables that the POST functions use/set (not override v...

Need to be careful with these.
These functions are currently resetting the POST functions to start at beginning, but also need to reset ANY variables that the POST functions use/set (not override variables though).
Also, since we are not re-initializing everything like a true reset does, we need to make sure that these modules are setup to restart or resume (whichever is more appropriate for the module) after POST completes if the module is in any way interrupted/deferred by POST or competing with POST for a resource/driver (e.g. RTC or NV-Data).

Variable should already be a BOOL.

Variable should already be a BOOL.

Set to TRUE here.

Set to TRUE here.

Initialize to FALSE.

Initialize to FALSE.

Rename to isDGFaultActive.

Rename to isDGFaultActive.