In message <m3wsercme4.fsf@donnybrook.brouhaha.com>, Eric Smith 
<eric@brouhaha.com> writes
>Chris H wrote:
>> Actually the top for owners of the USA are in descending order:
>>
>> China
>> Arabs
>> Canada
>> Mexico.
>
>Actually, by far the majority of the US, both in terms of physical
>assets and in terms of national debt (T-bills), is still owned by US
>citizens.

Not any more.

-- 
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills  Staffs  England     /\/\/\/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

>> Actually the top for owners of the USA are in descending order:
>>
>> China
>> Arabs
>> Canada
>> Mexico.
> 
> Actually, by far the majority of the US, both in terms of physical
> assets and in terms of national debt (T-bills), is still owned by US
> citizens.

And this all has what to do with "latency needed in an RTOS"?

Chris H wrote:
> Actually the top for owners of the USA are in descending order:
>
> China
> Arabs
> Canada
> Mexico.

Actually, by far the majority of the US, both in terms of physical
assets and in terms of national debt (T-bills), is still owned by US
citizens.

In message <HOKdnSHT86QQ9rHUnZ2dnUVZ8t_inZ2d@posted.visi>, Grant Edwards 
<grante@visi.com> writes
>On 2008-11-25, Chris H <chris@phaedsys.org> wrote:
>> In message
>><ad12496d-8423-43f6-8f94-de3e2c54b2b7@k19g2000yqg.googlegroups.com>,
>> helix <ted@ohmslaw.co.uk> writes
>>>
>>>Anyway ??? how come most of you have time to have long lengthy arguments
>>>about using crappy tools instead of actually getting on with the
>>>development? No wonder the Chinese now own US and (shortly) Europe.
>>
>> Actually the top for owners of the USA are in descending order:
>>
>> China
>> Arabs
>> Canada
>> Mexico.
>
>They're sure going to be pissed off when they find out what
>we've done to the place...

I don't think so. It was not done by the US.  Other people have been 
pulling the strings for  a year or two. It is no coincidence the crunch 
came right on a US presidential election.

The US lost WW3 without even realising it had started let alone seeing 
the enemy


-- 
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills  Staffs  England     /\/\/\/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

On 2008-11-25, Chris H <chris@phaedsys.org> wrote:
> In message 
><ad12496d-8423-43f6-8f94-de3e2c54b2b7@k19g2000yqg.googlegroups.com>, 
> helix <ted@ohmslaw.co.uk> writes
>>
>>Anyway ??? how come most of you have time to have long lengthy arguments
>>about using crappy tools instead of actually getting on with the
>>development? No wonder the Chinese now own US and (shortly) Europe.
>
> Actually the top for owners of the USA are in descending order:
>
> China
> Arabs
> Canada
> Mexico.

They're sure going to be pissed off when they find out what
we've done to the place...

-- 
Grant

In message 
<ad12496d-8423-43f6-8f94-de3e2c54b2b7@k19g2000yqg.googlegroups.com>, 
helix <ted@ohmslaw.co.uk> writes
>
>Anyway &ndash; how come most of you have time to have long lengthy arguments
>about using crappy tools instead of actually getting on with the
>development? No wonder the Chinese now own US and (shortly) Europe.

Actually the top for owners of the USA are in descending order:

China
Arabs
Canada
Mexico.

Yes, Canada and Mexico are 3 and 4 globally in owning the USA.


-- 
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills  Staffs  England     /\/\/\/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

helix wrote:
> You lot are daft as hell.

That's nice, but are you going to answer the question?
Here I'll re-quote and attribute it for you.

> David Brown wrote:
>> I read this as helix claiming that RT-Linux was not 
>> flexible, and Juergen asking what he considers
>> inflexible about RT-Linux. I haven't used Linux for any
>> real-time work myself, but I too am curious as to what
>> helix considers inflexible about it.

So, why do you consider RT-Linux inflexible?


-- 
Michael N. Moran           (h) 770 516 7918
5009 Old Field Ct.         (c) 678 521 5460
Kennesaw, GA, USA 30144    http://mnmoran.org

"So often times it happens, that we live our lives in chains
  and we never even know we have the key."
"Already Gone" by Jack Tempchin (recorded by The Eagles)

The Beatles were wrong: 1 & 1 & 1 is 1

You lot are daft as hell.

It is pretty obvious to any Firmware Engineer in commercial sector why
Linux + RT is inflexible as hell.

It would be pretty bad if my employers and bill payers realised that
they pay for me to make my own set of spanners, screwdrivers, meters,
calibration equipment, workbench, DSO, logic  etc AS WELL as
developing their products =85.. well it would be great fun, but sadly I
(and my girlfriend) like to eat most days :)

