dopaready.blogg.se - Serial port library c

#SERIAL PORT LIBRARY C SERIAL#
#SERIAL PORT LIBRARY C MANUAL#
#SERIAL PORT LIBRARY C CODE#
#SERIAL PORT LIBRARY C WINDOWS#

#SERIAL PORT LIBRARY C MANUAL#

But I also recalled that even with the VC resource editor, manual GUI in Win32 API is a lot of work.

#SERIAL PORT LIBRARY C WINDOWS#

I recalled once again how much I like the Windows messages model (in contrast with Motif, for example).

My Win32 API experience got some exercise.

I learned a lot about threads (hadn't had much experience with them before, though it all turned out like I expected).

It's always nice to get "out of the PC" with your code.

#SERIAL PORT LIBRARY C SERIAL#

First of all that serial port programming is fun.

#SERIAL PORT LIBRARY C CODE#

I have a few more tests to do and when I'll put it on my website as GPL, like I do with all my code (the CSerial class is LGPL, by the way). It's sleek, fast, small and has more features. Usage of this class reduces both the amount of code to be written (I didn't have to implement threading code manually like in Perl), and the development time.Īll in all, the shiny new COM Monitor works a treat. My code is simple waiting on these messages and taking care of them when they arrive. It opens a thread listening on a port, and just sends me normal windows messages whenever it gets data. For my cause, the CSerialWnd wrapper was just perfect. It is as if its author anticipated all the common uses for the class and implemented them in a convenient way. It is cleverly designed (actually it's a family of classes), well documented, very intuitive (so the docs aren't really needed) and provides just the things the programmer needs. Google brought up the CSerial class immediately, and this was the beginning of a great friendship. While most of my Perl prototype development time was spent struggling with the terrible Win32::SerialPort module, I had much more luck in C++.

The second implementation built heavily on the expertise gained from the first (the prototype).Ĭode size wise - Visual Studio's resource dialog/menu builder saves quite some code.īut most important - the library I used. Now, this would be too surprising (C++ comparable in code size and coding time with Perl ?!?!), but there are some small details that complete the picture and make it more bearable.ĭevelopment time wise - I gained a lot of experience from the Perl implementation - I never made so complex a multi-threaded app, and I never worked so seriously with serial ports. Best of all - the executable takes 120K (compared to the 3MB of PARed Perl).It works fully satisfactorily - both error-handling wise (which is terrific), and speed wise (much faster and sleeker than the Perl version).It weighs ~1200 LOC (comparable to the Perl version).It took 3 days to develop (comparable to the Perl version).The results of this endeavor are well beyond my expectations: In short, I really like the way Windows GUIs are built, and find the message pump model very intuitive Plus, I have Petzold's excellent Windows Programming book, which makes things quite simple. My relationship with the Win32 API has some roots, and it's not a place to delve too deep into it (I'll dedicate some posts to it in the future). So, driven by a need for such a monitor of high quality (answering the very specific requirements I mentioned in a previous post) I fired up my old'n'dusty Win32 API skills and decided to rewrite the thing in C++. As I mentioned, I was quite dissapointed with my Perl implementation of the serial port monitor - mostly because of the extremely kludgy Win32::SerialPort library (that is the only option for Perl serial port interfacing at the moment).