RTOS interrupt latency and motor control

Hi,

I have to interface a WiFi card (most likely PCMCIA, probably USB too) onto a board that also has a motor controller. The embedded motor controller traditionally uses an 8-bit microcontroller. But some of the users' desires now ask for network connectivity to monitor the motor controller, so I figure, heck, i'll give them a WLAN option too.

I figure i can probably just add i2c or spi communication to the legacy controller, and it then talks via this serial communication to a network enabled board. Not too hard, since there's reference designs out there as well as plenty of app notes from just about every PIC,

8051, or Atmel site.

One other option i'm looking at is to use one 32 bit chip, probably an ARM, that already has a USB host and a MAC interface already integrated into it. However, I need to be able to count motor encoder interrupts that can have an arrival rate of 1ms.

I know that realtime embedded linux can only guarantee up to 15ms of determinism. I'm think that these other RTOSes, while they do guarantee determinism, cannot guarantee a 1 ms latency.

Is a 32-bit chip doing everything out of the question then? Am I then forced to offload the motor encoder counting to a small 8-bit micro?

Reply to
Mike V.
Loading thread data ...

There aren't too many processor/RTOS combinations around that wouldn't guarantee 100uS latency, let alone 1mS. That's very very slow in the embedded territory, and really the sort of thing you get with a full desktop OS like Winux or Lindows. You should be able to get an RTOS for the ARM if you really want it, and do the lot in it. Alternatively, something like the Z-World controllers using the Rabbit (though these are still pretty bloated, carrying around much software baggage that you won't need) might give you everything you want in a ready rolled package. If your client's paying for the extra work, he may not thank you too much for implementing a bunch of features he doesn't need.

Cheers,

-- Alf Katz snipped-for-privacy@remove.the.obvious.ieee.org

--
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
 Click to see the full signature
Reply to
Unbeliever

That's us (microseconds), not ms.

And of course it depends on the hardware architecture and processor clock. 15 us is average latency on a small 50 MHz embedded PowerPC; use a 400 MHz chip and divide numbers by 8 ...

15 milliseconds is a long, long time. Any RTOS that is worth the name will do that.

What makes you think the 8 bit micro might be faster than a high- speed 32 bit processor?

Best regards,

Wolfgang Denk

--
See us @ Embedded World, Nuremberg, Feb 17 - 19,  Hall 12.0 Booth 440
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88   Web: www.denx.de
 Click to see the full signature
Reply to
Wolfgang Denk

You are right, a 32 bits micro-processor with an RTOS is suitable for this job. Other postings pointed out that a 1ms interrupt latency should not be a problem. However, interrupt latency could be a misleading term. Do you measure the time from the external signal to the first instruction in the Interrupt Service Routine for that interrupt source? Do you account for the worst-case taking into account other interrupt sources and the maximum time the processor might spend with every external interrupt source disabledÉ

RTOSes are sometimes capable of excellent external event responsiveness if used appropriately. The challenge is to design the motor control software and to watch every other software in the system for their potential hidden contribution to the worst-case latency. This is where you are also right to assume that an 8-bit solution appears "faster": few other software components can adversely affect the worst case latency in an 8-bit motor control application.

The PPCMB/850 and the ABCD Proto-Kernel(tm) is a solution that fits your requirements. Sorry for the self-interest, but I think the following features list is relevant to your project design effort:

1) A mature 32-bits processor (Motorola MPC850) with integrated peripherals, including serial port, Ehternet support, and USB support. 2) An integrated interrupt controller that you can configure to get the motor encoder interrupt to be of highest priority in the system. 3) The ABCD Proto-Kernel(tm) that is designed precisely as a "hard real-time" or "deeply embedded" RTOS where worst-case interrrupt latency can be kept under control. Moreover, the application wakeup latency (the delay between the external event and the application software processing of this event) is managed with the ABCD Proto-Kernel(tm) default queuing mechanism. 4) For the motor control application from a 1ms encoder signal rate, the Interrupt Service Routine should record a precise timestamp of the interrupt occurrence, from which a near instantaneous speed estimate can be made (beware that this measurement tend to become unreliable at low speed because it becomes an average speed over a period that becomes too long -- this is from experience from a motor control project similar to yours). 5) The free software cross-compiler (GCC, GNU Compiler CColection ported to the PPCMB/850 ABCD Proto-Kernel(tm)), so that a Linux installation in your development environment (if not already done) spares you the shopping and spending for cross-development tools. 6) The PPCMB/850 SBC that lets you design quickly a prototype or low volume production model, with a well-defined migration path toqards a higher integration/lower unit cost solution.

