Go Down

Topic: Programming speed. (Read 3912 times) previous topic - next topic

rewolff

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

(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?

PaulS

Quote
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.

Quote
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.

Quote
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.

robtillaart

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

Less time than it takes to make a decent cup of tea* ;)

Please fill in your personal preferred beverage ;)

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.


Rob Tillaart

Nederlandse sectie - http://arduino.cc/forum/index.php/board,77.0.html -
(Please do not PM for private consultancy)

pYro_65

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.

retrolefty

Quote
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


rewolff

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.

retrolefty

Quote
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


robtillaart

Quote
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 :)

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.
Rob Tillaart

Nederlandse sectie - http://arduino.cc/forum/index.php/board,77.0.html -
(Please do not PM for private consultancy)

anon10500

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.

robtillaart

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

Nederlandse sectie - http://arduino.cc/forum/index.php/board,77.0.html -
(Please do not PM for private consultancy)

Grumpy_Mike

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.

westfw

Quote
Writing (130kbyte) ... 53.42s

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

CrossRoads

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.
Designing & building electrical circuits for over 25 years.  Screw Shield for Mega/Due/Uno,  Bobuino with ATMega1284P, & other '328P & '1284P creations & offerings at  my website.

Coding Badly

#13
Apr 14, 2012, 11:11 am Last Edit: Dec 29, 2012, 08:57 pm by Coding Badly Reason: 1

                                    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.

Paul Stoffregen

#14
Apr 14, 2012, 07:19 pm Last Edit: Apr 14, 2012, 07:30 pm by Paul Stoffregen Reason: 1
For another data point, writing 127K to a Teensy++ using Linux (32 bit) takes approx 5 seconds.

Go Up