Unit 6 - Practice Quiz

Serial communication involves transmitting data sequentially, one bit after another, over a single communication line or channel.

The TX pin is used for transmitting data, and the RX pin is used for receiving data as part of the microcontroller's built-in serial communication hardware (USART).

To send a byte of data via the serial port, the value is written to the Transmit Shift Register, which is accessed through the TXREG register.

The Virtual Terminal is a component in Proteus that acts like a serial monitor or terminal, allowing you to view data sent from the PIC's TX pin and send data to its RX pin.

Baud rate is a measure of the speed of data transfer in serial communication, representing how many bits are sent across the communication line each second.

Microcontrollers use TTL logic levels (0V to 5V), while the RS232 standard uses different voltage levels (e.g., -12V to +12V). The MAX232 chip acts as a level shifter to make them compatible.

When a byte of data is received through the serial port, it is stored in the Receive Shift Register, which is read via the RCREG register.

A 'cross-over' connection is required: what is transmitted (TX) by one device must be received (RX) by the other, and vice-versa.

The start bit alerts the receiver that data is about to be sent, allowing it to synchronize its clock with the incoming data stream for that byte.

Direct connection is not possible due to voltage level differences. The DB-9 connector from the PC connects to the RS232 side of the MAX232, which then connects to the microcontroller's TTL-level pins.

The desired baud rate is achieved by loading a calculated value into the SPBRG register, which works with the system clock to generate the correct timing.

Both the transmitter and receiver must operate at the same speed (baud rate) to correctly interpret the timing of the bits. A mismatch will result in garbled or no data.

Full-duplex communication allows for two-way data flow at the same time, much like a telephone conversation. This requires separate lines for transmitting and receiving.

PIC microcontrollers, like most digital logic chips, operate on Transistor-Transistor Logic (TTL) or CMOS levels, where logic low is near 0V and logic high is near the supply voltage (VCC).

The RCIF flag is automatically set by the hardware when a complete byte has been received and is ready to be read from the RCREG register.

COMPIM (COM Port Physical Interface Model) bridges the gap between the simulation and the real world, allowing your simulated circuit to communicate with a real device or terminal program on your PC.

The stop bit marks the end of the data unit (byte) and brings the line back to a known idle state (logic high), ensuring the receiver can detect the next start bit.

The RS232 standard specifies details like voltage levels, signaling rates, and the functions of pins on connectors like the DB-9, ensuring that devices from different manufacturers can communicate.

The TXIF flag is set when the transmit buffer (TXREG) is empty and ready to accept a new character for transmission. Polling this flag prevents overwriting data that hasn't been sent yet.

When you type in the Virtual Terminal, it acts as a transmitting device. The data is sent out from its TXD pin, which should be connected to the microcontroller's RX pin.

The 8-N-1 format sends 8 bits of useful data. However, the total number of bits transmitted for that data is 1 (start bit) + 8 (data bits) + 1 (stop bit) = 10 bits. The efficiency is the ratio of useful bits to total bits transmitted: (8 / 10) * 100% = 80%.

Rearranging the formula: . Plugging in the values: . Therefore, . The closest integer value to load into the register is 129.

The fundamental incompatibility is electrical. PIC microcontrollers use TTL/CMOS logic levels (e.g., 0V for logic 0, +5V for logic 1), while the RS232 standard uses bipolar voltages (e.g., +3V to +15V for logic 0 and -3V to -15V for logic 1). The MAX232 performs this critical voltage level conversion.

Receiving garbage characters when the nominal baud rates match is a classic symptom of a timing mismatch. If the C code calculates the SPBRG value based on a 20 MHz clock, but the PIC's properties in Proteus are set to 4 MHz, the actual transmitted baud rate will be incorrect, leading to framing errors and garbled data.

TXIF is set when the data from TXREG moves to the Transmit Shift Register (TSR), meaning you can now write the next byte to TXREG. However, the current byte is still being shifted out. TRMT is set only when the TSR is empty, meaning the transmission of the previous character is truly finished.

A framing error is specifically defined as the failure to detect a valid stop bit. After the start bit and data bits, the receiver expects the line to be in the idle state (logic '1') for the stop bit. If it's low (logic '0'), a framing error is flagged, often due to timing synchronization loss.

