I’m creating an application in which I need full duplex serial communcation. I’ve created two threads, one threads reads the comport (read function from bsp), and the other tries to write.
The write functions however won’t complete, till the read function has received some data. My guess is that those functions are mutual exclusive.
Is there a better way to do full duplex communication? Or what should I change to get it? Is it even possible without rewriting the whole BSP?
Finally my communication options: 9600 baud (this can change later), no parity, 1 stop bit. Creation options: O_RDWR, Config options: CS8 | CREAD
Keep in mind that you can only read or write to the serial interface at any given time. If you call a read and it’s blocking, it will not let you write to the serial interface until a read is performed. Try using nonblocking when you open the serial port (i.e. O_NONBLOCK). You can also use select so you only read from the serial port when something has been received.
Hmmm, If you can’t read and write at the same time, full duplex communication is impossible.
I’ll look into the select option.
I really don’t hear people referring to serial connections as ‘full’ or ‘half’ duplex unless they’re referring to RS485/422.
The NS7520 chip utilizes a UART that can communicate asynchronously or synchronously. While in asynchronous mode, this implies that the UART can both read and write at the same time. In effect, while you write to the serial port (using the serial driver, which stores the data in it’s own internal buffer and then passes it off to the FIFO), the UART can and does also receive data (which the serial driver collects and stores in an internal buffer).
The fact the serial driver only allows a single read or write at a time, does not by any means indicate ‘half duplex’ communication.
It would be impossible to communicate in full duplex anyway as you re running in an RTOS which will only perform one operation at once.
The driver will accept data to send and will present data received for any task that is scanning the appropriate I/F functions.
The simplest method as pointed out before is to use non-blocking and decide which has priority… send or receive. I tend to have send as the higher priority as the receive is buffered and can be scanned when the send has delivered the data.
It is important to remember that you have an abstraction from the hardware that you cannot control the flow of data in and out (unless you were to dive down into disabling and enabling interrupts).