Keyboard Shortcuts
Likes
Search
Which branch to use to compile the same firmware as Erik is releasing?
I have managed to get the source code to compile in a Windows 10 environment.
I thought that the "V4.3" branch was the one to use, but seeing an older version displayed in the CONFIG->VERSION screen. At this time, not planning any changes to the source code, just trying to get the firmware build environment setup properly. Lane VE7IHL |
On Wed, Dec 14, 2022 at 03:46 AM, Lane Wilson wrote:
I have managed to get the source code to compile in a Windows 10 environment.Hi, Lane, The project uses built-in C preprocessor directives for conditional compilation when built from the main branch. Would you, please, share some details of Your proper toolchain setup under Windows? I am also interested to try it (just for learning purposes, no modifications ). And would like to setup Windows environment. Alex |
Erik,
The build instructions will build a version "v0.1-602-gb87733e" based on the deprecated "master" branch.
The most important info to be on track with your development is to type git checkout V4.3?before running make?(to build tinySA) or TARGET=F303 make?(to build tinySA4 aka. Ultra. Funny fact - at the moment you can set TARGET to every nonempty string to get the Ultra, also TARGET=F072 builds the Ultra version, see also my ). BUT this will give a different version name "v1.2-658-g65f6118" (the g65f6118 correctly refers to the last commit on branch V4.3, but the v1.2-656 is out of order). See also?.? My Q'n'D fix is to do this once after cloning: ? ? git tag -d v1.3
? ? git tag -a -m v1.3 v1.3 12a96bb This matches your versioning and gives?v1.3-558-g65f6118 (at the time of my writing, you haven't pushed your latest commit 9ebab38, which is the base for??- have you?). EDIT: I saw your two new commits, now GitHub is in front of your download page at version?v1.3-560-g88121a2. (real work in progress) I hope this sheds some light on the mysteries of creating your own versions. Martin |
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? |
Hi Lane,
toggle quoted message
Show quoted text
just some thought and ideas as a starting point: On Thu, Dec 15, 2022 at 01:59 AM, Lane Wilson wrote: I am trying to understand this, what is the best method to get the V4.3 branch to match Erik's current (latest) code?I do all the git / GitHub stuff on the command line, the easy cold-start is: git clone? cd tinySA git checkout V4.3 git pull git submodule update --init --recursive now you're almost ready to start, this would build the latest firmware, but with a wrong version number - dunno why, neither does Erik. The Makefile uses the command "git describe" to get a version number like "v1.3-nnn-gxxxxxxx", where "v1.3" is the latest tag, "nnn" is the number of commits since this tag and "xxxxxxx" is the unique git commit hash. Without my hack it gives a wrong nnn, but xxxxxxx is correct, but the short version on the left margin is "1.3nnn". My fix is (do this once) git tag -d v1.3 git tag -a -m v1.3 v1.3 12a96bb Now also the nnn is in sync with Erik. For tinySA you can type:? make For tinySA Ultra type: TARGET=F303 make This should produce the *.bin *.hex and *.elf in directory build. Your toolchain 11.2 is quite new, I use 8.x and Erik's builds are still on 7.x, so it should work without an issue. Do you need to add a tag that points to the latest commit hash? (g1da836e) ?No, but with every new version that Erik puts on GitHub you should do a new make clean git pull and you can start again. If you want to make your own changes etc. you should create a new branch with git checkout -b MyNewFeature and you will be already on your new branch. Maybe all this can be done also with TortoiseGit, I never used it - I'm an old guy who is used to the command line. I do all my daily work on Linux (Debian stable) and have no Windows PC at home, so one or the other differences may exist. But the Makefile should work also for Windows, because Erik's development setup is also Win. If you need a *.dfu version of the FW you can look at my tinySA development branch on GitHub?https://github.com/Ho-Ro/tinySA/tree/Ho-Ro_devel , it is currently not in sync with Erik, but the Makefile builds also a *.dfu in addition to *.bin. *.hex and *.elf I provide the sourcecode fot hex2dfu which compiles on windows if you have the gcc in your path. Erik has also a precompiled binary: Maybe my and his version are a little different in syntax, but? Erik's version:
My version:HEX2DFU tinySA.hex -out tinySA.dfu hex2dfu -i tinySA.hex -o tinySA.dfu My favorite for firmware update is dfu-util, Erik provides a standalone windows binary: dfu-util -d 0483:df11 -a 0 -s 0x08000000:leave -D tinySA.bin This program uses libusb for access, so you need to create/load a driver with the tool Zadig, usage is quite easy, google is your friend. Maybe a windows hacker can also provide a signed *.inf file for the dfu-util access, I got this from some helpful guys for one of my other projects, that is a native Linux program but also compiles and runs on MacOS and Windows: As I'm currently on the road I have no access to my development system, so the git commands above are not tested but typed from my memory. I will review my text and together with your findings we can possibly put a simple tinySA-hacker-howto either here or on GitHub. What is the easiest way to find out where (and which branch) the latest code is ?The development branch is currently "V4.3" since quite a long time, unfortunately Erik's default branch is still on "master". So you should always look at? Happy hacking Martin |
On Wed, Dec 14, 2022 at 08:24 PM, Lane Wilson wrote:
Hopefully this explains a bit of what I have done, and what I am doing.Thanks a lot, Lane, for taking Your time to explain all this stuff in detail! While it seems a bit too complicated for me at the moment (the learning curve is too steep), but I think it might be a good idea to add all the explanations provided here by You & Ho-Ro to a separate TinySA Wiki page (or elsewhere) ) With best regards, Alex |
Martin,
Following your instructions I believe I have successfully compiled the latest tinySA4 firmware binary (as of today: Dec 15/2022), loaded into the tinySA ULTRA and confirmed correct operation. Executed the Self test, then the Level Calibration, both passed. The version display screen is clear/clean with no artifacts. Here is what I see with my compiled version of firmware: (using 11.2.1 GCC compiler): CONFIG->VERSION: tinySA4_v1.3-564-g47a9cbc? ? ? ? ? ? ? ?(newer version just pulled form github....) Compiler: GCC 11.2.1 20220111 HW Version: V0.4.5.1(168)? ? ? ? ? ? ? ? ?(slightly different than Erik's version?) Here is what I see with Erik's v1.3-563 version of firmware: The version display screen has some artifacts (extra dots, etc.) CONFIG->VERSION: tinySA4_v1.3-563-g1da836e? ? ? ? ? ? ? ?(version downloaded from http://athome.kaashoek.com/tinySA4/DFU/) Compiler: GCC 7.2.1 20170904 HW Version: V0.4.5.1(167)? ? ? ? ? ? ? ? ?(slightly different than my compiled version?) Both firmware compiles/version appear to be working OK. If this makes sense to you, I will start a document that describes how to compile the tinySA/tinySA ULTRA firmware from the latest code obtained from Github. Regards Lane VE7IHL |
On Thu, Dec 15, 2022 at 10:01 AM, Lane Wilson wrote:
HW Version: V0.4.5.1(168)? ? ? ? ? ? ? ? ?(slightly different than Erik's version?)No, digits (168) mean ADC resistor measure, noise on reference voltage or resistor precision provide little difference in measure. Add different resistor on PCB allow say firmware this PCB version |
Martin + others. Please review my notes below for accuracy and completeness. I can update with further information as required. Compiling from source code (using Git) on Windows 10
git tag -d v1.3
With every new version that Erik puts on GitHub you should do a new:
The easiest way to find out where (and which branch) the latest code is? The development branch is currently "V4.3" since quite a long time, unfortunately Erik's default branch is still on "master". So, you should always look at: Firmware Compile Tools Required 1.)??? ARM GNU Tools 2.)??? MinGW tools Getting/Installing the ARM GNU Tools: Go to click on Download to download the ARM GNU toolchain installer. As of Dec 15, 2022, recommend using the 11.3Rel1 installer. Newer versions may work as well. Arm-gnu-toolchain-11.3.rel1-mingw-w64-i686-arm-none-eabi.exe Download the installer and run it installing the files into the default locations.
There does not appear to be a single/simple method of installing the MinGW tools. The MinGW tools are required to provide the ¡°make¡± tool used to build the tinySA firmware. There are multiple sources and ways to do this. Download and then using the ¡°mingw-get-setup.exe¡± tool from SourceForge. It will then download the next level installer allowing you to download the parts of the MinGW package you need. ?This is just one method, MinGW is contained within other software development tool too. Obtain WinGW Get Installer from SourceForge: ? Run the mingw-get-setup.exe to get MinGW installer: When running the MinGW installer, you only need the "minw32-base" package. Recommend that you install the MinGW files into a high-level folder on your PC such as: C:\MinGW ? See various tutorials: (There are lots) https://www.ics.uci.edu/~pattis/common/handouts/mingweclipse/mingw.html https://www.youtube.com/watch?v=sXW2VLrQ3Bs&ab_channel=ProgrammingKnowledge2 https://www.geeksforgeeks.org/installing-mingw-tools-for-c-c-and-changing-environment-variable/ https://www.youtube.com/watch?v=Zcy981HhGw0&ab_channel=SemicolonDotDev https://www.youtube.com/watch?v=dRxPUblx2SY&ab_channel=AnielMaharajh ? Last step is to run the Windows Environment variable tool: Windows->Settings->Advanced System Settings->Environment Variables. Using this tool, you will need to add to the PATH environment variable, either user or System variables, the path that you used when you installed the MinGW tools. The example above shows the path as C:\MinGW Run this command from the Mingw64 Git Bash shell: Make --version Ensure that it runs and displays the current version number of the make tool. If this does not work, then check the .bashrc file in your windows home folder (Typically look in C:\Users\<Your_Login_Name>) and make sure it contains this line: alias make=mingw32-make.exe ? |
On Fri, Dec 16, 2022 at 01:17 AM, Lane Wilson wrote:
Martin, can you help me understand why that tag that is created uses the tag commit/hash of 12a96bb ?Lane, The reason why I do this ugly hack is described in this issue:? You need to do it only once when you freshly cloned the repo. The hack does redefine the point from which the clones start counting. The version number, e.g. "tinySA4_v1.3-564-g47a9cbc"?is - as written earlier - main version (the tag, i.e. "v1.3"), followed by the number of commits done after this tag ("564"), followed by a "g" (denoting this is from git, maybe "s" means svn, "c" stands for cvs, etc.) and the hash of the commit ("47a9cbc"). Due to some magical circumstances Erik's local git tag setting is out of sync with his GitHub tags. I just counted backwards from one of Erik's provided versions until I reached commit number zero (this was commit/hash of 12a96bb) and set my new tag v1.3 exactly there. I imagine as soon as Erik sets the main version to v1.4 or v2.0 we'll be in sync again. @Erik what do you think about a version step? Martin |
On Thu, Dec 15, 2022 at 11:49 PM, Ho-Ro wrote:
Erik what do you think about a version step?I intend to bring the working branch back to main and will do a version step now the Ultra is released Can one of you list the commands I need to give to do this? Merging the V4.3 branch with main is not something I want to do so it should be something like a rename???? ? -- For more info on the tinySA go to https://tinysa.org/wiki/ |
On Fri, Dec 16, 2022 at 08:52 AM, Erik Kaashoek wrote:
Can one of you list the commands I need to give to do this?Erik, There are two possible options I just am thinking of. 1. Rename "V4.3" to "main" locally and remotely. ? ? Set "main" as default on GitHub (instead of currently "master"). ? ? Work on "main". Do not touch "master" anymore (or remove it). 2. Rebase "master" with "V4.3", i.e. apply all changes made to "V4.3" from beginning (when you branched "V4.3" from "master") 'til now. ? ? Work on the (now up-to-date "master"), leave V4.3 untouched (or remove it). I think 1. is easier and less error prone. I'm currently on a business trip and will review both in a fresh fork on my system when I get back on Sunday. Then I'll distribute the step-by-step instructions. Martin |