Re: [fpc-pascal] Reading AM2302 temp/humid sensor on RaspberryPi?
On Fri, Aug 24, 2018 at 2:45 PM, Mark Morgan Lloyd wrote: > On 24/08/18 09:15, R0b0t1 wrote: >> >> On Thu, Aug 23, 2018 at 6:28 AM, Mark Morgan >> Lloyd 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>> >> 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. ___ 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 24/08/18 09:15, R0b0t1 wrote: On Thu, Aug 23, 2018 at 6:28 AM, Mark Morgan Lloyd 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>> 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. -- 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
[fpc-pascal] How is interface variable implemented?
if I have this test program below:
program testi;
{$INTERFACES CORBA}
uses sysutils;
type
IInterfaceA = interface
procedure Increment ;
end;
{ TObjectA }
TObjectA = class(IInterfaceA)
Value : Int64;
procedure Increment;
end;
var
c : int32;
i : IInterfaceA;
obj : TObjectA;
aTime : TDateTime;
{ TObjectA }
procedure TObjectA.Increment;
begin
Inc(Value);
end;
begin
obj := TObjectA.Create;
try
aTime := now;
for c := 1 to 1 do
obj.Increment;
aTime := now - aTime;
Writeln('Object call Time Taken Seconds:', aTime*24*60*60);
finally
FreeAndNil(obj);
end;
obj := TObjectA.Create;
try
aTime := now;
i := obj;
for c := 1 to 1 do
i.Increment;
aTime := now - aTime;
Writeln('Interface call Time Taken Seconds:', aTime*24*60*60);
finally
FreeAndNil(obj);
end;
Readln;
end.
The run results:
Object call Time Taken Seconds: 2.1899964194744825E-001
Interface call Time Taken Seconds: 2.799001622200E-001
so, the time difference is about 27%
My question is, where is this extra time spent?
I am assuming an interface variable has a table with entries storing (
pointer to the object instance AND an offset of method address in the
Virtual Method Table of that object.)
Am I correct?
What is the memory occupied by the interface variable?
I know the sizeof(i) = 8 (in 64 bit windows), but what is the size of
the instance?
I cannot find any of this info on the web.
Thanks for your answer in advance.
Dennis
___
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 11:28:16 +, Mark Morgan Lloyd wrote: >The AM2302 datasheet suggests that it's a device to be avoided assiduously. But it works fine hooked to an ESP-07 WiFi module, which is programmed using the Arduino framework. I have a test running for several months now and it logs T/H every 20 minutes. I will probably just build myself a copy of this and put it at the summer home. It can be set to transfer its data to the RPi2 at that location via the WiFi network. Of course I have to resort to C and C++ programming then... -- 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] Reading AM2302 temp/humid sensor on RaspberryPi?
On Thu, 23 Aug 2018 11:28:16 +, Mark Morgan Lloyd wrote: >The AM2302 datasheet suggests that it's a device to be avoided assiduously. But it works fine hooked to an ESP-07 WiFi module, which is programmed using the Arduino framework. I have a test running for several months now and it logs T/H every 20 minutes. I will probably just build myself a copy of this and put it at the summer home. It can be set to transfer its data to the RPi2 at that location via the WiFi network. Of course I have to resort to C and C++ programming then... -- 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] Reading AM2302 temp/humid sensor on RaspberryPi?
On Thu, Aug 23, 2018 at 6:28 AM, Mark Morgan Lloyd 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>> 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 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 ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
