- Is it normal for the ATP to take this long? The Turbo and Mega are pretty similar; I’m surprised the ATP takes 5-18 times as long. I constantly switch between boards for projects; it is quite annoying to wait 9 minutes for the first compile to finish. Is there something I can do to speed up the ATP compiles?
The Artemis indeed takes much longer and the resulting binary code is also much larger to upload. A Mega is compiling only the sketch. The Artemis is using nearly a complete operating system, of which MBED-OS is already precompiled and a lib-file. For most sketches far too much and heavy. But it is what it is.
Once the first compile has been done, the second goes much faster as it uses cached. Still, 9 minutes is very long, maybe you need a faster PC :-).
- Can I configure the IDE somehow to save the various board caches so they don’t have to be completely recompiled when I switch boards?
What I do (on Ubuntu) is open the first sketch in the IDE and then instead of opening a second sketch in the IDE directly, I look up a different sketch with explorer and double click. It will open a new instance of the IDE for which I can select another board type. In that case, the cache is preserved for 2 different instances.
- Reading various posts, I am confused as to the difference between pads and pins. I think pads refer to the pins directly attached to the Apollo chip, as given by the colored chart “Table 559: Apollo3 Blue MCU Pad Function Mapping”. Pins refer to the Uno pin numbers silkscreened on AVR boards.
A PAD is like the connection point on the CPU. A pin is what you see on the side of the board.
a) Are the pad names in table 559 defined to my sketch, so I can do
digitalWrite(GPIO1, HIGH)
which sets pad=3/FNCEL=3 to HIGH?
If you would know exactly how it works you could do that… but for each board, you need to make a different special code. Would not advise to do that and let the library handle it
b) How do the Arduino pins map to the pads?
All this is done in the library for each board. There are special functions that perform the mapping. It makes use of the table that is defined for each board variant. If you look in the library variants-folder you will see for each board a different folder. In one of the files the pins to pad mapping are defined. If you want to understand how that works exactly, you will have to deep-dive into the library. It is a long story and every library does it a bit (or a lot) differently.
c) How do the ATP silkscreened names correspond to Table 559 names and/or Arduino pin names? I.e., A29 and 45?
**I could write the complete sequence, but that would be a chapter in a book. For an ATP specific a short answer : Assume you use library V2.xx. In the 2.2.0/variants/SFE_ARTEMIS_ATP/config/pins.cpp. Here is part of the mapping defined and this table is used for other purposes as well. In each line, the first entry is a D0 or D1 up to D45. These are defined in 2.2.0/cores/mbed-os/targets/TARGET_Ambiq_Micro/TARGET_Apollo3/TARGET_SFE_ARTEMIS_ATP/pinnames.h**
**When you do pinMode(8, OUTPUT), it will call for a pinIndexByNumber() to look up the line in the table where the second entry is 8. It will then return the offset/ index in the variants table. Then it will call many other routines, some part of MBED-os, some part of the ‘TARGET_Apollo3’ to set the pad in the correct FNCSEL and mode etc**
- In the discussions, it sounded like one can put either the Arduino pin number OR the pad number into digitalWrite; somehow the IDE knows which one you are using. It sounded like the function signature was different for pads vs pins. If I do digitalWrite(3, HIGH),
The beauty of C++, you can have multiple functions with the same function name, but depending on parameters it will choose the correct one. E.g. in Artemis you have 2 calls :
void digitalWrite(pin_size_t pinNumber, PinStatus val) when you do digitalWrite(3, HIGH)
void digitalWrite(PinName pinName, PinStatus val) when you do digitalWrite(D3, HIGH)
a) is this Arduino pin 3 or pad 3?
pin
b) If this is pad 3, how do I specify FNCSEL 3 to get GPIO3?
FNCSEL 3 is only applicable for Apollo3, an Arduino AVR works with “I/O ports”. Each port has 3 registers and can handle up to 8 GPIO. The mapping is completely different… and all that is handled by the library without any change needed to the sketch.