public inbox for ecos-discuss@sourceware.org
 help / color / mirror / Atom feed
* [ECOS] delay function
@ 2001-02-06 20:15 Natarajan, Mekala (CTS)
  2001-02-07  2:45 ` Jesper Skov
  0 siblings, 1 reply; 2+ messages in thread
From: Natarajan, Mekala (CTS) @ 2001-02-06 20:15 UTC (permalink / raw)
  To: 'ecos-discuss@sources.redhat.com'

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 2250 bytes --]

> Hi Jesper,
>     In the below mail u have asked to use the us delay function for busy
> wait..Can u kindly tell which 
> ecos API to use.
> 
> regards,
> mekala
> 
> -----Original Message-----
> From:	Jesper Skov [SMTP:jskov@redhat.com]
> Sent:	Tuesday, January 16, 2001 6:21 PM
> To:	Pamulapati, Indrasena (CTS)
> Cc:	Jesper Skov; ecos-discuss@sources.redhat.com
> Subject:	RE: [ECOS] Suitability of eCos
> 
> >>>>> "Pamulapati," == Pamulapati, Indrasena (CTS)
> <pindrase@chn.cognizant.com> writes:
> 
> Pamulapati,> Hi Jesper, Yes, the tick duaration controls the kernel
> Pamulapati,> scheduler and I dont need scheduling at that rate.  But
> Pamulapati,> does'nt the tick duration also determine the smallest
> Pamulapati,> addressable time unit.  What i mean is:
> 
> Pamulapati,> Let us consider the duration of a tick to be a reasonable
> Pamulapati,> value of 10millisec.  Now, if I want to send some data
> Pamulapati,> at, say 20ms from the start of a reference point, I will
> Pamulapati,> give a delay of 2ticks from the reference point and as u
> Pamulapati,> mentioned send an interrupt to the driver after 2ticks.
> 
> If you want to busywait, use the uS delay function instead.
> 
> But as Björn Stenberg pointed out, you probably want a high-speed
> timer to driver things instead of relying on the kernel scheduler
> timer.
> 
> Pamulapati,> Jesper, actually I am quite a newbie wrt drivers and
> Pamulapati,> rtos's.  Can you elaborate on "Drivers doing IO should be
> Pamulapati,> driven separately, relying on device interrupts, not
> Pamulapati,> scheduler interrupts, for state transitions." based on
> Pamulapati,> the problem I mentioned above. I guess this may solve my
> Pamulapati,> problem.
>  
> 

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

^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: [ECOS] delay function
  2001-02-06 20:15 [ECOS] delay function Natarajan, Mekala (CTS)
@ 2001-02-07  2:45 ` Jesper Skov
  0 siblings, 0 replies; 2+ messages in thread
From: Jesper Skov @ 2001-02-07  2:45 UTC (permalink / raw)
  To: ecos-discuss

>>>>> "Natarajan," == Natarajan, Mekala (CTS)
      <NMekala@chn.cognizant.com> writes:

>> Hi Jesper, In the below mail u have asked to use the us delay
>> function for busy wait..Can u kindly tell which ecos API to use.

It's a HAL function, available if HAL_DELAY_US is defined. It may not
be defined by all HALs, but I think it is by now.

Jesper

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2001-02-07  2:45 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2001-02-06 20:15 [ECOS] delay function Natarajan, Mekala (CTS)
2001-02-07  2:45 ` Jesper Skov

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