Skip to content
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

LPC55(S)1x USB1 SRAM Address #40

Open
ehntoo opened this issue Dec 27, 2020 · 2 comments
Open

LPC55(S)1x USB1 SRAM Address #40

ehntoo opened this issue Dec 27, 2020 · 2 comments

Comments

@ehntoo
Copy link

ehntoo commented Dec 27, 2020

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:
Screenshot from 2020-12-27 00-44-04

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
Copy link
Member

nickray commented Dec 29, 2020

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
Copy link
Author

ehntoo commented Dec 29, 2020

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. :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants