Date: Tue, 26 Aug 2014 20:21:08 -0300 From: Patrick Tracanelli <eksffa@freebsdbrasil.com.br> To: Luiz Otavio O Souza <lists.br@gmail.com> Cc: "freebsd-arm@freebsd.org" <freebsd-arm@freebsd.org>, Rui Paulo <rpaulo@felyko.com> Subject: Re: HC-SR04 and FreeBSD Message-ID: <411C643B-BC46-494E-919B-39098FB87EEA@freebsdbrasil.com.br> In-Reply-To: <CAB=2f8xyu1EwL3zft8E%2BSXRL66vdYSjgcSuhF7Kva9zDatGtXA@mail.gmail.com> References: <CAG4HiT6wwbmSA_KWsgHOqdeZVOCUsdhRxDhMubvkG1tEwVH5Sw@mail.gmail.com> <5D802942-2D0F-4324-8212-C2871EEB6327@FreeBSD.org> <CAG4HiT6fiqVXMoqcJra1Yh8aFVbOcezP8rRqst6WC8aHuaF_rA@mail.gmail.com> <01562FB1-32C6-45AF-AB77-5BB80526E18C@FreeBSD.org> <CAG4HiT4kKz18iauXfuF0Dpv-USghunssUvwkTF7bDx_gE_VS2w@mail.gmail.com> <CCD5AEE5-798D-4EAC-BAE7-A086DE55B5D2@FreeBSD.org> <CAG4HiT6YUBCxXrK_KyRW6zTthPa-wDe=A9=CmMHQf-Gh54s7QA@mail.gmail.com> <EA5A973C-960A-4B0F-A690-8AA9BF66244A@felyko.com> <CAG4HiT4EbX=Lar_o8YZc5B51Yao1-B=Ebck0vQajyzoZwesWwQ@mail.gmail.com> <CAB=2f8zBDTVkQd15C_icZpOMC14XxFycW_ZR2Sa--updv=dX2w@mail.gmail.com> <53F8FED8.6030409@freebsdbrasil.com.br> <CAG4HiT4RXsUyGfjDDTTJPoeB8bqpY39z6C-_f0S3Zmka0C8gNQ@mail.gmail.com> <3949AF9C-B5BD-44E8-A049-21F26B8B6B9A@freebsdbrasil.com.br> <CAB=2f8xyu1EwL3zft8E%2BSXRL66vdYSjgcSuhF7Kva9zDatGtXA@mail.gmail.com>
index | next in thread | previous in thread | raw e-mail
On 26/08/2014, at 16:27, Luiz Otavio O Souza <lists.br@gmail.com> 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, >>> >>> 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). >>> >>> So the correct sequence should be, in a loop: >>> >>> 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’t cause a problem) >>> 3 - Wait until echo in is LOW >>> >>> When the sound come back to sensor, the device will LOW the GPIO pin again. > > 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’s why I did some tests and sent the other e-mail. You won’t set anything, you will measure how long it was set to high. >> What you wanna do is to measure how long HIGH takes. >> >> I just made a better test so you can actually "see" the sensor working. Run this more simple loop: >> >> gpioctl -c 2 IN >> gpioctl -c 3 OUT >> gpioctl 3 0 >> >> 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 >> >> On a second shell, run this horrible cpu consuming loop: >> >> sh -c "while true ; do /root/date-precisao && gpioctl 2 ; done" > > This one is okay, That’s 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. >> >> 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 ;-) > > 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. > > 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. > > 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. > > 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’s 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!"help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?411C643B-BC46-494E-919B-39098FB87EEA>