[time-nuts] An embedded NTP server

[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 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