6

I am trying to communicate between a single board computer and a PC over COM ports. On the single board computer I am running Debian Linux and there are two UARTs that I can use. On one of the UARTs (ttyS1) I can communicate (send and receive) with no problems. When I try to communicate on the other UART (ttyS0) the send works perfectly however the receive loses the 1st byte in (sends an error message to the console on the PC saying that the character that is typed is not a command) and then all future characters are received correctly.

If I switch from receiving to sending and then back to receiving the same occurs. If I stay in receive mode I can receive characters for as long as I want with no data loss. It appears that the transitioning from send to receive is causing this to happen.

As I mentioned earlier I do not see this issue on the other UART (ttyS1). I started looking for reasons why the two ports are different. I used the same program to set up send and receive for both UARTS so the problem is not in the program setup. One thing that I did find when I typed the command dmesg |grep tty I get the following:

[    0.000000] Kernel command line: console=ttyS0,115200 root=/dev/mmcblk0p2 roo twait loglevel=8 panic=10
[    0.446780] sunxi-uart.1: ttyS0 at MMIO 0x1c28400 (irq = 2) is a U6_16550A
[    1.114996] console [ttyS0] enabled
[    1.154643] sunxi-uart.3: ttyS1 at MMIO 0x1c28c00 (irq = 4) is a U6_16550A

I see that ttyS0 has the "console [ttyS0] enabled" associated with it where the ttyS1 does not. I was wondering what the "console [ttyS0] enabled means?

Also, is there a way to disable it to see if this is what is causing my 'first byte of data loss'? I see in my setup for the single board computer that ttyS0 is designated the "debug port'.

I was also wondering if that is analogous to console?

Can someone please explain what having the console enabled implies?

mikenycz
  • 81
  • 1
  • 1
  • 5
  • I assume the first UART, you meant that ttyS0 works fine in send and receive? – Sunny Patel May 09 '14 at 21:24
  • 1
    Actually, ttyS1 works fine, ttyS0 loses the first byte. – mikenycz May 09 '14 at 23:44
  • Appreciate the correction. – Sunny Patel May 09 '14 at 23:45
  • 1
    *"the send works perfectly however the receive loses the 1st byte"* -- This is ambiguous. When the problem occurs, which side is transmitting and which side is receiving? *"It appears that the transitioning from send to receive is causing this to happen."* -- There is no Tx or Rx "mode" (aka half duplex). The 16550A USART should be setup for full duplex, and capable of simultaneous transmitting and receiving at all times. The "console enabled" message is not the cause of the problem. I have used the "debug" ports as the console w/o any issues. What terminal emulator are you using? – sawdust May 10 '14 at 11:39
  • 1
    *"however the receive loses the 1st byte"* -- That seems to be a conclusion on your part. Please provide the raw data or evidence to support this (screen capture or program code?)/ – sawdust May 10 '14 at 11:40

2 Answers2

5

The console is the tty where the kernel logs go to.

You select a specific one through kernel parameters when booting, it is seen in the log you provided, in the line "Kernel command line: console=ttyS0,115200 root=/dev/mmcblk0p2 roo twait loglevel=8 panic=10"

You can select another console (if available in your platform) so ttyS0 will not get any bytes on kernel boot.

David Aparicio
  • 53
  • 1
  • 4
0

I see that ttyS0 has the "console [ttyS0] enabled" associated with it where the ttyS1 does not. I was wondering what the "console [ttyS0] enabled means?

I think this is because of unix history. Originally, as this is well explained in that mail, there was two kind of serial port: the /dev/tty* and the /dev/cu*. Long story short, the tty ones are for incoming connections over the serial port, and the cu ones are for outgoing connections over the serial ports. And at the other end, there was unix consoles, the serial terminals.

As your single board computer is communicating using a console over a serial port and has no "real" console (I mean display and keyboard) to bind the console to as a pseudo tty (the /dev/tty), chances are that your /dev/ttyS0 is indeed used by the kernel as a console for input and output, waiting patiently for a terminal to connect and assert the DTR line. But there you start sending data and not respecting that 40 year old protocol.

To solve your situation, chances are that you need to change the kernel boot line in the bootloader so that you change console=/dev/ttyS0. You may also want to look at /dev/inittab and check around the getty lines.

zmo
  • 24,463
  • 4
  • 54
  • 90
  • *"has no "real" console (I mean display and keyboard)"* -- Unix did use a TTY as the console. Mechanical Teletypes were replaced by VDTs. The video display and keyboard is a home computer and PC concept. A "debug" port on the numerous SBCs that I have worked on were always a 3-wire serial port, and had no DTR line. – sawdust May 10 '14 at 11:04
  • That's exactly what I'm saying, @sawdust. I don't get why you're trying to argue against me saying the same thing I am. And in the last paragraph I'm considering both problems: it's either the kernel taking /dev/ttyS0 as a console or a getty using it as is. If it's a getty, then chances are it's expecting a tty-like behavior in the port configuration. – zmo May 10 '14 at 11:10
  • You assert that there is no "real" console. Not true. The TTY is the console. You misunderstand; I'm not agreeing with you. There is no requirement for a "display and keyboard" or a DTR signal. Linux can run perfectly normal with a 3-wire serial port as the console. There are thousands of SoCs running embedded Linux to prove that. The OP so far has offered no evidence that the SBC is misconfigured. Those messages all look normal. – sawdust May 10 '14 at 11:20
  • 1
    The word "console" originally comes from the piece of furniture where you could sit at to input data, and access the output of a computer. When I talk about *"real"* console – please note the quotes, I'm only talking about keyboard+mouse bound to the system (however it's done), and I'm saying that *by design*, a SBC has no such thing. – zmo May 10 '14 at 14:00
  • 1
    Linux *can* run perfectly well with a 3 wire serial port, but that does not mean it does. If there's a `getty` bound to the serial port, then there's potential for trouble. If the kernel has `ttyS0` bound as kernel's console (i.e. where the kernel sends logs to) and that has the debug keys configured, there's potential for other troubles. Though, the `ttyS` lines are special tty bound to physical devices, in opposition of the original `tty` lines that have been bound to virtual devices to give terminal emulation. And to end this, the OP has offered no evidence the SBC is correctly configured. – zmo May 10 '14 at 14:04