 |
 |
| View previous topic :: View next topic |
| Author |
Message |
inl0ad
Joined: 13 Jan 2014
Posts: 8
|
| Bluetooth - RS232 - Not Receiving data |
 Posted: Thu Apr 24, 2014 8:41 am |
 |
|
Hello there,
First of all, I did my research in this forum, but I couldn't find any solution to my problem :(
Alright, I have a breadboard with a pic18f26k20 connected to a bluegiga wt11i-a bluetooth module. To program my pic, I'm using pickit2, mplab v8.9 and the ccs compiler (oh rly?). I'm trying to communicate this with my phone/pc(generic bluetooth module), using terminal on both of those devices.
So far, I configured my bluegiga module (name, pairing password etc.) and I was able to send data from the pic to my phone. However, I'm finding trouble on receiving data from my phone terminal as well as I can't read basic info when the bc is not connected to any device. For instance, if I send a string "AT", I was supposed to read "OK" on my uart, but I can't. I checked with my oscilloscope both rx and tx on my breadboard pins, and they were apparently sending/receiving info.
Well, I'm a quite beginner at this and asked for some information. Some said to me about interruptions, others said about buffers. I was wondering if that is the path that I have to follow in order to make it work, or if there's any other simpler way. If not, which one should I use: interruption or reading/configuring buffers? Where can I find more info about it?
Here goes my code so far. getc(), gets(), kbhit() etc seem not working.
| Code: |
#include <18f26k20.h>
#device adc =10
#device ICD=TRUE
#FUSES noWDT // Watch Dog Timer
#fuses LP //low power crystal
#FUSES HS //Crystal osc <= 4mhz
#fuses BROWNOUT_SW //Brownout enabled during operation, disabled during SLEEP
#FUSES NOPROTECT //Code not protected from reading
#FUSES BROWNOUT //brownout reset
#FUSES BORV27 //Brownout reset at 2.7V
#FUSES NOPUT //Power Up Timer
#FUSES NOCPD //No EE protection
#FUSES STVREN //Stack full/underflow will cause reset
#FUSES noDEBUG //No Debug mode for ICD
#FUSES noLVP //Low Voltage Programming on B3(PIC16) or B5(PIC18)
#FUSES NOWRT //Program memory not write protected
#FUSES NOWRTD //Data EEPROM not write protected
#FUSES noIESO //Internal External Switch Over mode enabled
#FUSES FCMEN //Fail-safe clock monitor enabled
#FUSES NOPBADEN //PORTB pins are configured as analog input channels on RESET
#FUSES NOWRTC //configuration not registers write protected
#FUSES NOWRTB //Boot block not write protected
#FUSES NOEBTR //Memory not protected from table reads
#FUSES NOEBTRB //Boot block not protected from table reads
#FUSES NOCPB //No Boot Block code protection
#FUSES LPT1OSC //Timer1 configured for low-power operation
#FUSES MCLR //Master Clear pin enabled
#FUSES XINST //Extended set extension and Indexed Addressing mode enabled*/
#include <stdio.h>
#include <string.h>
#use delay(clock = 11059200) /* Clock definition */
#use rs232(BAUD = 115200, XMIT = PIN_C7, RCV = PIN_C6, parity=N,bits = 8, ERRORS) /* BC and PIC communication */
char b[10];
const char strings[20] =
{
"SET BT AUTH * 1234\n"
};
void main(){
while (1) {
puts("AT\n");
if (kbhit()) gets(b);
delay_ms(10);
}
}
|
|
|
 |
