Need help sending 2 bytes!

Need help sending 2 bytes!

Postby Sickness6 » Mon Aug 11, 2014 11:14 pm

Hello,
I'm working on a project for school and I need to send 2 bytes from and 18F2550 and receive it with a 18F4550. I understand how to set all the configurations up and start the usart but in not really sure where to go from there. Can some one help me??
Sickness6
 
Posts: 3
Joined: Mon Aug 11, 2014 11:06 pm

Re: Need help sending 2 bytes!

Postby AussieSusan » Tue Aug 12, 2014 3:13 am

Writing to the UART buffer will start the transmission. The receiving UART will recognise when the bits are being sent (that is what the "asynchronous" part of UART means) and will save the value in its buffer. When the full value has been received, it will set its buffer full flag. If you have set up interrupts on the receiving UART then the ISR will also be called.
You will need to be sure to read the first value before the 2nd value is fully received or it will over-write the first in the buffer. This is why you should also always check the error flags in the UART status register.
Susan
AussieSusan
Verified identity
 
Posts: 93
Joined: Mon Jun 16, 2014 4:45 am
PIC experience: Experienced Hobbyist

Re: Need help sending 2 bytes!

Postby Sickness6 » Tue Aug 12, 2014 3:24 am

If I'm just using the TX pin on the 2550 and the RX on the 4550 does it matter is I use synchronous or asynchronous?
Also I've heard you can perform a break in between data to delay the stop bit? I'm not sure how it works.
Sickness6
 
Posts: 3
Joined: Mon Aug 11, 2014 11:06 pm

Re: Need help sending 2 bytes!

Postby vloki » Tue Aug 12, 2014 10:05 am

AussieSusan wrote:You will need to be sure to read the first value before the 2nd value is fully received or it will over-write the first in the buffer.
There is a 2 byte fifo buffer ...
vloki
Verified identity
 
Posts: 176
Joined: Wed May 28, 2014 8:42 am
Location: Germany
PIC experience: Professional 5+ years with MCHP products

Re: Need help sending 2 bytes!

Postby vloki » Tue Aug 12, 2014 10:13 am

Sickness6 wrote:If I'm just using the TX pin on the 2550 and the RX on the 4550 does it matter is I use synchronous or asynchronous?
Also I've heard you can perform a break in between data to delay the stop bit? I'm not sure how it works.

Synchronous means that you have an additional clock signal (and PIN) -> So, you should use asynchronous.

Why do you want to *delay* the "stop" bit ?

Writing is usually done by:
1. check if TXREG is free (wait until)
2. put new value in

Reading is done:
1. check if value is in RCREG
2. read it

A while ago I posted some example code that may be of help
vloki
Verified identity
 
Posts: 176
Joined: Wed May 28, 2014 8:42 am
Location: Germany
PIC experience: Professional 5+ years with MCHP products

Re: Need help sending 2 bytes!

Postby ric » Tue Aug 12, 2014 11:54 am

Sickness6 wrote:...
Also I've heard you can perform a break in between data to delay the stop bit? I'm not sure how it works.

I think you have misinterpreted something you have read.

Yes, you can have a gap between characters using asynchronous communication, but it comes AFTER the stop bit.
This may seem a little academic though, as the stop bit is a high, and the idle state of the TX line is also high, so you can't see any difference between them. ;)
Latest test project, an LED matrix display made from one reel of addressable LEDs. here
User avatar
ric
Verified identity
 
Posts: 453
Joined: Sat May 24, 2014 2:35 pm
Location: Melbourne, Australia
PIC experience: Professional 5+ years with MCHP products

Re: Need help sending 2 bytes!

Postby Ian.M » Tue Aug 12, 2014 1:23 pm

Next problem:

Its very common to get one or two garbage characters received at startup due to noise on the line, or the sending end may be ready before the receiving end ans a character may be lost. If the bytes you are sending can have all possible values there is no easy way of resynchronising so you don't know if the first byte you received is actually the first byte the transmitter sent, or the last byte of the previous pair.

It is often worth sending the data as ASCII hexadecimal to avoid this problem. Send a line feed after each group of four hex digits and the receiver can always tell which byte is which. This also has the advantage that its human readable, so you can check and test the communications one PIC at a time with a simple PC terminal program and either a MAX232 level converter if you have a real serial port or a FTDI USB <=> logic level serial converter cable if your PC is USB only.
Ian.M
Verified identity
 
Posts: 94
Joined: Wed May 28, 2014 12:47 am
PIC experience: Professional 1+ years with MCHP products

Re: Need help sending 2 bytes!

Postby Sickness6 » Tue Aug 12, 2014 5:32 pm

Vloki:
I will make sure to look at your sample code and thank you for clearing it up but what do you mean by 2 byte fifo buffer? I don't believe I've heard of that.

Ric:
That makes sense. Someone had told me about it but they never really clarified it.

Ian.M:
I will make sure to look out for that. What I want my code to do is check the states of ports b and a of the 2550 because they will have switches connected to them. Then read the states and apply them to the same ports on the 4550.
Sickness6
 
Posts: 3
Joined: Mon Aug 11, 2014 11:06 pm

Re: Need help sending 2 bytes!

Postby JoshuaHartwig » Tue Aug 12, 2014 5:40 pm

Sickness6 wrote:but what do you mean by 2 byte fifo buffer? I don't believe I've heard of that.


FIFO = First In, First Out
Buffer = Place where information is stored until you do something with it.

Basically he's saying that the hardware itself can hold up to two bytes before it starts discarding messages if you are not reading them fast enough in code. First in, first out means that when you read from this buffer, they come in the order that the hardware received them.
JoshuaHartwig
 
Posts: 9
Joined: Thu May 29, 2014 10:40 pm
PIC experience: Professional 1+ years with MCHP products

Re: Need help sending 2 bytes!

Postby vloki » Tue Aug 12, 2014 8:38 pm

Sickness6 wrote:Vloki:
... what do you mean by 2 byte fifo buffer? I don't believe I've heard of that.
->
2009 Microchip Technology Inc. DS39632E-page 257
PIC18F2455/2550/4455/4550
FIGURE 20-6: EUSART RECEIVE BLOCK DIAGRAM
vloki
Verified identity
 
Posts: 176
Joined: Wed May 28, 2014 8:42 am
Location: Germany
PIC experience: Professional 5+ years with MCHP products

Next

Return to SCI/USART/EUSART

Who is online

Users browsing this forum: No registered users and 1 guest