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.

DLPC350: About I2C access of DLPC350

Part Number: DLPC350

Hi Austin,Akhil or TI expert

I have another question about "I2C_BUSY GPIO".
Please answer each question.

(1) Does this signal change for all commands?
Ans →
(2) Do you know the minimum and maximum busy time?
Ans →
(3) Can you tell me the command whose busy time fluctuates greatly depending on the setting contents of the command?
Ans →
(4) Regarding the reading of "busy bit" in "Section 2.4.3.1", in the previous answer, "I2C_BUSY GPIO" was
I heard it is irrelevant. So do we need to look at both? Which is more accurate if one is possible?
Ans →

Regards,

Tak

  • Hi Tak,

    Please allow our team a few business days to look into this and we will get back to you by middle of next week.

    Thank you,

    Chris

  • Hi Chris,Austin,Akhil or TI expert

    Add a question about "I2C_BUSY GPIO".

    (5) Is "I2C_BUSY GPIO" enabled with the default firmware?
    If it is valid, which GPIO is set?
    Ans →
    (6) I saw the circuit diagram of EVM (LC4500EVM) of DLPC350.
    I couldn't find the pin corresponding to "I2C_BUSY GPIO" in the connector such as I2C.
    Please give me an example of evaluation with EVM.
    Ans →

    Thank you for your confirmation.
    (1)-(6) We are waiting for your reply next week.

    Regards,

    Tak

  • Hi user,

    The team are looking into these questions and will get back to you next week. 

    Thank you for your patience.

    Regards,

    Lori 

  • (1) Does this signal change for all commands?
    Akhil → If by signal you are refering to I2C_BUSY GPIO. this signal indicates the whether the controller is ready to process next command or not. This depends on the command operation and its execution time.


    (2) Do you know the minimum and maximum busy time?
    Akhil → Will get back on this if there are any actual limits.


    (3) Can you tell me the command whose busy time fluctuates greatly depending on the setting contents of the command?
    Akhil →SInce the busy time depends on the execution of command  and ideally the execution time of each command isn't dynamic.So We are not sure as to what do you mean by byusy time fluctuating. Then again you can use the I2C0 slave read/write commands of different command lengths to see the busy bit duration varying as per the length of the commad.


    (4) Regarding the reading of "busy bit" in "Section 2.4.3.1", in the previous answer, "I2C_BUSY GPIO" was
    I heard it is irrelevant. So do we need to look at both? Which is more accurate if one is possible?
    Akhil → I2C_BUSY GPIO - indicates that command has been processed or not. The busy bit supported by some of the commands is to check the status of that operation that needs to be done as requested using the command. Id you are interested in as to just whether the command execution is completed or not whether it being success/fail you can use the I2C_BUSY GPIO level, else if you want to klnow the status of that specifi operation you can read the the status bit to know. In short it isn;'t always necessary for you to monitor both.

    (5) Is "I2C_BUSY GPIO" enabled with the default firmware?
    If it is valid, which GPIO is set?
    Akhil → Will have to check and get back on this. As per usage you can use these seetings to set in .ini file 
    "PERIPHERALS.I2CBUSYGPIO_ENABLE"  to enable/disable the I 2C Busy Pin functionality, while the "PERIPHERALS.I2CBUSYGPIO_ENABLE" parameter is used to select a particular GPIO pin for this functionality. Valid GPIO numbers for this parameter are : 14,15, 20, 21, 25, 27, 28, 29, 33, 34, 35, 36.


    (6) I saw the circuit diagram of EVM (LC4500EVM) of DLPC350.
    I couldn't find the pin corresponding to "I2C_BUSY GPIO" in the connector such as I2C.
    Please give me an example of evaluation with EVM.
    Akhil → You can use the system board connector on the EVM to do so

    Regards,

    Akhil

  • Hi Akhil or TI expert

    Thanks.
    As for the answers to questions (1), (3), (4), and (6)
    I understand now.

    Check again for (2) and (5).

    (2) Do you know the minimum and maximum busy time?
    Akhil → Will get back on this if there are any actual limits.
    Tak → I2C_BUSY GPIO" cannot be connected in the current device.
    There is a reason for this.
    I understand that the commands used in "Section 2.4.3.1" can be handled by the "busy bit" in the response command.
    However, we do not know the busy time for other commands, and we would like to implement a software weighting system that takes the maximum busy time into account.
    As an example of an answer, I would like to have an answer such as it is okay if I implement a wait time of 100ms after issuing a command.
    Can you please confirm?
    Ans →

    (5) Is "I2C_BUSY GPIO" enabled with the default firmware?
    If it is valid, which GPIO is set?
    Akhil → Will have to check and get back on this. As per usage you can use these seetings to set in .ini file "PERIPHERALS.I2CBUSYGPIO_ENABLE" to enable/disable the I 2C Busy Pin functionality, while the "PERIPHERALS.I2CBUSYGPIO_ENABLE" parameter is used to select a particular GPIO pin for this functionality. Valid GPIO numbers for this parameter are : 14,15, 20, 21, 25, 27, 28, 29, 33, 34, 35, 36.
    Tak → I understand how to set it up.
    Please check and answer about the default firmware setting status.
    Ans →

    In particular, I would like a clear answer to question (2) as soon as possible.

    Regards,

    Tak

  • Tak-san,

    Thanks for your latest update. We will get back to you on the open questions by next week.

    Regards,

    Mayank

  • Hi Tak

    (2) Do you know the minimum and maximum busy time?
    Akhil → Will get back on this if there are any actual limits.
    Tak → I2C_BUSY GPIO" cannot be connected in the current device.
    There is a reason for this.
    I understand that the commands used in "Section 2.4.3.1" can be handled by the "busy bit" in the response command.
    However, we do not know the busy time for other commands, and we would like to implement a software weighting system that takes the maximum busy time into account.
    As an example of an answer, I would like to have an answer such as it is okay if I implement a wait time of 100ms after issuing a command.
    Can you please confirm?
    Akhil → There is no maximum busy time limits set. Using the 100msec should  be sufficient

    (5) Is "I2C_BUSY GPIO" enabled with the default firmware?
    If it is valid, which GPIO is set?
    Akhil → Will have to check and get back on this. As per usage you can use these seetings to set in .ini file "PERIPHERALS.I2CBUSYGPIO_ENABLE" to enable/disable the I 2C Busy Pin functionality, while the "PERIPHERALS.I2CBUSYGPIO_ENABLE" parameter is used to select a particular GPIO pin for this functionality. Valid GPIO numbers for this parameter are : 14,15, 20, 21, 25, 27, 28, 29, 33, 34, 35, 36.
    Tak → I understand how to set it up.
    Please check and answer about the default firmware setting status.
    AKhil → By default the I2C_BUSY_GPIO Implementation is not enabled and no GPIO is selected as you could see the .ini generated when applied default solution 

     PERIPHERALS.I2CBUSYGPIO_ENABLE 0x0 ;
    PERIPHERALS.I2CBUSYGPIO_SELECT 0x0 ;

    Regards,

    Akhil