The MAX232 has distinct channels: 'T' channels are drivers that take TTL IN and produce RS232 OUT, while 'R' channels are receivers that take RS232 IN and produce TTL OUT. The PIC's TX (output) must feed a 'T' input, and its RX (input) must be fed by an 'R' output for communication to work.

The OERR bit is not directly writable. The PIC18 datasheet specifies that to clear an overrun error, the user must clear the CREN bit. This resets the receiver FIFO. Any data in RCREG should be read first. After clearing CREN, it should be set again to re-enable reception.

The COMPIM model acts as a bridge. It needs to know how to talk to the real world (Physical Port/Baud Rate) and how to talk to the simulation (Virtual Baud Rate). All these settings must be configured correctly to match the hardware and the simulated microcontroller's code.

A standard 5V MAX232 has a minimum TTL high-level input voltage () of around 2.0V. While 3.3V is above this, noise margin is significantly reduced. A more robust solution is to use a level-shifter designed for 3.3V logic, like a MAX3232, which has input thresholds compatible with 3.3V CMOS logic.

Full-duplex communication uses separate lines for transmitting (TX) and receiving (RX), allowing data to flow in both directions at the same time. This is distinct from half-duplex (two-way, but not simultaneous) and simplex (one-way only).

SPEN (Serial Port Enable) is the master switch for the entire EUSART module and must be set. TXEN (Transmit Enable) specifically enables the transmitter circuitry. Both are required for transmission to occur.

The MAX232's key feature is its ability to generate the required RS232 voltages (e.g., +10V and -10V) from a single +5V supply. It does this using a charge pump, which is a type of DC-to-DC converter that uses capacitors to store and transfer energy to create the higher positive and inverted negative voltages.

If the EUSART module or its transmitter is not enabled via the SPEN and TXEN bits, the TX pin will remain in its high-impedance (or default high) state regardless of any data written to TXREG. This is a common initialization error.

The while(!TXSTAbits.TRMT); line causes the program to halt and poll the TRMT bit until it becomes true. While simple and reliable, this is inefficient as the CPU cannot perform any other tasks during the transmission time. Interrupt-driven transmission is a more efficient alternative.

Flow control prevents data loss due to buffer overruns. When a receiver's buffer is almost full, it can de-assert its CTS line, signaling the transmitter (which is monitoring this line) to stop sending data. It re-asserts CTS when it's ready for more data.

Both PCs (DTEs) expect to transmit on pin 3 and receive on pin 2 of a DB9 connector. To connect them directly, one device's transmitter must be connected to the other's receiver. A null modem cable accomplishes this by crossing over the TXD and RXD lines (pin 2 to pin 3 and pin 3 to pin 2).

The EUSART has a small two-byte receive buffer. RCIF indicates the first level (the RCREG register) is full. If a new byte is fully received into the shift register while RCREG is still full, there is no place for it to go. This condition sets the OERR flag, and the new byte is discarded.

Proteus simulates the timing of every bit. A low baud rate like 300 bps means each bit takes about 3.3 milliseconds. The simulator must accurately model this timing, including the idle time between bits and bytes, which can cause the overall simulation to appear to run much slower than real-time.

In RS232 terminology, 'Mark' represents the idle state or a logic '1' bit, which corresponds to a negative voltage (e.g., -12V). 'Space' represents a logic '0' bit (including the start bit), which corresponds to a positive voltage (e.g., +12V).

The formula is Baud Rate = FOSC / (K × (SPBRG + 1)), where K=16 for BRGH=1 and K=64 for BRGH=0. For BRGH=1 (high speed), SPBRG = (10,000,000 / (16 × 19200)) - 1 ≈ 31.55. Testing integer values, SPBRG=32 gives 18,939 bps (error -1.36%), while SPBRG=31 gives 19,531 bps (error +1.73%). For BRGH=0 (low speed), SPBRG = (10,000,000 / (64 × 19200)) - 1 ≈ 7.14. SPBRG=7 gives 19,531 bps (error +1.73%). The lowest magnitude error of -1.36% is achieved with BRGH=1 and SPBRG=32.

