I'd bet that I know the answer to this, but I want to run it by somebody who is 100% sure. I'm reasonably sure that programming the Leonardo's Mega32U4 (with it's shipping firmware at least) over it's Pin 0+1 TX/RX UART is a non-starter, since all of the programming now occurs over the virtual com port.
SO I guess my question is this: DOES firmware exist that allows me to upload a sketch over the hardware UART of the Leonardo so I can program without the USB interface? This will allow me to, obviously.... program the device over a wireless link. The project is for a ceiling installation. I know that I can do things like set variables and parameters once it's up there over the XBEE, and provided that I do plenty of testing, I should be ok, but we all know that nothing ever goes as planned, or the artist will want changes, etc, and I won't be able to do that without actually reprogramming the device, and a 30 foot USB cord or a scissor lift laptop party are not my idea of a good time. The other option is to just use a PRO with a 328P...
Disclaimer: Forum searches are being met with "Unable to access the search deamon" this afternoon... It the answer is out there, it's probably because I'm not looking in the right place.
DOES firmware exist that allows me to upload a sketch over the hardware UART of the Leonardo so I can program without the USB interface?
Theoretically you can recompile an optiboot bootloader for the Leonardo, probably without having to change a lot of things. But does that solve your problem? If you do you loose the reprogramming feature over the USB and you don't get programming capabilities over XBee with that (you're missing the reset capability). Why do you use a Leonardo if you wanna have programming capabilities over USART? Why don't you take an UNO to do this project?
It seems you're correct. Recompiling the boot-loader is probably the best solution out there that I can find. The reason I ended up using a Leonardo is because.... well.. that's what I ordered. From my previous post, I had stated that I could solve this problem by using an Arduino with the 328P chip (An Uno, Arduino Pro, etc) and that's probably what I'll end up doing just because it's a faster and more sure way to deal with this problem. As far as the Leonardo and the reset capability, this is (I believe) what the DTR pin is used for in Unos and whatnot, so I see no reason why it shouldn't translate to the Leonardo if wired correctly.
As far as the Leonardo and the reset capability, this is (I believe) what the DTR pin is used for in Unos
The UNOs don't have a DTR pin but the ATmega16U2 has a GPIO that is used to reset the ATmega328P. The DTR pin on the XBee is used only for having handshake lines for firmware updates. Where in the documentation have you found that this signal is transmitted to the remote XBee in a standard serial configuration? To my knowledge this is not the case. It's something different if you load your own firmware on the XBees, then you can use any of the GPIOs and connect it to the reset pin of the UNO or Leonardo to reset the Arduino. But you also have to take care that the reset line of the Arduino is NOT connected to the reset line of the XBee (which usually is the case) because else you won't get in a communication state fast enough before the bootloader finishes waiting for a new sketch upload.
So as it turns out, the RTS on the serial port connected to the programming Xbee ends up getting tied to a DIO on the XBEE. You can then make a reset circuit on the receiving end (and yes you need to modify XBEE settings in XCTU or terminal) OR you can solder a wire to the RST pin on the Arduno Pro's serial programming port (because the circuit in question is already there!)