You are on page 1of 8

UART to SPI Bridge

AN49694
Author: Anu M D Associated Project: Yes Associated Part Family: CY8C29xxx,CY8C27xxx GET FREE SAMPLES HERE Software Version: PSoC Designer 5.0 Associated Application Notes: AN2209

Application Note Abstract


PSoC is capable of interfacing with several communication protocols such as UART, SPI, USB, and I 2C. It can serve as a bridge between two buses. This application note demonstrates how PSoCs flexibility is used to configure it as a UART to SPI bridge.

Introduction
Universal Asynchronous Receiver and Transmitter (UART) is an asynchronous serial communication standard usually used in conjunction with RS232 communication protocol. Serial Peripheral Interface (SPI) is a synchronous high speed serial data link that operates in full duplex mode. PSoCs ability to interface with both these communication standards can be used to configure it as a UART to SPI bridge. This makes it possible for a UART to communicate with SPI slave through the bridge. It is particularly useful in applications such as debugging and monitoring SPI slave devices using a PC (HyperTerminal).

Internal oscillator (option to connect external crystal) Set in low power (sleep) mode when not in use

Overview
The UART uses a serial communication protocol for inter processor communication. GPS modules, smart cards, Bluetooth devices, and other devices use this interface for communication. The serial port of a PC also uses UART. The UART to SPI bridge allows these devices to communicate with SPI slave devices such as ADC, RTC, CODEC, LCD, and EEPROM through their standard UART.

Features
The UART to SPI bridge has the following characteristics:

Block Diagram
A block diagram of the UART to SPI Bridge is shown in Figure 1. Figure 1. UART to SPI Bridge Block Diagram

UART burst rates up to 3 Mbits/second SPI operates up to 4 Mbps SPI clocking modes 0, 1, 2, and 3 are supported Firmware selection of SPI clocking modes

UART
RS232 Computer

PSoC
SPIm UART SPI Bus

SPI Slave
SPI EEPROM SPI LCD SPI ADC

Multiple slave selects to connect multiple slaves Configured for 3.3V or 5V operation Programmable GPIOs for added functionality Additional digital and analog resources that can be configured as PWMs, counters, timers, CRC generator, pseudo random number generator, I2C, IrDA ADCs, DACs, multi-pole filters, gain stages, and so on Watch dog and sleep timers
Smart Cards GPS

M8C

Digital Blocks

Bluetooth

Analog Blocks GPIO

November 5, 2008

Document No. 001-49694 Rev. **

[+] Feedback

AN49694

Functional Description
The UART User Module is configured to receive data over the Rx line. This data is transmitted to the SPI slave over the SPI interface. The data received from the SPI slave is transmitted back to the UART master over the Tx line of the PSoCs UART module. The second UART in the system is referred to in this application note as the UART master because it initiates all transactions across the UART to SPI bridge. Some intelligent logic can also be incorporated depending on the application, to analyze the incoming data and perform operations according to the command received. Additional digital and analog blocks can also be configured to function as PWMs, timers, counters, ADCs, DACs, comparators, or other communication peripherals such as IrDA and I2C. Multiple SPI devices are connected to the bridge, making it possible for a single UART to communicate with multiple SPI slave devices.

UART_to_SPI_Bridge Example1
This is a simple example to demonstrate PSoC as a UART to SPI bridge. This program can be modified to meet the application requirement. In the example, the UART master sends data periodically to the bridge. The bridge receives data from the UART and sends it to the SPI slave device. It also sends the data received over the MISO line back to the external UART master.

Placement
The PSoC UART consumes two digital communication blocks: Tx8 and Rx8. The SPI master user module consumes one communication digital block. Digital blocks in PSoC parts are arranged in such a way that each row contains two basic digital blocks and two communication digital blocks. Therefore, any PSoC with two or more rows of digital blocks can be used for this application (for example, CY8C27x43 and CY8C29x66). Parts with single digital rows such as CY8C21xxx, also work with applications where only one way communication is desired. Select the part based on the applications requirement. Refer to application note AN2209 for more information on selecting a PSoC device. In this example, the Tx8 and Rx8 blocks of the UART user module are placed in DCB12 and DCB13 respectively. The SPI master user module is placed in DCB02.

Program Flow
The flowchart of UART to SPI Bridge is shown in Figure 2. Figure 2. Flowchart
Start

Routing
Initialize variables and start user modules

