dd-firmware

Clone Tools

Stats

Commits this week: 51
Total Committers: 14
Last Commit: 04 Feb
Commits this week: 51

Lines of code count not available

Commit Activity

Commits By Day In Week
52 week commits volume
Commits By Day In Week
Commits by day
Commits By Day In Week
Commits by hour
Commits By Hour In Day
Commit calendar
 

Most active committers (90 days)

loading
loading
  • last updated a few seconds ago
All Commits Reviews
Constraints
Constraints: committers
 
Constraints: files
Constraints: dates
Wednesday 04 Feb
10:52 pm

Reddaiah Utti <ven.ureddaiah@diality.com>

LDT-3223-dialysate-flow-rate---dd---mode-tel-dev-test : Updated test cases asper peer review findings for BalancingChamber.c file

Options
9:09 pm

chaithra bs <ven.cburudugatta@diality.com>

LDT-3223-dialysate-flow-rate---dd---mode-tel-dev-test : Committed vcm and tst file for concentratepumps file

Options
8:06 pm

Vendor - TEL - Sameer Poyil

LDT-2004-3 Limits execution to one active dry bicart state machine at any given time

Options
    • -15
    • +148
    /firmware/App/Controllers/DryBiCart.c
3:38 pm

Vinayakam Mani

Done.

Done.

3:38 pm

Vinayakam Mani

Done

Done

3:37 pm

Vinayakam Mani

Since trimmer heater is enabled, no need of temp compensation. only for testing purposes, temp compensation is needed. Hence by default, temp compensation is disabled.

Since trimmer heater is enabled, no need of temp compensation. only for testing purposes, temp compensation is needed. Hence by default, temp compensation is disabled.

3:36 pm

Vinayakam Mani

For spent chamber fill, we don't know how low the liquid level is ( in Chamber H) and hence decided not to turn on the trimmer heater for safety reasons. For bicarb fill, the dry bicart code should...

For spent chamber fill, we don't know how low the liquid level is ( in Chamber H) and hence decided not to turn on the trimmer heater for safety reasons. For bicarb fill, the dry bicart code should cover the actuators status. the current bicarb chamber fill code here should be updated with the newly implemented dry bi cart code changes.

3:31 pm

Vinayakam Mani

LDT-1473 code review comments

Options
    • -14
    • +14
    /firmware/App/Controllers/BalancingChamber.c
    • -1
    • +1
    /firmware/App/Controllers/BalancingChamber.h
    • -12
    • +1
    /firmware/App/Controllers/ConcentratePumps.c
1:29 pm

Dara Navaei

Bamboo Commit: Updated DDCommon.h with build versions from Bamboo.

Options
    • -1
    • +1
    /firmware/App/DDCommon.h
1:27 pm

Vendor - TEL - Jashwant Gantyada

Merge branch 'LDT-2030-blood-leak-refactor---dd' into develop

Options
11:43 am

Dara Navaei

Bamboo Commit: Updated DDCommon.h with build versions from Bamboo.

Options
    • -1
    • +1
    /firmware/App/DDCommon.h
11:36 am

Dara Navaei

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

Options
    • -2
    • +2
    /firmware/App/Controllers/PermeateTank.c
    • -2
    • +2
    /firmware/App/Controllers/RinsePump.c
    • -2
    • +2
    /firmware/App/Controllers/Valves.c
    • -1
    • +1
    /firmware/App/Controllers/Valves.h
    • -2
    • +2
    /firmware/App/Modes/FPModes/ModePreGenPermeate.c
    • -2
    • +2
    /firmware/App/Modes/ModeStandby.c
    • -2
    • +2
    /firmware/App/Modes/ModeStandby.h
    • -2
    • +2
    /firmware/App/Services/AlarmMgmtSWFaults.h
    • -2
    • +2
    /firmware/App/Services/TDInterface.c
11:34 am

Raghu Kallala

11:32 am

Raghu Kallala

LDT-3343 merged into staging

Options
11:30 am

Sean Nash , Vinayakam Mani and Michael Garthwaite

10:53 am

Vendor - TEL - Jashwant Gantyada

LDT-2030 removed static variables to update the values used by monitor and driver

Options
    • -7
    • +9
    /firmware/App/Drivers/BloodLeakDriver.c
    • -1
    • +1
    /firmware/App/Drivers/BloodLeakDriver.h
    • -44
    • +1
    /firmware/App/Monitors/BloodLeak.c
10:24 am

Vendor - TEL - Sameer Poyil

Fixed it

Fixed it

10:22 am

Vendor - TEL - Sameer Poyil

LDT-2004-3 removing blank line

Options
    • -1
    • +0
    /firmware/App/Monitors/Level.c
10:03 am

Raghu Kallala

LDT-3343 added condition for DD to wait for FP to start preGen

Options
    • -2
    • +2
    /firmware/App/Controllers/RinsePump.c
    • -4
    • +12
    /firmware/App/Modes/ModeStandby.c
6:25 am

Raghu Kallala

LDT-3343 updated function header

Options
    • -2
    • +1
    /firmware/App/Controllers/Valves.c
6:24 am

Raghu Kallala

Updated

Updated

6:23 am

Raghu Kallala

Fixed

Fixed

3:48 am

chaithra bs <ven.cburudugatta@diality.com>

LDT-3223-dialysate-flow-rate---dd---mode-tel-dev-test : Added testcases for ConcentratePumps file

Options
Tuesday 03 Feb
5:32 pm

Sean Nash

I think cal data and count should be retrieved by same function and possibly needs some interrupt protection to ensure data and count stick together. If these functions are called from general task...

I think cal data and count should be retrieved by same function and possibly needs some interrupt protection to ensure data and count stick together. If these functions are called from general task, we could have situation where data is retrieved, then priority task updates fpga, and then counter is retrieved with wrong (incremented) counter.
If these two functions are being called from a driver that is executed in priority task, then we don't need to worry about this situation, but still ought to add a constraint/warning comment in function headers noting that these functions should only be called from priority task.

5:23 pm

Sean Nash

Remove extra blank line.

Remove extra blank line.

5:17 pm

Sean Nash

It is your comment, so please resolve it.

It is your comment, so please resolve it.

5:16 pm

Sean Nash

I think Dialin will need get (or UI proxy) commands to have us send cal, s/n, and versions.

I think Dialin will need get (or UI proxy) commands to have us send cal, s/n, and versions.

5:15 pm

Sean Nash

Do FP sensors have to be treated separately? I realize there needs to be separate messages as they will be coming from different Dialin classes, but can't we handle both messages with same function...

Do FP sensors have to be treated separately? I realize there needs to be separate messages as they will be coming from different Dialin classes, but can't we handle both messages with same function (assuming shared enum to index)?

5:14 pm

Sean Nash

General Dialin question - does it make sense to override temperatures at driver level where they are spread out over several drivers? I would think overriding at monitor level would be simpler wher...

General Dialin question - does it make sense to override temperatures at driver level where they are spread out over several drivers? I would think overriding at monitor level would be simpler where they are all in one place and could be indexed by enum with single command.

5:09 pm

Sean Nash

Do we need to say Value?

Do we need to say Value?