Pin functionality for QFN-80 package
The QFN-80 package (RP2350B/RP2354B) has an additional series of GPIO pins GPIO30-GPIO47. These pins currently exist as type-level variants, but do not have functionality implemented beyond FunctionSIO<C>. In theory, this should be fairly straightforward to implement, because these pins do not introduce any new peripherals in and of themselves, but I don't have any experience in HAL development, and don't know this would be effected.
As an aside, are there any good resources floating around on learning HAL development or "raw" embedded Rust? I'd love to be able to contribute, especially coming from a C/C++ background the macros that seem to impliment the ValidFunction traits seem very arcane.
As an aside, are there any good resources floating around on learning HAL development or "raw" embedded Rust? I'd love to be able to contribute, especially coming from a C/C++ background the macros that seem to impliment the ValidFunction traits seem very arcane.
https://github.com/rust-embedded/awesome-embedded-rust contains a lot of links to learning resources and crates for embedded devices.
Any you could join https://matrix.to/#/#rust-embedded:matrix.org. (Or https://matrix.to/#/#rp-rs:matrix.org for rp2040/rp2350 specific topics.)
Hey, I also came across this for a project of mine, I am trying to implement the missing pins in #920 . I think I implemented all of them, but I could be wrong. I do not have any experience writing HALs so if you want to take a look, maybe we can work it out together.
This looks well put together from me, though I don't have my hands on test hardware at the moment.
I'll take a shot against changing the ADC pins, any advice about not implementing RP2350B as a feature for this? That code looks pretty specific to RP2350A. https://github.com/rp-rs/rp-hal/blob/38d28bd5e55298783284b4affcef2f0c4e01a357/rp235x-hal/src/adc.rs#L284
How does the ADC differ between 2350A and 2350B? I haven't looked at it in ages.
@thejpster According to section 12.4.2.1 of the RP2350 datasheet, the QFN-80 package contains an additional 4 channels.
Somewhat troublingly, it appears that the channels have differing physical pin hookups compared to the QFN-60 package. I'm trying to think of an alternate way around this, but we could use a qfn-80 feature and cfg's to determine which channels are available and where they are located.
I'm not totally sure how I feel about this, though it wouldn't be a breaking change for downstream applications if it's left as a non-default feature (which would be the way to go IMO, it seems like the QFN-80 variant is low-adoption at the moment).
we could use a qfn-80 feature and cfg's
Yeah that might be a good solution here.
I'm going to do a dive into the datasheet to see what other items might differ structurally between the two chips - I'll probably open another issue once I have a good idea of what needs to be changed overall, so I can track that better. I finally have some time to work on this.