AlarmMgmtSWFaults.h

Clone Tools
  • last updated a few minutes ago
Constraints
Constraints: committers
 
Constraints: files
Constraints: dates
Remove extra blank line.

Remove extra blank line.

Should we create a structure for these moving average filters and make an array of them based on enum of temp sensors? It looks kind of messy having separate handling for each sensor - can we conso...

Should we create a structure for these moving average filters and make an array of them based on enum of temp sensors?
It looks kind of messy having separate handling for each sensor - can we consolidate some of this code?

Should we maybe just have a constant array of sample counts based on enum of temp sensors?

Should we maybe just have a constant array of sample counts based on enum of temp sensors?

Should min and max be properties of the controller instead of global (assumes all controllers will want same min/max)? Controller properties already include a min and max field - can we use those?

Should min and max be properties of the controller instead of global (assumes all controllers will want same min/max)?
Controller properties already include a min and max field - can we use those?

Remove blank line.

Remove blank line.

Done.

Done.

Done.

Done.

mis aligned ?

mis aligned ?

mis aligned ?

mis aligned ?

Bamboo Commit: Updated the Copyright section and replaced tabs with 4 spaces

  1. … 11 more files in changeset.
need a brief description about this feature and how it is implemented/logic/math etc - also comment on the previous logic

need a brief description about this feature and how it is implemented/logic/math etc - also comment on the previous logic

its a reverse logic - is it OK to make positive instead of not defined ?

its a reverse logic - is it OK to make positive instead of not defined ?

LDT-3344 resolved merge conflicts with staging

  1. … 4 more files in changeset.
LEAHI-DD-FIRMWARE-LDT-3344_Firmware support for Beta 2 FPGA updates.
LEAHI-DD-FIRMWARE-LDT-3344_Firmware support for Beta 2 FPGA updates.
This is total mess up . that is what I want it a clean implementation. created a ticket LDT-3563 and closing all review comments.

This is total mess up . that is what I want it a clean implementation. created a ticket LDT-3563 and closing all review comments.

Removing all the review comments and created a ticket to handle it in separate ticket -LDT-3563

Removing all the review comments and created a ticket to handle it in separate ticket -LDT-3563

removed.

removed.

changed.

changed.

removed.

removed.

the 2nd if statement for beta 1.0 is an ask from systems team to raise fault alarm if user by mistake enable Beta 2.0 config when Beta1.0 is active

the 2nd if statement for beta 1.0 is an ask from systems team to raise fault alarm if user by mistake enable Beta 2.0 config when Beta1.0 is active

Noe says we can distinguish between beta 1.9 and 2.0 w/ ID (4 and 6). We still need test configs for beta 1.0 stuff and non-fpga differences. We can use DD fpga ID # here in this macro instead of t...

Noe says we can distinguish between beta 1.9 and 2.0 w/ ID (4 and 6).
We still need test configs for beta 1.0 stuff and non-fpga differences.
We can use DD fpga ID # here in this macro instead of test config.
Since this is all temporary, I'm not that concerned about how we do this so long as it works.

I think Sameer is saying that the monitor should just call one get level function in FPGA and that one function (in FpgaDD.c) would handle all of this beta 1/1.9/2.0 stuff. I agree, but didn't comm...

I think Sameer is saying that the monitor should just call one get level function in FPGA and that one function (in FpgaDD.c) would handle all of this beta 1/1.9/2.0 stuff.
I agree, but didn't comment on it because it's all temporary anyway.

Why do we need a get function to call another get function? The caller of this function should just call getFPGAGPIOStatus() and then we wouldn't need this.

Why do we need a get function to call another get function? The caller of this function should just call getFPGAGPIOStatus() and then we wouldn't need this.

Move this up to public definitions section.

Move this up to public definitions section.

readFloaterLevelStatus is higher level functions that give the data from the FPGA. Reason why we had these get functions here is, based on the FPGA response we translate it to the user understandab...

readFloaterLevelStatus is higher level functions that give the data from the FPGA.
Reason why we had these get functions here is, based on the FPGA response we translate it to the user understandable enum values (low, medium, high)

This is a reset call, as the default requirement is to be on Beta 1.9 HW The logic is checking if the user is resetting the Beta 2.0 config, if yes, we will have to fall back to the Beta 1.9 FPGA r...

This is a reset call, as the default requirement is to be on Beta 1.9 HW
The logic is checking if the user is resetting the Beta 2.0 config, if yes, we will have to fall back to the Beta 1.9 FPGA registers

Level.c is a higher level abstracted functions and should not implement the HW dependent details in this file. this details should be pushed to FPGADD. and single function should handle all the cas...

Level.c is a higher level abstracted functions and should not implement the HW dependent details in this file. this details should be pushed to FPGADD. and single function should handle all the cases instead of multiple functions.

Its not required, HW should be auto detected and initialized without any user configuration.

Its not required, HW should be auto detected and initialized without any user configuration.