Regarding the connector labeling confusion, my approach is to bag everything to do with Arduino-based silkscreen pin labeling and have my software symbols defined strictly in terms of Apollo3 pad names and numbers. Ambiq Suite only wants to deal with pad/pin numbers, which are simple integers. The Arduino pin naming just adds a needless layer of indirection to maintain compatibility with ancient AVR processors. To help simplify wiring things up to a board with Arduino silkscreen markings, I include that info I define my Apollo3 pin assignments, like this:
Code: Select all
// RFM95 radio (IOM0) additional pin assignments
#define RFM95_DIO0_PIN 28 // silkscreen D7
#define RFM95_RESET_PIN 12 // silkscreen D9
#define RFM95_CE_PIN 13 // silkscreen D10
#define RFM95_CE_CHNL 1 // pin 13 is associated with nCE IOM0.1
Regarding the general problem of mapping chip functionality to specific pins, there is no simple solution for any modern processor other than creating your own table that defines what functionality you require like number of ADC channels, serial ports, SPI chip selects, PWM outputs, button inputs, etc. Then, you read the big mapping table in the Apollo3 data sheet, and determine what set of pin assignments can be chosen to provide your desired functionality. Start by assigning the pins with the most functional restrictions, like debug port pins, VCOMP reference or input pins, or CLKOUT pins to name a few. If you are using SPI, read the section on NCE chip selects very carefully since while every pin can be an SPI CS, not every CS pin can be associated with each of the 6 possible SPI units. Don't bother assigning simple things like buttons inputs or GPIO led drivers until the very end, because every single pin can be used for GPIO. In my experience, the "functionality assignment dance" is an iterative process, which gets more difficult as you use up more and more IO pins. The only way to do it is to dive in and see what happens.