does ansi c allows serial communication on rs232 null modem?
if yes then any one give me example?
thanx in advance
Ansi C has nothing to do with serial communications. ANSI C is a formal description of the C language, it doesn't define libraries. Communicating with an RS-232 modem is possible with C language, but it will be completely different in different platforms (Windows, Linux, embedded processors).
It does, in as much as there's nothing in the language which prevents it, but it depends on your OS/platform to provide access to an appropriate device driver (or an abstraction of one).
For an (elaborate) example, refer to the source to the minicom package (GPL). Something simpler (on a POSIX-like platform) might involve opening a device node, using ioctl to configure it (baud rate etc), then you can simply read and write on the open file descriptor.
Related
I'm trying to read serial input from a USB device with 9600 baud into a C program, but I'm not sure how to go about this. The program input will be really simple. I have a circuit set up with a potentiometer and its sending the voltage value every second over the USB.
How do I read this into a C program being developed on Windows? I'd prefer something cross-platform if possible.
I assume you are using arduino-like device, which can be easily configured to output serial data over USB. See a tutorial on the subject.
USB is not as simple as legacy serial ports and USB devices will need drivers. Class compliant devices are usually supported directly by operating system, see USB device classes, at least to some extent.
For example, if you are using Arduino, the simple way is to install FTDI drivers (see their website) and use the virtual COM port provided by the driver.
Communication over a COM port is a well-covered subject and you should be able to find a vast number of documentation over that. There are also cross-platform serial communication libraries that could make your development easier.
Then you could also write your own library for the device, but that would probably be an overkill if all you want is to read in a voltage.
You can either do something like this in your code to write seperate functions for Linux and windows...
#ifdef __unix__
...
#elif defined(_WIN32) || defined(WIN32)
#define OS_Windows
#endif
Or search for C libraries for cross-platform serial communication, here is one I found for C++ in one google search https://github.com/wjwwood/serial.
I am thinking of creating a C program that will use picocom to read and write serial streams to ports (GPS module, NTPD). The c program will run on a Debian OS.
Is it possible to do this using Picocom? Is it bad design to interact with Picocom through c and system commands?
While that's technically possible, it's a bad idea; picocom is a somewhat uncommon tool, and it's primarily designed to be used interactively by a user. Trying to use it from within another application will be pretty weird.
It'll be much easier to interact with the serial port directly from your application. There's a nice introduction to doing that in the answer to How to open, read, and write from serial port in C.
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 need to define a communication protocol with a Linux device driver. Protobufs look very nice, and there is an active C port.
Is it possible to use protobufs in a Linux device driver?
Obviously the vanilla c code will not work as it makes malloc calls, etc. Is there protobufs implementation that targets the kernel?
If there is a drop in solution, how much effort is it to port a C library for use in the kernel?
Bonus question: Are the answers significantly different when writing with windows drivers?
In theory, you could do this - but there really isn't any point in doing so. Protocol Buffers was created to ease the task of transferring data between different machines and languages that use different representations for binary data - but the interface between a kernel driver and userspace is on the same machine (and typically the same language - a C language library is usually used on the userspace side, even when writing application code in another language).
This means that the different representation issue doesn't arise - you can simply define structs in header files and pass those across the kernel/userspace boundary.
I want to send data or packets at particular IP address using ANSI C standard so that my code will be platform independent. How is it possible in windows OS without using windows libraries like winsock etc.? Kindly give me some guidelines or hints.
i don't think it's possible to create platform independent socket code because though ANSI C is a standard, well-defined language and network communications are invariably a feature provided by the operating system and will vary from OS to OS. This means that your code will have differences between platforms. The best you could do is mitigate these differences by constructing a clever API/library to limiting the code you need to re/write when porting.