Description
Trying to reconfigure the serial port in use by the Nordic nRF51-DK seems to be inconsistent:
If I use the Blinky example as follows, it will not start to output data on pins p12 and p13 of my nRF51-DK board. On mbed Classic, this seemed to work fine, albeit the various issues with non-connected hardware flow control, which seem to be endemic to the Nordic chips.
The method calls to anotherPort
end up changing the baud rate of communications to the serial port connected to the /dev/ttyACM0
device, and printing to the mbed ACM device.
#include "mbed.h"
DigitalOut led1(LED1);
Serial anotherPort(p12, p13);
// main() runs in its own thread in the OS
// (note the calls to Thread::wait below for delays)
int main() {
anotherPort.baud(115200);
anotherPort.printf("Start.\n");
while (true) {
led1 = !led1;
anotherPort.putc('*');
Thread::wait(500);
}
}
Another issue I've seen with this exact code is that the serial data indeed would be emitted via pins p12 and p13 of my nRF51-DK to a receiving device on /dev/ttyUSB0
. Yes, that's right, same code, two completely different behaviors.
Also, more troublingly, the board could be induced to hang by playing with the DTR and RTS pins on /dev/ttyACM0
. I could have two instances of CoolTerm open, and twiddling those pins in one window would cause the other window to stop seeing asterisks being transmitted.
I'm wondering if this is a static initialization order issue of some kind...