Tengo una pregunta sobre el control del motor paso a paso mientras uso la pila TCP/IP.
En el pasado, he usado un temporizador para el control de mi motor paso a paso. Configuro el período de un temporizador al tiempo requerido entre pulsos y luego cambio las salidas de fase del motor según sea necesario en el ISR del temporizador. En los casos en los que hice esto, mi paso a paso se movía a una velocidad máxima de alrededor de 400 pulsos por segundo, lo que significa que la interrupción se producía cada 2,5 milisegundos. Y estaba usando USB para la comunicación con el host.
Ahora estoy trabajando en un nuevo producto que usará la pila TCP/IP para comunicarse con una PC a través de Ethernet. También se comunicará con otros dispositivos a través de módulos SPI y UART. Este nuevo dispositivo debe ser capaz de operar un motor paso a paso hasta 2000 pulsos por segundo, lo que significa que la interrupción puede dispararse cada 0,5 milisegundos si utilizo el mismo enfoque de temporizador/ISR para impulsar el motor paso a paso. El paso a paso se enciende y apaga en función de los comandos recibidos del host, por lo que la comunicación con el host y la operación del motor deben ocurrir de manera armoniosa y simultánea. Si la velocidad del paso a paso varía ligeramente, no sería un problema, pero no es lo ideal. Además, si el paso a paso hiciera una pausa de, digamos, 30 ms en medio de su movimiento, eso NO SERÍA aceptable.
Estoy considerando usar un PIC24F con una velocidad de reloj de instrucción de 16MHz (32Mhz/2 usando el FRC+PLL interno) para este proyecto. ¿Cree que las interrupciones del paso a paso interrumpirán la comunicación Ethernet o viceversa? ¿Hay una mejor manera de hacer esto?
Consideré usar un PIC separado para el control paso a paso y luego podría enviar comandos de posición de destino de imagen o comandos de parada para iniciar y detener el movimiento, pero eso agregaría otro firmware a la mezcla y complicaría las cosas.
Como mencionó Nick T, TCP/IP no está filtrado y no es determinista. Dijo que también desea interactuar con dispositivos SPI y UART, y las versiones anteriores usaban USB. Estos son difíciles de hacer en tiempo real y probablemente requieran un espacio de código significativo.
Por otro lado, desea un control en tiempo real de sus motores paso a paso, lo que requiere una ejecución determinista e interrupciones rápidas, pero no mucho espacio de programa.
Si bien dijo que quería evitar el uso de un microcontrolador separado porque complicaría las cosas, este es un ejemplo perfecto de cuándo necesita un coprocesador, y creo que al final simplificaría las cosas.
Puede desarrollar un firmware de controlador de motor paso a paso simple que se ejecute en microcontroladores pequeños y económicos. Diseñe (o descubra) un protocolo que pueda usar un bus de comunicación disponible en hardware en cualquier controlador que elija. Recomendaría SPI para esto (en un canal diferente al dispositivo que mencionó en su pregunta; su maestro debe tener dos periféricos SPI), no quiere meterse con conflictos de direcciones dada la pequeña cantidad de controladores que tendrá . No haga nada con este controlador, pero ejecute el paso a paso de acuerdo con los datos que recibe sobre el protocolo. Probablemente puedas comprar algo que ya haga esto. El objetivo es poder tratar esto como un periférico de hardware.
Luego, puede desarrollar controladores USB o Ethernet que se conectarán a estos dispositivos. Tendrá flexibilidad en los protocolos de host (¿Necesita usar RS485 esta vez? ¡No hay problema!), Puede usar diferentes números de motores y tiene una mayor modularidad para diseñar, probar, depurar, reparar y reemplazar. Las únicas razones por las que intentaría implementar algo como esto en un solo controlador serían las restricciones extremas de costo/tamaño y/o la falta de módulos de hardware (como PWM? ¿Me perdí algo?) que podrían hacer esto sin interrumpir el host. procesador.
La pregunta principal es ¿qué va a manejar realmente los datos que llegan por cable? La cantidad de basura (cosas que no están dirigidas a usted) que puede proporcionar Ethernet es asombrosa. Si va a utilizar un MCU de gama baja (PIC24F), necesitará algún tipo de coprocesador, por ejemplo, un ENC28J60 , para proporcionar filtrado de direcciones MAC como mínimo.
Alguien en el chat mencionó que el PIC24F tiene prioridades de interrupción, por lo que si mantener la isocronicidad es fundamental, puede configurar la prioridad del temporizador más alta.
Un pequeño aparte: tenga en cuenta que TCP/IP y Ethernet no son deterministas (independientemente). Por ejemplo, no espere poder enviar un comando a través de Ethernet para detener su motor paso a paso "ahora" cuando está justo en la posición X y responder repetidamente.
Probablemente necesitará usar un módulo PWM para generar sus pulsos. He tenido dificultades para generar pulsos en el software a frecuencias> 1kHz en PIC. Simplemente busque un PIC con el número correcto de módulos CCP/ECCP y salidas PWM para su aplicación.
nick t
PICtucerebro
nick t