¿Controlador de señal digital con cadena de herramientas GNU?

¿Algún fabricante ofrece un controlador de señal digital (que básicamente significa un microcontrolador con alguna funcionalidad DSP como una instrucción MAC y otras cosas) al que podría compilar software con GCC? Aparentemente, dsPIC usa el compilador C30 propio de Microchips, que es un derivado de GCC pero no es gratuito (como en el código fuente gratuito).

Solo necesitaría algunos canales ADC, dos canales DAC y una FPU, así que nada especial.

Me gustaría tratar de mantenerme alejado de las cadenas de herramientas de un solo fabricante si es posible.

"código fuente gratuito", ¿es gratuito como "cerveza gratis" o gratuito como "libertad de expresión"?
como en la libertad de expresión. Sé que varios fabricantes ofrecen cadenas de herramientas gratuitas (como en la cerveza), pero me gustaría evitarlas.
¿Qué pasa con la cadena de herramientas SDCC? Soporta micros C30?
@Dago: DSP no significa "básicamente con FPU" (unidad de punto flotante) en absoluto. No es inusual que un DSP tenga solo capacidades aritméticas de punto fijo. Lo que es mucho más típico para un DSP es la arquitectura Harvard (separación de memorias de datos y programas, buses de datos y programas separados).
Sí, ninguno de los dsPIC tiene una FPU. Supuse que realmente querías decir motor DSP, que está optimizado por hardware para realizar convoluciones rápidas en matrices de memoria. Si realmente te refieres a FPU (unidad de punto flotante), entonces tu selección será mucho más limitada.
Sí, el motor DSP es lo que quise decir :)

Respuestas (3)

No menciona qué tipo de energía necesita, pero los dispositivos AD Blackfin y TI OMAP son compatibles con cadenas de herramientas de código abierto (gcc, etc.). Para OMAP, consulte OpenEmbedded @ www.openembedded.org/wiki/Main_Page, para Blackfin consulte ucLinux @ www.uclinux.org/.

Incluso si parecen exagerados en cuanto a capacidad (hasta alrededor de 1 GHz ARM + DSP), son pequeños y eficientes energéticamente, por ejemplo, consulte Gumstix Overo @ www.gumstix.com/store/index.php?cPath=33 para conocer una gama de tableros OMAP y una buena comunidad de desarrolladores @ gumstix.org).

OMAP también se usa en Beagleboard, que es un excelente lugar para comenzar.

(Disculpas, la primera publicación en electronics.stackexchange está tan limitada a 2 hipervínculos, ¡de ahí el desorden anterior!)

MCU basados ​​en núcleo ARM Cortex-M4(F).

No es un DSP completo, pero tiene algunas "funcionalidades similares a DSP":

  • ciclo único 32x32->64 operación MAC.
  • opcionalmente FPU (en la variante F).

Es compatible (incluido el soporte de FP de hardware) por GCC desde https://launchpad.net/gcc-arm-embedded .

ARM también proporciona rutinas DSP optimizadas en la biblioteca CMSIS DSP.

El compilador de Microchip se basa en GCC y, por lo tanto, su fuente es abierta. Microchip agregó algunas de sus propias cosas para las optimizaciones más avanzadas, pero el compilador básico es gratuito y su fuente está disponible.

Intentar ser independiente del proveedor con compiladores de microcontroladores también es un poco tonto. Sí, C es más o menos un estándar, pero se deben realizar mejoras en cualquier instancia en particular para usar bien la arquitectura. Se requerirán algunas diferencias en el código fuente entre las diferentes familias de microcontroladores sin importar qué compilador use. El hecho de que dos compiladores estén basados ​​en GCC no significa que el código de la aplicación sea compatible con el código fuente.

En el mejor de los casos, la compatibilidad del código fuente se aplicará a las sentencias C genéricas y la aritmética. Sin embargo, la mayor parte del firmware incorporado en sistemas tan pequeños con recursos limitados administrará los periféricos de hardware especializados. Ese código será específico para esa familia y, a veces, para la pieza, por su propia naturaleza. Exigir la compatibilidad general con C es el 5 % de la solución e ignorar el problema del 75 % de la portabilidad entre diferentes dispositivos en primer lugar.

Además, no tiene mucho sentido exigir que el código fuente del compilador esté abierto. ¿De verdad vas a entrar allí y hacer cambios? Es mejor dejarlo en manos de los expertos cuyo trabajo es a tiempo completo. Para un proyecto personal único, tiene sentido usar un compilador gratuito, pero la mayoría de los proveedores tienen algún tipo de compiladores gratuitos. Todos los compiladores de Microchip tienen versiones gratuitas que solo se diferencian de las completas en que algunas de las optimizaciones avanzadas están desactivadas. En la mayoría de los casos esto es irrelevante. Si está empujando los límites, entonces, para una sola vez, use el siguiente chip de tamaño superior, y siempre hay un ensamblador disponible si realmente necesita el espacio de código y la velocidad para partes particulares del sistema.

Nunca dije que quería que el código fuera independiente del proveedor. Simplemente no quiero admitir código no libre a menos que tenga que hacerlo. Me gustaría reservar la posibilidad de arreglar el compilador (y lo he hecho con un par de proyectos anteriores) si es necesario.
peligrosaprototypes.com/2011/08/30/… Aquí hay un artículo sobre Microchip y material de código abierto que refleja mis sentimientos bastante bien.