firmware

Clone Tools
  • last updated a few seconds ago
Constraints
Constraints: committers
 
Constraints: files
Constraints: dates
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?

I recommend to explicitly name the input and output variables.

I recommend to explicitly name the input and output variables.

Reverse the order of the condition.

Reverse the order of the condition.

Why do you need an else here to zero the counter? Do you not need to 0 it anyways?

Why do you need an else here to zero the counter? Do you not need to 0 it anyways?

HD-DEN-8679_HD Dev Treatment Log
HD-DEN-8679_HD Dev Treatment Log
RESOLVED in CODE WALKTHROUGH.

RESOLVED in CODE WALKTHROUGH.

RESOLVED in CODE WALKTHROUGH.

RESOLVED in CODE WALKTHROUGH.

RESOLVED in CODE WALKTHROUGH.

RESOLVED in CODE WALKTHROUGH.

RESOLVED in CODE WALKTHROUGH.

RESOLVED in CODE WALKTHROUGH.

RESOLVED in CODE WALKTHROUGH.

RESOLVED in CODE WALKTHROUGH.

RESOLVED in CODE WALKTHROUGH.

RESOLVED in CODE WALKTHROUGH.

I will address this comment in DEN-9054 (switches) branch.

I will address this comment in DEN-9054 (switches) branch.

Done

Done