Advice on uC selection wanted - driving microsteppers etc

Well the big questions you have to ask are if you are trying to implement micro-stepping and/or chopper-type current control in software, to directly drive the H-bridge, or if you are feeding step & direction to a driver module that does all of that for you. And incidentally, if you are doing it in software you need analog input or at least threshold comparators to monitor the current sense resistors.

If you are doing PWM microstepping and/or current control, your real time demands are going to be drastically higher than if you are feeding step and direction. (Though do watch for for microstepping modules which may require extremely high pulse rates to create enough of the tiny steps to spin at a meaningful rate).

A good idea for such projects is to a) First make it work. Then b) make it cheaper. So, start with a "micro-stepper special", to get it operating, and then when the spec's have stopped moving-about, look to cost-down that section. You may decide to use a a second micro for that task. Look about for low cost eval modules for step a).

-jg

For low volumes, it may be cost effective to buy a motor with integrated controller. For a recent project, I've used some motors from these guys:

The motors are controlled through a serial interface, and they run very smoothly. Multiple motors can be daisy chained, such that their motions can be coordinated.

I wasn't too impressed with the command line interface, though.

I need to do 1/8 stepping. I am happy to use driver chips for the purpose but if the suggested uController is up to the task of triving a plain H-bridge and monitoring the currents, and there are app notes on how to do this then I can do it that way. Timescales are tight and this project has failed once already so any solution needs to sure-fire. We know we can do it with microstepper specific driver chips that just need direction and step pulses. An intermediate solution where the current control is done in an analog control loop controlled by DACs or PWM from the micro isn't really a goer - too many bits and cost saving isn't the here. If the project gets canned then probably the whole department will too because current products are profitable.

Spinning isn't the point, accurate positioning is and smooth movement. This design only needs 1/8 stepping but a previous project has 1/500 degree usteps with backlash compensation etc.

I'll have a look at that but we have working mechanics and a choice of several motors. We have driven usteppers before. I'm looking for advice on the microcontroller that I can trust to do the job of control and data acquisition. The volumes are very small, perhaps only 1000/year but there are two usteppers per machine. Price is no object, which means a few tens of $ rather then a few $.

Peter

ap

ot

'm

nd

ve

py

Steppers look easy to drive but there not if you want more than 30% of the motors specs. So thats your first question to answer. Assuming 30 % is enough for you use a small micro for each motor, there are several that have H bridge driver periferals built in, they are made for the motor inverter market. You would only need a very simple program to recieve instructions from your main controller (arm or whatever) to move the motor.

I am impressed by the versatility of the peripherals on the TI 28xx DSP chips. If they have any of their ARM parts equipped with their PWM drives it may be useful looking into them.

I'm about to design some Luminary Micro parts into a product that I'm making, but Luminary Micro has a number of strikes against it (they're new, they're small, they may not last long) that don't matter for what I'm doing but may matter a great deal to you. These are also ARM parts with (what appears to be, at least) a rich selection of peripheral functions.

This bring up a point that I hadn't addressed. The product life is very long by today's standards. We're still making stuff with source code copyright dated 1994. That stuff had to be ported to new hardware ~2000 due to difficulty getting parts and was considered a distressing outcome. In the case of this project I suspect that once it has been proven to work and there is income then there will be pressure to cost reduce by changes to mechanics and eletronics. But doing my job properly I'd like to feel happy that parts will be available >5 yrs from now.

Thanks for your help.

Peter

Would there be objections to the purchase and stocking of critical components intended to last the full production and maintenance cycles of this device?

Michael

One this is for sure, there will be plenty of Cortex-M3 parts around in 5 years time, be they from LMI or not. Porting software from one CM3 part to another should in theory be a simple task (a theory that in my case was proven true). The core will be the same, the tools will be the same, and in some cases the peripherals will be the same (and use the same memory map). This does not help the hardware guys of course if swapping parts results in a different footprint, but I would not be worried about it from a software view point.

Hello,

Have you looked into using a stepper motor driver chip with your MCU?

Look up a stepper motor driver chip made by a company called Allegro on digikey.

They make drivers for both bipolar and unipolar steppers. Their chips can provide resolutions per turn higher than what is rated on the stepper motor by creating 'microsteps' between each step. Changing a bit will forward/reverse direction on the motor. Look for the appropriate chip to drive the load you intend to use.

