This is the mail archive of the ecos-discuss@sources.redhat.com mailing list for the eCos project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: eCos and PC timer


>>>>> "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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]