C++ Programming
11-10-2009, 12:06 PM
Background: I am an embedded 'C' programmer, with no windows development experience other than simple console applications using Win32. I have developed using classes but mostly in Java. Other than the ubiquitous "Hello World" using Windows Forms and C++, I have limited to no windows programming experience.
Problem:I have a project where I need to interface an embedded controller to a windows application. Ultimately I need to translate input from windows controls into a stream of serial characters. This stream is interpreted by the embedded controller to do "stuff". The serial interface here may be a "real" serial port, or through a USB-Serial converter cable.
I don't have the money to buy comm libraries, I am using the Visual Studio 2008 Express because it is free, and unless it is absolutely necessary, I am not interested in learning another ******** like C# or Visual Basic. It is difficult enough for a 'C' coder in the embedded world to transition into the windows world of C++. I don't understand the implications of using ATL vs. MFC vs CLR vs Win32, so please be gentle.
I have posed this question now a half a dozen other forums and keep getting references to Visual C++ 2005 or 2006 code that will not compile in the .NET vernacular (did I get the nuance correct?) Or admonishments to "Just use ___" (insert any of J#, C#, VB or PHP). What used to be a simple:"fputc(com1, "My String");" is now a multilayered, insulated, managed into obscurity onion of code.
If I understand it correctly, in the Win32 vernacular, there is a serial port class, that can be used to instantiate an object that has methods for determining if a port exists, setting port parameters (like BRPY- Baud rate and parity, and flow control) as well as mapping the "" operators to accommodate inserting/retrieving objects (like a string) into the stream.
I have yet to see an example of code, written using Win32, that will demonstrate moving a single character to a serial port, using the Visual Studio 2008 toolbox.
I need to lean on the experience of more informed programmers for guidance and direction to help me to the next step. Any help or direction (even if it is an admonishment to "RTFM" as long as the requisite "FM" is given) would be greatly appreciated.
David
Melbourne, Florida
Problem:I have a project where I need to interface an embedded controller to a windows application. Ultimately I need to translate input from windows controls into a stream of serial characters. This stream is interpreted by the embedded controller to do "stuff". The serial interface here may be a "real" serial port, or through a USB-Serial converter cable.
I don't have the money to buy comm libraries, I am using the Visual Studio 2008 Express because it is free, and unless it is absolutely necessary, I am not interested in learning another ******** like C# or Visual Basic. It is difficult enough for a 'C' coder in the embedded world to transition into the windows world of C++. I don't understand the implications of using ATL vs. MFC vs CLR vs Win32, so please be gentle.
I have posed this question now a half a dozen other forums and keep getting references to Visual C++ 2005 or 2006 code that will not compile in the .NET vernacular (did I get the nuance correct?) Or admonishments to "Just use ___" (insert any of J#, C#, VB or PHP). What used to be a simple:"fputc(com1, "My String");" is now a multilayered, insulated, managed into obscurity onion of code.
If I understand it correctly, in the Win32 vernacular, there is a serial port class, that can be used to instantiate an object that has methods for determining if a port exists, setting port parameters (like BRPY- Baud rate and parity, and flow control) as well as mapping the "" operators to accommodate inserting/retrieving objects (like a string) into the stream.
I have yet to see an example of code, written using Win32, that will demonstrate moving a single character to a serial port, using the Visual Studio 2008 toolbox.
I need to lean on the experience of more informed programmers for guidance and direction to help me to the next step. Any help or direction (even if it is an admonishment to "RTFM" as long as the requisite "FM" is given) would be greatly appreciated.
David
Melbourne, Florida