From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29753 invoked by alias); 23 Feb 2007 04:28:29 -0000 Received: (qmail 29743 invoked by uid 22791); 23 Feb 2007 04:28:28 -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; Fri, 23 Feb 2007 04:28:23 +0000 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1HKS2U-0001gL-S2 for ecos-discuss@sources.redhat.com; Fri, 23 Feb 2007 05:28:10 +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 ; Fri, 23 Feb 2007 05:28:10 +0100 Received: from grante by grante.dsl.visi.com with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 23 Feb 2007 05:28:10 +0100 To: ecos-discuss@sources.redhat.com From: Grant Edwards Date: Fri, 23 Feb 2007 04:28: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/msg00222.txt.bz2 On 2007-02-22, Bart Veer wrote: > Grant> Changing a pin state requires a single instruction on my > Grant> platform. Still, setting the delay parameter to 0 results > Grant> in a SCK period of 50,000ns. Setting the delay parameter to > Grant> a non-zero value adds to that 50,000ns. [I'm running on a > Grant> NIOS2 CPU at 44MHz.] > > So apparently it takes 25us to change a pin state. Sounds like > there is a big problem somewhere. It sure does. I took a look at the C++ code, and I don't see how there could be that much overhead anywhere. > 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. For a bit-banged bus the delay should be > accurate to within a few percent, which should be good enough > for all practical purposes. There's got to be something wrong with my hardware platform -- not that I'd be surprised, the NIOS2 has been a giant headache from the beginning. > It will not be any more accurate than that because > HAL_DELAY_US() is not expected to be any more accurate than > that. There is a reasonable assumption here that the low-level > bitbang operations are sufficiently cheap as to be negligible. I'm also going to take a look at the HAL_DELAY_US() macro. Altera's NIOS2 eCos port has also been the source of headaches. >>> Under what circumstances does it make sense to write zero bytes >>> of data? > > Grant> The datasheet for the EEPROM I'm using states that in order > Grant> to determine if a write cycle has completed, one should > Grant> should send an address/control byte with the r/*w bit > Grant> cleared. If that byte is acked, then the write cycle is > Grant> finished. If it isn't then the write cycle is still in > Grant> progress. I've determined that sending an extra byte after > Grant> the control byte doesn't seem to hurt anything, but I'd > Grant> prefer to do things according to the datasheet. > > So the EEPROM will not acknowledge the address byte immediately after > the start condition. Correct (if it's busy). If it's not, it will ack the address byte and the subsequent data byte which is written into a pointer register. > cyg_i2c_bitbang_tx() should detect this and return immediately > after the address byte, with no attempt to send the data byte. > As long as the data byte is effectively a no-op when the write > cycle has completed and the EEPROM does accept the data byte, > no harm will be done. As far as I can tell, it's effectively a noop if you follow it with another write command to set the register back to the desired state. The datasheet seems quite explicit that the address byte (either acked or not) is followed by another start condition and then the command you actually want to execute. But, I can't see any reason why you can't send a data byte along with the address byte. > There is a marginal inefficiency in that your polling code > ends up transmitting one unnecessary byte, and arguably the > I2C API should have allowed for this case, but I do not think > it is worth changing the API at this stage. Proably not. -- Grant Edwards grante Yow! An Italian is COMBING at his hair in suburban DES visi.com MOINES! -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss