Hi Alex, I will try to explain my setup.
First a bit of background:
I am a professional firmware developer for many decades. I have been using SVN (TortoiseSVN) for many years without any issues.
I am quite well versed in using SVN, but am new to Git. Just learning it now.
Wanting/Needing to use Git, I decided to try out TortoiseSVN () which being familiar with TortoiseSVN I knew would be an easy learning curve for me.
After installing TortoiseGit, It stated/complained that I still needed to install the actual Git command line tools. I downloaded and installed the "Git For Windows" () tools to get it going.
The Git for Windows tools provides a "Git BASH emulation" command line environment. My assumption was that it would also allow me to run the "make" tool which is required to build the tinySA firmware.
I had previously installed the "ARM GNU Toolchain 11.2-2022.02" on my windows computer. (See:?)
The ARM GNU Toolchain provide the GNU make tool (Built for i686-w64-mingw32), which was in my windows PATH, so when I executed: "make" in the tinySA folder (in the Git local repository on my PC), it compiled the tinySA code.
NOTE: There is a newer version of the ARM GNU Toolchain availbe, but I have not yet downloaded it.
I see there are some issues getting the same actual firmware source code as Erik is using, so I will look at Ho-Ro's instructions to see if I can resolve that issue.
My Goal at this time is to clean-up all the firmware C compilers warnings being issued during the compile process. Not to make any function changes.
Reason for this is that you can ignore them (most are not important), but one of the warnings could be significant, indicating a real firmware issue/bug.
In my previous firmware development roles, I would always examine each C compiler warning message, and attempt to adjust the source file so the warning is removed. (Or fix the problem that is actually there)
Should eventually end up with a tinySA firmware build that is completely C compiler warning free.
Then, if a new C compiler warning shows up (after new source code changes), then the new "issue/warning" can be dealt with right away.
This is a method of improving the overall quality of the firmware.
I'm hoping that when I did have source code changes made (as explained above) that Erik will be able to take them into the main Git repository.
Hopefully this explains a bit of what I have done, and what I am doing.
I am just learning Git, and how to compile the tinySA firmware, so I am NOT an expert in this area at all! (Read my notes above with that in mind)
Lane
VE7IHL?
