Activity leahi-dialin/leahi

Zoltan and I had a meeting, and the counter solution he provided works better than mine. He explained to me that my proposed solution has flaws. RESOLVED.

Zoltan and I had a meeting, and the counter solution he provided works better than mine.
He explained to me that my proposed solution has flaws.
RESOLVED.

11:45 am

Tiffany Mejia and Michael Garthwaite

More
LEAHI-DIALIN-LDT-4872-1
finished reviewing

10:48 am

Dara Navaei

More
LEAHI-DIALIN-LDT-4874-1
started review

LEAHI-DIALIN-LDT-4874_Invalid values interrupt script

2:54 pm

Zoltan Miskolci

More
b167367
changed 4 files
LDT-5152-handler_refactor, handler_refactor LEAHI-DIALIN-LDT-5152-1

demo

- -168
- +343
./alarms.py
- History
- Source
- Diff
./alarms.py
… 3 more files in changeset.

4:20 pm

Zoltan Miskolci

More
3e8c157
changed 4 files
LDT-4003-hdf-fw-implementation-4-4, LDT-4611-hdf-fw-implementation-5-4 and 11 more LEAHI-DIALIN-LDT-4872-1

patient vitals module

- -0
- +102
./blood_pressure.py
- History
- Source
./blood_pressure.py
… 3 more files in changeset.

3:08 pm

Vendor - TEL - Santhoshkumar Reddy Alasandagutti

12:55 pm

Sean Nash

More
LEAHI-DIALIN-LDT-4072-1
finished reviewing

3:11 pm

Vinayakam Mani

More
LEAHI-DIALIN-LDT-4160-1
finished reviewing

1:19 pm

Vendor - TEL - Varshini Nagabooshanam

3:02 pm

The approach of what this code does and the conversion module are similar in function but a differ on maintenance and flexibility. 1. The conversion module's bytearray to value methods work, but th...

The approach of what this code does and the conversion module are similar in function but a differ on maintenance and flexibility.
1. The conversion module's bytearray to value methods work, but they require manual logistic around the indexing. It's the user's responsibility to handle where the reading starts and you need to code the handler for that (previous approach with MsgFieldPositions), It's inflating the method. I worked hard to remove the need for indexing where the value starts. Instead of the previous struct.unpack approach, where you needed to maintain the type, you will be needing to maintain the conversion methods that are being called, so it would be the same as before, you still need to mind the indexing, which was the main reason of changing from this approach.

2. In the current approach, you declare the type and pass it to a processor that dynamically handling the unpack type (based on the set datatype) and the indexing for that. This works much better and easier to maintain, as you can just insert a new value when it's added to the FW, and don't need to adjust all your indexes for the reading.

Example #1, changing build type from U16 to U08:

with the conversion approach, you need to change the function used, and update the starting index for all the following methods.
with the current approach you change the Datatype.U16 to Datatype.U08 and that's all you need to do.

Example #2: adding a new variable fpga_micro after fpga_minor, with U08 type:

with the conversion approach, you add the bytearray_to_byte, update the indexes for all the following reads.
with the current approach you insert an element after the fpga_minor with a value ('fpga_micro', Datatype.U08), and nothing more needed

12:33 pm

Behrouz NematiPour

RESOLVED for now.

12:32 pm

Behrouz NematiPour

I would not do that because the function names and messages for each project should be different to avoid confusion. I think that is fine for now. RESOLVED.

I would not do that because the function names and messages for each project should be different to avoid confusion.
I think that is fine for now.

RESOLVED.

12:17 pm

Vendor - TEL - Santhoshkumar Reddy Alasandagutti

