time@patoka.org said:
In addition, even MCU has not enough resources to handle TCP/IP, DHCP and
NTP, it is some solutions available to outsource it to dedicated chips. I
was using WIZ5100 (assembled as a modules) with great success.
NTP is pretty simple. If you are willing to take a few shortcuts, things get even simpler. If you have a NTP server on your LAN, you can skip routing and DHCP by broadcasting a request. It would be interesting to see how small you could make a set-the-time package.
The Xerox Alto had an Ethernet boot loader in microcode. (and space in the microcode ROM was tight) When bringing up a new machine, we figured out that it was much simpler and faster to debug the Ethernet before the disk controller. The debugger worked over the Ethernet. That gave you a solid place to stand early in the debugging process.
--
These are my opinions. I hate spam.
DHCP is handy to provide the IP address and specify which NTP server to
use. Using DHCP I don't need to setup all the network settings for my
project. The NTP packet parser itself is really small and doing its duty
very well. Using such setup, it gives me flexibility to choose the
different NTP servers as a time source. It could be my own NTP or it
could be NTP pool.
On 2016-07-12 16:21, Hal Murray wrote:
time@patoka.org said:
In addition, even MCU has not enough resources to handle TCP/IP, DHCP
and
NTP, it is some solutions available to outsource it to dedicated
chips. I
was using WIZ5100 (assembled as a modules) with great success.
NTP is pretty simple. If you are willing to take a few shortcuts,
things get even simpler. If you have a NTP server on your LAN, you
can skip routing and DHCP by broadcasting a request. It would be
interesting to see how small you could make a set-the-time package.
The Xerox Alto had an Ethernet boot loader in microcode. (and space
in the microcode ROM was tight) When bringing up a new machine, we
figured out that it was much simpler and faster to debug the Ethernet
before the disk controller. The debugger worked over the Ethernet.
That gave you a solid place to stand early in the debugging process.
--
WBW,
V.P.
Hi Hal,
I've done NTP before, I wanted to do this with GPS since I have never
done a GPS implementation before.
Xerox Alto, wow that brings back memories! My dad worked at Xerox in
Palo Alto for 20 years in the 70s and 80s. He primarily worked on the D
machines but I did get to use an Alto a few times when I was in high
school. I learned Mesa sitting in front of one.
That must have been 3Mbit Ethernet right?
I remember going to the lab one Saturday, they were working on a machine
that was supposed to have a custom chip, but it was not ready, so they
used 7 ASICs, but those were not ready yet either, so they made a large
board out of TTL for each ASIC with a ribbon cable into the motherboard,
these boards were hung on fishing line from the ceiling so they were
just above the motherboard with a very short cable. That thing really
looked like something out of a movie.
John S.
On 7/12/2016 1:21 PM, Hal Murray wrote:
time@patoka.org said:
In addition, even MCU has not enough resources to handle TCP/IP, DHCP and
NTP, it is some solutions available to outsource it to dedicated chips. I
was using WIZ5100 (assembled as a modules) with great success.
NTP is pretty simple. If you are willing to take a few shortcuts, things get even simpler. If you have a NTP server on your LAN, you can skip routing and DHCP by broadcasting a request. It would be interesting to see how small you could make a set-the-time package.
The Xerox Alto had an Ethernet boot loader in microcode. (and space in the microcode ROM was tight) When bringing up a new machine, we figured out that it was much simpler and faster to debug the Ethernet before the disk controller. The debugger worked over the Ethernet. That gave you a solid place to stand early in the debugging process.