Briefly, I2C uses two lines for communication, has built in device addressing, is somewhat sophisticated, therefore can be complicated to get working. SPI uses 3(or 4) lines, requires external device addressing, and is straight forward in implementation. --- Jovan Kostovski <chombium@chom...> wrote: > Hi, > > >I have been looking at digital pots and see > >that they have 2 types I2C and SPI. What does this mean? > > Those are the names of the communication protocols that are used > for comunicating with the devices. > > They don't offer any fancy features ;) > Cheers, Jovan > My software has no bugs, only undocumented features.

Hi, >I have been looking at digital pots and see >that they have 2 types I2C and SPI. What does this mean? Those are the names of the communication protocols that are used for comunicating with the devices. They don't offer any fancy features ;) Cheers, Jovan

--- In piclist@picl..., "Alan Marconett" <KM6VV@a...> wrote: > > Hi Chris, > > There are the Sherline, SherlineCNC and CAD_CAM_EDM_DRO lists, all on Yahoo, > plus other lists as well. > > An old PC works fine, just stick to DOS. And turn off other stuff such as > memory management, etc. We're doing just fine on old PCs! > > Best 73's as well to you! > > Alan KM6VV good to hear, thanks I'm already on CAD_CAM_EDM so i'll get plugged back into it. I can't tear myself away from the appeal of being able to machine your own pcb's and cases !

Hi Chris, There are the Sherline, SherlineCNC and CAD_CAM_EDM_DRO lists, all on Yahoo, plus other lists as well. An old PC works fine, just stick to DOS. And turn off other stuff such as memory management, etc. We're doing just fine on old PCs! Best 73's as well to you! Alan KM6VV > -----Original Message----- > From: piclist@picl... [mailto:piclist@picl...] On Behalf > Of Chris > Sent: Tuesday, October 11, 2005 2:47 PM > To: piclist@picl... > Subject: [piclist] R/C servos on PIC. WAS Re: Interfacing a PIC with > Digital Potentiometer? > > --- In piclist@picl..., "Alan Marconett" <KM6VV@a...> wrote: > > > > Hi Chris, > > > > That's true, there is PWM. I DO need to be changing the step > rates. For > > CNC (my intended use), we need to accelerate/decelerate, otherwise > steps are > > lost (bad thing). I don't know if I want to be changing the PWM > rate all > > the time; and I need 4 steppers. The motion (endpoints of moves) > must be > > coordinated so that arcs and angled paths can be followed. One > winds up > > having to generate from one to four streams of steps, at different > rates. > > And for arcs, the rates are CONSTANTLY changing! > > > > My current working CNC controller software is running on a PC under > DOS (no > > nasty OS grabbing CPU cycles at the worst time, stepper motors HATE > that!). > > > > The Gcode (RS-274U) interpretation, step count calculations and all > the > > other stuff would continue to be done on a PC; however now windoz > or LINUX > > could be used as an OS. > > Thats all good, by the sounds of it at least, Alan ! > > Are you a member of any Yahoo CNC groups too. Would you mind keeping > me in mind as someone else who has a desire to build a CNC machine > and is slowly collecting all the necessary parts. > > I thought I might use an old PC with the outputs contaisisting of > step and direction pulses coming from the parallel port...are you > saying it's possible to lose pulses doing this or do you still > consider it to have integrity ? > > Best personal regards, > Chris > GM4UCD >

--- In piclist@picl..., "Alan Marconett" <KM6VV@a...> wrote: > > Hi Chris, > > That's true, there is PWM. I DO need to be changing the step rates. For > CNC (my intended use), we need to accelerate/decelerate, otherwise steps are > lost (bad thing). I don't know if I want to be changing the PWM rate all > the time; and I need 4 steppers. The motion (endpoints of moves) must be > coordinated so that arcs and angled paths can be followed. One winds up > having to generate from one to four streams of steps, at different rates. > And for arcs, the rates are CONSTANTLY changing! > > My current working CNC controller software is running on a PC under DOS (no > nasty OS grabbing CPU cycles at the worst time, stepper motors HATE that!). > > The Gcode (RS-274U) interpretation, step count calculations and all the > other stuff would continue to be done on a PC; however now windoz or LINUX > could be used as an OS. Thats all good, by the sounds of it at least, Alan ! Are you a member of any Yahoo CNC groups too. Would you mind keeping me in mind as someone else who has a desire to build a CNC machine and is slowly collecting all the necessary parts. I thought I might use an old PC with the outputs contaisisting of step and direction pulses coming from the parallel port...are you saying it's possible to lose pulses doing this or do you still consider it to have integrity ? Best personal regards, Chris GM4UCD

