This is a list of all comments for HD-DEN-1312-1.

Review Summary: No summary


----------------------------------------
File: firmware/App/Services/SystemCommMessages.c
Revision Comment by pmontazemi on 10 January 2020, 10:35 
https://devapps.diality.us/cru/HD-DEN-1312-1#c916

  Add space.

  Reply by pmontazemi on 10 January 2020, 16:52
  > RESOLVED in CODE WALKTHROUGH.

----------------------------------------
File: firmware/App/Services/SystemCommMessages.h
Revision Comment by pmontazemi on 06 January 2020, 07:44 
https://devapps.diality.us/cru/HD-DEN-1312-1#c758

  Add extra space to all for legibility

  Reply by pmontazemi on 10 January 2020, 10:12
  > RESOLVED in CODE WALKTHROUGH.

Revision Comment by pmontazemi on 10 January 2020, 10:35 
https://devapps.diality.us/cru/HD-DEN-1312-1#c917

  Remove blank line.

  Reply by pmontazemi on 10 January 2020, 16:50
  > RESOLVED in CODE WALKTHROUGH.

Revision Comment by pmontazemi on 10 January 2020, 10:36 
https://devapps.diality.us/cru/HD-DEN-1312-1#c918

  Add blank line at eof.

  Reply by pmontazemi on 10 January 2020, 16:50
  > RESOLVED in CODE WALKTHROUGH.

----------------------------------------
File: firmware/App/Services/CommBuffers.c
Revision Comment by lbaloa on 09 January 2020, 08:57 
https://devapps.diality.us/cru/HD-DEN-1312-1#c856

  Is this commBuffers not called from different threads? if so,
  don't we need it to set it to volatile too?

  Reply by Sean Nash on 09 January 2020, 10:15
  > I only made these volatile to see if it helped with CAN issue
  > (it did not).  I'll likely change them back to remove the
  > volatile property.  We only need volatile if we access a
  > variable multiple times within a function and expect other
  > threads may have changed the variable's value between
  > accesses (as compiler may optimize the function to only
  > access it once if not volatile).  Other means of thread
  > protection should prevent other threads from accessing a
  > given side of a buffer at the same time.

    Reply by Dara Navaei on 19 October 2023, 09:32
    > RESOLVED in CODE WALKTHROUGH

----------------------------------------
File: firmware/source/sys_core.asm
Revision Comment by pmontazemi on 06 January 2020, 07:56 
https://devapps.diality.us/cru/HD-DEN-1312-1#c760

  What added functionality triggered the creation of the assembly
  and command files?

  Reply by Sean Nash on 06 January 2020, 16:01
  > Not new.  Bitbucket shows sys_core.asm was always in project.

    Reply by pmontazemi on 10 January 2020, 10:09
    > RESOLVED in CODE WALKTHROUGH.

----------------------------------------
File: firmware/source/spi.c
Revision Comment by pmontazemi on 06 January 2020, 07:55 
https://devapps.diality.us/cru/HD-DEN-1312-1#c759

  Why are we using both mibSPI and SPI?

  Reply by Sean Nash on 06 January 2020, 16:05
  > Needed for re-purposing a SPI4 pin for GPIO (used by
  > dialysate outlet pump).

    Reply by pmontazemi on 10 January 2020, 10:11
    > RESOLVED in CODE WALKTHROUGH.


---

ID: HD-DEN-1312-1 https://devapps.diality.us/cru/HD-DEN-1312-1

Title: HD-DEN-1312_HD Dialysate Inlet Pump/Drive, Flow Sensor, Control
Statement of Objectives:


State: Closed

Summary: 

Author: Sean Nash
Moderator: Sean Nash
Reviewers: (2 active, 2 completed*)
     pmontazemi   (*)
     lbaloa   (*)
     Dara Navaei
     Behrouz NematiPour