From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7667 invoked by alias); 23 Apr 2013 07:01:06 -0000 Mailing-List: contact ecos-patches-help@ecos.sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: ecos-patches-owner@ecos.sourceware.org Received: (qmail 7629 invoked by uid 89); 23 Apr 2013 07:01:06 -0000 X-Spam-SWARE-Status: No, score=-2.8 required=5.0 tests=AWL,BAYES_00,KHOP_RCVD_UNTRUST,KHOP_THREADED,RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.1 Received: from hagrid.ecoscentric.com (HELO mail.ecoscentric.com) (212.13.207.197) by sourceware.org (qpsmtpd/0.84/v0.84-167-ge50287c) with ESMTP; Tue, 23 Apr 2013 07:01:04 +0000 Received: from localhost (hagrid.ecoscentric.com [127.0.0.1]) by mail.ecoscentric.com (Postfix) with ESMTP id 3A371468000F for ; Tue, 23 Apr 2013 08:01:02 +0100 (BST) Received: from mail.ecoscentric.com ([127.0.0.1]) by localhost (hagrid.ecoscentric.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tXPDG7M0C935; Tue, 23 Apr 2013 08:00:55 +0100 (BST) From: bugzilla-daemon@bugs.ecos.sourceware.org To: ecos-patches@ecos.sourceware.org Subject: [Bug 1001397] I2C driver for Kinetis microcontrollers Date: Tue, 23 Apr 2013 07:01:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: eCos X-Bugzilla-Component: Patches and contributions X-Bugzilla-Keywords: X-Bugzilla-Severity: enhancement X-Bugzilla-Who: ilijak@siva.com.mk X-Bugzilla-Status: NEEDINFO X-Bugzilla-Priority: low X-Bugzilla-Assigned-To: ilijak@siva.com.mk X-Bugzilla-Target-Milestone: --- X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://bugs.ecos.sourceware.org/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-SW-Source: 2013-04/txt/msg00068.txt.bz2 Please do not reply to this email, use the link below. http://bugs.ecos.sourceware.org/show_bug.cgi?id=3D1001397 --- Comment #58 from Ilija Kocho --- (In reply to comment #57) > I get the same conservative frequency no matter how > CYGNUM_DEVS_FREESCALE_I2C_CLOCK_AGR is set. That means that it is the closest frequency to the set-point (i.e. the clos= est higher frequency would give larger error). The frequency selection is rather coarse so there's little help, given the system clock frequency. By experimenting I have noticed that if system clock is 100MHz (rather than current 96MHz) we get better match for 100Khz (and 400Khz). Also with inf t= hat case the aggressive lookup gives closer (upper) match than conservative. >=20 > I have given the code below, which I know ignores the delay specified in = the > CDL. Is there a different way to write the code so that the delay and AGR= of > the CDL get applied? Just set i2c_delay (i.e. i2c_bus_time) to 0. Instead of infinite frequency = it will give you the default one. For example: cyg_i2c_device device =3D { .i2c_bus =3D &cyg_i2c0_bus, .i2c_address =3D address, .i2c_flags =3D 0, .i2c_delay =3D 0 }; See other examples for enforcing FIT and aggressive lookup in comment 54. Some [off topic] remarks to the code below: device is automatic variable that means it's being initialized every time t= he function is called. It's very inefficient. Setting i2c_delay =3D 0 shall m= ake initialization far much efficient since the clock lookup once executed dur= ing initialization of the I2C bus, in subsequent calls will use cached F regist= er setting. However the code is still less efficient than what's possible, bec= ause the device structure ans device itself shall be initialized on every functi= on call. The better way is to declare device as static variable (spend little-= bit memory but save little-bit stack and little-bit more CPU time). However, I = can imagine that you use the same (hardware) device from other functions. If it= is true, than device should be a global variable. >=20 > uint16_t smbus_read_word(uint8_t address, uint8_t command) > { > cyg_i2c_device device =3D { \ > .i2c_bus =3D &cyg_i2c0_bus, \ > .i2c_address =3D address, \ > .i2c_flags =3D 0, \ > .i2c_delay =3D i2c_bus_time \ > }; > cyg_uint8 buffer[1]; > cyg_uint8 input[2]; > buffer[0] =3D command; >=20 > cyg_i2c_transaction_begin(&device); > if(!cyg_i2c_transaction_tx(&device, true, &buffer[0], 1, false)) { > diag_printf("Read Word: fail TX.\n"); > } else if(!cyg_i2c_transaction_rx(&device, true, &input[0], 2, true, tru= e)) > { > diag_printf("Read Word: fail RX.\n"); > } > cyg_i2c_transaction_end(&device); >=20 > return input[1] << 8 | input[0]; > } --=20 You are receiving this mail because: You are on the CC list for the bug.