Hi Chris, That's true, there is PWM. I DO need to be changing the step rates. For CNC (my intended use), we need to accelerate/decelerate, otherwise steps are lost (bad thing). I don't know if I want to be changing the PWM rate all the time; and I need 4 steppers. The motion (endpoints of moves) must be coordinated so that arcs and angled paths can be followed. One winds up having to generate from one to four streams of steps, at different rates. And for arcs, the rates are CONSTANTLY changing! My current working CNC controller software is running on a PC under DOS (no nasty OS grabbing CPU cycles at the worst time, stepper motors HATE that!). The Gcode (RS-274U) interpretation, step count calculations and all the other stuff would continue to be done on a PC; however now windoz or LINUX could be used as an OS. I've played with the L293/L297, but for this, I want G210 Geckos! The idea is to build a "black box" step (and direction) generator for 4 axis, and drive Geckos. In other projects, like steppers on a small robot, one might want to do it all (as much as possible, anyway) in the PIC. So the L293 gets replaced, leaving the high current (and chopper) up to the L297. Alan KM6VV > -----Original Message----- > From: piclist@picl... [mailto:piclist@picl...] On Behalf > Of Chris > Sent: Tuesday, October 11, 2005 10:44 AM > To: piclist@picl... > Subject: [piclist] R/C servos on PIC. WAS Re: Interfacing a PIC with > Digital Potentiometer? > > --- In piclist@picl..., "rtstofer" <rstofer@p...> wrote: > > > > Yes, the switcher makes the code much more clear. But, as you > said, > > there are drawbacks... > > > > I would make the stepper driver code fully interrupt driven, > > independent of the task switcher. > > The Atmel ATmega128 allows nested interrupts but the priorities are > > fixed. > > I've just finished my first 18f252 project and notice that there are > two levels of priority. > #Wether or not these priorities are assigned to any relevant hardware > to your project it's hard to say, but it may be possible to trigger > one interupt from another somewhow to work around this if it's an > issue. > > For the stepper drivers I think it was the l297 I used once, which > took speed and direction inputs. The inputs came from the pics pwm > output plus one other pin for direction. I turned off the pwm module > to keep the motor stationary and turned it on when needed. I didn't > go to the logical conclusion of making the speed variable by changing > the pwm frequency but then again it wasn't needed. > > That said, I think I'm the same as most other folks here and > generally prefer to do as much as possible in terms of control on the > pic itself. > > What I decided was that I would need an h-bridge to drive the stepper > anyway, that using an h-bridge/stepper driver (l293) with logic > (l297) wasn't cheating too much. > > ChrisB

Hi Richard, Sounds like the steppers really don't need a task switcher much. I would need to service either RS-232 or USB, but they could be interrupt driven as well. I will have to "ramp up" (and down) to the desired feed rates. This can go in the background. As well as buffering up commands, and watching limit and E-switches. As you say, the priorities are the problem. I think there are two levels of priority for the 18F4620, (or 18F4550 USB?), so that might help. And of course, there are bits to check to decide what to do in the ISR. I'm thinking then I need to have a TOD clock running (much like for DOS and its 8254) and be able to compare the lower end of the counter (CCP) for the time of the next step to be generated. The prescaler could be used on timer1, and the compare would generate the interrupt. Sounds like a 40Mhz clock / 8 would give me a 5 Mhz step clock, and a 16 bit Timer1 would allow 60+ seconds between steps, if needed. Although that would allow step time errors to accumulate because of the shorter (16 bit) counter. A long counter of say 40 bits could keep track of the "time" all day long. Basically what I do on a PC (under DOS). I'd maintain a list of the step counts to watch for, and watch for the earliest one needed. The counter (Timer1) would continue to run and rollover. Rollover is not hard to handle. I guess one could maintain the remainder of a long counter in memory. That would do it! If the CCP matched, the remainder of the long counter could then be compared to verify the complete time (since reset). The other chips are interesting... but I just got the MicroChip PICDEM FS USB board! RB0-7 (and a lot of other stuff) are on a pad for a header, so I can add a little board with the ULN2003 driver chips. These will then drive four Gecko G210 stepper modules. Food for thought! Thanks for the comments! Alan KM6VV > -----Original Message----- > From: piclist@picl... [mailto:piclist@picl...] On Behalf > Of rtstofer > Sent: Tuesday, October 11, 2005 10:09 AM > To: piclist@picl... > Subject: [piclist] R/C servos on PIC. WAS Re: Interfacing a PIC with > Digital Potentiometer? > > Yes, the switcher makes the code much more clear. But, as you said, > there are drawbacks... > > I would make the stepper driver code fully interrupt driven, > independent of the task switcher. Once commanded to make a certain > number of steps, that operation would run in the background. Even > with multiple steppers, the trick will be to give them higher priority > than the task switcher. > > The problem, as I see it, is that most microcontrollers don't allow > you to assign the interrupt priority and many won't allow interrupts > to be nested. > > The Atmel ATmega128 allows nested interrupts but the priorities are > fixed. This might be ok, it is a matter of capitalizing on the way > they are defined. And the chip moves right along at 16 MIPS. > > Moving up, the Philips LPC2106 ARM-7 has a fully programmable > interrupt controller so priorities can be dynamically assigned. And, > it screams at about 60 MIPS! The LPC2136 has an added A/D converter. > FreeRTOS (a free, real time OS) runs on the LPC2106 - I haven't > checked it on the LPC2136 but it probably works. There is a fairly > steep learning curve to getting started but it all plays nicely. > > Development boards for these devices are available at www.sparkfun.com > > Richard > > > to unsubscribe, go to http://www.yahoogroups.com and follow the > instructions > Yahoo! Groups Links

