Controllers

Clone Tools
  • last updated a few seconds ago
Constraints
Constraints: committers
 
Constraints: files
Constraints: dates
Merged DEN-13834

DEN-13834 updated the FPGA persistent alarms

BatteryStatusData is also an input

BatteryStatusData is also an input

Add 2 blank lines before test support banner.

Add 2 blank lines before test support banner.

Remove extra blank lines. Should only be 1 here.

Remove extra blank lines. Should only be 1 here.

Cases should be pulled back one indent (4 spaces) to align with others.

Cases should be pulled back one indent (4 spaces) to align with others.

Add blank line after declaration.

Add blank line after declaration.

Sort of. You will get something between the ms specified and 1 ms less because you don't know where you are in a given ms when you get your start time. Recommend changing this to 2 ms timeout.

Sort of. You will get something between the ms specified and 1 ms less because you don't know where you are in a given ms when you get your start time.
Recommend changing this to 2 ms timeout.

Why not checking payload length?

Why not checking payload length?

Keep blank line.

Keep blank line.

These FPGA registers are obsolete - h/w is no longer in our design. Need to continue to maintain register space since registers after these have not moved. You can think of these obsolete registers...

These FPGA registers are obsolete - h/w is no longer in our design. Need to continue to maintain register space since registers after these have not moved. You can think of these obsolete registers as "reserved" for future purpose.
Dara, I do think we could rename these register fields to something like Reserved1, Reserved2, ...

Monitor execs should be before operation modes exec.

Monitor execs should be before operation modes exec.

Why was blank line removed?

Why was blank line removed?

Align "=".

Align "=".

Add another blank line here.

Add another blank line here.

Idea is to re-purpose these (instead of adding new alarms to bottom of enum). We prefer not to collapse the table when an alarm ID goes obsolete so other alarm IDs do not change.

Idea is to re-purpose these (instead of adding new alarms to bottom of enum). We prefer not to collapse the table when an alarm ID goes obsolete so other alarm IDs do not change.

Does didTimeout support a 1ms timeout?

Does didTimeout support a 1ms timeout?

What is the significance of (OBSOLETE)? Applies to several blocks.

What is the significance of (OBSOLETE)? Applies to several blocks.

Merge branch 'DEN-13903-s80-mg-DIAL-204' into develop

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.

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

  1. … 2 more files in changeset.
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.