Drivers

Clone Tools
  • last updated a few minutes ago
Constraints
Constraints: committers
 
Constraints: files
Constraints: dates
arrange this code and new sensor code in a group- line 131 - 142

arrange this code and new sensor code in a group- line 131 - 142

I think we need a #ifdef TEENSY macro ?

I think we need a #ifdef TEENSY macro ?

Need two spaces before the test function

Need two spaces before the test function

It is there in line 131

It is there in line 131

This is already initialized (properly) near top of function. It is not proper (zero) here.

This is already initialized (properly) near top of function. It is not proper (zero) here.

Is there going to be an #else for new sensor?

Is there going to be an #else for new sensor?

Are we supporting multiple models? Is this for Teensy or new sensor or both?

Are we supporting multiple models? Is this for Teensy or new sensor or both?

Will new conductivity sensor driver have this override too? It looks Teensy specific.

Will new conductivity sensor driver have this override too? It looks Teensy specific.

Align comments.

Align comments.

I would describe function as "reconfigures FPGA driver to use appropriate FPGA register maps".

I would describe function as "reconfigures FPGA driver to use appropriate FPGA register maps".

Add space between } and type name.

Add space between } and type name.

Indenting looks off for most fields in this struct.

Indenting looks off for most fields in this struct.

Why doesn't name and comment match?

Why doesn't name and comment match?

LEAHI-DD-FIRMWARE-LDT-3344_Firmware support for Beta 2 FPGA updates.
LEAHI-DD-FIRMWARE-LDT-3344_Firmware support for Beta 2 FPGA updates.
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.

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.

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)?

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.

Do we need to say Value?

Do we need to say Value?

Add a blank line after public defs banner. Add a dox comment to the right. I believe they reserve space for 12 bytes, not 10. Not really for calibration - it's for s/n and versions.

Add a blank line after public defs banner.
Add a dox comment to the right.
I believe they reserve space for 12 bytes, not 10.
Not really for calibration - it's for s/n and versions.

Are these really going to be different types? I assumed they would all be floats.

Are these really going to be different types? I assumed they would all be floats.

Structures need a top level dox comment.

Structures need a top level dox comment.

enums need a top level dox comment.

enums need a top level dox comment.

I believe conductivity and temperature data will be F32s.

I believe conductivity and temperature data will be F32s.

Do we not need this anymore? I still see it in code all over the place and I don't think we're done w/ Teensy until Beta 1.9 units are obsolete.

Do we not need this anymore? I still see it in code all over the place and I don't think we're done w/ Teensy until Beta 1.9 units are obsolete.

LEAHI-DD-FIRMWARE-LDT-2004_Dialysate Composition - DD
LEAHI-DD-FIRMWARE-LDT-2004_Dialysate Composition - DD
Remove extra blank line.

Remove extra blank line.