Using Arduino as a uart

I want to write a gateway for RS-485 unclocked synchronous serial data. This means that I poll a data pin watching for state transitions, handle synch characters and when I collect a byte, I write it somewhere.

I will be polling the data pin at a very high rate. I want to know if a serial write is done synchronously or asynchronously. That is, when I do a serial write, do I lose control of the processor or is there a uart that handles it for me.

thanks,
Roger

I believe the data is sent somewhat synchronously in that the code hands the characters off to the hardware UART and then waits for the send to complete, etc.

Regardless, you should be using interrupts to monitor the data pin state. Then you won't have to worry about the critical timing.

Wow, thanks for the prompt reply.

That would be fine on output but if all I monitor is pin state change, how do I handle two bits with the same value? Two bit times have gone by with no state change. I need to poll the data pin at regular intervals. Can I set a timeout interrupt for polling my data pin state?

I am new to arduino but one thought I had was hooking two together. I use one processor just to poll my input. Then, when I have a character to send, I set 8 pins high/low for the byte value and then set a 9th pin high to tell a second processor to pick up the character. Then I let the second processor queue the character and do the write.

The cost of two arduinos is no big thing in this case. By the way, how fast can I poll a single pin for something like this?

thanks again,
Roger

Well I misread your original post a little and thought you had a clock signal for your data line. In that case you'd put the interrupt on the clock pin and read the data pin state at clock transitions.

If you're using sychronous serial without a clock line, how do you expect to sychronize the transmitter/receiver? With async serial you get the advantage of a start/stop bit to get things in sync. Sychronous serial assumes the transmitter and receiver are "in sync" some way and mutually know when the bit boundaries occur.

Therein lies the dilema. The way this protocol works is that the transmitter and receiver are both configured to a baud rate. Each frame starts with three pad charactes of 0xfe. When the first state change occurs, the receiver starts it's clock. First it waits .5 x baud rate to position itself to the middle of the bit. Then it starts polling the receive pin every bit time. Inevitably, they will go out of synch but not before the (fairly small) frame is complete. As you can imagine, rhythm is very important. I can't allow a serial write to delay my loop.

The protocol is a polled protocol with a master and some number of slaves. The master polls a slave by address and the slave has some amount of time to respond.

As you might imagine, there is very little hardware out there commercially that can do this.

This protocol gets better. Sender and receive happen over the same pin. When the Sender is finished, it goes to 0 volts so the receiver can become the sender. This actually makes my life easier since all I want to do is monitor the line.

That's why I was thinking about using two arduinos.

It sounds like you could do this with an pin-change interrupt (to catch the initial state change) and with hardware timers. In the initial pin-change interrupt you would enable the hardware timer with an appropriate prescaler and count that matches your bit interval as closely as possible. When the timer reaches the specified interval it'll fire an interrupt. In your interrupt handler for the timer event you would check the state of your data pin to determine the bit value.

Since you're relying on a hardware timer and not a tuned timing loop, you won't be affected by outbound serial through the UART (or anything else). The worst that could happen is that your timer interrupt is delayed a few cycles while another hardware interrupt is firing (or if some code temporarily disables interrupts). In that case only that bit interval will be delayed (hopefully not past it's window) and the timing will be back on track for the next timer interrupt.

You never specified the baud rate so this could be complicated by high speeds. High speed means short bit delay so it may be difficult to find a good enough timer prescaler and count to match. Also any delays in the bit timing due to other interrupts become more significant. At 57600 baud the bit delay is only about 17us. Thats only about 278 clock cycles for a 16MHz chip. If you're working at lower speeds then things become much more doable.

Here's a page I found useful when looking into hardware timers in the past.