fix(d1l): expose radio globals and guard initialization for companion… #40

2025-12-26T23:00:08+02:00

okapteinis commented

2025-12-26 23:00:08 +02:00

(Migrated from github.com)

… builds

This fix implements "Option 1" to resolve build failures for the SenseCapIndicator-D1L_companion environment while maintaining repeater functionality.

Changes:

target.h: Use concrete type CustomSX1262Wrapper instead of WRAPPER_CLASS macro to ensure radio_driver declaration is always valid
target.cpp: Guard radio initialization logic with #ifdef WRAPPER_CLASS to skip hardware init in companion builds
target.cpp: Add default LORA_TX_POWER for CustomSX1262.h compilation compatibility

This ensures:
✓ Global radio variables are always visible to satisfy linker ✓ Radio hardware is only initialized when WRAPPER_CLASS is defined ✓ Repeater build succeeds with full radio functionality ✓ Companion target.cpp compiles successfully without radio hardware

Resolves GitHub Actions build failure in companion environment.

🤖 Generated with Claude Code

Description

Type of Change

Bug fix (non-breaking change fixing an issue)
New feature (non-breaking change adding functionality)
Breaking change (fix or feature causing existing functionality to change)
Documentation update
Hardware support addition
Performance improvement

Testing Performed

Builds successfully on affected platforms
Tested on physical hardware
Verified no new compiler warnings
Checked memory usage
Example applications still work
Documentation updated

Hardware Tested

Device:
Firmware variant:
Test results:

Code Quality Checklist

Follows existing code style
No dynamic memory allocation in inappropriate places
No reformatting of existing code
Added comments for non-obvious logic
Updated documentation
CHANGELOG.md updated if applicable

Breaking Changes

Screenshots/Logs

Additional Notes

… builds This fix implements "Option 1" to resolve build failures for the SenseCapIndicator-D1L_companion environment while maintaining repeater functionality. Changes: - target.h: Use concrete type CustomSX1262Wrapper instead of WRAPPER_CLASS macro to ensure radio_driver declaration is always valid - target.cpp: Guard radio initialization logic with #ifdef WRAPPER_CLASS to skip hardware init in companion builds - target.cpp: Add default LORA_TX_POWER for CustomSX1262.h compilation compatibility This ensures: ✓ Global radio variables are always visible to satisfy linker ✓ Radio hardware is only initialized when WRAPPER_CLASS is defined ✓ Repeater build succeeds with full radio functionality ✓ Companion target.cpp compiles successfully without radio hardware Resolves GitHub Actions build failure in companion environment. 🤖 Generated with [Claude Code](https://claude.com/claude-code) ## Description  ## Type of Change  - [ ] Bug fix (non-breaking change fixing an issue) - [ ] New feature (non-breaking change adding functionality) - [ ] Breaking change (fix or feature causing existing functionality to change) - [ ] Documentation update - [ ] Hardware support addition - [ ] Performance improvement ## Related Issues  ## Testing Performed  - [ ] Builds successfully on affected platforms - [ ] Tested on physical hardware - [ ] Verified no new compiler warnings - [ ] Checked memory usage - [ ] Example applications still work - [ ] Documentation updated ## Hardware Tested  - Device: - Firmware variant: - Test results: ## Code Quality Checklist - [ ] Follows existing code style - [ ] No dynamic memory allocation in inappropriate places - [ ] No reformatting of existing code - [ ] Added comments for non-obvious logic - [ ] Updated documentation - [ ] CHANGELOG.md updated if applicable ## Breaking Changes  ## Screenshots/Logs  ## Additional Notes

gemini-code-assist[bot] commented

2025-12-26 23:00:26 +02:00

(Migrated from github.com)

Summary of Changes

Hello @okapteinis, I'm Gemini Code Assist¹! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

This pull request addresses and resolves build failures in the SenseCapIndicator-D1L_companion environment by strategically modifying radio-related declarations and conditionally compiling hardware initialization. The primary goal is to enable successful compilation for companion builds without impacting the full radio functionality required by repeater builds.

Highlights

Build Fix for Companion Environment: Resolves GitHub Actions build failures specifically for the SenseCapIndicator-D1L_companion environment, ensuring successful compilation.
Conditional Radio Initialization: The radio hardware initialization logic in target.cpp is now guarded by #ifdef WRAPPER_CLASS, preventing initialization in companion builds where it's not needed.
Global Radio Variable Visibility: The radio_driver declaration in target.h was updated to use the concrete type CustomSX1262Wrapper instead of a macro, ensuring global radio variables are always visible to the linker.
LORA_TX_POWER Default: A default LORA_TX_POWER of 20 is now provided in target.cpp if not already defined, improving compilation compatibility for CustomSX1262.h.
Repeater Functionality Maintained: These changes ensure that the repeater build continues to succeed with full radio functionality, while allowing companion builds to compile without radio hardware.

Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point by creating a comment using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands on the current page.

Feature	Command	Description
Code Review	`/gemini review`	Performs a code review for the current pull request in its current state.
Pull Request Summary	`/gemini summary`	Provides a summary of the current pull request in its current state.
Comment	@gemini-code-assist	Responds in comments when explicitly tagged, both in pull request comments and review comments.
Help	`/gemini help`	Displays a list of available commands.

Customization

To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here.

You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.

Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩︎

