[SOLVED] Capuring data with Minicom over tty interface
Linux - GeneralThis Linux forum is for general Linux questions and discussion.
If it is Linux Related and doesn't seem to fit in any other forum then this is the place.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
Hi, I'm using a raspberry pi to capture the serial output of a device under test. The pi is managed remotely via SSH.
On my pi I have a USB to serial (1 USB, 2 serial - USB0 and USB1).
I tried a simple :
sudo stty -F /dev/ttyUSB0 115200
sudo cat /dev/ttyUSB0 > my_log_file.txt
but it seems that my USB driver is messing up in the sense that it is sending carriage return all the time... that's not good.
So I moved to minicom. After configuring minicom with the correct settings it's working with the following parameter
sudo minicom USB0 -C my_log_file.txt
My problem is that when I use the following :
sudo minicom USB0 -C my_log_file.txt &
the log file is not recording anything at all (size does not increment).
I configured minicom by default save a log file, but I'm not able to find it or read it (I looked in /etc/minicom).
I need to run two instance of minicom at the same time and have them run in the background so I can use my SSH session for other purpose.
AFAIK, minicom reads from stdin. Background processes have their stdin closed and are stopped when they attempt access to stdin. This would explain your problem, but I would have expected a message telling you that the process was stopped.
You could launch minicom inside a screen, detach from the screen program and use your ssh session for interactive work.
I also stumbled on a post here at Linuxquestions where somebody was successful using just stty and cat (as you attempted to do originally).
Last edited by berndbausch; 11-11-2015 at 11:02 PM.
A while back I was having similar issues, and just broke down and wrote a little C program to open and configure the serial port and then log everything that comes in to disk. It took a little development to write it, but it's been indispensable since, and I wouldn't do it any other way. With just some tiny tweaks you can have it rotate through numbered log files as they hit a certain size, you can add timestamps to the data that's collected, etc.
This is a slightly modified (and untested) version of my most recent iteration, it should get you 99.9% of the way there (just might need some tweaks to the file writing, that's the part that's untested):
Code:
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <termios.h>
#include <fcntl.h>
#include <unistd.h>
#include <sys/ioctl.h>
#include <sys/types.h>
// Change this to match the machine's serial port
#define SERDEV "/dev/ttyUSB0"
void initComPort(int* sfd, char* device)
{
struct termios options;
*sfd = open(device, O_RDWR | O_NOCTTY | O_NDELAY);
if (*sfd == -1)
{
fprintf(stderr, "unable to open %s\n",device);
exit(1);
}
else
{
fcntl(*sfd, F_SETFL, FNDELAY);
}
tcgetattr(*sfd, &options);
cfsetispeed(&options, B115200);
cfsetospeed(&options, B115200);
cfmakeraw(&options);
options.c_cflag &= ~(PARENB | CSTOPB | CSIZE | CRTSCTS);
options.c_cflag |= (CLOCAL | CREAD | CS8);
options.c_oflag &= ~OPOST;
options.c_cc[VMIN] = 1;
options.c_cc[VTIME] = 0;
tcsetattr(*sfd, TCSANOW, &options);
}
int main(void)
{
int sfd;
FILE *ofd;
int32_t n, i;
u_int32_t bytes;
u_int8_t buff[10000];
// Initialize the serial port
initComPort(&sfd, SERDEV);
while (1)
{
// Check if there's any data available to read
ioctl(sfd, FIONREAD, &bytes);
if (bytes > 0)
{
// Read what we can
n = read(sfd, buff, 10000);
if (n < 0)
{
fprintf(stderr, "read failed\n");
}
if (n > 0)
{
ofd = fopen("data.bin", "a");
if (ofd==NULL)
{
fprintf(stderr, "unable to open output file\n");
exit(2);
}
fwrite(buff, 1, n, ofd);
fclose(ofd);
}
}
usleep(1000);
}
}
It's hardcoded to the pretty standard 115200 8N1 protocol, but you can adjust that as necessary in initComPort.
Everything is done in raw bytes, so it doesn't matter if your device is pushing out ascii or binary data.
Last edited by suicidaleggroll; 11-12-2015 at 01:31 PM.
You mean in "Filenames and paths" > option F ?
I tried using :
sudo screen minicom USB0 -C USB0.log &
A pid is created but the file isn't modified.
Am I doing this right ?
Firstly, I LOVE the example shown by suicidaleggroll.
What I mean for minicom is the following:
Enter minicom normally.
CTRL-A Z to configure minicom, you get a menu
L shows on mine as the option for Capture on/off
When I do that I get a pop-up with some default filename that I can change to be like /home/myuser/myfile.txt
Well I guess I owe people an apology, my cat finally worked with the example below (added the background task). I don't fully understand what went wrong in the first place. I understand that if I start a task in my SSH/TELNET session this task will stop as I kill my active session, but this was not even working as I was in session...
Long story short, it's working !
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.