Controllers

Clone Tools
  • last updated a few minutes ago
Constraints
Constraints: committers
 
Constraints: files
Constraints: dates
Change order of comparison.

Change order of comparison.

Blank line after declaration.

Blank line after declaration.

I think we should add the new THd temperature sensor now. I know it's currently using TRo connection (and so we don't have a TRo), but we should handle that with build switch (THd reads from TRo ch...

I think we should add the new THd temperature sensor now. I know it's currently using TRo connection (and so we don't have a TRo), but we should handle that with build switch (THd reads from TRo channel and TRo can just be a copy of TDi for now if THD_USING_TRO_CONNECTOR build switch enabled, actual future code where both sensors exist on their own connectors if build switch is disabled).

Is this needed. Should we just let Standby mode set actuators as it wants on entry?

Is this needed. Should we just let Standby mode set actuators as it wants on entry?

I think we should at least say that the mode variables are reset to re-start the mode or something.

I think we should at least say that the mode variables are reset to re-start the mode or something.

Why are some values aligned at left and others at right? I think all values should align at left.

Why are some values aligned at left and others at right? I think all values should align at left.

I'm assuming HET was enabled to get access to a GPIO pin? If so, do we need these notifications? Is there a place in HalCOGen to disable HET interrupts?

I'm assuming HET was enabled to get access to a GPIO pin? If so, do we need these notifications? Is there a place in HalCOGen to disable HET interrupts?

Not necessary - included in .h file.

Not necessary - included in .h file.

Please keep this case in last position in switch statement.

Please keep this case in last position in switch statement.

Why commented out?

Why commented out?

Remove comments or add TODO.

Remove comments or add TODO.

I think we can remove this test code now.

I think we can remove this test code now.

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.

DG-DEN-8030_DG-HD DEV Mode Chemical Disinfect
DG-DEN-8030_DG-HD DEV Mode Chemical Disinfect
Good point. The module has been moved to fwcommon.

Good point. The module has been moved to fwcommon.

Removed the wrapper function. For now, only support one type of 32-bit CRC algorithm.

Removed the wrapper function. For now, only support one type of 32-bit CRC algorithm.

Done.

Done.

Noe said they updated the ID and this is the new ID for DG FPGA. The FPGA test will fail without this change.

Noe said they updated the ID and this is the new ID for DG FPGA.
The FPGA test will fail without this change.

Should mention somewhere that timer is counting ms.

Should mention somewhere that timer is counting ms.

Why did this change?

Why did this change?

Is there a reason why this module isn't in fwcommon? And if it can't be common for some reason, should this module (or group name) be named DGIntegrity?

Is there a reason why this module isn't in fwcommon? And if it can't be common for some reason, should this module (or group name) be named DGIntegrity?

Do we need to support more than one 32-bit CRC algorithm in firmware? If not, do we need this wrapper function?

Do we need to support more than one 32-bit CRC algorithm in firmware? If not, do we need this wrapper function?

Done.

Done.

RESOLVED in CODE WALKTHROUGH.

RESOLVED in CODE WALKTHROUGH.

RESOLVED in CODE WALKTHROUGH.

RESOLVED in CODE WALKTHROUGH.

RESOLVED in CODE WALKTHROUGH.

RESOLVED in CODE WALKTHROUGH.