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:

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

    Rafael>   The problem of associating an alarm is that I should use
    Rafael> a frecuency of 25 kHz or 44 kHz, and that means that every
    Rafael> time that a timer IRQ occurs, the ISR and DSR of the rtc
    Rafael> will be launched and that's a comuputational overhead that
    Rafael> should only be done at a 100Hz rate.

Just read your original message more carefully.

OK, you are expecting to transfer data to the sound hardware at 25kHz,
which means one item of data every 40 microseconds, without DMA. With
typical embedded processors that would involve a fairly tight polling
loop. With a 500MHz processor it should be possible to do it via
interrupts, but a large proportion of cpu time will be spent servicing
these interrupts. I would try to get DMA to the soundcard working
somehow. A good source of information on hardware details would be the
Linux kernel sources, although obviously copying code directly from
those has licensing implications.

If you must do it via interrupts, stealing the clock interrupt vector
after eCos has set up its clock handler and then arranging for the
eCos clock dsr to be called every 250 interrupts should work. However
it is ugly and essentially a workaround for inadequate hardware that
needs very high frequency interrupts but does not provide enough
clocks. I do not think any general-purpose solution is warranted here.

    <snip>

    Rafael> By the way, I'm working with eCos 1.3.1. Has the RTC
    Rafael> changed since then?

The PC-related HAL packages received a major clean-up last Summer, use
anoncvs to get the updates. There may have been some changes to the
implementation of the RTC, but the behaviour should be the same.

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]