Microcontroller choice for research project

 I'd be looking at something like PC/104 if your budget can handle it. Or
for that matter, why not a standard desktop with an ADC card? That way you
can have an Intel/PC architecture with all its benefits (no LOL please). For
state space you may require full floating point precision, a lot easier and
lower overhead when you have an FPP available. And there's unimaginably more
software around for that platform that for the smaller micros.

Once you have your algo in place and optimised, you can downsize later if
you need to for reproducibility reasons.

Goes without saying that dealing with your electrical environment will be a
significant challenge.

bruce varley wrote:

Unfortunately, price is a bit of a concern. How about this...Currently,
we've got a PC in the lab strictly to interface with our acquisition
card. Now, this is not a modern PC. The sensor I'm using is ultrasounic,
so the ADC card we've got samples at 30MHz. It's also and ISA card, so
we can't move it over to a new PC without a $5k adapter. So, with a PC
like this, it it worthwhile to try to run the computation on the PC? I
thought this might work, but am unsure if I can meet the 10Hz
requirement. What do you think? If I can do this, then I can use a
microcontroller to interface an enforce timing of the actuation.

Luckily, the welding environment is not too bad. As long as electronics
are in a nice metal case, I haven't had many problems.

Matthew Douglas Rogge wrote:

That PC has far more compute power than the HC11 (a processor dear to my
heart) It will have floating-point hardware and 32-bit words. Both are
painfully tedious to implement on an 8-bit micro. Design your system
using the PC as a development platform. The microcontroller system can
be designed when you have learned in detail what it needs to do. There
are very nice 16- and 32-bit microcontrollers available.

Jerry
--
Engineering is the art of making what you want from things you can get.
¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯

Jerry Avins wrote:

Sounds like a plan, if I do the computation on the PC, I can use an HC11
strictly as an interface box. The reason I'm a little fixated on using
an HC11 is that it is the processor used in the mechatronics class here
at school so future students in my lab could learn it fairly quickly by
taking the class.

I haven't done enough PC programming to determine the computational
power. It does make sense that a 32 bit machine with a fpp would be the
better choice.

Thanks to all that replied for the advice,

Matt

Matthew Douglas Rogge wrote:


Just two comments on this thread:

1.  A control algorithm would have to be pretty complex before you would
have trouble running it at 10Hz on an HC11.

2.  Use the PC anyway.  For any research problem like this you want to
concern yourself with the problem, not deficiencies in the solution
space.  As others have said, once you have the algorithm figured out
then you can figure out if the HC11 is sufficient, and how to shoehorn
your application into it.

--

Tim Wescott
Wescott Design Services
http://www.wescottdesign.com

Tim Wescott wrote:

   ...


   ...

We (Siemens) used an HC11 to implement a motor protection relay. Its
input is three current coils read by the ADC in either of two ranges.
That's 6 inputs. The other two read ground (so offset is known) and a
reference (so the scale can be corrected).

The program is a parameterized motor model that calculates winding
temperatures and shuts down the motor if they rise too high. Almost all
motors are transiently overloaded on startup. Excessive starting and
stopping with no load can injure a motor, while running at 125% of full
load for half an hour, then backing off to half load is perfectly fine
for most 300 HP motors. Our little box protects a motor without the need
to add temperature sensors to its guts and bring the leads out. The ROM
parameter tables accommodate about 25 common motor types and there's
room in flash for more. In its spare time, the '11 implements a small
PLC whose program is also in flash.

Flashback to another thread: I [invented | discovered | reinvented]
fraction saving to remove long-term drift from the calorie integrators.

Jerry
--
Engineering is the art of making what you want from things you can get.
¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯

On Wed, 01 Feb 2006 09:32:19 -0800, the renowned Tim Wescott


