Programming speed.

Hi,

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... :slight_smile: )

(Oh, And I get to use the full 16k of my processor for sketchmemory).

So: My question: Someone with a real arduino, how fast does your sketch upload?

Can somone tell me how fast the programming of say a 4k sketch is?

Anywhere from a few minutes to several days, depending on how many bugs the code still contains and what libraries are being used.

I can now program a bootloader (i.e. the full 16k of my atmega168) in less than 8 seconds.

Yeah, but how often do you need to program a bootloader? Still, 8 seconds is phenomenal.

So: My question: Someone with a real arduino, how fast does your sketch upload?

Now, wait a minute. You were asking about something completely different, earlier.

Someone with a real arduino, how fast does your sketch upload?

Less time than it takes to make a decent cup of tea* :wink:

Please fill in your personal preferred beverage :wink:

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 :wink:

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.

So: My question: Someone with a real arduino, how fast does your sketch upload?

Well I can give you one 'benchmark' data point.

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.

Lefty

Lefty, thanks for your datapoint.

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.

Lefty

I 'debug' my sketches using simple serial print statements placed and removed

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 :slight_smile:

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.

I have ftdi breakout using patched avrdude.
Here's benchmarks writing 128kb:

avrdude: writing flash (130672 bytes):

Writing | ################################################## | 100% 53.42s
Reading | ################################################## | 100% 34.49s

I really interested in your faster solution.

would be nice if someone puts these datapoints in an excel sheet to get a graph :slight_smile:

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.

Writing (130kbyte) ... 53.42s

Writing 100kbyte to a 1284p using optiboot (115200bps) took about 19s.
Writing 30kbyte to a 328p takes about 5s.

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.

                                    Target              t1                t2                t3                Average
                                    ------------------  ----------------  ----------------  ----------------  ----------------
Programmer  Version  Baud    SPI    Proce  Speed  Size  Writing  Reading  Writing  Reading  Writing  Reading  Writing  Reading    Total    Rate
----------  -------  ------  -----  -----  -----  ----  -------  -------  -------  -------  -------  -------  -------  -------  -------  -------
ArduinoISP        *   19200  125 K    t85         8192    13.63     9.59    13.63     9.66    13.63     9.59    13.63     9.61    23.24    352.4
TinyISP           1   19200  250 K    t85  1 MHz  8192     8.07     6.52     8.07     6.51     8.08     6.47     8.07     6.50    14.57    562.1
TinyISP           1   19200  250 K    t85  8 MHz  8192     8.14     6.52     8.05     6.50     8.06     6.47     8.08     6.50    14.58    561.9
TinyISP           1  250000  250 K    t85  1 MHz  8192     2.99     2.64     3.07     2.43     2.92     2.54     2.99     2.54     5.53   1481.4
TinyISP           1  250000    2 M    t85  8 MHz  8192     2.50     1.39     2.40     1.72     2.64     1.44     2.51     1.52     4.03   2032.8
Optiboot        3.3  115200    n/a  m328p    n/a  8644     1.64     1.31     1.73     1.37     1.64     1.50     1.67     1.39     3.06   2821.8
Pololu         1.07     n/a  200 K  m328p    n/a  8644     2.46     1.87     2.42     1.87     2.32     1.87     2.40     1.87     4.27   2024.4
Pololu         1.07     n/a    2 M  m328p    n/a  8644     1.14     0.83     1.17     0.72     1.14     0.67     1.15     0.74     1.89   4573.5
Optiboot #      4.4  115200    n/a  m328p    n/a  8644     1.37     1.09     1.39     1.17     1.37     1.23     1.38     1.16     2.54   3403.1
Optiboot #      4.4  250000    n/a  m328p    n/a  8644     0.94     0.66     0.94     0.69     0.98     0.67     0.95     0.67     1.63   5313.9
  • ArduinoISP version 1.0.1-rc2 used.

via Pololu to Breadboard

Arduino version 1.0.1-rc2 used in all tests.
avrdude version 5.11 used in all tests.

For another data point, writing 127K to a Teensy++ using Linux (32 bit) takes approx 5 seconds.

rewolff: I am trying to understand your question. :~
It seems unlikely you are concerned about 4KB
Are you programming many many pieces?
Are you anticipating that if 4KB takes 8 seconds does 40KB take 80 seconds?
Have these posts answered your question ?

Coding Badly: Excellent post. Is there any reason to expect anything other that liner response for larger uploads? What OS are you using? How did you get sub-second times?

Paul Stoffregen: Is that 127KB a uploading performance test or an application you have?

westfw: Is that 127KB a uploading performance test or an application you have? Does that include compiling?

anon10500: Can you provide additional info:
InSystemProgramming IDE host system (ArduinoISP) (windows, linux, mac)
Connection FTDI, SPI, USB
Baud
Uploader program:avrdude, Optiboot, Arduino 1K Bootloader, STK500, AVRStudio

Standalone Programmer: USBTinyISP, USBasp, Pololu

Coding Badly results summerized in spread sheet attached

ProgrammingSpeeds.xls.gz (1.82 KB)

dgerman:
Coding Badly: Excellent post.

Thanks.

Is there any reason to expect anything other that liner response for larger uploads?

Don't know. I'll try different image sizes when I have time.

What OS are you using?

I think this computer is Windows Vista.

How did you get sub-second times?

Optiboot modified for 250 K baud; Pololu AVR Programmer functioning as a USB-to-serial converter.

westfw: Is that 127KB a uploading performance test or an application you have? Does that include compiling?

Performance test. Someone pointed out that it is easy to create a .hex file from an arbitrary text file, so crafting a particular sized upload is also easy. The actual uploads I did were from an disk copy of an SF novel...
("avr-objcopy -I binary -O ihex 100ktest.txt 100ktest.hex")

Is there any reason to expect anything other that liner response for larger uploads?

There are a couple factors that might come into play.

  1. Optiboot attempts to interleave flash "page erase" operations with the upload of the page that will go there, but this isn't possible for all parts of memory (sort of the parts that COULD have bootloader code, whether or not they actually do.) So in theory optiboot will be slower programming the last 4k or so than the earlier flash. (in reality, I'm having trouble measuring any difference...)
  2. Some bootloader protocols have a "bulk upload" protocol that covers 64kbytes or 128kbytes of memory space, but have "other mechanisms" that MIGHT be used (depending on the Host-side programmer software) to upload data beyond that range. But those alternate mechanisms are likely to be significantly slower than the bulk upload protocols...

Coding Badly: Thanks again for your response.
My poorly worded question :"How did you get sub-second times?"
Was meant to ask "How did you get times down to the hundredth of a second precision?"

That's the way avrdude reports them. I'm using the times as-reported. There is some setup time not included (open port, synchronizing, probably reading the file).