1

My team and I are designing a project which requires the detection of rising edge of a square wave and then storing the time using time.time() in a variable.If a same square wave is given to 3 different pins of RPi,and event detection is applied on each pin,theoretically,they should occur at the same time,but they have a delay which causes a difference in phase too (we are calculating phase from time). We concluded that time.time() is a slow function. Can anyone please help me as to which function to use to get SOC more precise than time.time()? Or please provide me with the programming behind the function time.time(). I'll be really thankful.

neo
  • 11
  • 1
  • 2
    I'm afraid the answer is very likely to be "you need to drop down to C", but I don't really know from RPi-specific programming. Also it would help if you tell us what you mean by "SOC"; that is not a TLA I am familiar with. – zwol Sep 02 '16 at 18:10
  • @zwol System on a Chip, I believe. – Morgan Thrapp Sep 02 '16 at 18:13
  • @MorganThrapp That doesn't make sense in context. "Get system on a chip more precise than time.time"??? – zwol Sep 02 '16 at 18:17
  • @zwol My assumption is that they mean that they need the timing on their SOC to be more precise. It's kinda hard to tell exactly what's needed here. – Morgan Thrapp Sep 02 '16 at 18:25
  • SOC=seconds of century. sorry to write that in flow. – neo Sep 03 '16 at 10:12

1 Answers1

0

time.time uses gettimeofday on platforms that support it. That means its resolution is in microseconds.

You might try using time.clock_gettime(time.CLOCK_REALTIME) which provides nanosecond resolution (assuming the underlying hardware/OS provides that). The result still gets converted to floating point as with time.time.

It's also possible to load up the libc shared object and invoke the native clock_gettime using the ctypes module. In that way, you could obtain access to the actual nanosecond count provided by the OS. (Using ctypes has a fairly steep learning curve though.)

Gil Hamilton
  • 11,973
  • 28
  • 51
  • Thanks.but I couldn't get the "libc" thing you mentioned.I was thinking if I could get access to the actual programming of time.time() function, I could mould it somehow. – neo Sep 03 '16 at 10:16
  • The source of cpython (the most common python implementation) is freely available for download (https://www.python.org/downloads/source/). You will find the `time.time` function in `Modules/timemodule.c`. Modifying it is certainly possible but the learning curve on that is arguably steeper than for `ctypes`. – Gil Hamilton Sep 03 '16 at 19:19
  • Just realized something. You should try this: `import time; time.get_clock_info("time")` which will give you information on the implementation of `time.time`. You may already be using `clock_gettime`, in which case you will not likely get better resolution (though you *could* avoid loss of precision due to the integer-to-float conversion with the `ctypes` access of `libc`). – Gil Hamilton Sep 03 '16 at 19:32
  • printing the import time; time.get_clock_info("time") gave some info about time.time like the resolution=0.015625.Thanks for that. "(though you could avoid loss of precision due to the integer-to-float conversion with the ctypes access of libc)" Sorry but I have no idea of what you are talking about here.I am an amateur in python programming and I dont know anything about ctypes and libc – neo Sep 04 '16 at 17:42
  • What I was thinking of is this: https://docs.python.org/3/tutorial/floatingpoint.html -- however, in retrospect, the scale of the issue is probably not significant for what you're doing. For the other, I was suggesting you could use `ctypes` to gain access to the raw `clock_gettime` API function in the standard C library on your system to avoid the conversion. It now seems likely to me though that your OS/hardware clock resolution is simply too low to provide the precision you need. Not sure what you can do about that. – Gil Hamilton Sep 06 '16 at 15:31