Re: [fpc-pascal] Reading AM2302 temp/humid sensor on RaspberryPi?
On Thu, 23 Aug 2018 00:33:05 -0500, R0b0t1 wrote: >Can you briefly describe its protocol? Does it look anything like >Dallas/Maxim Semi 1-wire or I2C, or is it something else? If it is >either of those the I2C or SPI peripheral likely could do it. Even if >not the SPI peripheral may work. This is what the datasheet says (times here are the nominal ones): 1. It uses a 1-wire connection with 5K pullup and open drain drivers. 2. The master requests data by pulling the wire low for 1 ms 3. The sensor then waits 30 us before setting the wire low for 80 us followed by high for 80 us. 4. Next follows 40 bits of data each composed of: - Low level for 50 us - High level for bit value depenednt time: Bit = 0 time = 26 us Bit = 1 time = 70 us 5. After the 40 bit transfer the line is held low for 50 us, then released. Data are sent as 4 bytes (16 bit humidity, 16 bit temp) followed by one parity byte. The bytes are sent MSB first. The DHT driver for Arduino ESP8266 (in C) seems to measure and stuff pulse widths into an array during the transfer and after the fact evaluates the bits depending on the recorded widths. My problem is that I don't see how I could measure the high level pulse widths Possibly a loop where the input level is checked: function MeasureHighPulse: cardinal; var Ts, Te: cardinal; const Tmax = 100; //Max allowed pulse length begin Ts := TickCountus(); //Need a tickcount with us resolution... Te := Ts; while InputPin(Sensorpin) = 1 do begin Te := TickCountus(); if Te - Ts > Tmax then begin Te := Ts; break; end; end; Result := Te - Ts; end; I will need a higher resolution GetTickCount for this... The usleep() function is somethingh I have never seen before, but I guess it "sleeps" for a certain number of microseconds... -- Bo Berglund Developer in Sweden ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Branch table
Am 21.08.2018 um 11:42 schrieb Marco Borsari via fpc-pascal: > Il 20/08/2018 17:32, Giuliano Colla ha scritto: > >> On the Intel architecture you cannot perform pointer arithmetic as if a >> pointer were just a number. >> A pointer is composed of two parts: a "selector" and an "offset", which >> must be handled separately. > > Ah, I saw, 32 bit segmentation is quite complicated. > Thank you twice, Marco I still miss the point of a hand coded branch table ... ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Reading AM2302 temp/humid sensor on RaspberryPi?
On Thu, 23 Aug 2018 09:00:07 +0200, Bo Berglund wrote: > >I will need a higher resolution GetTickCount for this... Is there in fact a way (on Linux - Raspbian) to get a tickcount with higher resolution than 1 ms? I need us so I can time between two events (pulse rise and pulse fall) which are 20 to 90 us apart... An alternate way would be to do an accurate sleep for a time between the two limits, say 48 us, after seeing the pulse rise and then determine the state of the I/O at that time. If the input is 0 then the bit is zero and if it is still 1 the bit is a 1... -- Bo Berglund Developer in Sweden ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Branch table
On Thu, 23 Aug 2018 09:32:58 +0200 Florian Klämpfl wrote: > Am 21.08.2018 um 11:42 schrieb Marco Borsari via fpc-pascal: > > Il 20/08/2018 17:32, Giuliano Colla ha scritto: > > > >> On the Intel architecture you cannot perform pointer arithmetic as if a > >> pointer were just a number. > >> A pointer is composed of two parts: a "selector" and an "offset", which > >> must be handled separately. > > > > Ah, I saw, 32 bit segmentation is quite complicated. > > Thank you twice, Marco > > I still miss the point of a hand coded branch table ... It would be for the Wirth optimization in the access of an array, when the index is 0 or 1, allowing the elimination of a multiplication. case idx of 0: (*adr:=adr*); 1: adr:=adr+lel; end else adr:=adr+idx*lel; It's half for paranoia and half for the desire to learn, I am sorry, Marco ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Reading AM2302 temp/humid sensor on RaspberryPi?
Hi, I recently built a Weather-Station using an RPi and Lazarus/FPC, but: anything that's not I2C or SPI (or otherwise supported within the RPi hardware) is IHMO hard to realize. I went on and used an AVR (Arduino) to interface the DHT11, and hooked that up to the Pi with UART (just before dumping it completely, because it's accuracy and self-heating issues were just to much to calibrate accurately). Reason: Am 23.08.2018 um 11:11 schrieb Bo Berglund: > An alternate way would be to do an accurate sleep for a time between > the two limits, say 48 us, after seeing the pulse rise and then > determine the state of the I/O at that time. > If the input is 0 then the bit is zero and if it is still 1 the bit is > a 1... There are commands like usleep() in Linux. But - as the typical system on the Pi is not a realtime OS and we have the granularity of the system scheduler, task switching, interrupts etc. pp. to account for, many sources give it's accuracy to be only above 100 µs. Generally I would say that, on any complex system, without considerably effort, no loop or timer can be 100% sure not to be interrupted while processing input data for at least a few µs, which is exactly the problem here. One solution might be possible, though I never digged in further (and I suspect it's not possible for a user-land process, but I might be proven wrong): try do define your own interrupt on the specific pin (there are some libs for this, also in user-land) and find a hardware timer in the Broadcom chip that is running stable enough to count a few µs. There are timers and interrupts in the Chip (see https://www.studica.com/blog/raspberry-pi-timer-embedded-environments). Regards, Alex PS: I dumped the DHT11 and used a HTDU21D. I2C, stable and easy with FPC ;-)) ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Reading AM2302 temp/humid sensor on RaspberryPi?
On Thursday 23 August 2018 11:11:34 Bo Berglund wrote: > On Thu, 23 Aug 2018 09:00:07 +0200, Bo Berglund > > wrote: > >I will need a higher resolution GetTickCount for this... > > Is there in fact a way (on Linux - Raspbian) to get a tickcount with > higher resolution than 1 ms? MSEgui has "timestamp()" (lib/common/kernel/msesysutils.pas) which returns microseconds. MSEgui "ttimer" also has 1 us resolution. > I need us so I can time between two events (pulse rise and pulse fall) > which are 20 to 90 us apart... > I don't think that can be done reliably in user space. Martin ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Reading AM2302 temp/humid sensor on RaspberryPi?
On Thursday 23 August 2018 11:54:14 Martin Schreiber wrote: > > I don't think that can be done reliably in user space. > As Alexander writes, the right way to do such a task is to use a hardware timer in capture mode. I don't know how difficult this is on RPi. Martin ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Reading AM2302 temp/humid sensor on RaspberryPi?
On 23/08/18 10:00, Martin Schreiber wrote: On Thursday 23 August 2018 11:11:34 Bo Berglund wrote:> On Thu, 23 Aug 2018 09:00:07 +0200, Bo Berglund>> wrote:> >I will need a higher resolution GetTickCount for this...>> Is there in fact a way (on Linux - Raspbian) to get a tickcount with> higher resolution than 1 ms? On a mid-00s server I'm using clock_gettime(CLOCK_REALTIME which is apparently better than 1uSec, but from previously looking at older PCs and (I think) RPi3 your mileage may vary enormously. AIUI there's been a lot of issues over the years with different cores not having their counters in step, with counter frequency following dynamic clocks rather than being fixed and so on. The AM2302 datasheet suggests that it's a device to be avoided assiduously. -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
