Add gpio functionaliy to lpc845

[david-sawatzke]

• Add compatibility layer for differently named peripherals raw_compat (Unfortunately couldn't find a way to do the same for registers)
• Add pin assignments for for lpc845
  • Currently a few are commented out, as gpio1 & pinenable1 are currently missing
  • There's now also a Dac & capacitive measurement, I think the best way to handle them is to rename pin_state::Adc to pin_state::Analog.
• Disable UARTFRG & IRC for lpc845, as they don't exist
• Add Peripherals to lpc845. As the gpio is per default disabled, this also meant adding an additional new constructor(?) for disabled gpio peripherals and renaming the old one to new_enabled.
• Add a gpio example. Currently without accurate timing, as that isn't ported yet

As an aside: What's your policy about rom routines, as the fro (internal oscillator) of the lpc845 doesn't seem to be configurable otherwise

[hannobraun]

Thanks for the pull request, @david-sawatzke. I haven't taken the time to look at it in detail so far, but I have a note about the general approach.

I think the large number of #[cfg(...)] in the code is unfortunate. I think some of those can't be avoided (for register names, for example, unless we find a clever solution here too). But in some cases it looks like it might be avoided.

For example, why define IrcDerivedClock in -common, when it's only used in lpc82x-hal? Maybe the syscon module in -common should only define what's generally available, and more specific syscon modules in the two HALs should define the device-specific stuff and re-export the common stuff. Maybe a similar approach could be used for pin_state too?

I haven't tried this myself though, so maybe there are problems I'm not seeing right now. In any case, I think it's fine to merge the current approach now and find better solutions later.

As an aside: What's your policy about rom routines, as the fro (internal oscillator) of the lpc845 doesn't seem to be configurable otherwise

There's no policy right now, except that I decided not to use them years ago without ever revisiting that decision. If using ROM routines is required to get something to work, then that's what we're going to do.

[david-sawatzke]

This approach will probably lead to code duplication, e.g. with syscon I'd add an unsafe Parts::new, which then gets called, so all the SYSCON impls can stay the same. But they still have to be defined in the same crate. I think "copying" them with macros may be the best approach, instead of copying them manually or using cfg everywhere. What do you think?

We'd also have to add constructors to the structs describing parts of the SYSCON or expose their phantom data and probably other stuff, so this should at least be a separate PR.

[hannobraun]

This approach will probably lead to code duplication, e.g. with syscon I'd add an unsafe Parts::new, which then gets called, so all the SYSCON impls can stay the same. But they still have to be defined in the same crate. I think "copying" them with macros may be the best approach, instead of copying them manually or using cfg everywhere. What do you think?

Not sure what I think. What you say makes sense, but I don't think I fully grasp all the issues right now. I need to get my hands dirty and see for myself what's possible and what's not. Only problem is to find the time to do it :-)

[hannobraun]

Finally got time to review this. Sorry for the delay.

I left some comments, but since all of them are nice-to-haves, I'm going to merge this immediately. My general concern about too much #[cfg(...) in the common crate remains, but as long as I only have a vague feeling that it could be done better, that's no reason to delay any pull requests.

Thank you, @david-sawatzke!

[hannobraun]

We can keep this as-is for now, but this looks like something that should happen in raw_compat.

[hannobraun]

Same. Looks like a job for raw_compat.

[hannobraun]

Would be nice to add a comment here about which optimization level this was tested with. Compiling with or without --release makes a big difference when using this method :-)