Anyway =96 how come most of you have time to have long lengthy arguments
about using crappy tools instead of actually getting on with the
development? No wonder the Chinese now own US and (shortly) Europe.

P.S I will be helpful and suggest the OP to read this to appreciate
development concepts around =91strict real time=92 (as freeRTOS calls them
here) :
http://www.freertos.org/tutorial/index.html

Chris H wrote:
> In message <ggdvfi$qkn$01$1@news.t-online.com>, Juergen Beisert 
> <jbeisert@netscape.net> writes
>> helix wrote:
>>>
>>> Linux with RT patch is not available on as many platforms as real RTOS
>>> are,
>>
>> It supports most (not all) of the CPUs listed in arch:
>> $ ls -F linux-2.6.26/arch/
>> alpha/  blackfin/ h8300/   m32r/   mips/   powerpc/  sh/   um/
>> xtensa/ arm/      cris/    ia64/   m68k/   mn10300/  ppc/  sparc/
>> v850/   avr32/    frv/     m68knommu/      parisc/   s390/ sparc64/
>> x86/
> 
> 
> That is not a particularly wide range and is mainly large MCU. However 
> it is still not an RTos.
> 

*Linux* is mainly for large MCU - it requires a 32-bit cpu, memory 
measured in MB, and preferably an MMU (though you can do without if 
necessary).  It is a much wider range of cpus than any other *large* OS 
I have heard of.  Remember, it is not comparable with something like 
FreeRTOS (which would, of course, be a far better match for most 
projects that require controlled latencies and RT behaviour).

>>> and is not flexible.
>> Why not?
> 
> God question.
> 

"God" question?

I read this as helix claiming that RT-Linux was not flexible, and 
Juergen asking what he considers inflexible about RT-Linux.  I haven't 
used Linux for any real-time work myself, but I too am curious as to 
what helix considers inflexible about it.

>>> So there is not much point in trying to make it work in a RT enviroment.
>> Why not? We do. You can work with it like every other Linux system,
> Which is not RT

Correct - many tasks in many systems do not have critical time 
constraints.  Often you will split a system into a critical part that 
has RT constraints, and a more general non-critical part.  One way to 
handle such splits is to have a dedicated microcontroller for the 
critical parts (running a "pure" RTOS like FreeRTOS), and the general 
part running something else (such as "normal" Linux).  Using one of the 
several RT Linux systems gives you another option - run the non-critical 
parts as normal non-RT Linux processes, and run the critical parts as RT 
processes.

>> plus
>> some userland threads/processes or kernel threads are working with 
>> realtime
>> capabilities.
> 
> "Some" so it is not a real RTOS.  BTW I have not worked on Linux but I 
> have worked on UNIX which is also not a real RTos
> 

Linux is not UNIX - they simply have a wide area of overlap in system 
philosophy and API.

And having *some* processes or threads running with real-time 
constraints *does* make it a real RTOS.  You run real-time tasks with 
real-time priorities, and non-real-time tasks without worrying about 
precise or controlled latencies.  That applies regardless of what OS (if 
any) you use in your real-time system.

> 
>>> Latency is what every you need in an RTOS.
>> You only need the latency your application specifies. The main feature 
>> of a
>> RTOS is to guarantee this latency independent what happens else in your
>> system.
> 
> Yes... So a 60 second latency might be acceptable. :-)
> 

Yes.

In message <ggdvfi$qkn$01$1@news.t-online.com>, Juergen Beisert 
<jbeisert@netscape.net> writes
>helix wrote:
>>
>> Linux with RT patch is not available on as many platforms as real RTOS
>> are,
>
>It supports most (not all) of the CPUs listed in arch:
>$ ls -F linux-2.6.26/arch/
>alpha/  blackfin/ h8300/   m32r/   mips/   powerpc/  sh/   um/
>xtensa/ arm/      cris/    ia64/   m68k/   mn10300/  ppc/  sparc/
>v850/   avr32/    frv/     m68knommu/      parisc/   s390/ sparc64/
>x86/


That is not a particularly wide range and is mainly large MCU. However 
it is still not an RTos.

>> and is not flexible.
>Why not?

God question.

>> So there is not much point in trying to make it work in a RT enviroment.
>Why not? We do. You can work with it like every other Linux system,
Which is not RT
> plus
>some userland threads/processes or kernel threads are working with realtime
>capabilities.

"Some" so it is not a real RTOS.  BTW I have not worked on Linux but I 
have worked on UNIX which is also not a real RTos


>> Latency is what every you need in an RTOS.
>You only need the latency your application specifies. The main feature of a
>RTOS is to guarantee this latency independent what happens else in your
>system.

Yes... So a 60 second latency might be acceptable. :-)

-- 
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills  Staffs  England     /\/\/\/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/