It did work.
Hi Bruce,
I do have some difficulty in this logic that I think is due to too much info comming from my serial display or a lack of complete understanding of the onboard eusart. Just FYI Im communicating to a Crystal Fonts 633 serial display. " http://www.crystalfontz.com/products/633/index.html " I have no problems talking to it, although the crc routine that it requires was a bit of a bugger. But only because Im used to LRC. So every time I send the display any Information like (display data), (Contrast Values), (Backlight Values) or anything else, it sends my an acknologment. Normally this is fine, and easy to deal with. But if you look at the Their specs you will find that their Packets have little "common" structure. Their is no (start Byte Char) or (end Byte Char) in the packet and their is no (standard packet length). Some packets are as little as 5 bytes in total packet size and some are as great as 20 bytes in total packet size. The only thing that i have to work with is the 2nd Byte (length of data) and the last 2 bytes are the crc. But screw the receive CRC, I dont think that i have enough time for the added calculations even though the crc routine is easily usable. Not to mention the display is only 1 inch away from my 18f2620. I just feel like i hardly need soo much structure when im not cableing my communication across a room. The part Im currently working on is the built in keypad in the display, Its really Cool!
So Basically the keypad receive packets look like this:
(Command,Length of data,Data,CrcLo,CrcHi) so if I press and release the (down key) on the display keypad I get
Down Key Pressed ($80,$01,[dont care],CrcLo,Crchi) Im trying to ignore this Packet when down
Down Key Released ($80,$01,$08,CrcLo,Crchi) Only care if released.

My controler is very busy with Pid algorithems plus Im communicating with a PC on seperate pins as well as a few I2C devices on my i2c bus.
Because of all of this activity I'm attempting to use my Hardware serial input without a pause for the LCD.

I have thought about using a seperate 12f683 As my "LCD Menu controller" and then using my 18f2620 to communicate via i2c with my own simple protocol. That way the 12f683 can work its butt off parsing whats needed and taking the necessary time to do so.

From your experience, do you have any suggestions as to the best way to parse this data?
Do you like or favor the idea of a seperate pic like the 12f683 do to my requirements?

Your Ideas will be graciously appreciated.

thanks Ash Tillotson