Looking for ARM system with RTOS

I'm right at the end of my tether in trying to move some real time stuff 
(MIDI) to Linux. The ARM-9 platform I've chosen, while very nice in other 
ways, uses a proprietary FPGA interface for all the port inputs, that makes 
it next to impossible to strip out the OS and replace it with something 
else, or to go right back to CPU-side code cutting (which is what I've 
always done in the past). My testing has shown that the Linux platform is 
right on the limit in terms of speed, and kernel interrupts could easily 
sink the whole show.

Has anyone got a suggestion for a combination of an ARM SBC platform and a 
RTOS (preferably free or hobby-level cost) that I could adopt? I've followed 
the many comments in this newsgroup and others for a while, and also done a 
lot of browsing and struggling with selection lists, but the supplier 
websites for ARM seem to be singularly hard to get into unless you're a 
guru, which I'm not.

I need:

o  CPU clock 200MHz or higher.

o  2 serial ports, with access to the logic level lines on at least one (LV 
OK).

o  USB support. Socket support also would  be nice, not essential.

o  Some sort of file system.

o  Guaranteed turnround of 10mS, even lower would be nice. My ARM Linux 
won'd do better than 20.

I don't need:

o  ADCs or DACs or audio in/out.

o  Monitor/graphics output.


Suggestions that don't turn out will remain appreciated. Any ARM system with 
RTOS will be a nice addition to my kit. We all have a few in our bits box.

Or a website that would facilitate my search.

Any input would make my day. 

On 2012-12-31, Bruce Varley <bv@NoSpam.com> wrote:
> I'm right at the end of my tether in trying to move some real time stuff 
> (MIDI) to Linux. The ARM-9 platform I've chosen, while very nice in other 
> ways, uses a proprietary FPGA interface for all the port inputs, that makes 
> it next to impossible to strip out the OS and replace it with something 
> else, or to go right back to CPU-side code cutting (which is what I've 
> always done in the past). My testing has shown that the Linux platform is 
> right on the limit in terms of speed, and kernel interrupts could easily 
> sink the whole show.
>
> Has anyone got a suggestion for a combination of an ARM SBC platform and a 
> RTOS (preferably free or hobby-level cost) that I could adopt? I've followed 
> the many comments in this newsgroup and others for a while, and also done a 
> lot of browsing and struggling with selection lists, but the supplier 
> websites for ARM seem to be singularly hard to get into unless you're a 
> guru, which I'm not.
>

I don't have anything firm unfortunately, but just some further reading
suggestions in case you are not aware of them. I also think you are
probably going to have to assemble a solution from various pieces.

> I need:
>
> o  CPU clock 200MHz or higher.
>

How much memory ?

Have you looked on the Olimex website at their latest boards ?

They have added a range of USB host capable boards over the last few
months, in addition to their existing ones.

> o  2 serial ports, with access to the logic level lines on at least one (LV 
> OK).
>

Not really sure what you need here. Are you asking for the ability to
read the control pins directly on a RS232 port, or is this for another
RSxxx type interface on serial port hardware ?

> o  USB support. Socket support also would  be nice, not essential.
>

I am assuming USB host here.

This is probably going to be your main problem in the free/open source
RTOS area; I've looked for open source USB host stacks in the past for
bare metal or a open source RTOS but without any real match on requirements.
RTEMS has initial support for a USB host stack, but it's not yet been
integrated into the release code base AFAIK:

http://www.rtems.org/wiki/index.php/USBStack

Then there's this:

http://hackaday.com/2011/11/11/lufa-open-source-usb-stack-now-for-nxp-arm-processors/

It sounds like your resource needs are greater than what the PIC32 offers,
(and you asked for ARM, not MIPS), but Microchip do a free USB host stack
(but the license restricts you to running it on Microchip MCUs only).

> o  Some sort of file system.
>

This is available in RTEMS.

> o  Guaranteed turnround of 10mS, even lower would be nice. My ARM Linux 
> won'd do better than 20.
>

