public inbox for ecos-discuss@sourceware.org
 help / color / mirror / Atom feed
From: Nick Garnett <nickg@ecoscentric.com>
To: "Transferencia de Archivos" <transfers@phaber.com>
Cc: ecos-discuss@sources.redhat.com
Subject: Re: [ECOS] at91eb40a Timer Counter
Date: Fri, 17 Oct 2003 09:32:00 -0000	[thread overview]
Message-ID: <m3brsg5j6f.fsf@miso.calivar.com> (raw)
In-Reply-To: <200310160401.h9G41fXk005039@dns.vitacom.net>

"Transferencia de Archivos" <transfers@phaber.com> writes:

> >eCos currently uses TC0 to implement its main system timer and TC2 to
> >implement a microsecond delay timer. You could probably disable the
> >latter, but disabling the system timer would only work if you have no
> >code that needs timing services of any sort. This is fairly rare, even
> > for very simple programs.  -- 
> >Nick Garnett                    eCos Kernel Architect
> >http://www.ecoscentric.com      The eCos and RedBoot experts
> 
> Thank you all, who answered my last message, and now I have other
> questions In fact I really need to get the maximum free
> timer-counters of the board, since I need a pretty fast measurement
> rate of signals.(PWM) Anyone knows, wich features are compromised
> disabling the microsecond timer?

In theory you can transfer the microsecond timer over to using the
same timer as the system clock. However, you will have to rewrite the
hal_delay_us() function in the HAL. An example of how to write the new
routine can be found in the i386 HAL.

> So the "clock ticks" I would expect
> from ecos in this case would be maximum the MCK/2 that TC0 supports?

I'm not sure what you are asking here. It is a bad idea to run the
system clock at too high a rate, since you would then swamp the CPU
with interrupts. 

> And a final question, since the Interrupt model that eCos uses as
> the documentation says, is based on the ARM model, should I expect
> that the interrupt model work would be transparent from ecos
> code?(On the AT91EB40a).
> 

eCos has its own interrupt architecture. This invoves decoding all
interrupt sources into their own ISR vectors by using the interrupt
controller. However, you can also access the underlying hardware
interrupt vectors if you really want to. However this is not
recommended.


-- 
Nick Garnett                    eCos Kernel Architect
http://www.ecoscentric.com      The eCos and RedBoot experts


-- 
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss

      reply	other threads:[~2003-10-17  9:32 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-10-16  4:01 Transferencia de Archivos
2003-10-17  9:32 ` Nick Garnett [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=m3brsg5j6f.fsf@miso.calivar.com \
    --to=nickg@ecoscentric.com \
    --cc=ecos-discuss@sources.redhat.com \
    --cc=transfers@phaber.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).