Add support for LPC55S16. by wt · Pull Request #30 · embassy-rs/nxp-pac

wt · 2026-02-13T03:33:05Z

No description provided.

wt · 2026-02-14T09:42:28Z

BTW, this change is draft pending an update to the mcux-soc-svds repo. See here for details.

FWIW, chiptool will currently generate bad code with the invalid SVD currently in that repo. I have also filed a bug for that here.

eva-cosma · 2026-02-17T16:47:32Z

Isn't the whole point of chiptool to be able to fix bad SVD files? Can we not patch a fix ourselves using chiptool until then?

wt · 2026-02-21T11:02:05Z

This is based on my directory move PR. If we can get that one landed, I'm happy to land this one and iterate on fixes via transforms after the fact.

eva-cosma · 2026-02-21T11:31:19Z

I would prefer we iterate over the transforms here at least a little bit. It doesn't have to be final, but it still needs to go through review. etc. When you want the transforms reviewed, move the PR from draft to ready and add the reviewers.

I am still unsure what you mean by

FWIW, chiptool will currently generate bad code with the invalid SVD currently in that repo. I have also filed a bug for that embassy-rs/chiptool#94.

Please see my previous comment.

wt · 2026-02-21T12:02:19Z

The bug in chiptool accepts a bad description in the SVD. I have an direct example in the linked issue. I do think that chiptool needs to, at the very least, needs to report that such an issue is happening. I honestly think it should default to erroring out with maybe a flag to generate the code anyway.

Assuming it's possible to fix this particular problem with only transforms, I didn't want to spend time to write the transforms to fix it since the fixed SVD is coming from NXP. This holding this ass a draft.

With regard to transforms in general, there are a ton of things we could do to make the loc55s16 pac coffee seem more sane. Like there are a ton of enums with options with names like ENUM0x1. Those names are just terrible. So, do we keep those, or do we fix the names? I'm tempted to leave the names for two reasons. 1. It matches the svd. 2. Fixing all the poorly named enums is a lot of transforms.

It also feels important to note that the enums have the same problems in LPC55S69, but only one is rewritten by the transforms for that board. That honestly seems worse than changing them all.

wt · 2026-03-01T12:00:47Z

I've changed my mind. I marked this as ready for review so that it can hopefully be landed. I guess if we need to regenerate the code for a new version of the svd, we can do that in the future. Landing it will also make it easier for me to start working on nxp-hal changes.

FWIW, I do think that transforms are a bit more reasonable to iterate on after landing this. I hope we can do that. Thanks.

wt · 2026-03-01T20:20:02Z

@eva-cosma I think I've addressed everything. please let me know if there is anything else.

wt · 2026-03-02T14:59:39Z

I went ahead and used the transforms from the lpc55s69 after verifying them. I have a diff that is compiling for embassy-nxp that I have not yet published that is based on this change.

wt · 2026-03-02T22:44:58Z

I am considering another commit on this stack to move the transform lpc55s69_cm33.yaml to lpc55.yaml Then we could have separate specializations for different boards in the lpc55 family in a sane way. I just wanted to keep this change as minimal as possible since it's so big already.

wt · 2026-03-03T06:20:36Z

The commits on this PR include #46. The transforms needed to be zhuzhed since there is an inconsistency between the SVDs for S16 and S69.

eva-cosma

No. I don't want a common mega-file for all lpc55. I understand the rationale, but the core idea is that the LPC55s69 yaml file needs to be refactored to include comments and proper explanations as to what is happening and why we are doing in that file. Making a "common" file now, will just make it harder in the future to track what we did for the lpc55s69. Leave that one alone, for now. I would much much much rather have data duplicated in 2 places than spread amongst many files. More so that if someone makes a change in the common LPC file, it should be tested on all variations. Not easily feasible and the code is not "final" enough for that.

When someone implements a 3rd LPC chip we can think of a common file.

eva-cosma · 2026-03-03T09:36:11Z

-  - !MergeEnums
-    from: iocon::vals::Pio\d+Asw
-    to: iocon::vals::PioAsw


Because the SVDs different in the naming of a particular enum. On the S16, the enum values are named so that the enum is removed by the useless removal feature of chiptool. On the S69, that removal does not happen, and these rules are applied to rewrite the enum.

A better solution would be to make that single bit field resolve to a bool instead of the enum and remove the enum. Then the S16 and S69 would be identical in that regard.

eva-cosma · 2026-03-03T09:36:22Z

-  - !AddFields
-    fieldset: iocon::regs::Pio
-    fields:
-      - name: asw
-        description: "Analog switch input control."
-        bit_offset: 10
-        bit_size: 1
-        enum: iocon::vals::PioAsw
-


