leahi-dialin / leahi_dialin / td

proxies

Clone Tools

Stats

Commits this week: 6
Total Committers: 2
Last Commit: 13 Aug
Commits this week: 6

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 minutes ago
All Commits Reviews
Constraints
Constraints: committers
 
Constraints: files
Constraints: dates
Thursday 13 Aug
10:42 am

Zoltan Miskolci

We will need to get the event_id first, to know how to process the content as Operation status content is different from rest. So this line is just for getting the event id, and based on the resul...

We will need to get the event_id first, to know how to process the content as Operation status content is different from rest.

So this line is just for getting the event id, and based on the result, process the rest into the correct variables

10:40 am

Zoltan Miskolci

removed

removed

10:37 am

Zoltan Miskolci

fixed

fixed

10:05 am

Raghu Kallala

remove if we are sure about the message ID

remove if we are sure about the message ID

10:02 am

Raghu Kallala

Will we need this after adding the below code?

Will we need this after adding the below code?

9:57 am

Raghu Kallala

Fix typo

Fix typo

Wednesday 12 Aug
1:29 pm

Dara Navaei

LEAHI-DIALIN-LDT-5482_[Dry Self Test] Update the module to match the current dev changes
LEAHI-DIALIN-LDT-5482_[Dry Self Test] Update the module to match the current dev changes
Tuesday 11 Aug
2:59 pm

Dara Navaei

LEAHI-DIALIN-LDT-5205_[DD] Update NVM records architecture in Dialin
LEAHI-DIALIN-LDT-5205_[DD] Update NVM records architecture in Dialin
9:34 am

Zoltan Miskolci

Monday 10 Aug
3:36 pm

Zoltan Miskolci

I think that's what is usually shown, the first 7 char, but in this case it might have been a typo

I think that's what is usually shown, the first 7 char, but in this case it might have been a typo

3:07 pm

Raghu Kallala

2:29 pm

Raghu Kallala

Was it a regulatory requirement before to have 7 characters from commit ID or something we implemented?

Was it a regulatory requirement before to have 7 characters from commit ID or something we implemented?

Friday 07 Aug
3:49 pm

Zoltan Miskolci

No need, in a different CR I have a module that pulls the Alarm ID, Reject Reason and Msg Ids directly from the FW. After that's merged, this file won't be needed any more manual update. For more ...

No need, in a different CR I have a module that pulls the Alarm ID, Reject Reason and Msg Ids directly from the FW. After that's merged, this file won't be needed any more manual update.

For more information check LDT-5205 CR, file: utils\ enum_updater.py

Thursday 06 Aug
10:21 pm

Michael Garthwaite

10:10 pm

Michael Garthwaite

In FW we pre-populated Alarm IDs up to 300 to help with the reservation process. Would this also benefit dialin if we reserve up to 300?

In FW we pre-populated Alarm IDs up to 300 to help with the reservation process. Would this also benefit dialin if we reserve up to 300?

Wednesday 05 Aug
3:02 pm

Zoltan Miskolci

8:34 am

Michael Garthwaite

Wednesday 29 Jul
3:20 pm

Raghu Kallala

Monday 20 Jul
12:34 pm

Dara Navaei

LEAHI-DIALIN-LDT-5152_[Dialin] Handler architecture refactor
LEAHI-DIALIN-LDT-5152_[Dialin] Handler architecture refactor
Monday 13 Jul
11:51 am

Zoltan Miskolci

Sunday 12 Jul
11:44 pm

Behrouz NematiPour

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.

Friday 10 Jul
11:45 am

Tiffany Mejia and Michael Garthwaite

Wednesday 01 Jul
3:02 pm

Zoltan Miskolci

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.

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: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.

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)
Monday 29 Jun
9:44 am

Zoltan Miskolci

Being generic is the whole point of it. It was renamed because this is a dialin dedicated to Leahi unit and calling the messages DenaliMessage is misleading. It was renamed to CanMessage for 2 reas...

Being generic is the whole point of it.
It was renamed because this is a dialin dedicated to Leahi unit and calling the messages DenaliMessage is misleading.
It was renamed to CanMessage for 2 reason:
1. This is a Leahi only dialin, so there is no need to differentiate between different type of Can Messages as there would be only 1 type
2. Calling it CanMessage will make it more future compatible when the dialin get copied over for a new unit development (unlikely in the foreseeable future but possible), removing the need to rename it again

9:43 am

Zoltan Miskolci

There is no Leahi or Denali CANChannels. There are CAN channels and the naming is what that channel is being used for. The collision occurs in the FW and the FW handles it before sending out a mess...

There is no Leahi or Denali CANChannels.
There are CAN channels and the naming is what that channel is being used for.
The collision occurs in the FW and the FW handles it before sending out a message.
When reading a CAN, there are no collisions, so there are no priorities. So I have no clue what you want here.