Maybe tightly coded in fixed-point math (which takes significant added
effort when you're fiddling with the algorithm). A floating point
divide or multiply can take 1-1.5 msec on an HC11 @ 8MHz. That's even
getting tight for simple PID if you add on the usual saturation,
scaling, calibration and linearization type stuff. I usually aim for
no more than 50% bandwidth devoted to the control algorithm for a
periodically triggered algorithm, so 50msec only is available. I think
a state-space controller wot with all that matrix math will easily
cause the poor little micro to choke.


--
"it's the network..."                          "The Journey is the reward"
speff@interlog.com             Info for manufacturers: http://www.trexon.com
Embedded software/hardware/analog  Info for designers:  http://www.speff.com

Spehro Pefhany wrote:

   ...


   ...

I found that the greatest boon conferred by floating point is freedom
from having to understand the problem space in detail. In my admittedly
limited experience, I haven't run across a physical quantity that needed
to be expressed with more than 12 bits or calculated with more than 24.
Adding two guard bits on each end brings the number up to 16. The
difficulty with fixed-point programming is needing to understand the
problem well enough to remain within that confine, and devising
algorithms and arithmetic procedures that won't force the solution
outside it. Floating point removes the need for tedious or nail-biting
analysis.

Jerry
--
Engineering is the art of making what you want from things you can get.
¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯

On Wed, 01 Feb 2006 16:21:31 -0500, the renowned Jerry Avins


Of course there's no limit to how big the difference is between the
number of bits you need for calculation and the number of bits
required for the physical quantity. A poorly conditioned matrix can
easily require 32 bit calculations to get 10 or 12 bit answers. Fixed
point math seems to come up similar in the number of total bits, as
you use the lower resolution more efficiently with floating point (the
bits grabbed for the exponent mean less available for the mantissa).


It's still possible to get into trouble, but it makes it less of a
worry.

It might be easier now with some of the new $$$ tools available to
develop complex fixed point algorithms, but you're still developing
and testing the algorithm on a PC (to make sure you don't overflow or
saturate on the intermediate results, for one thing) then porting it
to the micro. Why not cut out the middleman while you're testing?


Best regards,
Spehro Pefhany
--
"it's the network..."                          "The Journey is the reward"
speff@interlog.com             Info for manufacturers: http://www.trexon.com
Embedded software/hardware/analog  Info for designers:  http://www.speff.com

Spehro Pefhany wrote:

                                              Oh. wow!


   ...


Devising appropriate algorithms and arithmetic is both the difficulty
and the solution.


/It's always possible to get into trouble!/


I cut out the middle two ways. I develop on the PC, and also on the
micro itself via an umbilical connection. The New Micros boards make
that easy in Forth and C. That way I can know if an algorithm isn't
practical on the micro, and not refine it on the PC.

Floating point is not always suitable. Gerber plotters serial numbers 1
and 2 had lead screws with .8" pitch and stepper motors with 800 steps
per turn. The plotting surface was some 60" square; 60,000 steps.

We wrote a Fortran program to draw circles and arcs, to scale patterns,
and to rotate them. The mainframe punched a tape in APT which went into
the Gerber reader. The Fortran floating point version worked perfectly
when written; our mainframe actually did decimal arithmetic. We found
closure errors when it was replaced by a binary machine. In the end, we
found only one fix. We rewrote the program using integers instead of
floats. The trig got dicey, and it turned out that there is more to
scaling than we had naively imagined, but in the end it all worked. On
the mainframes of that day, it even ran faster. The program was aptly
called AdApt.

Jerry
--
Engineering is the art of making what you want from things you can get.
¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯

Spehro Pefhany wrote:


I disagree.  I find that a well scaled problem with 16-bit input data
will often have precision problems on a floating point integrator (with
25 bits of good data in the mantissa) yet will do just dandy in a 32-bit
fixed-point integer.

The key here is 'well scaled', but if you pay attention you should know
the ranges for all the variables in your system, and you should dig into
any that may be on the edge.

Of course if you try to do this with integer arithmetic then you'll
waste bits -- I've always gravitated toward fractional math because it
seems to do what I need.

Scilab is nice, at $0.00.


--

Tim Wescott
Wescott Design Services
http://www.wescottdesign.com

Spehro Pefhany wrote:

I almost always use fixed-point math; whenever I end up implementing
control stuff on a micro I just code up a fractional-arithmetic
fixed-point library.  I haven't tried this from C in an 8-bit processor
but I usually see significant speedup over floating point.  The only
places I haven't seen this were on Pentiums and on the '28xx chips from
TI -- and in the case of the '28xx we ended up doing all the controllers
as state-space with a generic block floating point arithmetic routine in
assembly and C++ code to load the constants.

The last time I wrote control code in a 68HC11 it was a PI that sampled
at 400Hz.  It used a 24-bit accumulator in the integrator, 16-bit
precision arithmetic in the main data path, 8-bits of precision on all
of the coefficients, and it was all coded in assembly.

--

Tim Wescott
Wescott Design Services
http://www.wescottdesign.com

Matthew Douglas Rogge wrote:

   ...


The HC11 had big cousins with similar architecture and more resources.
Look at the HC12 and HC16 if you want to keep matters in the family.

New Micros Inc. <http://www.newmicros.com/>  makes some rather
inexpensive development boards for these and other processors. I like to
program in Forth, but they also support C and assembly.


C or Forth on a 333 MHz PC runs rings around a 68HC11 programmed in
efficient assembly.


--
Engineering is the art of making what you want from things you can get.
¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯

On Wed, 01 Feb 2006 00:36:59 -0500, the renowned Matthew Douglas Rogge


Forget it, an HC11 isn't fast enough for your application. An ARM7 or
9 would more than likely be, but a PC would probably be a better
development platform (you'd end up using a PC anyway to do the
cross-compilation, so running the control software on the PC cuts out
the middleman). You can always port the application to skinned-down
hardware if it needs to be produced for sale.

Wrt your other comment about needing an ISA slot, you can easily get a
relatively modern PC motherboard with a single ISA slot for < $100
that supports a PIII 1.2GHz processor. That's probably 5000 times the
processor your HC11 is, making reasonable assumptions about data
types.


Best regards,
Spehro Pefhany
--
"it's the network..."                          "The Journey is the reward"
speff@interlog.com             Info for manufacturers: http://www.trexon.com
Embedded software/hardware/analog  Info for designers:  http://www.speff.com