If I have to develop a driver myself...

What are my options? I spent some days verifying my idea...and would love to hear addiional input.

AFAIK, all existing solution to interface with motor driver broad are going through the parallel port. Be it directly bitbang-ing the step/dir/pwm (parport) or sending movement information over parallel port (pluto-p). I wasn't be able to find a component that is not.

Now my Thinkpad T40 is the only laptop I have around me that has a parallel port, product of 2003. I am afraid in a near future the parallel port will be totally dumped. (I checked the price for a ExpressCard54 parallel port that would suit for my T61p...I found it quite expensive).

I am going to make something anyway. Because
* I am going to convert my CNC Mill to a Repstrap which requires some more I/O (extruder motor, heater, thermocouple), parport is not enough
* I am using a serial rs232 -> AVR uC but it's not realtime / bandwidth is limited
* I don't own a pluto-p but I can source Cyclone II FPGA boar for around 20 EUR locally. (Compare to Pluto-p $50 + shipping!), ...I could design the hardware like Pluto-P, but I am thinking if I could do something more, so that it could migrate the parallel port away!

Here is the options that I visited
* USB
* Firewire
* Ethernet

USB protocol itself seems only communication up to 1ms resolution - be it Interrupt or Isochronous mode. Although 1ms is enough, but I guess we need some buffer. Plus, it doesn't seem there are open USB stack (IP Core) for FPGA, nor I don't think I can do it myself. Even I fixed the FPGA side, there wasn't anything working in RTAI side AFAIK.

Firewire - even the low end 100Mhz seems too fast for FPGA to handle without any MAC. That makes thing so complicated. At this point I realize parallel port is darn old good - what else could be easier by putting a byte in an address and wola, the signal is changed on the wire.

Ethernet - looks like someone already made an core for 10/100M Ethernet, and interfacing the PHY shouldn't be all that difficult. I am a newbie in FPGA but after reading the 10BASE-T tutorial in fpga4fun.com, only realized that 10BASE-T is so dumb and 80's (oh yeah it's really 80's), and I am comfortable to handle with - even without some sophisicated core published on opencore. And even 10Mbps is so overkilled to send trajectory info every 1ms, or even 0.1ms - Plus getting a dedicated PCI/ExpressCard network card is so much cheaper.
The only question is I didn't checkout the RTAI side yet. Basically I know there is a thing called "rtnet" but that's it. I hope it's available and usable on EMC2 Ubuntu platform (want to avoid re-compile whatever kernel module fun...it's a big turn down for other to reproduce the work!), and hope that the protocol is simple to work with (but maybe who care if there is only 1 slave attached)

At the end, I think I am going to make a FPGA - BASE10-T (rtnet) solution.

Thoughts?

Have you looked at the mesa cards?
Cards like the 5i20 plug into pci slots, with cards available for many options of inputs/outputs.

Rick G

Those cards look rather expensive to me plus I don't have desktop around me (hence no PCI(e) slot...).

I have to admit getting my hands dirty for DIYing something is also part of the goal.
(Just as I am using EMC2 and working on repstrap...it's more on the fun side than.If I really need to rapid prototyping or milling done now, I would have it done by other routes already.

Have you run a latency test on your laptop? Laptops are typically poor targets for EMC because of latency issues
usually related to power management.

PCW wrote:

Have you run a latency test on your laptop? Laptops are typically poor targets for EMC because of latency issues
usually related to power management.

I have integrated EMC2 with a XYZ mill on my Thinkpad T40. Stepper based, bitbangging the step thru parport.
Base = 0.1ms, Servo = 1ms. So far so good. I have used to mill a thermocouple PCB .

Very occasionally if I open some random hardware related thing (like playing something through sound card, or manipulating screensaver options), the base thread will delayed for a few more 0.x ms, but otherwise the steppers run smoothly in normal operation, even under HDD, browser load.