Can somone tell me how fast the programming of say a 4k sketch is? (using the arduino bootloader).

I don't have a real arduino, but just a more or less compatible board, and I want to know how my programming speed compares. If all goes well, my programming speed will also become available to arduino users, provided they connect the ftdi pins (aargh! with the at90usb162 as the USB chip that has gone away, right?) to the programming header.

I have just finished porting the ftdi bitbang programmer to the most recent avrdude..... I can now program a bootloader (i.e. the full 16k of my atmega168) in less than 8 seconds. (I suspect it can go even faster... :-) )

More serious, some theory:- The compiling speed depends upon the speed of your computer. Not determinable.

- The uploading is done (if I recall correctly) at 57600 baud ==> effectively max 5000 bytes == 5K per second at full throttle. As a program is uploaded in hex, it takes approx 2++ times (some additional overhead) as much time, so we go down to 2K per second. As your OS does some taskswitching in the meantime it becomes indeterminable too. Lets say you get 50% of the timeslices == 50% of the 2K/sec ==> 1K per second is what I expect in practice**. So 4K program takes 4 seconds to upload + some time to compile. I never measured as I like a cup of tea once and a while

In my experience it takes far more time to think about good design, (including data flow functions interfaces IO memory footprint etc) and to define right datatypes and the code right than to get the code compiled and uploaded.

** Hofstadter's Law: It always takes longer than you expect, even when you take into account Hofstadter's Law.

If your arduino usb is plugged into a usb hub containing more than one connected device, its transmission could be blocked for upto 10 seconds. Otherwise yes you can calculate the approx transmission time from the baud rate. Compile time is a good thing, the more it pre calculates there, the less instructions are kept in the finished binary. Arduino compile time is really nothing, I once had a copy of the p2p program shareaza, it took about three to four minutes to compile.

Using the arduino supplied blink program (1018 bytes) using a UNO bootloader equiped board the total compile/upload takes 9 seconds, and I would estimate it's 6 seconds compiling, 3 seconds for uploading. This is on a windows XP SP3 system using arduino ide version 22.

I quoted the time for downloading/burning/programming (chose the term you prefer) a full 16k, as that is most accurate to determine the throughput.

Other things in your computer could slow things down. Other things on the USB bus could slow things down. However as a modern PC can execute billions of instructions per second, and because (reasonable) USB has a throughput of at least 1Mbyte per second, the arduino-programming should not make a significant impact.

I agree that a good program design is a lot better than debugging by trial and error. However bugs do happen, and sometimes you have to debug by adding a print here, then after you've seen the results you decide to add a print of another variable there. Such decisions don't take a lot of time, but once you iterate more than a few times like that, the download speed to the hardware starts to make a difference in the overall speed that you can work.

As far as I could tell, the downloading to the bootloader happens at 19k2, not 57k6, so I was expecting an even lower throughput.

I've flushed a few bugs out of my code, and it's starting to look nice and reliable. Hopefully submit to avrdude code repository today.

I agree that a good program design is a lot better than debugging by trial and error. However bugs do happen, and sometimes you have to debug by adding a print here, then after you've seen the results you decide to add a print of another variable there. Such decisions don't take a lot of time, but once you iterate more than a few times like that, the download speed to the hardware starts to make a difference in the overall speed that you can work.

I 'debug' my sketches using simple serial print statements placed and removed as I progress forward to isolate the problem. I found most of my time is spent thinking carefully where and how to desing and place the next 'test condition' and what results I expect to get. Time spent uploading is pretty unimportant during that kind of troubleshooting. However as I tend to design, write, and test my sketches as small functions at a time, only combining the functions into the overall program once all the low level functions have been tested. I've found while this can take a little longer in inital design time, I tend to see fewer bugs so overall it's quicker to a finished project, at least for me. I tend to build and test my electronic circuits the same way, build a functional stage, test, then move on to next stage.

Tracing is a much applied technique that works very well and quick. However it does not work if you have timing constraints.

Serial output disrupts any timing shorter than (estimate) a few milliseconds so communication and ISR's are difficult(not) to trace with print statement. If you do use print statements, keep them as short as possible e.g. one char or one digit to minimize the effects of the print

If you want to debug in the sub milli region and you have free pins it is possible to use LED's to indicate state(change) of variables, and for even faster debugging you have to connect a scope to IO pins.

What always work for me is to trace the code with pencil and paper, a box for every var, "playing the cpu" has solved many coding errors in my life.

It is all very well getting the data into the arduino but you have to burn it in the flash memory, it is this that dominates the upload / program time, and it is this that is indeterminent as it changes with the age of the flash. That is how many times it has been programmed before.

I don't pay much attention, it takes what it takes. Doesn't seem like long tho.

Don't why the IDE has to re-compile before downloading, when I had just compiled to make sure the code updates I might have made did not introduce compile errors.

Downloading bootloaders varies - with Atmel AVR ISP MKii & AVR Studio 5.1, bootloading a '1284 the first time, even set to 125 KHz (need slow first time adding a bootloader) goes waaaaaay faster than using MDFLY programmer - MKii only seems to program the boot area, while MDFLY & the IDE appears to program the entire 128K of flash memory.

I tend to follow retrolefty's approach - I may write what seems like a complete sketch, but I'll comment out sections and add print statements to see what is going on.Having lots of comments is good in case there are delays between coding sessions, or to keep straight what you intend to have happen.

I was doing that last night, trying to find out why I couldn't data from MAX232 thru 9pin connector to RS232/USB cable (with prolific chip inside) to my PC. Turned out I needed to swap Rx/Tx between chip & connector, so the cable adapter was expecting DTE & I was wired for DCE (or vise versa).

Along same lines, added print statements to verify octal 12-bit ADC was reading data correctly from pot's and could be passed along.Will be checking out quadrature encoders tonight.Then start reading some data back and setting some LEDs on/off based on the message received.

Sometimes I'll use LEDs as indicators too, just a brief flash to show a section of code was executed, or more often to show that the software is mapped to the IO pins in agreement with the hardware routing for PCBs.