The input and output of Tx8, Rx8, and SPI master can be routed to any of the digital IOs desired using the various row and global interconnects. The input to the Rx8 module is routed from P0[4] via the global input net GIE4 and row input net RI1[0]. The output of the Tx8 module is routed to P1[0] via Row_1_Output_0 and GlobalOutOdd_0 net. Similarly, the SClk, MOSI, and MISO of SPI master are routed to P0[2], P0[3], and P1[4] via the various row and global interconnects.

UART Rx interrupt? Yes

No

Setting the Baud rate


Read data from the UART Rx register and send it over SPI

PSoCs UART supports a maximum baud rate of 3 Mbits/s in burst mode; SPI master supports up to 4Mbits/s. These are burst data rates. The M8C processor cannot sustain these rates. In the example, the baud rate of Rx8 and Tx8 is set to 19200 bits/s. This is done by setting the user module clock source to eight times the desired baud rate. In the example, VC3 is the clock source to Tx8 and Rx8 modules; VC3 source is set to SysClk/1 and VC3 divider to 156.

Read data from SPI Rx register and send it over UART

If only one way communication is desired as in the case of UART communicating to a SPI slave LCD, the Tx8 Module of the bridge can be turned off. This application note contains two example projects. The first one describes how to configure PSoC as a UART to SPI bridge based on a simple project. The second one describes a high level implementation with command based data transfers.

VC 3

SysClk/ 156 153846

Baud Rate VC3/8 19200


The SPI master speed clock source is set to VC1, which is set to SysClk/16(150000) so that the bit rate is VC1/2 (clock/2).

VC1

SysClk/16

1500000
750000

Bit Rate VC1/2

November 5, 2008

Document No. 001-49694 Rev. **

[+] Feedback

AN49694

Interrupts
The UART Tx interrupt can be configured to occur at TX_Complete or TX_RegEmpty condition. The mode of the Tx interrupt is configured by setting the TX interrupt mode in the device editor or by using an API. Enabling the UART-Rx interrupt causes an Rx interrupt to occur on the Rx Register Full condition. The SPI block has a selection of two interrupt sources: interrupt on TX Reg Empty (default) or interrupt on SPI Complete (the same selection as SPIM). If SPI Complete is selected as the block interrupt, the control register must still be read in the interrupt routine so that this status bit is cleared; otherwise, no subsequent interrupts are generated. The Global Interrupt Enable (M8C_EnableGInt) must be set for these interrupts to occur. In the example, only the UART Rx8 Receive interrupt is enabled and a polling method is used to detect the status of SPI transactions.

Test Setup for Example 1


CY3210-PSoC Evaluation Kits along with the projects accompanying this application note (UART_Mater.zip and SPI_Slave.zip) are used to test the UART to SPI Bridge_Eg1 project. This bridge is tested with one PSoC as the UART master and another PSoC as the SPI slave. The UART master sends data over Tx line at regular intervals and receives data from the bridge over the Rx line. The bridge receives data from the master and sends it over to the SPI slave, reads back the received data from SPI slave, and sends it back to the UART master. The SPI slave increments data after each SPI transaction and sends it to the bridge. The SPI slave project and the UART master project displays the transmitted and received data on LCDs. Table 1. Example 1 Connections
Bridge-to SPI Slave Connections SClk MOSI SS MISO Bridge-to UART Master Connections Tx-Rx Rx-Tx Bridge P0[2] P0[3] P0[1] P1[4] Bridge P1[0] P0[4] Slave P0[0] P0[1] P0[2] P0[3] UART Master P0[0] P0[1]

