| View previous topic :: View next topic |
| Author |
Message |
sharpiedeluxe
Joined: 18 Feb 2012
Posts: 7
|
| UART with PIC18F458 problems |
 Posted: Sat Feb 18, 2012 6:52 pm |
 |
|
Hello, I'm experiencing some issues while sending serial data over bluetooth to the UART on the PIC18.
I'm using PuTTY with settings of BAUD = 115200, Data bits = 8, Stop bit = 1, no parity, no flow control. My bluetooth module is at factory settings with the same baud rate. I'm able to send a character to my pic. I included a function to take the character and send it back.
It ends up sending back a character on the extended ascii table. For example, if I send the character 'a', I will get back 'Ø'. This happens every time I send 'a'. Has anyone seen this before? I will post code below. Similar things happen when I try to type different characters. They all tend to be from the extended ascii table.
I included the gethex functions because I thought that if I tried to use them and returned a byte then it would be different. Unfortunately, I get the same results as before. If anyone has any advice, I would really appreciate it. Thanks!
EDIT: I also just tried to use putc('a'), to see if I would get 'a' to return after the getc(). However, nothing returns at all.
| Code: |
#include <18F4550.h>
#define TX1 PIN_C6
#define RX1 PIN_C7
#fuses HSPLL,USBDIV,PLL5,CPUDIV1,VREGEN,NOWDT,NOPROTECT,NOLVP,NODEBUG
#use delay(clock=48000000)
#use rs232(baud = 115200, xmit = TX1, rcv = RX1, bits=8, stop=1)
#use fast_io(A)
#use fast_io(B)
#use fast_io(C)
#use fast_io(D)
#use fast_io(E)
void turn_left();
void turn_right();
void go_straight();
BYTE gethex1();
BYTE gethex();
void main() {
char data;
set_tris_a(0B00000000);
set_tris_b(0B00000000);
set_tris_c(0B10000000);
set_tris_d(0B00000000);
set_tris_e(0B00000000);
while(1)
{
data = getc();
putc(data);
}
}
BYTE gethex1() {
char digit;
digit = getc();
putc(digit);
if(digit<='9')
return(digit-'0');
else
return((toupper(digit)-'A')+10);
}
BYTE gethex() {
unsigned int8 lo,hi;
hi = gethex1();
lo = gethex1();
if(lo==0xdd)
return(hi);
else
return( hi*16+lo );
}
|
|
|
 |
temtronic
Joined: 01 Jul 2010
Posts: 9225
Location: Greensville,Ontario
|
|
| Posted: Sat Feb 18, 2012 7:04 pm |
|
|
You should always add 'errors' to the use rs232(...) options when using the hardware UART..
Also if sending more than a couple of bytes of data use an ISR with buffering. CCS does supply examples in the Examples folder.
I use 115k200 all day long without problems. |
|
|
sharpiedeluxe
Joined: 18 Feb 2012
Posts: 7
|
|
| Posted: Sat Feb 18, 2012 7:11 pm |
|
|
| Okay, I will add ERRORS, however, I don't understand what that means exactly or what it does even after reading the documentation. I plan to use an ISR; however, since I am only sending one byte for now, I didn't implement it yet. |
|
|
asmboy
Joined: 20 Nov 2007
Posts: 2128
Location: albany ny
|
|
| Posted: Sat Feb 18, 2012 7:18 pm |
|
|
your baud situation could be messed up
dont send to the PIC -
instead
try just doing a string of TRANSMITS -- with a delay between each
as in
| Code: |
putc('A');
delay_ms(2);
putc('B');
delay_ms(2);
putc('A');
delay_ms(2);
putc('B');
delay_ms(2);
putc('A');
delay_ms(2);
putc('B');
delay_ms(2);
printf("\r\n");
// spit out the line
|
i think you might have a FUSES problem - and this test will tell if your baud is really your baud
but DO add the errors statement |
|
|
sharpiedeluxe
Joined: 18 Feb 2012
Posts: 7
|
|
| Posted: Sat Feb 18, 2012 7:30 pm |
|
|
Okay, thanks for the tips. I tried to do exactly what you said.
With the code you provided, this was my output:
| Code: |
¿ñ×ö¿¿ñ×ö¿¿ñ×ö¿¿ñ×ö
|
Seems strange right? The fuses are set the same as when I got the dev board. I didn't change them because I wasn't sure how to set them up.
Also, how do I check rs232_errors? Is that a string, char array? |
|
|
temtronic
Joined: 01 Jul 2010
Posts: 9225
Location: Greensville,Ontario
|
|
| Posted: Sat Feb 18, 2012 8:59 pm |
|
|
If you bypass the wireless stuff and go PIC to PC connections , is it 100% ?
If so , then you've got a bad bluetooth device or improper setup in the communications protocol. |
|
|
sharpiedeluxe
Joined: 18 Feb 2012
Posts: 7
|
|
| Posted: Sat Feb 18, 2012 9:21 pm |
|
|
I don't have a way to go directly to the PC. I have an RS232 port, but I don't have a cable.
EDIT: I tried it using an LCD and I get the same thing |
|
|
asmboy
Joined: 20 Nov 2007
Posts: 2128
Location: albany ny
|
|
| Posted: Sat Feb 18, 2012 10:36 pm |
|
|
what you received tells me that your actual baud in the pic is probably 1/4 of what you say in
#use delay(clock=48000000)
or as i said
your device fuses are the likely cause of this
try changing the #use delay to 12mhz for grins and try again  |
|
|
sharpiedeluxe
Joined: 18 Feb 2012
Posts: 7
|
|
| Posted: Sat Feb 18, 2012 10:49 pm |
|
|
I changed #use delay(clock=12000000)
Now I don't get any output at all.
But, I definitely am appreciating all the help.
EDIT: after some more tests, I always get ascii characters that start with
"11000000". This happens no matter what. |
|
|
asmallri
Joined: 12 Aug 2004
Posts: 1634
Location: Perth, Australia
|
|
| Posted: Sun Feb 19, 2012 4:34 am |
|
|
| sharpiedeluxe wrote: | | Okay, I will add ERRORS, however, I don't understand what that means exactly or what it does even after reading the documentation. I plan to use an ISR; however, since I am only sending one byte for now, I didn't implement it yet. |
The UARTS in PIC are very stupid. If an overrun error occurs, where a bytes is received but there is no space in the UART to receive the byte, the UART receive logic is disabled. The only way to re-enable the receive logic is to have the application software reset the receive logic. If the hardware engineer that designed this logic worked for me, I would have fired them for incompetence.
The ERRORS keyword tells the CCS compiler to insert logic to test for the error and reset the receive logic.
_________________
Regards, Andrew
http://www.brushelectronics.com/software
Home of Ethernet, SD card and Encrypted Serial Bootloaders for PICs!! |
|
|
sharpiedeluxe
Joined: 18 Feb 2012
Posts: 7
|
|
| Posted: Sun Feb 19, 2012 4:40 am |
|
|
Thanks, that makes sense now  .
Still having problems with this now..haven't figured it out. Except that my fuses were in fact incorrect. Even after fixing those, I still have problems. |
|
|
sharpiedeluxe
Joined: 18 Feb 2012
Posts: 7
|
|
| Posted: Sun Feb 19, 2012 4:01 pm |
|
|
Thanks for all the help people.
I found out the problem. On my bluetooth spec sheet, there was a misconception of whether it needs to run through a max232 or not. I had it going through one, and after I removed the max232 it works fine. |
|
|
|
FAQ 
Search
Register
Profile 
Log in to check your private messages 
Log in
