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
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 Using RX is a great advantage.
I’ll report back after I test the whole thing, thank you again
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?
Without Serial1.begin the RX/TX pins output the correct voltages in this basic test.
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
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
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
I’ve seen enough good solutions from you to trust you without checking , 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
. 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 https://prerelease-docs.particle.io/reference/firmware/photon/#begin-
You shouldn’t - I’m clueless but know how to disguise it