Skip to content

Conversation

@brentfpage
Copy link
Contributor

(Following up on some of the discussion in #381.)
This PR:

  • adds a workflow (avr.yml) for the firmware
  • makes edits to continuous.yml:
    • adds a firmware compilation job
    • adds support for the mac build scheme described in the bullet below
  • revises mac.yml so that:
    • when mac.yml is called by continuous.yml, the firmware .hex asset produced by continuous.yml is packaged into the mac desktop interface
    • when mac.yml is called in some other context, the firmware .hex asset produced by the most recent call to continuous.yml is packaged into the desktop interface

The versioning is centralized, but not automatic. Namely, the current version of the firmware has to be set in a repository-wide variable, AVR_VER, under (repo home)->settings->secrets+variables->actions->variables->(repository variables). In the fork, AVR_VER=0x0007. At compile time, this variable gets injected:

  • into AVR_Code as the macro FIRMWARE_VERSION_ID, which previously was defined in AVR_Code/globals.h
  • into the desktop interface as the macro EXPECTED_FIRMWARE_VERSION, which previously was defined in Desktop_Interface/genericusbdriver.h

It would be nicer to have AVR_VER defined in some location like continuous.yml instead, but it needs to be available to mac.yml when that workflow is called individually. I don't know of any other place to define AVR_VER where it would be available to both workflows.

Also, the inclusion of the version number in the .hex file names has been retained, so they are, e.g., labrafirm_0007_0{1 or 2}.hex. To me, this is worthwhile because then the firmware that's packaged into a given release can be very easily determined.

If we decide to go forward with this approach, extending it to encompass the android, linux, and windows builds I think would be straightforward. Also, a prerequisite for merging would be #404 .

…; also removed hard-coded firmware version macros in the Desktop Interface and the firmware
@brentfpage brentfpage marked this pull request as draft January 30, 2026 08:13
@brentfpage
Copy link
Contributor Author

Copying from a previous draft of this PR:


Posted by @mi-hol

@brentfpage I like the approach documented above and would approve it. With the number of changes a real review seems impossible though.

Lets see how other maintainers react.

The is only a minor nit pick

Namely, the current version of the firmware has to be set in a repository-wide variable, AVR_VER

I'd suggest to change name of variable from AVR_VER to AVR_FIRMWARE_VERSION so its purpose is completely self explanatory

@brentfpage brentfpage changed the title Workflow for avr build (ver. b) Workflow for avr build Jan 31, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant