every new uC family I touch has an increasingly more contrived way of operating GPIOs. in 2022 I expect to have to solve a sudokupic.twitter.com/pxvNYr8KxE
You can add location information to your Tweets, such as your city or precise location, from the web and via third-party applications. You always have the option to delete your Tweet location history. Learn more
Without such a scheme, you need all access to gpio mediated through a gpio driver that ensures drivers don't clobber each other's changes.
or you could just do it like STM32 and have a bitbanding region that provides atomic RMW for every peripheral
Yes, that's a very nice interface from the programming side, but it probably doesn't scale or factor well on the hardware side.
I think I'd prefer hw designs where the cpu's atomics don't have to interact with anything except cache/dram controller. No "bus locks".
Yeah, I don't think bitbanding works on multicore, but *also* I don't think there are Cortex-Ms that don't have exclusive access to periph.
And CPUs other than Cortex-M-class don't really have the address space to spare for bitbanding, so it works out in the end.
fwiw not all Cortex-M have bitbanding. M7 at least does not
I think it's vendor-dependent, at least for AHB/APB peripherals, no?
no, Cortex-M3/M4 implement bitbanding by doing locked RMW ops over AHB. M7 doesn't in part because it moved to AXI
I don't see how this prevents clobbering when "threads" won't know of each other's writes.
It's assuming each driver does its own synchronization with itself or is single-threaded; that's trivial to satisfy.
What's nontrivial is synchronizing access to a gpio register between independent drivers that don't know about each other.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.