Does anyone know if Serial2 can hit 115200 baud rate? I have a project that is working on Serial1 just fine, but when I switch to Serial2.begin(115200) and connect my project to D0(RX) and D1(TX) nothing seems to work. I have already imported the library and I understand that the pins are shared with the RGB led (which I have not disconnected).
Is there any speed limitation by chance on Serial2?
If you suspect a hardware issue, it’d be always good to write a little test sketch to make sure it’s no issue with your own code first.
e.g. a sketch that receives a byte from Serial to send via Serial1 to Serial2 and vice versa and print the result(s) back to Serial.
@ScruffR, the changes to the docs for Serial2 have not be pushed yet. However, I can confirm that the Serial2 pins are NOT D0/D1 but actually the lines going to the RGB Green and Blue LEDs. To use Serial2, the LED current limiting resistors should be removed. Not ideal but possible.
So in order to use Serial 2 we have to remove the current limiting resistors for the RGB LED? But Serial2 does in fact work on the photon correct? When I emailed into Particle before I purchased the photon they said that there is a hardware UART for both TX / RX pins and D1/D0 Pins.
There is a difference here between the Particle Core and Photon products. On the older Core, you could use serial2 on D0/D1 but the Photon is different.
My apologies, I am talking about the Photon. On the photon is Serial2 on the Blue and Green LED pins? Thus to utilize them we have to connect wires to the pads exposed on the bottom and desolder the LED resistors?
Yes, I believe that is correct–check the Photon schematic on github for the final word. If you don’t remove the resistors and effectively disconnect the LED, TX will also drive RX causing problems.
If I am understanding this correctly, in order to use the Serial 2 on the photon:
Remove the 1k ohm resistors on Blue and Green Segment
Connect Serial Device to Blue and Green pads on bottom of photon
Include Serial2.h and initialize Serial2 to override the RGB
And if we want the RGB LED’s back, we must utilize the RGB onChange handler to move the Blue and Green segments to 2 other PWM pins? (we could use D0 and D1?) and connect an external LED
When I am moving the Blue and Green to D0 and D1 using the onChange Handler, I am no longer getting any breathing effects. Is that expected for it to be a stable cyan?
I assume, I will no longer be able to see any firmware level LED colors if I completely disable the internal RGB by removing the 1k resistors?