Each byte requires a frame consisting of 1 start bit, 8 data bits, 1 parity bit, and 2 stop bits. Total bits per frame = 1 + 8 + 1 + 2 = 12 bits. The packet has 128 bytes, so the total number of bits to transmit is 128 bytes × 12 bits/byte = 1536 bits. The time to transmit one bit is 1 / 4800 seconds. Therefore, the total transmission time is 1536 bits / 4800 bits/sec = 0.32 seconds, which is 320 ms.

RS232 uses inverted logic with voltages from approx. -12V (MARK, logic 1) to +12V (SPACE, logic 0). A PIC's TTL output is 0V (logic 0) and +5V (logic 1). The PC's RS232 port expects a SPACE (+3V to +15V) for a start bit. The PIC sends 0V, which is in the undefined voltage region (-3V to +3V) for RS232. The receiver will likely fail to detect a valid start bit, leading to a framing error or no data reception at all.

The COMPIM component acts as a bridge between the simulated microcontroller and a real-world serial port. This bridging is not perfectly real-time. The Proteus simulation engine, host operating system scheduling, and driver latencies can introduce significant timing jitter. At low baud rates like 9600, this jitter is a small fraction of the bit period and is tolerated. At high baud rates like 115200, the bit period is much shorter, and the same jitter can cause the receiver to sample the bit at the wrong time, leading to garbled data.

The EUSART has a two-byte hardware buffer (the Receive Shift Register and the RCREG data register). An overrun error (OERR) occurs when a third byte is completely received before RCREG has been read. Even if the software buffer is managed well, if a higher-priority interrupt service routine (ISR) prevents the serial receive ISR from executing promptly, it can fail to read RCREG in time. If the high-priority ISR's execution time exceeds the time it takes to receive two bytes at the current baud rate, an OERR is guaranteed.

A bit time at 9600 baud is . A standard 8-N-1 frame is 10 bit-times long ($1.04$ ms). The observed 1.5 ms low-level duration is longer than a full frame time, which constitutes a "Break" condition. The UART will first detect a start bit, then sample eight '0' data bits, and then fail to find the required high-level stop bit. This action results in receiving the byte 0x00 and setting the Framing Error (FERR) bit. Because the condition persists beyond the frame time, the UART's specialized hardware will also recognize and flag it as a Break condition.

Hardware flow control signals (RTS/CTS) must also undergo the same voltage level conversion as the data signals (TXD/RXD). The PIC's RTS (Request to Send) is a TTL-level output that must be converted to an RS232-level signal for the modem. This is done by passing it through a TTL-to-RS232 driver channel on the MAX232A (e.g., T2IN to T2OUT). The modem's RTS is an RS232-level output that must be converted to a TTL-level signal for the PIC's CTS (Clear to Send) input. This requires an RS232-to-TTL receiver channel (e.g., R2IN to R2OUT).

The Virtual Terminal in Proteus is a TTL/CMOS level device, just like the PIC microcontroller. It expects a high idle line and a low start bit. A MAX232 model converts TTL signals to inverted RS232 voltage levels. Placing a MAX232 model between the PIC's TTL output and the Virtual Terminal's TTL input will present a logically inverted signal to the terminal. The terminal will interpret the high idle line as a constant break condition and misread all subsequent data frames. Toggling the "Inverted" property compensates for this erroneous inversion.

The FERR bit is a read-only flag that indicates the byte currently at the top of the hardware FIFO (in RCREG) was received without a valid stop bit. This flag is cleared automatically when RCREG is read. Therefore, the correct procedure is to read RCREG (and typically discard the value as it is likely corrupt) to clear both the data and its associated error flag from the buffer, allowing the EUSART to proceed with the next incoming byte. Other methods like toggling SPEN or CREN are more drastic resets.

Throughput is calculated by (Baud Rate) × (Data Bits / Total Frame Bits). Protocol A: Frame size = 1(start) + 7(data) + 1(parity) + 1(stop) = 10 bits. Throughput = 115,200 × (7/10) = 80,640 bps. Protocol B: Frame size = 1(start) + 8(data) + 2(stop) = 11 bits. Throughput = 128,000 × (8/11) ≈ 93,090.9 bps. Therefore, Protocol B offers a higher effective data throughput.

