Advice on uC selection wanted - driving microsteppers etc

I'd suggest researching the stepper motor side of things in more detail.

Classically the problem with steppers is winding inductance. To make them spin fast, you have to use a far higher than rated voltage to shove current through the winding inductance at high step rates. If allowed to remain in steady state, this would fry the windings or even demagnetize the rotor, so PWM current control chopping is implemented. You can get chips to do this - like the L297 & L298 pair for "printer-sized" stepper motors, but their max voltage isn't high enough for "hobby CNC machine tool" scale usage. A simpler option for small motors is to use a high voltage and a power resistor in series with the winding - wasteful, but it does work.

But if you only have small motors, you don't have to worry about that anyway. In that case, you have to decide if you get enough steps from the combination of using windings fully energized alone, combined with half steps where both windings are energized. If that's not enough, you'll need to drive fractional currents into the two windings to get finer positions. If intending to spin fast, you'd need to combine this with chopper current control to overcome inductance, but if spinning slow you can merely use a PWM algorithm without feedback to establish proportional currents in the two windings after the inductance has been overcome.

I'd suggest getting the motor and a bench supply and doing a little playing. For one thing, figure out exactly what you mean by steps compared to what the motor data plate does - how many cycles of (winding one up, winding two up, winding one down, winding two down) does it take to make a revolution? You can get twice that number by adding the both windings cases, before you get into needing proportional currents to go smaller.

Reply to
cs_posting
Loading thread data ...

formatting link

Well one possibility was to use the controller from another product that also has microsteppers. That has an M16C62 in it, which has insufficient RAM. Thats considered well underpower from a processing point of view. Last time I looked there was no C++ compiler either.

formatting link

I have not used the M32C but have used some H8s with varying degrees of happiness.

Peter

Reply to
Peter Dickerson

Is this using thumb or ARM code? Are you sure that wasn't the STR91xFW part, The FAW parts are supposed to have a much better branch target cache? In any case I can live with 48MHz.

16-bit timers with prescalers are fine. TIM0 and TIM1 can do DMA, which will reduce the 8000 interrupt/sec down to 2000+.

Peter

Reply to
Peter Dickerson

ARM code for the FA parts! But from the results, the FA is only 10% slower overall, with a wide variation depending on the test.

System (Compiler) Total Sieve Fib Sort Random LZ77 Dhry ============================================================================= LPC2106 60MHz (VFX) 5920 1090 1030 1010 920 1060

810 ST912FAW44 96MHz (VFX) 6419 1262 786 1014 874 1326 1157

Stephen

--
Stephen Pelc, stephenXXX@mpeforth.com
MicroProcessor Engineering Ltd - More Real, Less Time
 Click to see the full signature
Reply to
Stephen Pelc

Yes, I understand how to drive the steppers. They are 200-step, 0.6A, 7.5 ohm driven probably from 24V.

That's what microstepping means. In this case I need 1/8 stepping but in the past I've use ~1/256 with calibrated motors and analog drive.

The microsteppers need to run at 120 RPM max, which I consider very slow. They accelerate smoothly to avoid triggering resonances and slopping liquids about.

The both full on case leads to higher torque than the one winding energised case. As a result they pulsing vibration generated, so even in that case I'd want to use 70% drive.

Peter

Reply to
Peter Dickerson

I'm a bit puzzled by this. Isn't VFX a Forth compiler, in which case it not very relevent to me since I think I'd use gcc.

Peter

Reply to
Peter Dickerson

It's a Forth compiler, but it's also a *compiler*. And the numbers are relevant because you got numbers rather than hand-waving about the relative performance of LPC2xxx and STR9xx. The relative performances of these two parts will remain the same (mostly) regardless of the language and compiler used for the comparison.

As VFX shows, you can generate performant code from a wide range of languages.

Stephen

--
Stephen Pelc, stephenXXX@mpeforth.com
MicroProcessor Engineering Ltd - More Real, Less Time
 Click to see the full signature
Reply to
Stephen Pelc

Stephen, yes the information is useful because it tells me I should be careful not to assume more MHz means more speed or ARM9 faster than ARM7. I see a number of reasons why the STR might not be so fast as it first looks. The SRAM has one wait-state by default - not sure what that's about. The burst memory looks like it can deliver streamed 32-words at 96 MHz - I presume that bursts are pipelined because it (ref manual) talks about non-sequential access flushing the burst buffer. The prefetch queue and branch cache may well improve common branches but it won't help if there are a lot of constants accessed from Flash because they will break the streaming up but not be helped by the branch cache.

Peter

Reply to
Peter Dickerson

formatting link

Last

formatting link

The M32C and M16C support C++ through IAR. The M32C compiler for GCC als does C++, I think. Check

formatting link
for GCC compilers fo M16C/M32C. You can also ask quesiton here:
formatting link

The Renesas C compiler is supposed to have a release this year that add C++ support.

If you have an M16C/62 in another product, you might like the M32C - it i a pin compatible package for easy migration. And the peripherals ar backward compatible with the M16C peripheral drivers you have, an certainly do what you need: DMA, PWM, 16 bit timers, etc.

(please remember that most ARM C code uses RAM in a "wasteful" manne because of the 32 bit minimum data fetch. You may be able to use less RA in a CISC environment than an equivalent RISC system.)

--CG

Reply to
vinnie

It does.

Reply to
DJ Delorie

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.