Date: Sun, 30 Sep 2001 20:58:59 +0200 From: Bernd Walter <ticso@mail.cicely.de> To: Bart Kus <bsd@shell-server.com> Cc: Bernd Walter <ticso@mail.cicely.de>, hackers@FreeBSD.ORG Subject: Re: precise timing Message-ID: <20010930205859.A19910@cicely20.cicely.de> In-Reply-To: <200109301303.08611@EO>; from bsd@shell-server.com on Sun, Sep 30, 2001 at 01:10:35PM -0500 References: <200109301010.07784@EO> <20010930180302.A19621@cicely20.cicely.de> <200109301303.08611@EO>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20010930205859.A19910>