Delays in UART and I2C peripherals

Hello Uthrakumar,

Which TM4C device is this? A TM4C123 or TM4C129 and what system clock frequency is being used?

Regards

Amit

Hello Amit,

  I have working with both Tm4c129 and TM4c123 series. I believe the delay would be propotional to the clock speed ( number of clocks taken for any operating clock).

   Either way I am using at 120MHz and 80MHz respectively.

Thanks

Uthrakumar

Hello Uthrakumar,

You would need to define the delay as well. Please note that in both protocols a write to run bit or data write would be followed by a start condition. This would be active high to low transition. So is this what you would like to measure as well? or is there some other reference point.

Regards

Amit

Hello Amit,

  Yes you are right. I would like to measure the delay between the point writing the data register and the time actually it is changing in the hardware signals.

  My ultimate Aim is to sync both I2C and UART signals in the hardware signals( Both Signal start should be at same time with one or 2 clock difference) . if you would suggest some idea that also helps us.

Thanks

Uthrakumar

Hello Uthrakumar

I hope the one or 2 clock difference is w.r.t System Clock in enabling the two peripherals but not the line side behavior?

Regards
Amit

Hello Amit,

We expect the signals coming out on signal line side ( Hardware signals coming out of chip) to be synced. In other words , The delay between I2C start and UART start we are expecting a very less delay.
This is the reason I wanted to know the delay in start transmitting the data in Hardware signals side after keeping the data in TX register or after triggering it ( for both I2C and UART)

Thanks
Uthrakumar

UTHRAKUMAR ARUMUGANAINAR said:

We expect the signals coming out on signal line side...to be...  very less delay...

Might that prove an "unrealistic" expectation?  And - why do you expect that?    And - what constitutes, "very less delay?"  (our "standards" manual (somehow) misses such "very less"  mention...)

MCU peripherals usually are individually controlled - in decades of MCU use - we've rarely (perhaps never) encountered such a, "peripheral to unrelated peripheral" Sync requirement.

You're aware that you cannot launch two different (unrelated) peripherals at the same time - aren't you?  Perhaps this is what your language struggles with - in describing your real objective.  When such Sync is legitimately required - is it not far more often done, "Off MCU" by other devices designed to that purpose?

And lastly - normal/customary I2C data rates don't "match up" nicely w/normal/customary UART rates - do they?   What then - how do you propose to "maintain" this heralded Sync?

Perhaps if you'd detail "why" this sync between unrelated peripherals is so important - more time/effort can be devoted - your behalf...

Hello Uthrakumar,

I agree with cb1 (100%). The data rates and the format for the two protocols are different so you can match once but be left suffering at Time = 1 day. Please clarify the requirement better.

Regards
Amit

Hi Amit,

One final "deal-breaker" in poster's quest just dawned. (perhaps rises "bit sooner" than your 1 Day alert)  (i.e. after very 1st I2C transmission!)

What happens when the I2C Slave must ACK/NAK?    Is that time sequence - at all - predictable? (we think not!)   Does not that KILL any sync?   What then???
 
Post is not effectively detailed ("very less delay" escapes our ability to quantify) - we cannot recall another post similar (at all) in these unrelated peripheral, sync objectives - and the end goal (why you believe this is required/important) is completely silent.

Those 3 shortcomings - riding w/in one post - (if unresolved/uncorrected) - point strongly to post's, "Not ending well...")  (despite best efforts of hapless helpers...)