i2c basic

hello , i'm a new embedded crusader , i have some basic questions :

how do i know how many nops i must insert between each writing on SDA pin ? (i was looking on google for some help on writing to at24C01 from a

8051) and i found out this

bit clockPulse(void) { bit level; // state of SDA line SCL = 1; _nop_; while(!SCL); //if a pulse was stretched _nop_; _nop_; _nop_; level = SDA; _nop_; _nop_; SCL = 0;//put the scl to low to allow sda changes return(level); }

i've some troubles to understant how the clock pulse works, any help is welcomed , thans !

Reply to
zebulon
Loading thread data ...

You don't. Because that's not the right question to be asking yourself. Doing this in C is begging for trouble. You really have to do low-level work like this in assembler, after having read and understood enough of the data sheet to be able to say exactly how long each instruction will take.

Looking at random source snippets you trawled off the internet is unlikely to help you. Look out for application notes by your CPU's manufacturer and/or the compiler vendor instead.

--
Hans-Bernhard Broeker (broeker@physik.rwth-aachen.de)
Even if all the snow were burnt, ashes would remain.
Reply to
Hans-Bernhard Broeker

I disagree. I've done plenty of I2C in C with no problems. It *is* nicer to do it in assembler, but by no means essential.

To the OP: a NOP inserts a delay. To determine how many NOPs you need, you need to understand: - how long a NOP on your CPU, at your clock speed, takes - how long you want to wait between transitions

FWIW, I tend to use a delay subroutine so that all the NOPs are in one place.

One other point: this is a little dangerous:

Reply to
Steve at fivetrees

[...]

I wasn't referring to I2C as much as to programming micro-delays in C. That's pretty much never a bet worth making. By the time you know that the bet is a safe one to make, you don't need to bet anymore.

Now, I haven't done I2C myself yet, so maybe you're trying to say that I2C doesn't really need control over such delays to work. But even then it would still be the wrong question.

Well, the only alternative is trusting your understanding of the C compiler used, to the point that you're *sure* the timing of the code will never change magically, e.g. by common tail elimination turning two similar routines like this into one.

and

- how exactly C source relates to machine code.

By the time you've found out that out beyond reasonable doubt, it will have been easier to just write the thing in asm.

C makes exactly no promise at all about timing of the target code. If you need control over size or speed of the code at the level of individual machine instructions, C is the wrong tool to get it. C is, despite all statements to the contrary, not a macro-assembler. Pretendding otherwise will break your code one day in a way that, by then, you will no longer have the instincts to anticipate.

--
Hans-Bernhard Broeker (broeker@physik.rwth-aachen.de)
Even if all the snow were burnt, ashes would remain.
Reply to
Hans-Bernhard Broeker

Ah, ok.

It does need control, but not fine control. So long as the max clock rate isn't exceeded, the timing is very loose.

I understand your point. However, as mentioned above, the timing can be quite loose.

Yes, you're right. However on a specific embedded (i.e. where the clock doesn't double every 6 months ;)) platform, and with appropriate precautions, it's not hard. I've usually seen the timing tuned empirically with a 'scope - the delays are measured and tweaked until they're well away from the max (at least 2:1, if not greater). I've also seen generous warnings in the code to the effect of "if the clock changes, or if the compiler optimisation level changes, this delay needs to be recalculated". The former will also affect assembler, FWIW; but the latter is definitely a trap.

Personally, I try to avoid hard-coded delays where I can (see my earlier comment re a hardware timer), unless they're trivial. Most of the time, I2C delays fit in the "trivial" bracket.

Steve

formatting link

Reply to
Steve at fivetrees

ok , but reading datasheet is useless for my problem of delay/transition because i don't even know why i should put nop here ??? yes i'm an horrible newbie , i beg your pardon ...

Reply to
zebulon

The reason is setup and hold times.

Setup time is the amount of time between the time the data is output and the reader (slave) can recognize it. Hold time is the amount of time the data must stay to insure the reader get it right. In I2C the bus maybe very capacitive. This means after a transition the new data does not just snap to the new value.

the sequence goes something like this.

Output data. wait ... NOP(S) clock high. wait for clock to go high. wait ... NOP(S) clock low. wait ... NOP(S)

repeat....

You IC data sheet should show the times.

You did not say what CPU you are using. That and the compiler may help you get an answer. The primary delay in I2C is 4.7uS (if I remember correctly) One technique is to put the correct number of NOPs in an asm function. Then call it for the delay. This will be longer than needed due to the call. You can trim it or leave it. Or just inline the NOPs.

If you are not sure and can not figure it out. Put in too many NOPs. I2C works down to DC. So too many will work, while too few will not.

Reply to
Neil

ok , thanks a lot , i understand better now. the mc used to drive the process is an at89c51.

maybe the datasheet is useful but i've no electronic experience...

thanks

Reply to
zebulon

Maybe take a look at:

formatting link
formatting link
of data there re I2C. (Philips are the originators of I2C.)The I2C spec is at:
formatting link
formatting link
electronics experience: so long as the bus hardware is implemented withinspec, then you don't need to worry too much about the details (setup/holdtimes, capacitance etc) - just ensure that your maximum bus frequency isn'texceeded. (I can't tell you what that is without knowing which devicesyou're using, since there are several specs; but 100kHz should work withanything, IIRC. This means >= 5us for each low/high clock state.)Steve
formatting link

Reply to
Steve at fivetrees

formatting link

formatting link

Gah. It really is time I tried another news client.

I'll try again:

Maybe take a look at:

formatting link

or

formatting link

Plenty of data there re I2C. (Philips are the originators of I2C.)

The I2C spec is at:

formatting link

or

formatting link

Re electronics experience: so long as the bus hardware is implemented withinspec, then you don't need to worry too much about the details (setup/hold times, capacitance etc) - just ensure that your maximum bus frequency isn't exceeded. (I can't tell you what that is without knowing which devices you're using, since there are several specs; but 100kHz should work with anything, IIRC. This means >= 5us for each low/high clock state.)

Steve

formatting link

Reply to
Steve at fivetrees

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.