next topic »

[on:]

Hi,
as discussed in an another topic, it seems designs with the 1284p may benefit when Full Swing Oscillator setting has been used, at least as the upload reliability is concerned. The 1284p DIL has got flipped XTAL1 and XTAL2 pins against ie. 328p, thus the 1284p' pin XTAL1 (crystal oscillator input, sensitive, high impedance) could be affected by the noise injected from adjacent pins (ie RX0).
http://arduino.cc/forum/index.php/topic,139671.120.html

[Reply #1 on:]

He means this knuckle bruiser of a thread, last few postings,
http://arduino.cc/forum/index.php/topic,139671.105.html

[Reply #2 on:]

Great job troubleshooting this.  Now I understand why the UART1 Optiboot worked!  I am unclear if you are using the "full-swing" with an external crystal or external resonator.  I currently use the resonator and full-swing with no trouble for those dips.

[Reply #3 on:]

I am unclear if you are using the "full-swing" with an external crystal or external resonator

..do use it with both..
PS: I would recommend to use full-swing-oscillator fuse setting with all 1284p-DIL-pin-compatible variants..  

[Reply #4 on:]

I wonder why the 644p DIL/DIP is not plagued with this flaw...

[Reply #5 on:]

BTW, this may apply to other Arduinos as well.  The way I read the datasheet(s) and the boards.txt file, almost ALL arduinos are configured to use the low-power crystal oscillator, which "tops out" at 16MHz.  The full-swing oscillator is for crystals between 0.4MHz and 20MHz...

I had a problem with the current setting on an ATmega8 with ceramic oscillator; it looks like the Atmel recommendation is to use the full swing oscillator always, with resonators.  But the same board that worked fine with 168 and 328p using a 16MHz resonator, failed when I put the mega8 in there, and started working again when I changed the fuse setting.

[Reply #6 on:]

BTW, this may apply to other Arduinos as well.  The way I read the datasheet(s) and the boards.txt file, almost ALL arduinos are configured to use the low-power crystal oscillator, which "tops out" at 16MHz.  The full-swing oscillator is for crystals between 0.4MHz and 20MHz...

I had a problem with the current setting on an ATmega8 with ceramic oscillator; it looks like the Atmel recommendation is to use the full swing oscillator always, with resonators.  But the same board that worked fine with 168 and 328p using a 16MHz resonator, failed when I put the mega8 in there, and started working again when I changed the fuse setting.

Indeed.  I was under the impression that full swing was just for resonators, but, viola, it works for both.  I wonder if it works for the internal resonator   Just kidding.

[Reply #7 on:]

i dont see why anyone would not use full swing for boards like this in the first place. the power savings is insignificant compared to things like chip and regulator idle current. many xtls wont even oscillate w/o full swing. not to mention the extreme sensitivity to noise and component variations. imo arduino designers made a few bad decisions. poor choice of xtl frequency almost guaranteed to fail at high baud. another example would be setting fuse to destroy ee data every time chip is reflashed. whats up with that.

[Reply #8 on:]

setting fuse to destroy ee data every time chip is reflashed. whats up with that.

irrelevant, since the chip is normally programmed via the bootloader, which doesn't do "chip erase" (and never erases the EEPROM) ?

[Reply #9 on:]

irrelevant...

Well, it's relevant in the sense that new users, thinking the Arduino folks did not include it for a valid reason, don't include it when programming without a bootloader.

[Reply #10 on:]

irrelevant...

Well, it's relevant in the sense that new users, thinking the Arduino folks did not include it for a valid reason, don't include it when programming without a bootloader.

Are you saying that an ICSP upload erases the EEPROM contents?

That would certainly explain something that was happening with me and a menu library. I thought my settings weren't being saved, but maybe this was the issue.

[Reply #11 on:]

irrelevant...

Well, it's relevant in the sense that new users, thinking the Arduino folks did not include it for a valid reason, don't include it when programming without a bootloader.

Are you saying that an ICSP upload erases the EEPROM contents?

That would certainly explain something that was happening with me and a menu library. I thought my settings weren't being saved, but maybe this was the issue.

It appears that there is fuse bit that determines if a chip erase commands erases or reserves the EEPROM data, and a quick check of the Uno fuse values looks like it does allow a chip erase to wipe EEPROM clean, but I would let others verify that as I can be pretty fuse value challenged at times.  

Lefty

[Reply #12 on:]

...I would let others verify that as I can be pretty fuse value challenged at times.  

Not this time.  Spot-on.

The fuse in question... Preserve EEPROM memory through the Chip Erase cycle; [EESAVE=0]

[Reply #13 on:]

...I would let others verify that as I can be pretty fuse value challenged at times.  

Not this time.  Spot-on.

The fuse in question... Preserve EEPROM memory through the Chip Erase cycle; [EESAVE=0]

Cool, so the user has control over this if they wish to change the fuse setting. I wonder how much scrutiny or analysis the fuse setting values when through for all the various boards.txt entries by the Arduino team?

Lefty

[Reply #14 on:]

Thanks for the response lefty and CB. I'll have to have another investigate to see if that was my problem. I'll have to try and work out if that is also true for the 1284P fuse settings. Now that I can also upload to the 1284P via serial, I'll give it another go and see if my settings are preserved.