A need for protecting a buffer which is only accessed within an ISR

I don’t think it’s the same UART. You should check the wiring on the board. Then you can easily determine the interrupt source and distinguish the Rx data.
If both devices are wired to the same UART the HW is kind of broken (UART is not a bus) or it’s somehow ensured that only ONE device is active on the serial interface at a time. Then again you could get the information which device talks to the UART.

don’t you think if you write to a UART’s TX/RX register, it would invoke an IRQ handler?

Sorry - I don’t understand the question.

When you enter a character in a serial port, it gets written to UART’s RX register, agreed?

Yes. I wrote a number of serial drivers for different MCUs in the past so I’m aware how some UARTs work.

Right. When you write to TX register of the UART, a UART IRQ handler is fired and so does in the case of when you write to an RX register of the UART.

In my case, whatever gets sent from the BLE service is sent over UART. Meaning an IRQ handler is invoked either when 1) data is received from the BLE service 2) Data is received from the COM port.

Questions: 1) how do you handle the situation when data is sent over UART from either source? 2) protect the data being to Fifo such that data from one source doesn’t get mixed with another

We took care that the HW was done right. In your case 1 UART connected to COM port (whatever that is) and a 2nd UART connected to BLE device. Many MCUs support multiple UARTs and/or USARTs so this was never a problem when designing a board accordingly.
Did you check your HW and are you 100% sure that both devices are electrically connected to the SAME UART Tx/Rx pins ?

Edit: regarding question 1) it can’t be resolved without knowing which device is active as I explained before.

Did you check your HW and are you 100% sure that both devices are electrically connected to the SAME UART Tx/Rx pins ?

Maybe I’m misunderstanding. There’s one USB-TTL cable that connects to the RX/TX pins on the MCU. You could receive from it, or write to it, either shall fire the same IRQ handler, correct?

I can‘t help you writing your UART driver. Take the reference manual and start coding as I did. :slight_smile: and ask the HW designer how the board is supposed to work.
Good luck !

1 Like

The problem isn’t with the driver itself. But thanks everyone for the help :slight_smile:

The interrupt happens, the ISR reads the input character.

If the character is from source 1, add it to reception buffer 1, if from source 2 to reception buffer 2; tell the receiving task (or tasks) that there’s data to process.

But if the ISR can’t tell which source the input character is coming from, you’re screwed; no amount of later processing can make sense of the scrambled data stream.

SW, and I know of no hardware where the ISR gets a character and it doesn’t know which device it came from. Ultimately it will get the character out of a device buffer that will be connected to a given data source, so it knows where the data is coming from.

How would you know which source the data came from inside the ISR though?

Again, Furx, it is about time you give us a drawing of what you try to do as you seem to be the only one here who understands it.

Are you thinking about wiring up two physical sources to the same Rx pin (possibly electrically decoupled with diodes)? If so, there is by definition no way to distinguish between the sources as the UART can only respond to what comes in on the line.

In any other setup, it’s very simple on the MCU level: A character comes in, and your code can read it from the DR register, and if a character needs to be transmitted, your code (ISR and/or task, many possible combinations are being used) writes it to the DR register (I’m sure you know that the MCU will internally keep two registers, one for Rx and one for Tx, which will just logically be mapped to the same visible register). I’m sure you know all of that, so where exactly is your complication?

There would be a status bit somewhere: bit n clear => source 1, set => source 2.
Or perhaps the MSB of the input character tells you.
Anyway, if it’s anywhere it’s in the data sheet of your hardware!

A couple of things that might help us help you, or even to get you to help yourself:

What processor are you using?
How are these devices connected to the system?

From what you have described, you seem to have two separate devices connected to the processor, so they would be connected to two different UARTS in the system, each of which should have its OWN ISR that gets data from it, so those ISRs would know which device they are getting data from.