If we look at the screen man page, we will find the escape sequence CTRL-a a. Yes, it is USB but you know exactly what I am talking about) would not be freed even if I remove the serial-to-USB cable.
Quit minicom serial#
As a result, that serial port ( /dev/ttyUSB0 in my case. Another option would be to close that screen session, which would quit minicom. Some of you will argue that I could remap the escape sequences for each program so they will not match, but hindsight is 20/20: it does not do me any good once they are already running inside each other. So, if I want to send a CTRL-A X (exit) to minicom, screen will think I am talking to it and then lock the screen. But, problem is that screen and minicom by default use the same CTRL-A sequence to enter commands. At first that does not seem to be a bad idea after all, it would be nice to connect to the console of, say, a Brocade fabric switch, start something there, log out, and then come back to it later. I really should not do that because you can connect to a serial port from screen by doing something like :screen /dev/ttyUSB0 115200(some devices I use have their default port speed set to 9600, others like the one in this example to 115200)īut, force of habit (read: lazyness) or distraction (did you see that ant crawling up the wall?) caused me to start minicom right in screen. The problem begins when I try to use them together. I also like screen, which allows me to run multiple sessions on different machines and stop and resume them as needed kinda like running vnc/rdp but in command-line. And I have used it long enough to remember some of the commands. You see, I like to use minicom as a terminal program since it plays nice with my usb-to-serial cables and my serial devices (Sun and AIX workstations, Seagate Dockstar, Pogoplug, routers, switches). Here we should disable the Hardware Flow Control.So, I did it again. One of the reason would be the wrong setting of the serial tool, such as the Hardware Flow Control, etc. Once finish the setting, press Open button to start.įAQs 1.While using debug console, there is system startup information on the screen, but the keyboard cannot be used to input text? Write rockpiE in the Saved Sessions column and press Save.įor category Connection-Serial, do the setting: And do the setting as follows:įor category Session, set serial line as COM3, speed ad 1500000, connection type as Serial.
Quit minicom windows#
Launch the application Putty on your windows PC. Viewing the device manager you can find the COM number. Plug in the USB to TTL cable to you windows PC. Putty is also great serial tool that supports wide range baud rate. Now run minicom rockpiE to use the config above and connects to the ROCK Pi E serial console. usb 1-6.4.3: FTDI USB Serial Device converter now attached to ttyUSB0įirst add current user to plugdev group to use minicom without sudo or root.Įdit your ~/.bashrc and add the following line with some default parameterĪlias minicom='minicom -w -t xterm -l -R UTF-8'Ĭreate and edit file ~/.minirc.rockpiE, add the following content: ftdi_sio 1-6.4.3:1.0: FTDI USB Serial Device converter detected
usb 1-6.4.3: New USB device strings: Mfr=1, Product=2, SerialNumber=0 usb 1-6.4.3: New USB device found, idVendor=0403, idProduct=6001 usb 1-6.4.3: new full-speed USB device number 103 using xhci_hcd Plug in the USB to TTL cable, kernel `dmesg | tail` should show the following device: Minicom is the serial tool that supports wide range baud rate. The default serial setting for ROCK Pi E u-boot and kernel console is:
Quit minicom how to#
If you know how to set custom baudrate on macOS, please add an item here to show your findings.Ĭonnect the USB to TTL serial cable as below.
Quit minicom driver#
It seems that the serial tool on macOS platform can not support custom baudrate such as 1.5Mbps due to driver restriction.The instructions below use a FT232RL based cable. We also tested that some cheap PL2303x based cable does not work well.
Some model of CP210X and PL2303x have baudrate limitation, please check the specified model.
0 kommentar(er)
