Using RX when Serial is in use

Hello,

I have a device Iā€™m sending serial data to using Serial1 on TX. I donā€™t have to receive anything. If I have the Serial1 channel open by using Serial1.begin is RX blocked by the channel or can I use it as a GPIO? Iā€™m on my last pin, already lost A4 due to SPI MISO which I don;t use but itā€™s held high if the SPI is on :smile:

Thank you

1 Like

Have you tried this yet? Connect an LED or something to RX and try to turn it on and off while Serial1 is open.

You should be able to control RX as long you set pinMode(RX, ...) after Serial1.begin().
You could also try Serial1.halfduplex(true)

And just to make sure you are already using A6 (DAC) and A7 (WKP)?

For curiosityā€™s sake, what happens to A4 when you set pinMode(A4, ...) after SPI.begin()?

1 Like

Thank you for the help :smile:

Unfortunately all my photons are in the field and until the robots return I canā€™t test. I wanted to design a new board before the next competition and I needed every pin I could get.

Thank you ScruffR, I will include RX as well in the pin list and hope I can use it as you recommended. Yes, both DAC and WKP are used. I didn;t want to mess with pinmode-ing A4 since I have 3 SPI devices and I would have to reset the mode after every transaction. I had enough room for a SPI Port expander a SPI TFT and the SPI SD_card pin on the board and Iā€™m out :smile: Using RX is a great advantage.

Iā€™ll report back after I test the whole thing, thank you again

@ScruffR

Now that my photons are back and the new board is ready I verified your suggestion and unless I'm doing something stupidly wrong, I can;t use RX after serial1 has begun even if I set it to half duplex and/or change its pinmode. The RX and TX pins appear to be frozen after the Serial initialization. Am I missing something or is there anything else I can do or do I have to design a new board? :frowning:

Without Serial1.begin the RX/TX pins output the correct voltages in this basic test.

int led1 = RX;
int led2 = TX;

void setup() {

Serial1.begin(9600);
Serial1.halfduplex(true);

pinMode(led1, OUTPUT);
pinMode(led2, OUTPUT);

}

void loop() {
pinMode(RX, OUTPUT);

digitalWrite(led1, HIGH);
digitalWrite(led2, HIGH);

delay(2000);

digitalWrite(led1, LOW);
digitalWrite(led2, LOW);

delay(2000);

}

With the standard Wiring functions pinMode() and digitalWrite() you have some extra ā€œsanityā€ checks in place that prevent ā€œwrongā€ usage of pins.
But when you know what you are doing, you can bypass these checks and still get your job done :wink:

void setup() {
  Serial1.begin(9600);
  Serial1.halfduplex(true);
  HAL_Pin_Mode(RX, OUTPUT);
  pinMode(D0, OUTPUT);
}

void loop() {
  digitalWriteFast(RX, !pinReadFast(RX));
  digitalWriteFast(D0, !pinReadFast(D0));
  delay(1000);
}

You can check this with the on-board LED by just bridging RX or D0 to D7.

BTW, having this checked before ordering a PCB would always be a clever move :sunglasses:
Having said this, what I stated above about Serial1.halfduplex() only would apply to RX anyway, TX will be the one pin where RX & TX transfer takes place, so no point to do the led2 stuff in your code.
And youā€™d need to test whether the RX action has any negative side effects on the half-duplex communication.

Iā€™ll test it, thank you :smile:
Iā€™ve seen enough good solutions from you to trust you without checking :stuck_out_tongue:, plus I had no access to my photons for a while.

I know I can;t use TX, I was just testing the output from both pins for science :smile:
. Is there any protocol difference in half duplex mode other than using the same pin for both directions? I have a pretty iffy H-Bridge that prefers very ā€œclassicā€ serial communication.

AFAIK some half-duplex devices need an extra signal to tell them data will be coming by sending a break signal (e.g. SRF01)
This is what I think the LIN_BREAK_ constants are for, but I haven't found any documentation I could make sense of for myself, so I wrote my own ParticleSoftSerial library to do half-duplex :wink:
https://prerelease-docs.particle.io/reference/firmware/photon/#begin-

You shouldn't - I'm clueless but know how to disguise it :sunglasses:

1 Like