Elegir microcontrolador para control de motor trifásico.

Hola a todos.

Tengo hecho y funcionando varios programas para control de motor trifásico con MC908MR32 pero como muchos sabran este micro ya no se produce y los que aun se venden son muy caros por esa razón.
Tengo que cambiar de microcontrolador y no se que hay de lo último en la actualidad. El sucesor del 908MR32 puede ser el 9S08PA60 pero tambien es de 8 bits, tiene ya algunos años (no muchos) y me gustaria cambiar a 16bits.
Se que hay algunos muy específicos para control de motores pero prefiero alguno mas general para poder reutilizar el soft que ya tengo y solo modificar las rutinas de nivel mas bajo.
Tiene que tambien conectar además del PWM, muchas entradas, salidas, botones, un lcd, comunicacion serie, etc. Asi que tiene que tener muchas patas.
Alguien me puede recomendar alguno?

Gracias.
 
Hola, a cuánta cantidad le llamas "muchas patas"? Es muy relativo.
Velocidad de procesamiento?
Necesitas PWM en cuántos puertos?
Espacio de memoria FLASH?
RAM?
Creo que faltan aclarar varios detalles.
 
por lo memos 20 pines e/s
rx y tx para uart
ss, clk, miso y mosi para spi
4 adc
6 pwm (3+3 complementarios) para excitar el motor
por lo menos 32k de flash y 1k de ram
eeprom independiente de la flash

20Mhz de frecuencia de bus.
 
Gracias Gudino.
Los PIC he programado hace años y son medio básicos. Sirven para programas simples que hagan pocas cosas.
Este programa usa matamática de punto flotante, atiende interrupciones del pwm, interrupciones de un encoder con el que calcula posicion y velocidad del rotor.
Temporizaciones diversas. un protocolo de comunicacion serie.
Algunas señales analógicas.
Guardar parámetros. Por eso necesito que tenga EEPROM. Podria usar la propia flash siempre que pueda seguir corriendo el programa mientras la escribo en alguna parte.

Y lo tiene que atender todo al mismo tiempo por eso busco algo mas potente.
 
¿Matemática en punto flotante?
A lo mejor me equivoco pero muchas cosas se pueden hacer con una lookup table.
Es decir, no calcular el sen(wt) en tiempo real ni con N decimales... Calculas las 256 posiciones del pwm equivalentes en coma fija y las dejas en una tabla, al final vas a sacar un pwm probablemente de 8 bits o de 10 no necesitas un cálculo en coma flotante de 8 decimales.
Si vas a "emitir" un nivel analógico cada ms solo necesitas 10 valores porque los del semiciclo contrario son los mismos y los del resto de las fases también, si es cada 100μs son 100 valores de 8 o los bits que sea el pwm.
Si es cada 10μs serían 1000 valores, pero eso me parece mucha frecuencia ya.
En cualquier caso son muy pocos valores que guardar y la velocidad de consultar una tabla en ROM es muy alta.

A lo mejor se me escapa otro sitio en el que si que sea necesaria la coma flotante.
 
Pues un micro que hoy día esta en auge es el STM32, este pequeño bichito corre a frecuencias mayores que 80MHz dependiendo de la familia, trabaja con 32 bits y cuentan con grandes capacidades de memoria, por lo general mayor a 16KB. Una de las cosas interesantes es que se puede conseguir por un precio bastante bajo en relación a precio/características en comparación con otros micros de similares características e incluso comparable con micros de características inferiores.
 
¿Matemática en punto flotante?
A lo mejor me equivoco pero muchas cosas se pueden hacer con una lookup table.
Es decir, no calcular el sen(wt) en tiempo real ni con N decimales... Calculas las 256 posiciones del pwm equivalentes en coma fija y las dejas en una tabla, al final vas a sacar un pwm probablemente de 8 bits o de 10 no necesitas un cálculo en coma flotante de 8 decimales.
Si vas a "emitir" un nivel analógico cada ms solo necesitas 10 valores porque los del semiciclo contrario son los mismos y los del resto de las fases también, si es cada 100μs son 100 valores de 8 o los bits que sea el pwm.
Si es cada 10μs serían 1000 valores, pero eso me parece mucha frecuencia ya.
En cualquier caso son muy pocos valores que guardar y la velocidad de consultar una tabla en ROM es muy alta.

A lo mejor se me escapa otro sitio en el que si que sea necesaria la coma flotante.
Hola.
La funcion seno esta dibujada un semiciclo con una tabla de 512 bytes. Es innecesario e imposible hacerlo con la funcion seno del C a un frecuencia de modulacion es de 15Khz.
Con punto flotante hago la aceleración, desaceleración y detención del motor que son variables.
Todo eso esta funcionando ya. Solo que necesito mudarlo a otro micro.
Pues un micro que hoy día esta en auge es el STM32, este pequeño bichito corre a frecuencias mayores que 80MHz dependiendo de la familia, trabaja con 32 bits y cuentan con grandes capacidades de memoria, por lo general mayor a 16KB.

