Re: mega128 at 18.432 MHz

>
>It's great you can achieve such good speed and code efficieny 
>optimisations, there are however applications that just can't be squashed 
>so readily (don't ask for examples as I too don't have time to waste).

But you've got time to write test code to thoroughly test an overclocked 
micro, for things like pattern sensitivity and address range jumps, and to 
do these tests over a full voltage and environmental spread, then to debug 
the flaky problems that show up when the next production batch is slightly 
different?

>Feel free to continue operating below the limits.

I design real products for mass production. They have to work when they 
build them. All 10,000 of them (or millions.)

>Some of the newer AVR's have clock source switching so you can really slow 
>things right down when required which is great for power and EMI reduction.

Yes, and I use it.


>As a designer I often find there are requirements for extra features to be 
>added to firmware and the only responsible thing I can do is allow 
>headroom, my boss would be very unimpressed if I was to tell him I needed 
>to re-write a whole bunch of code in order to add a feature because there 
>wasn't enough instruction cycles available.

Sometimes, that's how it is.  I try to hit a compromise between small fast 
code, and easy to understand and maintain code, then start crushing it when 
the crunch comes. (Like today, when I just got some interesting 
requirements added to a project with 7 instructions free.  I'll fit it in.)

>Luckily we all have different approaches and design methodologies 
>otherwise we'd all be designing identical products!

True. Engineering is the art of compromise.
I just disagree about compromising the "do not exceed" limits.