So does the Blink sketch run properly after reset with the FTDI removed?

I have not encountered this problem, although I've used Optiboot in many projects and I usually leave the RX/TX pins free to permit uploading new code.  Which version of Optiboot are you using?  Does this problem occur with the "blink" sketch?  Does it occur after a power-on reset?  Does it also occur after briefly grounding the reset pin?  Does it still occur if you ground Pin 0 before resetting?  After a reset does an LED on pin-13 blink 3-times?

A sharp photo of your setup would be helpful.

That's what I've done now, but I'm curious: what was the bug?

Be careful with the terminology:  An oscillator is a circuit which generates the clock signal required by the CPU.  A crystal is just one part of one type of oscillator circuit.

There are two types of oscillator built into the ATtiny85:

• One type uses an on-chip resistor and capacitor to generate an 8MHz clock[1].  It needs no external components, but it is not very accurate.
• The second type requires an external crystal[2] plus two capacitors.  The external components take up space and cost, but the resulting clock is very accurate.  You can also choose any frequency, within certain limits[3].

It's also possible to use the clock signal from an external oscillator, but note that this is not the same as using an external crystal.

Normally the software runs faster or slower in proportion to the clock frequency.  However the Arduino software is clever enough to take the CPU clock into account, so delay(1000); always produces a one-second delay.  It also tries to ensure that Serial.begin(9600) always produces serial data at 9600 bits per second.

What the Arduino software can't do is account for an inaccurate clock.  The simplest thing to do is to use an external crystal, as these are manufactured to a high accuracy.  Alternatively you can tune the frequency of the internal oscillator, by adjusting the value stored in the OSCCAL register (check the datasheet for more details).

-------
note [1]: There is also a 128kHz clock, but most people will find this too slow.
note [2]: Instead of a crystal a ceramic resonator may be used.  It is slightly less accurate, but cheaper and doesn't need the extra capacitors.
note [3]: 0.4 - 20MHz for the ATtiny85, although crystals are only available with certain frequencies in this range.  Below 5V the maximum clock frequency is less than 20MHz.

It looks like the internal oscillator is just under 5% too-fast in that example, although the internal oscillator can be up to 10% off.  5% is pretty much the limit for reliable serial communication.  I think you'd need to either set the clock calibration register, or program the baud-rate generator specially to compensate.

Nice job.  Did you use solder paste and an oven for the surface-mount components?

Can you give us a hint as to what you're doing?  At least a schematic or a sharp photo of your setup, and a link to the code.

[-p at90usb162]

Hi Tumbleweed,
I've been programming 8U2s (without patching the conf file) as follows:

Code:

avrdude -p at90usb82 -P com4 -b 19200 -c stk500v1 -v -F -e -u ^
  -U efuse:w:0xF4:m -U hfuse:w:0xDF:m -U lfuse:w:0xFF:m ^
  -U flash:w:Arduino-usbisp.hex ^
  -U lock:w:0x2b:m

Maybe you could try something similar, substituting -p at90usb162 for -p at90usb82?

ISP upload will indeed flatten the bootloader.  When writing to flash by ISP, the programmer first erases the entire chip before uploading the new data.  This differs from self-programming mode used by the bootloader, where the flash is erased one page at a time.

If you want to go back to using serial upload you'll need to reinstate the bootloader first.

PS. it's possible to combine the sketch and bootloader and upload both together, but AFAIK the Arduino IDE doesn't do that.

For sure clock-skew could become problematic for high-speed I/O, even for serial data transfer.  OTOH the I/O doesn't necessarily have to run at the same rate as the CPU, and in fact usually doesn't.  Even on the ATmegas the interfaces are usually run far below 20MHz.  The benefit of a faster CPU is lower latency, which is especially useful when multitasking or doing something slow like floating-point maths.

In the case of the ATmegas it's clear that the clock is limited by the electrical properties of CPU and not by any external considerations.  If high clock-rates are problematic in any particular application the user is free to slow things down to his or her taste.  And at the same time any user who needs to use the highest speeds can do so - on condition that he/she deals with the consequences that brings.

