| ??? 03/05/09 17:38 Read: times |
#163102 - it's a tradeoff Responding to: ???'s previous message |
David Prentice said:
Richard Erlacher said:
As for the "religious" issue ... I guess we'll have to agree to disagree. I can understand the desirability of using a small ARM-core single-chip microcomputer, but by its very central characteristics, it differs considerably from the classic microcontroller. Further, for its cost, ARM can't well compete with the performance of current-generation 805x one-clockers. That may change, of course, but I won't hold my breath.
RE Perhaps you would like to back up this statement with a current example single-clocker price. I would agree that future pricing may well change. I'm not the one to ask about IC prices, since most of the newer stuff I use is received in the form of samples. Erik has, on more than one occasion mentioned a price of about $6 for those 'F120-series parts he likes to buy from SiLabs. They're 100 MIPS one-clockers. That's about what one of my clients pays for his 33 MIPS MAXIM DS89C4x0-series one-clocker parts, in small quantity, though I've heard that, in large quantity, they approach half that amount. Keep in mind that these parts have plenty of on-chip resources and often require no external memory. As I've said, ARM's will become interesting when they can have all their code and data memory on-chip. Few MCU's do that with data memory, since most microcontroller tasks don't involve lots of data memory, yet, thanks to the trend toward HLL's, they have provided vast increases in on-chip code memory. In terms of execution speed, I would agree that 8 bit operations are comparable. It is also a bit of a pain splitting a 32 bit port, but for anything wider than 8 bits there is no contest. And this applies to common peripherals too.
Execution timing is seldom that critical except to delay an operation. In which case using the hardware peripheral timers is generally wiser than cycle wasting. Cycle-wasting is not what I mean when referring to precise timing. What I'm referring to in that context is writing code that "gets around the loop" in precisely the right amount of time. Sometimes that means writing long, straight-lined loops with bits of several processes built into it. It seldom involves timers and interrupts. It almost always requires the selection of precisely the right crystal frequency. Of course no one can argue about a single ASM instruction. But how many people are prepared to wade through pages of ASM that would be concisely put in a few HLL statements? I'd be interested in seeing "a few HLL statements" that replace "pages of ASM" and then examine the compiler output. Being unwilling to "wade through pages of ASM" is simply unwillingness to do the assigned job. Perhaps as an experiment, Richard could ask a colleague to read his documentation and code, and then ask him to maintain his project. I've been revisiting/updating/modifying 805x code I wrote in '79-'81 at about 10-year intervals. I can assure you I'd have lots of trouble doing that if the doc weren't complete and thorough, since few people at that plant remember much about the original installation. Colleagues have had no trouble doing the same thing. David. Clearly there are good reasons why one would want to use HLL in programming a control task, particularly if it's not demanding of speed or precise timing. However, as I've mentioned in the past, microcontrollers were developed as replacements for hardware. Consequently, I prefer to use them instead of peripheral hardware instead of with it. Nevertheless, some tasks demand external memory, external hardware, etc, and those impose additional precise requirements on the system designer. However, the ultimate decision is between buying "at least plenty" of performance, resources, and code, as opposed to "just the right amount." RE |
