LPC55(S)1x USB1 SRAM Address

[ehntoo]

I've started bringing up a new custom board based on the LPC5514 using this crate. So far, most things appear to be pretty well compatible, but I did run into an issue with the USB SRAM - on the 551x chips, the USB SRAM is mapped at 0x20010000 rather than at 0x40100000 as in their bigger-brother LPC55S69 cousins:

From what I can tell, this would be the first change in the crate for another chip family member. In other crates I've used like the stm32 hal packages, these differences are to be handled with feature flags. Would a similar strategy be the best way forward here? I suspect we could detect this particular difference easily at runtime as well. I can put together a PR if that would be helpful. :)

[nickray]

Hmm, that's annoying :) I haven't thought out a strategy for eventually covering all chips in the family; my expectation was that "lesser" chips in the family would simply have peripherals removed, and one could get by with feature flags à la STM32 HALs, but just patching out certain submodules. Generally I'm hoping to avoid a deluge of conditional compilation, from a code readability perspective.

For this specific simple constant selection I'd definitely also favor a feature flag over runtime detection.

I should add that I don't have the bandwidth to check on other chips. Is your project long-term, i.e. would you be willing to maintain an eventual 55x1 part?

Do you have an idea of how many / which feature flags would be appropriate, and good names? I personally only use the S69, and read UM11126, which covers "LPC55S6x/LPC55S2x/LPC552x"; I see that UM11295 covers "LPC55S1x/LPC551x", UM11424 covers "LPC55S0x/LPC550x", and who knows what the unreleased chips will bring.

Perhaps most of the actual changes (not just missing peripherals in lower subfamilies) turn out to be just constants, which could even be pushed down to additions to the SVD/PAC crate.

Pragmatically, we could start with a feature flag um11295 activating necessary changes for the (S)1x family, and postpone a systematic design to when you/we have a better idea of what's necessary (and possibly others turn up who use the "0" family).

What do you think?

[ehntoo]

A um11295 flag sounds like a reasonable approach, especially while still discovering the full scope of differences are between parts. So far, the parts are still significantly more compatible than I'd have expected going in - even the pin muxing seems to be relatively conflict-free.

I'm relatively new to Rust, and my project is fairly constrained in scope (a USB-HS to CAN-FD adapter), though I also plan on using the LPC551x parts on future projects. I can commit at least to being available to review any future changes that might effect support for the 551x parts.

I'll work up a PR to encapsulate this change behind a um11295 feature flag. :)