Custom rusEFI firmware for your custom board¶

If you have developed a custom board, at some point custom firmware will be needed for the best user experience around connector mapping.

Only looking to develop a custom board? See https://github.com/rusefi/hellen-example and https://github.com/rusefi/uaefi-adapter-template

🟢No more fragile local compilation - these days GitHub compiles it for you, and you download the resulting binaries!🟢

Where Are the Binaries?¶

See the Actions pane on your fork, similar to https://github.com/rusefi/fw-custom-example/actions click a recent "Create Board Firmware" workflow run and see the artifacts near the bottom of the page!

OK I am Onboard¶

https://github.com/rusefi/fw-custom-example is an example of a custom rusEFI firmware repository. Just fork it, edit meta-info.env with the name of your board, and let GitHub Actions do the rest!

https://github.com/rusefi/fw-custom-paralela and https://github.com/rusefi/fw-custom-core8/ are the best examples as of right now. https://github.com/rusefi/rusefi/tree/master/firmware/config/boards should be another source of inspiration.

Update rusEFI Reference¶

Happens daily.

Alternatively open "Actions" in your repo, similar to https://github.com/rusefi/fw-custom-example/actions/workflows/update-rusefi-reference.yaml, and click "Run Workflow"->"Run Workflow"

To stop it from happening daily, you would have to remove two lines from .github/workflows/build-firmware.yaml - the ones with cron and schedule.

Default Board Configuration¶

Adjust setBoardDefaultConfiguration@board_configuration.cpp method, see other boards for setBoardDefaultConfiguration method examples.

Rare Advanced Scenario¶

If you have a more complex situation, with several different board variants you need to build, you can still achieve this with one repo.
If, for example, your variants only need different compile flags, having multiple meta-info files within the same repository would be a good way to achieve it.
For example:

• meta-info-brainboard.env
• meta-info-brainboard-debug.env

Now, in .github/workflows/build-firmware.yaml, you need a matrix to run the build firmware action for two different targets. It should look something like this:

name: Create Board Firmware

on:
  push:

jobs:
  build:
    runs-on: ubuntu-latest
    strategy:
      matrix:
        meta-info:
        - meta-info-brainboard.env
        - meta-info-brainboard-debug.env

    steps:
    - uses: ./ext/rusefi/.github/workflows/custom-board-build
      with:
        meta-info: ${{matrix.meta-info}}
        MY_REPO_PAT: ${{secrets.MY_REPO_PAT}}
        RUSEFI_ONLINE_FTP_USER: ${{secrets.RUSEFI_ONLINE_FTP_USER}}
        RUSEFI_ONLINE_FTP_PASS: ${{secrets.RUSEFI_ONLINE_FTP_PASS}}
        RUSEFI_FTP_SERVER: ${{secrets.RUSEFI_FTP_SERVER}}
        RUSEFI_SSH_SERVER: ${{secrets.RUSEFI_SSH_SERVER}}
        RUSEFI_SSH_USER: ${{secrets.RUSEFI_SSH_USER}}
        RUSEFI_SSH_PASS: ${{secrets.RUSEFI_SSH_PASS}}
        ADDITIONAL_ENV: ${{secrets.ADDITIONAL_ENV}}

If you want to have several different boards in the same repo, you should put them in different sub-directories, so they can have their own board.mk, board_configuration.cpp, and prepend.txt.

There is also a rusefi-dir option you can use if you want to put your rusefi submodule somewhere other than ext/rusefi. You will also need to change the path in the uses: field.

FAQ¶

Q: I get "exti index already used" error?¶

A: stm32 has a limitation: you can only have 16 digital inputs. Also each input has to be on a pin with unique numeric part: for example, you can have digital input on pins PA1 PB2 PC3 but you cannot have PA1 and PB1 since those are both "something-1" pins.

Q: How do I have nice pin names?¶

A: see https://github.com/rusefi/fw-custom-example/blob/main/connectors/readme.md