Forums

Looking for ARM system with RTOS

Started by Bruce Varley December 31, 2012
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