Communication UART with Linux

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
Anonymous
Not applicable

Hello,

   

I try to communicate between my PRoC-BLE and a Linux using UART.
Linux can write on a tx port, it can read on a rx port. No problem. After numerous tests, I am sure Linux can read a message that it sent to itself (rx connected to tx).

   

The same thing for the PRoC-BLE. rx can read what tx sent.

   

Then, the PRoC-BLE can read what Linux sent (Linux tx connected on BLE rx, and gnd connected to gnd of course). On Linux, I send my message using "cat > /dev/ttyS1".

   


But, and this is my problem, Linux can not read what the PRoC-BLE send...
I do a "cat < /dev/ttyS1" on Linux, and he does not see any message from the BLE.
However, the messages, seen on the oscilloscope, seem to be the same.
I do not understand. What is the difference between the message that Linux send to himself (and that BLE can read) and the message that the BLE send to Linux ? Is there a configuration that I didn't see ?
Has anyone already encountered this problem ?
Thanks, regards.
Yann

0 Likes
3 Replies
HeLi_263931
Level 8
Level 8
100 solutions authored 50 solutions authored 25 solutions authored

Use a proper terminal program (e.g. picocom, minicom). Or use screen: 'screen /dev/ttyS1 115200'. This allows to use one command for RX and TX.

0 Likes
Anonymous
Not applicable

Thank you for your response. "Screen" works much better than "cat".
What's more, I didn't know Linux was waiting for 32 bytes before printing them. Many of my tests were shorter... And when I tried to send a byte as 0x05, of course Linux did not print them because it did not have a character to put on... It works better with "0x66" which is printed as a "f".
Thanks, regards.

0 Likes
HeLi_263931
Level 8
Level 8
100 solutions authored 50 solutions authored 25 solutions authored

I've never seen Linux waiting for 32 bytes on the serial line before it prints anything. If this is what you are seeing the problem might be somewhere else.

0 Likes