Is there a possibility of running a test to show that the code already uploaded and running in my Arduino is the same as the one I have in editor? In other words: is it possible to compile a scetch and compare the resulted hex(?) code with the one already in Arduino to find out if the version of my sketch is the same that I have on hand in my editor?
pekka
Is there a possibility of running a test to show that the code already uploaded and running in my Arduino is the same as the one I have in editor?
Sure. Just upload the code. Then, you'll know.
You can get the hex file from the Arduino. You can compare than to the hex code created when you again compile the code in the IDE. But, what is uploaded to the board is like a fully decorated wedding cake that you want to compare to the stuff you just brought home from the store, that you will use to make the cake. No way to unbake that cake.
pekka:
In other words: is it possible to compile a scetch and compare the resulted hex(?) code with the one already in Arduino to find out if the version of my sketch is the same that I have on hand in my editor?
You could do that by downloading the hex code from the Arduino - but it would not be a lot of use IMHO because, while you would know they are different you would not know in what way they are different.
It would be much better (IMHO) to include a message in setup(), perhaps something like
Serial.println("Source code is in /myfiles/mytest/mytest.ino");
which you can read when the Arduino starts.
For my own programming I have written a short Python program that automatically puts a message like the above into the program and then archives a copy of the source code with the time and date. It also includes in the archive any libraries that are used.
...R
Thanks for the replies. I'm not trying to sort of reverse engineer C++ code from HEX, just trying to verify it is the same or not, irrespective of what is different.
Long ago I've done a fair amount of PIC coding in assembler. It was possible to get the checksum of code within the PIC and the checksum of the HEX file I had in the "burner", and verify they are the same. That is all I'm after.
So, I trust Arduino IDE is not giving me the checksum of the HEX file inside the AVR, nor the checksum of the code I have in the Arduino IDE, and let verify before uploading the code in IDE.
If this verification is possible using other tools, then can you show me the right tools, please?
In future I think I must start using the Serial.println() idea. Good plan!
pekka
pekka:
to get the checksum of code within the PIC and the checksum of the HEX file I had in the "burner", and verify they are the same. That is all I'm after.
The IDE verifies that the uploaded code is correct after it completes the upload.
...R
The IDE can give you the hex it made after a compile. And with just AVRdude (what the IDE uses to upload) you can download the HEX from the Arduino. And you can indeed compare the two.
But keep in mind, minor changes in C may result in pretty large changes in the hex.
My luck is out. AVRdude needs the ISP interface. My project's housing did not allow soldering the ISP pins on top of the Nano, so I'm getting nowhere.
As an added bonus I did not know/recall that Arduino IDE by default quietly and without any warning saves the modified source when verifying or uploading, so the file on disk got silently damaged while I thought I was safely fooling around testing without saving my trials.
Luckily I have one old version that I mailed away to fall back, with no guarantee that it actually is the version I have in my reasonably well working Nano device.
I wonder what is the advantage of saving trial edits to a file without any warning whatsoever?
pekka
pekka:
My luck is out. AVRdude needs the ISP interface. My project's housing did not allow soldering the ISP pins on top of the Nano, so I'm getting nowhere.
Maybe you could use angled header pins or connect the header pins to the PCB with flexible wire.?
As an added bonus I did not know/recall that Arduino IDE by default quietly and without any warning saves the modified source when verifying or uploading, so the file on disk got silently damaged while I thought I was safely fooling around testing without saving my trials.
AFAIK every editor must save the source code (i.e, over-write the file) before submitting the file to the compiler. It is up to the programmer to make backup copies of his/her files.
...R
AVRdude needs the ISP interface.
No it doesn't. It talks to the bootloader just fine.
Robin2:
AFAIK every editor must save the source code (i.e, over-write the file) before submitting the file to the compiler. It is up to the programmer to make backup copies of his/her files....R
It needs to save the file but it does not need to write over your previous version without asking.
In version 1.8.2 of the IDE, and maybe earlier, there is an option to "Save when verifying or uploading" which can be turned off.
I wonder what is the advantage of saving trial edits to a file without any warning whatsoever?
Thematic Compatibility with nearly every other IDE in existence (most of which will only compile the "saved" versions), and the comfort that the saved version matches the code in the chip.
The Arduino IDE used to do it the other way around (which is why it is still an option), and there were quite a few very vocal complaints from people who had gotten their code working "just right" and somehow managed to exit without saving the final version, even though they had the code they wanted in the chip...
there were quite a few very vocal complaints from people who had gotten their code working "just right" and somehow managed to exit without saving the final version,
On the other hand, when the IDE wrote a non working version over one that was working (after I "improved" it) without warning me, I was bl**dy furious
There is of course a difference between not asking to save a changed sketch when exiting and saving a sketch when you don't hit save (but verify or upload).
I would say both are kind of annoying...
UKHeliBob:
On the other hand, when the IDE wrote a non working version over one that was working (after I "improved" it) without warning me, I was bl**dy furious
The smart answer to that "problem", used by EVERY professional programmer, is version control. When you get something that works, check it in, and you'll ALWAYS be able to revert to that version, even after making further modifications. Download a copy of Git, and use it.
Regards,
Ray L.
RayLivingston:
The smart answer to that "problem", used by EVERY professional programmer, is version control. When you get something that works, check it in, and you'll ALWAYS be able to revert to that version, even after making further modifications. Download a copy of Git, and use it.Regards,
Ray L.
That is, indeed, the smart answer, but what if I forget to check it in ? I really don't want the IDE overwriting a file without warning. By all means have that as an option but why that is the default escapes me.
I had the same problem. I had to figure a simple solution.
We have different units in the field, with different versions.
Its called "Version Control". Every time I am about to change ANYTHING in the software - I take a copy and increment the version number, in the name.
I then increment the "version number" variable in the code. I send this to a monitor (serial.print kind of thing) in the setup part of the program.
The result is that , whatever the version, it is printed out , when I plug the laptop in - I know immediately the code that's in it. ( robot_software_version3).
I believe the trick is to NEVER make changes to working software - make changes to a copy, that has an incremented version number.
I learnt the hard way that having embedded software, in the field, with associated hardware, is deadly, unless you have version control. Well, maybe not deadly, but you know what I mean.