| View previous topic :: View next topic |
| Author |
Message |
kinf
Joined: 19 Jul 2011
Posts: 7
|
| Can't get #int_rda to work |
 Posted: Tue Jul 19, 2011 5:07 pm |
 |
|
I've looked up problems on this site but no answers. My best guess is the compiler is the problem.
I'm using the code example from CCS and the only thing I've added was an LED light to indicate that it goes there. The processor is an 16f877. Even tried ERRORS and UART1
version is 4.111
Anyone have a clue on what's going on?
| Code: |
#define LED PIN_A4
#define OFF 1
#define ON 0
do {
delay_ms(10000);
printf("\r\nBuffered data => ");
while(bkbhit)
putc( bgetc() );
output_bit(LED,OFF);
} while (TRUE);
} |
++++++++++++++++++++
Ex_sisr.c code removed except for LED part.
-- Forum Moderator
++++++++++++++++++++
|
|
 |
ezflyr
Joined: 25 Oct 2010
Posts: 1019
Location: Tewksbury, MA
|
|
| Posted: Tue Jul 19, 2011 6:17 pm |
|
|
Hi,
You aren't supposed to post CCS example code, so you've already run afoul of the forum guidelines.
May best guess is that you've got a circuit or wiring problem. Can you describe your circuit, and how you are testing this code?
John |
|
|
asmallri
Joined: 12 Aug 2004
Posts: 1635
Location: Perth, Australia
|
|
| Posted: Tue Jul 19, 2011 6:25 pm |
|
|
Not answering your question but...
Using the % modulas operation in the interrupt handler is very inefficient. Faster and more compact code is generated by testing if the index has exceeded a max value and, if so, set the index to 0
_________________
Regards, Andrew
http://www.brushelectronics.com/software
Home of Ethernet, SD card and Encrypted Serial Bootloaders for PICs!! |
|
|
kinf
Joined: 19 Jul 2011
Posts: 7
|
|
| Posted: Tue Jul 19, 2011 6:37 pm |
|
|
Oops, didn't know that. I've seen the same code when doing a search on this forum.
The hardware is proven. Simple max232 converter for the level shift. Has worked fine in the past without interrupts. I can verify with standard printf commands and see it on my monitor. I have the LED output going high if it enters the irq routine. I only see it happening once in the beginning of the program, probably clearing out what was leftover. It never lights after that. Seems to me it's more of a compiler issue. I'm not good with assembly so I don't have a way to verify if the uart code is compiled correctly.
Not sure where else to focus on. |
|
|
kinf
Joined: 19 Jul 2011
Posts: 7
|
|
| Posted: Tue Jul 19, 2011 6:44 pm |
|
|
Hi Andrew,
Nice to see you here, I purchased your code for smartcard a couple a years ago. Nice coding, it helped me understand C a bit better. Still concider myself just a novice at this stuff, even though I been around it for a while.
Vince |
|
|
ezflyr
Joined: 25 Oct 2010
Posts: 1019
Location: Tewksbury, MA
|
|
| Posted: Tue Jul 19, 2011 7:23 pm |
|
|
Hi,
Well, maybe it's the compiler, but 98% of the time someone says 'compiler bug' it really turns out to be 'programming bug' or 'hardware bug'.....
You seem convinced that the hardware is OK. Printf's will test the hardware in one direction, sending data, but what about receiving data? I'd write a short program (without the interrupt) that sits in a loop looking for an incoming character with getc. As soon as you receive the character, immediately use putc to spit it back out. Until you can do this simple task, I wouldn't bother with the interrupt.... Once this works, the CCS example will to!
John |
|
|
kinf
Joined: 19 Jul 2011
Posts: 7
|
|
| Posted: Tue Jul 19, 2011 7:33 pm |
|
|
I have a o-scope on the xmit line and rx lines and have monitored it on the chip itself. If the IRQ would work, any toggle of those lines should bring it into the interrupt routine. This isn't happening. The software is taken directly from the sample code, so that should rule on the software. I have no problem without the int routine since I have been using the same setup with no issues with normal printf and getc, but I need to use the int routine.
| ezflyr wrote: | Hi,
Well, maybe it's the compiler, but 98% of the time someone says 'compiler bug' it really turns out to be 'programming bug' or 'hardware bug'.....
You seem convinced that the hardware is OK. Printf's will test the hardware in one direction, sending data, but what about receiving data? I'd write a short program (without the interrupt) that sits in a loop looking for an incoming character with getc. As soon as you receive the character, immediately use putc to spit it back out. Until you can do this simple task, I wouldn't bother with the interrupt.... Once this works, the CCS example will to!
John |
|
|
|
FvM
Joined: 27 Aug 2008
Posts: 2337
Location: Germany
|
|
| Posted: Tue Jul 19, 2011 11:58 pm |
|
|
You are saying that the unmodified ex_sisr.c doesn't work with your 16F877A board and V4.111, although the serial pins showed it's correct wiring with non interrupt driven code?
I agree, that it sounds unlikely, but don't say it can't be before checking it under same conditions. Unfortunately I don't have a 16Fxx system at hand and no V4.111 installed now. Can someone confirm, that the interrupt is working with V4.111? As everyone knows, there have been arbitrary changes to the compiler creating new bugs, and silent bug fixes, too.
| Quote: | | Using the % modulas operation in the interrupt handler is very inefficient. |
CCS C uses and operation for modulus power of two. It's becoming inefficient only if you change the buffer size without this restriction in mind. |
|
|
PCM programmer
Joined: 06 Sep 2003
Posts: 21708
|
|
| Posted: Wed Jul 20, 2011 12:22 am |
|
|
| Quote: | | Can someone confirm, that the interrupt is working with V4.111? |
Yes, it is. I installed vs. 4.111 and modified Ex_sisr.c only to change the
#use delay() to 4 MHz to match the crystal on my PicDem2-Plus board.
I ran it on a 16F877 and typed in "asdf" a few times after the program
started and got this output:
| Quote: |
Running...
Buffered data => asdfasdfasdfasdf
Buffered data =>
Buffered data =>
Buffered data =>
Buffered data =>
Buffered data =>
|
|
|
|
kinf
Joined: 19 Jul 2011
Posts: 7
|
|
| Posted: Wed Jul 20, 2011 6:39 am |
|
|
| Crap, wonder why mine has issues. I ordered the latest download cable, hoping that it might solve the problem. The current one has been flakey, but I really don't see it being the problem. I will try it on a different board. Very frustrating. Thanks for confirming that the sample code works. |
|
|
kinf
Joined: 19 Jul 2011
Posts: 7
|
|
| Posted: Wed Jul 20, 2011 7:30 am |
|
|
| Thanks guys. I found the problem. I ended up getting together another identical board. It runs on this one. I should of been clued in that there was a communications problem when I would get garbage initially when the system powered up. Then correct characters. The crystal must be off or some other hardware issue. I'll have to investigate. It's been my test board for a while, must of flaked out recently. It was good that you guys made me question everything instead of being focused on what I thought was wrong. |
|
|
kinf
Joined: 19 Jul 2011
Posts: 7
|
|
| Posted: Wed Jul 20, 2011 10:49 am |
|
|
| kinf wrote: | | Thanks guys. I found the problem. I ended up getting together another identical board. It runs on this one. I should of been clued in that there was a communications problem when I would get garbage initially when the system powered up. Then correct characters. The crystal must be off or some other hardware issue. I'll have to investigate. It's been my test board for a while, must of flaked out recently. It was good that you guys made me question everything instead of being focused on what I thought was wrong. |
Update: It ended up being a bad solder joint on pin 16 of the max232 chip, this is the 5v power. The strange part was the chip was able to function enough to throw me off. The charge pumps were able to supply enough power to transmit, but receive timing was off because of it even though I saw signals on the micro end. Still not sure why the levels did not trigger an interrupt, my only guess is the baud rate was skewed enough to not be accepted. |
|
|
|
FAQ 
Search
Register
Profile 
Log in to check your private messages 
Log in