In summary, items 1-4 are generic features that you would be looking for in any PowerPC(or ARM)-based design. Items 5-6 are the part of the solution packaging that CONNOTECH made with the hope to meet the expectations of embedded designs like yours.

Good luck with your project.

- Thierry Moreau

CONNOTECH Experts-conseils inc.

9130 Place de Montgolfier Montreal, Qc H2M 2A1

Tel.: (514)385-5691 Fax: (514)385-5900

web site:

formatting link
e-mail: snipped-for-privacy@connotech.com

Reply to
Thierry Moreau

A typical M$/Intel answer: Buy faster hardware :(

A HCS12 (though a 16bitter) with 24MHz outperforms an 32MHz ARM7TDMI and even an 50MHz PPC in many disciplines.

Many 8/16bit CPUs have less registers to save/restore, this gives them a better interrupt latency and better context switch timing.

--
42Bastian
Do not email to bastian42@yahoo.com, it's a spam-only account :-)
 Click to see the full signature
Reply to
42Bastian Schick

This sounds like a good fit for a Rabbit 3000 series processor. It has two on-bard hardware quadrature decoders, which should free the processor from ultra low latency interrupts by letting it do average speed calculations in the foreground. 1us arrival rate is really pushing most CPUs. What type of motor/motor control are we talking about here?

It also lincludes SPI and ethernet (in a core module.) You will need an external USB solution, but these are pertty easy to come by these days.

I have used many of the application layer internet modules included with the Rabbit development kit. I think you'll find it easy to build up you internet connectivity with them, they are pertty straight forward and easy to work with. My only gripe is that bastardized Dynamic C, but it is workable and the price is certinaly nice. Good luck!

-J

Reply to
Mood

It's a 1ms interarrival rate when running the motor application at the max speed that standards committees suggest for such an application, not microseconds. And it's a permanent magnet dc motor with hall effect interrupts from the encoder.

I'm looking into Rabbit micros as well as the 8051, ARM7, or a subsystem of PICs. I particularly am attracted to IOsoft's ready-to-go PIC solution with its PCMCIA driver in the 18F452. I like Maxim's 8051 too because of its integrated MAC (which I think is the only one of its kind when it comes to 8-bitters). And the ARM7 because i can get a usb host, integrated mac, and PWM all in one package (i think it's Atmel or TI that has this), and not to mention, i want to muck around with ARMs. It's just that i don't know much about ARM assembly language, so i'll go with an RTOS if i have to. Can't really go with Linux, despite it's available drivers for PCMCIA and USB, because its non-determinism can cost me a fried motor drive, (not to mention some broken bones :-( ).

Reply to
Mike V.

I don't doubt that a nicely clocked 32-bit processor is faster. It's just that offloading the motor driver control part to an 8-bit micro might be more efficient, as Thierry mentions, in terms of less latency, and its sole devotion to just watching out for motor encoder interrupts.

~~~~~~~~~~~~~~~~~~~~~~~

At the end of it all, I figure an subsystem of two to three 8-bit micros processing their own thing might be equal to, if not cheaper, a souped-up ARM7 microcontroller. It all depends on what i need in it and what they want in it i guess. Like I said, it's traditionally been enough to use a lower-end 8-bit micro in this application, but it calls for something like an ARM7 to carry it into next-generation data logging and monitorability over the net. The PowerPC 850 solution proposed will definitely work, but at $50 for a PPC850 chip, it's like trying to push a Cadillac among economy car shoppers.

Reply to
Mike V.

Looks to me like you've answered your own question. If there is already a legacy controller, and an existing user base, of whom only SOME want networks, then the solution is to add that as an option. Motor control is not a trivial design area, and it's the details that bite you. The most reliable encoder interfaces are in HW, and it's best to keep control SW in a local form where the code base is most stable, and easiest to test. Also if the encoder arrival rate is 1 millisecond, you need to be very carefull on averages vs peaks. viz - A direction change can generate a pulse of very narrow width, which you don't want to miss.

-jg

Reply to
Jim Granville

Okay, I got coufused by a previous post that said something about microseconds, but now I see that the poster was not you, and he wasn't talking about the arrival rate anyways. No posting before coffee for me!

Using a hardware system for counting shaft revolutions is typically good practice. I've heard stories of processors getting overrun with interrupts, because the shaft stopped in an intermediate postion, and the hall output toggled so fast that it overran the processor with interrupts. A hardware counter would just toggle up and down 1 step.

-J

Reply to
Mood

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.