Using Arduino 1.0.
I compile my sketch by clicking the "check" button. It takes the usual (overly long) amount of time, and compiles fine.
Then I click the upload "arrow" button to upload the just-compiled sketch, and Arduino re-compiles it before uploading.
This is very tedious.
Previous versions of Arduino knew it didn't need re-compilation for upload... why does v1.0 insist on performing these unnecessary re-compiles?
-Dave
For each library you use the IDE would have to keep track of what compile-time options were selected last time it was compiled in order to be sure the resulting binary would not be different. For most cases the compile doesn't take more than a few seconds.
No need to 'verify' your code is you plan to immediately upload it. Just hit the upload button. If the compile fails it won't upload.
(Verify is useful if you want to check the compile without having the target board connected.)
I get what you're saying but respectfully disagree.
All the IDE really needs to do is compare the timestamps of the .ino file and the .hex file. If .hex is later than .ino just upload w/o compiling.
Additionally, if options are a concern, then when options change just delete the .hex file.
dlchambers:
All the IDE really needs to do is compare the timestamps of the .ino file and the .hex file. If .hex is later than .ino just upload w/o compiling.
To do that it would have to keep the .hex file for every compiled sketch. The default is to delete the intermediate files after the upload/verify. (You can change that default in preferences.txt. export.delete_target_folder=false or preproc.save_build_files=true or something like that.)
Something like this could theoretically be done but it would take a good deal of work and is probably not worth it for the small number of people who are frequently uploading the same very large sketch.
A work-around is to change the options to NOT delete intermediate files, then use avrdude directly to re-upload your .HEX file.
Another work-around is to skip the Arduino IDE and use makefiles to directly drive the compiler and uploader.
I accept your reasoning.
Thanks for the intelligent discussion.
-Dave
dlchambers:
Previous versions of Arduino knew it didn't need re-compilation for upload... why does v1.0 insist on performing these unnecessary re-compiles?
This behavior isn't new to 1.0. As I remember it, all previous versions have behaved this way. In fact, I just double-checked with 0022 and "verify then upload" results in being compiled twice.
Compiling libraries each time was added in version 0017 where the release notes say:
Earlier, in 0008, they tried recompiling all libraries when changing boards, which caused that process to be slow:
Back before 0005 it sometimes didn't re-build the sketch when it should:
Fixed bug that sometimes caused uploading of old versions of a sketch.
I don't accept this reasoning at all. No other chip compiler that I know of works this way and I have been programming chips since 1971. It is two lines of code to check if the user prefers recompile. and only 10-15 lines of code to see if changes have been made to the environment since the last compile. Even the Arduino compiler worked this way in the past. Hence, the problem is clearly with the programmers of the Arduino environment. If you only save developers 15 seconds, that is significant. But for many, as has been pointed out repeatedly here, many computers take up to 60 seconds to compile. Adding an "upload without recompile" button would take seconds to create. So, why not wear the white hat and save a hundred thousand programming people a few million hours. Thank you.
The Arduino IDE was designed for ease of use by artists, tinkerers, and people inexperienced with embedded programming. Professional using AVR microcontrollers should use AVR Studio to get the versatility and control they may need some day.
Dude, why did you bump a FOUR YEAR OLD THREAD just to declare that you don't like how Arduino does things?
Besides, it now does do an incremental compile so the time for compile argument is less compelling.
Arduino (at least in principle - though I find this hard to reconcile with their reaction to the serial bug in 1.6.8 which is still screwing up newbies - they shoulda pulled the release on day 1) is meant to make it easy for newbies to get started. So it protects you from clicking upload without compiling the code, since uploading something that doesn't match the code you're looking at in the window you clicked "upload" on is not what users are likely to expect... If you want to upload the code through other mechanisms, 1.6.4 and later have an "export compiled binary" to generate a .hex you can upload yourself.
I think OP has a point. I sometimes struggle with my ESP8266:s and need several tries before I manage to upload the binary to the chip. At every try I need to wait the 15 seconds for the compile.
I would appreciate a menu item like "Upload last Compiled bin again".
(can be hidden and enabled in the config-file to not scare away beginners from Arduino)
IDE 1.6.6 has a line upload.verify=true in the file preferences.txt
I don't have an Arduino with me so can't test, but maybe setting it to false stops the verify step. Will have to try in the weekend.
sterretje:
IDE 1.6.6 has a line upload.verify=true in the file preferences.txt
That is the same as File > Preferences > Verify code after upload. That option stopped having any effect from 1.5.? - 1.6.8. It was fixed in 1.6.9 for the Arduino AVR Boards(Implement Do-Not-Verify-After-Upload preference for Serial Uploads by gh-megabit · Pull Request #4873 · arduino/Arduino · GitHub) but I think it still has no effect on the ESP8266 Arduino core. A search of esp8266 v2.3.0's platform txt shows no ocurrences of "upload.verify".
I believe what this option does is to check the uploaded code on the board to be sure that it was not corrupted in the upload process, rather than Arduino's use of "verify" in lieu of the word "compile". I've never once seen the verification fail so I've turned it off. Of course the one time the code is corrupted during upload I'll probably spend more time than I've saved by turning it off trying to find the non-existent bug in my program.
Sorry, there might be a misunderstanding. It is not about the verify thing. The concern is that you can not upload the same compile several times. Every time the Compile runs again. Some sketches take long time to compile, so what I ask for is a possibility to upload the last compiled bin several times.
(Verify is (or used to be, I assume it means the same as when I was young) a function that downloads the code from the chip (e.g. Arduino board) directly after it has uploaded it. By doing so it verifies that the upload went OK.)
@pert, I've actually seen a cheap Arduino-clone make faulty calculations. But after I uploaded a modified sketch with a trap that would detect bad calculations, it worked flawlessly. So now I don't know if it is me or the CPU...
while this is an old topic, its still relevant because the bugbear of recompiling every time has not been addressed, also I have OTA on my ESP devices but its very unreliable and topic of multiple threads
Is it so hard to add a few lines of code to the IDE to force a refresh of OTA device addresses and fix the annoyance of constantly recompiling the same code before upload?
While it was originally aimed at artists and beginners, clearly there are many of us using this IDE who are skilled developers, how about giving us some power user modes that could be enabled by the user allowing us more fine grained control of the IDE
Have you assesed the PRO / CLI version ?
Or considered moving to a more professional app ?
The regular IDE is meant to be simple and thats it.
As a skilled developer it would probably be in your remit to make the required changes yourself.
peterdunne:
while this is an old topic, its still relevant because the bugbear of recompiling every time has not been addressed, also I have OTA on my ESP devices but its very unreliable and topic of multiple threads
I also have a second problem, my devices are not always showing up in the IDE (because of my freaking router filtering out their broadcasts).
A nice work-around for both problems is to export the compiled as a bin-file (Ctrl-Alt-S).
And in the project folder, I have put my drop_bin_here_to_upload.bat-file:
@echo off
rem kaffe 23f5gx7SEFQqqfcd 192.168.1.156
rem halltak odHN4rwerwrs14fG 192.168.1.161
c:
cd "\Users\Dick\AppData\Local\Arduino15\packages\esp8266\hardware\esp8266\2.7.1\tools\"
python.exe "espota.py" -i 192.168.1.156 -f %1 --auth=23f5gx7SEFQqqfcd
pause
Just press Ctrl-k to open the folder and drop the newly compiled bin-file on this bat-file to start upload.
If it fails, just try again. If you are running on something else but Windows, I am of no help.
If any bat-master sees this and finds that this file is lacking bells and whistles, please help me update it.
/Dick
Some routers split the subnet into two or more parts (usually for the WiFi bands)
This can prevent some aspects working as expected.
A better option is to use the reserved IP's for devices in the router and on the device so that they are locked to the IP and the router will always play nice.