Skip to content

Move hackrf_core.x driver instances to drivers.x (2/3)#1709

Merged
mossmann merged 1 commit into
greatscottgadgets:mainfrom
antoinevg:antoinevg/refactor-hackrf-core-drivers
Apr 24, 2026
Merged

Move hackrf_core.x driver instances to drivers.x (2/3)#1709
mossmann merged 1 commit into
greatscottgadgets:mainfrom
antoinevg:antoinevg/refactor-hackrf-core-drivers

Conversation

@antoinevg

@antoinevg antoinevg commented Mar 31, 2026

Copy link
Copy Markdown
Member

Depends on #1705


@antoinevg
antoinevg force-pushed the antoinevg/refactor-hackrf-core-drivers branch from 9de0e60 to d05de20 Compare March 31, 2026 09:34
@antoinevg
antoinevg marked this pull request as ready for review March 31, 2026 11:53
This was referenced Apr 2, 2026
@antoinevg
antoinevg force-pushed the antoinevg/refactor-hackrf-core-drivers branch from d05de20 to 7acb91f Compare April 2, 2026 07:39
@mossmann
mossmann self-requested a review April 2, 2026 15:14
@antoinevg
antoinevg force-pushed the antoinevg/refactor-hackrf-core-drivers branch 4 times, most recently from e570167 to 91c8646 Compare April 7, 2026 15:26
@antoinevg antoinevg changed the title Move hackrf_core.x driver instances to drivers.x Move hackrf_core.x driver instances to drivers.x (2/3) Apr 10, 2026
@antoinevg
antoinevg force-pushed the antoinevg/refactor-hackrf-core-drivers branch from 91c8646 to 20864c0 Compare April 10, 2026 07:55
@antoinevg
antoinevg marked this pull request as draft April 14, 2026 08:26
@antoinevg
antoinevg force-pushed the antoinevg/refactor-hackrf-core-drivers branch 3 times, most recently from 1c53970 to b93b219 Compare April 22, 2026 11:55
@antoinevg
antoinevg marked this pull request as ready for review April 22, 2026 12:59
@antoinevg
antoinevg marked this pull request as draft April 23, 2026 14:10
@antoinevg
antoinevg force-pushed the antoinevg/refactor-hackrf-core-drivers branch from b93b219 to 6d9622f Compare April 23, 2026 15:03
@antoinevg
antoinevg marked this pull request as ready for review April 23, 2026 15:12
@antoinevg
antoinevg force-pushed the antoinevg/refactor-hackrf-core-drivers branch from 6d9622f to adf83cb Compare April 24, 2026 07:17

@mossmann mossmann left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I wonder if these would be better in hackrf_usb.c or distributed through various source files instead of continuing to lump them together into a common .c file, but I'll let @martinling make that decision later if this doesn't work for his effort. I think this is fine for now.

@mossmann
mossmann merged commit 60f7ccf into greatscottgadgets:main Apr 24, 2026
50 checks passed
@martinling

martinling commented Apr 28, 2026

Copy link
Copy Markdown
Member

For integration into PortaPack firmware, the following bits of drivers.c are problematic:

radio

radio_t radio = {
        .sample_rate_cb = sample_rate_set,
};

The reason for the sample_rate_cb field is to allow different clock generator logic to be used - in particular the existing clock_manager.cpp implementation in the PortaPack firmware, which has extra features. Setting the callback here in drivers.c adds an unnecessary dependency on our own clock_gen.c, even if the sample_rate_cb is changed at runtime.

For this reason, I think the radio instance definition should be somewhere under firmware/hackrf_usb.

That said, I'm working on making it possible for our clock_gen.c to replace clock_manager.cpp entirely, which seems like a better way forward given all the precision improvements made there recently. so this is probably a temporary issue.

spi_flash

w25q80bv_driver_t spi_flash = {
        .bus = &spi_bus_ssp0,
        .target_init = w25q80bv_target_init,
};

This adds an unnecessary dependency on w25q80bv_target.c which won't be used in a PortaPack build, since the SPI flash is kept in SPIFI mode there and we access the SPI flash via the memory mapping.

Suggestion

I agreed with the decision to merge this, to advance the process of breaking up hackrf_core, but going forward, I think I'd be inclined to also break up drivers.c, and distribute the instances into the drivers themselves, e.g:

  • i2c0, i2c1 -> i2c_bus.c
  • ssp_config_max283x, max283x -> max283x.c
  • clock_gen -> clock_gen.c, or si5351.c
  • ...etc

We can't use the instances without their drivers, and it's hard to see a scenario where we'd want the drivers without their instances.

@antoinevg
antoinevg deleted the antoinevg/refactor-hackrf-core-drivers branch April 30, 2026 07:02
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.

3 participants