 |
 |
| View previous topic :: View next topic |
| Author |
Message |
Lykos1986
Joined: 26 Nov 2005
Posts: 68
|
| PIC 16F877 USART Interrupt problem |
 Posted: Sat Jun 06, 2009 11:33 am |
 |
|
Hello! I have got a problem using the USART interrupt. My code is the following…
| Code: |
#include <16F877A.h>
#FUSES XT, NOWDT, NOPUT, NOPROTECT, NOBROWNOUT, NOLVP, NOCPD, NOWRT
#use delay (clock = 4000000)
#use rs232(baud=9600, Bits=8, Parity=N, xmit=PIN_C6, rcv=PIN_C7, stream=module)
#int_rda
void module_uart_isr()
{
output_high(led3);
delay_ms(400);
output_low(led3);
delay_ms(400);
fgetc(module);
....Settings
}
void main()
{
....PIC settings
enable_interrupts(int_rda);
enable_interrupts(global);
while(1)
{
delay_ms(100);
}
}
|
The problem is that I cannot go the interrupt service routine even if I am sending data to the PIC microcontroller. I haven’t got any hardware problem for sure, because I am using the same interface without problems but with not any USART interrupt. |
|
 |
PCM programmer
Joined: 06 Sep 2003
Posts: 21708
|
|
|
Lykos1986
Joined: 26 Nov 2005
Posts: 68
|
|
| Posted: Sat Jun 06, 2009 12:01 pm |
|
|
Well, first of all thanks for the fast respond! But the problem remains!
I have totally remove the delays from the interrupt service routine and I am measuring the pin using an oscilloscope… Still nothing… |
|
|
PCM programmer
Joined: 06 Sep 2003
Posts: 21708
|
|
| Posted: Sat Jun 06, 2009 12:07 pm |
|
|
Strip the program down so it's very simple. Don't use streams.
Just echo a received character back to the PC. Here's an example:
http://www.ccsinfo.com/forum/viewtopic.php?t=37380&start=3
Carefully check all your connections, including the PIC, the Max232 chip,
and the cable. |
|
|
Lykos1986
Joined: 26 Nov 2005
Posts: 68
|
|
| Posted: Sat Jun 06, 2009 3:35 pm |
|
|
It’s already very simple program… and it is almost impossible not use the streams. I am trying to communicate with a GSM module and I have got strait connections between the PIC and the module. No MAX232 chips or any other interfacing circuit between them.
My hardware is 100% OK and tested with software’s without interrupts… the problem is the software that use interrupt service routines, but I don’t know what I have to do!
I was trying to debug the system looking for what happens with the INTCON reg, PIE1 reg and finally PIR1 reg. The only problem was that the bit 5 from the PIR1 reg was always 0 so it is almost impossible to have an interrupt because the buffer is empty! |
|
|
PCM programmer
Joined: 06 Sep 2003
Posts: 21708
|
|
| Posted: Sat Jun 06, 2009 4:07 pm |
|
|
If you tested it on a PC (with a MAX232 chip), then you would prove to
yourself that you can make an #int_rda routine work.
You don't need to debug the PIR1 register. Just make that sample
program work. |
|
|
Ttelmah
Guest
|
|
| Posted: Sun Jun 07, 2009 2:30 am |
|
|
I'd suggest you triple check the hardware.
You have to understand, that RCIF, is a completely _hardware_ based bit. It _is_ set, automatically, if pin C7, goes low, for more than about 2/3rd the bit time. Nothing else is needed to trigger it.
Also, the standard getc routine, if you are reading data from the hardware UART, _uses this signal_.
The code, as posted by PCM_programmer, in thread 37380, - don't change it, except to select the 877, instead of 876, _will_ work, if your hardware is functional. If it doesn't, you have a hardware problem.
Best Wishes |
|
|
Lykos1986
Joined: 26 Nov 2005
Posts: 68
|
|
| Posted: Sun Jun 07, 2009 4:03 am |
|
|
When I am using that program:
| Code: |
#include <16f877A.h>
#FUSES XT, NOWDT, NOPUT, NOPROTECT, NOBROWNOUT, NOLVP, NOCPD, NOWRT
#use delay (clock = 4000000)
#use rs232(baud=9600, Bits=8, Parity=N, xmit=PIN_C6, rcv=PIN_C7, stream=Module)
#use rs232(baud=9600, Bits=8, Parity=N, xmit=PIN_C0, rcv=PIN_C1, stream=PC)
void main()
{
int i=0;
...Configurations...
while(1)
{
if (kbhit(PC))
{
i=fgetc(PC);
fputc(i,module);
}
if (kbhit(module))
{
i=fgetc(module);
fputc(i, PC);
}
}
}
|
I can sent AT command from my PC to the GSM module and vice-versa, without any problem. So, it is almost impossible to have any hardware problem! |
|
|
Ttelmah
Guest
|
|
| Posted: Sun Jun 07, 2009 1:31 pm |
|
|
So, if you use the code modified to give an interrupt version:
| Code: |
#include <16f877A.h>
#FUSES XT, NOWDT, NOPUT, NOPROTECT, NOBROWNOUT, NOLVP, NOCPD, NOWRT
#use delay (clock = 4000000)
#use rs232(baud=9600, Bits=8, Parity=N, xmit=PIN_C6, rcv=PIN_C7, stream=Module)
#use rs232(baud=9600, Bits=8, Parity=N, xmit=PIN_C0, rcv=PIN_C1, stream=PC)
int1 have_byte=false;
int8 val;
#int_rda
void int_rx(void) {
val=fgetc(Module);
have_byte=true;
}
void main()
{
int i=0;
...Configurations...
enable_interrupts(INT_RDA);
enable_interrupts(GLOBAL);
while(1)
{
if (kbhit(PC))
{
i=fgetc(PC);
fputc(i,module);
}
if (have_byte)
{
have_byte=false;
i=val;
fputc(i, PC);
}
}
}
|
What happens?.
Best Wishes |
|
|
dyeatman
Joined: 06 Sep 2003
Posts: 1924
Location: Norman, OK
|
|
| Posted: Sun Jun 07, 2009 3:16 pm |
|
|
For safety reasons shouldn't he add ERRORS to the USE statement?
_________________
Google and Forum Search are some of your best tools!!!! |
|
|
Ttelmah
Guest
|
|
| Posted: Mon Jun 08, 2009 4:01 am |
|
|
Yes, though obviously only on the 'Module' stream.
It is always worth having this on hardware UARTs.
However, as the 'test' code stands, it shouldn't make a difference, _unless he is taking a long time, in the unpublished 'Configuration' section, that is not posted_. If so, it'd explain everything.....
Best Wishes |
|
|
Lykos1986
Joined: 26 Nov 2005
Posts: 68
|
|
| Posted: Mon Jun 08, 2009 9:14 am |
|
|
What you mean | Ttelmah wrote: | | unless he is taking a long time, in the unpublished 'Configuration' section, that is not posted |
Well, in the “Configuration” section I am using long delays a couple of times… |
|
|
|
|
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