even though we are sending U08 at Firmware. Due to structure padding Raw message for priority is converted as 16 bits. While receiving we need to read them as U16. Here is my debug values [CortexR4...

even though we are sending U08 at Firmware. Due to structure padding Raw message for priority is converted as 16 bits. While receiving we need to read them as U16. Here is my debug values [CortexR4] ALARM_PROP_T size = 22 bytes
byte[0] = 0x03
byte[1] = 0x00
byte[2] = 0x6F
byte[3] = 0x00
byte[4] = 0x01
byte[5] = 0x00
byte[6] = 0x00
byte[7] = 0x01
byte[8] = 0x00
byte[9] = 0x00
byte[10] = 0x01
byte[11] = 0x00
byte[12] = 0x00
byte[13] = 0x01
byte[14] = 0x00
byte[15] = 0x00
byte[16] = 0x01
byte[17] = 0x00
byte[18] = 0x00
byte[19] = 0x01
byte[20] = 0x0A
byte[21] = 0x00

This is structure defined at firmware side
struct AlarmTableRequestPayload

Unknown macro: { U08 alarmPriority; U16 alarmSubRank; U08 alarmSource; U08 alarmIsFault; U08 alarmIsDDFault; U08 alarmStops; U08 alarmConditionClearImmed; ///< Alarm condition is cleared immediately (does not persist after alarm triggered) U08 alarmNoClear; ///< Alarm cannot be cleared (unrecoverable)? U08 alarmNoResume; ///< Alarm prevents treatment resume U08 alarmNoRinseback; ///< Alarm prevents rinseback U08 alarmNoEndTreatment; ///< Alarm prevents ending treatment U08 alarmBlockRinseback; ///< Alarm should not trigger while in rinseback states U08 alarmBlockEndTx; ///< Alarm should not trigger while in post-treatment mode U08 alarmNoBloodRecirc; ///< Alarm prevents blood re-circulation U08 alarmNoDialysateRecirc; ///< Alarm prevents dialysate re-circulation U08 alarmAutoResume; ///< Alarm should resume automatically once the condition is cleared U08 alarmClearOnly; ///< Clear only this alarm on user acknowledgment U08 alarmTreatmentLog; ///< Log alarm to treatment log if active during treatment U16 alarmID; ///< Alarm ID }

;
typedef struct AlarmTableRequestPayload ALARM_PROP_T;

12:11 pm

Behrouz NematiPour

So the same channels are used for both the Leahi and Denali? I am not talking about how collisions are handled; that is handled by the CAN driver, not the FW or SW. My point is that the CAN Channel...

So the same channels are used for both the Leahi and Denali?
I am not talking about how collisions are handled; that is handled by the CAN driver, not the FW or SW.
My point is that the CAN Channels by themselves do not have the meaning we want; they are only a priority.
As we defined them, we gave them a meaning as a category; therefore, it is better to name them the Denali/Leahi Channels rather than the CAN Channels.

12:06 pm

Behrouz NematiPour

RESOLVED.

12:06 pm

Behrouz NematiPour

def fp_versions(self, major: int, minor: int, micro: int, build: int, fpga_id: int, fpga_major: int, fpga_minor: int, fpga_lab: int, compatibility_rev: int...

def fp_versions(self, major: int, minor: int, micro: int, build: int,
                     fpga_id: int, fpga_major: int, fpga_minor: int, fpga_lab: int,
                     compatibility_rev: int):
     """
     Broadcasts the current dd Version Data (Msg ID: 0x0F, 15)
     Args:
         @param major: (uint) - Major version number
         @param minor: (uint) - Minor version number
         @param micro: (uint) - Micro version number
         @param build: (uint) - Build version number
         @param fpga_id: (int) - FPGA id version number
         @param fpga_major: (int) - FPGA Major version number
         @param fpga_minor: (int) - FPGA Minor version number
         @param fpga_lab: (int) - FPGA Lab version number
         @param compatibility_rev: (uint) - The FWs/UI compatibility revision
     @return: None
     """
     if not self.can_enabled:
         raise ValueError("CAN Interface is not enabled")

     payload =  conversions.unsigned_byte_to_bytearray   (major            )
     payload += conversions.unsigned_byte_to_bytearray   (minor            )
     payload += conversions.unsigned_byte_to_bytearray   (micro            )
     payload += conversions.unsigned_short_to_bytearray  (build            )
     payload += conversions.unsigned_byte_to_bytearray   (fpga_id          )
     payload += conversions.unsigned_byte_to_bytearray   (fpga_major       )
     payload += conversions.unsigned_byte_to_bytearray   (fpga_minor       )
     payload += conversions.unsigned_byte_to_bytearray   (fpga_lab         )
     payload += conversions.unsigned_integer_to_bytearray(compatibility_rev)

     message = CAN.CanMessage.build_message(
                                         channel_id=CAN.CanChannels.fp_sync_broadcast_ch_id,
                                         message_id=msg_ids.MsgIds.MSG_ID_FP_VERSION_RESPONSE.value,
                                         payload=payload)

     self.can_interface.send(message, 0)

11:08 am

Zoltan Miskolci

More
ad4c490
changed 1 file
develop, version_fix

Merge branch 'LDT-4505' into develop

- -1
- +1
./blood_flow.py
- History
- Source
- Diff
./blood_flow.py

modules

Stats

Commits this week: 3

Commit Activity

52 week commits volume

Commits by day

Commits by hour

Commit calendar

Most active committers (90 days)

Zoltan Miskolci

Vendor - TEL - Arpita Srivastava

Zoltan Miskolci

Raghu Kallala

Dara Navaei

Michael Garthwaite

Dara Navaei

Michael Garthwaite

Michael Garthwaite

Tiffany Mejia and Michael Garthwaite

Zoltan Miskolci

Michael Garthwaite

Michael Garthwaite

Behrouz NematiPour

Tiffany Mejia and Michael Garthwaite

Dara Navaei

Zoltan Miskolci

Zoltan Miskolci

Vendor - TEL - Santhoshkumar Reddy Alasandagutti

Sean Nash

Vinayakam Mani

Vendor - TEL - Varshini Nagabooshanam

Zoltan Miskolci

Behrouz NematiPour

Behrouz NematiPour

Vendor - TEL - Santhoshkumar Reddy Alasandagutti

Behrouz NematiPour

Behrouz NematiPour

Behrouz NematiPour

Zoltan Miskolci