Hardware Reference
In-Depth Information
This variability in preemptive scheduling makes it difficult to do reliable timings.
I have seen the high-level bit counts vary between 26 and 378. (The interested reader
can modify the code to record the counts.) If the program is able to read 6.6 times per
microsecond, a 1-bit time of 70 ms should yield a count of 462. Yet the maximum seen was
378. Preemptive scheduling prevents the code from performing that many reads without
interruption.
The lower count of 26 represents the minimum count for 0 bits, where the line stays
high for a shorter period of time. This suggests that each GPIO read is about 1 ms or longer
during the 0-bit highs.
The preceding information is just a crude sampling of the problem to illustrate
the variability that must be grappled with in a user space program, on a multitasking
operating system.
Chosen Approach
The program shown in this chapter uses the following general approach:
1.
Count the number of GPIO reads that report that the line is
low (call it
C
low
).
C
D
2.
Compute an adjustment bias B based on
B
, where D is
=
low
some fixed divisor.
3.
Compute a new count
K
=
B
+
C
high
, where
C
high
is the number
of times the line was read as high.
4.
If the count value
K
>
C
low
, the value is considered a 1-bit;
otherwise, it's considered a 0-bit.
The method is intended to at least partially compensate for the level of preemption
being seen by the application program. By measuring the low read counts, we get an idea
of the number of times we can sample the line at the moment. The approach is intended
to adapt itself to a faster-running Raspberry Pi.
Table
1-1
shows some experimental results on an idle Raspberry Pi running at the
standard 700 MHz. Different divisors were tried and tested over 5-minute intervals.
When the program runs, it attempts to read and report as many sensor readings as it
can, tracking good reports, time-out, and error counts. The program was terminated by
pressing ^C when an egg timer went off.
