I am trying to get a microcontroller to communicate with a Windows PC over serial port.
It looks to me like Windows is buffering the input on COM1 such that if I stop both programs running, then restart only the Windows program it is still receiving some output from the previous run of the microcontroller's program.
After I open COM1 can I some how flush its receive buffer before beginning to read? Is there a function call to do that?
I believe the function you are looking for is PurgeComm, to which you pass the HANDLE you got from CreateFile() when you opened the port. I'm not sure, but I believe the serial port is also automatically flushed each time you open it.
However, a better method is to use ReadFile (or ReadFileEx) until you encounter something meaningful. Serial protocols are always designed with one or more sync bytes for this very purpose. Unless you are writing a terminal program or similar, you will have to do like this anyhow, since the Windows PC will never be in sync with the microcontroller otherwise.
Related
I need to "talk" with a certain sensor through a UART connection.
Using the termios everything works with no problems and I'm able to have continuous communications with it- writing and reading multiple times.
But if I open a file for r/w purposes using either fopen() or open() at any time during this communication, the UART connection stops working properly:
messages can still be sent, but when read they're incomplete.
Even closing and reopening the same UART connection results in errors.
Code is written in C, and am currently using Eclipse on some Linux distro. All of this on VM.
Any ideas on what could cause this problem?
P. S.: any suggestions regarding posting here would also be appreciated
Check if you are using the same BAUD rate which your sensor works on. This is is the main problem most of the times.
I'm writing a Windows kernel driver in C and I need to send and receive data over a serial device, specifically COM3. I am stuck on the CreateFile, ReadFile, and WriteFile functions, as these seem to be user space functions that will not work in the kernel. Am I mistaken? Or if not, what is the best way to open and use a serial port from within the Windows kernel?
Many thanks.
You need ZwCreateFile, ZwReadFile and ZwWriteFile functions for working in kernel mode.
You are writing a driver then You must have to write kernel module for windows .
check this
http://www.codeproject.com/Articles/9504/Driver-Development-Part-1-Introduction-to-Drivers
One more thing once you have finished the driver you need a application to test it.
so you need a user space application to test it.
How are you supposed to programatically detect when the remote modem on your call hangs up? I am writing a C program which interfaces with a SoftModem device /dev/ttySL0 in Ubuntu linux. I am able to configure the modem using Hayes AT commands and communicate with the remote modem. However, I haven't been able to determine how I'm supposed to detect that the other end has hung up the line.
I have the modem configured so that when the other end hangs up, the device prints NO CARRIER and switches to command mode. However, I can't use the NO CARRIER string because I can't guarantee that the modem won't receive that string while in data mode.
How do you "listen" for remote hang up?
This is a hardware signal on modems, the Carrier Detect (CD) line. You'll need to monitor it to know that the connection was lost. Basics in linux are described in this how-to, you obtain the signal state with ioctl() using the TIOCM_CAR command.
Testing for NO CARRIER as text will not suffice. This text frequently occurs on sites in the net, even on Q&A sites.
Coming from the modem, it should be enclosed in line breaks.
Besides, after you detect that text, you can try to switch to command mode with +++. If that works, your connection persists and you can reattach it and continue using it. If it doesn't (because you are already there and +++ is an invalid command), the connection has gone.
I am writing a C program in Linux which will read/write to/from a serial port. I know the data that needs to be read and written on the port but I don't have a serial port to currently test this with.
Is there any way to simulate a serial port? Would reading/writing to a file be sufficient? I can have one process write to the file while another process reads that data and writes back other data to the file. Or are there others tools that can be used to simulate a port?
Thanks
Serial ports on Linux are terminal devices. A close simulation is to create a pseudo-terminal pair; the program that normally talks to the serial port is instead told to open the slave side of the pseudo-terminal, and the simulator writes and reads from the master side.
The pty(7) man page has more information.
Despite being an old topic, and my answer is not exactly something the OP was looking for, I decided to share my experience, as someone else might come across it like I did. Instead of straightforward simulation, I used the software called Serial to Ethernet Connector to gain access to the specific device I needed to test the app with. Worked nicely for me.
A character device, even something as simple as normal stdin and stdout should work if you don't care about attributes specific to port devices.
I am using C language and Linux as my programming platform. Right now I am learning some embedded programming. I am using a POS device for my practice session and my host is a Windows OS using a cygwin.
I created a simple application that will run in the target device that will read the data in the serial port and in the host side I created a simple application that will write the data in the serial port. Now my problem is when I am sending a data without 0x0a(LN) at the end of the buffer the target device will not receive that data. But I am not sure if that was sent or not. But when I put a 0x0a(LN) at the end of the buffer to send then the target device will receive that data.
Did I missed some configuration of my application? Or putting a 0x0a byte at the end of the tx buffer is the correct way.
Thanks
It sounds like your serial port (actually the 'terminal device' as far as Linux is concerned) may be in line-buffered mode. When setting it up with tcsetattr, be sure to clear c_lflag (you don't want ICANON). You should also check out the input/output flags that affect translation between CRLF and NL since you probably don't want that behavior either. Default terminal settings are oriented towards user/application interaction, not data transmission.
Sounds like it's doing line buffering. Do a flush after sending the data.