![]() |
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.
|
Its in the White Papers section now.
[attachment removed to save database space] :) |
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.
|
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?
|
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... |
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!
|
Quote:
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. |
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. |
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? |
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 |
Quote:
Quote:
Quote:
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. |
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 :) |
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. |
Quote:
Quote:
|
Quote:
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