--- In piclist@picl..., "rtstofer" <rstofer@p...> wrote: > > Yes, the switcher makes the code much more clear. But, as you said, > there are drawbacks... > > I would make the stepper driver code fully interrupt driven, > independent of the task switcher. > The Atmel ATmega128 allows nested interrupts but the priorities are > fixed. I've just finished my first 18f252 project and notice that there are two levels of priority. #Wether or not these priorities are assigned to any relevant hardware to your project it's hard to say, but it may be possible to trigger one interupt from another somewhow to work around this if it's an issue. For the stepper drivers I think it was the l297 I used once, which took speed and direction inputs. The inputs came from the pics pwm output plus one other pin for direction. I turned off the pwm module to keep the motor stationary and turned it on when needed. I didn't go to the logical conclusion of making the speed variable by changing the pwm frequency but then again it wasn't needed. That said, I think I'm the same as most other folks here and generally prefer to do as much as possible in terms of control on the pic itself. What I decided was that I would need an h-bridge to drive the stepper anyway, that using an h-bridge/stepper driver (l293) with logic (l297) wasn't cheating too much. ChrisB

Yes, the switcher makes the code much more clear. But, as you said, there are drawbacks... I would make the stepper driver code fully interrupt driven, independent of the task switcher. Once commanded to make a certain number of steps, that operation would run in the background. Even with multiple steppers, the trick will be to give them higher priority than the task switcher. The problem, as I see it, is that most microcontrollers don't allow you to assign the interrupt priority and many won't allow interrupts to be nested. The Atmel ATmega128 allows nested interrupts but the priorities are fixed. This might be ok, it is a matter of capitalizing on the way they are defined. And the chip moves right along at 16 MIPS. Moving up, the Philips LPC2106 ARM-7 has a fully programmable interrupt controller so priorities can be dynamically assigned. And, it screams at about 60 MIPS! The LPC2136 has an added A/D converter. FreeRTOS (a free, real time OS) runs on the LPC2106 - I haven't checked it on the LPC2136 but it probably works. There is a fairly steep learning curve to getting started but it all plays nicely. Development boards for these devices are available at www.sparkfun.com Richard

Hi Richard, I've been examining my companies' PIC products, and we use these task switchers quite a bit. I can see the utility, one product has 50 "mini tasks" that take turns running off the main system tick. A/D reads on multiple channels, trigger input reads, start/stop/monitoring of several small pumps, display update tasks, etc. There are drawbacks, but it still makes a simpler system then a fully pre-emptive one. I'm not sure how my stepper drivers will fare under a task switcher, 'tho. Alan KM6VV > -----Original Message----- > From: piclist@picl... [mailto:piclist@picl...] On Behalf > Of rtstofer > Sent: Monday, October 10, 2005 9:16 PM > To: piclist@picl... > Subject: [piclist] R/C servos on PIC. WAS Re: Interfacing a PIC with > Digital Potentiometer? > I did a similar task switcher a while back - mostly because it > cleaned up the code. Tasks are just neater - simple, stand alone > functions with limited interaction. > > My time base was 1 mS so I switched a lot and each task had to be > guaranteed to be complete in 1 mS because this was not a preemptive > scheduler. But, 1 mS is a long time when you grind out 5,000,000 > instructions (albeit simple ones) per second. You can execute about > 5000 instructions in a time slice and that is a lot. > > It worked quite well but there was the drawback of the fixed time > slice. Even when a task completed early, another task was not > dispatched. That would be a simple upgrade... > > Richard