I try to create two qemu instances and let them communicate via usart. the background is, that I want to emulate the communication while the boards aren't even finished but the code is already testable.
So the creating of two parallel qemu instances is no problem, but the communication between these two doesn't happen.
The way I thought it maybe could work is to extend the command line of the master device with -serial pty to bind the USART1 of the STM32 to an pty socket and after that binding the USART1 of the slave to the same pty. But obviously it doesn't work.
The code I use is already tested with two Olimex development boards so there have to be problems in the qemu setup.
Does anyone have tried something like this or can provide a different way to establish an emulated connection?
Use semihosting with unix pipes. I have implemented this approach and it works well. Only drawback is that there is no way in the semihosting spec to configure a file descriptor to be async, so it will always block when you do a read.
Related
I'm debugging an embedded application that runs in a Linux environment on a remote target. The only usable interface to the board is a single serial interface. Right now that's hooked up /bin/sh on init. I'm connecting with minicom, (re-)loading my application with lrzsz, and using printfs to get the job done.
I'd like to use gdbserver for more fine-grained debugging, but connectivity seems like a problem. Normally I'd connect over ethernet, but that's not available on this hardware. I understand gdbserver can run on a serial line, but right now my one comm port belongs to the shell.
Is there a good way to work around this restriction? Ideally I'd like to be able to run gdbserver and get back to a shell when I'm finished. I've tried starting gdbserver from the shell using the one available serial interface (/dev/ttyS0), then quitting minicom and starting GDB on my host, but it's messy & doesn't appear to work (even after setting remotebaud appropriately). Should that work? What's the sane thing to do in this situation?
How about the old-school solution? Use PPP to run IP networking over your serial line. You can then ssh (or even telnet) to your board, and connect to gdb at the same time. Given your circumstance, I'd recommend starting pppd manually to reduce the risk of locking yourself out through misconfiguration. The LDP link dates from 2000, but contains a lot of debugging advice.
I'm working on an IO expansion device.
Among other things, it exposes a bunch of serial ports, which I want to expose on my Linux host as /dev/ttySomethingN
I could write a TTY kernel module for that, but I'd like to keep it on userspace for now.
The solution I've found is to use a PTY as a proxy: The master side talks to my device and the slave talks to my applications, and I use TIOCPKT_IOCTL to know when the device needs to reconfigure its speed/bits/parity/stop bits.
It works pretty well! See my source
But there is one little issue: I cannot set the number of bits (CS5/CS6/CS7) or parity (PARENB) in a PTY:
Any ideas why this restriction is in place? And how to work around it?
I have an Ada program that communicates with an Intellibox Basic(a box that allows you to control trains) that is connected via USB.
Under Windows, I had to install a specific Serial driver (CP210x USB to UART Bridge VCP). With that driver I can communicate perfectly with the box. That means sending commands to the box.
Under Linux I'm communicating via /dev/ttyusb0 and I'm able to get messages from the box, but I can't send commands to the box. Nothing happens. I don't get an error or something.
Is the behavior of GNAT.SerialCommunication differently on Linux ? The program is the same. Do I have to setup certain things to get it to work on Linux ?
For example: A typical 2-byte command has the Command as the first Byte and the CRC check as the second one.
I had trouble with Serial_Communication at some point, where it turned out to be a problem with hardware-handshake being enabled in Linux. It's hard-coded in g-sercom.adb, look for "CRTSCTS". If your Intellibox does not use hardware handshake, Write() will block.
I believe I solved it by removing the CRTSCTS mask from the flags.
I'm writing a daemon that interfaces with a USB device (an Arduino). This daemon is continuously aware of the current state.
Now I want to be able to interface with this daemon through a client program, also to be written in Perl. This client must be able to query the daemon for its current state and it must be able to update the daemon with settings.
I'm on Linux (x86_64)
I don't want to use an intermediate file and preferably simultaneous queries are easily implemented.
What is the name of such a mechanism? What Perl libraries can I use or should I avoid? What should I DuckDuckGo for?
Probably, you need to implement an event loop to allow doing the tasks of your USB device communication and serve information to the new interface. This concept will change the way you solved the problem, but I think is the better approach.
You can search at CPAN for modules like POE and AnyEvent
The idea is to build an event loop that handles a TCP socket in order to send & receive information from te interface
Sorry for the rather long post.
I need some input regarding a project that I am going to undertake.
I am trying to make an application that collects kernel debugging information from a guest Linux OS, located inside a VmWare Virtual Machine, and send them to a host OS efficiently.
So far, I have found a similar project, but written for Windows[1].
The author of the project wrote a DLL that is loaded into memory, and replaces the implementation of the KdSendPacket and KdReceivePacket functions, to use the VmWare GuestRpc[2] mechanism, instead of the slow serial port.
The data are then send to a debugging application on the host(Kd or WinDbg) trough a named pipe.
The author claims that there is a speed-up up to 45%, by avoiding the serial port transmission.
I am trying to achieve something similar ,but for Linux, and try to make the debugging process a little faster, than using the serial port.
My concrete questions are :
Do any similar applications exist?
I didn't manage to find any.
Would such an application be worth it ,comparing its functionality to netconsole[3], for example?
What method of intercepting printk messages would you suggest ?
Is there an equivalent of KdSendPacket/KdReceivePacket on Linux ?
[1]. http://virtualkd.sysprogs.org/dox/operation.html
[2]. http://articles.sysprogs.org/kdvmware/guestrpc.shtml
[3]. http://www.kernel.org/doc/Documentation/networking/netconsole.txt
Using the serial port is really suboptimal.. even the (virtual) network would be preferable to that, but getting back to host-guest IPC channels, VMware's VMCI comes to mind.
many approaches can use to achieve your goal, below methods can be applied if network is connected:
use syslog service and transfer log though network to your server:
syslogd, syslogng seems support sending log to a log server with some filter critiera.
directly call tcp/udp socket functions in your kernel module to sends your collected data back to server.
other approaches, you may write application on host machine that calls hypervisor's share memory access function to read the memory buffer of your kernel module. However, the xen/kvm hypervisor both support these apis and i am not sure about weather vmware have this kind of library.