View previous topic :: View next topic |
Author |
Message |
tranz
Joined: 10 Feb 2007 Posts: 78
|
Interesting problem with hyperterminal |
Posted: Tue Oct 28, 2008 4:20 pm |
|
|
Hey Guys ,
I have an interesting problem with the RS232 terminal.
I am trying to send data via RS232 to a DSP controller. Now when I send the data through the computer at 9600 baud, the data is sent and the controller works.
But when i send this data via 18f4620 at 9600 baud, it does not seem to work. I am stumped, is there any difference between the computer based hyperterminal and a microcontroller based RS232.
Thanks
Tranz |
|
|
PCM programmer
Joined: 06 Sep 2003 Posts: 21708
|
|
Posted: Tue Oct 28, 2008 4:29 pm |
|
|
1. Get a 2nd computer. Run the CCS program, SIOW.exe on it.
2. Connect your main computer to the 2nd computer. Run Hyperterminal
and send your data to the 2nd computer. Note the Hex characters
that are displayed by SIOW.exe.
3. Now connect your PIC to the 2nd computer. (remove the connection
made in step 2). Run the PIC program and look at the Hex characters
displayed on SIOW.
You should now be able to see the differences between the data
sent by Hyperterminal and your PIC. |
|
|
newguy
Joined: 24 Jun 2004 Posts: 1909
|
|
Posted: Tue Oct 28, 2008 4:33 pm |
|
|
A quick question: do you have the TX and RX lines switched around on the PIC? |
|
|
Freddie
Joined: 06 Sep 2003 Posts: 49
|
|
|
tranz
Joined: 10 Feb 2007 Posts: 78
|
|
Posted: Wed Oct 29, 2008 12:24 pm |
|
|
Gents,
The TX and RX lines are switched around on the PIC.
Here are the results of the tests carried out as suggested by PCM.
Yes there is a difference when the micro sends the data over RS232 than the computer, and the difference is when "FF" is sent over the RS232.
When the hyperterminal sends that data its "FF" but when the micro sends the data its "FF FF".
Rest of the data send does not seem to have this problem. Only in case of "FF" this error comes up, what do you think is the cause of this glitch, and how can I rectify this problem?
Thanks
Tranz |
|
|
PCM programmer
Joined: 06 Sep 2003 Posts: 21708
|
|
Posted: Wed Oct 29, 2008 12:46 pm |
|
|
Post the PIC code that sends the FFFF. |
|
|
tranz
Joined: 10 Feb 2007 Posts: 78
|
|
Posted: Wed Oct 29, 2008 12:51 pm |
|
|
Code: |
//settings
#use rs232(baud=9600, xmit=PIN_C6,rcv=PIN_C7, STREAM=USER,parity=N,stop=1)
//the part of the code where in the data is sent from the TCP client to the //PIC and then the PIC sends that data to the RS232
int8 TCPConnectedTask(TCP_SOCKET socket, int8 which) {
char c;
if (TCPIsGetReady(socket)) {
while (TCPGet(socket, &c))
{
fputc(c,USER);//RS232
}
}
|
|
|
|
RLScott
Joined: 10 Jul 2007 Posts: 465
|
|
Posted: Wed Oct 29, 2008 12:58 pm |
|
|
tranz wrote: | Gents,
...When the hyperterminal sends that data its "FF" but when the micro sends the data its "FF FF"... |
Well, it's your program in the PIC that is misbehaving, isn't it? Look at your code and see if it is treating FF differently from other data.
One possible reason for doubling up on a certain character is when that character is an "escape" character in a binary protocol. Sometimes a special character is used as a delimiter in the protocol. If that special character happens to come up as part of the data, then you can send that character twice to indicate that it is just the character as data and not the character used as a delimiter. _________________ Robert Scott
Real-Time Specialties
Embedded Systems Consulting |
|
|
tranz
Joined: 10 Feb 2007 Posts: 78
|
|
Posted: Wed Oct 29, 2008 1:12 pm |
|
|
Well I am sending a stream of binary data, and the only part the PIC plays is to transfer the data which it receives over Ethernet. So there are no conditions on what the PIC is supposed to display when it encounters a certain character.
If I need to send the character twice then that would corrupt the entire stream of data that I am trying to send. (about 7 KB)
Regards
Tranz |
|
|
RLScott
Joined: 10 Jul 2007 Posts: 465
|
|
Posted: Wed Oct 29, 2008 1:37 pm |
|
|
tranz wrote: | Well I am sending a stream of binary data, and the only part the PIC plays is to transfer the data which it receives over Ethernet. So there are no conditions on what the PIC is supposed to display when it encounters a certain character... |
OK, then test that theory by eliminating the role of the Ethernet and do this:
Code: |
while (1)
{
fputc('A',USER);//RS232
fputc('B',USER);//RS232
fputc('C',USER);//RS232
fputc(0xFF,USER);//RS232
}
|
_________________ Robert Scott
Real-Time Specialties
Embedded Systems Consulting |
|
|
tranz
Joined: 10 Feb 2007 Posts: 78
|
|
Posted: Wed Oct 29, 2008 1:46 pm |
|
|
Yes with this test the PIC is displaying the data correctly. 0xFF is being displayed as FF. |
|
|
RLScott
Joined: 10 Jul 2007 Posts: 465
|
|
Posted: Wed Oct 29, 2008 2:26 pm |
|
|
tranz wrote: | Yes with this test the PIC is displaying the data correctly. 0xFF is being displayed as FF. |
OK, then the problem has nothing to do with RS-232. The problem has to do with how you get your data from the Ethernet stream. _________________ Robert Scott
Real-Time Specialties
Embedded Systems Consulting |
|
|
tranz
Joined: 10 Feb 2007 Posts: 78
|
|
Posted: Wed Oct 29, 2008 2:38 pm |
|
|
Yes, certainly seems like that now. But the thing is that the micro is acting like a TCP/IP webserver and a client computer sends the data via hyperterminal based TCP/IP winsock.
All the micro is doing is to take the data and from ethernet and dump it on the RS232 terminal.
Any ideas about how to deal with this problem?
Regards
Tranz |
|
|
|