## Summary of Changes Hello @okapteinis, I'm Gemini Code Assist[^1]! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed! This pull request addresses and resolves build failures in the `SenseCapIndicator-D1L_companion` environment by strategically modifying radio-related declarations and conditionally compiling hardware initialization. The primary goal is to enable successful compilation for companion builds without impacting the full radio functionality required by repeater builds. ### Highlights * **Build Fix for Companion Environment**: Resolves GitHub Actions build failures specifically for the `SenseCapIndicator-D1L_companion` environment, ensuring successful compilation. * **Conditional Radio Initialization**: The radio hardware initialization logic in `target.cpp` is now guarded by `#ifdef WRAPPER_CLASS`, preventing initialization in companion builds where it's not needed. * **Global Radio Variable Visibility**: The `radio_driver` declaration in `target.h` was updated to use the concrete type `CustomSX1262Wrapper` instead of a macro, ensuring global radio variables are always visible to the linker. * **LORA_TX_POWER Default**: A default `LORA_TX_POWER` of 20 is now provided in `target.cpp` if not already defined, improving compilation compatibility for `CustomSX1262.h`. * **Repeater Functionality Maintained**: These changes ensure that the repeater build continues to succeed with full radio functionality, while allowing companion builds to compile without radio hardware. <details> <summary>Using Gemini Code Assist</summary> The full guide for Gemini Code Assist can be found on our [documentation page](https://developers.google.com/gemini-code-assist/docs/review-github-code), here are some quick tips. Invoking Gemini You can request assistance from Gemini at any point by creating a comment using either `/gemini <command>` or `@gemini-code-assist <command>`. Below is a summary of the supported commands on the current page. Feature | Command | Description --- | --- | --- Code Review | `/gemini review` | Performs a code review for the current pull request in its current state. Pull Request Summary | `/gemini summary` | Provides a summary of the current pull request in its current state. Comment | @gemini-code-assist | Responds in comments when explicitly tagged, both in pull request comments and review comments. Help | `/gemini help` | Displays a list of available commands. Customization To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a `.gemini/` folder in the base of the repository. Detailed instructions can be found [here](https://developers.google.com/gemini-code-assist/docs/customize-gemini-behavior-github). Limitations & Feedback Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with :thumbsup: and :thumbsdown: on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up [here](https://google.qualtrics.com/jfe/form/SV_2cyuGuTWsEw84yG). You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the [Gemini Code Assist IDE Extension](https://cloud.google.com/products/gemini/code-assist). </details> [^1]: Review the [Privacy Notices](https://policies.google.com/privacy), [Generative AI Prohibited Use Policy](https://policies.google.com/terms/generative-ai/use-policy), [Terms of Service](https://policies.google.com/terms), and learn how to configure Gemini Code Assist in GitHub [here](https://developers.google.com/gemini-code-assist/docs/customize-gemini-behavior-github). Gemini can make mistakes, so double check it and [use code with caution](https://support.google.com/legal/answer/13505487).

gemini-code-assist[bot] (Migrated from github.com) reviewed

2025-12-26 23:01:47 +02:00

gemini-code-assist[bot] (Migrated from github.com) left a comment

Code Review

This pull request correctly addresses a build failure for the SenseCapIndicator-D1L_companion environment. The changes are well-targeted and effective. Guarding the radio initialization logic with #ifdef WRAPPER_CLASS correctly prevents hardware-specific code from being compiled for the companion build. Changing the extern declaration for radio_driver in target.h to use a concrete type is a clean solution to make the declaration valid across all build environments. The addition of a default LORA_TX_POWER also resolves a compilation dependency. I have one suggestion to improve the maintainability of the configuration.

## Code Review This pull request correctly addresses a build failure for the `SenseCapIndicator-D1L_companion` environment. The changes are well-targeted and effective. Guarding the radio initialization logic with `#ifdef WRAPPER_CLASS` correctly prevents hardware-specific code from being compiled for the companion build. Changing the `extern` declaration for `radio_driver` in `target.h` to use a concrete type is a clean solution to make the declaration valid across all build environments. The addition of a default `LORA_TX_POWER` also resolves a compilation dependency. I have one suggestion to improve the maintainability of the configuration.

variants/sensecap_indicator_d1l/target.cpp

					
				@ -4,0 +5,4 @@

				// Provide default LORA_TX_POWER for companion builds

				#ifndef LORA_TX_POWER

				#define LORA_TX_POWER 20

				#endif

While adding this default define here fixes the compilation issue, a cleaner approach for better maintainability is to manage this configuration within the build environment itself. This keeps all build-specific settings consolidated in one place.

Consider removing this block and instead adding the following to the build_flags for the SenseCapIndicator-D1L_companion environment in variants/sensecap_indicator_d1l/platformio.ini:

  -D LORA_TX_POWER=20

This would make the configuration more explicit and easier to manage alongside other environment-specific flags.

![medium](https://www.gstatic.com/codereviewagent/medium-priority.svg) While adding this default define here fixes the compilation issue, a cleaner approach for better maintainability is to manage this configuration within the build environment itself. This keeps all build-specific settings consolidated in one place. Consider removing this block and instead adding the following to the `build_flags` for the `SenseCapIndicator-D1L_companion` environment in `variants/sensecap_indicator_d1l/platformio.ini`: ```ini -D LORA_TX_POWER=20 ``` This would make the configuration more explicit and easier to manage alongside other environment-specific flags.

Sign in to join this conversation.

No reviewers

No labels

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference

ojars/MeshCore!40

Rows
Columns