public inbox for ecos-discuss@sourceware.org
 help / color / mirror / Atom feed
From: "Pamulapati, Indrasena (CTS)" <pindrase@chn.cognizant.com>
To: Jesper Skov <jskov@redhat.com>
Cc: ecos-discuss@sources.redhat.com
Subject: RE: [ECOS] Suitability of eCos
Date: Tue, 16 Jan 2001 11:08:00 -0000	[thread overview]
Message-ID: <8F1D166D08ACD41196EE00B0D020944B82983A@CTSINENTSXUB> (raw)

Hi Jesper,

Yes, the tick duaration controls the kernel scheduler and I dont need
scheduling at that rate.
But does'nt the tick duration also determine the smallest addressable time
unit.
What i mean is:

Let us consider the duration of a tick to be a reasonable value of
10millisec.
Now, if I want to send some data at, say 20ms from the start of a reference
point,
I will give a delay of 2ticks from the reference point and as u mentioned
send an interrupt to the driver after 2ticks.

Now, what if I want to send the data after 1 ms from the reference point. I
will not be able to specify the number of ticks I have to wait if tick
duration is 10ms. So what I thought was, I can decrease the tick duration to
less that 1ms, say 0.5ms and give a delay of 2ticks and then send the
interrupt. But this I guess will adversly affect the performance of the
system.

Jesper, actually I am quite a newbie wrt drivers and rtos's.
	Can you elaborate on
	 "Drivers doing IO should be driven separately, relying on device
interrupts, not scheduler interrupts, for state transitions." based on the
problem I mentioned above. I guess this may solve my problem.
 
Regards,
Indrasena

  

> -----Original Message-----
> From:	Jesper Skov [SMTP:jskov@redhat.com]
> Sent:	Tuesday, January 16, 2001 4:14 PM
> To:	Pamulapati, Indrasena (CTS)
> Cc:	ecos-discuss@sources.redhat.com
> Subject:	Re: [ECOS] Suitability of eCos
> 
> >>>>> "Pamulapati," == Pamulapati, Indrasena (CTS)
> <pindrase@chn.cognizant.com> writes:
> 
> Pamulapati,> the overhead involved in processing the tick.  But my
> Pamulapati,> application requires tick duration as low as a
> Pamulapati,> 100microseconds. I need to address such low time
> Pamulapati,> resolutions.
> 
> As Ramana pointed out, the tick duration controls little more than
> the kernel scheduler in eCos. Surely you don't need thread scheduling
> at that rate!?!
> 
> Drivers doing IO should be driven separately, relying on device
> interrupts, not scheduler interrupts, for state transitions.
> 
> But without further information about your application my comments
> above are just guesses and may not actually apply...
> 
> Jesper

This e-mail and any files transmitted with it are for the sole use of the intended recipient(s) and may contain confidential and privileged information.
If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. 
Any unauthorised review, use, disclosure, dissemination, forwarding, printing or copying of this email or any action taken in reliance on this e-mail is strictly 
prohibited and may be unlawful.

		Visit us at http://www.cognizant.com

             reply	other threads:[~2001-01-16 11:08 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-01-16 11:08 Pamulapati, Indrasena (CTS) [this message]
2001-01-16  4:52 ` Jesper Skov
2001-01-16 11:26 ` Grant Edwards
  -- strict thread matches above, loose matches on Subject: below --
2001-01-16  7:52 James Dabbs
2001-01-16  4:07 Stenberg Björn
2001-01-16  1:52 Pamulapati, Indrasena (CTS)
2001-01-16  2:44 ` Jesper Skov
2001-01-16  7:27 ` Grant Edwards
2001-01-16  1:27 Ramana
2001-01-16  1:10 Pamulapati, Indrasena (CTS)

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=8F1D166D08ACD41196EE00B0D020944B82983A@CTSINENTSXUB \
    --to=pindrase@chn.cognizant.com \
    --cc=ecos-discuss@sources.redhat.com \
    --cc=jskov@redhat.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).