From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19638 invoked by alias); 24 Feb 2007 17:03:13 -0000 Received: (qmail 19627 invoked by uid 22791); 24 Feb 2007 17:03:11 -0000 X-Spam-Check-By: sourceware.org Received: from main.gmane.org (HELO ciao.gmane.org) (80.91.229.2) by sourceware.org (qpsmtpd/0.31) with ESMTP; Sat, 24 Feb 2007 17:03:03 +0000 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1HL0IH-0008BC-M8 for ecos-discuss@sources.redhat.com; Sat, 24 Feb 2007 18:02:46 +0100 Received: from grante.dsl.visi.com ([208.42.141.248]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 24 Feb 2007 18:02:45 +0100 Received: from grante by grante.dsl.visi.com with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 24 Feb 2007 18:02:45 +0100 To: ecos-discuss@sources.redhat.com From: Grant Edwards Date: Sat, 24 Feb 2007 17:03:00 -0000 Message-ID: References: User-Agent: slrn/0.9.8.1 (Linux) X-IsSubscribed: yes Mailing-List: contact ecos-discuss-help@ecos.sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: ecos-discuss-owner@ecos.sourceware.org Subject: [ECOS] Re: typo in i2c example in reference manual? X-SW-Source: 2007-02/txt/msg00233.txt.bz2 On 2007-02-22, Bart Veer 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