I have a problem with my pl2303 converter. I'm using two of them like this:
LAPTOP <-USB-SERIAL-> <-SERIAL-SERIAL-> <-SERIAL-USB-> RASPBERRYPI
In other words, I'm connecting Raspberry Pi with my laptop using two usb-to-serial converters and having null modem in the middle.
I can communicate through minicom and "visually" it looks fine (all information is sent properly), but when I look into the logs it produces following dmesg output:
[ 343.390610] pl2303 ttyUSB1: pl2303_get_line_request - failed: -32
[ 343.685367] pl2303 ttyUSB1: error sending break = -32
I could live with that as long as everything works fine... but it doesn't. For example, I can't connect with RPi via ser2net. The "other side" simply doesn't get the messages. I suspect that this error is the cause of this problem. I was googling around, but I didn't find any solution. Could somebody help me with it?
Also - when I try to connect via ser2net, one thing breaks. Before that I can to stuff like
cat -v < /dev/ttyUSB0
and
echo "blablabla" > /dev/ttyUSB0
with success. After I try to connect via ser2net, it stops working and only minicom communication is fine.
Related
I have a Pololu PGM03A isp dongle to programm microcontrollers via avrdude. It worked great under Yosemite, but under El Capitan, it seems to disconnect and reconnect randomly every 1 - 5 sec. I can see this by the green status LED and in the terminal:
Macintosh:~ xxxxx$ ls /dev/cu.*
/dev/cu.Bluetooth-Incoming-Port /dev/cu.usbmodem00070153
/dev/cu.serial1 /dev/cu.usbmodem2169
/dev/cu.usbmodem00070151
Macintosh:~ xxxxx$ ls /dev/cu.*
/dev/cu.Bluetooth-Incoming-Port /dev/cu.usbmodem00070153
/dev/cu.serial1
Macintosh:~ xxxxx$ ls /dev/cu.*
/dev/cu.Bluetooth-Incoming-Port /dev/cu.usbmodem00070153
/dev/cu.serial1 /dev/cu.usbmodem2177
/dev/cu.usbmodem00070151
As you can see, the usbmodem00070151 is there, then not, and then again available. The usbmodem00070153 belongs to the ISP Dongle too, but it provides an different feature than programming the microcontroller (it's an USART Port or something I think).
Edit: The latter modem now also disconnects.
When I try to flash the microcontroller, it sometimes manages it to write some bytes, but the time between 2 disconnects is to short to finish the job:
Writing | ######################## | 47% 0.08s
avrdude: ser_recv(): read error: Device not configured
make: *** [all] Error 1
Does anyone know how to fix this?
(Wow it took me a while to post this question because of the formatting problem coming from special characters..)
I'm trying to bring up virtual terminal on our embedded system's LCD usnig USB keyboard which is also connected to the system. I have UART connection to my PC so I've been using UART for console till now but I want to switch to framebuffer console on LCD during the boot at some point..
The USB host controller seems to work fine because I've seen USB memory is attached, read and written ok. And when I connect a keyboard and print the events at keyboard_event function, it prints events that seem normal and corresponding to my action(type of key, press or release..)
I have a feeling that it's a configuration problem. In init/main.c, there is
run_init_process(ramdisk_execute_command);
(In my case, ramdisk_execute_command = "/sbin/init")
And this immediately calls
kernel_execve(init_filename, argv_init, envp_init);
// above, init_filename and argv_init are "/sbin/init" same.
I expect busybox to run after this.. (ramdisk had been installed before by a bootloader-like part) but I cannot see any prints on the LCD after this point. But I can see printks on the LCD until just before calling kernel_execve above. I'm using linux 3.3.
I understand I have to open a frame buffer console on LCD and connect it to a tty but I don't know how. Below are printed the current releavant settings.
(In serial UART connection case, linux boots ok up to the final busybox shell prompt printing things in busybox initialization after kernel_execve call. and #cat /proc/fb0 returns 0 for your info. Only LCD/framebuffer console mode stops after kernel_execve.)
#### arch/sparc/boot/ourprocessor/prom_stage.c : #####
// "console=ttyS,mmio,0xff003000,115200n8 " <== serial port case
"console=tty " <= frame buffer console case (below line too)
"fbcon=font:SUN8x16,map:0000 " <= Is this boot argment correct?..
#### sbin/init: #####
#!/bin/busybox sh
export LD_LIBRARY_PATH=/lib
export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/mnt/nand/lib
exec /bin/busybox init
### rcS #####
mknod /dev/tty0 c 4 0 <== Do I need to explicitly make tty0 and tty1 like this?
mknod /dev/tty1 c 4 1
mknod /dev/tty2 c 4 2
mknod /dev/tty3 c 4 3
mknod /dev/tty4 c 4 4
### .config #####
CONFIG_FRAMEBUFFER_CONSOLE=y <= LCD/framebuffer console case. Otherwise none.
CONFIG_FONT_SUN8x16=y
CONFIG_LOGO=y
By the way, I'm not using /etc/inittab.(so use default init). The busybox init/init.c code says if there isn't the inittab file and console is not the serial port, it runs
tty2::askfirst:/bin/sh
tty3::askfirst:/bin/sh
tty4::askfirst:/bin/sh
(starting shell on tty 2, 3 and 4) then How do make tty2's shell appear on the LCD/framebuffer/framebuffer console? It's confusing and books are not so kind..
Any hint would be deeply appreciated.
This question was solved months ago and I forgot to answer to this question myself.
Adding CONFIG_FRAMEBUFFEr and CONFIG_FBCONSOLE and setting console=ttyS,.. was all that is necessary. In my case, I had another bug in DMA that was causing the frambe buffer console's text not appear on the LCD. So I can use 3 virtual consoles on the LCD (switch using Alt-F2, Alt-F3, .. ) by default. Long storyg short, console is a console(on serial port), and we have 3 (by default busybox setting) virtual console on the LCD.
Is it possible to pipe serial console output to a file or a buffer or some virtual or pseudo device (in /dev)?
The Kernel command line has in startup at this point "console=null,115200".
(Normally it has "console=ttyS0,115200" - my requirement is: if "console=null,115200", should the output go to some other place than ttyS0, e.g. a virtual or pseudo device or to a file/buffer)
Maybe somebody know if there is good solution available?
Thanks a lot in advance!
There are two ways that I am aware of :-
First way :-
get ttylog from sourceforge :-
http://sourceforge.net/projects/ttylog/files/latest/download
Fire the below command:-
nohup ttylog -b 115200 -d /dev/ttyS0 > log.txt
this will then show you the PID of the process that is running, you now need to disown that PID so it doesn't get killed when you log out. Note that 115200 is the serial port speed/baud rate you configured grub for on the box you are monitoring.
Second way :-
Setup a serial console from system under test to some other linux/windows box. In case of linux install minicom and set minicom to listen on the serial port define in grub of system under test. Save that as dfl. You are good to go for more info :-
https://www.kernel.org/doc/Documentation/serial-console.txt
I need to know how to connect to a beaglebone (or beagleboard) with SSH when I plug it into a new network with an ethernet cable like this:
$ ssh root#beaglebone.local
So far I've only been able to access it like this, if I know the IP address:
$ ssh root#<ip_address>
But I don't always know the IP address of the board on new networks so I'm hoping to access it with with a name like: beaglebone.local.
Right now when I try to do this I get this error:
"ssh: Could not resolve hostname beaglebone.local: nodename nor servname provided, or not known"
I checked the hostname and hosts files, and added "127.0.0.1 beaglebone" to the hosts on the beaglebone, but not sure what else I can do?
# cat /etc/hostname
beaglebone
# cat /etc/hosts
127.0.0.1 localhost.localdomain localhost
127.0.0.1 beaglebone
I had a similar issue running my beaglebone on Angstrom-Cloud9-IDE-GNOME-eglibc-ipk-v2012.05-beaglebone-2012.04.22.img.xz. In this distribution, "beaglebone.local" should appear on the network after the system boots.
About 50% of the time after reboot, "beaglebone.local" would not appear on the network (although the bone would be available by IP address). When this happened, "systemctl status avahi-daemon.service" showed that the avahi-daemon failed with "exit code 255". Interestingly, a subsequent "systemctl start avaihi-daemon.service" would always be successful and "beaglebone.local" would appear on the network.
Also "journalctl | grep avahi" returned a single message stating something like "Daemon already runnin gon PID NNN".
So, I "fixed" the problem by adding the line "ExecStartPre=/bin/rm -f /var/run/avahi-daemon/pid" to the [Service] section of /lib/systemd/system/avahi-daemon.service. With this addition, "beaglebone.local" now appears on the network 100% of reboots.
I say "fixed" (i.e., in quotes) because I have not been able to track down the root cause that is leaving around the stray avahi pid file(s) and thus don't have a true fix.
-- Frank
For 'beaglebone.local' to work, your host machine must recognize Zeroconf. The BeagleBone uses Avahi to tell other systems on the LAN that it is there and serving up applications and that it should be called a 'beaglebone'. If there are more than one, the second one is generally called 'beaglebone-2.local'.
I hate answering my own questions. The following hack will work until a better way emerges:
This shell script (where xxx.xxx.xxx is the first three numbers in your computer's IP) will find your beaglebone or beagleboard (that is plugged-into ethernet on a new network with DHCP) by looping through all the ip address on the subnet and attempting to login to each as root. If it finds one then try your password. If it doesn't work just hit enter until the loop starts again. If it doesn't find the board then something else is probably wrong.
for ip in $(seq 1 254); do ssh root#xxx.xxx.xxx.$ip -o ConnectTimeout=5; [ $? -eq 0 ] && echo "xxx.xxx.xxx.$ip UP" || : ; done
UPDATE 1
Today I plugged-in the beaglebone and saw Bonjour recognize that it joined the network. So I tried it and it worked. No idea why it decided to all of the sudden but it did. Strange, but true.
I had this issue quite often with Mac OS X 10.7. But unlike Frank Halasz "systemctl status avahi-daemon.service" shown no failure. And in fact the problem was on the Mac side. Restarting Bonjour with the following commands fixed the issue.
$ sudo launchctl unload /System/Library/LaunchDaemons/com.apple.mDNSResponder.plist
$ sudo launchctl load -F /System/Library/LaunchDaemons/com.apple.mDNSResponder.plist
I've got a Tcl/Expect program that reads and writes data to the serial port.
I did all of my development and testing on a Fedora 7 machine, but I'm now trying to run the same code in Ubuntu 8.10, and I'm getting the following error:
spawn: returns {0}
bad option "-mode": should be one of -blocking, -buffering, -buffersize, -encoding, -eofchar, or -translation
while executing
"fconfigure $port -mode 19200,n,8,1"
(file "./scan1.tcl" line 31)
I have no issues in Fedora, just Ubuntu. It would seem that it doesn't like the serial options being given to fconfigure, but I don't know of an alternate way of doing this.
Both machines have Tcl 8.4.
Here's the relevant code snippet:
#Open serial port
set portname "/dev/ttyS0"
spawn -open [set port [open $portname "r+"]];#This is a beast!
fconfigure $port -mode 19200,n,8,1
Does anyone know what's wrong? Thanks for your help!
Some research seems to indicate that the [fconfigure] command doesn't offer the -mode switch when it doesn't recognize the channel in question as being a true serial port (though I don't see this mentioned in the docs). Ultimately, that decision seems to rely on an "isatty()" system call, which is apparently failing to report the channel as a TTY. More info can be found here:
http://groups.google.com/group/comp.lang.tcl/browse_thread/thread/ea0e772c59fa1e52/949c04fe4cebc2a3?q=fconfigure+mode+group:comp.lang.tcl#949c04fe4cebc2a3
According to the above thread, this could be due to a misconfigured Tcl.
Update... I see the serial configuration options (including -mode) are documented with the [open] command. There, it mentions that [fconfigure] can be used to query or set the additional options specific to serial ports. The [fconfigure] docs should probably be updated to reflect that fact also.
Bottom line, Tcl doesn't think your port really is a serial port under Ubuntu, though I don't know why...
Could be a bug. It has been in the past.
http://sourceforge.net/tracker/?func=detail&atid=110894&aid=218617&group_id=10894