Update READMEs

This commit is contained in:
Gregory Nutt 2015-12-03 09:52:50 -06:00
parent f04287305d
commit 734144ad66
5 changed files with 127 additions and 50 deletions
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
----------------- -----------------