Drivers

Clone Tools
  • last updated a few minutes ago
Constraints
Constraints: committers
 
Constraints: files
Constraints: dates
LEAHI-DD-FIRMWARE-LDT-4246_FW Support for UI Demo
LEAHI-DD-FIRMWARE-LDT-4246_FW Support for UI Demo
Remove this flag.

Remove this flag.

Remove this code.

Remove this code.

Remove this condition to apply the speed for BC switch only as well.

Remove this condition to apply the speed for BC switch only as well.

Check the else portion and do the required changes.

Check the else portion and do the required changes.

Name something similar to 'BCSwitchingBasedOnClosePeriodCounter'?

Name something similar to 'BCSwitchingBasedOnClosePeriodCounter'?

I guess, all these checks should be moved to FillEndState.

I guess, all these checks should be moved to FillEndState.

after one state of BC switching completed. update the next comment as well.

after one state of BC switching completed. update the next comment as well.

LDT-3963 dialysate flow rate algorithm changes and testing

  1. … 11 more files in changeset.
Should we add a TODO to remove this one as well?

Should we add a TODO to remove this one as well?

If we are removing this call, then where are we calling the function testDDFloaterLevelStateOverride?

If we are removing this call, then where are we calling the function testDDFloaterLevelStateOverride?

Please update the function name : testDDFloaterLevelStateOverride

Please update the function name : testDDFloaterLevelStateOverride

Why are we removing this TODO comment? It looks like we should keep it.

Why are we removing this TODO comment? It looks like we should keep it.

Do we need TODO comments to restore these alarms later?

Do we need TODO comments to restore these alarms later?

What is the point of this message?

What is the point of this message?

Looks like we need a TODO comment to restore these checks later.

Looks like we need a TODO comment to restore these checks later.

fixed emrge conflicts and merged LDT-3963

  1. … 3 more files in changeset.
LDT-3963 Fixes for beta 2.1 testing

  1. … 5 more files in changeset.
Merge branch 'LDT-4000-hdf-fw-implementation-1' into develop

  1. … 7 more files in changeset.
LDT-4000: substitution pump implementation and fixes.

  1. … 8 more files in changeset.
LDT-3963 enabled fault mode tranisiton for switching off hetares for dilaysate flow rate testing

  1. … 10 more files in changeset.
First two logics ANDed correct (first cycle and close period). the third one (BC switch only must be ANDed only with close period), not to include first cycle..

First two logics ANDed correct (first cycle and close period). the third one (BC switch only must be ANDed only with close period), not to include first cycle..

LEAHI-DD-FIRMWARE-LDT-4000_HDF - FW Implementation - 1/4:
LEAHI-DD-FIRMWARE-LDT-4000_HDF - FW Implementation - 1/4:
So this unit manages the sending of record messages, right? I don't see a unit managing read/write/erase jobs. Where is that queue?

So this unit manages the sending of record messages, right? I don't see a unit managing read/write/erase jobs. Where is that queue?

I think this enum should be in a different header file. I don't think this unit uses this enum.

I think this enum should be in a different header file. I don't think this unit uses this enum.

Slot size and offsets can probably be private and maybe better placed in a different header file? I don't see why a msg Q would need/use/be responsible for this kind of thing.

Slot size and offsets can probably be private and maybe better placed in a different header file? I don't see why a msg Q would need/use/be responsible for this kind of thing.

These addresses should be calculated in init function from sector start addresses (call driver get function to get these) and your offsets and stored in static variables within the .c file.

These addresses should be calculated in init function from sector start addresses (call driver get function to get these) and your offsets and stored in static variables within the .c file.

Do these need to be public? I think only the driver should have to know sector addresses and sizes. If other units want to know these things, they should call a function in this driver to get them.

Do these need to be public?
I think only the driver should have to know sector addresses and sizes.
If other units want to know these things, they should call a function in this driver to get them.

I think isSectorStartAddress is a better function name.

I think isSectorStartAddress is a better function name.