I'm working on a program to take readings from a proximity sensor using Arduino UNO. While I can get the readings just fine using Arduino's build-in Serial Monitor, somehow I cannot open the same port from MS VC++.
Following is (one part of) the program:
int main(void)
{
/*used for port"COM13"*/
HANDLE hCom=INVALID_HANDLE_VALUE;
char input[30];
string ss,ss1,ss2,ss3,ss4;
/*Open "COM13"*/
hCom=CreateFile("COM13",GENERIC_READ|GENERIC_WRITE,0,NULL,OPEN_EXISTING,0,NULL);
if(hCom==INVALID_HANDLE_VALUE)
{
printf("can't open file");
}
/*Communication Setting*/
DCB dcb;
memset(&dcb,0,sizeof (DCB));
dcb.DCBlength=sizeof (DCB);
dcb.BaudRate=CBR_9600;
dcb.ByteSize=8;
dcb.Parity=NOPARITY;
dcb.StopBits=ONESTOPBIT;
SetCommState(hCom,&dcb);
while(1)
{
//using the data string inputs, printout the readings, process it etc...
}
}
When I try to debug it, I'll get this error:
and I got can't open file from debug windows showing there is problem during port opening.
Some additional infos:
Why VC++? I'm also using OpenCV and some mathematical computation in the same program so it is easier for me to work in VC++
I've also tested my UNO program with TeraTerm for data readings with no problem (=no problem with my UNO)
I've tested above program with another microcontroller(non-Arduino) with no problem.
I'll upload my UNO program if needed.
Thanks in advance!
From the MSDN page on CreateFile:
To specify a COM port number greater than 9, use the following syntax:
"\.\COM10". This syntax works for all port numbers and hardware that
allows COM port numbers to be specified.
Related
I am trying to make a Console C++ program that will be able to communicate through the serial port with my Arduino microcontroller, however I am having a problem with the ReadFile() function:
This is the ReadFile() function code from my C++ Console Program:
if(ReadFile(myPortHandle, &szBuf, 1, &dwIncommingReadSize, NULL) != 0)
{
cout<<"FOUND IT!"<<endl;
Sleep(100);
}
else
{
cout<<".";
Sleep(100);
}
The ReadFile function is consistently returning the "False" value, meaning it is not finding anything in the serial port. On the other side of the serial port, I have my Arduino Hooked up with the following code:
int switchPin = 4; // Switch connected to pin 4
void setup() {
pinMode(switchPin, INPUT); // Set pin 0 as an input
Serial.begin(9600); // Start serial communication at 9600 bps
}
void loop() {
if (digitalRead(switchPin) == HIGH) { // If switch is ON,
Serial.write(1); // send 1 to Processing
} else { // If the switch is not ON,
Serial.write(0); // send 0 to Processing
}
delay(100); // Wait 100 milliseconds
}
And every time I press a push button, I would send a "1" value to the serial port, and a "0" every time I don't press a push button. Basically, I got the Arduino code from a tutorial I watched on how to do serial communication with the program Processing (which worked perfectly), though I am unable to do the same with a simple Console Application I made with C++ because for some reason the ReadFile() function isn't finding any information in the serial port.
Anyone happen to know why?
P.S.: The complete code in the C++ Console Program can be found here:
https://stackoverflow.com/questions/27844956/c-console-program-serial-communication-arduino
The ReadFile function is consistently returning the "False" value, meaning it is not finding anything
No, that is not what it means. A FALSE return value indicates that it failed. That is never normal, you must implement error reporting code so you can diagnose the reason. And end the program since there is little reason to continue running. Unless you setup the serial port to intentionally fail by setting a read timeout.
Use GetLastError() to obtain the underlying Windows error code.
You look to use MS Windows so try to catch the arduino output using portmon first, then you can debug your C++ code.
It seems to be a pain to get serial working in c++, adding to that, to do it on the Beaglebone Black is hard, so I need someone with some expertise!
I created /dev/ttyO4 with the following command:
echo BB-UART4 > /sys/devices/bone_capemgr.9/slots
This gives me /dev/ttyO4. I then write a small program in cpp using a library linked here. My code is found below:
#include <stdio.h>
#include "serialib.h"
#if defined (_WIN32) || defined( _WIN64)
#define DEVICE_PORT "COM1" // COM1 for windows
#endif
#ifdef __linux__
#define DEVICE_PORT "/dev/ttyO4" // ttyS0 for linux
#endif
int main()
{
serialib LS; // Object of the serialib class
int Ret; // Used for return values
char Buffer[128];
// Open serial port
Ret=LS.Open(DEVICE_PORT,115200); // Open serial link at 115200 bauds
if (Ret!=1) { // If an error occured...
printf ("Error while opening port. Permission problem ?\n"); // ... display a message ...
return Ret; // ... quit the application
}
printf ("Serial port opened successfully !\n");
// Write the AT command on the serial port
Ret=LS.WriteString("AT\n"); // Send the command on the serial port
if (Ret!=1) { // If the writting operation failed ...
printf ("Error while writing data\n"); // ... display a message ...
return Ret; // ... quit the application.
}
printf ("Write operation is successful \n");
// Read a string from the serial device
Ret=LS.ReadString(Buffer,'\n',128,5000); // Read a maximum of 128 characters with a timeout of 5 seconds
// The final character of the string must be a line feed ('\n')
if (Ret>0) // If a string has been read from, print the string
printf ("String read from serial port : %s",Buffer);
else
printf ("TimeOut reached. No data received !\n"); // If not, print a message.
// Close the connection with the device
LS.Close();
return 0;
}
When I run the code, it says it opened the port successfully and successfully wrote serially, but I receive no data on the RX. I have connected the RX pin to the TX pin for UART4 (P9.11 and P9.13). I also connected the RX and TX pins for UART5 just incase (P8.37 and P8.38), as the ttyO4 confused me a bit as to which UART I'm using.
Is there something I'm missing to get the serial port working? Or can someone refer me to a working example for serial communication with c++ on the beaglebone black, perhaps like a step-by-step guide?
Regards,
Cornel
EDIT:
The Boost serial libraries work more reliably than serialib, find them here.
So I tried the same steps as you did. I downloaded and compiled the code from http://serialib.free.fr/html/classserialib.html and compiled with a warning about
serialib.cpp: 337:40: warning: converting to non-pointer type 'unsigned int' from NULL [-Wconversion-null]
(If you know how to fix this please let me know). But I ran the program with the Tx/Rx pins hooked up to an Arduino Mega Rx1/Tx1 pins. The program writes fine and I can see the Arduino read in the bytes. When I write from the Arduino to the Rx of the Beaglebone Black it times out and says no data was received.
As far as I can tell, this is a problem with how the Rx pin is set.
EDIT: So I just printed the Buffer that receives the data written to the port and it receives the data just fine. So the problem is with the value of Ret. For now you can use the buffer as the received data. I'll try and figure out why the return value from ReadString() isn't working.
to correct the [-Wconversion-null] error:
Open 'serialib.cpp' file and go to the 'ReadStringNoTimeOut' function.
Change
ret=ReadChar(&String[NbBytes]);
to
ret=ReadChar(&String[NbBytes],0);
I'm trying to make a serial connection to an Arduino Diecimila board with QextSerialPort. My application hangs though everytime I call port->open(). The reason I think this is happening is because the Arduino board resets itself everytime a serial connection to it is made. There's a way of not making the board reset described here, but I can't figure out how to get QextSerialPort to do that. I can only set the DTR to false after the port has been opened that's not much help since the board has already reset itself by that time.
The code for the connection looks like this:
port = new QextSerialPort("/dev/tty.usbserial-A4001uwj");
port->open(QIODevice::ReadWrite);
port->setBaudRate(BAUD9600);
port->setFlowControl(FLOW_OFF);
port->setParity(PAR_NONE);
port->setDataBits(DATA_8);
port->setStopBits(STOP_1);
port->setDtr(false);
port->setRts(false);
Any ideas on how to get this done. I don't necessarily need to use QextSerialPort should someone know of another library that does the trick.
I'm new to C++ and Qt.
UPDATE:
I noticed that if I run a python script that connects to the same port (using pySerial) before running the above code, everything works just fine.
I had a similar problem.
In my case QExtSerial would open the port, I'd see the RX/TX lights on the board flash, but no data would be received. If I opened the port with another terminal program first QExtSerial would work as expected.
What solved it for me was opening the port, configuring the port settings, and then making DTR and RTS high for a short period of time.
This was on Windows 7 w/ an ATMega32u4 (SFE Pro Micro).
bool serialController::openPort(QString portName) {
QString selectPort = QString("\\\\.\\%1").arg(portName);
this->port = new QextSerialPort(selectPort,QextSerialPort::EventDriven);
if (port->open(QIODevice::ReadWrite | QIODevice::Unbuffered) == true) {
port->setBaudRate(BAUD38400);
port->setFlowControl(FLOW_OFF);
port->setParity(PAR_NONE);
port->setDataBits(DATA_8);
port->setStopBits(STOP_1);
port->setTimeout(500);
port->setDtr(true);
port->setRts(true);
Sleep(100);
port->setDtr(false);
port->setRts(false);
connect(port,SIGNAL(readyRead()), this, SLOT(onReadyRead()));
return true;
} else {
// Device failed to open: port->errorString();
}
return false;
}
libserial is an incredible library I use for stand-alone serial applications for my Arduino Duemilanove.
qserialdevice use!
Example:
http://robocraft.ru/blog/544.html
Can you just use a 3wire serial cable (tx/rx/gnd) with no DTR,RTS lines?
Ok, so I have 3 devices.
an AVR Butterfly microcontroller, set up with USART
A Bifferboard, running Debian, using a custom made program for serial.
A Desktop machine running Br#y's.
So I'm trying to make the Bifferboard send serial to the AVR, But the AVR never receives the signal, (we've checked the wires). But if i connect the AVR to the desktop box, and send with Br#y's it receives just fine.
If I connect the Bifferboard to the Desktop, Br#y's receives just fine.
Heres the code for the Bifferboard.
#include "string2num.h" //a custom header
#include <cstdlib>
#include <iostream>
#include <SerialStream.h>
using namespace LibSerial;
//using namespace std;
int main(int argc, char*argv[])
{
if (argc<2)
{
std::cout<<argv[0]<<" requires the device name eg \'dev/tty0\' as a parameter\nterminating.\n";
return 1;
}
SerialStream theSerialStream(argv[1]); //open the device
if(!theSerialStream.IsOpen()) //did the device succesfuilly open
{ //open faile
std::cerr<<"Open " << argv[1] << " failed\n Terminating.\n";
return 1; //exit failure
}
theSerialStream.SetVMin(0);//no min number of characters to send
theSerialStream.SetVTime(0);// don't wait betwenn characters
theSerialStream.SetBaudRate( SerialStreamBuf::BAUD_19200);
theSerialStream.SetCharSize(SerialStreamBuf::CHAR_SIZE_8); //8
theSerialStream.SetParity(SerialStreamBuf::PARITY_NONE);// N
theSerialStream.SetNumOfStopBits(1);// 1
theSerialStream.SetFlowControl(SerialStreamBuf::FLOW_CONTROL_NONE);
std::cout<<"Ready for serial trasmission. Press Ctrl+C to quit\n";
//insert basic instructions here
while (1)
{
char input[BUFSIZ];
std::cin>>input;
char* values=getAllValues(input); //DECODE any formatting (this function is in the custom header)
std::cout<<"about to transmit: " << values << "\n";
theSerialStream << values;
free(values);
}
theSerialStream.Close();
return 0;
}
I've also tried using minicom from Bifferboard - it can talk to the desktop windows machine, but not the the AVR.
(We've checked the wires)
This still sounds like a cabling problem. If Br#y's can communicate with both, then it doesn't seem to be a configuration issue. You should throw a logic analyzer or oscilloscope on the receive pin (and probably probe other pins) of the AVR and see what's happening electrically when yo try to send data from the Bifferboard.
I'd bet that you see the data on some other pin. But I wouldn't bet a whole lot, because serial RS232 connectivity is such a touchy thing.
It's a long shot, but are all the serial ports running at the same voltage levels? I see the bifferboard has a 3.3V UART, whereas the AVR has a level convertor. The desktop port may be more flexible about voltage.
I'll throw out another "long shot" possibility. Depending on the transciever chip being used on a board it may not be able to produce its own negative supply voltage (typically via a charge pump) for RS232 levels. Some chips will "steal" their negative supply from the other side of the line, and that works great if you're talking to something like a PC. If both sides take that approach, however, it doesn't work out so great. Tranceivers like MAX232 (plus external caps and resistors) will generate their own negative supply, but chips like the DS275 don't.
What's the problem in given code? Why it is not showing the output for rs232 when we connect it by the d-9 connector with the short of pin number 2 & 3 in that?
#include <bios.h>
#include <conio.h>
#define COM1 0
#define DATA_READY 0x100
#define SETTINGS ( 0x80 | 0x02 | 0x00 | 0x00)
int main(void)
{
int in, out, status;
bioscom(0, SETTINGS, COM1); /*initialize the port*/
cprintf("Data sent to you: ");
while (1)
{
status = bioscom(3, 0, COM1); /*wait until get a data*/
if (status & DATA_READY)
if ((out = bioscom(2, 0, COM1) & 0x7F) != 0) /*input a data*/
putch(out);
if (kbhit())
{
if ((in = getch()) == 27) /* ASCII of Esc*/
break;
bioscom(1, in, COM1); /*output a data*/
}
}
return 0;
}
Well, the code looks alright. Have you really connected the remaining pins correctly in the plug, see serial and pin connections.
Nothing obvious stands out from your code as the cause. Check all your bases as you are dealing with hardware/software. The following Microsoft article has a different implementation using _bios_serialcom (from bios.h) which might be a good reference point for you.
http://support.microsoft.com/kb/39501
Suggestions for where to go from here:
I would also suggest replacing the literals (eg 0x08) using the constants predefined for Baud rate, Parity (eg _COM_NOPARITY) to make the code more readable in your question.
Check that the Com port is actually open, as its a assumption which is unchecked in your code example above.
Also check up on the pin connections for the DB9. To connect two computers/devices you will need to null modem it, eg pin 2 to pin 3 at the other end, plus the Signal Ground. Make sure you are disabling/not looking for DTR.
If the other computer/device is setup then I would suggest first running HyperTerminal (Programs->Accessories->Communication) and connect to your COM 1 and check you can see characters from the other device. If not its most likely related to your cable.
Hope that helps.
Before checking with your code always check your serial communication with a terminal program. I don't have much experience with Windows environment but in Linux you have programs like cutecom or gtkterm where you can send/receive data from serial port. We extensively used these programs for serial communication in Linux, they are great for debugging potential problems with serial port interface (both h/w & s/w as well). So, before suspecting your code check with a terminal emulator program.
Hey, I am not an expert on Win32, but it seems to be easier to use another article as a source (the one mentioned here before looks outdated):
http://msdn.microsoft.com/en-us/library/ms810467
This is old too, dated around 1995, but it looks still effective. The NT architecture is very restrictive when it comes to grant access to hardware, for example, to send bytes to a PC paralell port one needs to rely on workarounds dll written by open source developers.
I'm assuming from your comment about "pin 2 & 3" that you've connected a loopback cable, so you're expecting to see anything you type come up on the screen (and stop doing so when you disconnect the cable).
I think there's a bug in the code: the if (kbhit()) is inside the if (status & DATA_READY).
That means you only check the keyboard if there is some input ready to receive from the serial port - which there won't be, because you haven't sent it anything yet! Try moving the test and see if it improves matters.
(Here is some similar serial port code that puts the if (kbhit()) test outside the DATA_READY check. It doesn't claim to work, but provides some evidence that this might be the source of the problem...)