how to use Serial1 on Artemis nano?

Dear all.

I am trying to use Serial1 on pins D9/10 on my Artemis nano board to talk to a sensor and i have some very strange behavior.

If i try :

#define BAUD 115200       // any number, common choices: 9600, 115200, 230400, 921600
#define CONFIG SERIAL_8N1 // a config value from HardwareSerial.h (defaults to SERIAL_8N1)


void setup() {
    Serial.begin(BAUD); 
    Serial1.begin(9600); // set the baud rate with the begin() method
}

void loop() {
  Serial.printf("this print on Serial\n");
  Serial1.printf("this on Serial1\n");
  delay(1000);
}

Then both prints are sent both on physical pin D9 and on the USB console at 9600 bauds. I am using a scope to capture pin D9 and i see both messages concatenated on that pin.

If i now invert the order of initialization of serial ports:

void setup() {
    Serial1.begin(9600); // set the baud rate with the begin() method
    Serial.begin(BAUD); 
}

both prints are sent to pin D9 and USB console (i get both messages on both UARTS again) , but this time at 115200 bauds (on both UARTS)

So it seems that changing baudRate on Serial1 changes Serial and reciprocally. More intriguing , why can is see the output of Serial.printf on the pin D9 using my scope ? How can the ouput of the the Serial.printf command be on two physically separated UART TX pins ?

How do i decouple Serial (which should only be talking to the USB bridge) and Serial1 which should be a hardware UART connected to pins D9/D10 ?

Thank you so much for any clarity you can bring. I purchased that board specifically because i has 2 UARTS (on top of BLE off course :-)) , so i am kind of stuck there

I have tried this on my ATP (do not have a Nano) and can not reproduce it. In the many projects with different Artemis boards (Edge, ATP, Micromod etc) never had this problem. I check the Nano pins for Serial and Serial1 and they are differently assigned. Looks to me like a corrupt board library. Try reinstalling the Artemis 2.2.1 library and see what happens

Thank you so much for your answer Paul. I will try to reinstal the lib and recheck. Will keep you posted

Given that someone else also complained about Serial speed setting I have bought an Artemis Nano.

Compiled your example and … now I got the same problem as you. I could not set the speed for Serial and Serial1 independent from each other and the data is showing up BOTH on Serial as well as Serial1.

I have been able to find the root cause and solution.

An Apollo3 chip has 2 uarts : UART0 and UART1. When a Serial instance is created, based on the provided TX and RX pad, a lookup is performed to decide which UART to use.

First, the Serial-instance is created (TX = 48 / RX= 49) and based on the lookup UART0 is assigned. Then the Serial1-instance is created (TX=39, RX =40), but now DUE TO AN ERROR IN THE LOOKUP TABLE, it is ALSO assigned to UART0.

In the same lookup table (PeripheralPins.c) there are already entries to assign (TX=39, RX =40) to UART1. So I commented-out the 2 lines that enable UART0 assigment. Serial1 is now assigned to UART1 and it now works as expected.

The change requires a new Artemis-Nano pre-build archive for Mbed, which I have created.

Go to  the directory :

Windows :  <userdir>\AppData\Local\Arduino15\packages\Sparkfun\hardware\apollo3\2.2.1\variants\SFE_ARTEMIS_NANO\mbed

Ubuntu/Linux:~/.arduino15/packages/SparkFun/hardware/apollo3/2.2.1/variants/SFE_ARTEMIS_NANO/mbed

There is the archive file called libmbed-os.a.
If you want you can make a safety rename or copy.

Now UNZIP the attached  libmbed-os.zip in this folder to get a updated  an libmbed-os.a and recompile your sketch .
 All should be working now.

Note 1: Why I did not see this on any of the other boards ? Because they use TX=24 / RX=25 for Serial1, which in the table can only be assigned to UART1.

Note 2: I have made a github bug report : https://github.com/sparkfun/Arduino_Apollo3/issues/474

libmbed-os.zip (1.94 MB)

Could this explain why, after defining my SDA and SCL as D10/D9 in the Apollo 3 I2C example, my INA219 sensor is detected when it is wired to Nano pins 6/7?

no, but I will answer this on your original post not to mix topics.

Thanks

paulvha:
Given that someone else also complained about Serial speed setting I have bought an Artemis Nano.

Compiled your example and … now I got the same problem as you. I could not set the speed for Serial and Serial1 independent from each other and the data is showing up BOTH on Serial as well as Serial1.

I have been able to find the root cause and solution.

An Apollo3 chip has 2 uarts : UART0 and UART1. When a Serial instance is created, based on the provided TX and RX pad, a lookup is performed to decide which UART to use.

First, the Serial-instance is created (TX = 48 / RX= 49) and based on the lookup UART0 is assigned. Then the Serial1-instance is created (TX=39, RX =40), but now DUE TO AN ERROR IN THE LOOKUP TABLE, it is ALSO assigned to UART0.

In the same lookup table (PeripheralPins.c) there are already entries to assign (TX=39, RX =40) to UART1. So I commented-out the 2 lines that enable UART0 assigment. Serial1 is now assigned to UART1 and it now works as expected.

The change requires a new Artemis-Nano pre-build archive for Mbed, which I have created.

Go to  the directory :

Windows : \AppData\Local\Arduino15\packages\Sparkfun\hardware\apollo3\2.2.1\variants\SFE_ARTEMIS_NANO\mbed

Ubuntu/Linux:~/.arduino15/packages/SparkFun/hardware/apollo3/2.2.1/variants/SFE_ARTEMIS_NANO/mbed

There is the archive file called libmbed-os.a.
If you want you can make a safety rename or copy.

Now UNZIP the attached libmbed-os.zip in this folder to get a updated an libmbed-os.a and recompile your sketch .
All should be working now.




Note 1: Why I did not see this on any of the other boards ? Because they use TX=24 / RX=25 for Serial1, which in the table can only be assigned to UART1.



Note 2: I have made a github bug report : [https://github.com/sparkfun/Arduino_Apollo3/issues/474](https://github.com/sparkfun/Arduino_Apollo3/issues/474)

There might be a bug in this build that causes the BLE address to become fixed. I was experiencing the glitch where multiple Artemis units have the same BLE MAC address and muscle each other out of the way and leave it random which device I’m connecting to, and when I ran the same code on another PC that seemingly didn’t have this fix, the BLE MAC problem was cleared up.

Correlation doesn’t necessarily mean causation, but I thought I’d bring it up