• State TI Thinks Resolved
  • Locked Locked
  • Replies 5 replies
  • Answers 2 answers
  • Subscribers 83 subscribers
  • Views 797 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

TMS320F280049: Piccolo processor with 2* I2C bus?

Chris van der Aar
Intellectual 570 points
Part Number: TMS320F280049
Other Parts Discussed in Thread: LAUNCHXL-F280049C, , TMS320F28075, LAUNCHXL-F28379D, TMDSDOCK28379D

For a new project we need a T.I. DSP with 2* I2C bus (and SPI and enough memory). For this project we prefer the TMS320F28xx series.The two I2C busses are needed for reading pressure sensors with I2C interface (for controlling pumps) so the 2 busses will have the same functionality here. These sensors require a standard I2C interface and are not individually adressable. When I look in the overview of the TMS320F28xx series there are 2 possible candidates with 2* I2C bus:

- TMS320F28004x

- TMS320F2807x

However the TMS320F28004x has 1* I2C and 1*PMBUS.

So what would you suggest here? Can we use the PMBUS in the same way as I2C or are there any software issues when using this bus for I2C?

The TMS320F28004x looks something cheaper but some suppliers here in Europe (like EBV/AVNET) does not have them at stock at this moment and we want to be sure that we don't get problems with stock the next months. 

And are there evaluation kits available for these processors?


Regards


Chris van der Aar

NTS Systems Development

Eindhoven , The Netherlands

  • 0
    TI__Guru** 119670 points
    Yes, PMBus can be used as I2C
    Please see chapter 26.1 of the TRM for F28004x
    SPRUI33

    The F28004x just started production this year, so most distributors are ordering from TI on an as-needed basis. We typically only stock low volume sample quantities of the superset version TMS320F280049C

    yes, there is a low cost LAUNCHXL-F280049C as the starting development tool
  • 0 in reply to ChrisClearman
    Intellectual 570 points

    Ok everything clear.

    However 1 question regarding the TMS320F280049 DSP. We need SPI for communication with an external Powerlink module for communcation with a PLC and 2x I2C for communication with sensors. These sensors are part of a control loop that will run locally within the DSP and this will run continously because we have to control pumps by measuring pressure and flow via the I2C bus. When we look to the datasheet of the TMS320F280049 the PMBUS is shared with the SPI bus on a PF2 block (Peripheral Frame) and according the technical ref manual (SPRUI33) this can lead to conflicts:

    Typically, DMA activity is independent of CPU and CLA activity. However, when the DMA and CPU (or CLA) try to access the same peripheral at the same time, an arbitration procedure is required to resolve the conflict.

    Conflict Example: The CPU is accessing an SPI FIFO while the DMA is simultaneously accessing a PMBus register.

    So we are wondering if the SPI communication could have impact on the performance of the PMBUS when communication is running simultaneously?

    The TMS320F28075 has separate I2C busses (not shared with SPI on a peripheral frame) so do you think that this will have less impact on communication on both I2C busses? In fact we use the 2 I2C busses in the same way. Each bus contain the same sensors and both control loops have to run simultaneously (max 400Khz I2C clock).

    And do you have a low cost development kit for the TMS320F28075 if we would decide to choose this DSP?


    Regards Chris

  • 0 in reply to ChrisClearman
    Intellectual 570 points

    Ok everything clear.

    However 1 question regarding the TMS320F280049 DSP. We need SPI for communication with an external Powerlink module for communcation with a PLC and 2x I2C for communication with sensors. These sensors are part of a control loop that will run locally within the DSP and this will run continously because we have to control pumps by measuring pressure and flow via the I2C bus. When we look to the datasheet of the TMS320F280049 the PMBUS is shared with the SPI bus on a PF2 block (Peripheral Frame) and according the technical ref manual (SPRUI33) this can lead to conflicts:

    Typically, DMA activity is independent of CPU and CLA activity. However, when the DMA and CPU (or CLA) try to access the same peripheral at the same time, an arbitration procedure is required to resolve the conflict.

    Conflict Example: The CPU is accessing an SPI FIFO while the DMA is simultaneously accessing a PMBus register.

    So we are wondering if the SPI communication could have impact on the performance of the PMBUS when communication is running simultaneously?

    The TMS320F28075 has separate I2C busses (not shared with SPI on a peripheral frame) so do you think that this will have less impact on communication on both I2C busses? In fact we use the 2 I2C busses in the same way. Each bus contain the same sensors and both control loops have to run simultaneously (max 400Khz I2C clock).

    And do you have a low cost development kit for the TMS320F28075 if we would decide to choose this DSP?


    Regards Chris

  • 0 in reply to Chris van der Aar
    TI__Guru** 119670 points

    I'll assign the SPI question to an expert.

    For F28075 we recommend you use the superset Delfino F28379D tools: LAUNCHXL-F28379D or TMDSDOCK28379D

    F28075 is fully a subset of this device

  • 0 in reply to ChrisClearman
    TI__Guru 60865 points
    Hi Chris,

    The arbitration will only occur when the CPU, DMA, and/or CLA try to read or write to multiple memory addresses in the same peripheral frame on the same cycle. If you aren't planning to use DMA or CLA to offload communications servicing, then you won't have any issues.

    Even if you use the DMA or CLA, it should be OK. The arbitration will only delay one of the concurrent memory transactions, and only briefly. If you look at the priority, DMA or CLA has priority over CPU, so you can reduce the FIFO size for whatever peripheral is getting serviced in the background so that foreground reads/writes by the CPU are minimally delayed when a collision occurs. Even in the worst case where, for example, the DMA is filling the full 16-message SPI TX FIFO, a read or write to the PMBUS would be delayed by at most the duration of the 16 word DMA memory transaction, which should still be reasonably brief compared to even a single I2C bit-time.