Other Parameters
UART RxCmdBuffer: This parameter enables the receive command buffer and firmware used for command processing. The UART RX interrupt must be enabled for the command buffer to operate. In this example, the RxCmdBuffer can be disabled because the bridge is designed for byte by byte transfers without any logical analysis of data. Some UART parameters such as RxBufferSize, RxCmdBuffer, IgnoreCharsBelow, and IgnoreCharsBelow are set to the default values. These parameters are significant for only command based data transfers and are ignored with the RxCmdBuffer disabled. Some other parameters of the UART such as parity and interrupt type can be set in firmware. The UART can be configured for even, odd, or no parity. The SPI transfer mode can be set to 0, 1, 2, or 3 and MSB first or LSB first using APIs. For example, an SPI master is set to mode 0, MSB first by using the API: SPIM_Start(SPIM_SPIM_MODE_0| SPIM_SPIM_MSB_FIRST); The active low slave select signals, ~SS, must be set in firmware by writing to a PRTxDR register. Slave select control is not part of the SPIM User Module. In the example project, P0[1] is used as a slave select pin. One or more slave select signals can be configured, but only one slave select signal can be active at a time. The drive mode for slave select pins must be set to StdCPU-Strong (in the Device Editor of PSoC Designer). In SPI clocking mode 0 and 1, the slave select must be toggled off and then on again before the next byte of data is transmitted. The ~SS line (for example, P0[1]) is turned low or high by writing a 0 (PRT0DR &= ~0x02) or 1 (PRT0DR |= 0x02) to the appropriate bit of the PRTxDR register.

Connect all devices to a common ground. Connect the LCDs to Port2 of the UART master device and to the SPI slave.

November 5, 2008

Document No. 001-49694 Rev. **

[+] Feedback

AN49694

Example 2
This example demonstrates how to interface a Dallas RTC DS1305 with HyperTerminal using PSoC as a UART to SPI bridge. In this example, the RX8 receive buffer is enabled for a command based data transfer and some logic is employed to analyze the incoming data and take necessary actions.

Commands to the Bridge


Turn on the power supply to the Eval1 board after setting up HyperTerminal.

Slave Select Command


The Dallas RTC DS1305 has an active high chip enable. The slave select signal is active high in this case. The format to select slave1 connected to P2[7] is: S1 P2[2], P2[4], P2[6], and so on are other slave select lines which can be selected by S2, S3, or S4 followed by enter key.

Test Setup
The example project can be evaluated using CY3210 PSoC Evaluation Board, a UART connection to a PC, and data terminal emulation software such as HyperTerminal. Connect a 9-pin Male to Female (one to one RS232) Serial cable from PC's serial port to CY3210-LP EVK Board serial port. Connect Tx and Rx of J13 to P1[4] and P1[5] respectively. Table 2. Example 2 Connections
Bridge-Slave Connections SClk MOSI MISO SS Bridge P2[3] P2[5] P2[0] P2[7] Slave Pin11(SClk) Pin12(SDI) Pin13(SDO) Pin10(CE)

Write Command
Format of the write command is as follows. w <start address> <bytes to be send > The arguments are separated by spaces. The data to be sent must be entered as decimal values. For example: w 128 35 16 69 On receiving this command, the bridge sends 0x80 (hex equivalent of 128) followed by 0x23, 0x10, and 0x45. This command is used to write 0x23 (35) to Reg [80] (seconds), 0x10 (16) to Reg[81] (minutes), and 0x45 (69) to Reg[82] (hours) of the DS1305.

Setting up HyperTerminal in Windows


1. 2. 3. Click Start > All Programs > Accessories > Communication > Hyper Terminal. Enter a name and select OK. In the Connect To pop up window, select Connect using as the port where the serial cable is connected (for example, COM1, COM2); click OK. In the COM properties window (File > Properties) set:

Read Command
Format of the read command is as follows: r <start address> <No. of bytes to read> The arguments are separated by spaces. The bridge sends the start address followed by N dummy data bytes; it reads back data over MISO line and sends it back to the PC where it is displayed by HyperTerminal. For example: r 0 3 This sends 0x00 (start address) followed by three dummy bytes; it reads back the value of registers 0, 1, and 2 and sends it over the UART to the PC.

4.

Bits per second = 19200 Data bits = 8 Parity = None Stop bits = 1 Flow control = None

Sleep Command
sleep This command puts the bridge to sleep. To wake the device from sleep, send a dummy byte (for example, ?) via HyperTerminal. Before putting the device to sleep, the user modules are temporarily stopped and the GPIO interrupt of the Rx pin is enabled. On receiving the dummy data (?), the device wakes up from sleep and restarts the UART operation.

5. 6.

Click OK. Click on File > Properties > Settings > ASCII Setup and enable Echo typed characters locally.

November 5, 2008

Document No. 001-49694 Rev. **

[+] Feedback

AN49694

Interfacing to the RTC


The register map of DS1305 is shown in Figure 3. Figure 3. DS1305 Register Map

Steps to Initialize RTC


