PICS as L297 replacements

> The 16F84A does have Interrupt on RB0, interrupt on PortB change 7:4 and the
> normal Timer 0 interrupt and eeprom write completion interrupt. Haven't
> looked at the F84 data sheet though.

Momentary brain-fade. You're absolutely correct. ( Word of advice - never
get old ) Even the original has all of the above. It's the C54 that lacks
interrupts and that's the chip that I was originally using.

In the end, I did use the F84, to gain an extra input. But no interrupts,
though. I'm sure interrupts would be slower than simply polling, but more
to the point, in the case of a stepper driver, there's really no other
operation to interrupt. Unlike a DRO, for example, where the display update
or math calculations can easily be set aside for a bit, step generation pulses
really can't.

> I generally agree. But the Basic compilers for the PIC produce good code. So
> do some of the C
> compilers. I prefer the Bytecraft MPC compiler for day to day work with a
> PIC. I would only use
> the CCS PIC C for hobby work. Hi-Tech C compiler is good but I just haven't
> warmed up to it.
> I also use the Microchip 18C compiler for the 18CXXX series. I like it as
> well as the Bytecraft compiler.

In the case of the 18Cxxx products, I certainly agree with using a C compiler.
And for most all other projects, C or even Basic are fine.

But when things are ABSOLUTELY time critical and ABSOLUTELY cannot be
allowed to fail, I prefer to do it all myself, meaning assembly. And
with one glaring exception, I've generally found even C code to be not quite
as efficient as assembly.

The glaring exception was using an IBM OS/2 C compiler. At work one day,
someone posted some benchmark results run on a VAX and the C source used
to generate it. Within days, everyone had compiled it on their own machines
and posted the results. This represented about 10 different OSes and
even more flavours of compilers.

I decided to cheat. I had the OS/2 compiler turn on all optimizations,
then spit out an assembly listing as well. It was my intention to then
tweak the assembly. Only I couldn't .. there was not one single thing I
could do to make it run faster.

More than that, though, there was one EXTREMELY unusual instruction
sequence that I just didn't understand, until I realized that the compiler
was using an indirect address calculation instead of a multiply. It turns
out that for a narrow range of calculations, this "trick" ( that I had
never seen or heard of in 25 years of coding ) was significantly faster.

So not only could I not "optimize" the C code, my own would have been
slower.

> However, I'd say if you are starting out, go ahead and learn the Microchip
> version. Then if you do progress into bigger and better things and happen to
> get a Microchip ICE, you will already be used to writing in what you'll have
> to debug in. ( you can get the Tech Tools ICE though )

You CAN use PASMX code inside the Microchip stuff, it's just harder
to read.

> TI DSP chips have the
> single worst instruction set I've ever had to use. Now that stuff will make
> your head hurt!

Decided a long time ago that I couldn't be paid enough to program DSPs. I'm
a married man - I already have a source of torture, and one's enough.
Only ...

> A DSP chip however would be a better choice for a stepper controller than a
> PIC if you want to make a fancy controller. ( microstepping, acceleration
> curves etc ) I'm just not that ambitious though.

At one time, I said that I'd never need to do that, a stand alone stepper
controller. I'd always have a PC on the other end to do the math.

But right now, I'm struggling with exactly that, acceleration curves to
drive steppers in a standalone box - this one for my NC Shaper project.
I may have to haul out the TI books ! :(

Alan



--

Alan Rothenbush | The Spartans do not ask the number of the
Academic Computing Services | enemy, only where they are.
Simon Fraser University |
Burnaby, B.C., Canada | Agix of Sparta