FpgaTD.c

Clone Tools
  • last updated a few minutes ago
Constraints
Constraints: committers
 
Constraints: files
Constraints: dates
done.

done.

Update I/O section here to include rotor revs accumulated and previous.

Update I/O section here to include rotor revs accumulated and previous.

handled accordingly.

handled accordingly.

removed and added.

removed and added.

LDT-1394 addressed code review comments

  1. … 3 more files in changeset.
fixed in latest code

fixed in latest code

implemented

implemented

fixed

fixed

Converting U16 to U32. Presumably, U16 will wrap back to zero when it gets to 65535. We don't want our U32 to wrap, so we need to do something to handle this conversion properly.

Converting U16 to U32. Presumably, U16 will wrap back to zero when it gets to 65535. We don't want our U32 to wrap, so we need to do something to handle this conversion properly.

I think this whole function should be moved to the PeristalticPump.c driver unit. We don't want controller/monitor level units directly accessing fpga registers - the drivers should be doing that.

I think this whole function should be moved to the PeristalticPump.c driver unit. We don't want controller/monitor level units directly accessing fpga registers - the drivers should be doing that.

I think this would be a TD s/w fault (alarm already define). Just need a new TD s/w fault ID in AlarmMgmtSWFaults.h.

I think this would be a TD s/w fault (alarm already define). Just need a new TD s/w fault ID in AlarmMgmtSWFaults.h.

This structure doesn't seem necessary - it's just a middle man. Why not just pass the #defines directly into the quadratic macro?

This structure doesn't seem necessary - it's just a middle man. Why not just pass the #defines directly into the quadratic macro?

LDT-1394 added h4 rotor revs count for broadcasting it

  1. … 2 more files in changeset.
LEAHI-TD-FIRMWARE-LDT-1394_Blood Flow Rate - TD - 04: DEV - Feature Implementation
LEAHI-TD-FIRMWARE-LDT-1394_Blood Flow Rate - TD - 04: DEV - Feature Implementation
Fixed

Fixed

removed from here

removed from here

fixed

fixed

We need new alarm . That should be included in SRS right ? or shall i use SET_ALARM_WITH_2_U32_DATA( ALARM_ID_TD_SOFTWARE_FAULT) ?

We need new alarm . That should be included in SRS right ? or shall i use SET_ALARM_WITH_2_U32_DATA( ALARM_ID_TD_SOFTWARE_FAULT) ?

Add blank line after declarations.

Add blank line after declarations.

Alarm should be handled inside of setAirPumpState().

Alarm should be handled inside of setAirPumpState().

Alarm should be handled inside of setAirPumpState().

Alarm should be handled inside of setAirPumpState().

Alarm should be handled inside of setAirPumpState().

Alarm should be handled inside of setAirPumpState().

Alarm should be handled inside of setAirPumpState().

Alarm should be handled inside of setAirPumpState().

Alarm should be handled inside of setAirPumpState().

Alarm should be handled inside of setAirPumpState().

Alarm should be handled inside of setAirPumpState().

Alarm should be handled inside of setAirPumpState().

Add blank line after declarations.

Add blank line after declarations.

I think alarm should be handled inside the setAirPumpState() function.

I think alarm should be handled inside the setAirPumpState() function.

Should we have alarm here?

Should we have alarm here?