Looking for ARM system with RTOS

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.

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.

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 ?

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:

Then there's this:

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).

This is available in RTEMS.

20mS ? Ouch. :-(

Have a read through the RTEMS scheduling options in the online documentation.

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:

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

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).

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.

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

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

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

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

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

As do I.

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.)

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

Interesting. I would certainly hesitate a good long time before I made anyone any promises that depended on getting anything resembling real- time performance out of USB.

Yes, I know you can run audio through it -- but I'm not sure how _good_ of audio you can run through it, how much of the audio is working because it's really real time and how much is just deep FIFO's pasted over a bunch of problems, or how far away you can get from the optimized-for- audio software paths in the OS before things break down.

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

I don't know how much "realtime" isochronous transfers are, but here, they say that "Isochronous transfers are used to transfer data in real-time between host and device. When an isochronous endpoint is set up by the host, the host allocates a specific amount of bandwidth to the isochronous endpoint, and it regularly performs an IN- or OUT-transfer on that endpoint. For example, the host may OUT 1 KByte of data every 125 us to the device. Since a fixed and limited amount of bandwidth has been allocated, there is no time to resend data if anything goes wrong. The data has a CRC as normal, but if the receiving side detects an error there is no resend mechanism."

(LV

IIRC, the Cortex M4 instructions which would cause the greatest variation in interrupt latency (load and store multiple and divide) are, themselves, interruptible. I would guess that the interrupt latency variation would be on the order of 1 to 2 cycle times--- or about 12.5 nSec for a 168MHz clock. The overall latency is listed as 12 clock cycles or about 60-70nSec.

I can see that multiple-cycle instructions with variable execution time inside the interrupt handler could cause phase variations in the output. It might requirem more work to eliminate them than would be the case with a DSP having only a few rare cases to consider.

If you're using a DAC in the loop and want consistent phase delays, does that require a flash DAC? With a successive approximation DAC, the delay until you get the desired output would seem to depend on the value output unless there is a fast sample-and-hold between the DAC and the control system.

If you want outputs free of all phase jitter, a sample and hold triggered by a hardware clock could solve the problem. The problem then becomes what synchronization delays are acceptable.

Mark Borgerson

(LV

I gained some slightly useful benefits by having exactly 0 cycle variation in the application I'm talking about. One cycle (20ns in that application) of variation would have made a difference to me. The fact that I didn't have to add hardware to gain that tiny advantage ALSO was a useful benefit.

In the M4, there is also a pipeline and, if I remember, "faults" can occur not only in one stage. (I might be wrong about that.) You have to consider everything -- instruction faults (memory, etc.) But I admit I'm pretty ignorant of the M4, too.

I added the full closed loop control PID into the instrument. (It didn't have the ability beforehand.) In doing so, there was no DAC involved at that stage, anymore.

Price, size, power, etc., all mattered. Very competitive marketplace in that case.

Jon

successive approximation DAC ??

Yes, it's hard for me to understand too, particularly given that the kernel timer.c source code indicates that the base clock rate for the kernel is in the very low mS range (several build options that I can't decipher). But a standard interval timer set for 10mS or less repeat time delivers 20mS. The supplier apparently doesn't want to buy into timing issues, my queries aren't being answered. They've probably just given up, can't blame them.

Anyway, enough! I just want a system with heaps of CPU and timing headroom so I can implement my software knowing that capacity won't be a problem.

Ooops---got my DACs and ADCs mixed up. Even serial interface DACs generally have input latches so that there is a single step to the new output voltage.

It does occur to me that if there is any capacitive loading on the DAC output, the input to the next stage will have some variation in the time at which it settles at the final voltage. The variation will depend on the size of the DAC output step from the last voltage. I think controlling that phase delay will be as important as controlling jitter in the DAC output timing.

Mark Borgerson

one (LV

Linux

The 50Mhz ADSP-21061KSZ-200-ND is $101.43 qty 1 at Digikey. The

168Mhz STM32F407 is about $12. That seems pretty competitive to me ;-) How much work would it take to tune the STM32 and would you sell enough with an $80 lower price to be worth the effort.

I suspect the STM32 is lower in power at 168Mhz than the DSP at 50MHz, but I haven't verified that guess.

Mark Borgerson

Last century I made some timing accuracy tests on 167 or 333 MHz x86 platforms (using the TSC) and was able to reach less than +/- 1 ms jitter with 99.xx % reliability with standard Windows NT4. Of course, this was a headless (no mouse or keyboard) with carefully selected applications and hardware (drivers) and with multimedia timers enabled.

On standard Linux 2.4 kernels compiled with HZ=100 (10 ms clock interrupt rate), the performance was very bad compared to the NT4 case. Compiling the kernel with HZ=1000 (1 ms) and applying the RT and kernel pre-empt patches, both platforms performed in the similar way.

As far as I understand Linux 2.6 essentially contains the RT and pre-empt patches and when compiled with HZ=1000 or higher should give similar performance.

Running the system clock and hence timer interrupt services and thus rescheduling at say above 1000 Hz should not be a problem, since old PDP-11 machines with 1 us core memory time cycle times (1 MHz) used 50 Hz (20 ms) clock interrupt rates in RSX-11.

Thus your 20 ms latencies sounds very bad, even for a low resource processor.

The OP was talking about the ADSP-21xx fixed point DSP series. The ADSP-21XXX part you listed is floating point. 21XX and 21XXX are also both a bit long in the tooth.

For a better comparison look at something like the newer blackfin series, ADSP-BF592 @ 200MHz is ~$6 qty. 1 at digikey. TI also has some fixed point DSP 'controllers' that are similar.