 |
 |
| View previous topic :: View next topic |
| Author |
Message |
Mustang1945
Joined: 07 Jul 2015
Posts: 31
Location: Ecuador
|
| Problem with receiving strings from SIM900 with INT_RDA |
 Posted: Mon Sep 28, 2015 6:46 pm |
 |
|
Hi i am from Ecuador, south America, i am stuck in a little problem, please help me:
TRANSMISOR:
| Code: |
void main()
{
while(1)
{
printf("\r\nSPITFIRE\r\n"); //the program keeps FOREVER in the interrupt
//printf("SPITFIRE\r");// the program goes to interrupt and after returns to the blink function
delay_ms(4000);
}
} |
RECEPTOR:
| Code: |
void blink()
{
output_b(0b00100000);
delay_ms(1000);
output_b(0b00000000);
delay_ms(1000);
}
#INT_RDA
void interr()
{
//here i compare the strings without problem
|
//the problem here is not the comparision, the problem is that if i receive
\r\nSPITFIRE\r\n the pogram never returns to the void blink...only returns if i receive SPITFIRE\r...
}
| Code: |
void main()
{
enable_interrupts(GLOBAL);
enable_interrupts(INT_RDA);
blink();
}
|
My receptor works "fine", but this is the big question:
why the INT_RDA doesnt work with a string that ends in \r\n and only works with a \r terminated string????
This is a big problem when you work with a SIM900 module because that module responses are:
\r\nresponse\r\n |
|
 |
