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

[R0b0t1]

On Fri, Aug 24, 2018 at 2:45 PM, Mark Morgan Lloyd
<markMLl.fpc-pascal at telemetry.co.uk> wrote:
> On 24/08/18 09:15, R0b0t1 wrote:
>>
>> 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.
>
>
> That shows the nominal resolution, not the actual rate that the counter is
> updated.
>

The counter is updated, generally, at its resolution; the
implementation as far as I know reads the counter value directly which
may be associated with hardware.

What is more problematic is the scheduler's minimum timeslice. I
couldn't exactly find a way to find it though it exists as a define in
the Linux kernel, but that value may or may not be used as-is.