hdfirmware

Clone Tools
  • last updated a few seconds ago
Constraints
Constraints: committers
 
Constraints: files
Constraints: dates
Sent events only for changed settings.

Sent events only for changed settings.

Set UF volume initially to 0 and removed this variable and related function.

Set UF volume initially to 0 and removed this variable and related function.

It is part of background task in the battery monitor exec function. The initial value is 0, we will wait here till we get status.

It is part of background task in the battery monitor exec function. The initial value is 0, we will wait here till we get status.

Done. I prefer generally output description, so refactor is easier. Normally, a refactor will often make these variables in the doxygen comment obsolete (variable name change).

Done. I prefer generally output description, so refactor is easier. Normally, a refactor will often make these variables in the doxygen comment obsolete (variable name change).

Dara Navaei Please take a look.

Dara Navaei Please take a look.

This message is requested by UI. UI wants to keep it consistent with other request message, in case there is reject reason in the future.

This message is requested by UI. UI wants to keep it consistent with other request message, in case there is reject reason in the future.

Removed.

Removed.

If fault mode calls the treatment log data collect function, the record can be zeroed also.

If fault mode calls the treatment log data collect function, the record can be zeroed also.

The transition function will call this init function.

The transition function will call this init function.

Done.

Done.

Fixed.

Fixed.

Fixed.

Fixed.

Done.

Done.

The else is when AC power detected. Added clear alarm condition.

The else is when AC power detected. Added clear alarm condition.

Seems like the two states given as data are not very meaningful. Consider just setting before/after data to zero for this event.

Seems like the two states given as data are not very meaningful. Consider just setting before/after data to zero for this event.

Not sure this variable (and related get function) are needed.

Not sure this variable (and related get function) are needed.

User may not have changed all 4 settings. Should we only send events for those that actually changed?

User may not have changed all 4 settings. Should we only send events for those that actually changed?

I think this will be the time we initiate a treatment. Is that what we want? Or should we move this to transition function to capture time of treatment start?

I think this will be the time we initiate a treatment. Is that what we want? Or should we move this to transition function to capture time of treatment start?

Are there ever any reject reasons? Is this message requested by UI or sent unsolicited when ready?

Are there ever any reject reasons? Is this message requested by UI or sent unsolicited when ready?

I think we set UF volume to zero in TreatmentParams mode, so this condition should not be necessary.

I think we set UF volume to zero in TreatmentParams mode, so this condition should not be necessary.

Why not zero record here? I see it is zeroed just prior to creation at end of treatment, but that means this record may have prior treatment's data until current treatment is over.

Why not zero record here? I see it is zeroed just prior to creation at end of treatment, but that means this record may have prior treatment's data until current treatment is over.

If typical h/w response is very quick (e.g. < 1ms) and worst case is still pretty quick (e.g. < 5ms), then I think this is ok with the t/o there to prevent getting stuck in loop forever. Also, batt...

If typical h/w response is very quick (e.g. < 1ms) and worst case is still pretty quick (e.g. < 5ms), then I think this is ok with the t/o there to prevent getting stuck in loop forever.
Also, battery monitor is called from background task so we can be a little more relaxed about this.

Why would we zero it when no AC detected?

Why would we zero it when no AC detected?

Why are DG definitions in HDDefs.h? If needed by both stacks, should we create a FWDefs.h common to both f/w stacks?

Why are DG definitions in HDDefs.h? If needed by both stacks, should we create a FWDefs.h common to both f/w stacks?

HD-DEN-9054_DG HD Switches
HD-DEN-9054_DG HD Switches
Does the payload length does not match with the payload? In the payload, you have 1 U32 and 2 F32s so should not the length be U32 + 2 * F32?

Does the payload length does not match with the payload? In the payload, you have 1 U32 and 2 F32s so should not the length be U32 + 2 * F32?

Do we not need a battery remaining percent override function for testing?

Do we not need a battery remaining percent override function for testing?

The name of the function does not match with the actual name.

The name of the function does not match with the actual name.

Is it safe to stay in while loop until the hardware responds? I understand that you have a timeout but I thought we still should not do that.

Is it safe to stay in while loop until the hardware responds? I understand that you have a timeout but I thought we still should not do that.

How do you get the status of the battery charge in the self test before you check the whether it is in range?

How do you get the status of the battery charge in the self test before you check the whether it is in range?