From owner-freebsd-questions@FreeBSD.ORG Wed Aug 6 09:54:22 2003 Return-Path: Delivered-To: freebsd-questions@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4A0B337B401 for ; Wed, 6 Aug 2003 09:54:22 -0700 (PDT) Received: from sccrmhc12.comcast.net (sccrmhc12.comcast.net [204.127.202.56]) by mx1.FreeBSD.org (Postfix) with ESMTP id 82AF243F75 for ; Wed, 6 Aug 2003 09:54:21 -0700 (PDT) (envelope-from jshamlet@comcast.net) Received: from [192.168.1.1] (pcp04633217pcs.gambrl01.md.comcast.net[68.49.68.116](untrusted sender)) by comcast.net (sccrmhc12) with SMTP id <2003080616541701200hea8oe>; Wed, 6 Aug 2003 16:54:17 +0000 From: "J. Seth Henry" To: Malcolm Kay In-Reply-To: <200308062328.38914.malcolm.kay@internode.on.net> References: <1060119004.53095.25.camel@alexandria> <200308062328.38914.malcolm.kay@internode.on.net> Content-Type: text/plain Organization: Message-Id: <1060188850.55262.12.camel@alexandria> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 06 Aug 2003 12:54:12 -0400 Content-Transfer-Encoding: 7bit cc: freebsd-questions@freebsd.org Subject: Re: FreeBSD programming question X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Aug 2003 16:54:22 -0000 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 >