strange

[Christophe]

on RDA interrupt this happens:

[Ttelmah]

First: Do _not_ disable and enable the interrupt inside the handler. The chip itself disables the _global_ interrupt for you. Ideally (personal choice here), you can add the option 'noclear' to the handler header, then clear the interrupt yourself as the first line of the handling code, which then allows you to test at the end of the handler for the interrupt being set, and loop back inside the handler if it is. This gives better handling of 'fast' interrupts than the default code. However the simplest solution is to not fiddle with the interrupts at all in the handler.
Second, your code should only read one character from the serial. As it stands, if you see the incoming 'COMMANDO_BYTE', the code will sit inside the interrupt handler for five more character times. Look at a 'state machine', that in the first state, looks for this command byte, if it is found, it advances to the next state, and exits.. On the next interrupt the first character is read, ad you advance to the next state. As written, the code is only using interrupts to find the first character, which is inefficient, and may cause problems for other code. If the five characters do not arrive, the code will be 'hung' inside the handler.
I'd suspect your 'hang', is the result of more characters arriving while you delay. If so, adding 'errors' to your #use RS232, _may_ prevent this happening, but a better solution is not to have delays in interrupt handlers. There have been a _lot_ of posts explaining the problems this can cause in the past. Why on earth would you want to delay, of the charater is not a recognised one?.
The code as written, is a good example, of how _not_ to write an interrupt handler.

Best Wishes

[Douglas Kennedy]

Ttelmah is right you shouldn't try to pick up more than one char in an RDA interrupt service routine. There must be a hundred posts on this issue... to have a chance of success you need to learn from others and have your interrupt routine accept the single char thats been recieved and save it in a circular buffer. In you main routine you can parse the circular buffer looking for the command sequences you want.
This circular buffer is provided behind the scenes by PC operating systems so it is often ommitted in a PIC design..the PIC hardware buffer is two chars deep one just received and one possibly being received..you will need a circular buffer. As for the clearing of interrupt flags it is always good practice to look at the .lst file ..thats where you can see that the compiler does it for you.

[Christophe]

[Ttelmah]

'Errors', will prevent the UART hardware hanging, if the internal hardware buffer overflows.
Consider rewriting, using the ex_sisr code that comes with the compiler. This shows how to buffer incoming characters. Have your main code, use bkbhit to check for characters waiting. When one arrives, retrieve it with bgetc, and check if it is the command header. If so, look for the rest of the command, using almost exactly the code you currently have in your interrupt. The key with this, is that the UART will still retrieve characters while you are doing this.
Alternatively, consider a state machine. You have a static variable 'state', that you set to zero, then a switch statement in the interrupt handler, using this variable. At the start of the interrupt handler, you retrieve the character (since there has been an interrupt, there will be a character). Then you enter the switch statment, which as the first state, checks for this being the command character. If it is, you increment the state, and exit. If not, you leave the state where it is. You then advance through the states for each incoming character, storing them into the array as required. On the last character, you launch a hardware timer, and set the state back to zero. When the hardware timer expires (and interrupts), you do what you need at the end of the time.

Best Wishesw

[Christophe]

I'm having difficulties understanding that code, can you post in code what you mean?

What exactly is the problem with my code? That while the UART is waiting for a character, - and none arrives - the program is stuck in that isr() ?
Then I can use timed_getc() no?

[Christophe]

Ok I modified the code, so that it can NEVER get stuck inside the isr();
Can you evaluate?