Plataformas uC a considerar para una CPU más rápida y más de 30 pines GPIO

Estoy construyendo un proyecto de Persistencia de Visión con 120 leds RGB (=360 líneas totales a controlar). Nos hemos decidido por el TLC5940 para controlar los LED (y podríamos estar abiertos a cambiar esto); sin embargo, ahora tenemos un problema para llevar los datos lo suficientemente rápido a los chips del controlador LED. Actualmente estamos usando chips de clase ATmega328/ATmega128 que alcanzan un máximo de 20Mhz, y no podemos procesar los datos para cargarlos en los TLC5940 lo suficientemente rápido. ¿Deberíamos considerar otro uC? Los deseos son:

  • Bajo costo/uC
  • Costos iniciales bajos (por ejemplo, los CPLD requieren una cierta inversión inicial para comenzar)
  • 3,0-5,0 V
  • Idealmente disponible en un paquete DIP para facilitar la creación de prototipos
  • Más de 30 líneas GPIO (para cargar los controladores LED en paralelo)

Esta pregunta puede ser un primo pobre intelectual de esta pregunta , sin embargo, creo que nuestros requisitos son algo diferentes.

Detalles: por qué ATmega328 no es lo suficientemente rápido (hasta ahora)

En el mundo ideal, deberíamos poder cargar los datos de todos los LED en menos de 746 uS (esos son los requisitos del proyecto) y, nuevamente, en teoría, si hacemos bitbang a 2 relojes/bit, deberíamos poder hacerlo en 108 uS a 20 Mhz. Sin embargo, todo el cambio de bits para decidir qué intensidad enviar a cada LED en este momento nos da tiempos de carga de 1536uS. Esto es con avr-gcc OPTLEVEL=2o OPTLEVEL=3, todo tipo de bucles desenrollados manualmente, carga paralela de todos los controladores LED y todas las técnicas de ahorro de tiempo que se nos ocurran.

¿Por qué estás golpeando el reloj? Utilice los módulos SPI o USART integrados. Eso debería ser bastante rápido.
La razón principal es que con bitbanging puedo colocar hasta 8 líneas de datos (una para cada controlador) en cada puerto, luego cargar 8 bits a la vez probando sus líneas de reloj juntas. Esto termina siendo más rápido que cargarlos en serie, creo. En cualquier caso, no es tanto "empujar los bits fuera de los puertos" lo que ocupa la mayor parte del tiempo, sino decidir qué bits deben ir aquí: muchos cambios de bits que consumen mucho tiempo. ¿Quizás debería publicar el código para eso?
En ese caso, tal vez debería tener más claro que está limitado por la CPU, no por la E/S. Como tal, "GPIO rápido" no es realmente relevante, principalmente necesita más potencia de CPU.
Creo que tienes razón. El tema cambió en consecuencia. Gracias.
Tal vez eche un vistazo al Parallax Propeller , también disponible en DIP @ alrededor de € 10 por unidad.
Sí, suena prometedor. - Por cierto, ¿estás programando en C? La codificación de piezas en ensamblador puede mejorar mucho el rendimiento, especialmente cuando se trata de operaciones bit a bit al aprovechar al máximo todas las banderas en el SREG.
Sí, estoy echando un vistazo a eso.

Respuestas (4)

Daría un paso hasta un ARM barato. Puede obtener el Freedom Board , que es un Cortex-M0+ que puede funcionar hasta 48Mhz. Además, al ser un brazo, obtendrá registros de 32 bits para que pueda hacer más por código de operación. También tiene un motor DMA, por lo que es posible que pueda descargar la carga de los LED en DMA mientras el procesador actualiza la memoria. Puede obtenerlos de Digikey , así como de los otros sospechosos habituales.

En cuanto a herramientas de desarrollo están CooCox , mbed y CodeWarrior .

Esta placa también es compatible con la plataforma mbed, que es una plataforma de desarrollo fácil de usar con herramientas, bibliotecas y una gran comunidad similar a arduino. Te ayudará a comenzar en poco tiempo. mbed.org/handbook/mbed-FRDM-KL25Z

La línea Atmel XMEGA tiene una capacidad nominal de hasta 32 MHz, es bastante económica y viene en paquetes de hasta 100 pines.

Sparkfun tiene un desglose prefabricado para el xmega128A1 para la creación de prototipos: https://www.sparkfun.com/products/9546 -- también hay un montón de kits de desarrollo que incluyen la placa XPLAIN de Atmel.

Sin embargo, consideramos XMega, dado que es menos del doble de la velocidad de reloj de ATmega, parecía que no iba a ser una solución ideal dado que necesitamos cargar los LED el doble de rápido.

Probablemente buscaría en la plataforma mbed . Es posible que pueda usar uno de sus módulos DIP como su "uC DIP", aunque también contendrá los periféricos necesarios (cristal, alimentación, etc.). Si bien esto será significativamente más costoso que comprar chips de microcontroladores desnudos, parece que no está produciendo esto en masa, por lo que no debería ser un gran problema.

Existe una gran comunidad de desarrolladores y el hardware definitivamente puede cumplir con sus requisitos de E/S y velocidad. Debido a las herramientas de desarrollo fácilmente accesibles, estos microcontroladores bastante complejos casi no tendrán tiempo de puesta en marcha.

BRAZO, si. Pero probablemente no mbed, ya que eso solo retrasa el gasto de los pocos días necesarios para aprender a trabajar con las partes desnudas; es mejor aclarar eso por adelantado y no tener sorpresas pendientes. Los TQFP son bastante accesibles.

La PIC24EP256GP204 es una máquina de 16 bits, puede funcionar a 70 MIPS y tiene 35 líneas de E/S. Desafortunadamente no está disponible en DIP.

No necesita un oscilador externo y es un dispositivo de 3.3V. Se puede programar en circuito con programadores de bajo costo como PICkit3 (alrededor de $ 70), tiene un compilador C gratuito que no optimiza (XC16: la licencia le brinda optimización) y dos IDE gratuitos con simuladores (MPLAB 8 y MPLAB X) .

Según mi experiencia, trabajar en ensamblaje en esta parte no es tan malo: uso la versión gratuita del compilador y optimizo manualmente el ensamblaje cuando es necesario.