Ttelmah
Joined: 11 Mar 2010
Posts: 19477
|
|
| Posted: Thu Apr 24, 2014 10:01 am |
|
|
Get rid of the LP fuse. This is for when you are using a low power oscillator. You aren't. There should always be only _one_ oscillator fuse (except on chips like PIC24's).
Change XINST to NOXINST. The CCS compiler _does not support XINST_.
Then do a basic flash an LED test, and verify that this flashes at the correct rate (no point in even trying comms till it does).
Then do a search here, and understand why there may be problems with the code:
1) if any serial data arrives in the 10mSec pause.
2) why gets, and kbhit don't really work together. |
|
|
inl0ad
Joined: 13 Jan 2014
Posts: 8
|
|
| Posted: Thu Apr 24, 2014 11:44 am |
|
|
Thanks Ttelman for you answer 
I've done the modifications that you mentioned. Also, I've done the LED tests and they are working fine.
Let's see if I find something about what you said |
|
|
inl0ad
Joined: 13 Jan 2014
Posts: 8
|
| Still not working :/ |
| Posted: Tue Apr 29, 2014 6:27 am |
|
|
Okay guys, I've done my research and tried different types of codes, for instance:
kbhit() and getc() - it seems here that kbhit returns true, but i can't get any data
| Code: |
while(1){
puts("AT\n");
if(kbhit()) {
for (i=0;i<3;i++) b[i] = getc();
}
}
|
Here, it seems that interruption is never triggered.
| Code: |
void isr() {
for(i=0;i<3;i++) b[i] = getc();
}
.
.
.
enable_interrupts(INT_RDA);
enable_interrupts(GLOBAL);
while(1) puts("AT\n");
|
I also have tried those codes below, with no success:
| Code: |
puts("AT\n");
gets(b);
//////////////////////////////
void isr() {
gets(b);
}
enable_interrupts(INT_RDA);
enable_interrupts(GLOBAL);
/////////////////////////////
|
Notes:
1 - LEDs are blinking correctly.
2 - With a osciloscope, I could see that there's communication between the bc and pic. That is, whichever leaves the pic enters in the bc, and vice-versa.
3 - When I connect my bc to my phone, I keep receiving infinite "AT"s on my phone terminal. Therefore, I can send data with my PIC.
I have no idea what could be wrong with my code. I think it's not hardware related because I can send data.
Any help will be appreciated. |
|
|
temtronic
Joined: 01 Jul 2010
Posts: 9215
Location: Greensville,Ontario
|
|
| Posted: Tue Apr 29, 2014 7:18 am |
|
|
couple of things...
1) It's generally as bad idea to use gets(b);
Unless the incoming data DOES have a string delimiter( /0) the PIC will sit there forever looking for it.
2) The RDA ISR is 'triggered' when there is ONE incoming character NOT a 'bunch' of them.Also you haven't properly coded for the ISR.
3) Have a look at the CCS supplied example 'ex_sisr.c'. This program will properly receive and store any incoming data to the UART. It is a GREAT start to do what you want and it WORKS!
recode/recompile/retest/report back
post your full code so we can see what's going on.
hth
jay |
|
|
inl0ad
Joined: 13 Jan 2014
Posts: 8
|
|
| Posted: Tue Apr 29, 2014 7:24 am |
|
|
Thank you buddy, I'll have a look at the example.
My whole code is on my first post. Previous post was about routines that I was using to get any data |
|
|
inl0ad
Joined: 13 Jan 2014
Posts: 8
|
|
| Posted: Tue Apr 29, 2014 8:04 am |
|
|
I've looked at the example ex.sisr.c and I came up with the code which can be found below.
I still can see with my osciloscope data leaving the Pic(PIN_C7) and entering(PIN_C6). However, it's not storing data in my string. At some point, I put a breakpoint within the isr routine. It was never triggered.
Notes: As you can see at my code below, it sends "AT\n" every 100ms, and it's supposed to receive "OK" with the same rate. I was verifying it with the osciloscope and most of the time the pic sends and receives at this rate. There are times when the pic sends/receives at different rates, but it soon comes back to normal.
At some point, I thought that the variable i would be more than 29 (size of string), but I was watching it and it stays at 0.
| Code: |
#include <18f26k20.h>
#device adc =10
#device ICD=TRUE
#FUSES noWDT // Watch Dog Timer
//#fuses LP //low power crystal
#FUSES HS //Crystal osc <= 4mhz
#fuses BROWNOUT_SW //Brownout enabled during operation, disabled during SLEEP
#FUSES NOPROTECT //Code not protected from reading
#FUSES BROWNOUT //brownout reset
#FUSES BORV27 //Brownout reset at 2.7V
#FUSES NOPUT //Power Up Timer
#FUSES NOCPD //No EE protection
#FUSES STVREN //Stack full/underflow will cause reset
#FUSES noDEBUG //No Debug mode for ICD
#FUSES noLVP //Low Voltage Programming on B3(PIC16) or B5(PIC18)
#FUSES NOWRT //Program memory not write protected
#FUSES NOWRTD //Data EEPROM not write protected
#FUSES noIESO //Internal External Switch Over mode enabled
#FUSES FCMEN //Fail-safe clock monitor enabled
#FUSES NOPBADEN //PORTB pins are configured as analog input channels on RESET
#FUSES NOWRTC //configuration not registers write protected
#FUSES NOWRTB //Boot block not write protected
#FUSES NOEBTR //Memory not protected from table reads
#FUSES NOEBTRB //Boot block not protected from table reads
#FUSES NOCPB //No Boot Block code protection
#FUSES LPT1OSC //Timer1 configured for low-power operation
#FUSES MCLR //Master Clear pin enabled
#FUSES NOXINST //Extended set extension and Indexed Addressing mode enabled*/
#include <stdio.h>
#include <string.h>
#use delay(clock = 11059200) /* Clock definition */
#use rs232(BAUD = 115200, XMIT = PIN_C7, RCV = PIN_C6, parity=N,bits = 8, ERRORS) /* BC and PIC communication */
#define BUFFER_SIZE 32
BYTE buffer[BUFFER_SIZE];
BYTE next_in = 0;
BYTE next_out = 0;
#int_rda
void serial_isr() {
int t;
buffer[next_in]=getc();
t=next_in;
next_in=(next_in+1) % BUFFER_SIZE;
if(next_in==next_out)
next_in=t; // Buffer full !!
}
#define bkbhit (next_in!=next_out)
BYTE bgetc() {
BYTE c;
while(!bkbhit) ;
c=buffer[next_out];
next_out=(next_out+1) % BUFFER_SIZE;
return(c);
}
char string[30];
int i = 0;
void main() {
enable_interrupts(int_rda);
enable_interrupts(global);
while(1) {
delay_ms(100);
puts("AT\n");
while(bkbhit) {
string[i] = bgetc();
i++;
}
}
} |
|
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19477
|
|
| Posted: Tue Apr 29, 2014 8:21 am |
|
|
It won't....
Comments:
Look through your fuses. You have several that disagree with one another (BROWNOUT, and BOWNOUT_SW for example). Read the data sheet, and realise these are 'either or', not 'both' options....
As it stands, you send the AT command, and immediately check bkbhit. Nothing will have been received (no time to do so), so bkbhit will be false. No data read.....
You need to delay _after_ sending the AT, before calling bkbhit.
Then a 'string' requires a null terminator character. You need to check the character received, and when it is a line feed, add this character to the string.
The PIC should never change speed. The only reason it would, is if the master oscillator has stopped. Then (since you have FCMEN enabled), it'll change speeds and use the internal oscillator. That it is changing speed, suggests there is a problem with the layout round the oscillator somewhere. |
|
|
temtronic
Joined: 01 Jul 2010
Posts: 9215
Location: Greensville,Ontario
|
|
| Posted: Tue Apr 29, 2014 8:32 am |
|
|
hmm...
I see you have ICD=TRUE as a fuse....
I don't use the ICD but others who do might know if it's tied into the UART or if it 'reconfigures' fuses to suit itself and NOT your real program.
just food for thought
jay |
|
|
inl0ad
Joined: 13 Jan 2014
Posts: 8
|
|
| Posted: Tue Apr 29, 2014 8:34 am |
|
|
Here I go again to the datasheet :P I'm a begginer at this, that's why I messed up with the fuses. I will try to make them right then.
Just one question regarding what you just said: how much delay do I need to insert?
Thank you again. |
|
|
temtronic
Joined: 01 Jul 2010
Posts: 9215
Location: Greensville,Ontario
|
|
| Posted: Tue Apr 29, 2014 8:47 am |
|
|
just reverse the order of these....
delay_ms(100);
puts("AT\n");
to this
puts("AT\n");
delay_ms(100);
at least it's a start.....
hth
jay |
|
|
inl0ad
Joined: 13 Jan 2014
Posts: 8
|
| UP |
| Posted: Wed Apr 30, 2014 11:02 am |
|
|
Thanks for the replies!
I came back with the same problems :(
Okay, first things first. I got rid of some fuses that seem useless for my application. Actually, I got 'em copied and pasted from another project. So, right now, I think came up with the ideal configuration for my project.
Also, I still found some problems using my osciloscope. My code (shown below) prints "AT\n" at a rate of 100ms, so every 100ms I was expecting a signal (High>Low), but there're some periods that there's no signal (does that make sense?). Same thing happens to the entrance_pin, which was supposed to receive "Ok".
However, at some point, I inserted a 1s. delay inside the main_while, before puts, and conected the bc device to my phone. Using the terminal, I was able to verify that I was receiving a "AT\n" every 1s.
--- Sorry if it's not clear, english isn't my mother language :(---
My problem still relies on not receiving data with pic. I really don't know what could be wrong.
Any help would be appreciated. I'm starting think that I have issues with the hardware, but how is that even possible if I can send data?
| Code: |
#device adc =10
//#device ICD=TRUE
#FUSES NOXINST
#fuses HS,NOWDT,NOPROTECT,NOLVP
#include <stdio.h>
#include <string.h>
#use delay(clock = 11059200) /* Clock definition */
#use rs232(BAUD = 115200, XMIT = PIN_C7, RCV = PIN_C6, parity=N,bits = 8, ERRORS) /* BC and PIC communication */
#define BUFFER_SIZE 32
BYTE buffer[BUFFER_SIZE];
BYTE next_in = 0;
BYTE next_out = 0;
#int_rda
void serial_isr() {
int t;
buffer[next_in]=getc();
t=next_in;
next_in=(next_in+1) % BUFFER_SIZE;
if(next_in==next_out)
next_in=t; // Buffer full !!
}
#define bkbhit (next_in!=next_out)
BYTE bgetc() {
BYTE c;
while(!bkbhit) ;
c=buffer[next_out];
next_out=(next_out+1) % BUFFER_SIZE;
return(c);
}
char string[30];
int i = 0;
void main() {
enable_interrupts(int_rda);
enable_interrupts(global);
while(1){
i = 0;
//delay_ms(1000);
puts("AT\n");
delay_ms(100);
while(bkbhit) {
string[i] = bgetc();
if (string[i] == '\n') string[i++] = '\0';
else i++;
}
}
} |
|
|
|
temtronic
Joined: 01 Jul 2010
Posts: 9215
Location: Greensville,Ontario
|
|
| Posted: Wed Apr 30, 2014 11:21 am |
|
|
Time for some low level hardware debugging....
I'd disconnect the PIC from your bluetooth device and hardwire it's xmt to rcv. this makes a 'loopback' connection.
Now running a PC terminal program, type on the PC KBD and whatever you type should go from PC to it's BT unit, then wirelessly to the 'PIC' BT unit, loopback and go wirelessly to the PC's BT unit,go into the PC terminal program and be displayed on the PC screen.
Please confirm that this setup works. If it does, then there's some problem with your PIC program or hardware.
Another test is to use a PC with a REAL comport and use a MAX232 chip .CCS supplies a simple example in the FAQ section of the manual.
the 'trick' is to divide and conquer! break the project into smaller pieces to see what works, what doesn't.
hth
jay |
|
|
inl0ad
Joined: 13 Jan 2014
Posts: 8
|
| SOLVED |
| Posted: Wed May 07, 2014 7:37 am |
|
|
Guys, I appreciated a lot your comments! I figured out what was wrong.
Basically, by the begining of the project, we wired TX<>TX and RX<>RX, which I thought I could set it right throughtou the software. It seems it doesn't work that way :P
Thank you very much. |
|
|
|
|
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