20mS ? Ouch. :-(

Have a read through the RTEMS scheduling options in the online documentation.
http://www.rtems.org/onlinedocs/releases/rtemsdocs-4.10.2/share/rtems/html/

I have not done anything with RTEMS recently (it's been all bare metal
recently) and I unfortunately cannot remember where some example RTEMS
performance benchmarks are listed.

The RTEMS developers supply a tmtests test suite in the source kit however,
so you could use it as the basis of testing on a BSP of your choice.

You may find the Wiki of use as well:

http://www.rtems.org/wiki/index.php/Main_Page

> I don't need:
>
> o  ADCs or DACs or audio in/out.
>
> o  Monitor/graphics output.
>
>
> Suggestions that don't turn out will remain appreciated. Any ARM system with 
> RTOS will be a nice addition to my kit. We all have a few in our bits box.
>
> Or a website that would facilitate my search.
>
> Any input would make my day. 
>

Sorry the information above is more vague and less firm than normal, but
given the frustration you are obviously feeling, you might find _any_
information helpful. :-)

Simon.

-- 
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world

"Simon Clubley" <clubley@remove_me.eisner.decus.org-Earth.UFP> wrote in 
message news:kbtksl$2ss$1@dont-email.me...
> On 2012-12-31, Bruce Varley <bv@NoSpam.com> wrote:
>> I'm right at the end of my tether in trying to move some real time stuff
>> (MIDI) to Linux. The ARM-9 platform I've chosen, while very nice in other
>> ways, uses a proprietary FPGA interface for all the port inputs, that 
>> makes
>> it next to impossible to strip out the OS and replace it with something
>> else, or to go right back to CPU-side code cutting (which is what I've
>> always done in the past). My testing has shown that the Linux platform is
>> right on the limit in terms of speed, and kernel interrupts could easily
>> sink the whole show.
>>
>> Has anyone got a suggestion for a combination of an ARM SBC platform and 
>> a
>> RTOS (preferably free or hobby-level cost) that I could adopt? I've 
>> followed
>> the many comments in this newsgroup and others for a while, and also done 
>> a
>> lot of browsing and struggling with selection lists, but the supplier
>> websites for ARM seem to be singularly hard to get into unless you're a
>> guru, which I'm not.
>>
>
> I don't have anything firm unfortunately, but just some further reading
> suggestions in case you are not aware of them. I also think you are
> probably going to have to assemble a solution from various pieces.
>
>> I need:
>>
>> o  CPU clock 200MHz or higher.
>>
>
> How much memory ?
>
> Have you looked on the Olimex website at their latest boards ?
>
> They have added a range of USB host capable boards over the last few
> months, in addition to their existing ones.
>
>> o  2 serial ports, with access to the logic level lines on at least one 
>> (LV
>> OK).
>>
>
> Not really sure what you need here. Are you asking for the ability to
> read the control pins directly on a RS232 port, or is this for another
> RSxxx type interface on serial port hardware ?
>
>> o  USB support. Socket support also would  be nice, not essential.
>>
>
> I am assuming USB host here.
>
> This is probably going to be your main problem in the free/open source
> RTOS area; I've looked for open source USB host stacks in the past for
> bare metal or a open source RTOS but without any real match on 
> requirements.
> RTEMS has initial support for a USB host stack, but it's not yet been
> integrated into the release code base AFAIK:
>
> http://www.rtems.org/wiki/index.php/USBStack
>
> Then there's this:
>
> http://hackaday.com/2011/11/11/lufa-open-source-usb-stack-now-for-nxp-arm-processors/
>
> It sounds like your resource needs are greater than what the PIC32 offers,
> (and you asked for ARM, not MIPS), but Microchip do a free USB host stack
> (but the license restricts you to running it on Microchip MCUs only).
>
>> o  Some sort of file system.
>>
>
> This is available in RTEMS.
>
>> o  Guaranteed turnround of 10mS, even lower would be nice. My ARM Linux
>> won'd do better than 20.
>>
>
> 20mS ? Ouch. :-(
>
> Have a read through the RTEMS scheduling options in the online 
> documentation.
> http://www.rtems.org/onlinedocs/releases/rtemsdocs-4.10.2/share/rtems/html/
>
> I have not done anything with RTEMS recently (it's been all bare metal
> recently) and I unfortunately cannot remember where some example RTEMS
> performance benchmarks are listed.
>
> The RTEMS developers supply a tmtests test suite in the source kit 
> however,
> so you could use it as the basis of testing on a BSP of your choice.
>
> You may find the Wiki of use as well:
>
> http://www.rtems.org/wiki/index.php/Main_Page
>
>> I don't need:
>>
>> o  ADCs or DACs or audio in/out.
>>
>> o  Monitor/graphics output.
>>
>>
>> Suggestions that don't turn out will remain appreciated. Any ARM system 
>> with
>> RTOS will be a nice addition to my kit. We all have a few in our bits 
>> box.
>>
>> Or a website that would facilitate my search.
>>
>> Any input would make my day.
>>
>
> Sorry the information above is more vague and less firm than normal, but
> given the frustration you are obviously feeling, you might find _any_
> information helpful. :-)
>
> Simon.
>
> -- 
> Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
> Microsoft: Bringing you 1980s technology to a 21st century world

