[fpc-pascal] Reading AM2302 temp/humid sensor on RaspberryPi?

[R0b0t1]

On Thu, Aug 23, 2018 at 6:28 AM, Mark Morgan Lloyd
<markMLl.fpc-pascal at telemetry.co.uk> wrote:
> 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>> <bo.berglund at gmail.com> 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.
>

There is clock_getres(2) to test this. The problems you're talking
about do exist but have mostly been hidden behind the clock_gettime
interface, or, on Windows, QueryPerformanceCounter.

> The AM2302 datasheet suggests that it's a device to be avoided assiduously.
>

It's definitely not the best protocol. It's not even communication
line powered, so I don't see the point of the strange implementation.


On Thu, Aug 23, 2018 at 4:54 AM, Martin Schreiber <mse00000 at gmail.com> wrote:
> On Thursday 23 August 2018 11:11:34 Bo Berglund wrote:
>> 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.
>

I think it could, but the success of the program depends entirely on
what else is running. That could be avoided with scheduling settings
or running a "realtime" kernel.

I do think this could be done by beating the SPI peripheral over the
head, but just like the solution involving timers it may not be easy
to implement as you need to slide your code in to Linux.

Cheers,
    R0b0t1