CCS C Software and Maintenance Offers
FAQFAQ   FAQForum Help   FAQOfficial CCS Support   SearchSearch  RegisterRegister 

ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

CCS does not monitor this forum on a regular basis.

Please do not post bug Reports on this forum. Send them to support@ccsinfo.com

Can't get #int_rda to work

 
Post new topic   Reply to topic    CCS Forum Index -> General CCS C Discussion
View previous topic :: View next topic  
Author Message
kinf



Joined: 19 Jul 2011
Posts: 7

View user's profile Send private message

Can't get #int_rda to work
PostPosted: Tue Jul 19, 2011 5:07 pm     Reply with quote

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: 1005
Location: Tewksbury, MA

View user's profile Send private message

PostPosted: Tue Jul 19, 2011 6:17 pm     Reply with quote

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: 1555
Location: Perth, Australia

View user's profile Send private message Send e-mail Visit poster's website

PostPosted: Tue Jul 19, 2011 6:25 pm     Reply with quote

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

View user's profile Send private message

PostPosted: Tue Jul 19, 2011 6:37 pm     Reply with quote

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

View user's profile Send private message

PostPosted: Tue Jul 19, 2011 6:44 pm     Reply with quote

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: 1005
Location: Tewksbury, MA

View user's profile Send private message

PostPosted: Tue Jul 19, 2011 7:23 pm     Reply with quote

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

View user's profile Send private message

PostPosted: Tue Jul 19, 2011 7:33 pm     Reply with quote

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

View user's profile Send private message

PostPosted: Tue Jul 19, 2011 11:58 pm     Reply with quote

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: 20384

View user's profile Send private message

PostPosted: Wed Jul 20, 2011 12:22 am     Reply with quote

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

View user's profile Send private message

PostPosted: Wed Jul 20, 2011 6:39 am     Reply with quote

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

View user's profile Send private message

PostPosted: Wed Jul 20, 2011 7:30 am     Reply with quote

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

View user's profile Send private message

PostPosted: Wed Jul 20, 2011 10:49 am     Reply with quote

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.
Display posts from previous:   
Post new topic   Reply to topic    CCS Forum Index -> General CCS C Discussion All times are GMT - 6 Hours
Page 1 of 1

 
Jump to:  
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