The UART RF Controller

Overview of UART

The basic idea behind a UART connection protocol is that communication can occur without the use of RTS (Request to Send) and CTS (Clear to Send) signals. In fact, no syncronization is required at all ideally for a UART connection. The RX (Receive) and TX (Transmit) lines operate on a high-low basis where '1' represents high and '0' represents low.

- The TX line remains high normally - idles in this mode. This means that any device connected to it can assume a continual high signal means no data is being transmitted.

(Low power devices can use an inverter on the input of the TX/RX lines in order to save the power associated with holding high for long periods of time.)

- When data wants to be transmitted, the transmitting device will bring the TX line low for one clock cycle. This start bit tells receiving devices that the next bit sent will be valid data.

(Here one clock cycle is defined with respect to the actual device being used. Thus, if you are using a FPGA and say an RF Transceiver then one clock cycle here is defined as the maximum speed the RF Transceiver can reliably send data at, i.e. the baud rate of the device not the speed of the FPGA.)

- Some implementations of UART can have an associated stop bit with data transmission. This bit is normally high and immediately preceeds the 8 bits sent (and any parity bits sent along with the data).

Overview of the RF Controller

There are a couple important notes to mention regarding this particular implementation of a RF Controller. It uses the TR-916-SC-PA-ND RF Transceiver from www.digikey.ca, which is produced by Linx Technologies. Careful examination of the data sheet reveals important information.

1. Transmission up to 33,600bps
   
   -FPGAs typically operate in the nanosecond range.
   -33,600bps converts to ~29.76 microseconds.
   -Values sent and received will need to be slowed down.
2. Input range of 2.7 to 13 VDC; Required 10-19 mA current requirement.
   -Current and voltage requirements are low, however may come into factor when more than one device is connected to the FPGA.
   -Design for minimum voltage and maximum current drive to ensure correct operation.
3. Operates as half-duplex
-Only one way communication can happen at a given time.
-Is there a possibilty for collisions or lost data?

• Power-on to Valid Receive 6-8 ms
• Power-on to Valid Transmit 3-5 ms
• RX to Valid TX Switching 3-5 ms
• TX to Valid RX Switching 4-6 ms

Different timing requirements for each mode means that optimizing transmitting and receiving should be optimized. Transmission time for one byte at maximum baud rate will typically be 240 microseconds (i.e. 25 bytes could be transmitted during the worst case switching time of 6 ms).

The speed of the device between transmitting and receiving must be slowed down some how to cope with the switching times.

Power Up and Receive States

One implementation of the RF Controller (to eliminate slowing down to 33,600 kbps) would be to create a clock multiplier that would make a new clock to operate at this speed. This is bad practice since other devices may be hooked up to this same clock and cause major problems. Thus, values must be held using a counter (while in a given state).

Handling of the power-up time variation occurs using a custom made 'largecounter'. This variation of a counter was implemented since the amount of hardware increases with the size of the counter. The code is found here as part of the RF controller package. The counter expects two input numbers which form the expression N = (input1*input2)-1 where N is the value to count up to. The inputs are given as std_logic_vectors.

Idle state for this device is the receive state (waitRX and waitRX0).

It idles while the shifter s2p gets a value of "11111111". This is how the UART protocol is detected. The exit condition for waitRX0 is when s2p gets "11111110" signifying the detection of an incoming transmission (due to the appearance of a start bit).

If at any time while in the idle states a Request to Transfer occurs (signified by the two arrows pointed right) then the controller switches to the Transmit State. If waitRX enters its state with CurrentMode set to '0' then it proceeds to the waitRXtopowerup state. This means the device has just finished transmitting and must return to the idle states. Thorough explanation of both of these operations follows.

After receiving a start bit, the RF controller must begin sampling the input signal for data. Due to the analog nature of any RF device there will be a transition time associated with the rise and fall of a signal. Therefore, the best time to sample a given data bit is in the middle of transmission. This time is approximately known since transmission occurs at a baud rate already established (I say approximately since the detection of the start bit could have occurred during the transition time). The following picture illustrates this idea of sampling. As you can see there is a short period where values may be interpreted as either 1 or 0. This is the period we want to avoid.

The RXstateStart1 and RXstateStart2 states cause a delay in the sampling of Half the Baud Rate to achieve the best sampling. The reason for the extra states (1 vs. 2) is described below

Now the controller can start receiving valid data bytes in the RXstate1 and RXstate2 states. It remains in the RXstate2 for a Full Baud Rate. It then checks to see how many bits it has received and cycles through RXstate1 -> RXstate2 until 8 bits are received from the input data line.

All data is received MSB first. Once 8 bits are received the controller proceeds back to the waitRX state.

Transmit States

Entrance to the waitTX state is accomplished by the condition that the device is not currently receiving a message and there has been a request to transfer data. For interest sake, a request to transmit is accomplished by setting RequestTX high - the controller checks the first bit of the D storage buffer (from CPU) to see if there is 'valid data' (i.e. a one).

It is important to note here that the waitTX and power_upTX1 states are the same. The rationale for designing the controller this way is for ease of future modifications and reusability. The waitTX state allows one to modify the idle state to transmit if such a need occured. Mirroring the receive and transmit states in this fashion allows for easier modification. It is not considered a waste of a state since one clock cycle in the grand scheme of things is insignificant.

Just as the power up time is a factor, the switching time from RX to TX must be handled. Here that is done by the power_upTX1 and power_upTX2 states.

To establish the UART protocol correctly the next step is to pull the transmit line low for the Baud Rate. This is done in the TXzerobit1 and TXzerobit2 states. (Up until this point, the transmit line is forced to output high to ensure that no values get interpreted as valid data.)

Data transmission occurs upon entering TXstate1 and TXstate2. Bits get shifted out one by one MSB first. The states continue to cycle when 8 bits have not been sent out. The value of each bit is still held for the Full Baud Rate.

The bottom line signifies leaving the TXstate2 and re-entering the waitRX state. This is where CurrentMode comes into play.

CurrentMode

Second State Names

There are a number of cascading states that make use of the ability of the counter to reach large values. This must occur every time the device switches modes, needs to count for Half the Baud Rate, or count for a Full Baud Rate.

Early simulations (without double the states) indicated that the counter did not get reset fast enough for the timeoutDone value of '1' to get pulled back down low. This caused the state machine to cycle through states without ever reseting the value in the counter.

Code Reference