Support shared resources in pin map resources #278
Comments
ducky64
added a commit
that referenced
this issue
Aug 8, 2023
…SPI and I2C naming (#277) Add I2C target and SPI peripheral ports as IoController ports. While these ports are less commonly used, microcontroller can be used as e.g. IO expanders. Coming soon in an example board... These are exceptions: - While RP2040 can run in SPI peripheral mode, it will not automatically tristate the data-out pin which is software controlled. The SPI peripheral definition is not included. - While STM32 can run in SPI peripheral mode, the CS pins are restricted (not pin-matrix'd). Since CS pins are defined separately (#276) it may make it easy to mis-pin the device. - It's a weird line to draw which may be re-explored later. This also models SPI controllers and peripherals as distinct resources without a mutual exclusivity constraint as common on microcontrollers. Needs a deeper refactor into the pin resource system, #278 Other changes: - Update nRF52840 peripheral names to be consistent with datasheet peripheral instance names Modernize port names as follows (keeping legacy names as an alias): - This is not expected to break backwards compatibility. - SpiMaster -> SpiController, SpiSlave -> SpiPeripheral, per https://www.oshwa.org/a-resolution-to-redefine-spi-signal-names/ (note, there isn't one authoritative SPI standard, and different vendors use different terminologies including controller/target - this seems to be one of the efforts to create a broader standard) - Doesn't change MISO / MOSI port names for now, since this would break compatibility. A name alias in Python is possible, but this would break pin assignments which are string-based and would need dedicated aliasing capability (which may be added in the future - as other migrations are needed). - Port-side SDI/SDO naming may be better in terms of matching the datasheet (which seem to prefer the device-relative naming) and reducing transcription errors when building library parts, though may be less objectively unambiguous. - I2cMaster -> I2cController, I2cSlave -> I2cTarget, per authoritative specification document https://www.nxp.com/docs/en/user-guide/UM10204.pdf
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
For example, a SPI master and SPI peripheral controller, though distinct ports in the block diagram model because they're different types, commonly share the same resource on microcontrollers and a mutual exclusivity constraint needs to be defined.
Currently this is ignored, so it's possible to allocate double the amount of SPIs that actually exist, though is likely to be a rare problem given that common application probably do not have SPI and I2C operating in peripheral model and experts using those probably are aware of resource constraints anyways.
Related: #156, to specify resource constraints beyond the port type system
Idea:
The text was updated successfully, but these errors were encountered: