Pin-to-function mapping is boggling my mind

Development Boards Artemis
1

I’m looking to use Artemis ATP for development for a medium volume product.

But the whole pin-to-function mapping is boggling my mind. I’m having a difficult time understanding the mapping, or even what functionality is available, etc. The Apollo3 mapping table uses abbreviations that don’t help. The seeming random pin ordering on the connectors doesn’t help, either. There are just too many gears turning gears here for a new user for me to be comfortable.

Is there a guide that simplifies this, or demos it a bit more so that I can get going.

2

Hi SeattleDavid,

I’m afraid there’s not really a guide that will simplify the pin mapping since the Apollo3 pins have so much flexibility and the ATP version is really meant to experiment with all the pins (hence the name). The [Hardware Overview section of our “Designing with the SparkFun Artemis Tutorial” will have a bit more information along with links to the [Apollo3 Datasheet and other helpful links. The Apollo3 datasheet is going to be the most extensive resource on all of the pin functionality of the Artemis module but it is quite in-depth.

We also have some Arduino examples built into our [Apollo3 Arduino Core that can help you get started programming the Artemis ATP and playing around with pin functionality. That GitHub repository will also have the most up-to-date information on the development of that Arduino core. I hope this helps!](Arduino_Apollo3/libraries at main · sparkfun/Arduino_Apollo3 · GitHub)](https://cdn.sparkfun.com/assets/learn_tutorials/9/0/9/Apollo3_Blue_MCU_Data_Sheet_v0_9_1.pdf)](Designing with the SparkFun Artemis - SparkFun Learn)

3

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:

  // 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.