Thanks Simon, really appreciated. I'm sure your refs will get me going. 
Cheers 

On Tue, 1 Jan 2013 09:54:30 +0800, "Bruce Varley" <bv@NoSpam.com>
wrote:

>I need:
>
>o  CPU clock 200MHz or higher.
>
>o  2 serial ports, with access to the logic level lines on at least one (LV 
>OK).
>
>o  USB support. Socket support also would  be nice, not essential.
>
>o  Some sort of file system.
>
>o  Guaranteed turnround of 10mS, even lower would be nice. My ARM Linux 
>won'd do better than 20.

What Linux version and what scheduling policy are you using to get 20
ms ?

If you need 100 % hard real time performance no general purpose OS
will do. If you can live with soft real time (99.9... % reliability),
general purpose OSes such as Windows/Linux can be used,

It should be noted that in any priority based scheduling, only the
highest priority task response times (interrupts, rescheduling) can be
guarantied, unless you have full control of the execution time of that
high priority task(s).
 

On Tue, 01 Jan 2013 12:09:40 +0200, upsidedown@downunder.com
wrote:

>On Tue, 1 Jan 2013 09:54:30 +0800, "Bruce Varley" <bv@NoSpam.com>
>wrote:
>
>>I need:
>>
>>o  CPU clock 200MHz or higher.
>>
>>o  2 serial ports, with access to the logic level lines on at least one (LV 
>>OK).
>>
>>o  USB support. Socket support also would  be nice, not essential.
>>
>>o  Some sort of file system.
>>
>>o  Guaranteed turnround of 10mS, even lower would be nice. My ARM Linux 
>>won'd do better than 20.
>
>What Linux version and what scheduling policy are you using to get 20
>ms ?
>
>If you need 100 % hard real time performance no general purpose OS
>will do. If you can live with soft real time (99.9... % reliability),
>general purpose OSes such as Windows/Linux can be used,

I pretty much agree with this. I write my own O/S and, not
infrequently, use a 2 microsecond resolution process timer (I
can switch tasks in 5 cycles -- 100 nanoseconds for a task
switch on the ADSP-21xx I used it on -- with no variation in
timing, guaranteed fixed phase delay.) But the code and the
task switcher are designed together to work well. In that
case, my shortest task-to-task delay was 20 microseconds. But
I also had to control an external ADC at about 1.5Ms/s and
the precision there had to be no more variation, sample to
sample, than about 5 nanoseconds. That was achieved not with
hardware, but with software running on it.

No file system, though. All queue insertions were done
between process starts, so the time involved was hidden.

>It should be noted that in any priority based scheduling, only the
>highest priority task response times (interrupts, rescheduling) can be
>guarantied, unless you have full control of the execution time of that
>high priority task(s).

That's also a sensible comment.

