Programming

First off, the target system is FreeBSD 6.x on an old AMD K6 333. I know C++ but I wouldn't consider myself a programmer. (Haven't written a line since college.)

Anyway, I want to write a program to allow me to pan and tilt a webcam or to simply send a signal from a serial port to a relay switch in a diagram I found.

I found a program written in C that is pretty close to what I'm wanting to do, but the only problem is it's using...

#include <asm/io.h>
#include <libio.h>

Here's a link to this program and diagram of switch.
http://axlebath.net/rccar.txt

These headers don't appear to be installed on my system. I'm assuming this program was written for a LINUX system.

MY QUESTION...
1. Any idea on how to do this using C++?
2. Knowing full well I need to know what I'm doing to accomplish this, is there a good reference guide, tutorial, and/or set of examples to help me understand termios programming; especially in respect of interfacing with a serial port?
3. Does anyone have any tips to point me into the right direction?

Thanks in advance for your help...

Drop any linux or assembly bits, you should not need them.

cfmakeraw() is useful API, makes sure you don't have a terminal discipline enabled on the port....

otherwise, just make sure you set the baud rate, characters bits, parity and stop, and set the file descriptor to blocking or nonblocking as per your whim.

I just finished re-writing a cctv utility that does the whole ptz thing. The first cut was a trivial C utility. I built a C++ architecture that does the same thing, but it does it reliably. It is also very extensible, maintainable, flexible, self documenting, supplemented with srs and design docs, and is specialized at three levels to provide a solid foundation.

So, the first thing that I did was to set up a couple libraries. The first one is just a grab bag of basic tools. The second, a set of parameterized classes that provide stream specializations. These not only can work on every platform (with necessary specializations), but can be adapted to different types of com devices. The third library set up an abstract architecture to facilitate stream interactions. The final utility is a specialization of the abstract architecture, and defines specifically how to interact with the target device.

So, all of the generic work is handled using generic stuff. All the specializations are handled in the user code.

-Jmt

I am wanting to keep it fairly simple. I don't need any kind of GUI, at least at this point....you know, one step at a time.

At this point I'm still trying to figure out details how things in this subject work. I'm trying to figure out the "Hello World" stage, so to speak.

Is there some kind of reference that would be more helpful than man pages?

Serial Programming Guide for POSIX Operating Systems - Michael R Sweet

http://www.lafn.org/~dave/linux/Seri...ming-HOWTO.txt

It's amazing what you can come up with in two minutes using google these days.

I've been googling a lot in the past week. The big part of the problem is I not sure what exactly to look for and if I'm looking at anything relevant.

Thanks for the links; the HOWTO step by step explanation will be helpful and should allow me to learn things.

My only concern is they're directed to LINUX systems. How I understand it, as far as serial comm programming, there are some differences between LINUX and BSD systems.

mikes serial device resources look really good.

The way I look at it, the most important thing to consider is that the device may not do what you think it will. The utility needs to have a way of checking to see if it did what you asked it to do. It needs to be patient, the clock on your target device is not in sync with your cpu, so don't expect it to respond, just check, and patiently wait 'till it says it did what you asked it to do, then let your program continue on to the next command. If it never does what you asked it to do, request a heartbeat response, there might be a com problem, or the device may be busy or dead, when you get a response, you've got to be able to issue the command that failed again (and you might have to send re-init sequences before you can do that right).

It makes good sense to start with some libraries that already do approximately what you want to do, then refine, maintain and extend 'till it does exactly what you want.