Open rbkettlewell opened 2 years ago
I'll start looking at maybe using some type level kung-fu for accessing an array of pins in a coherent order. I am not sure how that will look yet but I'll report back if it is even possible!
Here is a screenshot of the alternative functions table itself, which is useful for determining the type state exclusions.
Reference for the alternative function state transitions. We are not quite sure what the tables 8-5 and 8-6 mean. The tables seem to imply that to get from one alternative function state to another, the user has to go down to the IO mode and then to the desired alternative function. However, the bits to do this seem to be the same for multiple actions!
The zip for the C code is in the manuals channel of slack (it can't be uploaded here for some reason).
Here is a screenshot of the alternative functions table itself, which is useful for determining the type state exclusions.
The last line of the page seems particularly important for some pins
**This signal can be mapped to more than one GPIO, but there is only one instance of this peripheral. †I2S_BCLK, I2S_LRCLK, I2S_SDI, I2S_SDO when enabled.
This seems to state that some interfaces (such as SWD or UART1) can be on one of several different pins, and that those functions can be accessed from multiple pins simultaneously. So one could map UART1_TX
to AF2 P0.10
and AF3 P0.06
, accessing the transmit pin of the protocol from either pin.
Ideally, if you want to configure an I2C, or SPI peripheral, those modules should check to ensure that the pins being used are setup properly.
https://datasheets.maximintegrated.com/en/ds/MAX32660.pdf