[ECOS] Re: typo in i2c example in reference manual?

[Grant Edwards <grante at visi dot com>]

On 2007-02-22, Bart Veer <bartv@ecoscentric.com> wrote:

> On processors which have dedicated I2C bus master support (as
> opposed to bitbanging GPIO lines) the delay is likely to be
> exact since it will be used to set a clock register within the
> I2C hardware.

Probably true

> For a bit-banged bus the delay should be accurate to within a
> few percent,

OK, let's do some math.

On every I2C bus I've ever seen the clock period was 2500ns.

There are two sources of error which directly sum: inaccuracy
in HAL_DELAY_US() and overhead.  

We'll assume HAL_DELAY_US() has zero error.  That allows us "a
few percent" of 2500us for overhead (we'll say 3%). We have
37ns per half-bit for overhead.

We're talking about a 44MHz CPU, so a single CPU clock is 23ns.
I'm going to claim I should be allowed 1 cpu clock for my one
machine instruction set/clear an I/O bit.  That means we now
have 14ns per half-bit left over for all of the C/C++ overhead.

That's about 1/4 of an average machine instruction execution
time (which is about 2 clock cycles).  1/4 of a machine
instruction for C++ code that's shifting data around in a loop
while making indrect calls through structure fields to a
function that's executing a switch statement.

> which should be good enough for all practical purposes. It
> will not be any more accurate than that because HAL_DELAY_US()
> is not expected to be any more accurate than that.

I've assumed HAL_DELAY_US() has 0 error, yet expecting the
delay in a bit banged driver to be within a few percent is
clearly unrealistic.

> There is a reasonable assumption here that the low-level
> bitbang operations are sufficiently cheap as to be negligible.

No, that's just not a reasonable assumption.  On a 44MHz CPU
which executes an average of 1 instruction every 2 clock
cycles, an instruction time is 45ns.  A half-bit time is
1250ns.  That means that you can execute about 28 machine
instructions per half bit.  

Simply calling dm2_i2c_bitbang(bus,op) is using up over 100% of
the available time.  Adding another layer of C++ code on top of
that uses up 2000% percent of the available time.  

How can we add another 100% for HAL_US_DELAY() and expect the
result to be accurate to within a few percent?

-- 
Grant Edwards                   grante             Yow!  ... Just enough
                                  at               time to do my LIBERACE
                               visi.com            impression...


-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss