C++ code for serial port comm

[Richard Ingram]

I trying to set up communication to a mpu. I have been working with a c++ serial class that I found on the internet:
http://www.codeguru.com/Cpp/I-N/network/serialcommunications/article.php/c2503
I am am fairly new to C++ and C programming for the PC in general. I am using Visual C++ 6.0 as my compiler. I managed to get the code to compile and I can send data to an external device ( a serial lcd ). My problem is I cannot receive anything at all, nada, nothing, zilch. I'm using the same example read code as shown in the link. I get zero bytes read and if I do a COUT on the buffer it is not the data I should be receiving. NOTE: I can use hyperterminal and see the correct data being returned from the port. I know there are other forums for this kind of question but there are a lot of smart folks here.
Thanks

[mmormota]

Simply try another one. If that one is working - you are there... ;)
If not, then you have to deal with the uncomfortable details, like null terminal connection, RTS, DTS pin handling etc.
Another possible reason is that some hw interface cable is using the unused pins as power supply, and you have to set the pins to the proper states or the hw lacks power.

[Richard Ingram]

I know this is vague at the best. To simplify I can send data but cannot receive data. I can open the port no problem. The examples for send and receive in the link are the basis for the code (along with the rest of the class) that I'm using. Hoped some C guru might see something that I could work with. :)

[podavis]

???NOTE: I can use hyperterminal and see the correct data being returned from the port.???

Confusing... does this mean Hyperterminal is printing out data received by the port but your application is not?

[Richard Ingram]

That is correct. Hyperterminal sees the data from the port, so I know it's there. For some reason the application will not see the data. I checked the number of bytes read and it is zero. I do a cout (print to app) the buffer and it is not data that I expect ( all "=" ??). Could be something I am doing wrong. What is odd is that the send works fine. :confused:

[deh6]

I wrote a C++ class for the serial port some time ago (8 years?). It was written using Visual Studio 6.0. If you want to wrestle with it, I would be happy to send a complete app. The main reason I made the (supreme! I spent months on it) effort was to be able to send/receive *binary* data for a half duplex RS485 network I concocted for my home to communicate with micros driving such things as sprinklers, logging rainfall, etc. No garantees, but it has worked for me, though after a great deal of work, I concluded that a PC cannot deal with the RS485 xmit enable for half-duplex; the xmit enable has to be handled in the hardware since the op sys just can't handle the timing (a friend and I considered writing a special driver but that "little project" got pushed down the list).

[rant] The serial port stuff for the PC that has developed, especially with MS, is a total mess. Linux is not all that much better, though I found the documentation and examples a little more accessible than for Windows (98SE is what I was using at the time). The serial port hardware is simple. The software chaps, not understanding hardware, have managed to build layer upon layer of abstraction to try to get it to behave like a disk or tape drive. They managed to make something simple into something almost incomprehensible and poorly documented their effort. Even buying the few books that cover serial port programming on a PC there were a number of gaps that took a lot of experimenting and studying the VC++ help files to figure out.


Currently my preference for dealing with an MPU and PC is to use C on Linux, or even C on MSDOS(!) for an ancient laptop (yes it has storage--two 360K floppies--wow. Reads/displays MPU data just great and if I spill glow fuel on it and ruin it, the loss is inconsequential.)

[ezflyr]

Deh6,

With all due respect, there is nothing wrong with the PC serial port and Microsoft. I have been writing code for the PC from the days of DOS to the current versions of Windows, Vista. No problems, no issues, very robust and reliable.

Your contention that it's not well documented is also a bit off the mark. The PC serial port is probably one of the most mature, and well-documented, computer interfaces in existence. Buy a copy of "Serial Port Complete" as a start.

BTW, I write all my MCU/PC interface code in Visual Basic 6. The MSCOMM control makes it a truly trivial exercise.

John

[deh6]

As I remember (!) VBasic will not handle binary serial port data. The say they can but when I got into the details of what they do (did?) it was to send/rcv ascii hex data (requiring sending 2 bytes per byte of data) and called that binary. That's what got me digging into the bowels of it.

[GlowFly]

I've always found that most receive problems are caused by incorrect or incomplete setup of the DCB data. Pretty well all data items must be initialised. Obviously RTS, DTR handshaking but note that the number of stop bits value isn't value 1 or 2 but an index into an internal stop bit table. Also make sure you either disable else handle any error conditions otherwise the port may appear to fail for receiving.
--
Steve

[Richard Ingram]

If you want to wrestle with it, I would be happy to send a complete app.

