(Since I used Google Translate for some complex content, the meaning may be difficult to convey. I ask for your understanding.)

Hello, friends!

Recently, whenever I have free time, I’ve been playing with used CLUSTER and BCM toys, and I’ve developed a question. Specifically, I want to know about the bit length related to IPC XML configuration.

Based on what I’ve found so far, I understood that for each DID, there are startbyte, startbit, and startbyte values for each item, and that the function is turned ON (True=1) / Off (False=0) using the desired RPO option.

However, the calculation rules for some items are ambiguous, so I don't quite understand them.

For example, if there is an item DID00A5 with Startbyte '16', Startbit '7', and Bitlength '3', my understanding is that 3 bits starting from bit 7 are allocated to byte 16. Does this mean it includes bits 7, 8, and 9 (?)?

Based on my knowledge, since bits range from 0 to 7, totaling 8 bits, I am wondering if bit 9 is allocated up to the 0th bit of the next 17th byte.

If so, I am concerned that the 0th bit of byte 17 might conflict with other items cause that.

Is there anyone here who is knowledgeable about this bitlength part?

I have attached an example below.

    <DidItem>
      <ID>DID00a5</ID>
      <DidNo>00A5</DidNo>
      <DidDataIndicator>0000</DidDataIndicator>
      <Name>DID_A5</Name>
      <Description>This DID is used to set functionality controls. It shall be write protected via security access.</Description>
      <DidLength>32</DidLength>
      <DefaultValue>09B1004083D1C0006C090000000001800004080000019D00E80000F078532000</DefaultValue>

byte on 16, and 17

<Parameter ParamDefaultValue="00">
        <ParameterName>P_FDI_TYPE</ParameterName>
        <StartByte>16</StartByte>
        <StartBit>7</StartBit>
        <BitLength>3</BitLength>
        <ConfData useConfData="true">
          <ConfigData Value="00" AutoGenExpression="(!KSG)">
            <Product>
              <RpoCodeRef IDREF="OCKSG" hasToBeAvailable="false" />
            </Product>
          </ConfigData>
          <ConfigData Value="01" AutoGenExpression="(KSG)">
            <Product>
              <RpoCodeRef IDREF="OCKSG" hasToBeAvailable="true" />
            </Product>
          </ConfigData>
        </ConfData>
        <ServiceSection IsServiceAccessAllowed="false">
          <Interpretation Text="none" Value="00" />
          <Interpretation Text="ACC" Value="01" />
          <Interpretation Text="camera" Value="02" />
          <Interpretation Text="Reserved" Value="03" />
          <Interpretation Text="Reserved" Value="04" />
          <Interpretation Text="Reserved" Value="05" />
          <Interpretation Text="Reserved" Value="06" />
          <Interpretation Text="Reserved" Value="07" />
        </ServiceSection>
      </Parameter>
      <Parameter ParamDefaultValue="01">
        <ParameterName>P_TOP_BAR_INFORMATION_PRESENT</ParameterName>
        <StartByte>17</StartByte>
        <StartBit>0</StartBit>
        <BitLength>1</BitLength>
        <ConfData useConfData="false" />
        <ServiceSection IsServiceAccessAllowed="false">
          <Interpretation Text="False" Value="00" />
          <Interpretation Text="True" Value="01" />
        </ServiceSection>
      </Parameter>

Hi,

You can force these values (one by one) and upload to the test cluster - you should see the full-length hex value for each DID in the DPS log after each programming event.

That way you can compare how it works.

13 hours ago, pupu14 said:

안녕,

이러한 값들을 (하나씩) 강제로 입력하고 테스트 클러스터에 업로드할 수 있습니다. 각 프로그래밍 이벤트 후 DPS 로그에서 각 DID에 대한 전체 길이 16진수 값을 확인할 수 있습니다.

그렇게 하면 작동 방식을 비교할 수 있습니다.

As you mentioned, come to think of it, benchmarking would allow me to monitor value fluctuations..

There was a simple way to check all along; haha.;;

Thank you for your interest.~