that said, I did just have the serial monitor lock up the IDE
yup ok that’s the deal…
There’s still framing errors occasionally but i think that’s more of a buffer issue on the library or uart.
i’m running 115k2 and here’s the sketch below.
Wiring was:
FTDI from windows machine to 4 pin header
28 pin header D0/D1 to 40 pin header RX/TX and using cutecom with /dev/ttyS4 @ 115k2
/*
Multiple Serial test
Receives from the main serial port, sends to the others.
Receives from serial port 1, sends to the main serial (Serial 0).
This example works only with boards with more than one serial like Arduino Mega, Due, Zero etc.
The circuit:
- any serial device attached to Serial port 1
- Serial Monitor open on Serial port 0
created 30 Dec 2008
modified 20 May 2012
by Tom Igoe & Jed Roach
modified 27 Nov 2015
by Arturo Guadalupi
This example code is in the public domain.
*/
void setup() {
// initialize both serial ports:
Serial.begin(115200);
Serial1.begin(115200);
SerialUSB.begin(115200);
}
void loop() {
// read from port 1, send to port 0:
if (Serial1.available()) {
int inByte = Serial1.read();
Serial.write(inByte);
SerialUSB.write(inByte);
}
// read from port 0, send to port 1:
if (Serial.available()) {
int inByte = Serial.read();
Serial1.write(inByte);
SerialUSB.write(inByte);
}
// read from port 0, send to port 1:
if (SerialUSB.available()) {
int inByte = SerialUSB.read();
Serial1.write(inByte);
Serial.write(inByte);
}
}
now im still getting occasional lockups on the IDE when using the serial monitor, but that’s irrelevent now that I know what pins are what and that the 3 serial ports all work as intended.
also, don’t forget that you can also access the serial monitor/usb via the /dev/ttyACM0 port in linux too 
@ansonhe97 i think what we need to do is to update the wiki with the information i just provided in the previous couple of posts and also. maybe some “hard” documentation on how to access etc. you are welcome to use the above sketches as they are just examples from the library.
It is now a proven fact that with the current released version of the seed library that I have here the serial device names are not what you have said. and still it makes sense to leave them as they are now and not even worry about Serial2 - unless that’s another port broken out somewhere that we can play with 
:
With regards to the seeed library, it is my suggestion that you use the correct serial names and at least document them somewhere.
i’ll settle for the 5G PCIE LTE board
Looking at the SAMD21 datasheet, it appears as though we might indeed be able to have 4 UART ports. I see this:
Up to six Serial Communication Interfaces (SERCOM), each configurable to operate as either:
- USART with full-duplex and single-wire half-duplex configuration
- I2C up to 3.4MHz
- SPI
- LIN slave
I see one each SPI and I2C bus on the 28-header, and SerialUSB is one UART. So Serial1 and (now) Serial makes three serial ports (5 total SERCOMs). So it’s conceivable that there might be a Serial2 after all. That might be a reason @ansonhe97 mentioned it by name in his post earlier today.
TB
ok i did a quick test with /dev/ttyACM0 in cutecom.
Ther’es DEFINATELY issues on the SerialUSB side. Same setup as before but instead of the serial monitor I just used a dumb terminal on /dev/ttyACM0 (which is what it should be connected to as that 's the progrmaming port too). The IDE was NOT running at all during this test and you can see garbage characters being sent out from the device node.
Ah, there you go. There might well be framing errors on that SerialUSB as well?
I’ll need to look through the BIOS some more. There are settings for some of the pins there, but I can’t recall if it was just for the 40-pin header? I’ll look later today. Maybe there’s something tweaky in there about the SerialUSB?
Did you see any framing errors on Serial1? I found all kinds of them there using the LA the other day, so I am wondering if you were able to confirm them on that port as well.
TB
there did seem to be a few on the uart pins until the first CR/LF, but im guessing that’s just half baked buffers.
flushing the buffers is always a good thing to do first off anyway, i just didnt do it in that sketch
Sorry for the misunderstanding again, for my test i’ve used a different board to compile instead of the M0+ mentioned in the wiki. For your reference, i used Seeeduino Zero as my board. To install this board, you can add the following URL to the board manager URL: https://files.seeedstudio.com/arduino/package_seeeduino_boards_index.json
For more, to find out what serial of what board has, you can visit the github page to find such repo and its location, under variant.cpp. So for my test, I checked here: https://github.com/Seeed-Studio/ArduinoCore-samd/blob/master/variants/arduino_zero/variant.cpp
You can see that it’s Serial1 and Serial2.
This caused some issues since we didn’t release schematics due to business aspect but we will consider!
@ansonhe97 @tcbetka i think that’s where the confusion is… you’re using a completely different library to the pone that was mentioned in the wiki. The one i posted earlier is the one the wiki describes to download - as you can see below. it clearly states SAMD-ZERO.
So again… which library are we supposed to be using… the ZERO one or the one you posted about as right now, we are talking two completely different libraries
and then we are supposed to choose the Cortex M0 core:
@ansonhe97 schmatics aren’t necessarily needed, but it would be nice to have more documentation on what ports are what. i’m also still curious as to what the other ttys are for.
@ansonhe97, You are leaving out a lot of very important information from your posts. Also, are you even reading the (only) documentation that we have been provided? As @wx4cb states, both he and I have been following the available documentation to the letter–but now it appears that we haven’t been given the complete picture at all.
So PLEASE update to documentation on the wiki with the information you want us to be using. Otherwise this is really just a waste of everyone’s time.
TB
@tcbetka to be honest i think that the way we have been doing it is fine… I know what devices are on what pins now and with the exception of the monitor issues which are now moot… at least for me, then i will be continuing on coding with the library i’m using as per the wiki unless something changes.
@wx4cb @tcbetka
Sorry for the problems caused, yes we definitely will make the change in wiki today. This is because both boards can be used to compile X86 (SAMD21) but i do apologies for the misleading instructions.
I will update the wiki to the most updated board library for everyone to be on the same page.