ezflyr
Joined: 25 Oct 2010
Posts: 1019
Location: Tewksbury, MA
|
|
| Posted: Mon Sep 28, 2015 7:56 pm |
|
|
Hi,
I think you have a basic misunderstanding about how int rda interrupt works? The interrupt simple receives serial characters via the UART, and it's up to YOU to program the response to what is received. Right now, you haven't shown enough code to determine the problem!
_________________
John
If it's worth doing, it's worth doing in real hardware! |
|
|
Mustang1945
Joined: 07 Jul 2015
Posts: 31
Location: Ecuador
|
|
| Posted: Mon Sep 28, 2015 9:21 pm |
|
|
Sorry if my explanation and my code was not so clear:
here is:
TRANSMISOR:
| Code: |
#include <16F887.h>
#FUSES XT
#FUSES NOWDT
#FUSES NOPUT
#FUSES NOPROTECT
#FUSES NOBROWNOUT
#FUSES NOCPD
#use delay(clock=4000000)
#use rs232(baud=9600, xmit=PIN_C6,rcv=PIN_C7,bits=8,parity=n,ERRORS)
void main()
{
while(1)
{
printf("\r\nSPITFIRE\r\n");//if i send a \n terminated string,the program goes to interrupt and stay there, waiting for enter a new character...it doesnt return to void blink
//printf("SPITFIRE\r");//only when i send a \r terminated string the program goes to interrupt and returns to void blink[/color]
/*
i think i have expressed bad my ideas, you are right [b]ezflyr[/b] ...it depends of me how i program the response, but i am still trying to resolve this, some functions like gets() get a string until a \r is encountered...and that doesnt help me because the string ends in \n
*/
delay_ms(5000);
}
}
|
RECEPTOR:
| Code: |
#include <16F877A.h>
#FUSES NOWDT
#FUSES XT
#FUSES NOPUT
#FUSES NOPROTECT
#FUSES NOBROWNOUT
#FUSES NOCPD
#use delay(clock=4000000)
#use rs232(baud=9600, xmit=PIN_C6,rcv=PIN_C7,bits=8,parity=n,ERRORS)
#include <INPUT.C>
void blink()
{
while(1)
{
output_b(0b00100000);
delay_ms(1000);
output_b(0b00000000);
delay_ms(1000);
}
}
#INT_RDA
void interr()
{
char string[9];
get_string(string,9);//clear the buffer
printf("INTERRUPT");
}
void main()
{
enable_interrupts(GLOBAL);
enable_interrupts(INT_RDA);
blink();
}
|
I am still trying to resolve this, but if you can give me a clue, it would be a big help!
Thanks |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19559
|
|
| Posted: Tue Sep 29, 2015 12:35 am |
|
|
OK.
Fundamental problem is that INT_RDA, says _one_ character is waiting. Just one.
gets, waits for a 'string' (actually a line terminated by a new line, which it then turns into a 'string'). So straight away your INT_RDA, will hang waiting...
What you need is an INT_RDA handler that 'builds' a string for you:
| Code: |
//global defines
#define BUFF_SIZE 10
int1 have_string=FALSE;
char buffer[10];
#INT_RDA
void char_rx(void)
{
static int ptr=0; //location in buffer
int c;
c=getc(); //get the character
buffer[ptr++]=c; //store to buffer
if (ptr>=(BUFF_SIZE-1))
ptr--; //step back if overflow
if (c=='\r') //carriage return seen
{
buffer[ptr]='\o'; //null terminate string
have_string=TRUE; //tell main code there is a string
ptr=0; //start at the beginning again.
}
}
//Then in your main loop:
if (have_string)
{
have_string=FALSE;
//Now there is a string in the buffer - do what you want with it
//code here to test etc..
}
|
As shown here this will build a maximum of nine characters plus the null terminator (so 10 characters allowed), throwing away any after the ninth character. and terminating the resulting 'string' when the carriage return is seen. The flag 'have_string' is then set.
This is what ezflyr is telling you INT_RDA does not magically get called when there is a complete line waiting for you, it gets called for every character.
I'd suggest you consider just throwing away the \n character.
In fact gets will handle the \r\n fine, but then the next 'string' will contain the extra \n, and the rest of the string will be in the next string decoded. This is standard behaviour for gets, but 'write your own', and you can ignore the extra characters. |
|
|
ezflyr
Joined: 25 Oct 2010
Posts: 1019
Location: Tewksbury, MA
|
|
| Posted: Tue Sep 29, 2015 7:49 am |
|
|
Hi,
And, a more fundamental question would be "what (the heck) are you trying to do?"
The SIM900 GSM module communicates with a host processor via it's internal UART, using 'AT' commands. Why do you have a 'Transmit' PIC, and a 'Receive' PIC? How is your hardware connected, and are you really using a SIM900 modem? Also, what is the significance of 'SPITFIRE'? AFAIK, that is not a valid SIM900 AT command! 
At this point, I assume you are just testing serial comms by connecting two PICs together, right? When you do get around to connecting your SIM900 modem, keep in mind that the SIM900 is a 3V device, so you can't just connect it directly to a 5V PIC. You need level shifting hardware to do this, or better yet, you need to obtain an 'LF' version of your PIC, and run it at 3.3ish volts!
_________________
John
If it's worth doing, it's worth doing in real hardware! |
|
|
Mustang1945
Joined: 07 Jul 2015
Posts: 31
Location: Ecuador
|
|
| Posted: Tue Sep 29, 2015 10:25 am |
|
|
| Thanks Ttelmah, now i understand better how the INT_RDA works !! |
|
|
Mustang1945
Joined: 07 Jul 2015
Posts: 31
Location: Ecuador
|
|
| Posted: Tue Sep 29, 2015 10:38 am |
|
|
| ezflyr wrote: | Hi,
And, a more fundamental question would be "what (the heck) are you trying to do?"
The SIM900 GSM module communicates with a host processor via it's internal UART, using 'AT' commands. Why do you have a 'Transmit' PIC, and a 'Receive' PIC? How is your hardware connected, and are you really using a SIM900 modem? Also, what is the significance of 'SPITFIRE'? AFAIK, that is not a valid SIM900 AT command!
At this point, I assume you are just testing serial comms by connecting two PICs together, right? When you do get around to connecting your SIM900 modem, keep in mind that the SIM900 is a 3V device, so you can't just connect it directly to a 5V PIC. You need level shifting hardware to do this, or better yet, you need to obtain an 'LF' version of your PIC, and run it at 3.3ish volts! |
Hi, in real hardware i am using a SIM900 module, but for simulation in Proteus i use a PIC16F887 as the module sim900..basically is the same because the sim 900 sends AT commands and i am sending strings in the same format of the SIM900 :\r\nresponse\r\n (i know because i have read the sim900 manual)...and as i said, i am connecting a PIC and the sim900,but i think that in the simulation you can test faster your configurations and ideas, but my module sim900 works with 5v, i bought it in amazon and i took care of that caution, because as you say , some modules works with 3.3v
thanks for your observations |
|
|
ezflyr
Joined: 25 Oct 2010
Posts: 1019
Location: Tewksbury, MA
|
|
| Posted: Tue Sep 29, 2015 12:27 pm |
|
|
Hi,
Can you post a link to the Amazon product listing so that we can take a look at what you've got? I assume that the module included full documentation?
_________________
John
If it's worth doing, it's worth doing in real hardware! |
|
|
temtronic
Joined: 01 Jul 2010
Posts: 9250
Location: Greensville,Ontario
|
|
| Posted: Tue Sep 29, 2015 12:49 pm |
|
|
re: testing in simulation is faster....
That is based on a properly working simulator ! As we all KNOW Proteus is full of bugs, errors and faulty DRCs so don't waste your time use REAL HARDWARE !
Simply take a 2nd PIC and code it to 'emulate' the SIM900 or even use a PC running a terminal program. Either of these methods WILL work for you unlike the broken Proteus 'simulator'.
By making a real PIC based SIM900 'module' you'll gain valuable test bench time instead of gazing at the Proteus screen wondering why it doesn't work.
Jay |
|
|
Mustang1945
Joined: 07 Jul 2015
Posts: 31
Location: Ecuador
|
|
|
Mustang1945
Joined: 07 Jul 2015
Posts: 31
Location: Ecuador
|
|
| Posted: Tue Sep 29, 2015 1:02 pm |
|
|
| temtronic wrote: | re: testing in simulation is faster....
That is based on a properly working simulator ! As we all KNOW Proteus is full of bugs, errors and faulty DRCs so don't waste your time use REAL HARDWARE !
Simply take a 2nd PIC and code it to 'emulate' the SIM900 or even use a PC running a terminal program. Either of these methods WILL work for you unlike the broken Proteus 'simulator'.
By making a real PIC based SIM900 'module' you'll gain valuable test bench time instead of gazing at the Proteus screen wondering why it doesn't work.
Jay |
temtronic, i make a simulation and then make the test in real hardware, even i have a ttl to usb device to send serial data through teraterm to my PIC, but thanks for your advice...i will try the 2 PICs working in real hardware... could you tell me or someone here could tell me a what is a better simulator than Proteus?
thanks |
|
|
temtronic
Joined: 01 Jul 2010
Posts: 9250
Location: Greensville,Ontario
|
|
| Posted: Tue Sep 29, 2015 1:46 pm |
|
|
The ONLY 'simulator' I've used in the past 40 years ( 25 with PICs) has been real hardware. NO simulator that I've tried( and there have been lots) can 'simulate' real World problems like EMI, arc welders,bad solder joints, faulty connections, open grounds, etc. Marginal power supplies can really test you at 3 in the morning !
These days PICs ( really all electronics) are so inexpensive it's easy to make 2-5 test units,cut code, see what happens and build from there.
Probably 99.9999% of the Proteus 'schematics' will NEVER work if wired as shown.It's the simple things like no xtal, caps, etc. that make it obvious it can never work but it 'runs' in the simulation......
Consider using a 'big' PIC ( 40 pin version) for your project.Something with lots of I/O, memory, 2 hardware UARTs, etc. While it costs a bit more now, having a common PIC makes your life easier when the client needs another LED,bell, buzzer,or just a few more lines of code ! As well, you'll develop a 'library' of routines YOU like or need for future projects.
I've used the 18F46K22 for quite some time from simple 'intelligent' battery chargers to realtime wireless greenhouse datacontrollers.
Jay |
|
|
Mustang1945
Joined: 07 Jul 2015
Posts: 31
Location: Ecuador
|
|
| Posted: Tue Sep 29, 2015 2:02 pm |
|
|
| temtronic wrote: | The ONLY 'simulator' I've used in the past 40 years ( 25 with PICs) has been real hardware. NO simulator that I've tried( and there have been lots) can 'simulate' real World problems like EMI, arc welders,bad solder joints, faulty connections, open grounds, etc. Marginal power supplies can really test you at 3 in the morning !
These days PICs ( really all electronics) are so inexpensive it's easy to make 2-5 test units,cut code, see what happens and build from there.
Probably 99.9999% of the Proteus 'schematics' will NEVER work if wired as shown.It's the simple things like no xtal, caps, etc. that make it obvious it can never work but it 'runs' in the simulation......
Consider using a 'big' PIC ( 40 pin version) for your project.Something with lots of I/O, memory, 2 hardware UARTs, etc. While it costs a bit more now, having a common PIC makes your life easier when the client needs another LED,bell, buzzer,or just a few more lines of code ! As well, you'll develop a 'library' of routines YOU like or need for future projects.
I've used the 18F46K22 for quite some time from simple 'intelligent' battery chargers to realtime wireless greenhouse datacontrollers.
Jay |
Thanks for share your experience |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19559
|
|
| Posted: Tue Sep 29, 2015 2:04 pm |
|
|
Yes.
I've just spent the last two days trying to debug a new USB driver I'm writing. Have three virtual PC's running on my desktop. One is logging the USB packets it receives (this is switchable between a W10 version, and an earlier version), another displaying a serial window, from markers I have put in the code, and the third is on a separate screen, running CCS, and the programmer. I'm also switching to connecting the USB to a Mac as well, since the unit wants to work with different hosts. I can't think of any 'simulation' (though of course the virtual machines are themselves in some senses simulations), that could hope to even handle a tiny fraction of the transactions involved.
I do use simulators (MPLAB only, and unfortunately, the one that actually works here is the old 8.92, so new chips are not supported), but only for looking at tiny register/timing issues once the important part of the code has already been identified.
In the past I swore by hardware ICE systems (far superior to the modern ICD - you had large amounts of RAM that allowed whole sections of code to be stepped 'back' if required, and could stop at registers holding particular values, or changing - I miss these). I still have dozens of adapters for older PIC's, but they were too expensive for general use, especially once ICE which gave perhaps 70% of the functionality became basically 'free'. I still wish these would come back cheaply!.... |
|
|
ezflyr
Joined: 25 Oct 2010
Posts: 1019
Location: Tewksbury, MA
|
|
| Posted: Wed Sep 30, 2015 7:36 am |
|
|
Hi,
The user reviews of that module are *not* encouraging with respect to documentation. The 'schematics' posted in the product description are clearly not even for the actual module shown. If you have a *lot* of experience with this kind of thing then you can probably untangle it, but otherwise you may be in for a frustrating challenge. The issue of poor documentation with some of these cheap development boards is a very common refrain here on the forum! It's worthwhile to tread carefully when making your purchase decisions, as 'cheapest' isn't necessarily always 'best'...
_________________
John
If it's worth doing, it's worth doing in real hardware! |
|
|
|
|
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
