Continue to Site

Welcome to EDAboard.com

Welcome to our site! EDAboard.com is an international Electronics Discussion Forum focused on EDA software, circuits, schematics, books, theory, papers, asic, pld, 8051, DSP, Network, RF, Analog Design, PCB, Service Manuals... and a whole lot more! To participate you need to register. Registration is free. Click here to register now.

Register Log in

Some Questions about PIC EUSART

Status
Not open for further replies.
Sajjadkhan

Sajjadkhan

Full Member level 5
Joined
Sep 25, 2010
Messages
307
Helped
17
Reputation
34
Reaction score
16
Trophy points
1,298
Location
Rawalpindi,Pakistan
Activity points
4,199
I am new to these controllers and now i want to learn USART, i have been reading about them but some questions i have which are making me confuse.

1. i have read in "mikroc pro for pic" that it has full duplex asynchronous transmit and receive. but people on the net set the matching baud rate for controller and hyper terminal in PC and using just rx and tx. i think this is not asynchronous. asynchronous is like this: if suppose controller baud rated is slower then pc then if its buffer is full then it should acknowledge the pc to wait and to hold data ( that is to be transmitted) until controllers buffer frees up and same case on the pc side. i was thinking that can i use other pins of DB9 for this purpose like request to send, clear to send etc (though i dont know wat they are for but i am guessing from the name) .

2. the mikroc has defined some routines for uart which handles lots of things in the background like we dont have to set bits in TXSTA register because uart1_init() does that. but what about the errors? forexamle if framming error occurs and and FERR bit is set. there is no routine for handling that right? so i believe that we should do something like this

if(FERR_bit ==1)
//discard that data;
else
temp = uart1_read();

any thoughts?
 

i have read in "mikroc pro for pic" that it has full duplex asynchronous transmit and receive. but people on the net set the matching baud rate for controller and hyper terminal in PC and using just rx and tx. i think this is not asynchronous.
Click to expand...
Well you need Rx, Tx and Ground, but otherwise I would say that this IS asynchronous serial communication, and I think you are mistaken.

Synchronous communication (which USART is also capable of) would have an extra clock signal wire.

if suppose controller baud rated is slower then pc
Click to expand...
Then if the difference is much more than about 5% you have a faulty communication link, only capable of sending garbage. Transmit and Receive baud rates must match for reliable communications.

if its buffer is full then it should acknowledge the pc to wait and to hold data ( that is to be transmitted) until controllers buffer frees up and same case on the pc side. i was thinking that can i use other pins of DB9 for this purpose like request to send, clear to send etc (though i dont know wat they are for but i am guessing from the name) .
Click to expand...
What you are describing is "hardware handshaking", nothing to do with synchronous or asynchronous, as it can be used with both.
if framming error occurs and and FERR bit is set. there is no routine for handling that right?
Click to expand...
Correct. MikroC pro for PIC handles overrun errors, but does not handle framing errors.
 

ok thanks for the reply. so as RX and tx pins operates at 13V so i guess other pins too, right? having said so i see that pind 7 and 8 to be used which are "request to send" and " clear to send". would you explain the other pins 1 4 6 and 9. thanks
 

Sajjadkhan said:
ok thanks for the reply. so as RX and tx pins operates at 13V
Click to expand...
Typically +12v on Tx or Rx line indicates space or 0, while -12v indicates mark or 1.

Any voltage +3v to +15V is interpreted as a space, -3V to -15V is a mark. -3v to +3v is invalid.

This assumes original RS232 spec. The original spec is abused and modified in many modern devices.

CD (carrier detect) and RI (ring indicator) are rarely used any more, but were signals indicating modem and telephone line status.

DTR and DSR originally signalled the status of modem and terminal, but now tend to be just alternatives to RTS/CTS handshakes.

Now you may see why many modern applications just use ground, Tx and Rx. The uses of the other signals were complex enough when they were used for modem links. Now that the other signals are mis-used for many other uses, the meanings have become almost unfathomable.

If you really want to know the "standard" uses for the other signals, then a lot of googling will be needed. But you will probably find information on RS232 use, not the many deviations to the original standard.

Not sure how clear I have been, but a full explanation would fill many books and still be incomplete.

EDIT: A pic will output +5V (or maybe +3.3V) for a mark (1) and 0v for a space (0). The above is the other side of level converter (maybe MAX232 or MAX3232) where RS232 voltages exist. Never connect PIC directly to PC.
 
Last edited:

hexreader said:
The original spec is abused and modified in many modern devices.
QUOTE]

So you are saying modified by modern devices, does that means that at PC side specs are the same and it depends how you want to use them?

DTR (data terminal ready ) which tells that DTE is ready and its port is active (this i believe is use to detect that device is connected or not) where as RTS is about allowing the flow of data, to be sent or not to be sent, and same case with the DSR and CTS. so i dont get it that how both can be used as alternatives?
Click to expand...
 

So you are saying modified by modern devices, does that means that at PC side specs are the same and it depends how you want to use them?
Click to expand...
A PC is a good example of where the spec is sometimes abused. A PC may well accept 0v and 5V signals as 1 and 0, even though spec suggests that 0V is "undefined".

The other lines are as you describe, with RTS/CTS meant for handshaking, while DSR, DTR, CD should remain asserted (+12V) while the link is up and working. I have however seen DSR/DTR used for handshaking before, but I do not think this was the original intention for these signals.

Some devices ignore hardware handshaking completely, either by not even connecting them, or by looping RTS/CTS, DSR/DTR/CD.

You seem to have a good understanding of the proper use of RS232 port, but sadly, serial ports are not always used properly.
 

Well thanks for your time, my orignal goal is to learn USB at the end. but i dont like shortcuts so i thought to start from the scrap. my plan is like this:

Serial connection using DB9 and then connecting different controllers whith one as master and others as slave using this method.
SPI and same thing above
I^2C and same thing above

and then i will jump to USB.

I think that would be a good and solid learning.

If i miss any thing in between then please add to my list. thanks.
 

Status
Not open for further replies.

Similar threads

Part and Inventory Search

Welcome to EDABoard.com

Sponsor

Back
Top