From owner-freebsd-arm@FreeBSD.ORG Tue Aug 26 23:21:24 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 96B39F72 for ; Tue, 26 Aug 2014 23:21:24 +0000 (UTC) Received: from capeta.freebsdbrasil.com.br (capeta.freebsdbrasil.com.br [177.10.156.3]) by mx1.freebsd.org (Postfix) with SMTP id DA7183FB8 for ; Tue, 26 Aug 2014 23:21:23 +0000 (UTC) Received: (qmail 84893 invoked from network); 26 Aug 2014 20:21:07 -0300 Received: by simscan 1.4.0 ppid: 84889, pid: 84891, t: 0.0059s scanners:none Received: from unknown (HELO darwin.bh.freebsdbrasil.com.br) (eksffa@freebsdbrasil.com.br@10.69.69.7) by capeta.freebsdbrasil.com.br with ESMTPA; 26 Aug 2014 20:21:07 -0300 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: HC-SR04 and FreeBSD From: Patrick Tracanelli In-Reply-To: Date: Tue, 26 Aug 2014 20:21:08 -0300 Content-Transfer-Encoding: quoted-printable Message-Id: <411C643B-BC46-494E-919B-39098FB87EEA@freebsdbrasil.com.br> References: <5D802942-2D0F-4324-8212-C2871EEB6327@FreeBSD.org> <01562FB1-32C6-45AF-AB77-5BB80526E18C@FreeBSD.org> <53F8FED8.6030409@freebsdbrasil.com.br> <3949AF9C-B5BD-44E8-A049-21F26B8B6B9A@freebsdbrasil.com.br> To: Luiz Otavio O Souza X-Mailer: Apple Mail (2.1878.6) Cc: "freebsd-arm@freebsd.org" , Rui Paulo X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Aug 2014 23:21:24 -0000 On 26/08/2014, at 16:27, Luiz Otavio O Souza wrote: > On 25 August 2014 16:57, Patrick Tracanelli wrote: >> On 24/08/2014, at 19:29, Evandro Nunes wrote: >>>> On Sat, Aug 23, 2014 at 5:51 PM, Patrick Tracanelli wrote: >>> Hello, >>>=20 >>> As far as I know, for this specific ultrasonic sensor, you are = missing >>> to set the echo GPIO pin to high. This sonar sensor will bring it = back >>> to 0 when the triggered sound get back to the sensor (round-trip). >>>=20 >>> So the correct sequence should be, in a loop: >>>=20 >>> 1 - Set echo pin to HIGH >>> 2 - Trigger the sensor for 10us (it means your 100ms is more than = you >>> need, but no, it won=92t cause a problem) >>> 3 - Wait until echo in is LOW >>>=20 >>> When the sound come back to sensor, the device will LOW the GPIO pin = again. >=20 > No, this is not correct, setting a value to an input is a noop and > when you need this kind of cooperation from both sides, you usually > will be using a pull-up and open colector outputs (they never drive > the output to 'high' to avoid short-circuits). Yes, I was not clear, that=92s why I did some tests and sent the other = e-mail. You won=92t set anything, you will measure how long it was set = to high. >> What you wanna do is to measure how long HIGH takes. >>=20 >> I just made a better test so you can actually "see" the sensor = working. Run this more simple loop: >>=20 >> gpioctl -c 2 IN >> gpioctl -c 3 OUT >> gpioctl 3 0 >>=20 >> while true ; do >> gpioctl 3 1 ; sleep .10; gpioctl 3 0 >> while [ $(gpioctl 2 | tail -1) -gt 0 ] ; do >> echo "..." #nada >> done >> sleep 1 >> done >>=20 >> On a second shell, run this horrible cpu consuming loop: >>=20 >> sh -c "while true ; do /root/date-precisao && gpioctl 2 ; done" >=20 > This one is okay, That=92s it, my best shot to be clear about this specific sensor = behavior. >> Yes, you are right, I personally agree some library with basic = electronic functions would be very valuable to FreeBSD. >>=20 >> Good to read you will try to write something, I believe Rui Paulo's = library is a good start to hack, reading GPIO device, detecting when a = PIN is HIGH and measuring the time until it becomes LOW is probably a = good starter challenge ;-) >=20 > What we need is interrupt support so you don't need to keep reading > the GPIO pin in a busy loop and just get notified when the pin change > its state. >=20 > I hope i can get this sorted out soon (it is being worked on). Wow this is very good news Loos. Is it something new to gpioctl or another utility? Do you need a sensor = to sort it out? I can send you with that board we talked before. >> One sensor I am trying to make work is DHT11 temperature and = humidity, according to datasheet[1] on section 7, this "single-wire = bi-directional" sensor seems to return a 32bit value which shall be = calculated in 4 octets. >=20 > I can help you with the DHT11. I have some DHT11 working with an AVR > bridge which gives me the DHT11 data through I2C, this make the > readings reliable. I hope GPIO eventually grow up so i can get rid of > the AVR bridge. There are 5 octets with the Parity. My DHT11 is just dead, Ill get a new one soon and I would like to see = your schematics and code, if possible, on how you made it to work. Are = you using on a BBB board? >> This is a kind of sensor that deserves a library for sure (and = FreeBSD deserves to have such a library) but hopefully not the kind of = Arduino library which is device specific. A more generic library that = reads a selectable 8/16/32bit value and returns it in different formats = (decimal, hex, ...) would do the job for this sensor as well as other = single-wire pin sensors. >=20 > A generic library isn't always possible because each device encodes > the data in its own format, the DHT11(/DHT22) is different than > onewire and so on, but a good driver (if possible) for DHT11 would be > useful. I agree, it=92s a cheap device and useful one. >> [1]http://akizukidenshi.com/download/ds/aosong/DHT11.pdf -- Patrick Tracanelli FreeBSD Brasil LTDA. Tel.: (31) 3516-0800 316601@sip.freebsdbrasil.com.br http://www.freebsdbrasil.com.br "Long live Hanin Elias, Kim Deal!"