Compiling without the Arduino IDE

[Ancyker]

Is there any interest in being able to compile the firmware with a Makefile?

Pros

• Can compile without the Arduino tools, only needing avr-gcc.
• Faster compilation than Arduino IDE because the Makefile uses precompiled libs and Arduino core.
• Quick switching capability. Cart support can be compiled as if enabled and then only linked if actually enabled, allowing to quickly recompile the firmware to add support as it will only need to recompile Cart_Reader.ino.
• Normally, the IDE takes all the .ino source files and combines them into 1 large .cpp file. Compiling them individually provides a way to guess flash usage before linking.
• For the most part, this is the correct way to program in C++. The Arduino IDE's handholding is nice for newbies, but if you want to code outside of the Arduino environment, then you need to give it up eventually. Also, doing it this way uncovers and punishes a lot more bad coding practices.
• The IDE is known to be fairly annoying to use for large programs due to it being designed around only having a few files.
• Can still use the IDE, but need to try to be mindful of not breaking the Makefile method.

Cons

• Need to declare functions before using them, either inline or in the header file. This, of course, is how C++ normally works.
• Slightly harder for inexperienced users, mostly due to the above-mentioned reason.
• Perhaps the biggest con is lots of files which the Arduino IDE does not handle well:
  
  

Thoughts? I've played around with it a bit, and it's... interesting...

[gemarcano]

I am in favor, but partially it's because I'm fairly familiar with C++. If anything the way Arduino does things (making function prototypes for you and concat-ing everything) is alien to me.

Another Con of doing it the "C++ way" is that there's a chance that GCC 7 (because that's what the Arduino IDE ships with apparently) may miss some optimizations that it could do when inspecting the entire program as a single file (LTO back in GCC 7 was fine... but not great still, so it won't be able to fully make up for it). Unfortunately, with my own testing trying to use GCC 14 avr-gcc actually leads to an increase in both program-size and global storage size (which is a little weird), so upgrading GCC isn't a clear option for improving LTO performance.

However, I still think switching to a more "traditional" approach is better. If left to me I'd even throw in some OS (e.g. FreeRTOS), but that's probably one step too far for the community as a whole.

One software development plus of going through this conversion is that it'd force thinking more deeply about all of the inter-dependencies in the code. From a cursory read of a lot of modules, for example, there are some global variables that would be better served as local temporary stack variables that only exist for the duration of a short function, instead of forever. Also, the process of separating the code might make it easier to split the UI code from the model/control code.