Control stepper motors via USB

Question

I'm doing a USB device is to control stepper motors. I've done this before using a parallel port. because these ports do not exist in current motherboards, I decided to implement a USB communication between my device and the PC (host). To achieve My objective, I endowed the freescale microcontroller the device with that has a USB module 12Mbps. My USB device must receive 4 bytes (one for each motor driver) at a given time, because every byte is a step that should move the engine. In the PC (Host) an application of user processes a text file with information and make the trajectory coordinates sending bytes at a certain rate for each motor (time is trivial to achieve the acceleration and speed of the motors) .

Using the parallel port was an easy the task because each byte is sent sequentially to a time determined by the user app.

doing a little research about full speed USB protocol understood that the frame is sent every 1ms. then you can send 4 byte or many more every 1ms but I can not manage time like I did with the parallel port. My microcontroller can send up to 64 bytes per frame (Based on transfer papers type Control, Bulk, Int, Iso ..).

question 1:

I want to know in what way I can send 4-byte packets faster than every 1 ms?

question 2:

What type of transfer can advise me for these type of devices?

Thanks.

Answer 1

Like Ricardo said, USB-serial will suffice.

As for the type of transfer, try implementing a CDC stack and use your SCI receiver to listen for PC commands. That will give you a receive buffer which will meet your needs.

• Initialize your SCI (baud, etc)
• Enable receiver and interrupt
• On data receive, move it to your 4-byte command buffer
• Clear receive buffer, wait for more

When you have all 4 bytes, fire off the steppers! Four bytes should take µs.

Check with Freescale to see if your processor is supported.

http://cache.freescale.com/files/microcontrollers/doc/support_info/USB_STACK_RELEASE_NOTES_V4.1.1.pdf?fpsp=1

There might even be some sample code to get you started.

-Cheers

Answer 2

I am achieving the same goal (driving/control CNC machines) like this:

the USB device is just synchronous I/O parallel port. Using continuous bulk transfer one pipe as input and one as output. This way I was able to achieve synchronous 64bit parallel communication with ~70KHz sample rate. It uses traffic around (i)4.27+(o)4.27 MBit/s that is limit for mine MCU and code. Bigger speeds cause jitter on the output due to USB events interrupts.

How to do it (on MCU side)

I have 2 FIFO's one for ingoing and one for outgoing data. I have timer interrupt occurring with sample rate frequency. In it I read the inputs and feed it to the first FIFO and read data from the other FIFO and send it to the outputs.

On top of that the USB task is called (inside the same interrupt) checking FIFO for sending to and incoming data from USB handling the transfer itself

I choose ATMEL AT32UC3A chips for this task. After a long and pain full research I decided these MCU's because they have enough memory for both FIFO's and program so no need for additional IC. It has FPGA package which can be used (BGA is not an option). It has HS USB (most USB MCU's have only FS like yours). It runs at 66MHz. It supports many interesting features (did interesting projects with it in the past) and of coarse I have experience with ATMEL MCU's from past

So if you want to achieve something similar then

1. start with bulk transfer (PC -> USB -> MCU -> output)

2. add FIFO if needed

   do not know the sample rate you need. The old LPT's could handle from 80-196KHz depend on the manufactor. The modern ones are much much slower (which is silly and sad).

3. measure the critical sample rate

   you need oscilloscope or very good hearing for this. The output data must be synchronous so no holes in it, no jitter, etc...

   if any of these are present you have to lower the sample rate. Mine setup could handle even 1MHz sample rate but the USB jitter was present (sometimes USB event froze the sending for longer that one sample...) so I achieve only 70KHz of stable output.

4. if needed also inputs then add them

   but only if the output is working as it should. Do not forget to lower the sample rate after this too ... Use separate bulk pipes and FIFOs for input and output.