From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28508 invoked by alias); 26 Sep 2003 06:37:15 -0000 Mailing-List: contact ecos-discuss-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: ecos-discuss-owner@sources.redhat.com Received: (qmail 28468 invoked from network); 26 Sep 2003 06:37:13 -0000 Received: from unknown (HELO mail.idtinc.de) (195.30.47.34) by sources.redhat.com with SMTP; 26 Sep 2003 06:37:13 -0000 Received: from DynaPel.com (unknown [10.0.2.109]) by mail.idtinc.de (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id D823F1850F; Fri, 26 Sep 2003 08:37:51 +0200 (CEST) Message-ID: <3F73DEC3.1000801@DynaPel.com> Date: Fri, 26 Sep 2003 06:37:00 -0000 From: Eric Doenges User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030626 X-Accept-Language: en-us, en MIME-Version: 1.0 To: eibach@gdsys.de Cc: ecos-discuss@sources.redhat.com References: In-Reply-To: X-Enigmail-Version: 0.76.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [ECOS] 1ms polling period X-SW-Source: 2003-09/txt/msg00477.txt.bz2 eibach@gdsys.de wrote: > I have to do some hardware polling every 1-5 ms. > What is the best way to do that in ecos? > Using the system clock there is only a minimum 10ms period available. > I wouldn't like modifying the system clock, but is that the only way > to do it? Or should I manually use a hardware timer in my controller > to generate an interrupt every 1ms? (My basic hardware is the ATMEL EB40A.) > Or is there maybe a completely different way to do this? > Any ideas you have about this are appreciated. I would say that depends on a number of things. If the overhead of eCos system timer interrupts is not much larger than a normal interrupt, then changing the system clock period is probably the easiest way to go since you can use all the normal eCos timer functionality. Another question is the required accuracy of your polling. If you use a 1ms clock interrupt, your timing will be off by up to +/- 1ms (you can probably disregard interrupt and thread switch latency in this case). In a previous application, I had to poll the UART of a 16MHz 68332 periodically with an accuracy of 5 microseconds. The solution was to request a timer interrupt sufficiently before ("sufficiently before" was determined empirically by measuring the interrupt and thread switching latency and adding a large safety factor) the actual polling time, and then poll the hardware timer in the highest priority thread (with interrupts disabled) until the exact time was reached. Pretty ugly, but it worked. Obviously, such an approach will suck up a lot of the available processing resources of your CPU, so depending on how much other work your application needs to do this may not be workable. -- -------------------------------------------------------------------- | Eric Doenges | DynaPel Laboratories GmbH | | Tel: +49 89 962428 23 | Fraunhoferstrasse 9/2 | | Fax: +49 89 962428 90 | D - 85737 Ismaning, Germany | -------------------------------------------------------------------- -- Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos and search the list archive: http://sources.redhat.com/ml/ecos-discuss