As per the title really. Is it possible to tell if the Serial Rx pin is HIGH or LOW while it's being used as the Serial port ?
Thanks,
Ian.
You probably can. But what do you want to achieve? Looks like the XY-problem to me 
Have you tried it ?
Why do you want to do it ?
Yes just read it BUT WHY?
Mark
I'm working with an automotive single wire data bus. The transceiver chip (MCP2025) converts the 12v bus line to TTL Tx/Rx levels, but doesn't have any means of managing bus contention. I would like to be able to check the state of the Rx line to make sure there is no traffic on the bus, before writing anything onto the bus myself.
The bus idles high, and the Rx pin always follows the state of the bus line. If the Rx pin is high for more than about 1.5ms, the bus can be considered idle.
I'm currently looping the Rx pin over to another digital pin to see if it's high or low, but I need to use that pin for other duties, hence my desire to directly monitor the state of the Rx pin.
Thanks,
Ian.
Interesting. Let us know if the idea works. It's always useful to have these discussions closed with a description of how the problem was actually solved. Otherwise we only have a list of things that might not have worked.
You can also edit the title of your original post to add [Solved] to the title. Don't edit the content of the post.
holmes4:
Yes just read it BUT WHY?Mark
I was under the impression that digitalRead() doesn't work on pins 0 & 1 when configured as Serial pins.
Ian.
ian332isport:
I was under the impression that digitalRead() doesn't work on pins 0 & 1 when configured as Serial pins.
I don't know the answer to that, but perhaps you could use PINx (I can't remember which Port the Serial pins are on).
...R
ian332isport:
I was under the impression that digitalRead() doesn't work on pins 0 & 1 when configured as Serial pins.Ian.
Maybe you could try it and see.
I would like to be able to check the state of the Rx line to make sure there is no traffic on the bus, before writing anything onto the bus myself.
Even if your idea works what's to prevent the other device starting to transmit at the same time as the Arduino ?
You can indeed still have a collision... What if two devices start listing at the same time and start transmission at the same time?
But a Serial Tx is idle high. If you just connect multiple Tx you end up with a dead short if a device wants to transmit. So maybe just end the transmitting (and returning to a floating Tx) after transmittion?
UKHeliBob:
Maybe you could try it and see.
Even if your idea works what's to prevent the other device starting to transmit at the same time as the Arduino ?
CSMA/CD
But a Serial Tx is idle high. If you just connect multiple Tx you end up with a dead short if a device wants to transmit
I think you deal with that by having a pull-up resistor and diodes to prevent the HIGHs from the other TXs from affecting the Rx pin. The other TXs can then pull the line LOW. (I think).
...R
That's indeed another option. But then reading the Tx pin has no meaning at all about the transmission of the other devices....
UKHeliBob:
Maybe you could try it and see.
I shall.
Even if your idea works what's to prevent the other device starting to transmit at the same time as the Arduino ?
All other devices on the bus have a hardware mechanism that detects the bus has been pulled low, and know not to send anything.
Ian.
But what if that happens at exactly the same time? You can't predict the future...
In practice (I've had this working in the car for over a year now), there are no data collisions. The system is robust enough to handle it without problems. Even if two devices were to transmit at exactly the same time, the transceiver chips have hardware to detect this, and the Tx is disabled.
As it happens, I am using a transceiver chip with hardware contention detection, but I'm writing a library to help other people with similar projects. Most people tend to use the MCP2003, 2004 or 2025 LIN bus transceiver chips that don't have hardware contention detection, but do have short circuit protection if multiple devices were to send at once.
Ian.
MorganS:
Interesting. Let us know if the idea works. It's always useful to have these discussions closed with a description of how the problem was actually solved. Otherwise we only have a list of things that might not have worked.You can also edit the title of your original post to add [Solved] to the title. Don't edit the content of the post.
Despite what I had read:
"Digital Pins 0-1/Serial In/Out - TX/RX (dark green) - These pins cannot be used for digital i/o (digitalRead and digitalWrite) if you are also using serial communication (e.g. Serial.begin)."
You can indeed use digitalRead() to get the state of the Serial pins. I put this line of code in loop():
digitalWrite(13, digitalRead(0));
I was then able to see the LED flash as serial data was received. I also looked at pin 13 with a logic analyser, and was able to confirm that it was accurately following the state of the Rx pin. I still need to run the same test on an actual Arduino, but it works fine on a Teensy 3.1.
Hopefully this info will help someone in the future, even if people question its usefulness.
Thanks,
Ian.
Despite what I had read:
"Digital Pins 0-1/Serial In/Out - TX/RX (dark green) - These pins cannot be used for digital i/o (digitalRead and digitalWrite) if you are also using serial communication (e.g. Serial.begin)."
You can indeed use digitalRead() to get the state of the Serial pins. I put this line of code in loop():
This is not saying that you cannot read the state of the Rx pin, rather that you cannot use the Rx pin for another purpose if you are using serial comms.
It is saying that you "cannot" use digitalRead() but, as I suspected, it is possible to use digitalRead() to read the pin state.
It's just a very rare usage case to try to read a pin which is already being "read" by the UART.