few small hardware changes for pico sdk 2.0

[pauldevine]

My c skills are meager, so I was hesitant to offer this as a PR. But I wanted to give you a heads up there's a few small changes to the pico 2.0 SDK hardware definitions that are required to build the library. In case this saves any time for you, I have them here: 2.0-sdk-differences

[carlk3]

Thanks! Will the changed code still compile with the earlier SDK, or does there need to be some kind of conditional compilation or something?

[sneakywumpus]

@carlk3 I was wondering why you directly manipulate the hardware state instead of using the SDK function gpio_set_slew_rate, i.e.

gpio_set_slew_rate(gpio, GPIO_SLEW_RATE_FAST);

instead of

padsbank0_hw->io[gpio] |= PADS_BANK0_GPIO0_SLEWFAST_BITS;

[carlk3]

@carlk3 I was wondering why you directly manipulate the hardware state instead of using the SDK function gpio_set_slew_rate, i.e.

gpio_set_slew_rate(gpio, GPIO_SLEW_RATE_FAST);

instead of

padsbank0_hw->io[gpio] |= PADS_BANK0_GPIO0_SLEWFAST_BITS;

That's ported directly from ZuluSCSI-firmware: gpio_conf. I think there is some value in not making too many changes to the ported code, so that when ZuluSCSI makes improvements to their code I can easily retrofit them (although I am a bit behind in that effort at the moment).

EDIT: However, that code is redundant with some in rp2040_sdio_init (where I do use gpio_set_slew_rate), so all that needs to be refactored.

[pauldevine]

@carlk3 The changes were all due to a change in the underlying SDK. If you look at the Pico Datasheet starting on page 628 there's release notes for the 2.0 release. Then on page 634 "The enum gpio_function no longer exists and has been replaced with gpio_function_t." In order to support both 1.5 and 2.0 I believe you will need to do some conditional #ifdef or something to handle the difference. I wasn't intending this to be a PR you'd take as-is, but more an FYI of what places the code needs adjustment to work in the 2.0 SDK. I didn't think my c skills were up to submitting a PR.

[carlk3]

In order to support both 1.5 and 2.0 I believe you will need to do some conditional #ifdef or something to handle the difference.

I guess there's no real need to be backward compatible. I'll just make a new git branch, and the old branch will still be there for anyone on the old SDK.

[carlk3]

See #53