In message 50e4c479.5080...@earthlink.net, Jim Lux writes:
On 1/2/13 11:37 AM, Poul-Henning Kamp wrote:
Actually, the OS is not important, floating point support is.
floating point support in the sense that the compiler supports it and
generates appropriate code to use software FP or
In message cahjg12qxpb9px8dp6ngk-x575etnsfc+csqr6acsrx7gfw-...@mail.gmail.com
, Tom Harris writes:
+1 for Forth!
Indeed, but for me that is only an indulgence :-)
+1 for your opinions on PICs AVRs. We can buy low end NXP ARM Cortex M0
chips (e.g. LPC1113) for less than the PIC18 we
On 1/3/13 12:53 AM, Poul-Henning Kamp wrote:
In general, you should reuse as much code as you can, life is too short
to write another UDP checksum subroutine.
You captured it exactly..
The thrill of implementing sin() is long past.
Heck, I'd be happy with something that ran
On 1/1/2013 4:58 PM, time-nuts-requ...@febo.com wrote:
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,
In message 50e45382.8090...@irtelemetrics.com, Dan Kemppainen writes:
Back on topic (sort of). I've been playing with some of the PIC24
chips lately. They have some neat oscillator options internally,
I've given up on PIC and Atmel microcontrollers and their antiquated
CPU designs.
On Wed, Jan 2, 2013 at 11:16 AM, Poul-Henning Kamp p...@phk.freebsd.dk wrote:
I've given up on PIC and Atmel microcontrollers and their antiquated
CPU designs.
My life is too short to fight odd-ball compilers, when I can get a
real 32 bit CPU and a good compiler instead.
That is a valid
In message CABbxVHuc1CcVqa2fgY_nriNrT3PYHtP8BSi=5=bsbk9eyhl...@mail.gmail.com
, Chris Albertson writes:
That is a valid point if you are building a one-off project. Your
time is worth something. But if you plan to sell a million AA cell
battery chargers using a 32-bit controller is
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 02/01/2013 19:25, Chris Albertson wrote:
For an NTP server I'd go with something that can run an OS and the
NTP reverence implementation. ARM (and others) can do that.
This is exactly what I've done using the Raspberry Pi (Broadcom ARM
SOC
From: James Harrison
[]
This is exactly what I've done using the Raspberry Pi (Broadcom ARM
SOC running Linux) and a GPS module with the PPS kernel hook for Linux
GPIO. Still a beginner/aspiring time-nut so I'm not sure on accuracy
(PLL offset jitter suggests ~5-10ms worst-case but I've not
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 02/01/2013 20:05, David J Taylor wrote:
James,
You might be interested in my write-up:
http://www.satsignal.eu/ntp/Raspberry-Pi-NTP.html
and its performance:
http://www.satsignal.eu/mrtg/performance_ntp.php
I was playing with
On 1/2/13 11:37 AM, Poul-Henning Kamp wrote:
Actually, the OS is not important, floating point support is.
floating point support in the sense that the compiler supports it and
generates appropriate code to use software FP or hardware FP as available?
Or you need HW floating point for
On Wed, Jan 2, 2013 at 12:37 PM, Poul-Henning Kamp p...@phk.freebsd.dk wrote:
Actually, the OS is not important, floating point support is.
That is one reason that the recent crop of inexpensive ARM Cortex M4
experimenter boards is quite interesting. I picked up two of the TI
Stellaris
Hi
That's the point I've been trying to make for about a month now. At some point,
for a hobby project, the cost of the CPU becomes irrelevant. In my book, once
the CPU goes below the price of lunch at McDonalds, it really doesn't matter
much.
Bob
On Jan 2, 2013, at 7:36 PM, Joseph Gray
On 1/2/13 4:46 PM, Bob Camp wrote:
Hi
That's the point I've been trying to make for about a month now. At some point,
for a hobby project, the cost of the CPU becomes irrelevant. In my book, once
the CPU goes below the price of lunch at McDonalds, it really doesn't matter
much.
yes..
Hi
Arduino's original popularity was based on low cost. These days you can get a
*lot* more for your money.
Bob
On Jan 2, 2013, at 8:07 PM, Jim Lux jim...@earthlink.net wrote:
On 1/2/13 4:46 PM, Bob Camp wrote:
Hi
That's the point I've been trying to make for about a month now. At some
+1 for Forth!
+1 for your opinions on PICs AVRs. We can buy low end NXP ARM Cortex M0
chips (e.g. LPC1113) for less than the PIC18 we were using before, and it
has a real compiler and (unlike the real world) evidence of intelligent
design!
Do you really need an OS? Surely for a box that is only
On 1/2/13 5:34 PM, Tom Harris wrote:
+1 for Forth!
+1 for your opinions on PICs AVRs. We can buy low end NXP ARM Cortex M0
chips (e.g. LPC1113) for less than the PIC18 we were using before, and it
has a real compiler and (unlike the real world) evidence of intelligent
design!
Do you really
On 01/02/2013 08:34 PM, Tom Harris wrote:
Do you really need an OS? Surely for a box that is only ever going to be an
NTP server you just need a network interface and good maths? I've just seen
a later comment where you mention floating point support, but would 64 bit
integer maths work just as
On 03/01/13 03:26, Jim Lux wrote:
On 1/2/13 5:34 PM, Tom Harris wrote:
+1 for Forth!
+1 for your opinions on PICs AVRs. We can buy low end NXP ARM Cortex M0
chips (e.g. LPC1113) for less than the PIC18 we were using before, and it
has a real compiler and (unlike the real world) evidence of
how about a Propeller? 8 cpu's no waiting :-)
Don
Magnus Danielson
On 03/01/13 03:26, Jim Lux wrote:
On 1/2/13 5:34 PM, Tom Harris wrote:
+1 for Forth!
+1 for your opinions on PICs AVRs. We can buy low end NXP ARM
Cortex M0
chips (e.g. LPC1113) for less than the PIC18 we were using
Not only SSH access, loggin g things like DNS lookup and rading the
ntp.comf file from local (flash?) memory. And then without an OS
you'd have to implement sceduling and process creation yourself. How
else to accept SSH log ins, talk to multiple NT clients and yu
reference clocks and write to
Hi
The only problem you may run into with an input capture is that the 72 MHz may
be from an internal VCO that's locked to the external clock source or crystal.
Often these micro's don't have VCO's that are as good a one might hope. You
will indeed have less than 1 UI jitter, you may not have
On Tue, 1 Jan 2013 11:23:57 -0500
Bob Camp li...@rtty.us wrote:
The only problem you may run into with an input capture is that the
72 MHz may be from an internal VCO that's locked to the external clock
source or crystal. Often these micro's don't have VCO's that are as good
a one might hope.
On 01/01/13 17:34, Attila Kinali wrote:
On Tue, 1 Jan 2013 11:23:57 -0500
Bob Campli...@rtty.us wrote:
The only problem you may run into with an input capture is that the
72 MHz may be from an internal VCO that's locked to the external clock
source or crystal. Often these micro's don't have
Hi
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.
Bob
On Jan
Hoi Bob,
On Tue, 1 Jan 2013 12:03:49 -0500
Bob Camp li...@rtty.us wrote:
On Jan 1, 2013, at 11:34 AM, Attila Kinali att...@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
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
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
In message aa21d17c-0ff4-4b22-b3a3-43ac2b9da...@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
PM
Subject: Re: [time-nuts] An embedded NTP server
In message aa21d17c-0ff4-4b22-b3a3-43ac2b9da...@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
The NXP LPC111x series has a PLL that runs at 156 to 320 MHz. You then divide
the clock down (internally by 2,4,8, or 16) to what you want. 50 MHz is the
max. for the LPC111x series. Giving you capture ticks in 20nS increments.
I have some experiments in the works with an LPC1114 chip and a 40
In message 1357073110.35421.yahoomail...@web160905.mail.bf1.yahoo.com, M. Si
mon writes:
The NXP LPC111x series [...]
My personal preference is the LPC1343, because it has a USB port, and
because there is a reltively nice codebase to start from:
On 1/1/13 12:16 PM, Poul-Henning Kamp wrote:
In message aa21d17c-0ff4-4b22-b3a3-43ac2b9da...@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
.
From: Poul-Henning Kamp p...@phk.freebsd.dk
To: M. Simon msimon6...@yahoo.com; Discussion of precise time and frequency
measurement time-nuts@febo.com
Sent: Tuesday, January 1, 2013 9:26 PM
Subject: Re: [time-nuts] An embedded NTP server
In message
Kamp p...@phk.freebsd.dk
To: M. Simon msimon6...@yahoo.com; Discussion of precise time and frequency
measurement time-nuts@febo.com
Sent: Tuesday, January 1, 2013 9:26 PM
Subject: Re: [time-nuts] An embedded NTP server
In message 1357073110.35421.yahoomail...@web160905.mail.bf1.yahoo.com
Hi
The VCO is part of the process, the PLL and it's loop are another part. There's
no reason why they can't put a good loop in a micro, other than chip area for
the passive parts. What ever they do, the loop will probably be a compromise,
since the frequencies involved are not known at design
can get at
a profit.
From: Poul-Henning Kamp p...@phk.freebsd.dk
To: M. Simon msimon6...@yahoo.com; Discussion of precise time and
frequency measurement time-nuts@febo.com
Sent: Tuesday, January 1, 2013 9:26 PM
Subject: Re: [time-nuts] An embedded NTP server
On 12/28/2012 12:34 PM, Chris Albertson wrote:
One idea that I like is to first get a large FPGA. Then you load in a
soft CPU and then you run an OS and NTP on the soft CPU. Inside
the softCPU the counter is implemented like it is in a real CPU but
you can add the ability for a PPS to latch
On Thu, Dec 27, 2012 at 1:36 AM, Hal Murray hmur...@megapathdsl.net wrote:
It would be interesting to see what ntpd would do on a system with a very
good clock and/or what you could do to the code/heuristics to take advantage
of a stable clock.
I've read reports of people who have
Hi
Much easier to simply use a cheap chip set (as in sub $3) that supports 1588
packet time stamping. It's doing everything you would need to do as far as
packet time of arrival. The heavy lifting would all be in the area of porting
that data into the NTP server.
Bob
On Dec 28, 2012, at
On 12/28/12 9:34 AM, Chris Albertson wrote:
On Thu, Dec 27, 2012 at 1:36 AM, Hal Murray hmur...@megapathdsl.net wrote:
One idea that I like is to first get a large FPGA. Then you load in a
soft CPU and then you run an OS and NTP on the soft CPU. Inside
the softCPU the counter is
albertson.ch...@gmail.com said:
The VXCO quality hardly matters for an NTP server. As long as it does not
gain out loose more then 1 uSecond per second. In other words one part per
million is fine for NTP. The goal is not to produce a 10MHz GDPDO. Clients
using this server over the
On 12/27/2012 01:41 AM, Michael Tharp wrote:
The good news is that the disciplining algorithm I lifted from my
previous GPSDO project works quite well, and I have the gritty details
of measuring the PPS worked out. If I can get the Trimble working
tomorrow I might have much better results soon,
@febo.com
Subject: Re: [time-nuts] An embedded NTP server
On 12/25/2012 02:51 PM, David J Taylor wrote:
I think you should be able to do better on the jitter as your
algorithms develop.
Yes, for starters something is causing a silly amount of extra latency hence
the 2.4ms round-trip. I managed
From: Michael Tharp
[]
Oh, and your Windows box 172.24.0.68 is either poorly configured or
broken - they can work much, much better than yours illustrates as I
expect you know.
Yes, it's not healthy. I installed Meinberg's NTP build and configured
it using defaults other than the server list
: Michael Tharp g...@partiallystapled.com
To: Discussion of precise time and frequency measurement
time-nuts@febo.com
Subject: [time-nuts] An embedded NTP server
Message-ID: 50d9dfe6.2050...@partiallystapled.com
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Hello and Merry
an OSH Park gold plated board. I love
their service.
Simon
===
Message: 1
Date: Tue, 25 Dec 2012 12:18:30 -0500
From: Michael Tharp g...@partiallystapled.com
To: Discussion of precise time and frequency measurement
time-nuts@febo.com
Subject: [time-nuts] An embedded
On 12/26/2012 12:01 PM, Chris Albertson wrote:
The VXCO quality hardly matters for an NTP server. As long as it
does not gain out loose more then 1 uSecond per second. In other
words one part per million is fine for NTP. The goal is not to
produce a 10MHz GDPDO. Clients using this server
Hello and Merry Christmas,
I made an embedded (S)NTP server. The software is still under
development and will eventually include a low-grade GPSDO but right now
even the simplistic algorithm is working quite well so I figured I'd share.
Hello and Merry Christmas,
I made an embedded (S)NTP server. The software is still under
development and will eventually include a low-grade GPSDO but right now
even the simplistic algorithm is working quite well so I figured I'd share.
On 12/25/2012 02:51 PM, David J Taylor wrote:
I think you should be able to do better on the jitter as your algorithms
develop.
Yes, for starters something is causing a silly amount of extra latency
hence the 2.4ms round-trip. I managed to cut that in half by changing
compiler options but
This is good. And really good that you have opened the design. Once
a few of these get out into the wild you can start seeing software
contributions and the performance will improve. We know that an ARM
based NTP server can do very well. Hopefully it can one day beat a
low-end Linux setup
52 matches
Mail list logo
