1. Home
  2. Embedded Programming
  3. How important is the time investment in a CPU architecture?

How important is the time investment in a CPU architecture?

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 to
Chris Carlen
Loading thread data ...

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 to
larwe

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 to
Chris Carlen

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:

Reply to
An Schwob in the USA

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 to
Chris Carlen

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.