How do I monitor serial output on raspberry pi 3.

Status
Not open for further replies.
G

Gibbedy

Well-known member
My teensy 3.2 has this:
Code: 
void setup() {
}

void loop() {
  Serial.println("Hello");
  delay(1000);                  // wait for a second
}

On raspberry pi 3 and pi zero I have tested, with the latest raspbian install if i do:
Code: 
pi@raspberrypi:~ $ cat < /dev/ttyACM0
Hello
Hello
Hello
Hello
Hello
Hello
Hello

I only ever get 7 to 10 prints before it stops. The command doesn't drop back to shell like if I pull the usb cable out.

Also if I do the command immediately after the teensy is powered up, I can watch the 7 to 10 messages arrive. If I leave the teensy powered for 10 seconds before attempting cat I get 10 straight up in one go like they were buffered.
I've wasted so long on this. Can someone tell me what I'm doing wrong.

Attempting to read the port gives nothing until the usb cable is unplugged and re-inserted.

I can see program has not stopped if I add debugging LEDs.

Windows arduino serial monitor works ok with same cable so I'm sure its software.
I use the pi 3/zero with a nano on ttyUSB ok.

I use teensy_Loader and avrdude fine on both for uploading programs.
 
Saw a similar post go by in recent days . . . not sure if there was an answer there . . . or who posted it . . . but it seemed it had some diagnostic tips ?
 
I think I see the one you mean, but it's talking about no /dev/ttyACM0 created because of a new teensy that hasn't been programmed yet.
My issue is very similar to an old post that was talking about udev rules but I believe I have the that installed correctly.
 
On unix most convenient tool to use is GNU screen so do:
screen /dev/ttyACM0
Click to expand...
if you need to set the tty speed use:
screen /dev/ttyACM0 115200
Click to expand...
Replacing 115200 with whatever speed you need. You may need to "sudo" the last command, depending on if ordinary users can change the speed.

Anyway GNU screen knows about serial lines, and how to talk to them. So using it should show if the problem is on the RPi or in the teensy.
 
So with screen, did you get the same output as before, or nothing at all. If nothing at all - then something is not working.

First check the speed (baud) you set the UART to in the teensy, and check that the computer is set to the same speed.

If all that checks out, and still no output on screen - then something going wrong with the communication.

So are you doing the UART on teensy pins and using and external 3.3V serial connector (like the FTDI RPi connector); or are using a USB UART library that brings a virtual UART up on the USB bus? That would give some idea of where to dig next.

Hope this helps.

David.
 
Nothing at all.
I'm typing "screen /dev/ttyACM0" as I'm using the teensy usb serial.
Strangely I don't drop back to a prompt, or see any of the serial output when I do "cat </dev/ttyACMO" and ctrl+c doesn't kill it. I just kill my ssh session and log back in.
 
Ah yes - screen will stay open. Best way to exit is "ctrl-A k" which will kill that session, and then drop out of screen. Otherwise screen stays attached to the terminal.

So you aren't setting a speed for the tty, so are you sure the speed setting on both sides is the same?

Alas I don't use the teensyduino set up myself (I live in mbed right now) so how the USB serial connection is set up and tested, I don't know. Sorry.
 
I don't understand it myself.... but when using teensy, I don't have to set a serial speed in my sketch, and in the arduino serial monitor on windows it doesn't matter what speed I select serial works correctly (300-2000000).
Thanks all the same as I expect screen will be usefull when I get this working.
 
teensyduino will have a default speed it sets, often these days it is 115200. Still though there will be some way of setting the speed, and its good habit to set it (even if to the default). Others can hopefully say how you set speed.

Then do the same in screen.

Problem is that speed isn't auto detected, so if set wrong it will gives problems. So to my mind its the first thing to test ...
 
Oh yes - you should also be able to check what the computer thinks the settings are with
Code: 
stty -F /dev/ttyACM0
This is what I get where there is a USB serial gadget on the line:
Code: 
[summers@nas ~]$ sudo stty -F /dev/ttyACM0
speed 9600 baud; line = 0;
-brkint -imaxbel
 
