• State Resolved
  • Locked Locked
  • Replies 4 replies
  • Subscribers 81 subscribers
  • Views 666 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.

Concerto F28M35 I2C bus question

Ronaldo Pace
Intellectual 875 points


Hi,

I'm with a philosophical concern regarding the utilisation of the dual-core and the I2C bus.

On my application M3 will be doing what M3 is supposed to do: ethernet communication, digital IO (on-off) control, serial interface with the screen, and general operation sequencing.

And C28 will be doing what C28 is supposed to do: *** loads of complex math with the analogue IO.

The point is, we will be using some very specialised high precision analogue I/O through the I2C bus and there is where my question is: Who should control the I2C bus?

a) M3 should take over the I2C and pass its values to C28 via IPC

    or

B) C28 should deal with the I2C by itself? Read I2C -> Process math algorithm -> Write I2C

I'm very beginner with TI controllers and a help from the experts will be very much appreciated. Thanks!

  • 0
    TI__Guru 57255 points

    Ronaldo,

    Both options are valid.  However, I would implement option B because it's less complex.  (assuming the mux will allow you to use C28x_I2C, M3_Enet and whatever other peripherals you hope to use at the same time)

    The C28x already has to handle dealing with a peripheral (IPC) in option A, so it may as well be doing I2C instead.  This will result in less handshaking in your system.


    Thank you,
    Brett

  • 0 in reply to Brett Larimore
    Intellectual 875 points

    Hi Brett,

    Thanks for the reply, but it was based on a wrong assumption (I should have better explained the system).

    ICP between C28 and M3 will already happen regardless of anything.

    M3 will read EEPROM parameters and pass to C28, M3 will receive messages from Ethernet (start, stop, change parameters) that will be passed to C28 too, in case C28 is reading the I2C, it will be passing back its values to M3 to be send over ethernet for monitoring purposes. I still have to dig into IPC or shared RAM (or probably a mix of those) issue to how I'll deal with those handshaking, but that's a different subject.

    Point is: regardless of the I2C path I choose, M3 and C28 will be heavily interconnected.

    Does this change your answer?

  • 0 in reply to Ronaldo Pace
    TI__Guru 57255 points

    Ronaldo,

    Perhaps, but not necessarily. :)

    I would then wonder about how timing critical the I2C is. Getting the I2C through the IPC will add some latency on top of the handshaking necessary on the M3 to move the I2C data to the IPC peripheral (about 150-250ns with some variability).  If your system can handle some latency between when the I2C data comes in to the chip and when it gets used by the C28x algorithm (which I assume you can), you shouldn't have an issue doing the I2C on the M3 side if you desire.

    After that concern is handled, I think you can safely choose either.  I'd do it based on which peripheral you're most familiar with.  For me that would be the C28x.  If you've not used either, the M3 core may have a slight advantage.


    Thank you,
    Brett

  • 0 in reply to Brett Larimore
    Intellectual 875 points

    Well,

    considering that effectively those signals are temperature ... I don't see how a few nanoseconds will make a difference.

    And it's my very first TI processor, and I'll already have to learn how to do the I2C on the M3 to interface the EEPROM, so I'll just get everything via M3 and leave C28x as free as possible to just process stuff.

    thanks!