Date: Fri, 12 Jan 2001 13:56:05 -0600 From: Steve Price <sprice@hiwaay.net> To: Dan Nelson <dnelson@emsphone.com> Cc: hackers@FreeBSD.ORG Subject: Re: synchronous IO Message-ID: <20010112135605.J36120@bonsai.knology.net> In-Reply-To: <20010111214449.A26983@dan.emsphone.com>; from dnelson@emsphone.com on Thu, Jan 11, 2001 at 09:44:49PM -0600 References: <20010111202855.Y36120@bonsai.knology.net> <20010111214449.A26983@dan.emsphone.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, Jan 11, 2001 at 09:44:49PM -0600, Dan Nelson wrote:
# I don't think you really mean synchronous IO; All you need is some
# buffering. If the toggling you're talking about is direct wave
# generation (i.e. you have to do something for each byte in the sample),
# your time restrictions are probably tight enough that you'll want
# multiple buffers, filled by one process and drained by another one.
# You mmap() some shared buffer space, fork your process into two, and
# send buffer status messages over a pipe connecting the two. Process 1:
# read a block of data from input file, fill an empty buffer, send the
# buffer address over the pipe, repeat. Process 2: read a full buffer,
# toggle buffer through the serial port, send the address of the buffer
# back over the pipe for reuse. This ensures that the only operations P2
# does apart from waveform generation are a select, two reads, and a
# write every sizeof(buffer). You could even toss the pipe and use
# another bit of shared memory to keep track of buffer usage.
#
# If, on the other hand, the toggling merely tells the controller to play
# a sample that you have already stored in the device's memory, then you
# presumably have looser timing requirements and can get away with having
# one process drain and fill the buffers as appropriate. This is similar
# to how the kernel's soundcard drivers work; most soundcards read system
# memory directly and signal the kernel via interrupts when its buffers
# are getting empty.
Thanks for the info. I don't think I was very clear in my first
explanation. I have an RF transmitter that I control via a serial
port on a FreeBSD box. I also have a sound card in that same
computer connected to the transmitter. I'm sending commands to
the transmitter in a sequence that looks like this.
DIGITAL_BURST (commands sent via serial port)
AUDIO (.wav files being played by the computer)
TEXT_ECHO (text to display on the radio)
I use DTR and RTS to control a set of relays in the transmitter to
select which source of data to broadcast to the radios. I set the
bits appropriately and I send the digital burst via the serial port.
I need to make sure all of these bits have made it to the controller
before I reset the bits to tell the transmitter to start sending
the WAV file I'm playing on the computer. In the same respect I
need to know when all of the sound data is completely sent so that
I can put the controller back in serial IO mode and transmit the
text to display on the radio.
I don't have control over the message format nor can I change
anything inside the transmitter. I only have control over the
software that runs on the computer. This is why I believe I need
something like synchronous IO. How would I otherwise know when
all the data from one phase has been transmitted and I can go on
to the next step? Currently the code is riddled with a bunch of
nanosleeps that do their best to estimate how long it takes to
transmit the data. This is kludgy at best and not very accurate
because it depends on the load of the box and a bunch of other
factors. I end up having to pad the times a bunch to try and cover
all the possible things that could cause my rough-order transmission
times to be missed.
-steve
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20010112135605.J36120>