PIC USART problem - need basic info on serial communication

[Futterama]

Hi forum,

I have two PIC16F767 driving some LED 7-segment displays directly from the outputs.

I then have a PIC18F2320 sending digits to the two PIC16F767 using the hardware USART at 19200 bps.

I'm having these strange problems - sometimes the PIC16F767 outputs won't change and just stays high and now I have a problem where the serial line can drive each PIC seperately but not together at the same time. The TX pin of the PIC18 is directly connected to both PIC16 RX pins - only a 100k pull-up is connected besides the PICs. The PIC16s are on one board and the PIC18 is on another - they are connected by 7" (17cm) wire.

Is there something in basic serial communication board layout I'm missing here? Some series resistors somewhere perhaps?

Thanks.

Best regards,
Futterama

 

[Diver300]

A circuit diagram would help.

I assume that you are not sending data from the PIC16s to the PIC18

There is nothing wrong with sending serial data from one serial transmitter to several receivers. If there are problems, you need to see what is happening with an oscilloscope, or use a terminal emulator, such as a PICkit2 in UART mode, to see what is being sent.

If the presence of one of the PIC16s stops the other one receiving, then either the RX pin is sometimes outputting signals, or the levels or timing are marginal. You could try slowing down the data rate. You could also put a resistor, say 1k, in series with each of the RX inputs. That will stop them messing up the signal if they do become outputs at any point.

 

[Pommie]

Assuming you have connected a common ground it should work. If not can you post some cut down example code to demonstrate the problem. If the cut down code works then it is probably a timing problem.

Mike.

 

[Futterama]

Thanks for the answers. I did try with 1k in series with the RX, but this just results in no PIC receiving the data.

I have been doing some test with the 7-segment LED displays and they seem to give a readable output at 7mA/segment. This enables me to drive them all from a single PIC18F4520 without exceeding the 200mA limit for the PIC (7mA x 28 segments = 196mA max). The approach I use now seems too complicated for the simple task of displaying 4 digits. Multiplexing 4 7-segment displays just seems to give a too weak output on the segment LEDs.

 

[ericgibbs]

Thanks for the answers. I did try with 1k in series with the RX, but this just results in no PIC receiving the data.

I have been doing some test with the 7-segment LED displays and they seem to give a readable output at 7mA/segment. This enables me to drive them all from a single PIC18F4520 without exceeding the 200mA limit for the PIC (7mA x 28 segments = 196mA max). The approach I use now seems too complicated for the simple task of displaying 4 digits. Multiplexing 4 7-segment displays just seems to give a too weak output on the segment LEDs.

hi Futterama,
Please post your full code and if possible a circuit diagram, it makes it so much easier for us to help you.

 

[Futterama]

Files attached as zip and image attached exported from Eagle.

The PIC18 just sends 2 bytes to the PIC16s representing the RPM value.

I had this setup working fine, then came the missing segments problem and now I have this serial problem.

 

[Pommie]

I can't see why your code isn't working. One question though, how do you keep the data in sync? May I suggest sending two 7 bit values and setting the top bit when sending the most significant byte.

So, on the transmit end do,

    Send((data>>7)|0x80);
    Send(data&0x7f);

And on the receiving end,

    data=0;
    while(data&0x80==0)
        data=getdata();
    data&=0x7f;
    data<<=7;
    data+=getdata();

You would of course put all the error handling in the getdata function.

Mike.

 

[Futterama]

The data in sync? Well, I just keep something like 250ms delay between each transmission.

The code should work, yes. But with this setup I keep getting these weird problems, thats why I'm thinking of getting rid of the two PIC16s and then just live with the lower light output from the displays when driving them all from a single PIC18F4520.
I did make a setup with the PIC18F4520 previously where it drives three 7-segment displays but with some inverters between PIC and LEDs to overcome the current limit of the PIC. But this require a lot of board space and I don't have that here - unless I stack 2 boards.
As you may have guessed from the filenames, the displays are for a RPM counter for a minimill - and driving the LEDs at 7mA troubles me, bacause I want the display to be easily read and I'm not sure 7mA is enough is strong ambient lighting.

 

[Futterama]

Hi again,

I put a scope on the serial line. Here's the results:

One RX pin connected:


Two RX pins connected:


When only a single PIC16 RX pin is connected to the PIC18 TX pin, the signal looks fine. When I connect the second PIC16 RX pin, it seems to be pulling the voltage up. Actually when only one PIC16 RX pin is connected, it also seems to be pulling the voltage up but this does not affect the signal - it must be within the PIC digital input specifications.

So what could be pulling the voltage up on pin RC7 on PIC16F767?

Just for trying something, I removed the 100k pull-up at the PIC18, and now look what happened with both RX pins connected:


Could I have damaged the PIC18 TX output while fiddling with the boards?

Btw. the boards have common ground and common supply of 5V.

 

[Pommie]

For the uart on the 16F767 to work correctly both TX and RX have to be input. This is not true for the 18F2320, the TX pin has to be output. Do you set it to output?

Mike.

 

[Futterama]

Well, I have not set it for the PIC18 since I use the built-in rs232 directive, but perhaps this does not set the TX pin as output. I will give it a try.

Actually, you are right about the PIC16F767, both TX and RX pins needs to be set as inputs - I have the TX as output, perhaps this does something to the UART. Will try to fix this also.

 

[Futterama]

Nope, it didn't help to set the PIC18 TX pin as output - I guess the built-in rs232 directive (CCS compiler) sets it as output.

It didn't help to set both TX and RX as inputs on the PIC16s.

But thanks for the suggestions anyway

 

[Futterama]

Oh I think I just found the error. I'm setting the default output in the beginning of my program using:

// Set startup pin states
output_a(0xFF);
output_b(0xFF);
output_c(0xFF);

The compiler will set all affected pins to output before outputting the value (0xFF) and this makes the RX pin an output. DOH! My bad :-(

Thanks for all your help and suggetions.