 |
 |
| View previous topic :: View next topic |
| Author |
Message |
hasimi20
Joined: 04 Sep 2010
Posts: 19
|
| pic to pic communication using uart |
 Posted: Sat Sep 04, 2010 12:31 pm |
 |
|
Dear all,
I have been trying to use pic to pic communication using uart. I am using pic16f877a, but none of the program code that posted in the internet is working.
At the moment, I have 2 pics called PIC_A and PIC_B and I need to read a data from PIC_B sent from PIC_B. Anyone please help me??? This is my code:
receiver (PIC_B)
| Code: |
#include <16f877a.h>
#fuses HS,NOLVP,NOWDT
#use delay(clock=20000000)
#include <utility.c>
#use rs232(baud=119200, bits=8, UART1, SYNC_SLAVE)
void main()
{
char data;
while(true)
{
while(true)
{
data = getc();
switch(data){
case 'g':output_high(PIN_A1);
output_low(PIN_A2);
output_low(PIN_A3);
break;
case 'y':output_low(PIN_A1);
output_high(PIN_A2);
output_low(PIN_A3);
break;
case 'r':output_low(PIN_A1);
output_low(PIN_A2);
output_high(PIN_A3);
break;
default:output_low(PIN_A1);
output_low(PIN_A2);
output_low(PIN_A3);
break;
}
}
}
}
|
transmitter(PIC_A)
| Code: |
#include <16f877a.h>
#fuses HS,NOLVP,NOWDT
#use delay(clock=20000000)
#use rs232(baud=119200, bits=8, UART1, SYNC_MASTER)
void main()
{
while(true)
{
putc('g');
delay_ms(1000);
putc('y');
delay_ms(1000);
putc('r');
delay_ms(1000);
}
}
|
|
|
 |
