fix(d1l): implement proper RADIO_DRIVER_AVAILABLE guards for target f… #41
Loading…
Reference in a new issue
No description provided.
Delete branch "feature/d1l-radio-driver-proper-guards"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
…iles
This fix properly implements Option 1 (unguarded globals, guarded initialization) using the RADIO_DRIVER_AVAILABLE flag that is now standard in the nightly branch.
Changes to target.h:
Changes to target.cpp:
Changes to platformio.ini:
Result:
✓ Repeater builds get full radio functionality
✓ Companion target.cpp compiles successfully without radio hardware ✓ Global radio_driver variable always available to satisfy linker ✓ Radio initialization only runs when RADIO_DRIVER_AVAILABLE is defined
Note: Companion example code (MyMesh.cpp, UITask.cpp) and repeater MyMesh.cpp have separate pre-existing issues that should be addressed in dedicated PRs.
🤖 Generated with Claude Code
Description
Type of Change
Related Issues
Testing Performed
Hardware Tested
Code Quality Checklist
Breaking Changes
Screenshots/Logs
Additional Notes
Summary of Changes
Hello @okapteinis, I'm Gemini Code Assist1! 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 refines the radio driver integration for the d1l target, specifically addressing how radio functionality is enabled and initialized. It introduces a standardized RADIO_DRIVER_AVAILABLE flag to guard radio-specific code, ensuring that builds without radio hardware compile successfully while full radio functionality is available for enabled configurations. This change also standardizes the LORA_TX_POWER definition and simplifies the global radio variable declaration.
Highlights
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./gemini review/gemini summary/gemini helpCustomization
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. ↩︎
Code Review
This pull request effectively implements conditional compilation for radio features using the
RADIO_DRIVER_AVAILABLEflag. The change to make theradio_driverglobal variable always visible to the linker is a solid approach to prevent build issues across different configurations. I have a couple of suggestions to improve code consistency and prevent a potential compilation error.@ -6,3 +5,4 @@// Provide default LORA_TX_POWER for builds that don't define it#ifndef LORA_TX_POWER#define LORA_TX_POWER 20#endifThis default definition for
LORA_TX_POWERis also present intarget.h. Since this file includestarget.h, this block is redundant. To avoid duplication and keep configuration in a single, authoritative place (the header), it would be best to remove this block from the.cppfile.This is a great change to make
radio_driveralways available to the linker. Applying this same principle of unconditional declaration for components that are always needed, the declaration ofradio_init()(currently on line 54) should also be moved out of its#if RADIO_DRIVER_AVAILABLEguard. The function's implementation intarget.cppnow contains non-radio initialization logic (like for clocks) and appears to be designed for unconditional execution. Making its declaration unconditional would prevent potential compilation errors in radio-disabled builds.