Go Down

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

dgerman

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

Coding Badly

Coding Badly: Excellent post.


Thanks.

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

Quote
What OS are you using?


I think this computer is Windows Vista.

Quote
How did you get sub-second times?


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

westfw

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

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

dgerman

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

Coding Badly


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

dgerman

Coding Badly: Thanks.
(Now a little off topic)
I am using Mac Arduino IDE, tools/programmer/AVR ISP; FTDI cable to USB serial port .
If I (accidently) unplug USB I get message
avrdude: stk500_recv(): programmer is not responding
Am I using avrdude? I get no timing messages.


Coding Badly


I don't understand the question.

westfw

The timing messages from AVRDude (and much of the rest of the output) are supresed and/or removed by the Arduino IDE, and/or are modified if you use verbose mode.  If you run AVRDude from the command line of a terminal window, you'll see very obvious reports:
BillW-MacOSX-2<10250> /Applications/arduino/arduino-1/Arduino-1.app/Contents/Resources/Java/hardware/tools/avr/bin/avrdude -C/Applications/arduino/arduino-1/Arduino-1.app/Contents/Resources/Java/hardware/tools/avr/etc/avrdude.conf -patmega1284p -carduino -P /dev/tty.usbmodemfd3141 -b19200  -U lock:w:0x3F:m -U flash:w:optiboot_atmega1284p.hex -U lock:w:0x2F:m

avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.02s

avrdude: Device signature = 0x1e9705
avrdude: NOTE: FLASH memory has been specified, an erase cycle will be performed
         To disable this feature, specify the -D option.
avrdude: erasing chip
avrdude: reading input file "0x3F"
avrdude: writing lock (1 bytes):

Writing | ################################################## | 100% 0.02s

avrdude: 1 bytes of lock written
avrdude: verifying lock memory against 0x3F:
avrdude: load data lock data from input file 0x3F:
avrdude: input file 0x3F contains 1 bytes
avrdude: reading on-chip lock data:

Reading | ################################################## | 100% 0.02s

avrdude: verifying ...
avrdude: 1 bytes of lock verified
avrdude: reading input file "optiboot_atmega1284p.hex"
avrdude: input file optiboot_atmega1284p.hex auto detected as Intel Hex
avrdude: writing flash (131072 bytes):

Writing | ################################################## | 100% 0.68s

avrdude: 131072 bytes of flash written
avrdude: verifying flash memory against optiboot_atmega1284p.hex:
avrdude: load data flash data from input file optiboot_atmega1284p.hex:
avrdude: input file optiboot_atmega1284p.hex auto detected as Intel Hex
avrdude: input file optiboot_atmega1284p.hex contains 131072 bytes
avrdude: reading on-chip flash data:

Reading | ################################################## | 100% 82.37s

avrdude: verifying ...
avrdude: 131072 bytes of flash verified
avrdude: reading input file "0x2F"
avrdude: writing lock (1 bytes):

Writing | ################################################## | 100% 0.05s

avrdude: 1 bytes of lock written
avrdude: verifying lock memory against 0x2F:
avrdude: load data lock data from input file 0x2F:
avrdude: input file 0x2F contains 1 bytes
avrdude: reading on-chip lock data:

Reading | ################################################## | 100% 0.02s

avrdude: verifying ...
avrdude: 1 bytes of lock verified

avrdude: safemode: Fuses OK

avrdude done.  Thank you.

Paul Stoffregen

#23
Apr 16, 2012, 12:16 pm Last Edit: Apr 16, 2012, 12:46 pm by Paul Stoffregen Reason: 1

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


I just clicked the Upload button in Arduino and watched a clock window on my computer, which admittedly isn't highly accurate, especially since I'm looking at the LED on the board and then I look over at the screen to see how many seconds elapsed.

I just tried it again, using a digital kitchen timer (with 1 second precision), where I click the Upload button with 1 hand and the timer start button with the other hand.  The sketch I'm loading is File > Examples > Basics > Blink with the pin changed to 6 (since Teensy++ has a LED on pin 6), and I set the Tools > USB Type to "Disk(internal)" (which causes all unused flash memory to become a tiny USB disk drive, creating a maximum size upload of 127K).  After clicking Upload, I stare at the LED with my finger on the stop button, which I press the instant the LED lights again.  The first second or so it continues to blink, while the PC compiles code, and then stops blinking during the actual upload.  It lights up again when the freshly-uploaded code begins running.  That occurs right after the timer advances from 4 to 5 seconds, so it's between 5 to 6 seconds, but much closer to 5 than 6.  Sorry, I don't own a sub-second stopwatch.  I could build something, but I'm not going to.  This is as accurate as I'm willing to measure for the sake of this conversation.

Again, the 5 second is from the moment the Upload button is clicked until the LED starts blinking again, so it includes the compile step and any overhead, and perhaps a slight error of human reaction time.

I stopped when the LED lights, but since Teensy is a native USB device which has just rebooted, the PC takes a moment to detect the newly-connected USB device.  I did NOT measure the extra time (on the scale of a second or two) until Linux fully enumerates the USB device and the kernel and udev deamon create new device files, and a moment later a new window appears showing the files (since in this test Teensy was configured to be a USB disk).

While those 5 seconds do include the compiling, when using Teensyduino, Arduino is patched with a speedup which avoids recompiling previously compiled files.  I contributed this code to Arduino and it has become part of 1.0.1-rc2, so you can grab that version for a small speedup in the compile step.  I repeated this test, but changed boards back and forth before clicking upload (changing Tools > Board causes a full recompile).  It measured 6 seconds, and the timer had been on 6 and might have been just about to advance to 7... so the full recompile adds about 1.5 seconds on my machine (which is Ubuntu 10.10, 32 bit, on a 2.8 GHz core2 processor, 2009 vintage).  The full recompile for Teensy probably takes longer than Arduino Uno, since it's recompiling a complex USB stack as well as all the usual Arduino functionality.

Anyway, that's exactly how I measured 5 seconds for 127K upload, since you asked....

Trust me, one of the first comments I regularly hear from long-time Arduino users when they try Teensy is how much faster the upload goes.  It's native USB with a specially written application, so it ought to be fast!  The speed varies slightly on each operating system, but it truly does upload very quickly compared to using AVRDUDE on conventional boards.


Paul Stoffregen

I'm afraid I must revise my time to 7 seconds.  I thought about this again and realized much of the data I was uploading was blank.  I copied a 120K jpeg image into the data set used in the initial disk image.  During upload, the erase step before the upload begins takes longer if the memory was previously programmed with non-blank data.

I measured 7 seconds to upload 127K to a Teensy++, using the digital kitchen timer, from the instant I clicked the Upload button in Arduino until the LED begins blinking when the code starts running.

dgerman

MacBookPro OSX lion USB to Duemilanova.
Running IDE with preferences :show verbose output during 
  • upload
    includes (in addition to every byte sent and received. maybe -v -v -v -v is one to many)

    100% 1.84s
    3660 bytes of flash written
    verifying flash memory against /var/folders/f6/...A1.cpp.hex:
    load data flash data from input file /var/folders/f6/.../A1.cpp.hex:
    input file /var/folders/f6/.../A1.cpp.hex contains 3660 bytes
    reading on-chip flash data:

    100% 1.57s
    verifying ...
    3660 bytes of flash verified

Go Up