This is just a suggestion.

Look for a manufacturer who has a track record of not obsoleting parts for a long long time, and try to find new parts from an established line, or parts that have been around for just a few years and still seem to be on the manufacturer's 'A' list.

I _think_ that TI is good about taking its sweet time to obsolete parts

-- it wouldn't be a bad thing to ask here and on sci.electronics.design about which manufacturers are good about this.

Generally, yes, there is liitle likelyhood of continuing a project that require production to have a lot of money tied up in stock. Just the cost of the floor space would be considered prohibitive. Mostly Buying use the JTL system - its a bit like JIT but with added delays.

The factory is already expanding to handle products pulled in from a closed down subsiduary. They (the powers that ought not to be) are deciding which current and in-development projects to keep. The project of which I speak is in the in-dev catagory.

Peter

Micros are almost always chosen on peripheral functions and memory grounds. So things are very straight forward but some things turn out to be very painful to port because of dependence on detailed behavour of timers, ADCs etc.

The boss has the view that redesigning the board is tantamount to failure. Pretty much the first prototype is what ends up in production give-or-take some incompetence, of which we have excess.

From my point of view a Cortex-M3 isn't an ARM in the sense that it doesn't run ARM code, just a Thumb2 subset. That isn't a big problem in itself, since I'm not tied to ARM.

Peter

I've actually been around a long time. Ok, some here whould call me a newcomer because I started electronics for a living in 1979. I am asking for advice on uC selection and product lifetime and supplier history are certainly part of the mix. We use TI on the analog side via Burr-Brown but haven' bought micros from them in some time.

Thanks for the help, Peter

Granted, but the same compiler can be made to spit out ARM, THUMB or THUMB2 code just by changing the compiler options. The M3 is designed (again in theory) so that you do not need to revert to asm code even to do the C startup, or write interrupts. Therefore what your C gets compiled into should hopefully be transparent.

OK, I'll follow up on myself. I am now looking at the STR911FAW42X6 (or even STR912FAW44X6) from ST. It has 96K RAM and 256K+32K Flash (or 512K+32K). Thats more than I budgeted for and at 96 MHz is about twice the speed I need. It looks like it uses quite a lot of power but thats not a real problem for me (about 50W used by lamps so a few hundred mW isn't a problem). The timers look like they can be updated by DMA so I might even be able to accelerate the motors with only DMA intevention.

So, now the key question. Anybody had experience of this part god or bad?

Peter

In use, these parts are slower than a 60Mz LPC2xxx. Our benchmarks indicate by about 15-20%, very much dependent on the code. They race through straight-line code, but the branch logic is awful.

The 96k RAM is wonderful, especially with Ethernet. We get excellent throughput on our PowerNet TCP/IP stack.

The peripherals are the usual weird ST mix, and many of them have 16 bit registers/counters rather than 32 bit ones. If they fit your requirements, it could be a good choice.

Stephen

sorts

have

of

this

do

can

long

or

that

trouble.

compatible

up

discover

if

that

to

even

I'd suggest looking at Renesas for a company with a great track record fo EOLed silicon. A lot of other chip makers seem to be going in and out o the hands of venture capitalists, so long-term support for silicon may b in question at other top-tier suppliers.

You'll probably want t achip with lots of PWM and DMA to off-load th motor control processing. I've seen microstepping done with very old 8 bi controllers - and it was done well. But you need the right peripherals.

The M16C/M32C series offers a lot of options that I think you'd like: 15 independent 16 bit PWM channels; lots of timers; very flexible vectore interrupt control built into the core (not a peripheral); and many DM channels you can allocate. Check out the M32C/87 chip here:

Another option that includes the USB device function is the H8S serie (from Hitachi lineage). The H8S/2215R has a USB device peripheral, multipl PWM channels (using the 8 and 16 bit timers); and DMA. But perhaps the bes thing is the Data Transfer Controller which would let you set up "channels to feed PWM values to the timers (like DMA).

If you are familiar with using GCC compilers, you'll have no troubl moving to an H8 or M32C based on your ARM7 experience - and the effor might even be less than moving to an ARM from ST.

--CG