Ttelmah
Joined: 11 Mar 2010
Posts: 19513
|
|
| Posted: Sat Sep 04, 2010 2:00 pm |
|
|
Are you genuinely using SYNC comms?.
Have you got the clock line connected?.
Remember for sync, the slave does not have a baud setting.
If not using sync, the get rid of these entries in the #use lines.
Best Wishes |
|
|
hasimi20
Joined: 04 Sep 2010
Posts: 19
|
|
| Posted: Sun Sep 05, 2010 10:56 am |
|
|
finally...
i did it!!! tqvm |
|
|
cheehow
Joined: 15 Sep 2010
Posts: 28
|
|
| Posted: Tue Oct 26, 2010 8:23 pm |
|
|
Hi ! hasimi20, can you please post the code that you have successfully tested one here ? Your help would be appreciation !!!!  |
|
|
cheehow
Joined: 15 Sep 2010
Posts: 28
|
|
| Posted: Tue Oct 26, 2010 8:31 pm |
|
|
| Sorry, may I know what is #include <utility.c> in here ? Because it cannot be found in the PICC drivers and devices. |
|
|
Humberto
Joined: 08 Sep 2003
Posts: 1215
Location: Buenos Aires, La Reina del Plata
|
|
| Posted: Fri Oct 29, 2010 10:02 am |
|
|
| Quote: |
Sorry, may I know what is #include <utility.c> in here ? Because it cannot be found in the PICC drivers and devices.
|
You do not need it, just delete the line.
| Quote: |
Hi ! hasimi20, can you please post the code that you have successfully tested one here ? Your help would be appreciation !!!!
|
Well, we expect that somebody asking for help in this forum, could have the kindness of share.
This reciprocal attitude is the kernel of any forum.
Anyway, regarding the code, replace these lines:
| Code: |
#fuses HS,NOLVP,NOWDT
#use rs232(baud=119200, bits=8, UART1, SYNC_SLAVE)
|
by these in both headers:
| Code: |
#fuses PUT, HS, NOWDT, NOLVP, NOBROWNOUT
#use rs232(baud=9600, xmit=PIN_C6, rcv=PIN_C7, bits=8, parity=N, errors)
|
Test it and tell us the result.
Regards. |
|
|
cheehow
Joined: 15 Sep 2010
Posts: 28
|
|
| Posted: Mon Nov 01, 2010 9:11 am |
|
|
| HI, Humberto ... yaya .. it's worked !! the LED will blink while the power is on ... i think need to add in push button to control the data sending ... that means once i push the push button the data will be sending to slave and the LED will lite up.. thank you very much !! |
|
|
Humberto
Joined: 08 Sep 2003
Posts: 1215
Location: Buenos Aires, La Reina del Plata
|
|
|
cheehow
Joined: 15 Sep 2010
Posts: 28
|
|
| Posted: Tue Nov 02, 2010 8:16 am |
|
|
HI humberto,
thanks so much !!! it's worked !! erm .. i have one more question ... if i wanna add one more MCU to it which means now i wanna have two MCU ... so for the second slave, how to connect the TX and RX ??? izit using FORCE_SW ??
Regards |
|
|
Humberto
Joined: 08 Sep 2003
Posts: 1215
Location: Buenos Aires, La Reina del Plata
|
|
|
temtronic
Joined: 01 Jul 2010
Posts: 9226
Location: Greensville,Ontario
|
|
| Posted: Tue Nov 02, 2010 1:25 pm |
|
|
| RS-485 is probably the best for you, unless you're an old guy like me and still use 20mA current loops ! Rock stable and bulletproof, old school stuff. |
|
|
cheehow
Joined: 15 Sep 2010
Posts: 28
|
|
| Posted: Fri Nov 05, 2010 4:39 am |
|
|
HI Humberto and temtronic,
i have read through all those RS-485 stuff, but i m confuse how to declare and initialize rs-485 at the beginning. i have also read through the example inside the PICC examples, i found that it is very messy and hard to understand. can u guys please give me some guide and clear picture for this rs-485 ? ur help would be appreciated, THANKS !!!!  |
|
|
Humberto
Joined: 08 Sep 2003
Posts: 1215
Location: Buenos Aires, La Reina del Plata
|
|
| Posted: Fri Nov 05, 2010 5:50 am |
|
|
| Quote: |
i have read through all those RS-485 stuff, but i m confuse how to declare and initialize rs-485 at the beginning.
|
From the PIC/CCS point of view RS485 is the same that handling RS232, except the for extra pin needed to handle
the enable Tx/Rx of the transceiver used in RS485 networks.
Just as we used the RS232 transceiver to adapt the MCU voltages to the RS232 standard, to implement RS485
we need a dedicated device to do this task, search for SN75176 - the most popular - just for reference, in
order to know the needed hardware to meet the RS485 hardware layer.
In half duplex implementations, the pin #2 and #3 of the transceiver are wired together and are handled by
the PIC pin defined in the option "enable".
#use rs232(baud=9600, xmit=PIN_C6,rcv=PIN_C7,enable=PIN_C5)
Well in order not to write the same things, please read these threads and the linked sites.
http://www.ccsinfo.com/forum/viewtopic.php?t=33914&highlight
http://www.ccsinfo.com/forum/viewtopic.php?t=34722&highlight
http://www.ccsinfo.com/forum/viewtopic.php?t=33778&highlight
Regards. |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19513
|
|
| Posted: Fri Nov 05, 2010 5:55 am |
|
|
Key thing to understand, is that the PIC, _does not send/receive RS232!.....
'RS232', is a very specific name for async serial comms using inverted signaling, at significant voltages (normally at least +/- 8v at the transmitter). The PIC doesn't do this.
This is why when you actually want to talk to an 'RS232' device, you need a device like the MAX232, that actually generates the required signaling levels.
What the PIC generates is TTL async serial.
Now, RS485, is another signaling standard just like RS232, but using a pair of wires carrying a differential signal, rather than the high voltages for RS232. Just like for RS232, there are standard driver chips that turn async TTL serial, 'into' RS485. Chips like the MAX485.
So the settings at the PIC, remain the same as for 'RS232'!.
One difference.
_If_ you use a single pair of wires, then the signaling changes to being 'half duplex', rather than full duplex (this means you can only send in one direction at a time, rather than in both directions at the same time). When doing this, you have to tell the transceiver chip to 'turn round' to do the transmission. This just involves choosing a pin on the PIC to connect to the direction control on the transceiver, and adding 'ENABLE=PIN_name' to the 'RS232' definition. The code will then automatically control the transceiver, setting it to transmit when you send data.
The key difference about RS485, is that you can have multiple devices all 'listening' on one pair of wires (remember this pair needs termination at each end, and _biasing_ if you are not to receive garbage when nothing is driving the bus.... - A search here will find a lot more about this). and you can set any device to transmit, with all the devices hearing the message. Obviously, you have to add code so that your 'message' contains an ID of some sort to say 'this is for device X' or 'this is for all devices'.
So the declaration is the same, except for the control of the 'direction', if you are only using one pair of wires.
Best Wishes |
|
|
Douglas Kennedy
Joined: 07 Sep 2003
Posts: 755
Location: Florida
|
|
| Posted: Fri Nov 05, 2010 6:33 am |
|
|
It is unfortunate that a few see this board as a help yourself board. Present an issue grab an answer and run. A few feel that if they have an issue others are obligated to spend hours picking over their code to find a solution. A few expect their issue be addressed immediately and will keep demanding till their expectation is met.
Fortunately most are appreciative and will return the favor and contribute back. |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|
FAQ 
Search
Register
Profile 
Log in to check your private messages 
Log in
