It's strange that you managed to upload the bootloader and Blink to the breadboard, but cannot upload anything else.  Which bootloader are you using?  The Uno bootloader is designed to work with auto-reset, so only waits a very short time for programming to start.  Are you certain that the Arduino is configured with RX and TX as inputs?

If programming via the TX/RX pins doesn't work, rearrange everything as for the bootloader installation and try uploading sketches via ArduinoISP.

Thanks guys.  I think I can manage without static globals, though exception handling could have been useful.  The comments on the build process were interesting and prompted me to look a little further into it.  If anybody is using a Makefile instead of the IDE, I'd be interested to hear their comments.

After using plain C for some 20 years, I am finally getting around to learning C++.  Apparently it is generally considered that C++ is not ideal for micro-controller programming.  However a number of Arduino libraries are written in C++.  And writing a few little test routines, I was pleased to see that compiled binaries from Object-Oriented code were barely larger than their non-OO equivalents.  Including Mikal Hart's <Streaming.h> library actually made some sketches shrink.

So I thought I'd just ask here if anybody has any thoughts, tips, or pointers regarding C++ on the Arduino?

PS. If anybody else is thinking of moving from C to C++, but has been put-off (as I was) by poor explanations in huge multi-volume textbooks, I can recommend Gregory Satir & Doug Brown's book, published by O'Riley.

Yes, the 10uF capacitor should normally disable the reset.  But if the modified sketch is being uploaded to the Arduino, it must be being reset somehow.

Does it stay lit if you remove the ATmega chip?  The FTDI chip should not need programming, and if your PC recognises it that's a good sign.  It could be that the AVR chip has its serial pins configured as high outputs, forcing the serial LEDs on.

In this setup you have two micro-controller chips connected to the same serial interface: one on the Arduino board, and one on the breadboard.  In order for this to work, one of the chips must not interfere with the serial interface signals whilst the other is being programmed.  It sounds as though the chip on the Arduino board is being reset, causing its bootloader to take over the serial interface.  Check that the Arduino chip has its reset suppressed, and has its RX and TX pins both configured as inputs.

Isn't it impossible to erase the bootloader by accident?  And normally the application lives at one end of the memory and the bootloader at the other, so even if the memory-lock bits are reset, the application will only overwrite the bootloader if it occupies almost all the available memory.

If you've disabled auto-reset on the UNO, it should be able to upload sketches to the breadboard chip.  AFAIK ArduinoISP uses the same upload protocol as the bootloader, so to Avrdude and the Arduino IDE it should appear like a normal Arduino board.  Keep the wires connected as they were for installing the bootloader and try it.

Lefty, are you thinking of the "amnesia" bug?  This sounds different.

Yes, sorry, I used completely the wrong term.  Inertial positioning is what I should have said.

What I have in mind is double-integrating the 3D acceleration to get position, assuming the sensor does not rotate.  Then I'd like to remove the rotation constraint by incorporating readings from a gyro.

The specs for reasonably-priced sensors seem amazingly good, but of course the errors will grow enormously once integrated over time.  The 650m/hr figure on Wikipedia is discouraging.

Hello,
Has anybody got any experience with gryo and accelerometer sensors?  I'm wondering how fast the errors accumulate when calculating relative-position by dead-reckoning.  For example, if a rover equipped with one of these sensors sets off to do a lap of a room, how near could it get to its starting point after (say) a minute?

if the constant is in the range of an "int" then the compiler treats it as an "int".  The result of any operation between two "int"s is an "int".

Ah-ha!  Nice explanation by the way.

Code:

  int n=32767;
  int i;
  long l;
  float f;
  i=32767+32767;
  l=32767+32767;
  f=32767+32767;
  Serial.println(n); // "32767"
  Serial.println(i); // "-2"
  Serial.println(l); // "-2"
  Serial.println(f); // "-2.00"

He's right too... 

Here's some useful links.  There's more in the "Playground" section of these pages.

http://arduino.cc/en/Hacking/BuildProcess
http://arduino.cc/en/Hacking/Bootloader
http://arduino.cc/en/Hacking/Programmer

These versions may be slightly clearer.  They avoid typecasting the integer into a character array.  See any C reference for an explanation of the '>>' and '&' operators.

This writes out the address as a binary number

Code:

/* initialisation */
uint16_t ptr;

/* these lines go inside the loop */
ptr = (uint16_t) &value;               // store 16-bit address of 'value'
putchar( (char) (ptr >> 8) & 0xFF );   // Write out high-byte of memory address
putchar( (char) (ptr >> 0) & 0xFF );   // Write out low-byte of memory address

This writes out the address as human-readable hexadecimal text

Code:

/* initialisation */
char string[]="0123456789ABCDEF";       // array of characters corresponding to numbers from 0 to 15
uint16_t ptr;

/* these lines go inside the loop */
ptr = (uint16_t) &value;                // store 16-bit address of 'value'
putchar( string[ (ptr >> 12) & 0xF ] ); // Write out highest 4-bits of memory address
putchar( string[ (ptr >>  8) & 0xF ] );
putchar( string[ (ptr >>  4) & 0xF ] );
putchar( string[ (ptr >>  0) & 0xF ] ); // Write out lowest 4-bits of memory address

How do you know that the pointer will be a 16-bit address? I looked at the avr-libc pages. They indicate that a uint16_t is an unsigned integer and is 16 bit. On some other places on the internet an unsigned integer is a 4 byte variable (or 32 bit). Not sure why there is a difference here, maybe depends on the system you are using the variable on.

A pointer is just a memory address, so the size of the variable storing the pointer value has to match the size of the memory address.  I was assuming you were using an ATmega328 or 168, which have 16-bit memory addresses.  So my code would not work on a processor with a larger memory space.  A uint16_t is always 16-bit by definition, whereas the size of an int varies depending on the platform and compiler.

The pointer value that I am trying to display is iterating. I try to display it after each iteration, but the value doesn't update when outputed to uart. Are there issues regarding outputing a pointer at runtime?

You'll need to re-read the pointer each time it changes.  So after every iteration you'll need to do this line before writing to the serial port:

Code:

uint16_t ptr = (uint16_t) &value;  // store 16-bit address of 'value'