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 firstname.lastname@example.org. 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.
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.
If you’re reading this, you should be reading that: Ringo Reflash factory firmware
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
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
Because i want to change some thinks in firmware is there any guide with steps how to compile it ? I have downloaded the vs code but i am confused how to do it.