Chief Delphi

Chief Delphi (http://www.chiefdelphi.com/forums/index.php)
-   Programming (http://www.chiefdelphi.com/forums/forumdisplay.php?f=51)
-   -   Serial Port Communication White Paper (http://www.chiefdelphi.com/forums/showthread.php?t=4574)

rbayer 03-06-2002 23:04

Serial Port Communication White Paper
 
While I wait for my white paper to be officially added to the white papers section, I'll post it here for your enjoyment. PLEASE send me comments/suggestions. This is still a first draft, so I'm always looking for ways to improve it.

Brandon Martus 03-06-2002 23:32

Its in the White Papers section now.
[attachment removed to save database space] :)

Ian W. 04-06-2002 16:50

is the white paper written for C instead of C++? cause looking at some of the things in there, they have C++ functions, but by different names, so i wasn't sure what you were using.

DanL 04-06-2002 18:34

hmm, can you explain the concept of a thread? I haven't really gotten that far in my C++ expierience. Sounds like it's basically an area for Windows to execute commands and can execute them independent of other threads?

Ian W. 04-06-2002 19:22

from what i can gather, yes, a thread is an executor, of code that is :D. i'm guessing that a thread is the part that runs down the code interpereting the code, and then running it. hence, if you're stuck in an infinite loop, there is no way you can go to something outside of that loop.

i'm still confused about some of the commands, and how they work though...

VanWEric 04-06-2002 20:21

Threads?
 
I have no solid idea what a thread is, but i thought it was like another program running at the same time. IE freecell and winamp are running at the same time. both are in infinite loops (until they quit) but they both work because the processor looks at one program and then the other -- they are independant. I think a multi threaded program has two peices running independantly of eachother, but the look at eachothers stuff, so that a time dependant communication device or sound device is not screwed over by other processes. of course, i am prolly way off here. THis sounds like a job for MEGA ROBOT DUDE!

rbayer 04-06-2002 20:40

Quote:

they both work because the processor looks at one program and then the other -- they are independant.
That is exactly correct. Basically, you can think of this as two programs running concurently. One of them deals with all the user interface stuff (mouse clicks, menu selection, displaying text, etc), while the other one ONLY talks to the serial port. This child process, to use the official name, would also deal with getting the data to the user interface. Far and away the easiest way of doing this is through a global variable.

In my Linux dashboard viewer, for example, all data is stored in a global struct called gRoboData. It is of type RoboData, which is basically just a struct with a variable to store each byte in. The regular part of the program then keeps reading this struct over-and-over again and updating the display as needed.

While this may seem like an overly complicated way of doing things, trust me. It is FAR easier than dealing with non-overlapped I/O.

As for whether this is C or C++, the distinction between the two is very fine. Basically, the way I chose to do multithreading is the C way of doing it. Other than that, all the code could be used under either language. I chose C for the multithreading because using the CThread class and MFC often induces more headaches than its worth.

Ian W. 04-06-2002 21:12

the thing that me and dan are doing doesn't use MFC, mostly cause we don't know that yet ;).

we're planning on developing a console app that runs in an infinite loop, that grabs the bytes from the serial port, then outputs them to various files. from that, a flash program, also running in an infinite loop, picks up these variables from the text file, and outputs them to a nice, pretty GUI. sure, it's super inefficent, but what the hell do i care? also, yes, it's only for my team, and has to be redesigned every year (the flash part at least). i like the way we're doing it though, because it's a creative solution to a problem.

anyways, all that i need is a mini program that grabs the variables, then just writes them all out to various text files. to do this, i really only need one loop. so, would i not need multithreading to do this, right? all that i need is a simple program that will try to open the com port, and if that works, start transmitting. after the transmission ends (program is closed), the com port must be closed, and then that's all that the C++ program has to do.

if i do need mutliple threads, then i guess i would follow the white paper exactly, and then just do a simple other program to write to the text files. i'm not sure exactly how i would do that, but i have all summer.

so, if someone could tell me whether or not i need mutiple threads? thanks.

rbayer 04-06-2002 21:26

Despite what it may seem like, you still do need multithreading. Without it, there will be no way to quit the serial capture program. Although, if it is a console app, you should still be able to ctrl+C it. It may lead to some minor memory leaks, but no big deal.

Anyway, the way you are describing doing this is fairly simple. In the SerialThread function, where I said to do the data processing, just sort through the twenty-six bytes it reads in, looking for the begining. Once it finds the begining of a packet, start writing out each byte to a file. You can even do this while inside the SerialThread function.

BTW, what compiler will you be using?

Ian W. 04-06-2002 22:14

i only know VC++, i think version 6.0, cause that's what i use at school, and what i have at home.

so the serial capture thing is always running, and while it's running, i can't execute any other commands in that thread, is what you're saying? i guess that makes sense, although, it makes everything harder :p.

and for memory leaks, i really don't care, cause i'll be running the program on a school computer (yes, we actually have a laptop from the school :D). the only reason i'm never gona run it on mine is that i'm never going to have a OI/RC in my house, a bit too expensive :D, unless someone makes an OI/RC emulator, as i've heard some talk about.

i'm going to be working on this in computer science, cause i have no more work :p. now i can play outsmart the teacher. i wonder if he knows about multithreading... :D

rbayer 04-06-2002 22:40

Quote:

i only know VC++, i think version 6.0, cause that's what i use at school, and what i have at home.
Good. VC++ 6 is probably the best compiler out there. Personally, I use professional edition (gotta love academic licensing), but the commands I gave in the white paper should work for all versions.


Quote:

i can't execute any other commands in that thread
somewhat. Basically, while the ReadFile function is being called, you can't do anything. If the serial cable becomes disconnected, the ReadFile function will never return, so you won't be able to do anything. Under normal operation, it will return immediately after reading the 26 bytes, so you can just put the processing code right there.


Quote:

and for memory leaks, i really don't care
OK, I guess. just make sure you restart the laptop periodically so you don't end up with a wonderful BSOD.


As for the OI/RC emulator, that was me talking about doing it and yes, I am currently working on it. I'm about halfway through the PBASIC interpreter, and the rest of it is just trivial UI stuff. I've been sidetracked by my automatic program generator though.

Dave Flowerday 05-06-2002 10:19

Just a note to add to this conversation: if you kill a program with Ctrl-C or similar, you won't really leak any memory. Memory leakage is a problem that can only occur when a program is running. This is because any dynamically allocated memory that the program requests during execution is allocated on the program's heap. When you kill the program, the operating system frees the program's heap space, which includes any dynamically allocated memory that you forgot to free in the program.

I also have to take issue with the statement that "VC++ 6 is probably the best compiler out there" but I won't get into that right now :)

rbayer 05-06-2002 11:04

Yeah, yeah, I knew that statement would get me in trouble. How about this: it is the best supported windows compiler out there. As soon as gcc gets all the point and click UI stuff that VC++ has, I will switch in a second. For now, I'm sticking with VC.

With the way windows does handles, it is still possible to have resources allocated after a program quits. While traditional new/delete statements will be freed, there are some weird instances where a program won't free all its handles. As an example, watch your free resource % in the performance tab. The more programs you have run, the lower this number gets, even if you quit programs the "nice" way. Basically, Windows sucks at memory management, and we as programmers need to give it all the help it can get.

Dave Flowerday 05-06-2002 11:49

Quote:

How about this: it is the best supported windows compiler out there. As soon as gcc gets all the point and click UI stuff that VC++ has, I will switch in a second.
I thought you were talking about the compiler itself being the best compiler, which I have problems with because the Visual C++ compiler has issues with standards compliance. As for the GUI, there are several nice ones that work on top of GCC. GCC itself is just a compiler, just like the command line compiler that's part of VC++. Personally, one of the biggest benefits for me with GCC or other compilers is that I don't have to use the bloated user interface. I greatly prefer the ease of use and flexibility of a good editor (nedit) and Makefiles coupled with a command line, but that's just me.
Quote:

With the way windows does handles, it is still possible to have resources allocated after a program quits.
If this is true then that sounds like (yet another) Windows bug. (I can't say that I know much about Windows GUI programming; I try to avoid Windows as much as possible.) A true OS would never allow a user process to allocate memory that can never be recovered, no matter how the application is terminated.

rbayer 05-06-2002 11:59

Quote:

A true OS would never allow a user process to allocate memory that can never be recovered, no matter how the application is terminated.
A true OS would also have a decent file permission structure, but then again, Windows isn't a real OS... And that's why I use Linux for any real work. As soon as it becomes possible to compile Windows programs in Linux, I'm making the switch entirely. Even now, most of my personal programming stuff is for Linux (gDash , file converters, math homework helpers, etc).

BTW, do you have the names of any good GUI front ends to gcc? I use glade for Gnome/GTK+, but I haven't found the Windows equivalent.


All times are GMT -5. The time now is 01:37.

Powered by vBulletin® Version 3.6.4
Copyright ©2000 - 2017, Jelsoft Enterprises Ltd.
Copyright © Chief Delphi