> Chris,
>
> your requirements seem to ask for a wide variety of devices based on
> the same architecture. The fastest growing architecture with excellent
> development tools support is probably ARM. Code can easily be ported
> from an ARM7 to an ARM9 or in the future to an ARM11. This covers an
> extremly wide area of performance and available devices.
> In regards to your selection AVR, this is a very good 8-bit
> architecture, sometimes the same function on the higher end AVRs are
> more expensive than on an ARM7 though!
> ARM7 can not compete with your DSP selection but may be ARM9 can
> compete with a 100-150 MHz fixpoint DSP.
> My point being, you might get along with one architecture if you use
> ARM.
>
> Schwob
Thanks for the input.
I have considered ARM at times as a high-end uC where AVR wouldn't be
enough.
I went with the TI DSP because of a desire to ultimately move toward the
DSP field specifically, as well as the fact that it is a relatively
simple processor to approach despite being about to reach very high
processing performance levels. Also, familiarity with the TI tools
extends from the C2000 series up to the floating point C6000 family,
when I get to that.
Similar processing speeds to the C2000 in ARM architectures involve
capabilities that I just didn't find necessary at this point, such as
DMA controllers and MMUs. And I wasn't aware of ARMs with built in
flash program memory and data RAM at the time I was looking, which makes
it possible to build small systems which do useful things basically with
one chip. This is something I can do with an F2810 if desired.
I am keeping ARM on my radar screen though.
Good day!
--
_______________________________________________________________________
Christopher R. Carlen
Principal Laser/Optical Technologist
Sandia National Laboratories CA USA
crcarleRemoveThis@BOGUSsandia.gov
NOTE, delete texts: "RemoveThis" and "BOGUS" from email address to reply.
Reply by An Schwob in the USA●August 9, 20052005-08-09
Chris,
your requirements seem to ask for a wide variety of devices based on
the same architecture. The fastest growing architecture with excellent
development tools support is probably ARM. Code can easily be ported
from an ARM7 to an ARM9 or in the future to an ARM11. This covers an
extremly wide area of performance and available devices.
In regards to your selection AVR, this is a very good 8-bit
architecture, sometimes the same function on the higher end AVRs are
more expensive than on an ARM7 though!
ARM7 can not compete with your DSP selection but may be ARM9 can
compete with a 100-150 MHz fixpoint DSP.
My point being, you might get along with one architecture if you use
ARM.
Schwob
Chris Carlen wrote:
> Greetings:
>
> Since I work in a research lab environment with a very wide range of
> responsibilities, I've decided to try to standardize as much as possible
> on a minimum number of microcontroller platforms for embedded
> control/processing applications.
>
> The ones I have chosen are the Atmel AVR for smaller stuff, and the
> TMS320F281x DSP/microcontrollers from TI for applications requiring very
> fast processing speed. (Our work has not yet demanded the ultra
> high-end processing of the best floating point DSPs, though )
>
> Because of the research environment, two factors are present. One is
> that cost is of little importance. If I need a fast processor, a $25
> part is no more expensive than a $12 part. So if I know the $25 part,
> but would have to learn a new architecture and development tool suite to
> use the $12 part, then I stick with the $25 part.
>
> The other factor is, as I mentioned, that I have a very wide range of
> duties. I have many years invested in learning the subtle tricks
> involved in aligning complex high-power pulsed YAG laser systems with
> dye and optical parametric oscillators. So I am our department's laser
> technologist as well as electronics technologist.
>
> I have to design analog, power, digital, and microcontroller applications.
>
> Programming micros actually occupies a small proportion of my time,
> perhaps only 5-10%. So since I don't do embedded programming most of
> the time like a dedicated software programmer, I consider the investment
> in time to learn an architecture and it's tools much more "expensive"
> than the parts themselves, and would prefer to engage that process as
> infrequently as possible.
>
> In a case like this, I think it's a sensible choice to standardize on a
> small set of architectures. It's not that I *can't* learn any others.
> It's just that it is more expensive to spend the time to do so than to
> throw an oversized part at a task. This also has a benefit that is easy
> to afford in a one-off situation that isn't as possible to afford in a
> volume production environment, which is that I can design in substantial
> headroom of processing power.
>
> I do realize of course that it is not possible to strictly adhere to
> such plans to keep to a minimum of architectures, as we have just
> deployed a C6713 platform from Innovative Integration in a multi-channel
> high-speed PID motion controller project. But I didn't get to program
> that one since I was needed to design the motor drive amplifiers.
>
> Just wondering how other folks' thought processes work in this regard,
> particularly consultants and research lab engineers who build mostly
> unique, small volume systems.
>
> Thanks for comments.
>
>
> Good day!
>
>
>
> --
> _____________________
> Christopher R. Carlen
> crobc@bogus-remove-me.sbcglobal.net
> SuSE 9.1 Linux 2.6.5
Reply by Chris Carlen●August 7, 20052005-08-07
larwe@larwe.com wrote:
>>Just wondering how other folks' thought processes work in this regard,
>>particularly consultants and research lab engineers who build mostly
>>unique, small volume systems.
>
> It depends on other constraints besides BOM cost and time to learn the
> tools. For example, power requirements. If you're engineering something
> that has to operate for a guaranteed minimum time interval off a
> specified battery, you probably can't simply choose any old micro. IOW,
> having experience with more than "one big + one small" micro family can
> be the difference between telling a customer that his project is
> feasible vs. telling him to take his money elsewhere.
>
> Apart from this caveat, I'd generally agree with your comments, though.
Ah yes, of course for special requirements like low-power then that
forces one to choose a power-optimized uC family, and may also require
careful software design and minimization of the capability of the device
chosen to only what is absolutely needed.
I would probably not turn up a job because it demanded using a different
CPU than my preferred set. Unless I was already very busy, of course.
Thanks for the input!
--
_____________________
Christopher R. Carlen
crobc@bogus-remove-me.sbcglobal.net
SuSE 9.1 Linux 2.6.5
Reply by ●August 7, 20052005-08-07
> Just wondering how other folks' thought processes work in this regard,
> particularly consultants and research lab engineers who build mostly
> unique, small volume systems.
It depends on other constraints besides BOM cost and time to learn the
tools. For example, power requirements. If you're engineering something
that has to operate for a guaranteed minimum time interval off a
specified battery, you probably can't simply choose any old micro. IOW,
having experience with more than "one big + one small" micro family can
be the difference between telling a customer that his project is
feasible vs. telling him to take his money elsewhere.
Apart from this caveat, I'd generally agree with your comments, though.
Reply by Chris Carlen●August 7, 20052005-08-07
Greetings:
Since I work in a research lab environment with a very wide range of
responsibilities, I've decided to try to standardize as much as possible
on a minimum number of microcontroller platforms for embedded
control/processing applications.
The ones I have chosen are the Atmel AVR for smaller stuff, and the
TMS320F281x DSP/microcontrollers from TI for applications requiring very
fast processing speed. (Our work has not yet demanded the ultra
high-end processing of the best floating point DSPs, though )
Because of the research environment, two factors are present. One is
that cost is of little importance. If I need a fast processor, a $25
part is no more expensive than a $12 part. So if I know the $25 part,
but would have to learn a new architecture and development tool suite to
use the $12 part, then I stick with the $25 part.
The other factor is, as I mentioned, that I have a very wide range of
duties. I have many years invested in learning the subtle tricks
involved in aligning complex high-power pulsed YAG laser systems with
dye and optical parametric oscillators. So I am our department's laser
technologist as well as electronics technologist.
I have to design analog, power, digital, and microcontroller applications.
Programming micros actually occupies a small proportion of my time,
perhaps only 5-10%. So since I don't do embedded programming most of
the time like a dedicated software programmer, I consider the investment
in time to learn an architecture and it's tools much more "expensive"
than the parts themselves, and would prefer to engage that process as
infrequently as possible.
In a case like this, I think it's a sensible choice to standardize on a
small set of architectures. It's not that I *can't* learn any others.
It's just that it is more expensive to spend the time to do so than to
throw an oversized part at a task. This also has a benefit that is easy
to afford in a one-off situation that isn't as possible to afford in a
volume production environment, which is that I can design in substantial
headroom of processing power.
I do realize of course that it is not possible to strictly adhere to
such plans to keep to a minimum of architectures, as we have just
deployed a C6713 platform from Innovative Integration in a multi-channel
high-speed PID motion controller project. But I didn't get to program
that one since I was needed to design the motor drive amplifiers.
Just wondering how other folks' thought processes work in this regard,
particularly consultants and research lab engineers who build mostly
unique, small volume systems.
Thanks for comments.
Good day!
--
_____________________
Christopher R. Carlen
crobc@bogus-remove-me.sbcglobal.net
SuSE 9.1 Linux 2.6.5