casainho said:
we are trying to do something that no one does: let the final user build a custom firmware.
Can you please clarify whether the goal is to
allow any person (including final users) to perform the build cycles to arrive at a working firmware, or whether you
require the person to do so.
The spirit of free software basically is limited to "all parts required to build the software are freely available" (where "free" can be equated with zero cost and sort of low entry barriers).
If you want to
require that every final user builds firmware, you will add quite a bit on top of the requirement of actually having access to an ST-Link V2 programmer, taking the pain to register with STMicroelectronics to download, and so on.
Anyway, I had a first quick peek in the middle of the night at one of the more recent branches. Some feedback:
I had difficulties seeing the relevant files, in the relevant places. I'd propose some rearranging of files (e.g. dedicated "docs", "src" directories, some dedicated directory dedicated to user customization etc), some .gitignore management, some
The build environment is challenged in a number of ways:
1.) quite a bit of Eclipse is leaking through; moving this away (or out) would clarify matters
2.) a copy of some make.exe (cygwin or mingw) is commited; this works, but is a bit awkward in light of GPL and updates
3.) the make files used for building on Linux and Windows diverge mostly because the Windows environment lacks tooling support, most likely in the form of cygwin plus https://stm8-binutils-gdb.sourceforge.io/
4.) it might be preferable to consistently use openocd (instead of going STM tools sometimes)
5.) the Windows build (with my sdcc) bitterly complains about some unmapped things, but still produces output; this does not instill confidence
6.) Linux build environment strips "useless" (ok, not, but then ...) sizable ELF sections to get the binary down in size; Windows does not (for lack of tooling - see above, cygwin etc)
Here is what I see as reasonable options to proceed:
1.) The owner(s) of the project declare(s) that this is designed to be Free Software, not "Final users must compile their own firmware". That is just a mission statement.
2.) Maximize alignment of the build environment across all supported build platforms; supported platforms could be Linux, Windows Subsystem for Linux (essentially Linux user land on Windows 10, https://msdn.microsoft.com/en-us/commandline/wsl/release_notes), Windows 10 (native), macOS
3.) Define an end user(!) firmware customization strategy - what are
meaningful values for an end user to configure? Battery protection - no? Wheel diameter / circumference - yes! I guess that from an 80/20 perspective, just a handful of custom builds would cover the vast majority of scenarios out in the wild - e.g. 26/28" wheels, 36/48V battery, 25 km/h limit/no limit. That's eight combination only for now. Establish continuous integration (CI) using travis-ci.org for all of that, offer the firmware binary for download immediately.
4.) Offer a ready-made, truly minimal virtual machine (based, e.g., on Alpine Linux) for download, to act as a deployable build environment (continuously composed and updated by CI, again). That would make it a 50 MB download (give or take) plus 100+ MB for installing VirtualBox (with admin privileges) as the only prerequisite.
