I have a question regarding stepper motor control while using the TCP/IP stack.
In the past I have used a timer for my stepper motor control. I set the period of a timer to the required time between pulses and then I change the motor phase outputs as needed in the timer tick ISR. In the cases where I have done this my stepper was moving at a maximum rate of around 400 pulses per second which means the interrupt was occurring every 2.5 milliseconds. And I was using USB for communication to the host.
I am now working on a new product which will use the TCP/IP stack to communicate with a PC over Ethernet. It will also be communicating with other devices via SPI and UART modules. This new device must be capable of operating a stepper up to 2000 pulses per second which means the interrupt may be firing every .5 milliseconds if I use the same timer/ISR approach to drive the stepper. The stepper is turned on and off based on commands received from the host, so communication with the host and operation of the motor need to occur harmoniously and simultaneously. If the stepper speed varies slightly that would not be a problem but it is not ideal. Also, if the stepper were to pause for say a 30ms in the middle of it's move that WOULD not be acceptable.
I am considering using a PIC24F with the instruction clock speed of 16MHz (32Mhz/2 using the internal FRC+PLL) for this project. Do you think that the interrupts for the stepper will disrupt the Ethernet communication or vise-versa? Is there a better way of doing this?
I have considered using a separate PIC for the stepper control and then I could send that pic target position commands or halt commands to start and stop the movement but that would add another firmware into the mix and complicate things all around.
Best Answer
As Nick T mentioned, TCP/IP is unfiltered and non-deterministic. You said you want to also interface with SPI and UART devices, and previous versions used USB. These are difficult to do in real time, and probably require significant code space.
On the other hand, you want real-time control of your stepper motors, which requires deterministic execution and rapid interrupts but not a lot of program space.
While you said you wanted to avoid using a separate microcontroller because it would complicate things, this is a perfect example of when you need a co-processor, and I believe that it would make things simpler in the end.
You can develop simple stepper motor controller firmware that run on small, cheap microcontrollers. Design (or discover) a protocol that can use a communication bus available in hardware on whatever controller you choose. I'd recommend SPI for this (on a different channel than the device you mentioned in your question; your master should have two SPI peripherals), you don't want to mess with address conflicts given the small number of controllers you'll have. Don't do anything with this controller but run the stepper according to the data it receives over the protocol. You can probably buy something that does this already. The goal is to be able to treat this as a hardware peripheral.
Then, you can develop USB or Ethernet controllers that will plug into these devices. You will have flexibility in the host protocols (Need to use RS485 this time? No problem!), you can use different numbers of motors, and you have greater modularity for designing, testing, debugging, repairing, and replacing. The only reasons I'd try to implement something like this in a single controller would be extreme cost/size restrictions, and/or a lack of hardware modules (like PWM? Did I miss something?) that could do this without interrupting the host processor.