Forums

How important is the time investment in a CPU architecture?

Started by Chris Carlen August 7, 2005
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
> 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.
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
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
An Schwob in the USA wrote:
> 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.