This is the mail archive of the
ecos-discuss@sources.redhat.com
mailing list for the eCos project.
Re: eCos and PC timer
- From: Bart Veer <bartv at redhat dot com>
- To: rrv at tid dot es
- Cc: ecos-discuss at sources dot redhat dot com
- Date: Thu, 4 Apr 2002 15:00:23 +0100
- Subject: Re: [ECOS] eCos and PC timer
- References: <3CAC5369.C7545D99@tid.es>
- Reply-to: bartv at redhat dot com
>>>>> "Rafael" == Rafael =?iso-8859-1?Q?Rodr=EDguez?= Velilla <Rafael> writes:
Rafael> I'm not very familiar with the hardware of PCs, but I
Rafael> think that there is only one timer available for all the
Rafael> system. I wanted to process a sampled sound from my
Rafael> SoundBlaster in real time, so the only solution that I
Rafael> found was programming the Sound Blaster to sample the
Rafael> sound automatically and transfer it to the memory, and
Rafael> using a peridicall interrupt to process the sounfd and
Rafael> transfer it to the speakers (I don't know how to program a
Rafael> second DMA buffer to transfer the processed sound to the
Rafael> output of the Sound blaster). The problem is that there's
Rafael> only a timer available, and eCos uses it, so I was going
Rafael> to extend the RTC routines to fit my pourposes while
Rafael> keeping the functionality that eCos expects from the
Rafael> timer. My idea is to add a function that allows the user
Rafael> to program the timer to produce an interrupt after the
Rafael> desired time, this IRQ throws the programmed handler. The
Rafael> function should be clever enough to throw the RTC's ISR
Rafael> and DSR only when necessary.
I believe a PC actually has several different counters, but only one
of these is hooked up to the interrupt subsystem and hence that one is
used for the eCos clock.
But why not set up an alarm function using cyg_alarm_create() etc?
That alarm function will then be called by the system every clock
tick, or every n clock ticks, as required, and it can manipulate the
soundblaster hardware as required. The alarm function will run in DSR
context. The only real problem here is clock resolution: the default
resolution of one tick every 10ms may not be fast enough for your
needs. You can configure the clock to run faster, but obviously that
means more clock interrupts so more overhead.
Bart
--
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss