[time-nuts] An embedded NTP server

[Don Latham]

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 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
>
> _______________________________________________
> time-nuts mailing list -- time-nuts at febo.com
> To unsubscribe, go to
> https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> and follow the instructions there.
>


-- 
"Neither the voice of authority nor the weight of reason and argument
are as significant as experiment, for thence comes quiet to the mind."
De Erroribus Medicorum, R. Bacon, 13th century.
"If you don't know what it is, don't poke it."
Ghost in the Shell


Dr. Don Latham AJ7LL
Six Mile Systems LLP
17850 Six Mile Road
POB 134
Huson, MT, 59846
VOX 406-626-4304
www.lightningforensics.com
www.sixmilesystems.com