Nick: Am I right to assume that if want to use 328p with a 16mhz oscillator, I would need to change the fuses by loading the uno bootloader or by some other method?
Reason: I have a sketch that runs quite will on the uno, but runs quite slow on the breadboarded 328p. I tried hooking up an oscillator (don't have a crystal right now), but it seems to make no difference, so I assumed that something has to happen with the fuses. Correct?
Also, I don't know if this is proper board etiquette since I may be introducing topic drift with this question. 
Thanks for all your help.
crchisholm:
Nick: Am I right to assume that if want to use 328p with a 16mhz oscillator, I would need to change the fuses by loading the uno bootloader or by some other method?
Yes, otherwise it is probably still using the internal oscillator. Possibly divided by 8. You should be able to to it with just a fuse change if you are confident. Otherwise doing a bootloader upload should do the trick as part of that process is to fix up the fuses.
Reason: I have a sketch that runs quite will on the uno, but runs quite slow on the breadboarded 328p. I tried hooking up an oscillator (don't have a crystal right now), but it seems to make no difference, so I assumed that something has to happen with the fuses. Correct?
Correct. In fact simply adding the resonator won't do anything useful. You have to tell it to use it.
Also, I don't know if this is proper board etiquette since I may be introducing topic drift with this question.
That's fine.
I would really like to learn to change these fuses "safely" even if one or two hit the sacroficial flames. Any clues as to where I might get the info to learn this?
I have never added the bootloader either, but I figure that won't be to difficult through the arduino software. Just hate to add something unnecessarily.
See this page where I talk about fuses at some length:
Near the bottom are suggested ways of changing them.
You are a jewel!!
I have a USBASP so I will probably try the ISP method. Unfortunately, my day job is pulling my strings pretty hard right now, but hopefully in a day or two.
Thank you.
Sorry...sometimes I just can't turn loose of things.
I was looking at the AVR Studio simulator and it appears that there are two changes I would need to make. I would want to turn off (0) the CKDIV8 bit and turn on (1) the CKOUT bit. Does that sound right?
Not quite.
Uncheck "divide by 8", yes.
Don't check CKOUT. That just outputs the clock on one of your pins. Your probably don't want that, and it just ties up a pin.
Select from the drop-down list "External oscillator 8 MHz" as shown. That will use the external crystal. It doesn't say 16 MHz but that's OK. The clock speed is what it gets.
CTS is normally an input. So I wouldn't expect an output pulse on this pin.
It is used for hardware flow control to tell the FTDI chip to stop transmitting serial data.
Setting it to ground tells the FTDI chip the other end is always ready.
While there are some variations. Normally, DTR is under control of the OS
and drops when the first open() on the serial port is done (multiple programs can
open the same serial port when non exclusive mode is used) and raises when
the last close() happens.
unix/linux can often use the stty -hup command to alter this behavior.
RTS is normally an output and is normally used for hardware flow control to tell the other end
(Arduino in this case) to stop sending serial data.
Software on the host can usually override this functionality and control the RTS signal level.
I actually prefer using RTS over DTR for autoreset because with DTR, the pin is controlled
by the OS before the application can override its functionality.
(Some OS's have the ability to configure/change this behavior).
But since RTS is usually used for h/w flow control, its output level will not normally change
when the port is opened so software can then disable h/w flow control and grab control of it.
The IDE and the newer avrdude when using the "arduino" protocol will toggle RTS so that an
an auto reset occurs when using RTS.
The reason I prefer RTS over DTR is if using RTS autoreset will happen when using
the IDE to upload but will not happen when the serial port is opened directly.
This allows you do things like open the serial monitor or write a custom application
that can communicate with the AVR and not reset the chip every time you open the serial port.
I have yet to figure out why those FTDI cables are so expensive.
I have one but now I use these:
http://www.ebay.com/itm/USB-2-0-to-UART-TTL-6PIN-Module-Serial-Converter-CP2102-NEW-/170813676975?pt=PCC_Drives_Storage_Internal&hash=item27c549ddaf
because all the signals you need are easily accessible.
With a tiny bit of re-wiring you can create a fully compatible 6 pin FTDI connector including
using RTS instead of DTR, if you like, to connect to the arduino
to have fully functioning upload cable with autoreset for less than $3 USD.
(The RST signal on this board resets the cp2102 but the serial RTS is also available)
--- bill
bperrybap:
CTS is normally an input. So I wouldn't expect an output pulse on this pin.
It is used for hardware flow control to tell the FTDI chip to stop transmitting serial data.
Setting it to ground tells the FTDI chip the other end is always ready.
Thanks for the suggestions. I amended my image (which appears in various posts) to connect CTS to Gnd.
CrossRoads:
How about a '1284 version Nick 
I think I may have posted this elsewhere, but the original page now shows the 1284 as well.
Ok according to avrdude using -v my fuses are currently....
lfuse = 0x62
hfuse = 0xD9
efuse = 0x7 (07 I guess)
according to the simulator in AVR Studio, I need lfuse to be FF, so it seems that I should be able to use avrdude to make the changes like this...
avrdude -c usbasp -p m328p -U lfuse:w:0xff:m
I am assuming that this will change the lfuse and leave efuse and hfuse as they are.
Does this seem to be the right direction?
(it almost seems that I should be able to do it in AVR Studio, but don't know how to get it to recognize my usbasp)
Yes that should do it.
My AVR uploader sketch, described here:
... can now be used to change fuses.
So...I do the avrdude as outlined above and the final message is an error. I'm think "Oh crap!" Then I realize that if it changed the fuse, it would expect the occilator and even though it communicated long enough to change the fuse, it couldn't communicate after tha to give the rest of the message.
Plugged it into the board that was running so slow and it does exactly what I wanted.
Thank you again. I love it when a forum plan comes together.
Charlie
Nick,
Can you add to your program to support 1280 boards too?
My recent sketches all support that chip.
The ATmega640, ATmega1280, ATmega1281, ATmega2560 and ATmega2561. Amongst others.
You can get them all in a batch from here:
Just click the Downloads button.
