You can do it with a standard 11.0592Mhz 8051.

Looking at your other I/O requirements:

1). 4x4 keyboard: msec time range
2). LCD interface: assume async
3). RS485: Uart handles it.

Looks like your interrupt priority would be:
1). Bit reading on INT0/
2). Byte RX on UART
3). LCD pixel slamming
4). Keyboard polling

Granted I don't know what your LCD interface requirements are but I assume this is for a product similar to Veriphone or Hypercom's terminals. So that wouldn't be anything in the LCD that requires high speed attention.

You can choose when to updat your LCD and when to transmit our your UART, you could handle those in foreground if you wanted to.

I only use Phillips 8051 products so those are the restrictions I know. I get 4 interrupt levels (2 is standard?). Just set your INT0/ routine up as your highest interrupt so it cuts in on ANY other routine. A 50us interval shouldn't affect the operation of any other devices. Your next critical interrupt would be your RX Byte ready, which would have to be very high speed to conflict (say about 115.2K which an 11.0592 won't support well anyway).

The code example I wrote could be made iven quicker by only using the Ri registers in a reserved register bank. Accesses to store partial data in Ri registers is usually a 1us faster than accesses direct or indirect memory.

You have to ensure that you have enough stack space for the worsecase call depth with recursive interrupts. I typically set STACK to E0h in ISEG and have plenty of room for a full four levels of interrupts.

You can postpone the xor encode/decoding until you've framed up a character. After all, the real purpose of you interrupt is to get the data and keep it until your foreground or tasker is ready to process it. Sometimes the trick to timely interrupt handling is to avoid doing too much. Of course, you don't have to do any decoding until after you've grabbed the data before your 50us window closes. The example code I showed did that in about 25us.

Whereas I simply rotated bits into a byte, you have the choice to xor compress it then or later. A ugly piece or code, but fast, would be to shift the incoming bits into 10bits of Ri registers in the reserved register bank and then using the last 8bit byte as a table offset to the character you decode into. The key here is using the

MOV A,@A+DPTR
or
MOV A,@A+PC

Its wasteful of memory but most 8051s have more than we need these days. You could use a spreadsheet program to build your conversion table. Each table entry could have the converted nibble in the low 4bits and the expected parity 2bits in the other nibble.

At the wordtime, you use the 10bits in the Ri registers to map a decode and compare the 2bit parity also loaded from the table.

However, if you use this technique which I can recommend due to its waste, you would have to remember that the table has TWO patterns for each nibble. The encoding method is giving you transitions of 1's and giving you data ready clocks on both sides of the transition. The xor of two bits is a bi-polar transition detector. So your table would map the last 8 bits (2bits x 4databits) as an address offset into a table. The table would have a byte for each viable pattern. As above, you could make the table entry be the decoded value and the expected parity 2bit pattern combined. If the 2bit parity pattern matched that in the Ri register, you could mask all but the low nibble as data for you 40 character buffer.

But in truth you have plenty of time to decode the dibits (2bits) at the bit interrupt time. Various techniques can be used. You could use a bseg flag to toggle upon every data ready pulse on INT0. In one case you collect the bit, in the other case you xor the current bit with the last bit an then shift into ri via the carry like my example. This is the way I'd do it. Instead of counting 8 bits, just count 5 bits into the Ri register. When done, either throw it into a pointed buffer (Use a MOV @R0,A and INC R0). You can include a 40byte counter too.

All of this can be done in 50us. It sounded like you had to respond within 50us but that the next pulse would be at least 250us later. That means you could actually spend an additional 150us or so after you've read the data bit into a register to do the decoding stuff.

So, you have ample capability with a standard 8051.

Heck, I might just write it for sport.
8-)

-Jay C. Box