Hey Emil, thanks for the info. It took a while, but I figured it out.
Any idea why the firmware.bin sizes are still different? Is there a way to select different optimization levels for the VS Code C++ compiler (analogous to -O3 etc. for gnu c++)? Perhaps we are compiling with different optimization levels? Or maybe itās because we are using different versions of VS Code (Iām using 1.40.0)?
I tried compiling the binary with the newest releases and Iām getting the same-sized firmware binary.
Could you double check that you are indeed compiling with the latest releases?
Also, is the size difference significant, and could you point me to how could I reproduce compiling this firmware binary thatās not the same size?
Emil, the size difference is only significant in that making the binaries compare is the only true way to be sure Iām replicating your process exactly.
The way I made this is first I followed Robertās instructions in the third and fifth posts of this topic. Then I did all the steps I outlined in the 13th post of this topic. Then I replaced the 1.0.0 release of CircuitMess-Ringo with the new 1.0.1 release and repeated the steps in the 13th post. That gave me the firmware binary that is now 6688 bytes larger than your binary. Like I said above, perhaps Robert left out some details as to how I should set up VS Code; if there are any options I need to select like optimization level. I am also using version 1.40.0 of VS Code - perhaps you are using an earlier version and that could account for the difference, I donāt know.
Ok, Iāve succeeded in reproducing the problem.
Iāve followed the instructions provided in the thread on a fresh installation on a 2nd PC and yes, the compiled binary is indeed larger than expected.
Currently, I have no apparent answer as to why this is happening, but as far as I tested, the firmware seems just as functional as the original one.
If I had to make a guess it would probably be something about the compiler version or the environment that was used to compile the original binary.
I will probably look into this sometime in the future but in the end, it seems like just a harmless difference in compilation environments.
@frankprindle I hope this cleared up this misunderstanding concerning the compilation of the firmware.
Thatās great to know. Iām going to stop worrying about the size difference now that I know it even happens to you. Iām pretty confident I know how to get the release sources now. Maybe Iāll take a crack at getting rid of some or all of the 80 warnings; Iāve always found that ignored warnings are a bad idea.
Emil, I was able to take the source code for the 1.0.1 release and eliminate all 80 warnings so that it compiles cleanly. Many of those were simple unused variables, but 10 specific warnings turned out to be because of suspected coding errors. Anyway the changes are concentrated in 19 source files. Iāll send the annotated files to [email protected]. It seems to run just fine.
Okay, thanks for that.
This seems like a standalone issue so I would prefer to have it in a separate forum thread to avoid irrelevant posts in this thread.
Also, a better course of action might be to fork our repository on github and open a pull request for our library/firmware, whichever you edited.
I will go over the files youāve sent and will message you back via email.
I have opened pull requests to CircuitMess-Ringo-firmware and CircuitMess-Ringo that removes all warnings and fixes the bugs hidden among them.
Remember that:
Compiler warnings should always be taken seriously, since bugs will hide among them.
Has anybody tried to build it from the command line? Iām having some success, but am missing setup() and loop(). Those functions are defined in /home/nelson/ringo/CircuitMess-Ringo-firmware/src/main.cpp but that file isnāt getting included in the build.
The command line of which build environment? Arduino? VS Code? Something else?
Unix shell. Probably using platformio.
You got me there. I searched high and low through my Windows 10 machine running VS-Code with Platformio extension and couldnāt find hide-nor-hair of a Makefile. Yet I know the compiler options must be being set somewhere because in this compilation ācharā is unsigned which is NOT the default for g++. Do you have a Makefile, and if so where did you get it? Main.cpp is in the same directory as the rest of the firmware, so something would have to be intentionally NOT compiling it, while compiling everything else.
I know what I did wrong here. I did a git clone in ā¦/lib/MAKERphone, which put the files into CircuitMess-Ringo, whereas they should have gone directly into MAKERphone. Oops.
Looks like you found the answer to your question, Russ.
So now that itās workingā¦ whatās the secret command line to do a build?
In an attempt to answer my own question, I tired (from the top level Firmware directory):
C:\Users\Frank\.platformio\penv\Scripts\platformio.exe run --target clean
C:\Users\Frank\.platformio\penv\Scripts\platformio.exe run
But the generated firmware.bin file was different (and of a slightly different size) from the one which is generated by building from the VS Code GUI (Terminal/Run Taskā¦/PlatformIO: Build Firmware). I didnāt try to run it on the phone.
So I seem to have failed to find a command line that exactly duplicates what the GUI does. Enlighten me Russ 
Yes @RussNelson, weāre all eager to know! 
Thank you guys for being such a big part of the community! 
Yes, itās just following the combination of the āReflash factory firmwareā instructions and Frankās instructions then running platformio run. That builds the .bin file, then you program it into the phone using the esptool.py command.
I havenāt looked into why the executable is yet a third size: 1547424