Just to add - I've just about convinced myself that speed rate on USB serial UCD ACM links is fictional - yes my tty report a speed of 9600, but think this is just to keep the OS happy.

Anyway raw pumping of bytes down the link, and I get 5.2MB/s so way over 9600baud. Also these virtual serial links don't have standard RX and TX wires that have to be clocked.

So on reflection for USB serial in particular, I suspect that setting speed can be ignored.

Sorry for the confusion. Anyway probably still worth using "screen" - as that will set up a two way communication across the serial line, and makes debugging easier ....
 
Those udev rules are just to give normal users access to the ports. So quick way to test is add a "sudo" before the command, e.g.
Code: 
sudo screen /dev/ttyACM0
"sudo" will run as root - and so have right to access almost everything! So if you test with "sudo" and it doesn't work, then modifying udev rules will never help ...

Can't say if its only you having problems, as I'm not using teensyduino. What seems strange to me is you finding it works on windows, but not in RPi. Usually accessing thing like serial ports is easier under unix than windows, so there is something odd going on here. Maybe what PSU does the RPi have? Does it have enough power for the RPi + Teensy? that kind of direction seems more likely the problem. [I could test with my RPi, but that hasn't been powered in ages, and also has a beast of a PSU ...]
 
I’ll have access to computer in a day so I’ll try sudo screen although I’m pretty sure I have already.

I am using the same cable with windows, and that cable has the 5v chopped out so the device powers it itself. I get the same result on 2 teensys in any case.
 
Experienced Unix users often misunderstand the udev rule file. It does more than just give non-root permission to the /dev/ttyACM device files.

If you're merely using a Teensy that's already been programmed (by another computer) to work as a USB Serial device, but you're not reprogramming the Teensy or using it in any other modes, then perhaps you don't need the extra stuff the udev rules do. But beware the Gnome Modem/Network manager. The udev rules tell it to not interfere, so even with just ordinary USB Serial you might still need the udev rules if your system has Gnome installed.

If you do reprogram Teensy or use it in non-serial modes, you definitely need the udev rules. Teensy uses HID protocol for uploading. Teensy Loader actually uses the usbfs driver to access your Teensy for programming, so only paying attention to /dev/ttyACM devices will leave you without the ability to upload new programs.
 
So the fact i upload fine means my udev rules are ok? Because it looks like my serial output is being interrupted. So can someone with raspberry pi 3 or zero see if “cat</dev/ttyACMO” will continue to display serial output.
 
I loaded a sketch on the raspberry pi teensy to read Serial and send it to Serial 1.
I loaded a sketch on the windows teensy to read Serial1 and send it to Serial.
I connected the two teensi and monitored the teensy on windows arduino serial monitor.
I am getting regular data.
Does this mean anything to anyone? (after putting through an online decimal to ascii converter)

Code: 
USB [255][172]USB [255][172]USB [254]W[214]USB [255][174]USB [254]VUSB [255]VUSB [255][172]USB [255]
 
@PaulStoffregen Hi Paul - which linux distribution was having problems with Gnome Network/Modem?

I'm on arch, and like many distributions this has switched to systemd doing all network stuff; now systemd doesn't seem to interfere too much with USB devices. E.g. if it detects a cdc acm serial link it loads the cdc_acm module - which means that the serial device exists - but it doesn't start getty or any modem stuff on the tty.

Similarly I've not noticed it doing anything odd with USB idVendor=16c0; e.g. what the teensy is on - its even recognised correctly in the usb database:

http://www.linux-usb.org/usb.ids

Now as many distributions have switched to systemd, I'm surprised that any do this wrong.

@Gibbedy, does give a though; what does this produce:

Code: 
sudo lsusb -v -d 16c0:

It should say what device linux is seeing on the usb ...
 
Code: 
pi@raspberrypi:~ $ sudo lsusb -v -d 16c0:

Bus 001 Device 065: ID 16c0:0483 Van Ooijen Technische Informatica Teensyduino S                                                  erial
Device Descriptor:
  bLength                18
  bDescriptorType         1
  bcdUSB               1.01
  bDeviceClass            2 Communications
  bDeviceSubClass         0
  bDeviceProtocol         0
  bMaxPacketSize0        64
  idVendor           0x16c0 Van Ooijen Technische Informatica
  idProduct          0x0483 Teensyduino Serial
  bcdDevice            2.00
  iManufacturer           1 Teensyduino
  iProduct                2 USB Serial
  iSerial                 3 2894480
  bNumConfigurations      1
  Configuration Descriptor:
    bLength                 9
    bDescriptorType         2
    wTotalLength           67
    bNumInterfaces          2
    bConfigurationValue     1
    iConfiguration          0
    bmAttributes         0xc0
      Self Powered
    MaxPower              100mA
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        0
      bAlternateSetting       0
      bNumEndpoints           1
      bInterfaceClass         2 Communications
      bInterfaceSubClass      2 Abstract (modem)
      bInterfaceProtocol      1 AT-commands (v.25ter)
      iInterface              0
      CDC Header:
        bcdCDC               1.10
      CDC Call Management:
        bmCapabilities       0x01
          call management
        bDataInterface          1
      CDC ACM:
        bmCapabilities       0x06
          sends break
          line coding and serial state
      CDC Union:
        bMasterInterface        0
        bSlaveInterface         1
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x82  EP 2 IN
        bmAttributes            3
          Transfer Type            Interrupt
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0010  1x 16 bytes
        bInterval              64
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        1
      bAlternateSetting       0
      bNumEndpoints           2
      bInterfaceClass        10 CDC Data
      bInterfaceSubClass      0 Unused
      bInterfaceProtocol      0
      iInterface              0
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x03  EP 3 OUT
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0040  1x 64 bytes
        bInterval               0
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x84  EP 4 IN
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0040  1x 64 bytes
        bInterval               0
Device Status:     0x0000
  (Bus Powered)
 
OK - I've compared to my (non teensy) CDC ADM, I get similar information, so the RPi does seem to detect it as a CDC serial across USB, so as you got, I'd expect the module cdc_acm to be loaded, and it sets up the device /dev/ttyACMn - as you have.

So its confusing. the Rpi sees the line correctly and gives a terminal device. So that terminal device should be able to communicate with the teensy, and gnu screen should do the job.

But you have a set up that works in windows, but doesn't work on the RPi. In both cases the teensy is powered externally.

Makes no sense really you could try an:

Code: 
lsof | grep ttyACM

That would see if some other process is grabbing the tty - which it really shouldn't be ....

Yes I guess we need a view from someone else here that uses RPi with teensy ...
 
pi@raspberrypi:~ $ ls
ls lsblk lscpu lsipc lslogins lsns lsusb
lsattr lsb_release lsinitramfs lslocks lsmod lspgpot


I don't have lsof :(
 
Yes "lsof" doesn't seem to be installed by default on many OS, I don't have it right not on Arch, and obvious not you of Debian. But its probably something you could install with something like
Code: 
apt-get install lsof
Or something like that, been some time since I used Debian (I like the rolling nature of arch, so things are undated rapidly, but it means at times things break ...)

Anyway "lsof" means "ls open files" so its a way of seeing *all* files, including devices, on your operating system. So Its a very verbose command. That said its *very* useful when you want to know whats got something open, e.g. trying to unmount a partition, that seems to be active, and you want to know which program is accessing it.

Sorry we aren't getting to the bottom of your problem, its probably something silly - but without your hardware set it its hard to say ...
 
Amusing watching youtube - because it takes me to the next video Joni Mitchell - Big Yellow Taxi ... just playing in the background.

Anyway, yes how you described it, and only thing that occurs to me is not using "screen" or other low level comands like "dd if=/dev/ttyACM0 of=/dev/null" and things like that - also do you want "cat" or "tail -f" try the latter instead of cat, its another high level command, but may do want you need. Me though I'd use "screen" by default (yes know it has faults - but it does what is correct!).
 
Status
Not open for further replies.
Back
Top