-
Notifications
You must be signed in to change notification settings - Fork 134
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[stm32] Add facilities for type-erased gpio manipulation #543
base: develop
Are you sure you want to change the base?
[stm32] Add facilities for type-erased gpio manipulation #543
Conversation
80eb9dc
to
4e7244b
Compare
Very cool! This should still be very fast. i'm quite unhappy with our lack of dynamic peripheral support and lots of code is unnecessarily duplicated by our literal code gen, even though the Peripheral Instances are often of the exact same type or compatible (sub-)layout (like some of the timers). We should remove the lbuild code gen for a more traditional C++ approach, since I don't see a performance boost for our current approach at all. Although we will still need lbuild for generating the interrupts for UART etc. Ideally I'd like to keep the complicated things like baudrate and connect stuff in compile time, which calls into a platform-specific inline, but non-generated API. That way you can still bit-bang individual IOs or entire ports really fast, but also use runtime indexing transparently. The main issue holding us back is AVRs, since their registers are not friendly to "algorithmic compression" with their random bit stuffing into registers of different devices. But I would suggest we just ignore that and move on with Cortex-M. Then on top of that we can have a (minimal) virtual interface that is used by non-platform specific drivers. Together with fibers that would allow to transparently use IO expanders in a non-blocking way (not possible right now). For some of the really fast IO expanders over SPI you could probably even bit-bang I2C (!) fairly transparently. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Merge?
(Even without unit test for now?)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes!
We can consider merging, if you are fine with having no support for |
I guess I would run it on a Nucleo tomorrow night for testing again. That could be turned into a tiny unit test. Let's see then, ok? |
Note that inspired by this code I updated the GPIO wrapper class used in my ELVA project, which was implemented using virtual functions, to now instead use a runtime computation and it shaved off about a dozen kB of Flash. I need to test this more thoroughly and perhaps check how AVRs fare with this API style, however, for STM32/Cortex-M this is still pretty efficient: ASM listings
|
c53a6dd
to
ae6002e
Compare
I added a more complete Runtime Gpio type, but I broke something in the RandomAccessPort. I also need to add a virtual base class for Gpio to implement UnusedGpio and GpioExpander pins (but the interface has too many functions for that). |
bf44fe8
to
ae6002e
Compare
I've moved my changes into #631 to explore this in a more structured way. Are you ok with waiting until the runtime GPIO interface is more mature? Your code is pretty independent of modm, so it's probably easy to just include in the project directly. |
I am fine with not merging yet. Didn't have any time to work on this last week, sorry. |
This adds the following:
This is implemented on STM32 register level. It stores the GPIOPort instance pointer and a 16-bit pre-computed bit value.
Thus, this is quite efficient.
The pin wrapper is a by-product of implementing the port class. My use-case is setting and reading Gpios from a sequence with a runtime index received from a communication link. I couldn't get reasonable code generation with a language-level solution on top of GpioXX classes. I presume this could be useful for others as well.
TODO: