The Zero isn't mentioned, but as it mentions the Due, I assume that the GPS Data Logger Shield is 3.3V compatible.
This guide states that this shield uses D0 and D1 for hardware serial, or D7 and D8 for software serial. Unfortunately, D7 and D8 on the Zero don't share the same Serial Communications (SERCOM) port, so configuring them as a hardware serial port isn't possible. However, the Zero's "Serial1" port is on D0 and D1, so your best bet is to move the switch to hardware serial and in Adafruit's example code redefine "mySerial" to "Serial1":
Another issue (if you're using it) is going to be your SPI, micro SD card data logger. The Arduino SPI library for the Zero doesn't use digtal pins D10-D13 like the Uno, but instead uses the 6-pin ICSP header. Fortunately it's possible to configure the Zero to use the same pins as the Uno, by following Adafruit's SERCOM guide here: Creating a new SPI | Using ATSAMD21 SERCOM for more SPI, I2C and Serial ports | Adafruit Learning System
It's for their Feather M0 board, but it's similar to the Zero, (they use the same processor).
Looking at the schematic, it appears as though Adafruit have reversed their Rx and Tx pins that go to digital pins 0 and 1. Reversing these pins and loading the Uno with a blank sketch allows a direct connection from the GPS to your PC. Using this method the GPS's NMEA data can be displayed on the Arduino IDE's console. Unfortunately, this won't work with the Zero.
To get the board to work with Serial1 on the Zero's D0 and D1 pins, your going to have to use the "Direct Connection with Jumpers on Leonardo" method:
This requires you to select "Software Serial" on the switch and directly connect the GPS's Tx to the Zero's Rx (D0) and the GPS's Rx to the Zero's Tx (D1) using jumper wires. Doing this however means that you can't use D7 or D8.
I have to pick up this thread as I think you may be the right audience for my issue.
I would like to use pins 2/3 for Serial2 and 4/5 for Serial3 on the Zero for easier cabling. Is that possible without modifying the variant files? Just with local code in my sketch?
If you're using an Arduino.cc's Zero then D2/D5 and D3/D4 make TX/RX sercom pairs, whereas on an Arduino.org's M0/M0 Pro it's D2/D3 and D4/D5. This is because on Arduino.cc's Zero, pins D2 and D4 are swapped.
Assuming that you're using the Arduino.cc's Zero, then D2 and D5 use sercom2, or if you're prepared to forgo the SPI port on sercom4. Pins D3 and D4 use sercom0 or sercom2, however sercom0 is already used by D0 and D1.
The pins you mention read differently in the page reference you linked.
If you look at the bottom of the linked page, you'll find an example that exactly matches your requirement, namely using sercom2 on pins D3 and D4. Here's the code from adafruit's page:
You just need to reverse the pins D2=TX, D5=RX and change the PAD definitions. I've also changed Serial4 to Serial3, although this doesn't really matter:
It's because you're calling the pinPeripheral() function before the Serialx.begin(). Call the begin() function for the serial ports first, then it should work OK.
I'm not sure it is possible as is. if you take a look at HardwareSerial.h, you'll see that the 9N1 config doesn't exist.
You're right, I didn't notice that 9 bits worth of data isn't an option in hardware serial.
Although, it might be possible to disable the UART, set the number of bits to 9 and then restart. I haven't tested it though:
Serial1.begin(115200); // Set-up Serial1 at 115200bps
SERCOM0->USART.CTRLA.reg &= ~SERCOM_USART_CTRLA_ENABLE; // Disable the UART
while(SERCOM0->USART.SYNCBUSY.bit.ENABLE); // Wait for synchronization
SERCOM0->USART.CTRLB.reg |= SERCOM_USART_CTRLB_CHSIZE(1); // Set CHSIZE to 1 = 9 bits per character
SERCOM0->USART.CTRLA.reg |= SERCOM_USART_CTRLA_ENABLE; // Re-enable the UART
while(SERCOM0->USART.SYNCBUSY.bit.ENABLE); // Wait for synchronization
yes, my understanding is that for 9N1, I would have to patch the libraries - those patches exist, but would force me to go back to 1.5.x or I will have to port the patches over. SoftwareSerial is available, just has the dependency on AVR.. Any plans to support ARM targets?