UART and RS232 are same protocols or not?If yes then why we called RS232 is a interfacing standard.Is the Protocol and interfacing standard same?
UART (universal asynchronous receiver/transmitter) refers to a hardware device for serial data transmission where the timing is recovered from the data frame. A frame has a start bit, data bits, optionally a parity bit, and a stop bit (or bits). The start but synchronises the bit sampling for the rest of the frame.
RS-232 refers to a series of related standards for the electrical interface and signalling of a specific serial interface. While the output of a UART will be at the logic level of the UART device, RS-232 defines specific voltage levels, so when a UART is used to implement an RS-232 interface, an RS-232 level line driver is required. RS-232 line levels are bi-polar (the logic states are negative and positive voltage), while UART will have logic levels of zero and some positive voltage.
Full RS-232 includes additional signal lines apart from serial Tx/Rx some of which (such as flow control) may be provided by a UART and others such ring indicator that would be provided by other logic such as GPIO. A minimal RS232 implementation (three-wire mode) requires Tx, Rx and Ground.
A UART might be used for other interfaces such as RS-422, RS-485, and for short distance chip-to-chip communication may be connected directly UART to UART. So UART and RS-232 are certainly not the same thing.
In the OSI 7-layer model for communications, RS-232 covers only Layer 1 - Physical Layer. A UART is merely a means of implementing part of such a physical layer.
So with respect to "protocols" RS-232 is a pysical layer protocol only - it does not define any semantics to the data being transmitted. A UART is not a protocol at all, but a digital electronic device for implementing a number of types of physical layer communications.
UART is a piece of translation hardware, not a protocol. they can work with many serial/parallel communications protocols including but not limited to RS232
RS232 is an electrical standard, not a protocol. Just like RS485, rs422 and others, all of which can carry the same serial protocol.
The output of an UART are UART frames. Frames are defined at the OSI layer2 Data Link Layer. So RS2-232 is a little bit more than Layer1 OSI.
RS485 and RS422 are working on LAye1 only because the rest of the communication will done by upper layer protocols such as Modbus or PROFIBUS for example (Layer2 and Layer7)
Peter The Netherlands
Related
I'm a beginner in the embedded system development world.
I would like some clarifications on the following questions.
Is every pin of a microcontroller (from here after referred to as mc) associated with a register?
Is it an one to one relationship?
How are ports (or groups of pins) assigned inside the mc?
Is it only possible to set a single pin low or high only?
No. Some pins are not associated with a register at all, e.g. Vcc and GND and if they do not have a dual use as a GPIO it also applies to clock/oscillator and reset pins.
If a pin is associated with registers, it is usually associated with several ones: one for determing the IO direction, one for reading the input, one or more for setting the output. For I2C, SPI, UART pins, the associated is indirect, i.e. the register mainly control the I2C/SPI/UART controller, which in turn is associated with the pin.
I don't understand the question
A GPIO pin can be set as input, as output in high state (delivering current or with a weak pull-up), as output in low state (sourcing current or with a weak pull-down) or in open-drain state (often similar to input mode). A pin can also be configured to be used by one fo the I2C/SPI/UART controllers or as DAC (outputting a variable voltage between GND and Vcc).
In addition to fundamental stuff like supply and clock pins, a MCU got numerous hardware peripherals internally. A hardware peripheral being something like a piece of GPIO (general-purpose input/output), ADC, UART, SPI etc. Each such hardware peripheral has a number of possible pins to which its functions can be routed.
Traditionally, these were pretty much fixed - if you wanted UART Tx then you would always get it on some fixed pin number, take it or leave it. Nowadays, most MCUs are quite flexible internally, allowing you to re-route hardware peripheral functionality to almost any pin you like, variably.
In either case, several hardware peripherals could share the same pin, and then it is MCU specific which one that takes precedence. For example GPIO could be present on the pin by default, but if you enable UART then maybe the MCU states that you get UART Tx on that pin instead.
As for the hardware peripheral called GPIO, they are almost always grouped in ports, where each port consists of a number of pins. Most often, port registers are either 8 bits or the size of the CPU's word length. Each bit in the various port registers corresponds to a pin.
You'll have a port data register, which is the actual read/write to the pin, a data direction register stating input or output, and then various other registers for interrupts, pull resistor enable etc etc.
Not all pins but all IOs (Input/Output) have a specific register.
Each IO has a specific group of registers. Bu also some registers may include specific bits which effects an IO or all IOs.
It depends of design of micro controller.
Yes it is.
I strongly recommend you to read some embedded hardware/software books(for example Newness Know It All books for embedded systems) and datasheets.
I'm a newbie in embedded programming.
Now I'm trying to understand a datasheet for Telechips 8001S.
What is the difference between SPI(Serial Peripheral Interface) and GSB(General purpose Serial Bus)?
Thank you.
google is your friend...
Telechips GPSB appears to be their spi implementation (and one or more other serial protocols) master or slave with dma. Spi is the protocol, call it a standard or not but there are a large quantity of devices that support it, GPSB is the logic/peripheral in the chip that you can use to connect to spi masters or slaves (you can always bit bang on gpio of course). Looks to have dma and probably other features.
I didnt find the 8001 nor the 8010 docs, but did find one that was enough to understand.
On some ti products you may find the USI, universal serial interface, the name for their uart, spi and i2c peripheral.
Some ftdi chips have MPSSE, which can be programmed to implement quite a few protocols, jtag, spi, i2c, mdio, roll your own.
Other vendors may simply call the peripheral UART, SPI, I2C.
Its just a name that marketing or engineering or a combination of the two at that company chose for the peripheral within the chip.
I am looking at the pin-out here: http://www.ti.com/lit/ml/slau536/slau536.pdf and can't find p1.0 and p1.1. Where are they?
The reason (perhaps, stupid) why I started looking for these two pins is because I need to connect RX and TX of a UART somewhere on the launchpad, and p3.3 and p3.4 did not work, and on some loosely related pinouts of other boards such as this: http://energia.nu/Tutorial_DigitalReadSerial.html p1.1 is RXD and p1.2 is TXD (not sure what's the difference between RX and RXD, assuming for now they are the same). So I thought maybe I try these pins and try my luck there? And now I can't find them.
BTW, the pinout shows that p3.3 and p3.4 are UART RX and TX on BoosterPack standard, which I don't have, and on the launchpad these pins are UCA0RXD and UCA0TXT (also, they are apparently UCA0SOMI and UCA0SIMO). I don't know yet what these abbreviations mean, and also, why there are two sets of functions on the same pins and how to switch between them.
My launchpad (in subj) documentation says it supports up to 4 hardware UARTs. Where? And why then is there a UART on booster pack?
Maybe p1.1 and p1.2 are taken for the launchpad's onboard backchannel UART?
If you want to know where every pin goes on this board then you should look at the schematic in the User's Guide. But more importantly, you should get familiar with the datasheet for the microcontroller on the board.
You don't see P1.0 and P1.1 because those pins are not brought out to the booster pack headers (connectors). Those pins are used within the launchpad board for something else. (They are not even UART pins as you hoped.)
P3.3 and P3.4 is the only UART connection that you have available through the booster pack headers. The other UART is on P4.4 and P4.5 and those pins aren't brought out through the headers. So you should probably try to get P3.3 and P3.4 working. Did you download TI's example software for this launchpad? There is probably an example program that uses the UART.
P3.3 and P3.4 are multiplexed as are many GPIO pins on typical microcontrollers. These particular pins can be configured as GPIO, a UART, or an SPI port. SOMI and SIMO are abbreviations related to the SPI function. Your code will have to configure these pins for the UART function. Read the datasheet and study the example software to learn how to do this.
I'm not sure where you saw four UARTs. The microcontroller on this particular launchpad has four serial interfaces but only two of those interfaces are designed for UARTs. The other two serial interfaces can be SPI or I2C.
I am examining a way to connect two microcontrollers. On the level of serialization I am thinking of using Nano protobuffers (http://code.google.com/p/nanopb/). This way I can encode/decode messages and send them between two processors.
Basically, one small processor would be the RPC server, capable of doing several functions. Bigger processor will call there RPCs via messages sent, and then when data is ready, it will read it from smaller processor.
What would be the pros/cons of using UART, I2C or SPI?
Messages will be put in the mailbox que prior to sending.
It depends on your total requirements and how expensive are pins.
I2C only needs two pins, but it's slow and to handle it with or without interrupts is a pain, even with the build in peripheral modules.
It's a master/slave system, it's good for controlling many slow devices like temp sensors.
Only two lines for all bus devices, the selection is done via an I2C-Address in the protocol.
Uart needs two pins, it's normally faster, easier to handle, but requires (nearly) the same clocks at both sides.
One to one asynchronous system, can be good if both systems needs to be send sometimes data without waiting for a master poll request.
Can also be used as a bus system, but then you need a master/slave structure or more complex protocols.
SPI needs 3 (or 4 with CS) pins, it's the fastest, simple to implement even with DMA, low cpu time overhead, often buffered.
When you have enough free pins I would prefer it.
All of these interfaces have pros/cons.
UART connection in it's basic functionality requires 2 pins: RX and TX. The SW implementation of how to message over that UART is quite a bit more complicated...you'll have to develop your own messenging protocol between the devices and decide what is a good message and what is a bad message. It could get quite complicated because you pretty much have to define how to "communicate" over the physical link, what is an error, retries, etc. Unless you are implementing a serial port connection to a PC or some other external device, I think a UART is highly overkill for a IC to IC communication path. Master and slave are not specifically defined.
SPI is a master-slave relationship and can be a faster interface (I've seen up to 60MHz clock rates, not common) but it also requires more pins, 3 at a minimum for a point-to-point communication scheme but the number of pins increases to 3+n as the number of "slaves" increases above 1. There are no error indications via SPI. SPI is a "de-facto" standard...meaning it can vary in implementation...your mileage may vary depending on how a IC supplier defined "their" SPI implementation. I generally consider the lack of a true standard for SPI to be a "con".
I2C is also a two pin interface and is an actual "standard" developed by Phillips (now NXP.) As a standard, it is well-defined in how it operates, how errors are raised, and is simple to implement. It has an addressing scheme, can send commands, and can support 0 or more data frames in a transaction. CRC (optional) and higher data rates can be supported (up to 5Mbits.) It does have cons, namely bus capacitance can limit actual data rates (rise/fall time) but generally you can design around this "problem".
In their most basic forms, all of these busses are "ground referenced"...and can suffer from system induced noise. Obviously, lower rail voltages can make this even more of issue. Again careful design practice can mitigate many of the problems some people report to be the bain of their existence.
For the point-to-point system initially asked by the poster, if a master-slave arrangement is required, a SPI or I2C interface may be appropriate (data rate dependent.) If a master-master relationship is required, I2C or UART may be required.
For ease of implementation from a software point of view, I'd rank these communication methods in the following order:
I2C, if you need faster data rates than I2C can handle, then SPI
SPI, if you need multi-master, then I2C or UART
UART as a last resort...has a lot more software overhead to manage the communications channel
I would use UART or CAN or ETH or any protocol that is asynchronous.
If you use a synchronous protocol, the master must always "ask" the slave if it has data and generate unwanted traffic.
I am working on a project which requires transfer of signals from external world to computer.
I have a source which generates analog signals, and this signal needs to be transmitted on the PC, via USB.
Here is my question:
What is the interfacing?
The analog signal which I get from the source, do I have to convert it into digital using microcontroller and then transmit via USB, or we can transmit the analog signal as it is through USB?
Also I tried cutting the USB wire and found 4 wires inside: V+, V-, Data+, Data-.
What is the significance of Data+ and Data-?
Data+ and Data- are wires of differential pair, which is used to transfer digital signal.
You cannot use them to transfer analog signal.
The simplest solution is any Arduino board, with AVR microcontroller and UART-to-USB converter (UART is much simple then USB). But actual solution depends on performance you need.