Date: Tue, 26 Aug 2014 16:27:12 -0300 From: Luiz Otavio O Souza <lists.br@gmail.com> To: Patrick Tracanelli <eksffa@freebsdbrasil.com.br> Cc: "freebsd-arm@freebsd.org" <freebsd-arm@freebsd.org>, Rui Paulo <rpaulo@felyko.com> Subject: Re: HC-SR04 and FreeBSD Message-ID: <CAB=2f8xyu1EwL3zft8E%2BSXRL66vdYSjgcSuhF7Kva9zDatGtXA@mail.gmail.com> In-Reply-To: <3949AF9C-B5BD-44E8-A049-21F26B8B6B9A@freebsdbrasil.com.br> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
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=E2=80=99t cause a problem) >> 3 - Wait until echo in is LOW >> >> When the sound come back to sensor, the device will LOW the GPIO pin aga= in. 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). [...] > > 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. R= un 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, > > And check for the date when PIN 2 becomes high and later when it becomes = low again. > > Speed of sound is 340 meters per second. Since this sensor measures round= -trip, you shall divide by two, so here is a simple measurement by hand: > > An object added 1 meter from sensor: > > (eksffa@localhost):~% echo "((999013225427212-999013225364525)/340)/2" | = bc > 92 > > An object added 2 meters from sensor: > > (eksffa@localhost):~% echo "((999013003943898-999013003811223)/340)/2" | = bc > 195 > > So, now you have a better precision, but insanely high CPU usage due to t= he second loop. > > 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 libra= ry is a good start to hack, reading GPIO device, detecting when a PIN is HI= GH and measuring the time until it becomes LOW is probably a good starter c= hallenge ;-) 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). > > One sensor I am trying to make work is DHT11 temperature and humidity, ac= cording to datasheet[1] on section 7, this "single-wire bi-directional" sen= sor 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. > This is a kind of sensor that deserves a library for sure (and FreeBSD de= serves to have such a library) but hopefully not the kind of Arduino librar= y which is device specific. A more generic library that reads a selectable = 8/16/32bit value and returns it in different formats (decimal, hex, ...) wo= uld 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. > > [1]http://akizukidenshi.com/download/ds/aosong/DHT11.pdf Luiz
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAB=2f8xyu1EwL3zft8E%2BSXRL66vdYSjgcSuhF7Kva9zDatGtXA>