This seems like a beginner question, I thought I'd passed that stage but apparently not!
I have a Teensy 3.2 which prints one line of text (data from ADC) every half-second or so, using Serial.println() so this goes out using its USB and not a true serial port.
The exact code is this https://github.com/jbeale1/DataAcq/blob/master/FMES-ADS1115.ino and it works 100% OK when connected to my Linux Mint "fitlet2" MiniPC. I can run the receiving program, stop it for any length of time and restart and there is no problem.
Now I unplug my Teensy's USB cable from the miniPC, and plug it into a Raspberry Pi. I have already installed the 49-teensy.rules file in /etc/udev/ and 'dmesg' shows ttyACM0 is there:
and the Teensy shows up with 'lsusb'
I am running the same Python3 program on the miniPC and the Raspberry Pi to log the serial data from Teensy to a file,
this is the code: https://github.com/jbeale1/DataAcq/blob/master/serial_log.py
It always works on the MiniPC, but it does NOT always work on the Pi. In particular it will work after a physical unplug-usb-replug cycle. It will still work if I stop the receiving Python program on the Pi for a short time (few seconds) and restart it quickly. If I stop for several minutes, and then restart the program on the Pi (while the Teensy has been continuing to run), then the Python program sees nothing from the serial port and always just times out on read. There is no error, the /dev/ttyACM0 port is present and can be opened, but no data is coming from the Teensy, However I can see from my use of pin 13 LED that the Teensy continues to cycle through its code just as before. Unplug/Replug the USB and restart the Python and it works again.
I guess this has to do with how USB buffering is handled (after some buffer size is filled, it looks like somebody just "gives up") but I'm not sure where exactly the problem lies or how to work around it. Is it because stopping Python with Control-C doesn't close the port, that it gets lost? Is the difference that Linux Mint auto-fixes that for me on the fitlet MiniPC, unlike the Raspberry Pi? Does this ring any bells with anyone? Thanks for any advice!
I have a Teensy 3.2 which prints one line of text (data from ADC) every half-second or so, using Serial.println() so this goes out using its USB and not a true serial port.
The exact code is this https://github.com/jbeale1/DataAcq/blob/master/FMES-ADS1115.ino and it works 100% OK when connected to my Linux Mint "fitlet2" MiniPC. I can run the receiving program, stop it for any length of time and restart and there is no problem.
Now I unplug my Teensy's USB cable from the miniPC, and plug it into a Raspberry Pi. I have already installed the 49-teensy.rules file in /etc/udev/ and 'dmesg' shows ttyACM0 is there:
Code:
[ 914.149878] usb 1-1.5: new full-speed USB device number 8 using dwc_otg
[ 914.282643] usb 1-1.5: New USB device found, idVendor=16c0, idProduct=0483
[ 914.282659] usb 1-1.5: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 914.282668] usb 1-1.5: Product: USB Serial
[ 914.282676] usb 1-1.5: Manufacturer: Teensyduino
[ 914.282684] usb 1-1.5: SerialNumber: 1231730
[ 914.283801] cdc_acm 1-1.5:1.0: ttyACM0: USB ACM device
Code:
pi@rp48:~/FMES $ lsusb
Bus 001 Device 008: ID 16c0:0483 Van Ooijen Technische Informatica Teensyduino Serial
Bus 001 Device 005: ID 413c:2005 Dell Computer Corp. RT7D50 Keyboard
Bus 001 Device 004: ID 04f2:0939 Chicony Electronics Co., Ltd
Bus 001 Device 003: ID 0424:ec00 Standard Microsystems Corp. SMSC9512/9514 Fast Ethernet Adapter
Bus 001 Device 002: ID 0424:9514 Standard Microsystems Corp. SMC9514 Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
I am running the same Python3 program on the miniPC and the Raspberry Pi to log the serial data from Teensy to a file,
this is the code: https://github.com/jbeale1/DataAcq/blob/master/serial_log.py
It always works on the MiniPC, but it does NOT always work on the Pi. In particular it will work after a physical unplug-usb-replug cycle. It will still work if I stop the receiving Python program on the Pi for a short time (few seconds) and restart it quickly. If I stop for several minutes, and then restart the program on the Pi (while the Teensy has been continuing to run), then the Python program sees nothing from the serial port and always just times out on read. There is no error, the /dev/ttyACM0 port is present and can be opened, but no data is coming from the Teensy, However I can see from my use of pin 13 LED that the Teensy continues to cycle through its code just as before. Unplug/Replug the USB and restart the Python and it works again.
I guess this has to do with how USB buffering is handled (after some buffer size is filled, it looks like somebody just "gives up") but I'm not sure where exactly the problem lies or how to work around it. Is it because stopping Python with Control-C doesn't close the port, that it gets lost? Is the difference that Linux Mint auto-fixes that for me on the fitlet MiniPC, unlike the Raspberry Pi? Does this ring any bells with anyone? Thanks for any advice!