Same as above.

eva-cosma · 2026-03-03T09:37:44Z

+                || x.starts_with("CARGO_FEATURE_LPC55S16")
                || x.starts_with("CARGO_FEATURE_LPC55S69")


I think you can merge this into a singe CARGO_FEATURE_LPC55

That's a good idea.

wt · 2026-03-03T23:26:47Z

Does this mean that there is no goal of trying to keep them as similar as possible?

eva-cosma · 2026-03-04T09:26:31Z

I don't want to touch the lpc55s69 transforms. Not yet. We can brainstorm later how to split it up and make stuff reusable. But I don't have the bandwidth to do that now, and I don't want to slow down this PR even more.

wt · 2026-03-05T05:28:37Z

Okay, so I reverted the changes with the S69 and copied the S69 transforms to the S16 ones except for the ones that needed to be removed since they are not relevant to the S16.

wt marked this pull request as draft February 13, 2026 03:33

wt force-pushed the add_lpc55s16 branch 2 times, most recently from 9e9aa14 to 24520ff Compare February 13, 2026 20:40

wt force-pushed the add_lpc55s16 branch from 24520ff to ea84654 Compare February 17, 2026 06:01

wt force-pushed the add_lpc55s16 branch 2 times, most recently from 3a05b55 to d9f410a Compare February 21, 2026 00:43

wt force-pushed the add_lpc55s16 branch 2 times, most recently from 766f4e8 to 7e8c1da Compare March 1, 2026 11:58

wt marked this pull request as ready for review March 1, 2026 11:59

eva-cosma requested changes Mar 1, 2026

View reviewed changes

Comment thread data/transforms/lpc55s16.yaml

Comment thread .zed/settings.json Outdated

wt force-pushed the add_lpc55s16 branch from 7e8c1da to 6a5789d Compare March 1, 2026 20:13

wt requested a review from eva-cosma March 1, 2026 22:40

wt force-pushed the add_lpc55s16 branch 2 times, most recently from f52a095 to b7c5dcb Compare March 2, 2026 14:55

wt mentioned this pull request Mar 3, 2026

Move lpc55 family transforms into a common spot. #46

Open

wt force-pushed the add_lpc55s16 branch from b7c5dcb to e57b70f Compare March 3, 2026 06:17

wt mentioned this pull request Mar 3, 2026

Add LPC55S16 support. embassy-rs/embassy#5566

Merged

eva-cosma requested changes Mar 3, 2026

View reviewed changes

wt force-pushed the add_lpc55s16 branch from e57b70f to 3b62725 Compare March 5, 2026 05:27

wt requested a review from eva-cosma March 5, 2026 05:28

Add support for LPC55S16.

a0a0aa3

wt force-pushed the add_lpc55s16 branch from 3b62725 to a0a0aa3 Compare March 5, 2026 05:33

eva-cosma approved these changes Mar 5, 2026

View reviewed changes

eva-cosma merged commit a7a6985 into embassy-rs:main Mar 5, 2026

		\|\| x.starts_with("CARGO_FEATURE_LPC55S16")
		\|\| x.starts_with("CARGO_FEATURE_LPC55S69")

Conversation

wt commented Feb 13, 2026

Uh oh!

wt commented Feb 14, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

eva-cosma commented Feb 17, 2026

Uh oh!

wt commented Feb 21, 2026

Uh oh!

eva-cosma commented Feb 21, 2026

Uh oh!

wt commented Feb 21, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

wt commented Mar 1, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Uh oh!

Uh oh!

wt commented Mar 1, 2026

Uh oh!

wt commented Mar 2, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

wt commented Mar 2, 2026

Uh oh!

wt commented Mar 3, 2026

Uh oh!

eva-cosma left a comment

Choose a reason for hiding this comment

Uh oh!

eva-cosma Mar 3, 2026

Choose a reason for hiding this comment

Uh oh!

wt Mar 3, 2026

Choose a reason for hiding this comment

Uh oh!

eva-cosma Mar 3, 2026

Choose a reason for hiding this comment

Uh oh!

wt Mar 3, 2026

Choose a reason for hiding this comment

Uh oh!

eva-cosma Mar 3, 2026

Choose a reason for hiding this comment

Uh oh!

wt Mar 3, 2026

Choose a reason for hiding this comment

Uh oh!

wt commented Mar 3, 2026

Uh oh!

eva-cosma commented Mar 4, 2026

Uh oh!

wt commented Mar 5, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

wt commented Feb 14, 2026 •

edited

Loading

wt commented Feb 21, 2026 •

edited

Loading

wt commented Mar 1, 2026 •

edited

Loading

wt commented Mar 2, 2026 •

edited

Loading