Skip to content

Generate the core register set - #28

Merged
glopesdev merged 2 commits into
mainfrom
generate-core-registers
Aug 18, 2026
Merged

Generate the core register set#28
glopesdev merged 2 commits into
mainfrom
generate-core-registers

Conversation

@glopesdev

@glopesdev glopesdev commented Aug 18, 2026

Copy link
Copy Markdown
Contributor

harp.device.core is now a single generated file rather than generator output with hand-written modules around it. The register declarations have been generated since June, but the copy had gone stale, and it needed __init__.py to re-export the names and _register_map.py to declare the address map. The Python target now generates __all__ and REGISTER_MAP itself, so the generated file is installed verbatim as the package __init__.py and both hand-written modules are removed. This is also what makes from harp.device import core, behavior symmetric, since both become the same kind of artifact.

test_core_register_structural gets stronger as a result, since both sides now come from the same core metadata, where previously one came from the protocol file at v1.13.0 and the other from the generator copy. Payload layout is now compared for all 15 core registers rather than 14.

The published surface does not change

The differences against the previous copy are confined to the Any import, __all__, the blank-line spacing between documented members, and REGISTER_MAP arriving in the same file. Every register, enum member, mask and docstring is identical, so the module still publishes the same 24 names and the same 15 register address map, and it still declares no WHO_AM_I, so it stays outside DeviceModuleLike. The _register_map.py docstring teaching downstream packages to spread the map is already in the harp-device README.

The module docstring now comes from the metadata

Generated output carried no module docstring, so installing it verbatim would have dropped the one this package had. The Python target now generates a top-level description from the metadata as the module docstring, and the core metadata declares one. Such a key already validates against registers.json, which sets no additionalProperties: false at its root, and the pyharp schema model already ignores unknown top-level keys.

Registers now carries the top-level description that the generator object model has, and a module built at runtime and a generated package now report the same __doc__ for the same metadata.

harp.device.core is now the generated Python interface for the core
register metadata, installed verbatim as the package __init__.py,
replacing a stale copy of that output and the two modules that wrapped
it. The module docstring is generated from a description field in the
metadata.

The register set, enum members, masks and docstrings are unchanged, so
the module still publishes the same 24 names and the same 15 register
address map. Runtime emission is verified against the package itself
and against core.yml vendored from the generator, so the expected_core
copy and the common.yml fixture are both removed, and register layout
is now compared for every core register. Requires the matching Python
target change in harp-tech/generators.
@glopesdev
glopesdev requested a review from bruno-f-cruz August 18, 2026 10:46
@glopesdev glopesdev added the feature New planned feature label Aug 18, 2026
Registers gains a description field, matching the top-level property in
the generator object model, and create_device_module uses it as the
module docstring.
@glopesdev
glopesdev merged commit 276ac49 into main Aug 18, 2026
13 checks passed
@glopesdev
glopesdev deleted the generate-core-registers branch August 18, 2026 16:39
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

feature New planned feature

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant