Re: [time-nuts] An embedded NTP server
Hi
The little Arm7/ Cortex-M3 micro's don't pay as much attention to the clock chain as some of their bigger brothers (like a Sandy Bridge I7) do. At least the M3's and M4's I have seen are running the VCO at 50 to 150 MHz to generate a CPU clock at that frequency. The clock is divided by two for the RAM clock, and divided by two again for the flash clock. They may be doing a fake out on the VCO frequency. If they are, it's well hidden.
Bob
On Jan 1, 2013, at 1:14 PM, Attila Kinali attila@kinali.ch wrote:
Hoi Bob,
On Tue, 1 Jan 2013 12:03:49 -0500
Bob Camp lists@rtty.us wrote:
On Jan 1, 2013, at 11:34 AM, Attila Kinali attila@kinali.ch wrote:
What about those uC that use a VCO that runs up at several 100MHz (i've
seen up to 800MHz) and devide it down to what they actually need.
Shouldnt this improve jitter quite considerably?
Most of the small micro's don't get very fancy on the clock chain.
You are lucky if the VCO is running at twice the CPU clock. In some
cases the input capture(s) (and PWM's) are running directly on the
VCO (at say 72 MHz) and the CPU is running at half or a quarter of that.
That's why i was specifically asking about those uC which use a higher
frequency VCO for their clock generation. Ie not the tiny 8bit stuff,
but those in the ARM7/Cortex-M3 class.
Attila Kinali
--
There is no secret ingredient
-- Po, Kung Fu Panda
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
Hi
I'm not bashing the Arm parts, they are nice gizmos. They don't do the clock chains the way they do because they are lazy. They very much plan things out. Their main target audience is low power portable gear. Having a part that drops down to very low current when nothing much is going on is one of their goals. That drives them to keep the clocks / VCO's as slow as they possibly can. They worry about every uA of current drain…
Bob
On Jan 1, 2013, at 1:14 PM, Attila Kinali attila@kinali.ch wrote:
Hoi Bob,
On Tue, 1 Jan 2013 12:03:49 -0500
Bob Camp lists@rtty.us wrote:
On Jan 1, 2013, at 11:34 AM, Attila Kinali attila@kinali.ch wrote:
What about those uC that use a VCO that runs up at several 100MHz (i've
seen up to 800MHz) and devide it down to what they actually need.
Shouldnt this improve jitter quite considerably?
Most of the small micro's don't get very fancy on the clock chain.
You are lucky if the VCO is running at twice the CPU clock. In some
cases the input capture(s) (and PWM's) are running directly on the
VCO (at say 72 MHz) and the CPU is running at half or a quarter of that.
That's why i was specifically asking about those uC which use a higher
frequency VCO for their clock generation. Ie not the tiny 8bit stuff,
but those in the ARM7/Cortex-M3 class.
Attila Kinali
--
There is no secret ingredient
-- Po, Kung Fu Panda
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
In message AA21D17C-0FF4-4B22-B3A3-43AC2B9DAA58@rtty.us, Bob Camp writes:
I'm not bashing the Arm parts, [...] They worry about every uA of
current drain
True story:
Many years ago when the very first ARM silicon arrived and they started
testing it, it was generally execeeding expectations but a little bit
flakey at high clock rates.
After the bubbly had been drunk and hangovers subdued, the serious testing
started and one of the first thing they found was that they had forgotten
to hook up VCC: The chip ran entirely on leaked power from the I/O pins,
most notably the #RESET pin.
When they also connected the VCC pin, it was stable well above spec'ed
speed.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
phk@FreeBSD.ORG | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
I have had that "problem" more than once. Missing Vcc on a chip but the thing runs, just not necessarily well enough, or well enough to go through the next level of test.
I have also used it when adding an inverter somewhere on a clock line, and a decoupling cap on the inverter's Vcc is enough to keep it running. Saves a jumper.
Didier
Sent from my Droid Razr 4G LTE wireless tracker.
-----Original Message-----
From: Poul-Henning Kamp phk@phk.freebsd.dk
To: Discussion of precise time and frequency measurement time-nuts@febo.com, Bob Camp lists@rtty.us
Sent: Tue, 01 Jan 2013 2:16 PM
Subject: Re: [time-nuts] An embedded NTP server
In message AA21D17C-0FF4-4B22-B3A3-43AC2B9DAA58@rtty.us, Bob Camp writes:
I'm not bashing the Arm parts, [...] They worry about every uA of
current drain
True story:
Many years ago when the very first ARM silicon arrived and they started
testing it, it was generally execeeding expectations but a little bit
flakey at high clock rates.
After the bubbly had been drunk and hangovers subdued, the serious testing
started and one of the first thing they found was that they had forgotten
to hook up VCC: The chip ran entirely on leaked power from the I/O pins,
most notably the #RESET pin.
When they also connected the VCC pin, it was stable well above spec'ed
speed.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
phk@FreeBSD.ORG | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
On 1/1/13 12:16 PM, Poul-Henning Kamp wrote:
In message AA21D17C-0FF4-4B22-B3A3-43AC2B9DAA58@rtty.us, Bob Camp writes:
I'm not bashing the Arm parts, [...] They worry about every uA of
current drain
True story:
Many years ago when the very first ARM silicon arrived and they started
testing it, it was generally execeeding expectations but a little bit
flakey at high clock rates.
After the bubbly had been drunk and hangovers subdued, the serious testing
started and one of the first thing they found was that they had forgotten
to hook up VCC: The chip ran entirely on leaked power from the I/O pins,
most notably the #RESET pin.
When they also connected the VCC pin, it was stable well above spec'ed
speed.
more than one person (including me) has found out that with boards
powered from their I/O interfaces rather than the power supply that they
forgot to turn on.
It's a huge deal in the spacecraft world because of the desire to do
cross strapped redundancy with cold spares. Is the interface truly
"dead faced"? And if you have a pyro actuated cable cutter, what
happens if power from one wire couples into an interface for an
unpowered unit?