From owner-freebsd-hackers Sun Sep 30 11:58:50 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from srv1.cosmo-project.de (srv1.cosmo-project.de [213.83.6.106]) by hub.freebsd.org (Postfix) with ESMTP id 588DD37B405 for ; Sun, 30 Sep 2001 11:58:44 -0700 (PDT) Received: from mail.cicely.de (cicely20 [10.1.1.22]) by srv1.cosmo-project.de (8.11.0/8.11.0) with ESMTP id f8UIwY634939; Sun, 30 Sep 2001 20:58:36 +0200 (CEST) Received: (from ticso@localhost) by mail.cicely.de (8.11.0/8.11.0) id f8UIx0K20023; Sun, 30 Sep 2001 20:59:00 +0200 (CEST) Date: Sun, 30 Sep 2001 20:58:59 +0200 From: Bernd Walter To: Bart Kus Cc: Bernd Walter , hackers@FreeBSD.ORG Subject: Re: precise timing Message-ID: <20010930205859.A19910@cicely20.cicely.de> References: <200109301010.07784@EO> <20010930180302.A19621@cicely20.cicely.de> <200109301303.08611@EO> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200109301303.08611@EO>; from bsd@shell-server.com on Sun, Sep 30, 2001 at 01:10:35PM -0500 X-Operating-System: NetBSD cicely20.cicely.de 1.5 sparc Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Sun, Sep 30, 2001 at 01:10:35PM -0500, Bart Kus wrote: > On Sunday 30 September 2001 11:03, Bernd Walter wrote: > > Controlling steppers via lpt is what I explained and showed last > > tuesday on the cosmo-project meeting. > > We used nanosleep() which worked fine for the demonstration and > > playing. > > As long as you don't have troubles with longer than requested periods > > this would fit your needs. > > Is there a record of your explanation somewhere? As for the > longer-than-requested timing periods, yes that is a problem. If maximum > velocity of the drill is 30cm/s, a sudden stop would not be good. I can of > course change the MAX_V, but I'm still hoping for a non-kludgy solution. > > > Nevertheless in my opinion it's a job for a dedicated CPU/controller. > > Think about using an 68HC11 or something like that. > > If you can enshure not only minimum but also maximum step times you > > can even get the motor faster - well not with lowered drill of course. > > I agree. This does need a dedicated MCU. However, I only had 1 PCB layer > to work with, so simplicity was key here. It's possible to build a single layer PCB with an MCU. Well it can be tricky sometimes. > > You can shorten the steps while the motor is rotating which you can't > > do at once. > > What do you mean here? I already do use variable timing for the steps BTW. > Remember, the motors perform constant-acceleration operations...it means they > slowly approach MAX_V. It's pretty neat to listen to. :) Yes - that's want I mean and that's what gets you in trouble with the longer-than-requested thing so you are stuck with the initial speed. The problem here is that nanosleep returns no earlier than the given time unless a signal is received, in which case the exceeded time is returned and you can recall with the remaining. So you can garantie a minimal time. But with a multitasking OS you can't enshure that you will have the CPU at a special given time - other tasks including ints may have priority. At worst your process may need to wait for a disk... You might be able to do in the kernel (ab)using the clock interrupts, so you realy know when you own the CPU. See hardclock() function in src/sys/kern/kern_clock.c Don't forget that the rate can be modified via sysctl. With an MCU you would also use a timer interrupt. -- B.Walter COSMO-Project http://www.cosmo-project.de ticso@cicely.de Usergroup info@cosmo-project.de To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message