HIGH_INTS = TRUE

jseidmann · Joined: 04 Nov 2004 Posts: 67

I am currently using the PCWH version 3.190 and I am considering upgrading to the newest compiler version, specifically to get access to the '#DEVICE HIGH_INTS = TRUE' command.

The reason is because I want to be able to have my INT_RDA a higher priority. I am having some problems with my RS-485 and believe that having a hardware interrupt (this is what HIGH_INTS does, no?) will help me out.

My question is: do I understand this correctly? Is that what HIGH_INTS does? If so, how do I implement it? Do I just add that one line? Do I need to add anything else?

Any comments are appreciated,

thanks

treitmey · Joined: 23 Jan 2004 Posts: 1094 Location: Appleton,WI USA

HIGH_INTS are beyond my scope.
They have to do with the stack and a high int breaking out of a low int.

BUT

Have you tried #priority?

ckielstra · Joined: 18 Mar 2004 Posts: 3680 Location: The Netherlands

jseidmann · Joined: 04 Nov 2004 Posts: 67

To clear a few things up, here is my situation:

I am using a PIC18F252 on a fairly intensive data acquisition product. When this product is 'off' so to speak, that its only collecting some data, then the RS-485 works flawlessly for 72 hours (thats how long I ran a test for).

If I turn on all of the data acquisition capabilities, it 'drop's' some RS-485 commands. It drops roughly 25 commands an hour (running at 19200 baud).

The interrupts are never disabled at any time. Ever. My question is that since the RS-485 interrupt should ALWAYS be interrupting any routine that the main program is in, I should never be having this RS-485 problem, but for some reason this problem is happening.

I am currently using 2 interrupts, the INT_RDA, and the TIMER2 interrupt which executes every 1/2 a millisecond. INT_RDA has been made a higher priority on the #PRIORITY with no improvement in the RS-485 performance. I feel that perhaps by using the HIGH_INTS = TRUE and making the RDA a #INT_RDA HIGH will improve this. Does that make sense? I tried making the #INT_RDA FAST, but the data acquisition process that used the TIMER2 interrupt did not work at all.

I am certainly up for any suggestions, but remember I am using compiler 3.190

Thanks!

MikeValencia · Joined: 04 Aug 2004 Posts: 238 Location: Chicago

I use

#priority EXT,TIMER3

in my code. Also, instead of using high priority interrupts (since the syntax overwhelms me!), i do the following:

Say i'm in the TIMER3 isr, then I check if the EXT interrupt flag is set. So I just call the function called by my INT_EXT isr. This way i avoid the latency of exiting the current isr, and then re-entering the pending isr.

There is still some latency, which depends on how soon you check for the pending interrupt flag while still in the current interrupt, but it is significantly reduced.

jseidmann · Joined: 04 Nov 2004 Posts: 67

How do I check if the interrupt flag is set as you suggest?

ckielstra · Joined: 18 Mar 2004 Posts: 3680 Location: The Netherlands

Another optimization that often is overlooked in the int_rda handling is that you can check for more characters to be waiting. The hardware UART can buffer up to three characters and you can read all of them in a loop instead of only reading a single character.

MikeValencia · Joined: 04 Aug 2004 Posts: 238 Location: Chicago

Ttelmah · Guest

As a comment, it is probably more efficient, to just declare the flag with a #bit declaration.So (for a PIC18):

MikeValencia · Joined: 04 Aug 2004 Posts: 238 Location: Chicago

[code]
.................... if (PIC_INTCON & PIC_INTCON_INT01F)
03A4: BTFSS FF2.1
03A6: BRA 03B4
[/code

Actually the generated assembly is optimized with a one-line btfss statement. I totally agree though that using #bit to declare it is more readable and use-able. I remember in my past job that it irked some people maintaining my code that all my code looks like cryptic logical operations.

asmallri · Joined: 12 Aug 2004 Posts: 1634 Location: Perth, Australia

EdWaugh · Joined: 07 Dec 2004 Posts: 127 Location: Southampton, UK

Hi,

Just wanted to say cheers to ckielstra for his great tip on the hardware buffer being 3 bytes long, by reading all present instead of just one I fixed my code.

cheers

ed

ckielstra · Joined: 18 Mar 2004 Posts: 3680 Location: The Netherlands

EdWaugh · Joined: 07 Dec 2004 Posts: 127 Location: Southampton, UK

Hi,

My code is much better now with the previous suggestions but I've noticed a little bit of occasional data corruption. This wasn't present during some testing I did just transfering bytes from one serial port to another using my circular buffers but is now when I add the rest of my code.

Basically I have a rs232 device that throws a string at me at 8Hz. I use a high priority rda interrupt to read as many chars as are available and test OERR like ckielstra suggests. This just chucks these into a circular buffer.

There is also a 40Hz timed interrupt that amongst other (fast) things checks the circular buffer and once a full sentence is received writes it to the mmc card buffer using:

ckielstra · Joined: 18 Mar 2004 Posts: 3680 Location: The Netherlands

Use the error-flags of the UART to figure out if it is a framing error or an buffer overrun error.

In case of framing error the problem is most likely a timing error between the clock speed of the sender and receiver. Only about 5% total error margin for sender and receiver together is allowed. Some PC's are known to be terrible inaccurate.

In case of an overrun error you know you are reading too slow. Do you have other interrupts active? Also note that some of the compiler inbuilt functions will disable all interrupts, think of functions like memcpy and a software UART.