Date: 5 Dec 2016 09:16:38 +0200 From: "HYDROSYST LTD" <pro@hydrosyst.eu> To: freebsd-arm@FreeBSD.org Subject: PERMANENT MAGNET GENERATORS
| raw e-mail | index | archive | help
PGh0bWw+PGJvZHk+PFA+PEZPTlQgY29sb3I9IzgwODA4MD5MT1cgU1BFRUQgUEVSTUFO RU5UIE1BR05FVCBHRU5FUkFUT1JTPC9GT05UPjwvUD4NCjxESVY+PEZPTlQgY29sb3I9 IzY2NjY2NiBzaXplPTMgZmFjZT1DYWxpYnJpPkdlbmVyYXRvciBwb3dlciByYW5nZSBp cyA1IGtXLTUgTVcgYW5kIG1vcmUuIDwvRk9OVD48Rk9OVCBzaXplPTM+PFNQQU4gbGFu Zz1lbiBpZD1yZXN1bHRfYm94IGNsYXNzPXNob3J0X3RleHQ+PEZPTlQgY29sb3I9Izgw ODA4MD48Rk9OVCBmYWNlPUNhbGlicmk+PFNQQU4+QWJpbGl0eSB0byB3b3JrPC9TUEFO PiA8U1BBTj51bmRlcjwvU1BBTj4gPFNQQU4+d2F0ZXIuPC9TUEFOPjwvRk9OVD48L0ZP TlQ+PC9TUEFOPjwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgY29sb3I9IzY2NjY2NiBz aXplPTMgZmFjZT1DYWxpYnJpPlNwZWVkIHJhbmdlIDEwLTEyMDAgcnBtLiBGcmVxdWVu Y3kgNTAgb3IgNjAgSHouPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBjb2xvcj0jNjY2 NjY2IGZhY2U9Q2FsaWJyaT5UaGVzZSBjaGFyYWN0ZXJpc3RpY3MgbWFrZSBpdCB2ZXJ5 IHN1aXRhYmxlIGZvciB3aW5kIGFuZCB3YXRlciB0dXJiaW5lLiA8L0ZPTlQ+PC9ESVY+ DQo8RElWPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBjb2xvcj0jNjY2NjY2IHNpemU9 MyBmYWNlPUNhbGlicmk+TW9yZSBpbmZvcm1hdGlvbiBjYW4gYmUgc2VlIGhlcmUgPEEg aHJlZj0iaHR0cDovL3d3dy5lbmVyc2V0LmV1LyI+d3d3LmVuZXJzZXQuZXU8L0E+PC9G T05UPjwvRElWPjwvYm9keT48L2h0bWw+ From owner-freebsd-arm@freebsd.org Mon Dec 5 08:56:00 2016 Return-Path: <owner-freebsd-arm@freebsd.org> Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 27965C66783 for <freebsd-arm@mailman.ysv.freebsd.org>; Mon, 5 Dec 2016 08:56:00 +0000 (UTC) (envelope-from manu@bidouilliste.com) Received: from mail.blih.net (mail.blih.net [212.83.177.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.blih.net", Issuer "mail.blih.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id A45DCF06 for <freebsd-arm@freebsd.org>; Mon, 5 Dec 2016 08:55:59 +0000 (UTC) (envelope-from manu@bidouilliste.com) Received: from mail.blih.net (mail.blih.net [212.83.177.182]) by mail.blih.net (OpenSMTPD) with ESMTP id 5726a9b3; Mon, 5 Dec 2016 09:49:16 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=bidouilliste.com; h=date :from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-type:content-transfer-encoding; s=mail; bh=yjitYqmiBRyuSXzYrBGaMG4sSMg=; b=DIeYpqvopF7IRvpNFLfUvxp61fGW /VGiDGMaVZHFU0iD4J77I1jLh0VJ9eIgaBiOxb6L5tLk/ObA0ErjHXiWM184MJL6 Zk4dBY4S8jKDCTjY/l3pQampyHG6p7MZZYxoXNfHXGn8t+6R78dk9BOu5OMPZWJK 3K32u4CV4FQVRVI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=bidouilliste.com; h=date :from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-type:content-transfer-encoding; q=dns; s= mail; b=MpyjU1yiTpiyI6YoKYB8oSBSC6J15oSLSbGCXknpL31FmJxfMFhcZbHO CDVmPuPeDY7eUfDfD+sdBJ3jGgT9LVYsieTtxEeiwTItwBKk2/adP4CVOI39/dId 3XoghSwaEYzv+q/wK2K5uO29IxQ1jAJShcSBbzeQr8DTPYA3OjQ= Received: from knuckles.blih.net (ip-54.net-82-216-203.roubaix.rev.numericable.fr [82.216.203.54]) by mail.blih.net (OpenSMTPD) with ESMTPSA id 43e263d9 TLS version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO; Mon, 5 Dec 2016 09:49:16 +0100 (CET) Date: Mon, 5 Dec 2016 09:49:15 +0100 From: Emmanuel Vadot <manu@bidouilliste.com> To: Oleksandr Tymoshenko <gonzo@bluezbox.com> Cc: Nick Hibma <Nick@ip-knowhow.com>, freebsd-arm@freebsd.org Subject: Re: Questions about i2c.c (TMP102 temperature sensor) Message-Id: <20161205094915.20847444789f803133b56af9@bidouilliste.com> In-Reply-To: <58B43D61-0B46-4310-868F-D7336585731B@bluezbox.com> References: <9424D7FD-C4B6-43D5-A0C5-76D5BE9ED1DE@ip-knowhow.com> <58B43D61-0B46-4310-868F-D7336585731B@bluezbox.com> X-Mailer: Sylpheed 3.5.1 (GTK+ 2.24.29; amd64-portbld-freebsd12.0) Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." <freebsd-arm.freebsd.org> List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-arm>, <mailto:freebsd-arm-request@freebsd.org?subject=unsubscribe> List-Archive: <http://lists.freebsd.org/pipermail/freebsd-arm/>; List-Post: <mailto:freebsd-arm@freebsd.org> List-Help: <mailto:freebsd-arm-request@freebsd.org?subject=help> List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-arm>, <mailto:freebsd-arm-request@freebsd.org?subject=subscribe> X-List-Received-Date: Mon, 05 Dec 2016 08:56:00 -0000 On Fri, 2 Dec 2016 13:11:34 -0800 Oleksandr Tymoshenko <gonzo@bluezbox.com> wrote: > Switching freebsd-embedded@ to freebsd-arm@ since the former does not get= as much attention as the latter. >=20 > > On Dec 1, 2016, at 2:11 AM, Nick Hibma <Nick@ip-knowhow.com> wrote: > >=20 > > Gents, > >=20 > > I am not quite sure who to owner of i2c.c is, so perhaps some I2C entho= usiast could help me with the following problem. > >=20 > > I was trying to access a TMP102 I2C temperature sensor. It kind of work= s with the default i2c utility. But it returns twice the high byte instead = of the high and low byte for the temperature. Probably because it does 1 by= te reads on the I2C bus, sending a stop condition after every byte. This wa= s verified with a logic analyser. > >=20 > > The device expects continuous reads and no stop/start in between the 2 = bytes. Trying all options i2c, most notably the -m mode switch, yields the = same results all the time. Looking at the code in i2c.c I get confused as = it seems to somehow fiddle with start/stop to get it right because of the -= m switch, but uses read() in the end to get the data, not I2CREAD. > >=20 > > fd =3D open(dev, O_RDWR); > > if (i2c_opt.width) { > > error =3D ioctl(fd, I2CSTART, &cmd); > > error =3D ioctl(fd, I2CWRITE, &cmd); > > if (i2c_opt.mode =3D=3D I2C_MODE_STOP_START) { > > error =3D ioctl(fd, I2CSTOP, &cmd); > > } > > } > > if (i2c_opt.mode =3D=3D I2C_MODE_STOP_START) { > > error =3D ioctl(fd, I2CSTART, &cmd); > > } else if (i2c_opt.mode =3D=3D I2C_MODE_REPEATED_START) { > > error =3D ioctl(fd, I2CRPTSTART, &cmd); > > } > > /******** Without i2c_opt.width set there is no START condition either = to set the slave address for the read() ****/ > > /******** Why this stop? ***/ > > error =3D ioctl(fd, I2CSTOP, &cmd); > > for (i =3D 0; i < i2c_opt.count; i++) { > > error =3D read(fd, &i2c_buf[i], 1); > > } > > close(fd); > >=20 > > I would have expected: > >=20 > > fd =3D open(dev, O_RDWR); > > if (i2c_opt.width) { > > error =3D ioctl(fd, I2CSTART, &cmd); > > error =3D ioctl(fd, I2CWRITE, &cmd); > > if (i2c_opt.mode =3D=3D I2C_MODE_STOP_START) { > > error =3D ioctl(fd, I2CSTOP, &cmd); > > error =3D ioctl(fd, I2CSTART, &cmd); > > } else if (i2c_opt.mode =3D=3D I2C_MODE_REPEATED_START) { > > error =3D ioctl(fd, I2CRPTSTART, &cmd); > > } > > } else { > > /***** Use START/STOP to set the slave address for the read() below ***/ > > error =3D ioctl(fd, I2CSTART, &cmd); > > error =3D ioctl(fd, I2CSTOP, &cmd); > > } > > error =3D ioctl(fd, I2CREAD, &cmd); // read all bytes in one go > > error =3D ioctl(fd, I2CSTOP, &cmd); > > close(fd); > >=20 > > Any opinions on where I am wrong? >=20 > There is no need for I2CSTART/I2CSTOP sequence, there is I2CSADDR > ioctl for that purpose. I agree that i2c tool looks broken from quick > glance, but someone with more knowledge should take a look. >=20 > > Second question: > >=20 > > Rolling my own little program with this change fails because I cannot g= et I2CREAD to work. It keeps returning EIO. Some other web pages claim that= there is an implementation problem with that. Using read() on the fd works= fine, so do get a valid temperature out of the device now. >=20 >=20 > I picked up TMP102 as a device to test I2C drivers for new boards and > wrote C application to talk to it. I used RPi as a reference > platform. The problem with I2C driver on RPi is that it does not > support sending explicit START/STOP conditions. So all ioctl(I2CSTART) > and ioctl(I2CSTOP). And READ/WRITE does not work without explicit > START. So I ended up working around it using I2CRDWR. For some > other boards it probably can be written with START/WRITE/READ/STOP, > or with read/write. I?m going to spend some time and get this app > working on all boards I have to get a general feeling of what bits of > I2C are supported on them what are not.=20 >=20 > Source code: https://people.freebsd.org/~gonzo/tmp102.c > _______________________________________________ > freebsd-arm@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" I have an updated version of i2c(8) which support I2CRDWR here : https://github.com/evadot/freebsd/tree/i2c_rdrw/usr.sbin/i2c I didn't commit it just because I want to make I2CRDWR the default since there is iicbus_transfer_gen. I just need to make sure that it works almost everwhere (it does on allwinner board where the driver doesn't support I2CRDWR at least). Can you test using i2c(8) from my branch with your device ? --=20 Emmanuel Vadot <manu@bidouilliste.com> <manu@freebsd.org>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?>