Re: precise timing
the REALLY best answer was the suggestion to use teh speaker output.. (ANDED with anuother bit.. you don;t want the bios BEEP to move teh drill.. alrternatively you can also use the tiemrs.. remember that the pcaudio device runs the available clock chip up to 16,000 Hz.. and changes teh duty cycle on each cycle.. You could do something like that julian On Sun, 30 Sep 2001, Warner Losh wrote: > In message <200109301010.07784@EO> Bart Kus writes: > : Right now, I use for() as a timing loop. I calibrate it on program start > : and can then get very precise timing. There are, of course, the intermittent > : interruptions of the multitasker. So this solution is not ideal by any > : means. In fact, the for() loop approach is really meant for the DOS port of > : this software. I'm wondering if there is any way I can access a more precise > : interrupt-driven (or blocking) timing source. I know I can do a select() > : with supposedly microsecond accuracy, but I doubt that it is in fact that > : accurate in practice (doesn't the kernel only use a 100Hz clock or > : something?). Is there any way to get at the system timers on the > : motherboard? Those can provide precise timing, no? > > you are likely better off implementing this as a device driver, likely > with the parallel port bus stuff. > > Warner > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-hackers" in the body of the message > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: precise timing
Bakul Shah wrote: > > > Hrm, I was planning on investigating the RT capabilities of fbsd after > > I got > > myself a decent timer mechanism. I was hoping they would be enough to get > > close to RT. I have an SMP system I can use, so 1 CPU can be dedicated to > > the task. > > I doubt even an SMP system would help. Plus this is ASMP -- ASymmetric MultiProcessing -- when you dedicate a CPU to a task. FreeBSD doesn't support this. Linux supports this, with the patches from Ingo. I'm guessing they will become part of the standard Linux distribution. He developes the "Tux" in kernel web server, and he has the entire code path for the thing, including the TCP stack, so it fits in a single CPU instruction cache. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: precise timing
In message <200109301010.07784@EO> Bart Kus writes: : Right now, I use for() as a timing loop. I calibrate it on program start : and can then get very precise timing. There are, of course, the intermittent : interruptions of the multitasker. So this solution is not ideal by any : means. In fact, the for() loop approach is really meant for the DOS port of : this software. I'm wondering if there is any way I can access a more precise : interrupt-driven (or blocking) timing source. I know I can do a select() : with supposedly microsecond accuracy, but I doubt that it is in fact that : accurate in practice (doesn't the kernel only use a 100Hz clock or : something?). Is there any way to get at the system timers on the : motherboard? Those can provide precise timing, no? you are likely better off implementing this as a device driver, likely with the parallel port bus stuff. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
RE: precise timing
On 30-Sep-2001 Bart Kus wrote: > Right now, I use for() as a timing loop. I calibrate it on program start > and can then get very precise timing. There are, of course, the > intermittent > interruptions of the multitasker. So this solution is not ideal by any > means. In fact, the for() loop approach is really meant for the DOS port of > this software. I'm wondering if there is any way I can access a more > precise > interrupt-driven (or blocking) timing source. I know I can do a select() > with supposedly microsecond accuracy, but I doubt that it is in fact that > accurate in practice (doesn't the kernel only use a 100Hz clock or > something?). Is there any way to get at the system timers on the > motherboard? Those can provide precise timing, no? I suspect the only way you could achieve this in FreeBSD at the moment is to write a kernel driver. That way you can disable interrupts while you frob your board.. (And get quick access when you need it). --- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: precise timing
In message <200109301318.44290@EO>, Bart Kus cleopede: >On Sunday 30 September 2001 12:47, Greg Shenaut wrote: >> Well, setitimer has a maximum rate of 100 Hz, with a slop factor >> sometimes much greater than 10 ms. This was the result of some >> recent testing on a lightly-loaded standard 4.3 system. > > That's not good enough. :/ > >> How many stepper motors are you driving? If it's only one at a time, then >> maybe the speaker port on the motherboard (a programmable counter-timer) >> would be more reliable. > > I like the speaker port idea. Can one program the speaker port to generate >an int/signal/un-block using bsd's kernel API? I do not think that there is hardware support for interrupts from the speaker port, but it seems to me that since it just sits there putting out a square wave at whatever frequency was most recently programmed into it, all one of the (relatively infrequent) less-than 10 ms timing glitches would do is to slow down the ramp sometimes, which would never harm the stepper motor (but would slow down the process a little bit). >> Another idea is to use a fifo'ed UART's data out >> line and fiddle with the baud rate to vary the speed of the pulses. > > I don't think this will provide the "smoothness" I want. Going from >2400->4800 steps/sec for example would be a huge jerk. Need SMOOTH >transition (constant-acceleration). I was thinking in terms of changing the baud rate in smaller increments than that--the timing hardware inside the standard PC UART is just a 16-bit programmable divider. But a MCU is still probably your best bet. (I remember writing a stepper-motor driver on a TI 9900 back in the 70's.) Greg Shenaut To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: precise timing
Devin Butterfield([EMAIL PROTECTED])@2001.09.30 12:33:26 +: > [...] > > > was suggested you may want to consider a dedicated cpu based > > > controller. Thre are a number of solutions for hobbyists > > > (such as the handyboard, see www.handyboard.com). > > > > Unfortunately, money is a big factor. So that's not an option. :/ > > > > Atmel AVR microcontrollers are < $10 from distributors like Digikey (and > Digikey usually has high prices). They're very slick and VERY FAST. You can > do 12 MIPS with one of their chips. i can second that. a good friend of mine is implementing particle accelerator control units on the avr series and is very content with features, performance and overall development/deployment cost. basically they seem to be standard 16bit arm thumb platforms, with memory and interface configurations being the only varying features. > Of course you'd need to spend some time learning their instruction > sets/learning how to code in C for them. There is a C compiler in the ports > named avr-gcc to do just that. what i have seen from the development environment under win32 (yes, yes, i know...) the gcc generates code with a quite good quality and performance, some bugs included but well documented, and the in system programmer frontend 'pony prog' being pretty good as well. i also find it appealing that the avr series has onchip flash/eeprom and can be programmed via the isp bus even if one managed to screw up the boot code completely -- this reduces development costs and time dramatically ;-) /k -- > "Her figure described a set of parabolas that could cause cardiac arrest > in a yak." --Woody Allen KR433/KR11-RIPE -- WebMonster Community Founder -- nGENn GmbH Senior Techie http://www.webmonster.de/ -- ftp://ftp.webmonster.de/ -- http://www.ngenn.net/ karsten&rohrbach.de -- alpha&ngenn.net -- alpha&scene.org -- [EMAIL PROTECTED] GnuPG 0x2964BF46 2001-03-15 42F9 9FFF 50D4 2F38 DBEE DF22 3340 4F4E 2964 BF46 Please do not remove my address from To: and Cc: fields in mailing lists. 10x PGP signature
Re: precise timing
> Hrm, I was planning on investigating the RT capabilities of fbsd after I got > myself a decent timer mechanism. I was hoping they would be enough to get > close to RT. I have an SMP system I can use, so 1 CPU can be dedicated to > the task. I doubt even an SMP system would help. > > you are better off writing a device driver which can run > > timing critical code while blocking out all other interrupts. > Not an option. It would stall the whole system during the (possibly 20 > minute) drilling operation. Maybe it'll be possible with SMPng, but not now. I meant blocking other interrupts only during critical periods. For instance, when your s/w gets control, you find out the current time and figure out what speed you want to set. Then you set timout for the next time you want to do this and return. Basically you are approximating a curve and while doing this at regular interval is easier, you can also approximate with an irregular interval (use Bresenham). But this is just a generic suggestion; I do not know enought details to do more than that. One other thing you can do is to increase clock tick rate to 1000 Hz from the default 100 Hz. > > was suggested you may want to consider a dedicated cpu based > > controller. Thre are a number of solutions for hobbyists > > (such as the handyboard, see www.handyboard.com). > > Unfortunately, money is a big factor. So that's not an option. :/ IIRC you can buy a kit (including a two sided PCB) for under $100. A few years ago I built the precursor to the Handy Board (called Miniboard) from a kit for a lot less. It had a 68hc11E2 (with a 2k EEPROM) + you can control upto 4 motors + a bunch of sensors and digitial output control pins. Someone may still be selling it. What I was thinking of was not a completely dedicated controller. You interface to something like the miniboard via a serial port and do all the fancy computation on your freebsd system and let the controller do the PWM by feeding it precomputed parameters (at time t0 velocity v0, at time t1 set it to v1 and so on). > It's home brew, I'll forward you more details in personal email. Thanks! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: precise timing
On Sunday 30 September 2001 14:33, Devin Butterfield wrote: > Atmel AVR microcontrollers are < $10 from distributors like Digikey (and > Digikey usually has high prices). They're very slick and VERY FAST. You can > do 12 MIPS with one of their chips. > > Of course you'd need to spend some time learning their instruction > sets/learning how to code in C for them. There is a C compiler in the ports > named avr-gcc to do just that. > > As for programmers, you can program these chips with a simple homebrew > cable that plugs into your parallel port. > > Please see: > > http://www.bsdhome.com/avrprog > > Is that cheap enough? Oh, very nice! Definate contender for "version 2" of this controller. I'd still like to get version 1 working though. Thanks for the info! --Bart To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: precise timing
You definite need to use a microcontroller. Something like the 68HC11F1 is a good single-chip solution (though the F1 only has 512 bytes of E^2). I'm sure Motorola has newer chips with more on-board E^2.Stepper motors can be manipulated from a PC parallel port but you will never get smooth output and you can forget about momentum accelleration. There are also a huge number of Intel-derivative microcontrollers that are as self contained and in much smaller packages then typical motorola parts. I'm most familiar with the Motorola's... For a stepper or waveform output I've always liked the motorola MCUs because they have timer output compare registers that will automatically flip a bit for you on an output port, giving you timer resolution down to crystal / 4 and accuracy that is at the crystal accuracy. But the Intel derivatives are going to be much, much cheaper... $2 or $3 for an MCU that does what you want and extremely easy to program. Look at the MCS51 and MCS96 series. Note that there are dozens of manfacturers of Intel-style controllers. -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: precise timing
[...] > > was suggested you may want to consider a dedicated cpu based > > controller. Thre are a number of solutions for hobbyists > > (such as the handyboard, see www.handyboard.com). > > Unfortunately, money is a big factor. So that's not an option. :/ > Atmel AVR microcontrollers are < $10 from distributors like Digikey (and Digikey usually has high prices). They're very slick and VERY FAST. You can do 12 MIPS with one of their chips. Of course you'd need to spend some time learning their instruction sets/learning how to code in C for them. There is a C compiler in the ports named avr-gcc to do just that. As for programmers, you can program these chips with a simple homebrew cable that plugs into your parallel port. Please see: http://www.bsdhome.com/avrprog Is that cheap enough? -- Regards, Devin. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: precise timing
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 [EMAIL PROTECTED] Usergroup [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: precise timing
On Sunday 30 September 2001 12:47, Greg Shenaut wrote: > Well, setitimer has a maximum rate of 100 Hz, with a slop factor > sometimes much greater than 10 ms. This was the result of some > recent testing on a lightly-loaded standard 4.3 system. That's not good enough. :/ > How many stepper motors are you driving? If it's only one at a time, then > maybe the speaker port on the motherboard (a programmable counter-timer) > would be more reliable. I like the speaker port idea. Can one program the speaker port to generate an int/signal/un-block using bsd's kernel API? > Another idea is to use a fifo'ed UART's data out > line and fiddle with the baud rate to vary the speed of the pulses. I don't think this will provide the "smoothness" I want. Going from 2400->4800 steps/sec for example would be a huge jerk. Need SMOOTH transition (constant-acceleration). But the speaker port idea sounds great. --Bart To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: precise timing
On Sunday 30 September 2001 12:30, Bakul Shah wrote: > Are you controlling the rotation speed of the drill or the > x,y,z position? I'd guess the latter. Don't you also need I am controlling XYZ. > guaranteed real time response (which FreeBSD won't provide > you)? I suppose if you are controlling the position (and not > the velocity) RT response won't be too critical. At any rate Hrm, I was planning on investigating the RT capabilities of fbsd after I got myself a decent timer mechanism. I was hoping they would be enough to get close to RT. I have an SMP system I can use, so 1 CPU can be dedicated to the task. > you are better off writing a device driver which can run > timing critical code while blocking out all other interrupts. Not an option. It would stall the whole system during the (possibly 20 minute) drilling operation. Maybe it'll be possible with SMPng, but not now. > Or else between the time you measure time and supply the next > pulse a higher prio interrupt handler else may sneak in. As I'm hoping higher-priority interrupts will be quick about their work. A few microseconds or 10s or possibly 100s hopefully won't upset the drill too much. > was suggested you may want to consider a dedicated cpu based > controller. Thre are a number of solutions for hobbyists > (such as the handyboard, see www.handyboard.com). Unfortunately, money is a big factor. So that's not an option. :/ > Is this a totally homebrew drill or something from a kit? > I'd be interested in details (probably better offline since > the interection of freebsd s/w hackers & h/w hackers is > tiny). It's home brew, I'll forward you more details in personal email. --Bart To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: precise timing
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. > 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. :) --Bart To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: precise timing
In message <200109301010.07784@EO>, Bart Kus cleopede: > On a totally unrelated subject to my sio.c message, I have a second problem. > I've built a computer-controlled drill, that is controlled via the parallel >port. This drill uses stepper motors, at 1/2 step. My driver software >implements a maximum-acceleration control algorithm that ensures that at any >point in time, any axis will not experience more than X m/s/s of >acceleration. This keeps the drill from self-destructing. :) Unfortunately, >it means I need access to a very precise timing source to issue the step >instructions to the motor control board. > > Right now, I use for() as a timing loop. I calibrate it on program start >and can then get very precise timing. There are, of course, the intermittent >interruptions of the multitasker. So this solution is not ideal by any >means. In fact, the for() loop approach is really meant for the DOS port of >this software. I'm wondering if there is any way I can access a more precise >interrupt-driven (or blocking) timing source. I know I can do a select() >with supposedly microsecond accuracy, but I doubt that it is in fact that >accurate in practice (doesn't the kernel only use a 100Hz clock or >something?). Well, setitimer has a maximum rate of 100 Hz, with a slop factor sometimes much greater than 10 ms. This was the result of some recent testing on a lightly-loaded standard 4.3 system. >Is there any way to get at the system timers on the >motherboard? Those can provide precise timing, no? But not necessarily realtime response if you are generating the stepper pulses yourself. How many stepper motors are you driving? If it's only one at a time, then maybe the speaker port on the motherboard (a programmable counter-timer) would be more reliable. Another idea is to use a fifo'ed UART's data out line and fiddle with the baud rate to vary the speed of the pulses. And one final idea is to use a (possibly port-powered) MCU as an independent timer generator. Greg Shenaut To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: precise timing
> On a totally unrelated subject to my sio.c message, I have a second problem. > I've built a computer-controlled drill, that is controlled via the parallel > port. This drill uses stepper motors, at 1/2 step. My driver software > implements a maximum-acceleration control algorithm that ensures that at any > point in time, any axis will not experience more than X m/s/s of > acceleration. This keeps the drill from self-destructing. :) Unfortunately, > it means I need access to a very precise timing source to issue the step > instructions to the motor control board. Are you controlling the rotation speed of the drill or the x,y,z position? I'd guess the latter. Don't you also need guaranteed real time response (which FreeBSD won't provide you)? I suppose if you are controlling the position (and not the velocity) RT response won't be too critical. At any rate you are better off writing a device driver which can run timing critical code while blocking out all other interrupts. Or else between the time you measure time and supply the next pulse a higher prio interrupt handler else may sneak in. As was suggested you may want to consider a dedicated cpu based controller. Thre are a number of solutions for hobbyists (such as the handyboard, see www.handyboard.com). Is this a totally homebrew drill or something from a kit? I'd be interested in details (probably better offline since the interection of freebsd s/w hackers & h/w hackers is tiny). To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: precise timing
On Sun, Sep 30, 2001 at 10:18:01AM -0500, Bart Kus wrote: > On a totally unrelated subject to my sio.c message, I have a second problem. > I've built a computer-controlled drill, that is controlled via the parallel > port. This drill uses stepper motors, at 1/2 step. My driver software > implements a maximum-acceleration control algorithm that ensures that at any > point in time, any axis will not experience more than X m/s/s of > acceleration. This keeps the drill from self-destructing. :) Unfortunately, > it means I need access to a very precise timing source to issue the step > instructions to the motor control board. > > Right now, I use for() as a timing loop. I calibrate it on program start > and can then get very precise timing. There are, of course, the intermittent > interruptions of the multitasker. So this solution is not ideal by any > means. In fact, the for() loop approach is really meant for the DOS port of > this software. I'm wondering if there is any way I can access a more precise > interrupt-driven (or blocking) timing source. I know I can do a select() > with supposedly microsecond accuracy, but I doubt that it is in fact that > accurate in practice (doesn't the kernel only use a 100Hz clock or > something?). Is there any way to get at the system timers on the > motherboard? Those can provide precise timing, no? 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. 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. You can shorten the steps while the motor is rotating which you can't do at once. -- B.Walter COSMO-Project http://www.cosmo-project.de [EMAIL PROTECTED] Usergroup [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
precise timing
On a totally unrelated subject to my sio.c message, I have a second problem. I've built a computer-controlled drill, that is controlled via the parallel port. This drill uses stepper motors, at 1/2 step. My driver software implements a maximum-acceleration control algorithm that ensures that at any point in time, any axis will not experience more than X m/s/s of acceleration. This keeps the drill from self-destructing. :) Unfortunately, it means I need access to a very precise timing source to issue the step instructions to the motor control board. Right now, I use for() as a timing loop. I calibrate it on program start and can then get very precise timing. There are, of course, the intermittent interruptions of the multitasker. So this solution is not ideal by any means. In fact, the for() loop approach is really meant for the DOS port of this software. I'm wondering if there is any way I can access a more precise interrupt-driven (or blocking) timing source. I know I can do a select() with supposedly microsecond accuracy, but I doubt that it is in fact that accurate in practice (doesn't the kernel only use a 100Hz clock or something?). Is there any way to get at the system timers on the motherboard? Those can provide precise timing, no? --Bart To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
