How to start using minicom?

[rin67630]

Hi
I need a plain terminal program on /dev/ttyUSB0.
I have installed minicom and started it with
minicom /s.
The default port is a non-existing /dev/usb8
After having set the port to /dev/ttyUSB0 i wanted to save the settings to dlf, but it failed due to missing permissions.
Doing the same with sudo minicom worked, but is saves the dlf to the root user.
Now i can't start minicom normally even with minicom /s:
minicom /s
minicom: cannot open /dev/tty8: Permission denied.

That was not a nice start...

How shout it have been to work flawlessly?
Thank you for advice.

P.S. maybe you can recommend another program?:
I just want to be able to type some commands and get lists on /dev/ttyUSB0.

[scruss]

Code: Select all

minicom --setup

will always try to save your setup into /etc/minicom - which will fail as a regular user.

So if you always want that setting to stick, create the file ~/.minirc.dfl and put this line in it:

Code: Select all

pu port             /dev/ttyUSB0

Once this file exists, defaults should be saved to it rather than the root file in /etc

Alternatively, since I can't always rely on having a good default setup, I specify parameters from the command line:

Code: Select all

minicom --device /dev/ttyUSB0 --baudrate 115200

The latest desktop update installed a terminal program - gtkterm, or somesuch. Not much use if you're running headless.

[swampdog]

I use minicom on rpi that have rs232 adapters attached into PC's (where I always 'sudo -i minicom') but for the USB->tty adapter I just use 'screen'..

Code: Select all

foo@sdu /kvm $ cat /usr/local/sd/bin/rpi-tty0
#!/bin/bash

echo "^D to leave.."
sleep 1
sudo screen /dev/ttyUSB0 115200

[GlowInTheDark]

sudo screen /dev/ttyUSB0 115200

sudo???


Anyway, the best answer to the Subject: title question is: DON'T.

(As you imply) Use screen instead. But don't use sudo...

[swampdog]

Possibly, but we don't know where the USB end of that device is plugged in. Another rpi or equally likely a linux PC. Unfortunately I don't know where my USB->tty adapter is, so dunno what group that device appears as. I suspect it's a moot point though because we look at my rpi with a serial rs232..


A buster rpiZW..

Code: Select all

foo@pi13:~ $ lc -d /dev/ser*
lrwxrwxrwx 1 root root 7 Feb  5 03:37 /dev/serial0 -> ttyAMA0
lrwxrwxrwx 1 root root 5 Feb  5 03:37 /dev/serial1 -> ttyS0

foo@pi13:~ $ lc -d /dev/tty* | egrep "(AM|S0)"
crw-rw---- 1 root dialout 204, 64 Apr 17 22:27 /dev/ttyAMA0
crw-rw---- 1 root dialout   4, 64 Feb  5 03:37 /dev/ttyS0

A buster rpi4..

Code: Select all

foo@pi18:~ $ lc -d /dev/ser*
lrwxrwxrwx 1 root root 5 Apr  1 08:17 /dev/serial0 -> ttyS0
lrwxrwxrwx 1 root root 7 Apr  1 08:17 /dev/serial1 -> ttyAMA0

foo@pi18:~ $ lc -d /dev/tty* | egrep "(AM|S0)"
crw-rw---- 1 root dialout 204, 64 Apr  1 08:34 /dev/ttyAMA0
crw--w---- 1 root tty       4, 64 Apr  2 21:12 /dev/ttyS0

On a (linux mint) PC with a serial port..

Code: Select all

guy@std ~ $ grep ^GRUB_CMDLINE_LINUX_DEFAULT /etc/default/grub
GRUB_CMDLINE_LINUX_DEFAULT="console=tty0 console=ttyS0"

guy@std ~ $ ls -l /dev/tty0 /dev/ttyS0
crw--w---- 1 root tty 4,  0 Apr 17 12:15 /dev/tty0
crw--w---- 1 root tty 4, 64 Apr 17 12:16 /dev/ttyS0

So on rpiZW I can add "dialout" to "foo" but it won't work for both cases in rpi4. Similarly its "tty" in both cases on that PC but will work in neither case. This is one of those rare cases where sudo *is* the answer.

