 |
 |
| View previous topic :: View next topic |
| Author |
Message |
asteriskme
Guest
|
| serial communication |
 Posted: Sun Jan 04, 2009 10:12 pm |
 |
|
Hi all,
I have a problem !!
I want to use both hardware and software uart and I want to establish a serial communication between two pics also using two computers. Both pics will send and receive search signals and when they receive search signal they will output desired things. I didn't use any interrupt yet the program works always but I want to see the desired outputs. I don't know where I made a mistake.
Can you please help me. Here is my code also
| Code: |
#include "16F877A.H"
#use delay(clock=4000000)
#use rs232(baud=9600, xmit=PIN_C6,rcv=PIN_C7,stream=coma)
#use rs232(baud=9600, xmit=PIN_B2,rcv=PIN_B3,stream=comb)
void main()
{
char c;
align=0;
while(TRUE){
if(align==0){
fprintf(coma,"sending search signal");
putc('~',comb);
align=0;
}
if(kbhit(comb)){
fprintf(coma,"received something");
c=getc(coma);
if(c=='~')
{
fprintf(coma,"received search signal");
}
else {
putc(c,coma);
}
}
} |
|
|
 |
Ttelmah
Guest
|
|
| Posted: Mon Jan 05, 2009 3:30 am |
|
|
It is difficult to understand what you actually want to happen. However lets give a slight 'analysis' of the code as posted:
You are sitting in a loop.
'Align', will always be '0'. You never set it to anything else.
So, the code will print 'sending search signal', on the hardware port, followed by '~' on the software port. Now, the first message, takes 19.8mSec. 19* the time per character. At this point _two_ characters are still in the hardware buffering and being sent. The '~' then takes another 1.04mSec, so 20.83mSec have now passed, and one character is still being sent from the hardware.
You then test to see if a character is being received by the software port. Now, the software port has _no buffering at all_. The 'kbhit' test, will only return 'true', if at the instant you call it, there is a 'low' level being seen from the serial line. You wll _not_ see such a level, unless the unit at the other end has responded _instantly_ to the '~'.
Then, assuming that the character is seen, you send a message out of the hardware port, 18 characters long. Since one character is already in the hardware buffer, this wll take another 17.7mSec. Now at this point, you have _missed_ the character that was seen by 'kbhit' (remember _no buffering at all on the software UART_). You then call 'getc', that will attempt to get a character from the software UART. If the remote unit sends multiple charcaters, then you will receive something, but not the first character you expected. However if the remote unit only sends the one character in reply to the transmission, you will sit here for ever, waiting or a character to arrive....
You need to learn about the limitations of the software and hardware UARTs. Realistically, you would almost certainly be 'better off', first keeping your messages shorter. A single character, can be sent, and the hardware can get on with this while you send a character with the software UART. Then, in the recieve part, wait a reasonable time for the character to arrive, and _immediately_ call the software getc.
Best Wishes |
|
|
SherpaDoug
Joined: 07 Sep 2003
Posts: 1640
Location: Cape Cod Mass USA
|
|
| Posted: Mon Jan 05, 2009 8:58 am |
|
|
Here is a Gotcha that had me confused for a couple of hours a few years ago. I had two PICs connected by software serial comms and a TTL sync line. The receiver waited in getc() for a character. The sender sent a character (what operation to do). Then the receiver set some bits and sent a sync pulse (exactly when the operation was done). Sounds simple doesn't it....
The sender never saw the sync pulse. I eventually realized than the receiver returned from the getc() function and executed its operation before the sender returned from putc(). Getc() returns when the PIC sees the MIDDLE of the Stop bit. Putc() does not return until the END of the Stop bit. In my case the sync pulse was arriving before the end of the Stop bit while the sender was still stuck in putc().
_________________
The search for better is endless. Instead simply find very good and get the job done. |
|
|
asteriskme
Guest
|
| serial communication |
| Posted: Mon Jan 05, 2009 10:06 am |
|
|
Hi Ttelmah
Thank you very much for your reply. I think i am confused when i am writing to the forum my code will be like this (coma and comb will reverse)
| Code: |
#include "16F877A.H"
#use delay(clock=4000000)
#use rs232(baud=9600, xmit=PIN_C6,rcv=PIN_C7,stream=coma)
#use rs232(baud=9600, xmit=PIN_B2,rcv=PIN_B3,stream=comb)
void main()
{
char c;
align=0;
while(TRUE){
if(align==0){
fprintf(comb,"sending search signal");
putc('~',coma);
align=0;
}
if(kbhit(coma)){
fprintf(comb,"received something");
c=getc(coma);
if(c=='~')
{
fprintf(comb,"received search signal");
}
else {
putc(c,comb);
}
}
} |
But i think that i will have the same problem when i run the code. The thing that i am trying to do is:
You have both tx/rx in two side so nodes will send '~' for search signal if a node gets search signal it responds back hey i got something and if he gets '~' he will say i got search signal. I know i made a mistake because i saw just received something (not search signal) as you mention. I think a need a good buffering timing knowledge about this problem. Can you prefer somethings.
I will try to send just '~' not comments at all but in future that will not help because i have to set some flags and preambles for the protocols. So if pic16f877a have hardware limitations to do this i will use another pic what you prefer me?
I also appreciate your answers to the forums. Thanks. |
|
|
|
|
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
