AVR_Code src edits that allow the firmware to be compiled using a Makefile

[brentfpage]

These edits to the firmware code are described in #369 . They are required to make the Makefile mentioned there functional, both on mac and linux in my experience. All of the changes are very minor and do not make any functional difference to the firmware. The main purpose of this PR would be to enable #405 .

[mi-hol]

@brentfpage from a non-technical standpoint (I lack C programmer skills!) it looks minor

@mmehari @turboencabulator what is your view?

[turboencabulator]

Looks good to me assuming it all builds correctly. (I haven't yet set up an environment to build the firmware.) One minor nitpick.

[mi-hol]

Looks good to me assuming it all builds correctly. (I haven't yet set up an environment to build the firmware.)

@turboencabulator
Since my PR #379 each PR builds all artefacts automatically.
In other words setting up your own environment to verify a PR is no longer needed!
Each PR has now (at the bottom) the section "Checks" like in below image and each artefact can be downloaded from these links for testing before is gets merged into master branch

For this PR all checks passed.

An example of another PR with errors is this

[turboencabulator]

@turboencabulator Since my PR #379 each PR builds all artefacts automatically. In other words setting up your own environment to verify a PR is no longer needed!

True, but we don't (yet) have a build for the firmware, which is what this PR touches. Hence my comment.

[mi-hol]

True, but we don't (yet) have a build for the firmware, which is what this PR touches

Apologize, you are absolutely right

[mi-hol]

Looks good to me assuming it all builds correctly. (I haven't yet set up an environment to build the firmware.)

@brentfpage wouldn't running the avr build workflow from #405 in your fork and matching branch give Kyle access to the new firmware?

[mi-hol]

@brentfpage in addition I'd believe the changes in PR #405 will need to be include into this PR.

Reasoning:

Both changes depend on each other. In case one change gets reverted it will cause a failure for the whole project, in other words the currently 2 separated changes can not be applied in independence.

[brentfpage]

@brentfpage in addition I'd believe the changes in PR #405 will need to be include into this PR.
Reasoning:

Both changes depend on each other. In case one change gets reverted it will cause a failure for the whole project, in other words the currently 2 separated changes can not be applied in independence.

I don't think that this PR depends on #405 . By "failure", do you mean that there would be no way to compile the firmware? I think that if the slightly modified AVR_Code/.../src in this PR were loaded in Atmel/Microchip Studio (where I think the firmware was originally developed), it would compile just fine.

[brentfpage]

Looks good to me assuming it all builds correctly. (I haven't yet set up an environment to build the firmware.)

@brentfpage wouldn't running the avr build workflow from #405 in your fork and matching branch give Kyle access to the new firmware?

Compiled .hex products for this PR's current version of the firmware are located here. I just tested labrafirm_0007_02.hex and everything appeared nominal.

[turboencabulator]

@mi-hol This PR is just fixing warnings/errors with some compilers that might be more strict. It is independent of the workflow.

Ship it!

[mi-hol]

@turboencabulator @brentfpage Thank you so much

[brentfpage]

@mi-hol Thanks for helping push this idea forward. I'm enjoying becoming familiar with some new areas of development.

[mi-hol]

@brentfpage I appreciate that you accept new challenges very much!
Please apologize in case I'm too pushy sometimes, don't take it personally and just push back :)