leahi-dialin / leahi_dialin

ui

Clone Tools

Stats

Commits this week: 3
Total Committers: 8
Last Commit: 31 Dec 69
Commits this week: 3

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
Tuesday 28 Jul
6:53 pm

Behrouz NematiPour

It has been reviewed and approved.

It has been reviewed and approved.

4:04 pm

Nicholas Ramirez

reviewed on Vm with BN

reviewed on Vm with BN

3:52 pm

Nicholas Ramirez

add accept

add accept

Monday 27 Jul
3:14 pm

Sean Nash

3:14 pm

Sean Nash

3:13 pm

Sean Nash

1:46 pm

Sean Nash

Thursday 23 Jul
11:44 am

Dara Navaei

LEAHI-DIALIN-LDT-5331_SW Misc & Enhc - SW - 01 - Pre-Tx - Usability Support - R&I
LEAHI-DIALIN-LDT-5331_SW Misc & Enhc - SW - 01 - Pre-Tx - Usability Support - R&I
Tuesday 21 Jul
4:49 pm

Dara Navaei

LEAHI-DIALIN-LDT-5246_System Interface for Users - SW - 01 - Bicarb/Acid Low Replacement - R&I
LEAHI-DIALIN-LDT-5246_System Interface for Users - SW - 01 - Bicarb/Acid Low Replacement - R&I
10:19 am

Dara Navaei

LEAHI-DIALIN-LDT-5232_HDF - SW - 01 - HDF - Messaging & Models - R&I
LEAHI-DIALIN-LDT-5232_HDF - SW - 01 - HDF - Messaging & Models - R&I
9:13 am

Nicholas Ramirez

Monday 20 Jul
3:26 pm

Stephen Quong , Tiffany Mejia and Behrouz NematiPour

Friday 17 Jul
4:04 pm

Dara Navaei

LEAHI-DIALIN-LDT-4767_SW Misc & Enhc - SW - 01 - Isolated UF - R&I
LEAHI-DIALIN-LDT-4767_SW Misc & Enhc - SW - 01 - Isolated UF - R&I
Tuesday 14 Jul
9:09 am

Sean Nash

9:08 am

Sean Nash

Monday 13 Jul
10:17 am

Dara Navaei

LEAHI-DIALIN-LDT-5074_SW Misc & Enhc - SW - 01 - Feature Complete - R&I
LEAHI-DIALIN-LDT-5074_SW Misc & Enhc - SW - 01 - Feature Complete - R&I
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.

Thursday 09 Jul
10:33 am

Dara Navaei

LEAHI-DIALIN-LDT-4919_SW Misc & Enhc - SW - 01 - SW Integration - Rinseback - R&I
LEAHI-DIALIN-LDT-4919_SW Misc & Enhc - SW - 01 - SW Integration - Rinseback - R&I
8:40 am

Sean Nash

Wednesday 08 Jul
2:02 pm

Dara Navaei

LEAHI-DIALIN-LDT-4979_SW Misc & Enhc - SW - 01 - SW Integration - Pre-Tx - R&I
LEAHI-DIALIN-LDT-4979_SW Misc & Enhc - SW - 01 - SW Integration - Pre-Tx - R&I
Thursday 02 Jul
3:39 pm

Nicholas Ramirez

3:38 pm

Behrouz NematiPour and Stephen Quong

3:36 pm

Nicholas Ramirez

bn approves

bn approves

3:35 pm

Nicholas Ramirez

3:31 pm

Stephen Quong

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.