Suena a demasiado pero es interesante si el precio es bajo.
Voy a averiguar.
Gracias.
 
En cualquier caso, si se puede, hay que hacer el ejercicio de usar enteros o coma fija que para el caso es lo mismo.
La captura de la aceleración vendrá de una CCU o semejante que da un valor entero múltiplo de la frecuencia de reloj.
No me lo he planteado pero creo que eso sale en coma fija.

Si he dicho algo que no és, pido disculpas, no pretendo crear polémica o "ser más listo que nadie", solo aportar ideas.
 
Scooter no se a que te referis con la captura de la aceleracion.
La aceleración y velocidad nominal la calcula y ejecuta el programa. No la captura de otro lado.
¿Que es CCU?
 
Capture
Compare
Unit

Suponía que tenías una realimentación de la velocidad real de giro, que uno de los modos de medirla es mediante una CCU.
Si solo"emites" frecuencia, no la has de calcular, la sabes per sé porque es lo que estás emitiendo.
 
ARM de cualquier empresa que cumpla con los requerimientos de búsqueda.

En particular yo uso los LPC de nxp y los modelos 15xx tienen una algo muy interesante que es cambiar las funciones de los pines de forma similar a una FPGA, eso ayuda muchísimo a la hora de diseñar el PCB.
 
Capture
Compare
Unit
... no la has de calcular, la sabes per sé porque es lo que estás emitiendo.
El programa trabaja en lazo abierto.
Lo que calculo es la rampa de aceleración. la velocidad máxima para la longitud a recorrer y cuando empezar a desacelerar hasta detenerse. Todo en funcion de la posicion de la cuenta de pulsos del encoder.
 

Dr. Zoidberg

Well-known-Papá Pitufo
Entonces no trabaja en lazo abierto, si hay un encoder en el sistema.
Nono, si que trabaja en lazo abierto, solo que el encoder lleva la posicion absoluta para hacer la planificacion de trayectoria, pero no cierra ningun lazo de control con el encoder.
La trayectoria va por un lado y el encoder por otro, y solo se juntan en "los extremos" del perfil de velocidad.

No es lo que yo haría, pero si le funciona sin error..
 
Pues partiendo de que la información del encoder no es punto flotante, son enteros...
Así, sin pensar, yo diría que eso se puede hacer en coma fija o con enteros.

No será el mismo caso, pero hace años estuve haciendo un tema de control de velocidad.
Claro, la velocidad es el inverso del periodo de giro de la rueda o del encoder o lo que sea y luego se multiplicaba por la distancia de nosequé...
Con enteros el inverso de algo es 0 y el resto, con lo que pierdes la información.
Pero si no aplicaba la propiedad conmutativa (santo grial pero no en enteros) y primero multiplicaba y luego dividía la información ya no desaparecía.
Si no recuerdo mal multiplique por 100 o por 1000 para tener coma fija con xxx,000
Lo he dicho de memoria y lo mismo no es eso lo que hice exactamente, pero fue algo así de cambiar el orden lógico de las operaciones y añadir ceros para tomar coma fija y entonces se podía operar con enteros.
Además me peleé para que con 16 bits cupiese todo y hubiera que mover números pequeños.
 
Última edición:

Dr. Zoidberg

Well-known-Papá Pitufo
Hace muuuuuchos años escribí en assembler del 80C196KB una biblioteca de punto fijo de 32 bits: los 8 menos significativos era la parte decimal y el resto era la parte entera.
Ese micro tenía multiplicacion y division (enteras) por hardware, y operaba nativamente en 16 bits con resultados en 32 bits, asi que las rutinas eran bastante simples y compactas.
Y sí, el encoder siempre es entero pero las constantes de mi PID eran con decimales.
 
Para los interesados, un procesador muy interesante para la aplicación de control de motores es el NXP (de la fusión de Freescale y Phlips) de la familia K64 MK64FN1M0LL12 basado en el estandar ARM Cortex M4 de 32 Bits, la tarjeta de desarrollo es la FRDM-K64F (Cuesta unos 50 USD en MOUSER), programable por CodeWarrior (libre con limitación del tamaño del programa) o el software libre MBED. Este procesador es muy avanzado, soporta casi todos los protocolos de comunicacions (I2C, I2S, SPI, CAN, UART, SDHC), ADC de 16 bits, DAC de 12 bits, comparadores análogos, varios canales PWM, 1 MB de Flash, 256 SRAM, 66 I/O, 120 MHz, trabaja con punto flotantante.
 

Temas similares


Arriba