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 CCS Technical Support
Problem with #INT_EXT for UART

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



Joined: 24 Jun 2007
Posts: 14

View user's profile Send private message

Problem with #INT_EXT for UART
PostPosted: Fri Jul 20, 2007 10:09 pm     Reply with quote
Hi

I am using a bootloader that requires the hardware UART to function. So I need to use a software UART for communications. I do this with INT_EXT.

Code:

#use rs232(baud=31250, rcv=PIN_B0, PARITY=N, FORCE_SW)


Below is my interrupt routine:

Code:

#INT_EXT
void ext_isr(void)
{
     unsigned char midi_message;

     if(status_ignore_interrupts)
     {
          while (RDAIF) getc();   //flush buffer
          return;
     }

     buffer[0] = getc();

     return;
}


The program starts with 'status_ignore_interrupts' set to TRUE. And so any data sent over RS232 is ignored and it works fine.

But when I change the status_ignore_interrupts to FALSE, the program hangs (in getc()). It hangs before I even have a chance to send any data. What I'm wondering is how the interrupt service routine was even activated in the first place!

I think I have made a fundamental mistake, because I know that software UARTs need to be handled differently to hardware UART.

Any help would be great.

Thanks.
Ttelmah
Guest
PostPosted: Sat Jul 21, 2007 4:50 am     Reply with quote
Your problem, is that this probably isn't going to work...
Unfortunately, the software UART, can only be used with an interrupt like this, at relatively _low speeds_. You _must_ arrive inside the interrupt handler and start the 'getc', no more than 1/2 the bit time after the RS232 falling edge is seen (and preferanly quite a bit sooner). Now, at 31250bps, this is just 16uSec (and really something like 10uSec, is probably all that can be safely allowed). Now it takes about thirty instruction times, from an interrupt event, to arrive in the handler (and a lot more if there are othr handlers etc.), which limits the maximum speed useable this way.
You don't mention what your clock rate is.
There are some things that may help.
First, try the option 'sample_early', in the RS232 setup. This tells the compiler to not add the half bit time delay into the software UART implementation.
Second, handle your disable flag differently. Just do:
Code:

#INT_EXT
void ext_isr(void) {
     unsigned char midi_message;
     int8 temp;
     temp=getc();

     if(!status_ignore_interrupts)
         buffer[0] = temp;

}

This makes the getc, the very first thing in the handler (saving a few instructions), and then just transfers the character to the buffer if the 'ignore' flag is off.
Really though, why not use the hardware UART?. It is quite normal to use the hardware bth for a bootloader, and for other tasks in the main code. You only need some way of telling if the data is meant to be for the bootloader or not (another line, time after startup, etc. ec.). Alternatively, if the bootloader is using a lower baud rate, then use the software UART for this.

Best Wishes
caddy



Joined: 24 Jun 2007
Posts: 14

View user's profile Send private message

PostPosted: Tue Jul 24, 2007 7:48 pm     Reply with quote
Thank you, ttelhmah. This is the reassurance that I needed.

For some reason I thought that I couldnt use the UART for both bootloader and other comms.. but now it seems ok - thanks!
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