[time-nuts] An embedded NTP server
Magnus Danielson
magnus at rubidium.dyndns.org
Thu Jan 3 03:36:26 UTC 2013
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 intelligent
>> design!
>>
>> 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 well?
>
>
> Well, one might not need a full-up multitasking OS, but I'd sure like to
> have a high level interface to the network (say BSD sockets or something
> like that). And most OSes (or OS-like infrastructure) also gives you
> some handy stuff like timers, threads, queues, etc.
>
> If you are doing something that is TRULY single function, the "one big
> loop" scheme can work, particularly if you've got a lot of nice
> libraries to do stuff like string handling/parsing/device interaction.
It fails quite quickly if you have not though through the real time
execution needs. Essentially, what execute when, triggered by what, with
what data and how late can it be, and what else needs to be done?
Real time properties does not need to be resolved by a real-time
operating system, but it needs to be resolved by doing the real time
analysis, and then attempting to find stable solutions. Bare-bone
processors can work just as well, but things like HW-drivers, lack of
network support etc. can be trouble-some.
> I think the dividing line might be where you are trying to do more than
> one thing with different time scales. It would be straightforward to do
> something like multiple PID loops with a common sample/update rate (like
> a lot of PLC industrial controllers do), but as soon as you start
> running things at different rates (check the Ethernet, check the serial
> port, update the loop, etc.) having an OS to do the book-keeping is
> pretty nice.
If it gives the needed infrastructure. It can just as well keep the
confusion high enough that the issues becomes fuzzidized enough for you
not to see them clearly.
Also, do not underestimate what a little HW/FW-support can do to relax
requirements significantly, or for that matter seemingly trivial OS
support features. HW/FW timestamping is one. Good quality timer support
another.
Just grabbing an RTOS and believing that it will solve all problems will
not work. I've seen it fail miserably. I all to often see people
expecting "a few lines of code" to solve bad system design, so do the
system design and figure out your needs, then figure out what hardware
and software platforms support those needs the best. You end up with a
few alternatives and then iterate a good solution. It's always in the
nitty gritty details, so few wide assumptions work very well.
Cheers,
Magnus
More information about the time-nuts
mailing list