The foils on spacecraft are for thermal insulation.  Since there's no air they only have to combat radiative-heating or cooling, and the best way to do this is with multiple layers of something light and reflective.  Metalised mylar or polyimidie is commonly used.  The same stuff is used to insulate ultra-low temperature cryostats.

The foils do nothing to shield against the high-energy radiation which can disturb electronics (and astronauts).

After a little more digging, I think Chagrin may be closest to the mark with his comment about fabrication processes.

Atmel's fastest processors do in fact have on-board ADCs, but what they don't have is PicoPower and high-voltage tolerance.  Both of these features would require thick oxide layers, which in turn requires larger and slower transistors.  Layer-thicknesses cannot easily be varied across a single chip, so if one part requires thick insulators (the IO ports, for example) the rest of the chip is condemned to use the same technology.

That would also explain why ATmegas need 5V to reach their maximum clock rate, whilst other designs can manage with 3.6V or 1.8V.  As Tom mentioned there are faster 8-bit processors, and significantly these chips also require lower supply voltages.

James, you misunderstand me.  This is a purely technical question motivated by curiosity about the inner workings of microprocessors.  I'm not saying Atmel should upgrade their 8-bit chips; I'm wondering why a modern chip doesn't "just work" at higher clock rates, irrespective of demand or application.

• In 1975 when the 6502 was designed, transistors were big and slow.  Result: a processor which ran at 1 or 2 MHz.
• In 1996 when the first AVR was designed, logic transistors were capable of 200MHz.  But AVRs do not run at this speed.  Why not? 
  

It could be due to memory speeds, it could be for improved reliability, it could be for compatibility with the numerous on-board peripherals a micro-controller needs, it could be that slow transistors are better in some other way, or it could be something else entirely.  I thought the answer might be interesting, and that somebody here might know.

[Re. motivation:]

Re. motivation:  any project with significant investment in 8-bit architecture (either by code or experience)
looking to make incremental improvements might benefit from a faster 8-bit CPU.

But I prefer to put the question the other way around: given the prevalence and cheapness of fast CPUs,  why are modern 8-bit CPUs still relatively slow?  I'm sure the designers did not turn their back on the available technology without a good reason.  So what is it about their design which stops them running at the same clock rate as other recent processor designs?

Re. power and heat:  look at mobile phone CPUs, already well into the GHz range.  Power-saving modes mean there's little to gain by using slower processors -- in other words the energy consumed per operation does not vary much.  But you're always free to use a slower clock should you desire.

Re. parallel execution:  I agree there's no sense in pipelining an 8-bit processor.  I'm just wondering how much of the speed difference that accounts for.  Surely not all of it, 50x or more?

Re. cost and fabrication:  The 32-bit Raspberry Pi on my desk cost *less* than the 8-bit Arduino Ethernet sitting next to it.  I don't know the costs of the CPU/MCU chips, but they can't be wildly different.  As for return on investment, well I bet more 8-bit chips are sold than 32-bit.  They're absolutely everywhere, and even used as peripherals to 32-bit processors.

There may be a clue in the voltages the CPUs need: the ATmegas need 5V to run at 20MHz, or 1.8V at 4MHz, whilst the ARM core in the Raspberry Pi runs at 700MHz with 1.2V and the maximum recommended voltage is something like 1.4V.  So it sounds like there is a fundamental difference at the transistor level.  Perhaps reliability has something to do with it.  Anybody know?

I see your point, but I don't think that can be the whole story.

Fast 32-bit CPUs have been around for a long time now.  They're cheap and widespread.  And you'd expect modern 8-bit CPUs to be built along the same design principles: same transistors and so on, at least for the CPU core.  All other things being equal an 8-bit core is much smaller and simpler than a 32-bit core, so you'd expect it to be at least as fast.

Now it doesn't make sense to design a hugely complicated 8-bit CPU with parallel instruction execution and so on, so overall performance will be less.  But equally it doesn't make sense to artificially limit the clock rate when a minority of applications could use that extra speed (the same principle has driven PC development for decades).

So is the difference due to CPU complexity - do 32-bit CPUs execute 50 instructions in parallel to get their 50x higher clock rate?

Or are 8-bit CPUs built along fundamentally different lines for some good reason?