[cleverca22]

So on rpiZW I can add "dialout" to "foo" but it won't work for both cases in rpi4. Similarly its "tty" in both cases on that PC but will work in neither case. This is one of those rare cases where sudo *is* the answer.

if the serial port is in the tty group, then its got a login prompt running on it, using sudo to force things will just lead to more problems*
you need to remove the console=serial0 from /boot/cmdline.txt, then the login prompt will go away and it will instead be in the dialout group


*: with a getty running on the port, it will randomly steal bytes being sent into the pi, and spit out error messages about an invalid username

[scruss]

(As you imply) Use screen instead. But don't use sudo...

screen is very limited compared to minicom. I'll use it if it's all I have, but minicom does so much more.

All of them are frankly small-fry compared to kermit, but its usability is quite poor.

[GlowInTheDark]

minicom does so much more.

I'm not saying you're wrong, but I've never felt any limitations in screen. What does minicom do that screen doesn't do?
(Again, I'm not saying otherwise; am genuinely curious).

But the overriding point is that, as I've said many times in the past - whenever the name "minicom" is mentioned - I've never met a program that tried so hard to (and succeeded so well at) being hard to use.

Anyway, as I have also mentioned many times in the past - whenever the subject of "serial comm" programs has come up - the best (IMHO) serial program for the Linux platform is Seyon.

Edit to add: Also, in wandering around the filesystem, I also found /usr/bin/miniterm.py
No idea if it is any good or not, but as it is Python source - it might be user-extendable into something useful.

[JumpZero]

Hello,

I was a screen user for years, and continue to use it from time to time, but I now use most of the time miniterm or minicom.
miniterm is very easy and is part of python py-serial (and gives the option to change the default exit hotkey because the Ctrl-[ isn't convenient on non-us keyboard)
I feel they are all the same, once you are connected to the device, you forget them.
To connect to MicroPython devices rshell is my favorite choice.

[scruss]

What does minicom do that screen doesn't do?

File transfers, with all protocols configurable. Controlled-speed text file transfer is the big one for me. Some of the computers I use are too old or too small to support any error-correcting protocols, so sometimes you just have to pretend you're typing. Niche, I know.

screen's eating Ctrl-A as a useful character is a huge annoyance. Minicom eats a few keys too, but not ones that so readily clash with software I'm used to. If only minicom would support Mark parity better: I have a device that uses 7M1 (so 7 data bits, one parity bit, but always set it to 1) so it's Kermit for that one.

But the overriding point is that, as I've said many times in the past - whenever the name "minicom" is mentioned - I've never met a program that tried so hard to (and succeeded so well at) being hard to use.

I'd agree. I think a lot has to do with the way Debian sets it up. By having no system config files in /etc, and no user-writeable configuration files created on first startup, it's very hard to save settings at all.

If we're on the subject of special-purpose serial things, Grabserial is entirely awesome for non-interactive logging from a serial device. I see it's now added timestamping and file splitting: both handy features I'd wished it had in the past

[swampdog]

So on rpiZW I can add "dialout" to "foo" but it won't work for both cases in rpi4. Similarly its "tty" in both cases on that PC but will work in neither case. This is one of those rare cases where sudo *is* the answer.

if the serial port is in the tty group, then its got a login prompt running on it, using sudo to force things will just lead to more problems*
you need to remove the console=serial0 from /boot/cmdline.txt, then the login prompt will go away and it will instead be in the dialout group


*: with a getty running on the port, it will randomly steal bytes being sent into the pi, and spit out error messages about an invalid username

^^^I've not seen this.

Is this information not correct https://learn.adafruit.com/adafruits-ra ... -configure (Linux section)?

I seem to have..

Code: Select all

foo@pi18:~ $ cat /boot/cmdline.txt
dwc_otg.lpm_enable=0 console=serial0,115200 console=tty1 root=/dev/mapper/pi18-root rootfstype=ext4 elevator=deadline fsck.repair=yes rootwait

..which must have worked fine when I set it up. It was a long time ago so cannot recall if it was a usb->tty or rs232 which was used.

[cleverca22]

Is this information not correct https://learn.adafruit.com/adafruits-ra ... -configure (Linux section)?

I seem to have..

Code: Select all

foo@pi18:~ $ cat /boot/cmdline.txt
dwc_otg.lpm_enable=0 console=serial0,115200 console=tty1 root=/dev/mapper/pi18-root rootfstype=ext4 elevator=deadline fsck.repair=yes rootwait

..which must have worked fine when I set it up. It was a long time ago so cannot recall if it was a usb->tty or rs232 which was used.

that is how to use a usb serial adapter on another system, to access the login prompt of the rpi
the console=serial0,115200 causes linux to run a login prompt on the serial port, which will then conflict with any non-console thing your trying to do over the serial port

https://www.raspberrypi.org/documentati ... on/uart.md
that is the official docs on how to configure the rpi end of the serial link

[swampdog]

Looks like I misread the intent of the OP. oops!

[fanoush]

But the overriding point is that, as I've said many times in the past - whenever the name "minicom" is mentioned - I've never met a program that tried so hard to (and succeeded so well at) being hard to use.

There is also picocom https://linux.die.net/man/8/picocom
Somehow I like it. It is simpler and easier to use version of minicom, I can
just run e.g. 'picocom -b115200 /dev/ttyUSB0' and no messing with menu or configuration needed. ctrl-a-x to exit.

[GlowInTheDark]

I'd agree. I think a lot has to do with the way Debian sets it up. By having no system config files in /etc, and no user-writeable configuration files created on first startup, it's very hard to save settings at all.

To amplify on this further, I think it is a fundamental design flaw - a clear cut instance of "Broken by design" - if a system requires root access in order to configure personal user settings - i.e., settings that every user will need to configure, and which affect no one else on the system.

The two instances of this that I am aware of in Raspbian are:

1) minicom - which is what makes it so hard to use and why I always recommend against it.

2) The LXDE "autostart" file - which is stored in /etc (*) and needs root to edit.

Which is what makes it so hard to use and why I always recommend against it.

(*) At least for the time being. Who knows where they'll store it in the next OS release???!

[rin67630]

Code: Select all

minicom --setup

will always try to save your setup into /etc/minicom - which will fail as a regular user.

So if you always want that setting to stick, create the file ~/.minirc.dfl and put this line in it:

Code: Select all

pu port             /dev/ttyUSB0

Once this file exists, defaults should be saved to it rather than the root file in /etc

Alternatively, since I can't always rely on having a good default setup, I specify parameters from the command line:

Code: Select all

minicom --device /dev/ttyUSB0 --baudrate 115200

The latest desktop update installed a terminal program - gtkterm, or somesuch. Not much use if you're running headless.

Thank you!
It helped me.

But the devs at minicom should admit that is is not intuitive and not user friendly.

[rin67630]

The two instances of this that I am aware of in Raspbian are:

1) minicom - which is what makes it so hard to use and why I always recommend against it.

2) The LXDE "autostart" file - which is stored in /etc (*) and needs root to edit.

Which is what makes it so hard to use and why I always recommend against it.

1) Full ack!

2) At least I can understand that an autostart needs admin privileges.

[rin67630]

Which is what makes it so hard to use and why I always recommend against it.

Meanwhile i have installed GtkTerm, not a wonder-weapon but does what I need.

[scruss]

I think minicom's old enough (pre-2000, at any rate) that the old advice of "make a copy of the system config in $HOME so the user can have their own setup" rule-of-thumb has been forgotten. I just remember a Unix tutorial as a first-year student where the first command you were supposed to type was something like cat /etc/csh.cshrc > .cshrc to set up your own options. This would have been a SunOS machine, c.1988.

New user setup on Linux does this automatically by copying files from /etc/skel/ . minicom could do something similar. It seems that no-one has raised a bug about this in all the years that this has been a Debian package. Minicom's got outstanding wishlist bug reports going back to 1998, so I wouldn't expect this to be fixed quickly.

GtkTerm seems to be supplied as part of the latest system update