Abstract microcontroller type

[ducky64]

One that has a grab-bag of common IO types (digital, SPI, I2C, UART, CAN, USB), using #20.

A future feature would allow the IOs to be of all of the above types, though the design model and implementation for that is unclear. For now, there would be an API similar to the current new_io that returns a io of the appropriate type. Main benefit is that it could allow micros to be more interchangeable with abstract types instead of changing HDL.

Related: #15, which is also relevant to this.

[ducky64]

Thoughts on architecture of the components involved:

Chip level:

• instantiates the footprint
• ports more or less directly correlate with the footprint, probably configured as a named vector that correlates with the port name
• perhaps also creates peripheral ports (eg, SPI, I2C), but it's unclear how to handle configuration (either pin matrix like LPC1549 or alternative-mapping like STM32) and overlap with GPIO ports (perhaps mutual exclusion functionality? or pin mapping generator?)
  • peripherals at this level more accurately models the chip and its resources
  • this better modeling may also make it easier to generate firmware stubs (in the future), without needing things like graph traversal (but this will need to traverse the graph to get names - perhaps using link name with name inference from allocated port names)
  • otherwise, ports would need to be passively-typed, since analog functionality is often overlapped with digital ports

Application circuit level:

• contains required supporting components, like decoupling capacitors
• exposes the same interface as the chip above, except for anything only connecting to required components
  • requires vector export functionality
• does not contain optional components, like crystals (if there is an internal frequency source - but exposes the port)

Pin mapping level (IO controller wrapper / adapter):

• a very magical block, does a lot of things to present this software-controlled bag-of-IOs abstraction
  • everything else needed to use the microcontroller is automatically generated - for example, crystals (details below) and programming ports
  • parameters and refinements can be used to turn these off and control their implementation
• can contain mixins (#104) to provide the interface to support different functionality, eg frequency tolerance spec to automatically generate a crystal if needed
• contains a very basic pin mapper (greedy assignment - maybe better or configurable in the future), it is expected users will manually specify pin mappings through suggested name on the connected ports and refinements
  • if the chip or application circuit provides peripheral IOs: there are now overlapping responsibilities, in which case this will need to both handle direct port assignment (even bundles like SPI aren't broken up, they are directly forwarded) AND generating refinements to the chip to control its internal assignment
  • architecturally, this will need to understand the chip's peripheral assignment architecture, then serialize that configuration, pass it as a parameter, which the chip will deserialize and handle its internal mapping
  • bitbang case: should bitbang adapters be instantiated here? - probably don't need to worry about it right now

Current state of things:

• chips have passive pins (for the analog/digital reason above) - so the modelling is meh
• application circuit block also handles pin mapping
• the instantiating level must create supporting components like crystals and programming ports - composable but still kinda overhead

Defining a cross-level-of-abstraction pin mapping interface:

• requirement: handle multiple mapping schemes, including pin matrix and fixed peripherals with alternate pins
• requirement: single source of truth: the pin assignment definition should be centralized, and pin assignments (in both the chip and IO controller levels) should draw from this central source of truth
• architecture:
  • chip contains a mapping of ports that indicates where they can connect
  • chip has IOs named by chip ports, eg .dio['p0_7'] or spi['0'], where multiple ones may map to the same pin
  • typically, single wire pins like GPIOs will have a fixed location, while bundles like SPI may map to several pins (and would be controlled via refinements)
  • this is structured as a generator, which generates the actual pin mapping
  • disconnected ports are asserted not-connected
  • the intermediate application circuit level is a passthrough
  • the IO controller level actually handles pin mapping
  • single wire pins (where the port maps to a fixed pin) is mapped to the appropriate IO on the inner block, while bundles are forwarded (and a corresponding refinement is generated)
  • TBD: how to actually do this
• alternative approach:
  • the chip is the generator with the grab-bag of IO interface
  • perhaps autogenerating things like crystals can be rolled into the application circuit block for simplicity
  • export semantics would need to propagate the allocated ports inward - need array export semantics