firmware

Clone Tools
  • last updated a few seconds ago
Constraints
Constraints: committers
 
Constraints: files
Constraints: dates
LEAHI-DD-FIRMWARE-LDT-3597_(DD) D5 Heater not turning on on B2.0 HW
LEAHI-DD-FIRMWARE-LDT-3597_(DD) D5 Heater not turning on on B2.0 HW
Since this driver is temporary, I don't think we need to document the approaches.

Since this driver is temporary, I don't think we need to document the approaches.

Doesn't look like this switch statement is doing anything. Can we remove it?

Doesn't look like this switch statement is doing anything. Can we remove it?

The Teensy driver is temporary - we will be deleting this driver in a few months. Let's just look for problems that might affect proper functionality.

The Teensy driver is temporary - we will be deleting this driver in a few months. Let's just look for problems that might affect proper functionality.

LDT-3219 removing D3 open in standby mode
LDT-3219 removing D3 open in standby mode
LEAHI-DD-FIRMWARE-LDT-3514_Dialin config request to disable IOFP current monitoring
LEAHI-DD-FIRMWARE-LDT-3514_Dialin config request to disable IOFP current monitoring
added

added

added

added

fixed.

fixed.

then we return false as expected

then we return false as expected

These are correct variable names based on their coefficient names in calculations of conductivity.

These are correct variable names based on their coefficient names in calculations of conductivity.

Can you clarify? this is allowing us to switch conductivity calculations based on the needs of the dialin user. ( systems team testing for accuracy )

Can you clarify? this is allowing us to switch conductivity calculations based on the needs of the dialin user. ( systems team testing for accuracy )

removed. thanks!

removed. thanks!

parameter check happens in getTeensyCondId

parameter check happens in getTeensyCondId

Yes as it is a way for us to identify if the teensy is not responding to us correctly. This along with no LED activity on the board helps us identify teensy failures

Yes as it is a way for us to identify if the teensy is not responding to us correctly. This along with no LED activity on the board helps us identify teensy failures

Not for this situation since its an array of structs and looks like a 2d array. Please see static const FP_OP_MODE_T MODE_TRANSITION_TABLE in FPOperationModes.c static const DD_OP_MODE_T MODE_TRAN...

Not for this situation since its an array of structs and looks like a 2d array. Please see

static const FP_OP_MODE_T MODE_TRANSITION_TABLE in FPOperationModes.c
static const DD_OP_MODE_T MODE_TRANSITION_TABLE in OperationModes.c
static PI_CONTROLLER_T piControllers in PIControllers.c ( FWCommon repo )

its unsigned integer , no need to check -ve value

its unsigned integer , no need to check -ve value

is this function required?

is this function required?

remove all commented code

remove all commented code

good to have doxygen comments on right hand side

good to have doxygen comments on right hand side

what if user send -ve values ?

what if user send -ve values ?

Where is len used ?

Where is len used ?

its a public function , input parameter check required, apply to all public functions

its a public function , input parameter check required, apply to all public functions

need documentation for this two approach, what is the merits ? when to use it ?

need documentation for this two approach, what is the merits ? when to use it ?