I'm using an old Arduino BT for testing at my workstation and, for the actual application, an Atmega328 in an Olimex 28 pin development board (reachable only via RS-232) -- so I wouldn't have thought to call it a UNO.

i narrowed down the range of sketch sizes where the optiboot bootloader would fail to between 28660 and 28676 and then did google searches on each of the values with optiboot:

optiboot 28660
optiboot 28661
etc.

and got hits for 28666 and 28668 -- that latter one (and 28672) gave me this page:
http://code.google.com/p/optiboot/issues/detail?id=23

I loaded the bootloader myself, using (in at least one case) the optiboot bootloader provided with the Arduino022 download (I've found it more or less impossible to migrate my code to Arduino 1.0X, but then again there isn't much motivation). The thing about "well known bugs" is that they're only really well-known to people who know.  My Google searches turned up nothing when I searched for all the symptoms I was seeing. It's good to hear this bug has been fixed; Optiboot is so much better than any other bootloader I've tried.  I really don't have the time to wait around for the stock bootloader. Also:  for an Arduino to be usable in real equipment, there needs to be a watchdog (supported by Optiboot and Adaboot). Otherwise your solar pump will hang at some point while you're on a beach in the Dominican Republic and all your antifreeze will boil out into the snow.

This is just a word of warning to people who compile large Atmega328 sketches using the Optiboot bootloader on Arduino0022 and 0023 (I haven't tried it on other versions of the IDE).  When the sketch exceeds 28725 bytes in size (and possibly smaller, though no smaller than 27734 bytes), the upload will fail if you are using the Optiboot bootloader.  It will initially seem to be working (lights will blink, etc.) but the the upload will hang.  This isn't a problem with the Adaboot bootloader (and perhaps others that allow so much usable flash space).  It was good to finally figure out that the size of the sketch was the issue and not something else. (It took me hours to figure out what was wrong -- it was only obvious when I tried uploading a different sketch.)

The error you will get when the upload fails is:

avrdude: stk500_getsync(): not in sync: resp=0x00
avrdude: stk500_disable(): protocol error, expect=0x14, resp=0x51

the commands in avrdude work for ponyser -- that's never been a problem. that's how i write the bootloader.

i would modify board.txt if i could find any info on what needed to be changed.  when i did this for arduino23, all i had to do was modify programmers.txt.  as things stand now, i can't use arduino1.0.3 -- which is just as well considering how much code of mine that it breaks (arduino.h, really?).  but i would like to try out some libraries written by others for it.

I don't really know what my device actually IS, I just know that it worked with this configuration in programmers.txt:

avrisp.name=Ponyserial
avrisp.communication=serial
avrisp.protocol=ponyser
avrisp.speed=19200


as you can see, it's a serial programmer. Hardware-wise, it only uses a few components:

here's the schematic:
http://www.lancos.com/siprogsch.html

I don't think any of that is at issue, though.  The problem is that Arduino1.0.3 doesn't seem to obey the dictates of programmers.txt.  I was hoping someone who has dealt with this issue could tell me what my problem is.

I've been searching everywhere for help on this, but part of the problem is that virtually nobody says whether what they are describing is happening in Arduino1.X or in the pre-1.0 version of Arduino.  The differences between those two are pretty big (and software incompatibility has kept me using Arduino23 (pre 1.0) for any actual work I do.  That said...

I cannot for the life of me figure out how to get my PonySerial programmer working in the Arduino 1.0.3 IDE.  I tried editing programmers.txt, but the IDE (unliked Arduino23) seems to completely ignore that info. I know, because I changed the names of the programmers and nothing changed.  Evidently it is pulling its programmers.txt file from somewhere other than C:\Program Files (x86)\arduino\hardware\arduino .  Argh! I'm about ready to cry.  Why couldn't things work like they did under Arduino23?  Part of the reason I try to stick with open source as opposed to proprietary environments is that changes tend to be evolutionary and not revolutionary.

Here's my solar controller, which involves master/slave Arduinos, an LCD, a real time clock, a range finder, and EEPROMs, so there should be plenty of example code in here for those who are hungry for that sort of thing. Most recently I created an interactive menu system using an LCD and an IR mutifunction remote (the code is all in the slave arduino).

Watch me narrate the menu system here:

more details here:
http://asecular.com/projects/homebrewsolar.php

the thing is, if you don't know the name for something and are simply experiencing a problem that you think you can solve, you find yourself designing something (at least in your head) until finally your research takes you to the wheel that has already been invented. i did a lot of research on how best to implement a 555 "auto resetter" (as i called it) before stumbling across a web page that spoke of watchdogs.  at that point i found atmel builds watchdogs into their chips and i was ecstatic!  i didn't have to build anything, i just needed a different bootloader and a couple lines of code. the more i work with arduino, the more i discover how rich an environment it is.  there's the arduino layer, but just beneath that is this huge avr layer. i do a google search, find some non-arduino page referencing libraries that turn out to exist in the the arduino environment. it's continually surprising (but in a good way).

a few days ago, i found myself needing a watchdog without evening knowing there was such a thing and that it had a name.  my initial plan was to hook up two 555 timers (actually, two such timers in a 556 package), using one as a missing pulse detector and the other as a brief one-shot (it would have to work through a logical inverter).  i'd dedicate an arduino pin to sending regular pulses to the missing pulse detector, and if that ever failed, i'd fire the one shot, which would strobe the reset pin through the inverter.  it wouldn't be difficult to implement and wouldn't require a special bootloader. but then i discovered that watchdogs are real things and are implemented in hardware on atmel chips.  the tricky part was getting past the stock bootloader, which is inherently incompatible with the built-in hardware watchdog. if i were in your position and gave up on the bootloader, i might implement the dual 555 analog watchdog.

After much experimenting, I was finally able to implement the Atmega328's watchdog.  This required, among other things, use of the Optiboot bootloader (which works so much better than stock bootloaders!).  My question is:  does anyone know if a reset generated by the watchdog timer actually pulls the Atmega328's reset line low electrically?  I'm curious because that line is connect to other things and it would be nice to know that they are also rebooting (or, if they are not, i might need to do something).  I know I could watch the reset line with an oscilloscope, but I don't feel like taking the circuit out of its application and hooking all that up right now.

i don't have the arduino cookbook. things are moving so fast with arduino that a book would probably get out of date pretty fast. i started working on atmega8s and my old sketches resemble my first VIC-20 BASIC programs: short and primitive.

this is in reply to nick about the use of Wire.available(). interestingly, i'd had code in there to do that but had bypassed it for some reason (i notice it's occasionally not used when communicating with certain other i2c devices when the byte count to be returned is known).  re-enabling it seems to be making my communication completely reliable.  thanks for the idea!

 

Can you explain exactly what you mean by "synchronously" in this context? Do you mean, you ask a question and get an answer?

i mean to ask a question of a device and then stop everything while waiting for an answer (as opposed to asynchronously, where i ask a question, go on with the program, and get the answer later, perhaps as an interrupt or in some place i can poll).
 
 

What is the problem with global variables? The response is done in an interrupt handle

there's nothing wrong with it -- but initially i'd thought the onRequest handler could also read data being passed in with the request.  this does not appear to be the case. i'd found no examples of anyone using a slave to do request-response type data exchanges of the type done by, say, a 24LC512 EEPROM, and i wanted to implement it.

 

I have done some examples of sending/receiving data via I2C here (scroll down to "Request/response"):

http://www.gammon.com.au/forum/?id=10896
 

nice!  i would have loved to find this example when i was working on the problem.

You shouldn't need to send things three times. Why do that?
 

i did it because i'd often get zero instead of the byte i'd requested. i have no idea why -- it was being flaky.  i need to investigate further. the other i2c devices on the bus all seem to work fine; it's just the slave that occasionally throws out glitch zeroes in response to queries.