Yes, that's correct.tkisner wrote:So would my pin definition look like the following
#include "Adafruit_FONA.h"
//I don't list the RX and TX as they are working and connected directly to the hardware pins that are appropriate
#define FONA_RST 5 //Assuming I connect to GPIO 5
#define FONA_RI 6 //Assuming I connect to GPIO 6
No, that's the pin that forces the SAMD21 microcontroller on the Feather M0 to reset. It's only an input, and will immediately terminate any code that happens to be running on the board.tkisner wrote:I did notice that there is an RST pin labeled on the MO board. Is that the pin I should use located in the top left of the pinout diagram of the MO
The FONA's RST pin does the same thing to the SIM808 module, and you need to connect that pin to one of the Feather's GPIO pins. The Feather needs to be able to force the SIM808 to reboot in a known state.
That's correct. The other labels describe alternate functions for each pin, and we include the physical pin number because that makes it easier to look things up in the datasheet.tkisner wrote:I believe I want to use the IDE reference number for the GPIO pin, the numbers in purple, and not the physical pin numbers, the numbers in gray.
You don't need any of that information if you're using a pin for simple GPIO with ditigalRead() and digitalWrite().
Yes.tkisner wrote:Am I also correct in my understanding in order for the SMS Auto Reponse sketch to work, RI needs to be connected and functioning in order to notify of the received SMS as an interrupt?
By itself, the microcontroller has no way to know whether the SIM808 has received an SMS. It could use AT-commands to check at regular intervals.. a technique called 'polling'.. but that makes both devices do a lot of work for a condition where the answer is usually 'nothing new to report'.
That's why the SIM808 has an RI pin: it holds the voltage on that pin high most of the time, but pulls RI low for about 125ms when it receives a call or an SMS. Connecting the FONA's RI pin to a GPIO pin on the Feather lets the microcontroller check for messages without having to use AT-commands.
The microcontroller could poll its GPIO pin.. check it every 100ms to see if the signal is high or low.. which is faster and easier than using AT-commands, but still does a lot of work for something that almost never chages. The alternative is to configure another circuit connected to the pin so it sends the microcontroller a message any time it sees the signal drop from high to low. Together, the circuit and the message to the microcontroller are called an 'interrupt'.
When the microcontroller receives an interrupt message, it has the option to stop executing the code currently running and run another function called an 'interrupt handler' or 'interrupt service routine' (ISR). Then when the ISR is done, the microcontroller can go back to the previous code and pick up where it left off. Interrupts are a convenient way to inject new inforamation into code without having to poll for it.