The MAX232's internal charge pump is designed to work with small capacitor values (typically 0.1µF to 1.0µF). Using capacitors that are 100 times larger dramatically increases the RC time constant of the charging circuit. While the chip might not be damaged, it will take a much longer time after power-on for these large capacitors to charge to the required operating voltages (approx. +10V and -10V). This can lead to communication failure if the microcontroller attempts to transmit data before the MAX232's drivers are stable.

In all EUSART transmission modes, writing to TXREG loads the data into a buffer. The hardware then immediately moves this byte to the Transmit Shift Register (TSR) as soon as the TSR is empty. The Transmit Interrupt Flag (TXIF) is set to indicate that TXREG is now empty and can accept the next byte. In Synchronous Master mode, the EUSART hardware itself then begins generating the clock on the CK pin and shifting the data out of the TSR. It does not wait for an external clock.

The primary advantage of RS-485 is its use of differential signaling over a twisted pair of wires. EMI from external sources tends to induce roughly the same noise voltage onto both wires simultaneously (this is called common-mode noise). An RS-485 receiver is designed to amplify only the difference in voltage between the two wires, effectively ignoring the common-mode noise. RS-232 is single-ended (signal referenced to ground), so any noise on the signal or ground wire directly affects the data integrity.

This "double echo" is a classic symptom of handling the same event in two different parts of the code. A common mistake is to perform the echo action (writing to TXREG) inside the Receive ISR for immediate response, but also to place the received character into a buffer or global variable. The main() loop then also reads this buffer/variable and performs the same echo action, resulting in the character being transmitted twice. The RCIF flag is cleared by hardware when RCREG is read.

The bit period is . The UART samples at the middle of each bit's time slot. The bits are Start, D0, D1, D2, D3, ..., D7, Stop. The center of the fourth data bit, D3, is at . Time = . The stop bit is the 10th bit in the sequence (index 9). Its center is at . Time = .

The transmitter sends bits at a period of s. The receiver samples at a period of s, or . The character 'U' (0x55) is 01010101 in binary, transmitted LSB-first as data bits 1,0,1,0,1,0,1,0. The receiver samples for its data bits (D0 to D7) at times approximately . In the transmitter's time base, these are . This timing causes the receiver to sample the transmitter's Start bit, D0, D0, D1, D1, D2, D2, D3 bits respectively. For 'U', this results in reading 0,1,1,0,0,1,1,0. Assembling the byte (LSB first) gives 0b00110011, which is 0x33.

The Ring Indicator (RI) pin is the dedicated signal for indicating an incoming call. The ringing voltage on a phone line is a large AC signal that follows a specific cadence (e.g., 2 seconds on, 4 seconds off). The modem's circuitry converts this into a logic-level signal on the RI pin that mimics this cadence. After being converted from RS232 levels to TTL by the MAX232, the PIC will see a digital signal that pulses on and off at a very slow frequency, corresponding to the ring pattern.

The "Virtual Baud Rate" controls the timing of the serial data within the simulation. By setting it to a very high value, the simulated transmission of a byte takes a negligible amount of simulation time. The "Physical Baud Rate" controls the actual rate at which data is sent out of the physical COM port. By setting Virtual to high and Physical to 9600, the simulation is not held up waiting for the slow serial transmission to complete. The COMPIM model buffers the data from the "fast" virtual side and trickles it out at the correct 9600 baud on the physical side, thus decoupling the simulation speed from the physical communication speed.

RS-232 is a point-to-point standard and cannot be used in a multi-drop bus configuration. RS-485 is specifically designed for multi-drop networks. Since the communication is a master-slave poll-response protocol, a single device (master or the polled slave) transmits at any given time. This is the definition of half-duplex communication. A 2-wire half-duplex RS-485 bus allows all devices to share a single twisted pair, minimizing wiring while perfectly suiting the communication requirements and distance.

The core of a software UART receiver is precise timing. After detecting a start bit, the software must sample the line at the exact middle of each subsequent bit period. This is typically done with a timer that generates interrupts. If another interrupt service routine (ISR) with a higher priority executes and delays the timer ISR for the software UART, the sampling point will shift, likely into the wrong bit period. This timing jitter is the primary source of errors in software UARTs and makes them very difficult to implement reliably in a complex system with multiple interrupts. The hardware UART handles all bit timing independently of the CPU.