-
Notifications
You must be signed in to change notification settings - Fork 101
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
nrf52-runtimes 14.1.0 #1318
nrf52-runtimes 14.1.0 #1318
Conversation
abc3969
to
c95a961
Compare
Use_Reset_Pin = { type = "Boolean", default = true } | ||
|
||
[[depends-on]] | ||
gnat_arm_elf = "^14" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I wonder if you might prefer ">=14". Although later GNAT versions might break something, this way you're anchoring all your clients to GNAT 14.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks. My understanding is that the runtimes are generally tied to a particular GNAT version, and later GNAT versions might break something as you say, since the compiler/runtime interface could change with diffferent GNAT versions.
My plan is to do one major release of these runtimes for each GNAT version. This version (14.1.0) is compatible with gnat-fsf-14. When gnat-fsf-15 is released then I'll do a 15.0.0, and I'm going to try doing releases for earlier GNAT versions too; this version is just the first attempt. This way users can either let the GNAT version be chosen automatically:
[[depends-on]]
light_nrf52840 = ">=14"
or let the runtime version be chosen automatically:
[[depends-on]]
gnat_arm_elf = ">=14"
light_nrf52840 = "*"
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Indeed, a given run-time can be strongly tied to a compiler version.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
OK, I didn't know this info about runtimes, I was only thinking of checks that find new errors. Then it must be like you have done it.
c95a961
to
7ab6616
Compare
7ab6616
to
528458a
Compare
tags = ["embedded", "runtime"] | ||
website = "https://github.com/damaki/nrf52-runtimes" | ||
|
||
project-files = ['runtime_build.gpr', 'ravenscar_build.gpr'] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Another clarification for my peace of mind: if you specify two project files, both will always be built by dependents. If those represent alternatives, they should go in separate crates.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for clarifying that. This is the intended behaviour (that both will be built).
The two project files are really just a consequence of how the runtimes are organised where it's split into 2 libraries: libgnat (built by runtime_build.gpr) for the sequential stuff, and libgnarl (built by ravenscar_build.gpr) for the tasking stuff. The light runtimes don't support tasking, so only provide libgnat (so the light_nrfxxx runtimes only build runtime_build.gpr), whereas light-tasking and embedded provide both libgnat and libgnarl (so both projects are built for those runtimes).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
OK, thanks. Then I think this is ready to be merged.
This adds v14.1.0 of the light, light-tasking, and embedded runtimes for some nRF52 SoCs.