hello and good day to you guys. I am running Windows XP which I am given to understand is a 32 bit windows system.
I have a microcontroller that continuously sends data serially through a COM port. I want to process data in a C program. The options I'm looking at so far are:
get serial data via python and pass to C
read data serially and use in C
The first option seems too hard for me. I was trying to use swig and am stuck.
any other suggestions?
You'll find it much easier just to receive the data straight via C, if you're going to process it there in the end anyway. Here's a quick overview of how to set things up. Essentially you call CreateFile on, eg, "COM1", then use GetCommState and SetCommState on the resulting handle to configure the port. If you need to do GUI interaction as well, have the reading code run on a different thread, and communicate the data it reads back to the GUI thread by posting custom (WM_USER, etc) messages to one of your windows.
Related
I just finished a small project written in C, where I read a data stream from a serial port and parse the incoming data.
The software is written for POSIX systems (using termios) and follows the standard steps to working with serial i/o
Opening the serial device using open()
Configuring communication parameters (termios)
Set blocking mode on file handle (fcntl)
Perform read() on serial interface.
Perform close() on serial interface when done.
Other than the socket parts, the code is straight ANSI C.
My question is, how involved would it be to make the code work on a windows platform.
The port would not be written by me, I'd only like to give an indication to others who might be interested in porting it (i.e. trivial, not so trivial, rip your eyes out insanity inducing).
Also if someone has Windows with "Windows Services for UNIX", would they be able to use the code without modifying it?
So, if anyone has experience with this could you please share.
It should be pretty easy to do. The names are very different, but the sequence of calls and concepts are very similar.
What you are looking for is the DCB structure which should be used with the SetComState() function to set baudrate, stopbits etc. Then use SetCommTimeouts() and set the timeout values in the COMMTIMEOUTS structure to make subsequent read calls blocking.
Here is a short introduction as a pretty PDF. (Backup.)
I have just managed to write my first windows driver (havent registered it yet- but i managed to get the things created!).
I wondered if someone can give me a high overview of how I could achieve the following:
I would like to write a driver which will implement some behaviour when a network packet is received by the computer, before windows does what it does with the packet, i'd like to take this data and output it to the console of a C or C++ program.
Lets assume I have a C/C++ program written, which has a console. How does the C/C++ program interact with the driver I wrote which is hooking the network activity? Is it simply some C code which calls my drivers, the function returns the data as an object and then I can use that object to display in the console?
Thank you in advance for any possible replies
You don't need a driver for this task. Use packet sniffer library like PCap (actually you'll need WinPCap). It's really simple to capture packets and print them to console.
Alternative way is raw socket. But desktop Windows (as opposite to Windows Server) limits raw socket functionality.
If you really want a driver, or have a requirement to manipulate or filter packets before they hit the windows network stack you need to look into filter drivers.
This filter driver can then expose a device file on which your user space application can then read/write. The windows DDK contains examples.
This question might sound fool, because I know there are bunch of frameworks that does it for you. What I want is actually get in touch with low level C API deeply and able to write a program that sits on computer and intercepts packets between local machine and outer spaces. I tried to figure it out by looking at open source code (i.e. tcpdump) but it's quite difficult for me to find out which file actually performs network sniffing. Any suggestions would be appreciated !
You have to use raw socket. Here's an example.
At least for what concern Linux and Unix like operating systems. I don't know about Windows.
If you're using a UNIX based system[*] then the simplest mechanism is libpcap, which is part of the tcpdump project.
Your process will need root privileges to be able to access the network interface (as would also be the case with raw sockets).
Usually you'll end up having to decode ethernet frames, IP headers, etc yourself, although for most protocols this isn't that hard.
[*] It is actually available for Win32 as well, but I've not used it under Windows myself.
I am using C language and Linux as my programming platform.
I am developing a user-space application that runs in a background, like a daemon. And my problem is, I want another user-space application to communicate with this daemon.
I know that I have to use Interprocess Communication method but I don't know what is the correct implementation.
But using IPC in my communication implementation is my other option. Actually I just want to change the attribute of my daemon by using another application. Please see below a senario:
My daemon runs in a background.
Then some application will control the properties of a daemon, like sleeping delay time.
My first option is by accessing a file with the values of the properties. So that my deamon will poll that values. While the other application will change that values.
I am not sure the efficiency of my options. Please advice.
THanks.
Updating the config file and sending a signal to cause re-read is a standard practise, cheap and easy.
You're looking for D-Bus. Store the initial values in a file, then listen over D-Bus for requests to change it.
Unix domain sockets are a simple IPC method.
If I were you, I'd forego IPC completely and instead have the daemon monitor a config file for changes. IPC is only really needed if you're going to be sending thousands of messages per second and the overhead would get intolerable.
inotify is an option for file monitoring.
I'd make the daemon listen on a pipe/fifo if it's simple enough that you only need to read a couple of bytes fed in from another program. Otherwise a local domain socket is nice to run a simple protocol over.
I am working on a robot automation project and I have run into a road block. To control the robot, one needs to connect with it wirelessly via telnet and send commands through the tcp/ip protocol. (ex. The 'Mabc' command moves it forward based on the left wheel speed (a), the right wheel speed (b) and time (c)). What I am trying to do is do some calculations in a C program and then send a message to the robot based on the value of the calculation.
How can send commands via tcp/ip protocol in a C program?
Thanks!
Erik
You are looking for sockets. This is a comprehensive guide to socket programming in C. Telnet is also a well defined protocol, although I don't know if this robot would use telnet or not (it's extra processing overhead for a protocol that wouldn't have much added benefit for a robot control program). Telnet is covered in detail by RFC 854
Expect would allow you to interact with external programs, but I am not aware of a C port of expect. Otherwise you would find a telnet library in C or write your own using socket programming.
I would use libcurl: http://curl.haxx.se/libcurl/. It'll do what you want, and handle all the telnet goo that you really don't want to handle.
Expect was designed to do exactly this - hold conversations with interactive programs. It's written in Tcl, extending the Tcl interpreter with various commands. Tcl is very easy to extend; it was designed to be an embedded scripting language right from the word go. The main C API uses argv-style constructs to pass parameters to Tcl commands and is very easy to use. The best guide to the C API is Ousterhout's original book and it took me one two-hour lab session to get my first embedded Tcl interpreter up and running.
As a bonus you also get a built-in Tcl interpereter, which you can use to add a scripting capability to your application. You'll probably find that quite a bit of it can be implemented in Tcl if you feel so inclined, so it will probably save you time overall.
I would be:
writing some simple shell scripts containing the telnet interractions written as here documents.
using a .telnetrc file in your home directory to control aspects of your telnet session, e.g. crmod
calling the script using system calls.
This way your turnaround time to change your interractions with the robot won't involve having to recompile your programm all the time.
BTW This sounds like fun.
HTH.
cheers,
Rob