hdfirmware

Clone Tools
  • last updated a few minutes ago
Constraints
Constraints: committers
 
Constraints: files
Constraints: dates
Merge branch 'DEN-13903-s80-mg-DIAL-204' into develop

    • -1
    • +1
    /firmware/App/Controllers/DialOutFlow.c
I think battery pack status, battery pack remaining capacity and charger status would be in a separate message sent by a separate "publish" function, but the timing would just be whenever any of th...

I think battery pack status, battery pack remaining capacity and charger status would be in a separate message sent by a separate "publish" function, but the timing would just be whenever any of the 3 registers (or the 3rd of the 3 if they are always next to each other in enum in same order) has been read (call publish function from the cases where we read one of the 3 registers). If you publish after reading any of the 3, you could sometimes get broadcast 250ms apart. If you publish after reading the last of the 3 in a group (i.e. the status_1, remaining_capacity_1, charger_status_1), the spacing of the broadcast will depend on how many enums are between them.

DEN-13903: DIAL-204: fixed DOP set PWM to not convert from PWM to ml/min twice.

    • -1
    • +1
    /firmware/App/Controllers/DialOutFlow.c
DEN-13903: Added fast flow rate for blood circ sub state within priming.

DEN-13834 updated the code with the latest FPGA persistent alarms

    • -6
    • +9
    /firmware/App/Controllers/DGInterface.c
    • -23
    • +12
    /firmware/App/Controllers/Fans.c
    • -91
    • +36
    /firmware/App/Controllers/PresOccl.c
    • -17
    • +9
    /firmware/App/Controllers/SyringePump.c
DEN-14001. Restored original method of retrieving battery pack and battery charger data. Only one value is read each time through the state. Some values are read more often.

    • -94
    • +119
    /firmware/App/Drivers/Battery.c
BatteryStatusData is an input.

BatteryStatusData is an input.

fpgaPersistentAlarmGroup is an input.

fpgaPersistentAlarmGroup is an input.

Are all available ALARM_IDs being removed?

Are all available ALARM_IDs being removed?

OK, I see what you wanted. I have a couple of questions: Is logging of the 3 values (remaining charge, battery status, charger status) in a separate message every 750 ms correct? If so, could that ...

OK, I see what you wanted. I have a couple of questions:
Is logging of the 3 values (remaining charge, battery status, charger status) in a separate message every 750 ms correct?
If so, could that be done by calling the publishBatteryStatusData function when the 3rd value (charger status) is read?

Restore alarm when done.

Restore alarm when done.

I think we should just be calling one function to do a single read at a time. If you try to read multiple times back-to-back, the bus reports busy and the read fails. I would keep call to getBatter...

I think we should just be calling one function to do a single read at a time. If you try to read multiple times back-to-back, the bus reports busy and the read fails. I would keep call to getBatteryManagementData() function with the large switch statement as it was with everything there and remove getBatteryStatusData() function altogether.

Keep multiple reads of remaining capacity and status in the switch as before.

Keep multiple reads of remaining capacity and status in the switch as before.

Keep read for battery charger status here before end of list.

Keep read for battery charger status here before end of list.

Dong fixed this.

Dong fixed this.

Need to save data to dataPtr so calling function gets the data.

Need to save data to dataPtr so calling function gets the data.

I think the enum from commit fbb6603 was fine as it was. I still think we should be doing only 1 read per 250ms interval and I think the one function with the large switch statement based on these ...

I think the enum from commit fbb6603 was fine as it was. I still think we should be doing only 1 read per 250ms interval and I think the one function with the large switch statement based on these enums was the way to achieve that - with the multiple status1..5 and remaining capacity1..5 enums spaced out to get them read more frequently.
And I think the individual cases for the higher frequency registers could just call the high frequency broadcast function whenever a new value is read for those registers. And so the slower broadcast could stay at end of list in that switch statement.

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

DEN-14000 Merge to develop.

    • -10
    • +16
    /firmware/App/Controllers/BloodFlow.c
    • -4
    • +26
    /firmware/App/Controllers/DialInFlow.c
    • -0
    • +1
    /firmware/App/Controllers/DialInFlow.h
    • -4
    • +2
    /firmware/App/Controllers/DialOutFlow.c
Update function header.

Update function header.

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

Merge branch 'DEN-13801-sw_dev-sprint-79_mg' into develop

Merge branch 'DEN-13903-sprint-80_mg_air_trap_optimization' into develop

DEN-13903: fixed fast rate not triggering during the purge air sub state.

Merge branch 'staging' into DEN-13903-sprint-80_mg_air_trap_optimization

DEN-13801: Fixed decay state failing with valid conditions. Loosened tolerances for Arterial and Venous pressure values during dry self pressurized state.

Merge branch 'staging' into DEN-13801-sw_dev-sprint-79_mg

    • -127
    • +53
    /firmware/App/Controllers/PresOccl.c
DEN-14001-hd-battery-driver-update. Made recommended changes in label naming. Split logging data into two groups--battery status data which is published more frequently, and battery manager data which is published less frequently.

    • -218
    • +218
    /firmware/App/Drivers/Battery.c
Do we want this checked into staging?

Do we want this checked into staging?

These are defined in the Code Composer project for DG and HD firmware respectively. You can only have one defined and you must have one defined.

These are defined in the Code Composer project for DG and HD firmware respectively. You can only have one defined and you must have one defined.