It appears that my experience on microcontrollers is throwing me off.
I'm used to having a touch more control at the hardware level.

It sounds like I would be best served by setting up a loop that sleeps
for a certain number of milliseconds, and then looks for new data in the
serial port buffers. Knowing the amount of time per loop, I could handle
the periodic data polling as well. My largest concern was in creating a
CPU hog. I don't want to slow the system down by constantly accessing
the serial port.

It occurred to me that I may be able to deal with this another way. I
can poll the thermostat for MOST things, only the user interface
requires fairly speedy interactions. I can simply listen for the "ENTER"
button, and then increase the polling rate until the UI exits.

As it were, I'm poking around in the ports to see how other programs
have dealt with this.

Just out of curiousity, since I can check the driver source, does the
sio driver add any additional buffering, or does it simply read the
16byte FIFO on the serial port? Most of the messages I am expecting
should fit in that FIFO anyway.

Thanks,
Seth Henry

On Wed, 2003-08-06 at 09:58, Malcolm Kay wrote:
> On Wed, 6 Aug 2003 07:00, J. Seth Henry wrote:
> > Not sure if this is the right list or not, but I could really use some
> > pointers.
> >
> > How can I code trap serial port interrupts in my C program?
> >
> 
> For any modern hosted system interrupt trapping and servicing is in the 
> province of the system -- it should not be a userland activity.
> 
> > For example, I want to read values from a serial device every
> > user-specified number of seconds, calculate some stuff and then sit for
> > a while. Should the serial device decide it wants to send some data
> > unsolicited, I would like to enter an interrupt service routine, handle
> > the communication, and then return to the previous loop.
> 
> There are a number of techniques which may or may not suit your needs;
> it is not too clear just what you are trying to do.
> 
> Generally the system will provide some buffering of input so it is not usually
> important that your code processes each character immediately on arrival.
> 
> In many cases using placing the select(2) system call in a loop will meet the 
> needs.
> 
> In more difficult cases you may need to look at threading pthread(3) or 
> forking fork(2) or vfork(2)
> 
> >
> > I can get the loop going by using sleep(n), but I don't know how to
> > write the ISR in C, and (additionally) make it such that it will run on
> > any *nix like platform.
> 
> You might be able to do something at system level by adding your driver to the 
> kernel possibly as a kernel module. This is not generally the way to go if 
> userland alternatives work and it certainly will be very operating system and 
> platform specific possibly even requiring significant editing from one OS 
> version to the next.
> 
> >
> > Any pointers, HOWTO's, or examples would be greatly appreciated!
> >
> > Thanks,
> > Seth
> >
> 
> Malcolm Kay
> 

_______________________________________________
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Reply via email to