You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I tried svd2nim for SVD file for RP2040 in https://github.com/raspberrypi/pico-sdk/blob/master/src/rp2040/hardware_regs/RP2040.svd
It generated rp2040.nim that has 66639 lines.
Importing large modules takes long time to compile.
If svd2nim divides device module, projects access only small numbers of peripherals can be compiled quickly.
How about to add a command line option that enables generating one module for one peripheral?
Where "device" gives you access to the device name, mpuPresent, fpuPresent, etc.
and each peripheral module would hold all the registers, their fields accessors and enum constants, etc.
One challenge will be where one peripheral is "derivedFrom" another. In those cases, I prefer the registers and register fields to be type-compatible, so I can copy values between them or put like registers into a list where they need to be the same type. To achieve this type-compatibility would require two modules importing the type from a common module. Not impossible to do, just a complication.
Activity
auxym commentedon Sep 12, 2024
Yeah, that makes sense I think. I'm also not a fan of the huge codegen. Thanks for the idea.
dwhall commentedon Sep 14, 2024
This is a compelling idea. It would be a fair bit of work, but it might be worth it. Thinking of how the result would be used:
Where "device" gives you access to the device name, mpuPresent, fpuPresent, etc.
and each peripheral module would hold all the registers, their fields accessors and enum constants, etc.
One challenge will be where one peripheral is "derivedFrom" another. In those cases, I prefer the registers and register fields to be type-compatible, so I can copy values between them or put like registers into a list where they need to be the same type. To achieve this type-compatibility would require two modules importing the type from a common module. Not impossible to do, just a complication.