Someone in the know should put out a tutorial or information on the operation and use of the Arduino preferences.txt files, since it (they) are so important to the function of the sketches, and information on it (them) is rather vague.
What happens to them!
How they are created!
Where they are stored!
How they can be modified, if user finds it necessary!
**What effect they have on the whole operation**![/u]
Thank you
since it (they) are so important to the function of the sketches, and information on it (them) is rather vague.
But they're NOT important. Important options show up in the menus of the IDE. preferences.txt holds the things that the IDE "remembers" between invocations (like which sketch you're working on), and it holds settings or a bunch of UN-important options that the IDE designers implemented but left out of the actual IDE because "too many options make a program confusing" (which is quite true.)
How they are created!
They are written whenever the Arduino IDE exits (perhaps other times as well, like if you switch sketches.)
What happens to them!
They are read by the Arudino IDE when it starts up, and used to set various internal parameters.
Where they are stored!
(operating system dependent.)(/Library/Arduino on my Mac.)
How they can be modified, if user finds it necessary!
You can modify them with any plain-ascii text editor, but be sure that you don't have the Arduino app open at the time or it will be overwritten when the IDE exits.
What effect they have on the whole operation!
In addition to remembering options that have been set in the menus that DO exist (bit rate for the serial monitor, etc.), it holds settings for various options that we're important enough to have menu options. Like, oh, the various colors used in the editor window, and the font used on the buttons. I couldn't find ANY options that actually affect the "function of sketches." (it MIGHT have had an "extra options to give the compiler" preference. But it doesn't.)
The items in preferences.txt are supposed to have pretty obvious names, and have pretty exact correspondence to variables in the SOURCE CODE of the ide (which of course you can download and browse.) I think the basic idea is that if you can't read the source code, and can't guess what the preference variable name might mean, then it's something you probably shouldn't modify unless you've been told to do so by someone who has read the source code.
The most useful thing to change IMO is to make the line that says:
build.verbose=falseintobuild.verbose=trueThis will change the amount of output from the compiler that is copied to the cconsole window of the IDE during compiles.
Thanks westfw:
I found your posted information very instructive.
posted by: westfw
But they're NOT important. Important options show up in the menus of the IDE. preferences.txt holds the things that the IDE "remembers" between invocations (like which sketch you're working on), and it holds settings or a bunch of UN-important options that the IDE designers implemented but left out of the actual IDE because "too many options make a program confusing" (which is quite true.)
For me, it was necessary to know how to use the preferences file when I finally gave up on using the, supposedly pre-programmed arduino bootloader, and found that I could use parallel programming to program my arduinoized Atmega168. I found this information here: http://arduino.cc/en/Hacking/Programmer (Burning sketches to the Arduino board with an external programmer) For this I had to use the preference files.
I had to search for the proper preference file. Others might want to use parallel programming and will need to know something about using that file. Or find it necessary.
While trying to get my arduino board operating with the bootloader I continuously ran into this problem:
avrdude: stk500_get sync(): not in sync resp+0x00
avrdude: stk500_disable():protocol error, expect=0x14, resp=0x51
I won't go into detail as to all the procedures I tried in attempts to overcome that problem, and all the non-workable advice that I received, (mostly things that I had already done) but I eventually came across the information on parallel programming, so I turned to that, and had to modify the pref. file to do so.
Perhaps someone can help another poster with an identical problem
: avrdude: stk500_get sync(): not in sync resp+0x00
avrdude: stk500_disable():protocol error, expect=0x14, resp=0x51
on this arduino forum (http://www.arduino.cc/cgi-bin/yabb2/YaBB.pl?num=1233093517), and has received no help yet (except for my reply, which is mostly sympathetic)
PO'T
Hmm. When my arduino AVR lost it's bootloader, I used avrdude in "bare" form with an STK-500 to re-install the bootloader, and then went back to using the (unmodified) Arduino IDE to download sketches using the (fixed) normal bootloader...
(The problem with helping people fix bootloader problems is that it usually takes some sort of ADDITIONAL AVR programmer to fix, which takes it out the "easy" category. A generally "correct" piece of advice is that if your brand new arduino doesn't upload programs, you should contact the vendor for advice or replacement. But that's so "general" as to not be very helpful.)
Posted by: westfw
A generally "correct" piece of advice is that if your brand new arduino doesn't upload programs, you should contact the vendor for advice or replacement. But that's so "general" as to not be very helpful.)
Oh yes, I very correctly contacted the vendor as a first step.
After the initial problems with my new arduino, I contacted the vendor. He gave some advice: things that I had already done, which were suggestions that I had followed in the instructions, suggestions from arduino troubleshooting guide, suggestions that I found on the internet. So, as he advised, I sent the assembly back to him, he tested it out found it to be just fine then sent it back.
After I got it back, I still couldn't get it to work. I informed him of my troubles, he replied with a message that said it should work ok and that many people are using the same ckt with no problem, I sent him more information on the type of computer I have, type of operating system, etc. As much info as I could - I have never heard from him again. He refuses to answer any more emails from this idiot customer.
Finally, I sent him a message informing him that I got it going by using parallel programming, one thing that he never suggested. Of course, he didn't reply; not his problem. So "generally" speaking the vendor was no help.
Has anyone offered help to the poster on this arduino forum (http://www.arduino.cc/cgi-bin/yabb2/YaBB.pl?num=1233093517), who has received no help yet ?
His problem:avrdude: stk500_get sync(): not in sync resp+0x00
avrdude: stk500_disable():protocol error, expect=0x14, resp=0x51
Did you try "tools/burn bootloader/parallel programmer" with your parallel programmer (I assume you built it yourself? Good job getting it working!)
That should have worked without modifying the preferences, and should have permitted you to continue using the normal "upload" process (via the serial port) (assuming that it was the bootloader that was broken. The advantage of the built-in USB/serial chip on "official" arduino board is that it removes a LOT of variables that can happen in between your computer and the avr chip...)
I do know, for a fact, that if you make the cable too long on a parallel programmer it won't work, or will work intermittently.
For me, once I did that, I never had a problem re-burning a bootloader using an unmodified preferences file.
Posted by: westfw
Did you try "tools/burn bootloader/parallel programmer" with your parallel programmer (I assume you built it yourself? Good job getting it working!)
Thank you. Yes, I did build it; I've had experience, but I didn't try burning a bootloader. I should do that.
Posted by: BroHogan
I do know, for a fact, that if you make the cable too long on a parallel programmer it won't work, or will work intermittently.
What would be the proper length? I was just kind of arbitrary about the length when I built it. Maybe I should ask this in a different post.
Thank you all 
My cable was about 3 feet when it didn't work and about 18 inches when it did.