What I did was to carefully craft the processes, knowing
their durations, and lay it all out on a timing diagram so
that I could guarantee each of them their exact start times.
The end times weren't quite as important, so long as I
ensured they were done.

A delta queue design helps. The timer only sees the top
process (all other processes are queued with 'delta' values
relative to the processes ahead of them) and decrements that
time value. When it drops to zero, the proecss is started.
All remaining processes only have delta timers relative to
that, so again the timer only needs to decrement the top
timer value. Keeps 'variability' in timing to zero if you are
careful (assembly) or near zero if it's in C.

The O/S I wrote allows me to include or exclude features at
compile-time, too. I can enable or disable pre-emption,
enable or disable priorities, enable or disable semaphores,
and so on.

But I've never cared about including a file system for it --
I don't need that on measurement instrumentation. What I do
need is precision sampling and absolute guarantees on DAC or
measurement outputs with FFT results you'd expect, so that an
external device (boule puller) can have closed loop control
with well designed control algorithms behaving as expected
from the math.

10ms turnaround would be... unacceptable.

Jon

On Tue, 01 Jan 2013 09:54:30 +0800, Bruce Varley wrote:

> I'm right at the end of my tether in trying to move some real time stuff
> (MIDI) to Linux. The ARM-9 platform I've chosen, while very nice in
> other ways, uses a proprietary FPGA interface for all the port inputs,
> that makes it next to impossible to strip out the OS and replace it with
> something else, or to go right back to CPU-side code cutting (which is
> what I've always done in the past). My testing has shown that the Linux
> platform is right on the limit in terms of speed, and kernel interrupts
> could easily sink the whole show.
> 
> Has anyone got a suggestion for a combination of an ARM SBC platform and
> a RTOS (preferably free or hobby-level cost) that I could adopt? I've
> followed the many comments in this newsgroup and others for a while, and
> also done a lot of browsing and struggling with selection lists, but the
> supplier websites for ARM seem to be singularly hard to get into unless
> you're a guru, which I'm not.
> 
> I need:
> 
> o  CPU clock 200MHz or higher.
> 
> o  2 serial ports, with access to the logic level lines on at least one
> (LV OK).
> 
> o  USB support. Socket support also would  be nice, not essential.
> 
> o  Some sort of file system.
> 
> o  Guaranteed turnround of 10mS, even lower would be nice. My ARM Linux
> won'd do better than 20.
> 
> I don't need:
> 
> o  ADCs or DACs or audio in/out.
> 
> o  Monitor/graphics output.
> 
> 
> Suggestions that don't turn out will remain appreciated. Any ARM system
> with RTOS will be a nice addition to my kit. We all have a few in our
> bits box.
> 
> Or a website that would facilitate my search.
> 
> Any input would make my day.

Hey Bruce:

You may want to revisit the idea of using a real-time Linux variant.  
It's been a long time since I looked, but the approach that seemed to 
guarantee success if you need 100% real-time performance is the one that 
runs an RTOS underneath Linux, with Linux running in a task.

You put all the hard real time stuff under the control of the RTOS, and 
you put Linux at a lower priority, and then Linux pretty much stays out 
of the way of your real-time stuff.  The downside is that you end up 
programming under two operating systems.

Note that my information is at least five years old: at that time the 
"Real-Time Linux" community was divided between the "two-OS" approach and 
one that tried to make Linux into a hard RTOS with kernel extensions.  
I'm not sure if they ever succeeded in the "Linux as really-real time" or 
not.

Note, too, that you can't always trust either a vendor or a customer when 
they use the term "RTOS".  Even after decades of repetition, there's a 
lot of folks that don't understand the mantra "real fast doesn't mean 
real time" (or the corollary: "real slow doesn't rule out real time").  
So a vendor (or a free software group) may say "RTOS", they may _think_ 
they're providing "RTOS", and in the end they may just be providing "real 
fast" or "soft real time*".

This may be a solution if you can't find a free USB host stack, and if 
your USB stuff can stand not being hard real time.

An alternative solution, if you don't need the USB response to be real-
time, is to get a board with three serial ports that are more clearly 
mapped to hardware, and use it as a MIDI peripheral.  Then just talk to 
it with your existing board via serial.  Serial comms is pretty easy to 
do, unless you make it complicated.

* Soft real time means that the OS almost always delivers real-time 
performance, and we're sorry that your pacemaker skips a beat once or 
twice a minute, Mr. Smith, but you _did_ buy the "cost effective" model.

-- 
My liberal friends think I'm a conservative kook.
My conservative friends think I'm a liberal kook.
Why am I not happy that they have found common ground?

Tim Wescott, Communications, Control, Circuits & Software
http://www.wescottdesign.com

On Wed, 02 Jan 2013 13:18:45 -0600, Tim Wescott wrote:

> On Tue, 01 Jan 2013 09:54:30 +0800, Bruce Varley wrote:
> 
>> I'm right at the end of my tether in trying to move some real time
>> stuff (MIDI) to Linux. The ARM-9 platform I've chosen, while very nice
>> in other ways, uses a proprietary FPGA interface for all the port
>> inputs, that makes it next to impossible to strip out the OS and
>> replace it with something else, or to go right back to CPU-side code
>> cutting (which is what I've always done in the past). My testing has
>> shown that the Linux platform is right on the limit in terms of speed,
>> and kernel interrupts could easily sink the whole show.
>> 
>> Has anyone got a suggestion for a combination of an ARM SBC platform
>> and a RTOS (preferably free or hobby-level cost) that I could adopt?
>> I've followed the many comments in this newsgroup and others for a
>> while, and also done a lot of browsing and struggling with selection
>> lists, but the supplier websites for ARM seem to be singularly hard to
>> get into unless you're a guru, which I'm not.
>> 
>> I need:
>> 
>> o  CPU clock 200MHz or higher.
>> 
>> o  2 serial ports, with access to the logic level lines on at least one
>> (LV OK).
>> 
>> o  USB support. Socket support also would  be nice, not essential.
>> 
>> o  Some sort of file system.
>> 
>> o  Guaranteed turnround of 10mS, even lower would be nice. My ARM Linux
>> won'd do better than 20.
>> 
>> I don't need:
>> 
>> o  ADCs or DACs or audio in/out.
>> 
>> o  Monitor/graphics output.
>> 
>> 
>> Suggestions that don't turn out will remain appreciated. Any ARM system
>> with RTOS will be a nice addition to my kit. We all have a few in our
>> bits box.
>> 
>> Or a website that would facilitate my search.
>> 
>> Any input would make my day.
> 
> Hey Bruce:
> 
> You may want to revisit the idea of using a real-time Linux variant.
> It's been a long time since I looked, but the approach that seemed to
> guarantee success if you need 100% real-time performance is the one that
> runs an RTOS underneath Linux, with Linux running in a task.
> 
> You put all the hard real time stuff under the control of the RTOS, and
> you put Linux at a lower priority, and then Linux pretty much stays out
> of the way of your real-time stuff.  The downside is that you end up
> programming under two operating systems.
> 
> Note that my information is at least five years old: at that time the
> "Real-Time Linux" community was divided between the "two-OS" approach
> and one that tried to make Linux into a hard RTOS with kernel
> extensions. I'm not sure if they ever succeeded in the "Linux as
> really-real time" or not.
> 
> Note, too, that you can't always trust either a vendor or a customer
> when they use the term "RTOS".  Even after decades of repetition,
> there's a lot of folks that don't understand the mantra "real fast
> doesn't mean real time" (or the corollary: "real slow doesn't rule out
> real time"). So a vendor (or a free software group) may say "RTOS", they
> may _think_ they're providing "RTOS", and in the end they may just be
> providing "real fast" or "soft real time*".
> 
> This may be a solution if you can't find a free USB host stack, and if
> your USB stuff can stand not being hard real time.
> 
> An alternative solution, if you don't need the USB response to be real-
> time, is to get a board with three serial ports that are more clearly
> mapped to hardware, and use it as a MIDI peripheral.  Then just talk to
> it with your existing board via serial.  Serial comms is pretty easy to
> do, unless you make it complicated.
> 
> * Soft real time means that the OS almost always delivers real-time
> performance, and we're sorry that your pacemaker skips a beat once or
> twice a minute, Mr. Smith, but you _did_ buy the "cost effective" model.

Another thought, if you really want to dive off the deep end, if you 
absolutely need real-time performance on that USB port, and if you can 
control what all gets plugged into it:

Things like USB host stacks are often huge and expensive because they 
have to work with _everything_ that might get attached to them.  If you 
want to become a freaking USB guru, you may find that writing a real-time 
host stack that _just_ talks to the _one_ device that you're going to 
hang on the thing is a lot easier (but still not at all trivial) than 
trying to write an entire compliant well-working USB stack.

But pay attention: I'm not entirely sure that USB itself is real-time.  
There are some protocols (TCP/IP, for instance) that are inherently non-
real-time.  If you USB is one of these then it doesn't matter what OS 
you're using: you are never going to achieve real-timeliness.

-- 
My liberal friends think I'm a conservative kook.
My conservative friends think I'm a liberal kook.
Why am I not happy that they have found common ground?

Tim Wescott, Communications, Control, Circuits & Software
http://www.wescottdesign.com

On Wed, 02 Jan 2013 13:24:06 -0600, Tim Wescott
<tim@seemywebsite.com> wrote:

><snip>
>Another thought, if you really want to dive off the deep end, if you 
>absolutely need real-time performance on that USB port, and if you can 
>control what all gets plugged into it:
>
>Things like USB host stacks are often huge and expensive because they 
>have to work with _everything_ that might get attached to them.  If you 
>want to become a freaking USB guru, you may find that writing a real-time 
>host stack that _just_ talks to the _one_ device that you're going to 
>hang on the thing is a lot easier (but still not at all trivial) than 
>trying to write an entire compliant well-working USB stack.
>
>But pay attention: I'm not entirely sure that USB itself is real-time.  
>There are some protocols (TCP/IP, for instance) that are inherently non-
>real-time.  If you USB is one of these then it doesn't matter what OS 
>you're using: you are never going to achieve real-timeliness.

I remember, that week I was reading through the USB 2.0 spec,
that there is supposed to be a 1ms queue/timer on the host
side that a slave device can expect to use. My recollection
is that you can't guarantee where, within the 1ms period
until the next one, your service lays. But you can, if I
recall right, expect some service in that 1ms window at some
point. [But I don't remember what happens when/if several
(and too many) such services that are queued for one
particular 1ms event happen to require long transfers and
might push some requests beyond the window.]

So, combined with a priori knowledge about competing devices,
it's possible that some USB service could be guaranteed each
1ms tick, but that the variability in when the service was
provided would also be about 1ms as well.

I haven't read a single word of the 3.0 spec. No idea there.

Jon

In article <l996e8dcrons0s9d6104r0t500fra0c0t2@4ax.com>, 
jonk@infinitefactors.org says...
> 
> On Tue, 01 Jan 2013 12:09:40 +0200, upsidedown@downunder.com
> wrote:
> 
> >On Tue, 1 Jan 2013 09:54:30 +0800, "Bruce Varley" <bv@NoSpam.com>
> >wrote:
> >
> >>I need:
> >>
> >>o  CPU clock 200MHz or higher.
> >>
> >>o  2 serial ports, with access to the logic level lines on at least one (LV 
> >>OK).
> >>
> >>o  USB support. Socket support also would  be nice, not essential.
> >>
> >>o  Some sort of file system.
> >>
> >>o  Guaranteed turnround of 10mS, even lower would be nice. My ARM Linux 
> >>won'd do better than 20.
> >
> >What Linux version and what scheduling policy are you using to get 20
> >ms ?
> >
> >If you need 100 % hard real time performance no general purpose OS
> >will do. If you can live with soft real time (99.9... % reliability),
> >general purpose OSes such as Windows/Linux can be used,
> 
> I pretty much agree with this. I write my own O/S and, not
> infrequently, use a 2 microsecond resolution process timer (I
> can switch tasks in 5 cycles -- 100 nanoseconds for a task
> switch on the ADSP-21xx I used it on -- with no variation in
> timing, guaranteed fixed phase delay.) But the code and the
> task switcher are designed together to work well. In that
> case, my shortest task-to-task delay was 20 microseconds. But
> I also had to control an external ADC at about 1.5Ms/s and
> the precision there had to be no more variation, sample to
> sample, than about 5 nanoseconds. That was achieved not with
> hardware, but with software running on it.
> 
> No file system, though. All queue insertions were done
> between process starts, so the time involved was hidden.
> 
> >It should be noted that in any priority based scheduling, only the
> >highest priority task response times (interrupts, rescheduling) can be
> >guarantied, unless you have full control of the execution time of that
> >high priority task(s).
> 
> That's also a sensible comment.
> 
> What I did was to carefully craft the processes, knowing
> their durations, and lay it all out on a timing diagram so
> that I could guarantee each of them their exact start times.
> The end times weren't quite as important, so long as I
> ensured they were done.
> 
> A delta queue design helps. The timer only sees the top
> process (all other processes are queued with 'delta' values
> relative to the processes ahead of them) and decrements that
> time value. When it drops to zero, the proecss is started.
> All remaining processes only have delta timers relative to
> that, so again the timer only needs to decrement the top
> timer value. Keeps 'variability' in timing to zero if you are
> careful (assembly) or near zero if it's in C.
> 
> The O/S I wrote allows me to include or exclude features at
> compile-time, too. I can enable or disable pre-emption,
> enable or disable priorities, enable or disable semaphores,
> and so on.
> 
> But I've never cared about including a file system for it --
> I don't need that on measurement instrumentation. What I do
> need is precision sampling and absolute guarantees on DAC or
> measurement outputs with FFT results you'd expect, so that an
> external device (boule puller) can have closed loop control
> with well designed control algorithms behaving as expected
> from the math.
> 
> 10ms turnaround would be... unacceptable.
> 
I'm a bit puzzled here.  I usually read '10ms'   as 10 milliseconds.
That seems like a lot of time for most embedded systems RTOS
variants, which have task switch times in the low microseconds
on chips like 160MHz  ARM-Cortex STM32s.

10milliseconds would certainly be too long a response time on
many of the instruments I've developed--none of which use
an RTOS.   I'm just now starting to play around with 
ChiBios and UCoS-II  on the STM32 chips.


Mark Borgerson

On Wed, 2 Jan 2013 12:52:47 -0800, Mark Borgerson
<mborgerson@comcast.net> wrote:

>In article <l996e8dcrons0s9d6104r0t500fra0c0t2@4ax.com>, 
>jonk@infinitefactors.org says...
>> 
>> On Tue, 01 Jan 2013 12:09:40 +0200, upsidedown@downunder.com
>> wrote:
>> 
>> >On Tue, 1 Jan 2013 09:54:30 +0800, "Bruce Varley" <bv@NoSpam.com>
>> >wrote:
>> >
>> >>I need:
>> >>
>> >>o  CPU clock 200MHz or higher.
>> >>
>> >>o  2 serial ports, with access to the logic level lines on at least one (LV 
>> >>OK).
>> >>
>> >>o  USB support. Socket support also would  be nice, not essential.
>> >>
>> >>o  Some sort of file system.
>> >>
>> >>o  Guaranteed turnround of 10mS, even lower would be nice. My ARM Linux 
>> >>won'd do better than 20.
>> >
>> >What Linux version and what scheduling policy are you using to get 20
>> >ms ?
>> >
>> >If you need 100 % hard real time performance no general purpose OS
>> >will do. If you can live with soft real time (99.9... % reliability),
>> >general purpose OSes such as Windows/Linux can be used,
>> 
>> I pretty much agree with this. I write my own O/S and, not
>> infrequently, use a 2 microsecond resolution process timer (I
>> can switch tasks in 5 cycles -- 100 nanoseconds for a task
>> switch on the ADSP-21xx I used it on -- with no variation in
>> timing, guaranteed fixed phase delay.) But the code and the
>> task switcher are designed together to work well. In that
>> case, my shortest task-to-task delay was 20 microseconds. But
>> I also had to control an external ADC at about 1.5Ms/s and
>> the precision there had to be no more variation, sample to
>> sample, than about 5 nanoseconds. That was achieved not with
>> hardware, but with software running on it.
>> 
>> No file system, though. All queue insertions were done
>> between process starts, so the time involved was hidden.
>> 
>> >It should be noted that in any priority based scheduling, only the
>> >highest priority task response times (interrupts, rescheduling) can be
>> >guarantied, unless you have full control of the execution time of that
>> >high priority task(s).
>> 
>> That's also a sensible comment.
>> 
>> What I did was to carefully craft the processes, knowing
>> their durations, and lay it all out on a timing diagram so
>> that I could guarantee each of them their exact start times.
>> The end times weren't quite as important, so long as I
>> ensured they were done.
>> 
>> A delta queue design helps. The timer only sees the top
>> process (all other processes are queued with 'delta' values
>> relative to the processes ahead of them) and decrements that
>> time value. When it drops to zero, the proecss is started.
>> All remaining processes only have delta timers relative to
>> that, so again the timer only needs to decrement the top
>> timer value. Keeps 'variability' in timing to zero if you are
>> careful (assembly) or near zero if it's in C.
>> 
>> The O/S I wrote allows me to include or exclude features at
>> compile-time, too. I can enable or disable pre-emption,
>> enable or disable priorities, enable or disable semaphores,
>> and so on.
>> 
>> But I've never cared about including a file system for it --
>> I don't need that on measurement instrumentation. What I do
>> need is precision sampling and absolute guarantees on DAC or
>> measurement outputs with FFT results you'd expect, so that an
>> external device (boule puller) can have closed loop control
>> with well designed control algorithms behaving as expected
>> from the math.
>> 
>> 10ms turnaround would be... unacceptable.
>> 
>I'm a bit puzzled here.  I usually read '10ms'   as 10 milliseconds.

As do I.

>That seems like a lot of time for most embedded systems RTOS
>variants, which have task switch times in the low microseconds
>on chips like 160MHz  ARM-Cortex STM32s.

I was using a 20ns cycle time ADSP-21xx processor (50MHz.)
It's a DSP with fixed cycle counts (1) for each instruction
and a guaranteed interrupt latency that NEVER varies (with
certain, inconsequential [to my application] conditions being
met.)

>10milliseconds would certainly be too long a response time on
>many of the instruments I've developed--none of which use
>an RTOS.   I'm just now starting to play around with 
>ChiBios and UCoS-II  on the STM32 chips.

In measurement instruments, which may be used in closed loop
control systems, predictability (both in terms of phase delay
relative to the sensor observation and also in terms of the
variability allowed in that phase delay) is vital.

I shoot for (and achieve where it is important) variability
that is measured as 0, or if forced in very small integers >0
like 1 or maybe 2, of cycle variation... measurement to
measurement... both in sampling the sensor as well as in
outputting it via a DAC. (I can't help what happens after.)
In the best of all cases, I implement the closed loop control
in the instrument, as well, so that there is no variability
caused by an external ADC and remaining system. In that case,
I drive the 0-100% control with similar attention to
precision control of the external device (heater, boule
puller, etc.) I also go to the trouble to ensure, where
branching code exists, that each branch takes exactly the
same number of cycles.

I very much dislike, in cases like this, devices with varying
interrupt latencies (which is almost guaranteed to happen if
the processor has instructions with varying execution time.)
I can control my code and the number of cycles each edge of
it may take, but the hardware latency is out of my control.
So I look for processors where it is predictable, if I need
that.

An STM32 would not qualify in the case I am thinking about.

Jon