1. Set the control register (address 0x8F) with a 0 before writing to any other registers of the DS1305. This is to set WP=0 (disable write protect) and start the oscillator. For example: w 143 0 This writes 0x00 to Reg[8Fh]. 2. Initialize the address locations 0x80 to 0x86 (seconds, minutes, hours, day, date, month, and year registers). For example: w 128 35 16 69 This command writes 0x23 (35) to Reg[80] (seconds), 0x10 (16) to Reg[81] (minutes), and 0x45(69) to Reg[82] (hours). 3. Read the locations 0x00 to 0x06 to update the time and date. For example: r 0 6 Locations 20H to 7FH are general purpose RAM locations. To write to these locations follow the same write command format. 4. 5. To put the bridge to sleep, use the command, sleep . A dummy byte such as ? must be sent to the bridge to wake the device from sleep.

Summary
This application note demonstrates how to configure PSoC as an UART to SPI bridge. The projects accompanying this application note can be modified according to the target application. The programmability and flexibility of PSoC allows the user to add more functionality to the device in addition to the bridging function. Unused digital and analog blocks can be configured as PWMs, counters, timers, ADCs, DACs, filters, and programmable gain amplifiers. Other interfaces such as I2C, DMX512, IrDA, and USB (24x94) can also be added.

November 5, 2008

Document No. 001-49694 Rev. **

[+] Feedback

AN49694

Appendix A
Figure 4. Routing for Example 1 Figure 5. Routing for Example 2

Figure 6. Pinout of Example 1

Figure 7. Pinout of Example 1

November 5, 2008

Document No. 001-49694 Rev. **

[+] Feedback

AN49694

Appendix B: Test Setup


Figure 8. Test Setup for UART to SPI Bridge Example1

Figure 9. Test Setup for UART_SPI_RTC_Example

November 5, 2008

Document No. 001-49694 Rev. **

[+] Feedback

AN49694

Document History
Document Title: UART to SPI Bridge Document Number: 001-49694
Revision ** ECN 2601356 Orig. of Change ANMD Submission Date 11/05/08 New application note Description of Change

PSoC is a registered trademark of Cypress Semiconductor Corp. "Programmable System-on-Chip," PSoC Designer, and PSoC Express are trademarks of Cypress Semiconductor Corp. All other trademarks or registered trademarks referenced herein are the property of their respective owners.

Cypress Semiconductor 198 Champion Court San Jose, CA 95134-1709 Phone: 408-943-2600 Fax: 408-943-4730 http://www.cypress.com/ Cypress Semiconductor Corporation, 2008. The information contained herein is subject to change without notice. Cypress Semiconductor Corporation assumes no responsibility for the use of any circuitry other than circuitry embodied in a Cypress product. Nor does it convey or imply any license under patent or other rights. Cypress products are not warranted nor intended to be used for medical, life support, life saving, critical control or safety applications, unless pursuant to an express written agreement with Cypress. Furthermore, Cypress does not authorize its products for use as critical components in life-support systems where a malfunction or failure may reasonably be expected to result in significant injury to the user. The inclusion of Cypress products in life-support systems application implies that the manufacturer assumes all risk of such use and in doing so indemnifies Cypress against all charges. This Source Code (software and/or firmware) is owned by Cypress Semiconductor Corporation (Cypress) and is protected by and subject to worldwide patent protection (United States and foreign), United States copyright laws and international treaty provisions. Cypress hereby grants to licensee a personal, non-exclusive, non-transferable license to copy, use, modify, create derivative works of, and compile the Cypress Source Code and derivative works for the sole purpose of creating custom software and or firmware in support of licensee product to be used only in conjunction with a Cypress integrated circuit as specified in the applicable agreement. Any reproduction, modification, translation, compilation, or representation of this Source Code except as specified above is prohibited without the express written permission of Cypress. Disclaimer: CYPRESS MAKES NO WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, WITH REGARD TO THIS MATERIAL, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. Cypress reserves the right to make changes without further notice to the materials described herein. Cypress does not assume any liability arising out of the application or use of any product or circuit described herein. Cypress does not authorize its products for use as critical components in life-support systems where a malfunction or failure may reasonably be expected to result in significant injury to the user. The inclusion of Cypress product in a life-support systems application implies that the manufacturer assumes all risk of such use and in doing so indemnifies Cypress against all charges. Use may be limited by and subject to the applicable Cypress software license agreement.

November 5, 2008

Document No. 001-49694 Rev. **

[+] Feedback