This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

CCS/MSP430i2040: EMDC I2C communication with EVM430-i2040S

Part Number: MSP430I2040
Other Parts Discussed in Thread: EVM430-I2040S, MSP430I2041

Tool/software: Code Composer Studio

Hello,

For MSP430i2040 EVM I have changed uart protocol successfully as per our application.

In one more application I want to use I2C protocol to get metering data.

How it will communicate with master?(I am considering MSP430 as a slave)

Will it be request based protocol? What are request command to get data?

For eg. If I want to get Vrms what command should master send to MSp430i2040?

Thanks,

Anuradha.

 

  • Hi Anuradha,

    Thanks for your detailed post. Are you using the Energy Measurement Design Center (EMDC) with the EVM430-i2040S? EMDC uses UART communication at 250k baud by default, but you can definitely change the communication protocol to meet your design requirements. For using I2C on a MSP430i2041 slave with EMDC-generated code, you can refer to the following thread. Please keep in mind that when you change from UART to I2C, you won't be able to communicate with the EMDC GUI. However, you can use two different projects that were generated by EMDC: one with no changes to be used for calibration, another one with your communication changes and the calibration factors from the first project.

    MSP430I2040: Interfacing the MSP430i2040S Sub metering EVM on I2C

    Regards,

    James

  • Part Number: MSP430I2040

    Hello,

    For I2C communication with MSP430i2040 EVM in previous query why user sending below string as this string is for uart  with baud rate 9600? We want I2C protocol details.

    byte command_frame[] = {0x68, 0x99, 0x99, 0x99, 0x99, 0x99, 0x99, 0x68, 0x23, 0x03, 0x52, 0x00, 0x00, 0xDE, 0x16};

     

    Please share the link explaining I2C protocol for MSP430i2040.

     

    Thanks,

    Anuradha.

  • Hello James,

    Thanks for the reply.

    In the above thread mentioned why user is using byte command_frame[] = {0x68, 0x99, 0x99, 0x99, 0x99, 0x99, 0x99, 0x68, 0x23, 0x03, 0x52, 0x00, 0x00, 0xDE, 0x16};  this string as this is for uart communication with baud rate 9600?

    I didn't get any document mentioning I2C protocol in details for MSP430i2040 EVM communication.

    Please share that.

    Above thread closed when user user was facing I2C communication issue, It was not solved. I doubt I2C tested protocol for MSP430i2040  EVM ?

     

    Thanks,

    Anuradha.

  • Hi Anuradha,

    What code base are you using? The legacy IAR-based Energy library described by the EVM user's guide or the newer Energy Measurement Design Center (EMDC) and Library? Both use UART as the default communication protocol. The thread that I linked above is related to the recommended EMDC library and how to change from the default UART communication to I2C communication. In that thread, Luis and I both tested and confirmed that basic I2C communication worked with those changes. If you would require additional changes, then you can leverage our I2C code examples and other resources to make those changes yourself. Our EVM software is intended to showcase functionality and not intended to support all customer requirements which would be very challenging to do. Especially with EMDC, our goal was to provide scalable, configurable metering code that allows you to focus on implementing the non-metering aspects of your design such as communication.

    Regards,

    James

  • Part Number: MSP430I2040

    Hello,

    In this thread ,

    byte command_frame[] = {0x55, 0xAA, 0x06, 0x04, 0x01, 0x01, 0x01, 0x07, 0x00};

    this string is sent to get response from target.

    Can you please explain how this string formed?

    Thanks,

    Anuradha.

  • Part Number: MSP430I2040

    Tool/software: Code Composer Studio

    Hello,

    https://e2e.ti.com/support/microcontrollers/msp430/f/166/p/809952/2998095#2998095

    In above thread,

    byte command_frame[] = {0x55, 0xAA, 0x06, 0x04, 0x01, 0x01, 0x01, 0x07, 0x00};  this string is used to get response from MSP430i2040 EVM using I2C protocol.

    Can you please explain how this string formed?

    Thanks,

    Anuradha.

  • Hi Anuradha,

    For related questions about this topic, please reply to this thread. Over the past few days, I've merged several new threads from you into this thread because it's related to the same topic. In the future, please click the "Reply" button in this thread to reply here. If you post a new thread each day about the same topic, I would assume that our community members would be less likely to chime in since they know you'll move on to another thread the next day. While we appreciate that you're using E2E, please keep these guidelines in mind.

    Anuradha Bulakh said:

    In above thread,

    byte command_frame[] = {0x55, 0xAA, 0x06, 0x04, 0x01, 0x01, 0x01, 0x07, 0x00};  this string is used to get response from MSP430i2040 EVM using I2C protocol.

    Can you please explain how this string formed?

    You can find more information about the EMDC protocol in the Communication Protocol Spec section of the EMDC Technology Guide (v1.30). To give you a quick overview:

    • 0x55 = Sync byte
    • 0xAA = Blank byte
    • 0x06 = Length byte
    • 0x04 = ID byte
    • 0x01 = Command byte
    • 0x01 = Read/write byte
    • 0x01 = Payload byte
    • 0x07 = Checksum LSB
    • 0x00 = Checksum MSB

    Regards,

    James

  • Hello,

    1.In  Communication Protocol Spec section of the EMDC Technology Guide (v1.30). this document it is not mentioned anywhere below protocol.

    • 0x55 = Sync byte
    • 0xAA = Blank byte
    • 0x06 = Length byte
    • 0x04 = ID byte
    • 0x01 = Command byte
    • 0x01 = Read/write byte
    • 0x01 = Payload byte
    • 0x07 = Checksum LSB
    • 0x00 = Checksum MSB 

    It is explained like below-

    MSP EM Design Center generic Packet Structure

    [0]

    [1]

    [2]

    [3]

    [4]

    [5]

    [6]

    ...

    [N +1]

    [N+2]

    [N+3]

    MSP Design Center ID Byte

    Command ID Byte

    Read/Write Command Byte

    Payload Byte0

    Payload Byte 1

    Payload Byte2

    Payload Byte3

    ...

    Payload Byte N

    Checksum (LSB)

    Checksum (MSB)

    This is very confusing.

    I tried with string you suggested but not receiving any response.

    2.What should be speed of I2C? --- I have set 1000000.

    3.In the above string 0x01 = Read/write byte , 0x01 is for write the how did you receive response? If command is 0x00 then only we will receive response bytes, right?

    4.To read Vrms what should be protocol? Please explain in detail(including start and stop condition for I2C). So that I can implement it for rest of the metering parameters.

    Please reply for the all 4 points in details , so that I need not to create separate thread.

    Thanks,

    Anuradha.

  • Hello Anuradha,

    Anuradha Bulakh said:
    This is very confusing.

    We appreciate the feedback. I agree, and we'll be updating this in a future EMDC release. I think this was missed since the EMDC protocol is based on the CapTIvate protocol (not trying to add confusion here), but new users wouldn't know that. By default, EMDC uses UART running at 250 kbaud. However, it's important to note that the EMDC GUI sends packets at this baud rate but spaces them out by 1 ms to give the i20xx target time to parse the commands. I don't think the 1 ms delay between packets is required from target to host.

    Anuradha Bulakh said:
    2.What should be speed of I2C? --- I have set 1000000.

    It should be 400 kHz.

    Anuradha Bulakh said:
    3.In the above string 0x01 = Read/write byte , 0x01 is for write the how did you receive response? If command is 0x00 then only we will receive response bytes, right?

    The Read bit is used when you send a command with a blank payload expecting the same command back with valid payload. In Figure 128 in the EMDC Technology Guide, you can see an example of this when the EMDC GUI sends the Application Version (0x02) command with the Read bit set and then the EMDC target sends back the same command with the Write bit set.

    Anuradha Bulakh said:
    4.To read Vrms what should be protocol? Please explain in detail(including start and stop condition for I2C). So that I can implement it for rest of the metering parameters.

    In the thread linked earlier, please see Luis' instructions on August 2, 2019 (on page 2 of this thread). They detail how to use a call-back function to listen for a command that you'd add for requesting VRMS. He also provides an example exchange including command sent and command reply. Hope that helps.

    Anuradha Bulakh said:
    Please reply for the all 4 points in details , so that I need not to create separate thread.

    Thank you for not creating a new thread :)

    Regards,

    James

  • Hello James,

    Thanks for the reply.

    Still the things not clear to me like,

    1. Is 0x04 is slave ID? if yes then why we set 0x0A  in EMDC code (ref:-https://e2e.ti.com/support/microcontrollers/msp430/f/166/p/809952/2998095#2998095 )

    2. In https://e2e.ti.com/support/microcontrollers/msp430/f/166/p/809952/2998095#pi320995=2  thread 55 AA 07 04 80 00 00 00 84 00 is string from master to slave(MSP430) and  0A )4 80 01 9A B51E 00 F3 01 is response from slave to master, right ?

    3. I have made changes in code as suggested and sent above string but not receiving any data.

    4. I am using master as a ST controller and connected SDA and SCL lines (only two) to MSP430 with ground common, did I miss anything?

    code is as follows,

     I2C_GenerateSTART(ENABLE);
       while(!I2C_CheckEvent(I2C_EVENT_MASTER_MODE_SELECT));
       I2C_SendData(0x55);
      while(!I2C_CheckEvent(I2C_EVENT_MASTER_BYTE_TRANSMITTED));
       I2C_SendData(0xAA);
       while(!I2C_CheckEvent(I2C_EVENT_MASTER_BYTE_TRANSMITTED));
        I2C_SendData(0x07);
      while(!I2C_CheckEvent(I2C_EVENT_MASTER_BYTE_TRANSMITTED));
       I2C_SendData(0x04);
       while(!I2C_CheckEvent(I2C_EVENT_MASTER_BYTE_TRANSMITTED));
       I2C_SendData(0x80);
       while(!I2C_CheckEvent(I2C_EVENT_MASTER_BYTE_TRANSMITTED));
       I2C_SendData(0x00);
       while(!I2C_CheckEvent(I2C_EVENT_MASTER_BYTE_TRANSMITTED));
       I2C_SendData(0x00);
       while(!I2C_CheckEvent(I2C_EVENT_MASTER_BYTE_TRANSMITTED));
       I2C_SendData(0x00);
       while(!I2C_CheckEvent(I2C_EVENT_MASTER_BYTE_TRANSMITTED));
       I2C_SendData(0x84);
       while(!I2C_CheckEvent(I2C_EVENT_MASTER_BYTE_TRANSMITTED));
        I2C_SendData(0x00);
       while(!I2C_CheckEvent(I2C_EVENT_MASTER_BYTE_TRANSMITTED));
     
     
     
     while(num_of_bytes)   //num_of_bytes=11
       {
           

     if(I2C_CheckEvent(I2C_EVENT_MASTER_BYTE_RECEIVED))
           {   


                if(num_of_bytes == 0)
                {
                     I2C_AcknowledgeConfig(I2C_ACK_NONE);
                     I2C_GenerateSTOP(ENABLE);  
                 }
     
                bytes[(num_of_bytes - 1)] = I2C_ReceiveData();
                num_of_bytes--;
         
             }
       }  
     
      UART1_SendData8(bytes[11]);Delay(0xFFFF);
      UART1_SendData8(bytes[10]);Delay(0xFFFF);
      UART1_SendData8(bytes[9]); Delay(0xFFFF);
      UART1_SendData8(bytes[8]);Delay(0xFFFF);
      UART1_SendData8(bytes[7]);Delay(0xFFFF);
      UART1_SendData8(bytes[6]);Delay(0xFFFF);
      UART1_SendData8(bytes[5]);Delay(0xFFFF);
      UART1_SendData8(bytes[4]);Delay(0xFFFF);
      UART1_SendData8(bytes[3]);Delay(0xFFFF);
      UART1_SendData8(bytes[2]);Delay(0xFFFF);
      UART1_SendData8(bytes[1]);Delay(0xFFFF);
      UART1_SendData8(bytes[0]);Delay(0xFFFF);

    Receiving 0000000000000.

    Waiting for your reply.

    Thanks,

    Anuradha.

  • Anuradha Bulakh said:
    1. Is 0x04 is slave ID? if yes then why we set 0x0A  in EMDC code (ref:-https://e2e.ti.com/support/microcontrollers/msp430/f/166/p/809952/2998095#2998095 )

    No, the 0x04 is the Command ID byte. For EMDC, that equals 0x04. We have other designs related to our CapTIvate and USS devices that would use a different Command ID byte because they also have a Design Center GUI and use similar protocols. The I2C slave address is 0x0A by default but can be changed if needed.

    Anuradha Bulakh said:
    2. In https://e2e.ti.com/support/microcontrollers/msp430/f/166/p/809952/2998095#pi320995=2  thread 55 AA 07 04 80 00 00 00 84 00 is string from master to slave(MSP430) and  0A )4 80 01 9A B51E 00 F3 01 is response from slave to master, right ?

    Yes, that's right based on what Luis did. Keep in mind that he used dummy data for the response from the slave (MSP430) to master.

    Anuradha Bulakh said:

    3. I have made changes in code as suggested and sent above string but not receiving any data.

    4. I am using master as a ST controller and connected SDA and SCL lines (only two) to MSP430 with ground common, did I miss anything?

    code is as follows,

    The master I2C code could be wrong. Also, do you have pull-ups resistors to VCC on the MSP430? Make sure the logic levels between the MSP430 and ST aren't different. If they are, you'll need to use a voltage logic level translator.

    Regards,

    James

  • Hello James,

    If 0x0A is slave ID then why it is not there in string 55 AA 07 04 80 00 00 00 84 00 ? Slave ID not needed in this protocol?

    Yes, we have pull up on SCL and SDA lines. And voltage levels are also same (3.3V).

    Regards,

    Anuradha.

  • Anuradha Bulakh said:
    If 0x0A is slave ID then why it is not there in string 55 AA 07 04 80 00 00 00 84 00 ? Slave ID not needed in this protocol?

    Yes, the slave ID would need to be sent before the EMDC packets to correctly address the I2C slave which is the MSP430. I think that's assumed based on the I2C bus specs.

    I2C Bus Specification

    Regards,

    James

  • Hello James,

    As I have worked on I2C protocol its very simple like,

    command from Master to slave:-

    START Slave address R/W Ack     DATA1 Ack   DATA1 Ack ...........DATAn NAck    STOP

    If want to change direction R/W ,

    START Slave address R/W Ack     DATA1 Ack   DATA1 Ack ...........DATAn NAck     RESTART    Slave address R/W Ack     DATA1 Ack   DATA1 Ack ...........DATAn NAck  

    But, For MSP430 its not like standard I2C protocol that's why user wants detail explanation of protocol including START to STOP condition without assuming anything.


    We have already used MSP430 Metering solution on UART with some modification in protocol as per application.

    And eager to use same on I2C for another application. Since protocol is not documented properly we are finding difficulties (I know EMDC generated code mainly for UART, as you are motivating user to modify code for I2C ,protocol should be explained in details).

    Please send me protocol string to read Vrms including START, SLAVE Address, R/W, Packet, STOP  (which I have already asked in my last reply).

     


    Thanks in Advance.

    Regards,

    Anuradha.

  • Also what I observed I receive reply on E2E only once in a day, so for my query I need to wait for another day.

    Cant it be fast like in 2-3-4 hrs after query raised?

    If because of timings its happening can't the query handled to India office member?

    Regards,

    Anuradha.

  • Hi Anuradha,

    Anuradha Bulakh said:
    As I have worked on I2C protocol its very simple like,

    I'm glad to hear that.

    Anuradha Bulakh said:

    We have already used MSP430 Metering solution on UART with some modification in protocol as per application.

    And eager to use same on I2C for another application. Since protocol is not documented properly we are finding difficulties (I know EMDC generated code mainly for UART, as you are motivating user to modify code for I2C ,protocol should be explained in details).

    Our goal with EMDC was to remove the complexity behind users developing metering code. It was not to support all communication protocols, but to allow users without metering experience to focus more on configuring and adapting the communication protocol. I agree that this may be challenging, but I assure you that it's much easier than developing the metering code. More importantly, we hear and appreciate your feedback with our tools. I2C communication does seem to be requested often for EMDC, so we've added that as a potential feature in an upcoming release.

    Anuradha Bulakh said:
    Please send me protocol string to read Vrms including START, SLAVE Address, R/W, Packet, STOP  (which I have already asked in my last reply).

    After performing the changes to the code as described in the thread linked above, I was able to capture the following communication with my logic analyzer. I used an Ardvark I2C tool as the I2C host.

    Under the Analyzer settings in the logic analyzer GUI, I had to change the address display to "7-bit, address bits only" for the slave address to be shown correctly. As you can see, the slave address (0x0A) with Write bit set is sent first as we've discussed earlier. Then, the sync byte (0x55). Then, the blank byte (0xAA). Then, the length byte (0x07) - remember the length is the size of payload bytes + 2-byte checksum. Then, the EMDC ID byte (0x04). Then, our command byte (0x80). Then, two bytes (0x00, 0x00) as the payload. The last two bytes (0x84, 0x00) are the checksum. This is the command from the host.

    Now, the response from the slave is defined by my function in 'emDCCommandHandlers.c'.

    void CommandHandler_transmitVRMS(Packet_t *packet,
                                     uint8_t phaseID,
                                     uint8_t *vrms)
    {
        packet->length = 8;
        packet->payload[0] = COMMAND_HANDLER_EM_GUI_ID_BYTE;
        packet->payload[1] = COMMAND_HANDLER_VRMS_ID;
        packet->payload[2] = COMMAND_HANDLER_WRITE_CMD;
        packet->payload[3] = phaseID;
        packet->payload[4] = vrms[0];
        packet->payload[5] = vrms[1];
        packet->payload[6] = vrms[2];
        packet->payload[7] = vrms[3];
    
        Comm_writePacket(packet);
    }

    Here's the communication from the slave to host. First, the slave address (0x0A) is sent with Read bit set. Next, the length byte (0x0A) is sent. Then, the EMDC GUI ID byte (0x04). Then, the Command byte (0x80). Then, the write command (0x01). Then, the phase ID (0x01) which is important for polyphase systems. Then, the four payload bytes (0x00, 0x00, 0x00, 0x00) for VRMS which are zero because my board is not connected to AC. The last two bytes are the checksum bytes (0x86, 0x00). As you can see, this matches my function for this Command byte in my code. Feel free to modify this function since it's just an example for how to receive VRMS values. This can also be applied to all the other supported results.

    Here are my other example functions for the other results.

    void CommandHandler_transmitIRMS(Packet_t *packet,
                                     uint8_t phaseID,
                                     uint8_t *irms)
    {
        packet->length = 8;
        packet->payload[0] = COMMAND_HANDLER_EM_GUI_ID_BYTE;
        packet->payload[1] = COMMAND_HANDLER_IRMS_ID;
        packet->payload[2] = COMMAND_HANDLER_WRITE_CMD;
        packet->payload[3] = phaseID;
        packet->payload[4] = irms[0];
        packet->payload[5] = irms[1];
        packet->payload[6] = irms[2];
        packet->payload[7] = irms[3];
    
        Comm_writePacket(packet);
    }
    
    void CommandHandler_transmitVPeak(Packet_t *packet,
                                     uint8_t phaseID,
                                     uint8_t *vPeak)
    {
        packet->length = 8;
        packet->payload[0] = COMMAND_HANDLER_EM_GUI_ID_BYTE;
        packet->payload[1] = COMMAND_HANDLER_VPEAK_ID;
        packet->payload[2] = COMMAND_HANDLER_WRITE_CMD;
        packet->payload[3] = phaseID;
        packet->payload[4] = vPeak[0];
        packet->payload[5] = vPeak[1];
        packet->payload[6] = vPeak[2];
        packet->payload[7] = vPeak[3];
    
        Comm_writePacket(packet);
    }
    
    void CommandHandler_transmitIPeak(Packet_t *packet,
                                     uint8_t phaseID,
                                     uint8_t *iPeak)
    {
        packet->length = 8;
        packet->payload[0] = COMMAND_HANDLER_EM_GUI_ID_BYTE;
        packet->payload[1] = COMMAND_HANDLER_IPEAK_ID;
        packet->payload[2] = COMMAND_HANDLER_WRITE_CMD;
        packet->payload[3] = phaseID;
        packet->payload[4] = iPeak[0];
        packet->payload[5] = iPeak[1];
        packet->payload[6] = iPeak[2];
        packet->payload[7] = iPeak[3];
    
        Comm_writePacket(packet);
    }
    
    void CommandHandler_transmitPowerFactor(Packet_t *packet,
                                            uint8_t phaseID,
                                            uint8_t *pFactor)
    {
        packet->length = 8;
        packet->payload[0] = COMMAND_HANDLER_EM_GUI_ID_BYTE;
        packet->payload[1] = COMMAND_HANDLER_POWER_FACTOR_ID;
        packet->payload[2] = COMMAND_HANDLER_WRITE_CMD;
        packet->payload[3] = phaseID;
        packet->payload[4] = pFactor[0];
        packet->payload[5] = pFactor[1];
        packet->payload[6] = pFactor[2];
        packet->payload[7] = pFactor[3];
    
        Comm_writePacket(packet);
    }
    
    void CommandHandler_transmitFrequency(Packet_t *packet,
                                          uint8_t phaseID,
                                          uint8_t *frequency)
    {
        packet->length = 6;
        packet->payload[0] = COMMAND_HANDLER_EM_GUI_ID_BYTE;
        packet->payload[1] = COMMAND_HANDLER_FREQUENCY_ID;
        packet->payload[2] = COMMAND_HANDLER_WRITE_CMD;
        packet->payload[3] = phaseID;
        packet->payload[4] = frequency[0];
        packet->payload[5] = frequency[1];
    
        Comm_writePacket(packet);
    }
    
    void CommandHandler_transmitActivePower(Packet_t *packet,
                                            uint8_t phaseID,
                                            uint8_t *actPower)
    {
        packet->length = 12;
        packet->payload[0] = COMMAND_HANDLER_EM_GUI_ID_BYTE;
        packet->payload[1] = COMMAND_HANDLER_ACTIVE_POWER_ID;
        packet->payload[2] = COMMAND_HANDLER_WRITE_CMD;
        packet->payload[3] = phaseID;
        packet->payload[4] = actPower[0];
        packet->payload[5] = actPower[1];
        packet->payload[6] = actPower[2];
        packet->payload[7] = actPower[3];
        packet->payload[8] = actPower[4];
        packet->payload[9] = actPower[5];
        packet->payload[10] = actPower[6];
        packet->payload[11] = actPower[7];
    
        Comm_writePacket(packet);
    }
    
    void CommandHandler_transmitReactivePower(Packet_t *packet,
                                             uint8_t phaseID,
                                             uint8_t *reactPower)
    {
        packet->length = 12;
        packet->payload[0] = COMMAND_HANDLER_EM_GUI_ID_BYTE;
        packet->payload[1] = COMMAND_HANDLER_REACTIVE_POWER_ID;
        packet->payload[2] = COMMAND_HANDLER_WRITE_CMD;
        packet->payload[3] = phaseID;
        packet->payload[4] = reactPower[0];
        packet->payload[5] = reactPower[1];
        packet->payload[6] = reactPower[2];
        packet->payload[7] = reactPower[3];
        packet->payload[8] = reactPower[4];
        packet->payload[9] = reactPower[5];
        packet->payload[10] = reactPower[6];
        packet->payload[11] = reactPower[7];
    
        Comm_writePacket(packet);
    }
    
    void CommandHandler_transmitApparentPower(Packet_t *packet,
                                              uint8_t phaseID,
                                              uint8_t *appPower)
    {
        packet->length = 12;
        packet->payload[0] = COMMAND_HANDLER_EM_GUI_ID_BYTE;
        packet->payload[1] = COMMAND_HANDLER_APPARENT_POWER_ID;
        packet->payload[2] = COMMAND_HANDLER_WRITE_CMD;
        packet->payload[3] = phaseID;
        packet->payload[4] = appPower[0];
        packet->payload[5] = appPower[1];
        packet->payload[6] = appPower[2];
        packet->payload[7] = appPower[3];
        packet->payload[8] = appPower[4];
        packet->payload[9] = appPower[5];
        packet->payload[10] = appPower[6];
        packet->payload[11] = appPower[7];
    
        Comm_writePacket(packet);
    }
    
    void CommandHandler_transmitActiveEnergy(Packet_t *packet,
                                             uint8_t phaseID,
                                             uint8_t *actEnergy)
    {
        packet->length = 12;
        packet->payload[0] = COMMAND_HANDLER_EM_GUI_ID_BYTE;
        packet->payload[1] = COMMAND_HANDLER_ACTIVE_ENERGY_ID;
        packet->payload[2] = COMMAND_HANDLER_WRITE_CMD;
        packet->payload[3] = phaseID;
        packet->payload[4] = actEnergy[0];
        packet->payload[5] = actEnergy[1];
        packet->payload[6] = actEnergy[2];
        packet->payload[7] = actEnergy[3];
        packet->payload[8] = actEnergy[4];
        packet->payload[9] = actEnergy[5];
        packet->payload[10] = actEnergy[6];
        packet->payload[11] = actEnergy[7];
    
        Comm_writePacket(packet);
    }
    
    void CommandHandler_transmitReactiveEnergy(Packet_t *packet,
                                              uint8_t phaseID,
                                              uint8_t *reactEnergy)
    {
        packet->length = 12;
        packet->payload[0] = COMMAND_HANDLER_EM_GUI_ID_BYTE;
        packet->payload[1] = COMMAND_HANDLER_REACTIVE_ENERGY_ID;
        packet->payload[2] = COMMAND_HANDLER_WRITE_CMD;
        packet->payload[3] = phaseID;
        packet->payload[4] = reactEnergy[0];
        packet->payload[5] = reactEnergy[1];
        packet->payload[6] = reactEnergy[2];
        packet->payload[7] = reactEnergy[3];
        packet->payload[8] = reactEnergy[4];
        packet->payload[9] = reactEnergy[5];
        packet->payload[10] = reactEnergy[6];
        packet->payload[11] = reactEnergy[7];
    
        Comm_writePacket(packet);
    }
    
    void CommandHandler_transmitApparentEnergy(Packet_t *packet,
                                               uint8_t phaseID,
                                               uint8_t *appEnergy)
    {
        packet->length = 12;
        packet->payload[0] = COMMAND_HANDLER_EM_GUI_ID_BYTE;
        packet->payload[1] = COMMAND_HANDLER_APPARENT_ENERGY_ID;
        packet->payload[2] = COMMAND_HANDLER_WRITE_CMD;
        packet->payload[3] = phaseID;
        packet->payload[4] = appEnergy[0];
        packet->payload[5] = appEnergy[1];
        packet->payload[6] = appEnergy[2];
        packet->payload[7] = appEnergy[3];
        packet->payload[8] = appEnergy[4];
        packet->payload[9] = appEnergy[5];
        packet->payload[10] = appEnergy[6];
        packet->payload[11] = appEnergy[7];
    
        Comm_writePacket(packet);
    }

    I hope this is helpful.

    Regards,

    James

  • Hello Anuradha,

    Was my last post helpful? Were you able to get your communication working?

    Regards,

    James