deh6, I would like to see what you have there. Please email me the app ringram2077@charter.net . Thanks.

BTW, I write all my MCU/PC interface code in Visual Basic 6. The MSCOMM control makes it a truly trivial exercise.

I have written a simple form in VB6 that receives the data from the device perfectly. However I hoped to do the same with VC++ mainly just to see if I could. I ultimately want to make a stripchart app that will take in the values received and plot them in real time. I found C++ code that could be the basis for such an app.

Richard

[deh6]

Richard,

OK I'll dig it out and send it.

Glowfly is correct. Setting up the DCB is key.

I downloaded the code at the url you gave in the 1st post and skimmed through it. (It's been a number of years since I tinkered with it...)

As I remember I had a number of problems getting the read sorted out. I presume you have set up break points and nothing happens.

I dug out my MS book on serial communications for Windows. It shows the DCB layout (it's also can be found in the VC++ help files). The 'EofChar' couples with the 'fbinary' which is worth looking at (the wording in the book is not logically clear how it applies to WN95 onward, v WN31 (a rant item!). Depending on how the DCB is setup, an EOL char may or may not be required to trigger an event, and of course it has to be the one your MPU uses, assuming the scheme uses one.

Another arcane gotcha (which most likely wouldn't apply since Hyperterm is showing correct data) is that if the MPU is continuously sending data and the program on the PC is started, thus opening the port (8N1), and with certain chars from the MPU, the UART will synchronize midway in a char and remain that way until the data changes. There is this string of incorrect chars. If the MPU pauses between "lines" or characters then the receiving end gets back in synch. Until encountered it, I never had thought that it would happen (another one of those things not mentioned in the documentation.) Also with in the continous sending situation, there was time in the development of this "stuff" where during bootup Windows would think the serial port with the MPU was the mouse.

However I hoped to do the same with VC++ mainly just to see if I could Sorting out the serial comm with VC++ makes an interesting (and at times frustrating) project. I learned a lot about C++ and the Windows API sorting the serial stuff out.

[alexcmag]

Over windows, I use TPAPRO (Turbo Power Async Professional) library for my projects.

It was designed to Borland Delphi and C++ builder, but has ActiveX controls also, you can use from MS Visual C++ if you want.

I bought it to a project several years ago, but after that the company changed the goal and now it is open source library.

http://sourceforge.net/projects/tpapro/

[Richard Ingram]

Alex
I have downloaded the library and docs. I'll take a look at that soon. So far I have found C++ to be overwhelming as compared to Visual Basic. I'm not sure I will be able to grasp enough to make a project work, just awfully complex. I recently got the free downloads for Visual C++ and Visual Basic 2005 Express. Visual C# is also available along with others. C# looks interesting and similar to Visual Basic. I wonder if there is an advantage to VC# over VB ??

Thanks
Richard

[alexcmag]

Programming languages are quite like religion or favorite sports team, everyone has its own preferences.

Actually I don't like VB...

I worked several years with Borland Delphi, Microsoft VB6, Microsoft Visual C++, Borland Cbuilder, ASP, PHP and currently am starting a project in C#.

Almost every complex application written in VB I already worked needs some code in C++ when the things come harder.

The main reason is it appear to be easy, but when the project grows up there is always something VB can't do, so C++ gives a help and the project must remain in two different programming languages.

On the other side, Visual C++ can do almost everything, but some codes that are easy to write on VB, Delphi, Cbuilder and so on can need hundreds of lines in C++. The resulting code for a complex application is difficult to maintenance and tiny errors like using "if (a = 2)" instead of "if (a == 2)" can do a lot of mess.

I think C# is a way MS did to make things easier then VisualC++ and more powerfull then VB, and is a good product.

My oppinions:

VisualC++: too much hard work to make small things, even more work to do big things;

VB6: enough for most applications, but slow and has a very poor error handling;

VB.NET: they inproved code clarity and error handling and added "true" Object-Oriented Programming;

C#: a different flavour of java, much simpler to use then VisualC++ and more powerfull then VB, but I am starting with it iet because most projects I work are on older languages;

Delphi: my favorite, I worked with TurboPascal since 1980s and it was always a great compiler and language, powerfull and fast enough to work with complex hardwares but easy and organized enough to make complex applications. I bought Delphi1 at the week it was released and used most releases after that;

Borland Cbuilder: A C++ compiler that is easy to use. I use it when the project will use C++ code or libraries for specific hardwares, but otherwise I prefer Delphi, since the speed and power are the same but language sintax is more natural;

plain C: I use only on small devices like microcontrollers;