It does not have generic bit-banding, and particularly does not provide the facility at all for RAM contents.Does either the RP2040 or the RP2350 support bit-banding? A quick scan of the datasheets does not seem hopeful...
For all the peripherals on the main bus (so everything _except_ GPIO) it has address ranges very similar to bit-banding, accessed via the SDK functions hw_set_bits(), hw_clear_bits(), hw_xor_bits(), hw_xor_mask(). Important to note when coming from other platforms that these (like many Pico SDK functions) implement as compiler inlines - so you are getting the same efficiency as if they were macros - you could go and do the address masking yourself, but there's little reason to do so.
For GPIOs, there are explicit separate registers for individual bit access; they are different in detail between RP2040/RP2350, but in both cases the GPIO registers are tightly tied to the CPU and only accessible by CPU instructions (not, for example, by DMA). However, there's the GPIO pad controls which are ordinary registers and give you overrides to force or invert the GPIO values coming from the CPU - a slightly unusual facility but occasionally quite handy.
Finally, when I was similarly porting some code from another Cortex-M machine that used bit-banding to set flags in a word of RAM (using the bitbanding to provide atomic access to bits within the word), I solved the fact that there's no bit-banding on RAM by moving my flags into the watchdog scratch registers - there's only 8 of them (32-bit wide) but they are effectively just RAM that's accessible via the main bus and so does have the bit-banding style access. I was using RP2040 for that project - the RP2350 does have CPU atomic instructions (and the necessary support for that) which might have been a better way to go had I been using it.
Statistics: Posted by arg001 — Thu Feb 19, 2026 10:43 am