Update READMEs
This commit is contained in:
parent
f04287305d
commit
734144ad66
configs
sama5d3-xplained
sama5d3x-ek
sama5d4-ek
same70-xplained
samv71-xult
@ -2539,16 +2539,35 @@ Tickless OS
|
|||||||
timing using the RC clock! UPDATE: This will now be selected by default
|
timing using the RC clock! UPDATE: This will now be selected by default
|
||||||
when you configure for TICKLESS support.
|
when you configure for TICKLESS support.
|
||||||
|
|
||||||
The slow clock has a resolution of about 30.518 microseconds. Ideally, the
|
The slow clock has a resolution of about 30.518 microseconds. Ideally,
|
||||||
value of CONFIG_USEC_PER_TICK should be an exact multiple of the clock
|
the value of CONFIG_USEC_PER_TICK should be the exact clock resolution.
|
||||||
resolution. Otherwise there will be cumulative timing inaccuracies. A
|
Otherwise there will be cumulative timing inaccuracies. But a choice
|
||||||
choice of:
|
choice of:
|
||||||
|
|
||||||
CONFIG_USEC_PER_TICK=61, or
|
CONFIG_USEC_PER_TICK=31
|
||||||
CONFIG_USEC_PER_TICK=122
|
|
||||||
|
|
||||||
will be close but will still have inaccuracies that will effect the time
|
will have an error of 0.6% and will have inaccuracies that will
|
||||||
due to long term error build-up.
|
effect the time due to long term error build-up.
|
||||||
|
|
||||||
|
UPDATE: As of this writing (2015-12-03), the Tickless support is
|
||||||
|
functional. However, there are inaccuracies in delays. For example,
|
||||||
|
|
||||||
|
nsh> sleep 10
|
||||||
|
|
||||||
|
results in a delay of maybe 5.4 seconds. But the timing accuracy is
|
||||||
|
correct if all competing uses of the interval timer are disabled (mostly
|
||||||
|
from the high priority work queue). Therefore, I conclude that this
|
||||||
|
inaccuracy is due to the inaccuracies in the representation of the clock
|
||||||
|
rate. 30.518 usec cannot be represented accurately. Each timing
|
||||||
|
calculation results in a small error. When the interval timer is very
|
||||||
|
busy, long delays will be divided into many small pieces and each small
|
||||||
|
piece has a large error in the calculation. The cumulative error is the
|
||||||
|
cause of the problem.
|
||||||
|
|
||||||
|
Solution: 30.518 microseconds is not representable and the value of
|
||||||
|
CONFIG_USEC_PER_SEC is too inaccurate; error build-up is throwing off
|
||||||
|
long delays (short delays are probably still okay). We should driver
|
||||||
|
the interval timer with PCK6 with a period that is exactly representable.
|
||||||
|
|
||||||
SAMA5 Timer Usage
|
SAMA5 Timer Usage
|
||||||
-----------------
|
-----------------
|
||||||
|
@ -2859,16 +2859,35 @@ Tickless OS
|
|||||||
timing using the RC clock! UPDATE: This will now be selected by default
|
timing using the RC clock! UPDATE: This will now be selected by default
|
||||||
when you configure for TICKLESS support.
|
when you configure for TICKLESS support.
|
||||||
|
|
||||||
The slow clock has a resolution of about 30.518 microseconds. Ideally, the
|
The slow clock has a resolution of about 30.518 microseconds. Ideally,
|
||||||
value of CONFIG_USEC_PER_TICK should be an exact multiple of the clock
|
the value of CONFIG_USEC_PER_TICK should be the exact clock resolution.
|
||||||
resolution. Otherwise there will be cumulative timing inaccuracies. A
|
Otherwise there will be cumulative timing inaccuracies. But a choice
|
||||||
choice of:
|
choice of:
|
||||||
|
|
||||||
CONFIG_USEC_PER_TICK=61, or
|
CONFIG_USEC_PER_TICK=31
|
||||||
CONFIG_USEC_PER_TICK=122
|
|
||||||
|
|
||||||
will be close but will still have inaccuracies that will effect the time
|
will have an error of 0.6% and will have inaccuracies that will
|
||||||
due to long term error build-up.
|
effect the time due to long term error build-up.
|
||||||
|
|
||||||
|
UPDATE: As of this writing (2015-12-03), the Tickless support is
|
||||||
|
functional. However, there are inaccuracies in delays. For example,
|
||||||
|
|
||||||
|
nsh> sleep 10
|
||||||
|
|
||||||
|
results in a delay of maybe 5.4 seconds. But the timing accuracy is
|
||||||
|
correct if all competing uses of the interval timer are disabled (mostly
|
||||||
|
from the high priority work queue). Therefore, I conclude that this
|
||||||
|
inaccuracy is due to the inaccuracies in the representation of the clock
|
||||||
|
rate. 30.518 usec cannot be represented accurately. Each timing
|
||||||
|
calculation results in a small error. When the interval timer is very
|
||||||
|
busy, long delays will be divided into many small pieces and each small
|
||||||
|
piece has a large error in the calculation. The cumulative error is the
|
||||||
|
cause of the problem.
|
||||||
|
|
||||||
|
Solution: 30.518 microseconds is not representable and the value of
|
||||||
|
CONFIG_USEC_PER_SEC is too inaccurate; error build-up is throwing off
|
||||||
|
long delays (short delays are probably still okay). We should driver
|
||||||
|
the interval timer with PCK6 with a period that is exactly representable.
|
||||||
|
|
||||||
SAMA5 Timer Usage
|
SAMA5 Timer Usage
|
||||||
-----------------
|
-----------------
|
||||||
|
@ -3367,22 +3367,35 @@ Tickless OS
|
|||||||
timing using the RC clock! UPDATE: This will now be selected by default
|
timing using the RC clock! UPDATE: This will now be selected by default
|
||||||
when you configure for TICKLESS support.
|
when you configure for TICKLESS support.
|
||||||
|
|
||||||
The slow clock has a resolution of about 30.518 microseconds. Ideally, the
|
The slow clock has a resolution of about 30.518 microseconds. Ideally,
|
||||||
value of CONFIG_USEC_PER_TICK should be an exact multiple of the clock
|
the value of CONFIG_USEC_PER_TICK should be the exact clock resolution.
|
||||||
resolution. Otherwise there will be cumulative timing inaccuracies. A
|
Otherwise there will be cumulative timing inaccuracies. But a choice
|
||||||
choice of:
|
choice of:
|
||||||
|
|
||||||
CONFIG_USEC_PER_TICK=61, or
|
CONFIG_USEC_PER_TICK=31
|
||||||
CONFIG_USEC_PER_TICK=122
|
|
||||||
|
|
||||||
will be close but will still have inaccuracies that will effect the time
|
will have an error of 0.6% and will have inaccuracies that will
|
||||||
due to long term error build-up.
|
effect the time due to long term error build-up.
|
||||||
|
|
||||||
UPDATE: As of this writing (2014-8-11), the Tickless support is
|
UPDATE: As of this writing (2015-12-03), the Tickless support is
|
||||||
functional. However, the timing for all delays appears to be half the
|
functional. However, there are inaccuracies in delays. For example,
|
||||||
duration that it should be. I don't see anything wrong with the setup
|
|
||||||
and I am suspecting that there may be something I don't understand about
|
nsh> sleep 10
|
||||||
the counting frequency.
|
|
||||||
|
results in a delay of maybe 5.4 seconds. But the timing accuracy is
|
||||||
|
correct if all competing uses of the interval timer are disabled (mostly
|
||||||
|
from the high priority work queue). Therefore, I conclude that this
|
||||||
|
inaccuracy is due to the inaccuracies in the representation of the clock
|
||||||
|
rate. 30.518 usec cannot be represented accurately. Each timing
|
||||||
|
calculation results in a small error. When the interval timer is very
|
||||||
|
busy, long delays will be divided into many small pieces and each small
|
||||||
|
piece has a large error in the calculation. The cumulative error is the
|
||||||
|
cause of the problem.
|
||||||
|
|
||||||
|
Solution: 30.518 microseconds is not representable and the value of
|
||||||
|
CONFIG_USEC_PER_SEC is too inaccurate; error build-up is throwing off
|
||||||
|
long delays (short delays are probably still okay). We should driver
|
||||||
|
the interval timer with PCK6 with a period that is exactly representable.
|
||||||
|
|
||||||
SAMA5 Timer Usage
|
SAMA5 Timer Usage
|
||||||
-----------------
|
-----------------
|
||||||
|
@ -911,22 +911,35 @@ Tickless OS
|
|||||||
definition BOARD_HAVE_SLOWXTAL in the configs/same70-xplained/board.h
|
definition BOARD_HAVE_SLOWXTAL in the configs/same70-xplained/board.h
|
||||||
file.
|
file.
|
||||||
|
|
||||||
The slow clock has a resolution of about 30.518 microseconds. Ideally, the
|
The slow clock has a resolution of about 30.518 microseconds. Ideally,
|
||||||
value of CONFIG_USEC_PER_TICK should be an exact multiple of the clock
|
the value of CONFIG_USEC_PER_TICK should be the exact clock resolution.
|
||||||
resolution. Otherwise there will be cumulative timing inaccuracies. A
|
Otherwise there will be cumulative timing inaccuracies. But a choice
|
||||||
choice of:
|
choice of:
|
||||||
|
|
||||||
CONFIG_USEC_PER_TICK=61, or
|
CONFIG_USEC_PER_TICK=31
|
||||||
CONFIG_USEC_PER_TICK=122
|
|
||||||
|
|
||||||
will be close but will still have inaccuracies that will effect the time
|
will have an error of 0.6% and will have inaccuracies that will
|
||||||
due to long term error build-up.
|
effect the time due to long term error build-up.
|
||||||
|
|
||||||
UPDATE: As of this writing (2015-12-02), the Tickless support is
|
UPDATE: As of this writing (2015-12-03), the Tickless support is
|
||||||
functional. However, the timing for all delays appears to be half the
|
functional. However, there are inaccuracies in delays. For example,
|
||||||
duration that it should be. I don't see anything wrong with the setup
|
|
||||||
and I am suspecting that there may be something I don't understand about
|
nsh> sleep 10
|
||||||
the counting frequency.
|
|
||||||
|
results in a delay of maybe 5.4 seconds. But the timing accuracy is
|
||||||
|
correct if all competing uses of the interval timer are disabled (mostly
|
||||||
|
from the high priority work queue). Therefore, I conclude that this
|
||||||
|
inaccuracy is due to the inaccuracies in the representation of the clock
|
||||||
|
rate. 30.518 usec cannot be represented accurately. Each timing
|
||||||
|
calculation results in a small error. When the interval timer is very
|
||||||
|
busy, long delays will be divided into many small pieces and each small
|
||||||
|
piece has a large error in the calculation. The cumulative error is the
|
||||||
|
cause of the problem.
|
||||||
|
|
||||||
|
Solution: 30.518 microseconds is not representable and the value of
|
||||||
|
CONFIG_USEC_PER_SEC is too inaccurate; error build-up is throwing off
|
||||||
|
long delays (short delays are probably still okay). We should driver
|
||||||
|
the interval timer with PCK6 with a period that is exactly representable.
|
||||||
|
|
||||||
SAME70 Timer Usage
|
SAME70 Timer Usage
|
||||||
------------------
|
------------------
|
||||||
|
@ -1496,22 +1496,35 @@ Tickless OS
|
|||||||
input. The 32.768KHz crystal is selected by the definition
|
input. The 32.768KHz crystal is selected by the definition
|
||||||
BOARD_HAVE_SLOWXTAL in the configs/samv71-xult/board.h file.
|
BOARD_HAVE_SLOWXTAL in the configs/samv71-xult/board.h file.
|
||||||
|
|
||||||
The slow clock has a resolution of about 30.518 microseconds. Ideally, the
|
The slow clock has a resolution of about 30.518 microseconds. Ideally,
|
||||||
value of CONFIG_USEC_PER_TICK should be an exact multiple of the clock
|
the value of CONFIG_USEC_PER_TICK should be the exact clock resolution.
|
||||||
resolution. Otherwise there will be cumulative timing inaccuracies. A
|
Otherwise there will be cumulative timing inaccuracies. But a choice
|
||||||
choice of:
|
choice of:
|
||||||
|
|
||||||
CONFIG_USEC_PER_TICK=61, or
|
CONFIG_USEC_PER_TICK=31
|
||||||
CONFIG_USEC_PER_TICK=122
|
|
||||||
|
|
||||||
will be close but will still have inaccuracies that will effect the time
|
will have an error of 0.6% and will have inaccuracies that will
|
||||||
due to long term error build-up.
|
effect the time due to long term error build-up.
|
||||||
|
|
||||||
UPDATE: As of this writing (2015-12-02), the Tickless support is
|
UPDATE: As of this writing (2015-12-03), the Tickless support is
|
||||||
functional. However, the timing for all delays appears to be half the
|
functional. However, there are inaccuracies in delays. For example,
|
||||||
duration that it should be. I don't see anything wrong with the setup
|
|
||||||
and I am suspecting that there may be something I don't understand about
|
nsh> sleep 10
|
||||||
the counting frequency.
|
|
||||||
|
results in a delay of maybe 5.4 seconds. But the timing accuracy is
|
||||||
|
correct if all competing uses of the interval timer are disabled (mostly
|
||||||
|
from the high priority work queue). Therefore, I conclude that this
|
||||||
|
inaccuracy is due to the inaccuracies in the representation of the clock
|
||||||
|
rate. 30.518 usec cannot be represented accurately. Each timing
|
||||||
|
calculation results in a small error. When the interval timer is very
|
||||||
|
busy, long delays will be divided into many small pieces and each small
|
||||||
|
piece has a large error in the calculation. The cumulative error is the
|
||||||
|
cause of the problem.
|
||||||
|
|
||||||
|
Solution: 30.518 microseconds is not representable and the value of
|
||||||
|
CONFIG_USEC_PER_SEC is too inaccurate; error build-up is throwing off
|
||||||
|
long delays (short delays are probably still okay). We should driver
|
||||||
|
the interval timer with PCK6 with a period that is exactly representable.
|
||||||
|
|
||||||
SAMV7 Timer Usage
|
SAMV7 Timer Usage
|
||||||
-----------------
|
-----------------
|
||||||
|
Loading…
x
Reference in New Issue
Block a user