Right, you had it backwards. An N-channel MOSFET is comparable to an NPN bipolar transistor, and a P-channel MOSFET is comparable to a PNP.
But MOSFETs are voltage-controlled, not current-controlled.
Polarities and directions of arrows are all reversed for a P-channel MOSFET or PNP transistor when compared with an N-channel MOSFET or NPN transistor. Electrode names and functions do not change.
An N-channel MOSFET is turned on by positive voltage on the gate relative to the source.
An NPN transistor is turned on by positive voltage and current flow into the base and out the emitter.
A P-channel MOSFET is turned on by a negative voltage on the gate relative to the source.
A PNP transistor is turned on by negative voltage and current flow out of the base and in the emitter.
I don't really understand your question. If you need to receive serial data, you should use the USART. It is possible to receive serial data on a general I/O pin using a technique called a software UART, but if you already have enough real USARTs for all the signal(s) you want to receive, you should use it/them.
A USART will produce an indication (RCIF in your case) when a character is received; this signal should also be able to generate an interrupt; this is probably an option that's enabled by a control register. For applications where you need the data reception process to run in the background, and when data is being received rapidly, an interrupt-driven architecture is used.
With an interrupt-driven receive architecture, when a byte is completely received by the USART, the USART indicates this on the RCIF flag, and triggers an interrupt. This interrupts the MCU core and causes it to suspend execution of the code that it was previously running, and execute a section of code called an interrupt handler.
The interrupt handler reads the received byte, clears the RCIF flag (if this isn't automatically done by the USART when the received byte is read), and does something with the received byte. It may simply store the byte in a buffer somewhere in RAM, ready to be processed by other code. Or the interrupt handler may decode or interpret the received byte and take some kind of action, such as transmitting a byte in response, setting a flag, incrementing a counter, etc. Then the interrupt handler returns, and execution of the main code continues.
Some interrupt handlers require interaction with the main code. The type that puts data into a buffer needs the main code to poll the buffer and remove data that has been put there by the interrupt handler. Otherwise, the buffer will become full and the interrupt handler will have to throw away bytes.
Some interrupt handlers implement a whole communication protocol. These make use of state machines or coroutines so that the interrupt handler knows "where it's up to". These systems can operate almost completely independently of the main (non-interrupt) code. Communication with the other code can be through flags (semaphores), counters, queues and other programming structures. These interrupt handlers usually have multiple interrupt sources that they can use; for example, when the interrupt code is transmitting a stream of bytes, it will make use of the USART's transmit ready interrupt to trigger each byte transmission.
If the USART is only receiving characters slowly, and your main code doesn't need to do anything complicated, a polling loop is the normal solution. Your code is written as a loop. Within the loop, inputs are checked, decisions are made, and outputs are updated, as appropriate. The USART received data signal is one of the inputs that needs to be checked. There are a few variations on the theme of a loop-based architecture, and which is best depends on what functions the code needs to perform.
If you give more information about the received serial data, I can be more specific.