|
Your test does not show what you think. It shows the values that you set in pData before the call to GetData, which does not change it. You need to reread the documentation, and understand the difference between a pointer and a reference.
|
|
|
|
|
Because the CData pointer is passed by value. If you need to modify the pointer then you have to pass it by reference (or use a double pointer).
|
|
|
|
|
I used double pointer and goes perfectly. Kindly thank you all of you (including Richard)!
|
|
|
|
|
In VS 2017, is it possible to create a static library project that exports classes the same way an MFC Extension DLL does?
I know I can create a regular static library project, but how would I make it possible to use MFC classes like CString inside that project?
The difficult we do right away...
...the impossible takes slightly longer.
|
|
|
|
|
|
Thank you for your response!
I just figured out how to do it.
First, create a static library project, then include all of the MFC headers in the stdafx.h file.
Thanks again. 
The difficult we do right away...
...the impossible takes slightly longer.
|
|
|
|
|
Hello everyone,
I'm kinda new to writing application programs for a PC, a Linux one at that, so I hope this isn't a stupid question. 
I am rather experienced at writing C programs for Microchip PICs. I need a PC application to interface with a PIC project, it will up load information to the PIC from the PC using a pair of Wixel modules. They are basically a USB to RF or RF to Serial bridge. I have them working (one connected to the PC, one connected to the PIC) using a terminal program. I can send data back and forth just fine.
I am now trying to send and receive data using a C++ application. The sending from the PC to the PIC works just fine also. The problem I am having is getting data from the PIC to the PC Application.
This is the application code ..
#include <cstdlib>
#include <iostream>
#include <fstream>
#include <sstream>
using namespace std;
int main(int argc, char** argv)
{
fstream COMPORT;
char line[256];
streamsize lim = 256;
char c;
COMPORT.open("/dev/ttyACM0");
while(1)
{
if (COMPORT.is_open())
{
cout << "Hit <Enter> to send command, <S> to Stop .." << endl;
cin.get(c);
if ((c == 's' || c == 'S'))
{
COMPORT.close();
return 0;
}
COMPORT << "UPLOAD NEW MAP\n";
COMPORT.getline(line, lim);
cout << "Line =" << line;
cout << "Response=" << c;
cout << endl;
}
}
COMPORT.close();
return 0;
}
The PIC code, if that helps ..
void APP_Wixel_IO_Test_Tasks(void)
{
APP_ESUART_Tasks();
if (CmdReady == 1)
{
CmdReady = 0;
RXBufCnt = 0;
utoa(TXBuf, Cnt, 10);
strcat(TXBuf, "\n");
WriteESUARTDataMsg(TXBuf, strlen(RXBuf));
Cnt++;
}
}
Basically all the PIC code does is send back the 'cnt' variable when it gets data from the PC.
The
COMPORT.getline(line, lim); doesn't work right. The first time I run it, it kinda works, but resending the data back to the PIC gets no response ..
Hit <Enter> to send command, <S> to Stop ..
Response=4
Hit <Enter> to send command, <S> to Stop ..
Response=
Hit <Enter> to send command, <S> to Stop ..
Response=
Hit <Enter> to send command, <S> to Stop ..
Response=
Hit <Enter> to send command, <S> to Stop ..
I've tried everything I can think of. Like I said, data out
COMPORT << "UPLOAD NEW MAP\n"; works fine. Data in does not.
Thanks
OtG
|
|
|
|
|
WriteESUARTDataMsg(TXBuf, strlen(RXBuf));
Should that not be strlen(TXBuf) ?
|
|
|
|
|
Yes, it should. I changed that but I get the same response from the application ..
Response=�
Hit <Enter> to send command, <S> to Stop ..
Response=
Hit <Enter> to send command, <S> to Stop ..
Response=
Hit <Enter> to send command, <S> to Stop ..
Response=
Hit <Enter> to send command, <S> to Stop ..
^C
RUN FINISHED; Interrupt; real time: 11s; user: 0ms; system: 0ms
I am pretty sure the PIC is doing it's job and replying to the message from the application (PC) correctly.
Thanks for spotting that error.
OdlG
|
|
|
|
|
I have never tried to read a serial port via a stream class. Serial ports tend to be slow, and are really character oriented. You could try just using a basic file handle and reading as many characters as you can, gradually filling a buffer until you see a newline character. I know the ifstream should work that way but ...
|
|
|
|
|
Thanks for the reply. I did try using get(c); but that didn't seem to work either. I will look at that some more.
OdlG
|
|
|
|
|
Any advise on how to do that?
Thanks.
Richard MacCutchan wrote: You could try just using a basic file handle and reading as many characters as you can, gradually filling a buffer until you see a newline character
|
|
|
|
|
I am not familiar with Linux but I have done some programming with usb to rs232 dongles in Windows and your symptom is familiar. For what it's worth, are you sure your serial port parameters match?
If not, you may get partial data and the port on the computer can error. Can you check for error
conditions like parity error? I do not know if you are sending a lot of data, but if you are,
you will have to consider serial handshaking as well or you will get buffer overruns.
|
|
|
|
|
speedbump99 wrote: For what it's worth, are you sure your serial port parameters match?
Yes. I can send data back and forth with a terminal program.
I have modified the programs like this ..
void APP_Wixel_IO_Test_Tasks(void)
{
APP_ESUART_Tasks();
if (CmdReady == 1)
{
CmdReady = 0;
RXBufCnt = 0;
utoa(TXBuf, Cnt, 10);
strcat(TXBuf, "\n");
WriteESUARTDataMsg(TXBuf, strlen(TXBuf));
Cnt++;
}
}
and this ..
int main(int argc, char** argv)
{
fstream COMPORT;
int number;
int x = 0;
char c;
while(1)
{
COMPORT.open("/dev/ttyACM0");
if (COMPORT.is_open())
{
cout << "Hit <Enter> to send command, <S> to Stop .." << endl;
cin.get(c);
if ((c == 's' || c == 'S'))
{
COMPORT.close();
return 0;
}
COMPORT << "UPLOAD NEW MAP\n";
COMPORT >> number;
cout << "number = " << number;
cout << endl;
}
COMPORT.close();
}
return 0;
}
I get this response ..
Hit <Enter> to send command, <S> to Stop ..
number = 0
Hit <Enter> to send command, <S> to Stop ..
number = 2
Hit <Enter> to send command, <S> to Stop ..
number = 4
Hit <Enter> to send command, <S> to Stop ..
number = 6
Hit <Enter> to send command, <S> to Stop ..
number = 8
Hit <Enter> to send command, <S> to Stop ..
s
I cannot figure why the cnt goes to two times instead of one.
I would like to not be limited to just sending numbers back from the PIC.
I think I am doing things "pretty' much correctly, but??
Any thoughts?
OdlG
|
|
|
|
|
If it works in a terminal program I really don't have any help for you except this.
I don't know if it is this issue but these lines could be a potential problem
depending on how COMPORT functions:
COMPORT << "UPLOAD NEW MAP\n";
COMPORT >> number;
There might be a timing issue if all data has not been received from the pic when
COMPORT >> number; is called. As a test you might want to put a delay in to give it time.
COMPORT << "UPLOAD NEW MAP\n";
delay?
COMPORT >> number;
|
|
|
|
|
Thanks for the reply and suggestion.
I think that a delay might help if I am trying to get a string from the PIC to the PC app.
I would HOPE that the Getline function would do the waiting, but ??
speedbump99 wrote: As a test you might want to put a delay in to give it time.
I've thought about trying that, I don't see a delay function in C++ though. Is there one?
In PIC C there is a __delay_us(10); function that would delay, in this case 10 microseconds based on the current clock speed.
Seems that C++ ought to have one. Maybe have to just do a loop?
OdlG
|
|
|
|
|
I kind of doubt that getline will wait for data as it has no way of knowing how
much data to expect.
A quick search for Linux and Delay turned up a sleep() command that may be what you need.
Also a search of "Linux synchronous serial port PIC" showed several of examples where they went through the process of setting the parameters for the serial port and running a loop to retrieve data.
Something like (pseudo code):
while (1)
{
read(1 char);
if char == "\n"
break;
}
You would probably read the text and convert back to integer.
You might try that search.
Hope this helps.
|
|
|
|
|
Thanks for the reply,
speedbump99 wrote: I kind of doubt that getline will wait for data as it has no way of knowing how
much data to expect.
I think it will. In fact there are several versions of the getline function. In one you can specify a char array, max number of chars and a delimiter char. The default delim is '\n'.
I have tried doing it char by char and didn't have any better results. I may try that again as it seems the operator >> only inputs numbers (of various types) and not strings. I think getline must be used for that.
For right now I'm going to get my scope out and see why my reply jumps by two's instead of one with each command sent to the PIC.
I will keep this thread updated.
Thanks all,
OdlG
|
|
|
|
|
Last suggestion. If you have another pc with a com port, connect the two pc's together
and run the terminal program you have on one and your application on the other. Then you
can see exactly what your application is sending out. I have also done this on a single computer
with two com ports.
Good Luck
|
|
|
|
|
Did a little debugging and it seems that the PC app is echoing the data from the PIC back to the PIC. I wonder why and how to stop that.
OdlG
|
|
|
|
|
Just an update on things I found using my oscilloscope and looking at what is being sent back and forth between the PC and PIC.
I wish I could upload a screen shot from the scope.
The PC is sending out three (sometimes two) data bursts. The first is obviously the
"UPLOAD NEW MAP\n" command to the PIC. What the other two data burst are, I don't know yet.
The PIC is replying twice, as would be expected if the data bursts contain the '\n' char.
So looks like my first objective is to find out why
COMPORT << "UPLOAD NEW MAP" << endl;
is sending data out more than once.
Any ideas would be appreciated.
OdlG
|
|
|
|
|
I did a little debugging on the PIC side and see that the PC app is echoing back the data it gets from the PIC.
Any ideas why and how to stop that?
Thanks?
OdlG
|
|
|
|
|
That is probably because the serial device has echoing enabled. Such is used with serial terminals. When a character is received, it is send back to be displayed in the terminal (which usually does not display the character locally before sending it but waits for the echoed character to display that).
To avoid that you have to disable echoing by configuring the serial device initially:
stty -F /dev/ttyACM0 raw pass8 -echo -hup -clocal 9600 Note that it might be necessary to specify also other settings, remove some used above, and change the baud rate. See stty(1): change/print terminal line settings - Linux man page[^] for the available options. Before changing the options I suggest to execute
stty -F /dev/ttyACM0 to check the current settings.
As already mentioned by others it is rather uncommon to use C++ streams with serial ports. The common method is using termios and the IO functions from the standard C library, or a library like Serial Ports - 1.65.0[^] from Boost.Asio - 1.66.0[^] .
Related reads:
Serial HOWTO[^]
Serial Programming/Serial Linux - Wikibooks, open books for an open world[^]
|
|
|
|
|
Jochen Arndt wrote: The common method is using termios and the IO functions from the standard C library
Thank you for the reply. It is ironic that I ran across this yesterday and was able to write something that used this successfully. I will use this in my final code I am sure. My issue now is the write command, it seems to be char based, so I'm working on sending a char buffer.
Once again, thanks to you and the forum, I really appreciate it.
OdlG
|
|
|
|
|
Thanks for the help so far. I have written a small PC App program to try termios out.
I am having two issues.
First is the first time I send data to the PIC, the return response is junk.
Second is the response is out of sync with the sent command, it takes sending the command a second time for the response string to be correct. Would appreciate a second pair of eyes to see what is the problem.
PC app code ..
int main(int argc, char** argv)
{
ComPort MyComPort;
char TXBuf[255];
char RXBuf[255];
char c;
while(1)
{
cout << "(U)load New Map, (N)ext Map, (Q)uit .." << endl;
cin >> c;
c = (char)toupper(c);
if (c == 'Q') return 0;
if (c == 'U')
{
strcpy(TXBuf, "UPLOAD NEW MAP\n");
MyComPort.WriteComPortDataMsg(TXBuf, strlen(TXBuf));
MyComPort.ReadComPortDataMsg(RXBuf);
cout << "RXBuf = " << RXBuf << endl;
}
else if (c == 'N')
{
strcpy(TXBuf, "NEXT MAP\n");
MyComPort.WriteComPortDataMsg(TXBuf, strlen(TXBuf));
MyComPort.ReadComPortDataMsg(RXBuf);
cout << "RXBuf = " << RXBuf << endl;
}
cout << endl;
}
return 0;
}
class defs ..
class ComPort
{
public:
ComPort();
~ComPort();
void WriteComPortDataMsg(char *data, char num);
void ReadComPortDataMsg(char *data, char dlimc);
void ReadComPortDataMsg(char *data);
void SetDlimiter(char dlimc);
private:
char dlim;
struct termios config;
int hComPort;
bool Error;
};
void ComPort::WriteComPortDataMsg(char *data, char num)
{
for (int cnt = 0; cnt < num; cnt++)
{
write(hComPort, &data[cnt], 1);
}
tcdrain(hComPort);
}
void ComPort::ReadComPortDataMsg(char *data)
{
int cnt = 0;
char c;
data[0] = 0x00;
do
{
read(hComPort, &c, 1);
if ((c >= 0x20) && (c <= 0x7E)) data[cnt++] = c;
} while ((c != dlim) && (cnt < 255));
data[cnt++] = '\0';
}
responses ..
(U)load New Map, (N)ext Map, (Q)uit ..
u
RXBuf = MMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMM
(U)load New Map, (N)ext Map, (Q)uit ..
u
RXBuf = Processing: UPLOAD NEW MAP
(U)load New Map, (N)ext Map, (Q)uit ..
u
RXBuf = Processing: UPLOAD NEW MAP
(U)load New Map, (N)ext Map, (Q)uit ..
n
RXBuf = Processing: UPLOAD NEW MAP
(U)load New Map, (N)ext Map, (Q)uit ..
n
RXBuf = Processing: NEXT MAP
(U)load New Map, (N)ext Map, (Q)uit ..
n
RXBuf = Processing: NEXT MAP
(U)load New Map, (N)ext Map, (Q)uit ..
q
RUN FINISHED; exit value 0; real time: 13s; user: 0ms; system: 0ms
As you can see the first command response gets junk in RXBuf. The second time response is correct.
Changing the command to "Next Map" gets incorrect response the first time but OK response the second.
Any ideas would be appreciated.
Thanks
OdlG
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
