TODOPIC
Microcontroladores PIC => Pic32 => Mensaje iniciado por: remi04 en 21 de Febrero de 2019, 07:48:27
-
Ahora que estoy de baja por rotura de un pié tengo tiempo para iniciarme en los pic32. Me regalaron hace poco una placa Starter DM320001 que viene con un MX360F512L y un microUSB que va a un 18f4550 que sirve para gestionar la comunicación con MPLAB, la veo limitadilla la verdad, solo tiene 3 pulsadores y 3 led pero como dice el refrán "a caballo regalado....."
Me he pedido a Farnell una placa de expansion IO DM32002 para poder tener acceso a todo el micro.
He descargado e instalado el compilador XC32 y el pack de Plib.h y lo tengo ya funcionando compilando ejemplos sin problema.
Sabiendo que vengo de CCS (integrado en MplabX) y de los pic18, ¿Por donde me recomendais que empiece?. ¿ Es muy diferente CCS de XC? Lo poco que he visto me hace indicar que los #use rs232, i2c y las formas de usar los módulos cambia aunque está todo explicado en los Plib.h. El delay_ms asi como otras funciones las tendría que hacer por que en XC32 no se contemplan (Supongo que por que son cosas nativas del CCS).
Otra cosa que veo es que me lanza Warning advirtiendo que las librerias Plib dejarán de tener soporte en futuras versiones, he eliminado esos warning poniendo un #define _SUPPRESS_PLIB_WARNING y funcionan. ¿ Debo "no aprender" ha usarlas y empezar directamente con la alternativa "que no sé aun cual es"??.
Como veis, estoy mas perdido que Mario Bross en una playstation.
-
Hola remi04, el motivo por el que te sale ese aviso de las Plib es porque se ha pasado a él configurador nuevo que también se integra en le MPLAB llamado Mplab Harmony, por si quieres irle echando un vistazo, yo de usar pic32 solo usaría Harmony al menos para que te configure el código y después tu ya o te haces tus propias librerías en base a las de harmony o usas librerías descargadas...
Yo intente usar los pic32 pero enseguida me di cuenta que no merecía la pena (quiza paar algo concreto...) y me pase a los ARM, con stm32 que le vi menso problemas/bugs y mas ventajas aunque de vez en cuando pruebo los nxp y renesas que son mucho mejores con el fin de irme adaptando a su ide e ir probando todo, pero ya estoy familiarizado con stm y cuesta sobre todo cuando no hay tiempo ni para echar una siesta :D :D
-
Estás a tiempo de elegir el buen camino, seguir en el mundo PIC, cerrado al resto de fabricantes, micros caros, placas de evaluación más caras aún, compilador de pago carísimo el de 32 bits (XC32), etc..
ARM, todo el entorno de desarrollo gratuito, compilador GCC C/C++ gratuito sin limitaciones, micros baratos, placas de evaluación a precio de risa (tanto de ST como de NXP), comunidad enorme, soporte oficial del fabricante (el de NXP es espectacular), portabilidad entre fabricantes, IDE basado en Eclipse en muchos de ellos (ST Workbench, NXP MCUXpresso).
Hace mucho que dejé los PIC32 y desde entonces todo han sido ventajas. En principio me decanté por los STM32, luego probé los Kinetis, y ahora estoy pasándome a los RT1020 de NXP, unos Cortex M7 500Mhz en LQFP100 y LQFP144, a precio de risa, 6 euros la pieza en Europa.
Ahora tu eliges "Neo", seguir en la Matrix, o abrirte al mundo real con infinitas posibilidades.
(https://i.imgur.com/4UkRIhT.jpg)
-
Tengo eclipse con Gcc c/c++ que uso para hacer aplicaciones Windows para la consola en c++.
Con los ARM ¿me dices que me sirve exactamente ese compilador??
-
Tengo eclipse con Gcc c/c++ que uso para hacer aplicaciones Windows para la consola en c++.
Con los ARM ¿me dices que me sirve exactamente ese compilador??
Con Windows he usado QT Creator, creo que este trabaja con el compilador MinGW, que es la versión GCC para Windows. Si trabajas en Linux, es GCC para cualquier plataforma hardware soportada, ARM, x86, etc. Por ejemplo, para Raspberry, también se usa GCC, al margen del editor que uses, yo he usado QT Creator, pero ultimamente prefiero un editor pelao como Geany y compilar en la linea de comandos con el Make.
Si ya has trabajado con GCC, te resultará muy fácil entrar en el mundo ARM.
Y en cuanto al Editor, lo mismo, si ya conoces Eclipse, ST para los STM32 usa el Workbench que está basado en Eclipse, y NXP usa el MCUXpresso también basado en Eclipse. Ambos son Eclipse con un plugin muy elaborado, ST añade Cube como generador de código para configurar la perifería, y NXP las Config Tools que vienen a hacer lo mismo.
Realmente creo que XC32 de Microchip, está basado también en GCC, pero los muy "listos", se lo apropiaron, le metieron una limitación a la optimización y te lo venden por 1200 euros. Los fuentes estaban a disposición de cualquiera, por el tipo de licencia que les obliga a darlos, y aunque el sistema que limita la optimización no es muy difícil de anular, ni por esas me iría a trabajar con los PIC32. Ten en cuenta que XC32, sin acceso a la optimización, te va a generar un objeto que va a tener el doble de tamaño, y va a ser mucho más lento que si estuviera optimizado.
-
No solo limita la optimización sino también que solo compila hasta 64 Kb de flash.
Perfecto. Tengo eclipse funcionando con MinGw por lo que en principio si quisiera seguir en eclipse solo tendría que instalar los plugin para ARM ¿no? . Tampoco pasa nada por usar otro editor, ¿ cual se suele usar mas?
La verdad es que aunque parezca una tontería, pero tengo códigos de aplicaciones para los pic18 que si yo hubiese podido hacerlos en POO hubiese ganado bastante.
-
No solo limita la optimización sino también que solo compila hasta 64 Kb de flash.
Ufff, entonces no vale para nada, para jugar un rato y para que los estudiantes hagan prácticas.
Perfecto. Tengo eclipse funcionando con MinGw por lo que en principio si quisiera seguir en eclipse solo tendría que instalar los plugin para ARM ¿no? . Tampoco pasa nada por usar otro editor, ¿ cual se suele usar mas?
Creo que MinGW no genera código para ARM, solo para x86, tendrías que instalar GCC, o mejor usas el producto de cada fabricante que ya te lo instala y configura todo. Para STM32 el System Workbench que a su vez te instala también Cube, y para NXP el MCUXpresso que también lo instala y configura todo.
Eso de partir de un Eclipse pelao y luego meterle el Plugin, se hacía al principio con los STM32, hace mucho tiempo que ST te da el paquete completo que te lo instala y configura todo, listo para usar. Y con el MCUXpresso de NXP, siempre se ha dado listo para usar, el plugin no está por ahí suelto para instalarlo en un Eclipse vacío.
Para los STM32 de ST:
https://www.st.com/en/development-tools/sw4stm32.html
Para los NXP (Kinetis, LPC, i.MX)
https://www.nxp.com/support/developer-resources/software-development-tools/mcuxpresso-software-and-tools/mcuxpresso-integrated-development-environment-ide:MCUXpresso-IDE
-
Y estas aplicaciones van en gcc ¿no?, es decir C y C++ puro ¿no?
He visto también que en los pic32 la información disponible es pobre y ya en Español pues nulo. Supongo que es por eso ¿no? Son muy poco usados..
-
No solo limita la optimización sino también que solo compila hasta 64 Kb de flash.
Ufff, entonces no vale para nada, para jugar un rato y para que los estudiantes hagan prácticas.
Perfecto. Tengo eclipse funcionando con MinGw por lo que en principio si quisiera seguir en eclipse solo tendría que instalar los plugin para ARM ¿no? . Tampoco pasa nada por usar otro editor, ¿ cual se suele usar mas?
Creo que MinGW no genera código para ARM, solo para x86, tendrías que instalar GCC, o mejor usas el producto de cada fabricante que ya te lo instala y configura todo. Para STM32 el System Workbench que a su vez te instala también Cube, y para NXP el MCUXpresso que también lo instala y configura todo.
Eso de partir de un Eclipse pelao y luego meterle el Plugin, se hacía al principio con los STM32, hace mucho tiempo que ST te da el paquete completo que te lo instala y configura todo, listo para usar. Y con el MCUXpresso de NXP, siempre se ha dado listo para usar, el plugin no está por ahí suelto para instalarlo en un Eclipse vacío.
Para los STM32 de ST:
https://www.st.com/en/development-tools/sw4stm32.html
Para los NXP (Kinetis, LPC, i.MX)
https://www.nxp.com/support/developer-resources/software-development-tools/mcuxpresso-software-and-tools/mcuxpresso-integrated-development-environment-ide:MCUXpresso-IDE
Para micros stm32 mejor utilizar Atollic que es el IDE oficial de ST desde que lo compró hace un tiempo, el system workbench es de una empresa externa y ya se queda atrás en comparación. Ojo, que también está basado en eclipse pero esta todo mejor integrado y mejores funcionalidades.
https://atollic.com/
-
Si quieres probar los micros de Renesas tienes el e2Studio, tambien basado en eclipse o mejor dicho, eclipse con plugins, este es un poco mas complicado que STM y NXP por lo poco que he visto pero de momento lo veo como mejor opcion aunque aun no ha sacado MCUs con mas de 240MHz y sus micros son caros... pero lo bueno... normalmente hay que pagarlo :D :D :D
https://www.renesas.com/in/en/products/software-tools/tools/ide/e2studio.html
Si vienes de Pic la opcion que mejor se entiende y por tanto sera mas facil de empezar para mi ha sido el SystemWorkbench para stm32 junto a cubeMX que es el configurador, aun no probé atollic como IDE asi que no puedo opinar de el...
-
Hola! Si vas arrancar con Pic32, como te comentan, usar harmony. Es lo ultimo y no tendras problemas para migrar a otro pic32 mas moderno como un PIC32MZ.
Y en arm, mucha info tenes de stm. Nxp andan medios olvidados.. y si no queres hacerte quilombo con compiladores y esas cosas busca mbed.
Saludos!
-
Hola! Si vas arrancar con Pic32, como te comentan, usar harmony. Es lo ultimo y no tendras problemas para migrar a otro pic32 mas moderno como un PIC32MZ.
Y en arm, mucha info tenes de stm. Nxp andan medios olvidados.. y si no queres hacerte quilombo con compiladores y esas cosas busca mbed.
Saludos!
Gracias a todos. Suky, he dejado Harmony descargando y he tenido que salir, es un giga y pico. Harmony ¿es un compilador o sólo un configurador?
-
Nxp andan medios olvidados..
Discrepo totalmente.
NXP con su serie i.MX está ofreciendo un producto extraordinario, su entorno de desarrollo MCUXpresso desde la versión 10.1 es una auténtica maravilla, ya vamos por la 10.3 y no dejan de sorprender por lo mucho que están mejorando el producto, mejoras reales y útiles, no cosméticas como hacen otros fabricantes.
A ver que fabricante ofrece un Cortex M7 500Mhz en LQFP por 6 euros (o por 4 Euros, si nos vamos a los nuevos RT1015). ST ofrece su serie H7, que es extremadamente cara (19-20 Euros la unidad) y no llega a tener la potencia (400Mhz) de la serie RT de NXP (500-600Mhz). Además los i.MX de NXP usan flash externa (QSPI, Hyperflash, SD) lo que te permite disponer de grandes cantidades de memoria de programa, también puedes conectar una SDRAM externa de hasta 512Mbit. En mi último desarrollo he conectado una SDRAM de 256Mbit para un proyecto que de otra forma no podría desarrollar con micros de otros fabricantes, y todo esto con un coste irrisorio.
ST ofreció antes un buen entorno de desarrollo, en el momento que liberó el System Workbench de AC6, como plugin basado en Eclipse, luego integraron Cubemx, todo muy bien. Ahí empezó a hacerse muy popular su serie STM32, también por sus tarjetas Discovery a precio de piruleta.
NXP ha sido más lenta, probablemente por tener que integrar su serie LPC y los micros de la antigua FreeScale (Kinetis) en su nuevo entorno MCUXpresso, pero eso ya está totalmente superado desde hace tiempo, a partir de la versión 10.0. Ahora ofrecen un producto que incluso supera al de ST.
Parece que por fin, los fabricantes han entendido, que ofrecer las herramientas de desarrollo gratuitas es fundamental, para que su producto se venda. Seguramente por eso ST compró Atollic, para darlo gratis, o el entorno TouchGFX para aplicaciones gráficas. NXP debería espabilar, necesita un gestor de aplicaciones gráficas con urgencia, o puede que ya tengan algo, no lo he podido mirar.
Para mi, sin dudarlo un segundo, el futuro está en la serie i.MX de NXP, muy potentes, muy baratos y con un soporte extraordinario, incluso puedes contactar con NXP directamente y sus técnicos te contestan a cualquier duda, ST ni de lejos ofrece algo así. NXP se está centrando mucho en la serie i.MX, y en concreto ultimamente en los RT, después de sacar los RT1050 y RT1020, han seguido con nuevas referencias, los RT1015, RT1060 y RT1064.
Los RT1015 quiero probarlos, porque son LQFP, el resto son BGA (excepto el RT1020). Un Cortex M7 500 Mhz por menos de 4 euros la unidad, se abarata al eliminar Ethernet y CAN bus, aunque solo está en LQFP100. Puede ser una maravilla, y extremadamente barato, para desarrollos que no requieran esos interfaces y valga un LQFP100.
Ahora mismo de ST solo me interesan los STM32 por el interface MIPI DSI y el decodificador JPEG de los F769/779/778, para poder hacer un reproductor de video para algunos de mis proyectos. Para cualquier otra cosa estoy con NXP, hasta hace poco con los Kinetis (algo caros), y ahora sin dudarlo, con los RT1020 y probablemente con los RT1015.
(https://i.imgur.com/lg3wv18.jpg)
-
Y la comunidad a nivel software? Hardware puede existir, pero es lo mismo que pic32, se usa poco. Me da la sensacion...
-
Hola! Si vas arrancar con Pic32, como te comentan, usar harmony. Es lo ultimo y no tendras problemas para migrar a otro pic32 mas moderno como un PIC32MZ.
Y en arm, mucha info tenes de stm. Nxp andan medios olvidados.. y si no queres hacerte quilombo con compiladores y esas cosas busca mbed.
Saludos!
Gracias a todos. Suky, he dejado Harmony descargando y he tenido que salir, es un giga y pico. Harmony ¿es un compilador o sólo un configurador?
En realidad son las librerias mas configurador que podes integrar con mplabx.
-
Gracias de nuevo.
De momento me he decidido por comenzar con los PIC32, ya que tengo el hardware no creo que pierda nada, de hecho ya tengo varios códigos corriendo. Mas adelante ya daré el salto a otras plataformas.
Eso si, ¿ Os ha sucedido que al pulsar el boton "compilar", bien desde el martillito o desde el boton "Run" se os apaga el programa entero y os tira al escritorio??. Me pasa de vez en cuando.
Usando MPLABX 4.05 y compilador XC version 2.15
Es molesto, lo mismo te pegas dos horas trabajando que no pasa, que lo mismo te pasa varias veces muy seguidas y claro, como no hayas guardado pierdes todo lo que hayas modificado desde la ultima vez que pulsaste "compilar".
El mismo MPlabx con CCS no le pasa. Es con el XC.
Descarto que sea algo del hardware del starter kit por que no le da tiempo ni a llamarlo, es pulsar el martillito y plaff... al escritorio y Mplab cerrado drásticamente y perdiendo los cambios que no se hubieren guardados.
-
Y la comunidad a nivel software? Hardware puede existir, pero es lo mismo que pic32, se usa poco. Me da la sensacion...
Los foros de NXP no están mal, yo diría que mejor que los de ST, además sueles recibir respuestas directas de técnicos de NXP, en los de ST si alguien te contesta es usuario, nunca un técnico oficial de ST.
En cualquier caso a mi me interesa más el soporte técnico (gratuito) que te ofrece directamente NXP por privado, eso no lo da ST.
En general los foros de cada fabricante, no tienen mucho movimiento, a nivel de comunidad puedes encontrar mucho más soporte en los foros de EEVBlog. http://www.eevblog.com/forum/microcontrollers/
-
Y la comunidad a nivel software? Hardware puede existir, pero es lo mismo que pic32, se usa poco. Me da la sensacion...
Los foros de NXP no están mal, yo diría que mejor que los de ST, además sueles recibir respuestas directas de técnicos de NXP, en los de ST si alguien te contesta es usuario, nunca un técnico oficial de ST.
En cualquier caso a mi me interesa más el soporte técnico (gratuito) que te ofrece directamente NXP por privado, eso no lo da ST.
En general los foros de cada fabricante, no tienen mucho movimiento, a nivel de comunidad puedes encontrar mucho más soporte en los foros de EEVBlog. http://www.eevblog.com/forum/microcontrollers/
Te das cuenta en que tan actualizadas tienen las librerias en general para esos micros, poco. En cambio ST por ejemplo, siempre mas al dia y eso es la comunidad.
Saludos
-
Te das cuenta en que tan actualizadas tienen las librerias en general para esos micros, poco. En cambio ST por ejemplo, siempre mas al dia y eso es la comunidad.
Saludos
Nadamos en mundos distintos, porque mi percepción es totalmente la contraria.
El entorno que mejor documentado me he encontrado, en cuanto a librerías y código fuente de ejemplo, ha sido Arduino, a pesar de que no soy un defensor de ese invento. Lo menciono porque es lo más parecido, en ese aspecto, a lo que ofrece NXP con MCUXpresso, una gran colección de código fuente de ejemplo que puedes importar directamente desde el IDE.
En cuanto a ST, todavía estoy esperando que, en sus foros, representantes oficiales de ST, den una solución al acceso a tarjeteros SD por SPI, algo que otra gente les pidió hace bastante tiempo también. Busqué y probé infinidad de código y no me convenció ninguno, por lo mal documentados que estaban. Cubemx solo soporta SDIO. En general ST te deja a tu suerte, en cuanto Cube te ha configurado el dispositivo, puedes urgar por los fuentes y vas encontrando cosas, pero como algo no esté documentado, ni soportado en sus librerías, estás perdido, y ya puedes buscar y buscar (tampoco hay tanto por Google, solo un sitio que es bastante conocido y poco más) que no vas a encontrar mucho.
Sobre NXP y MCUXpresso, es todo lo contrario, solo hay que importar el SDK del micro y te encuentras con una cantidad ingente de código fuente de ejemplo, para hacer prácticamente cualquier cosa. En ese sentido es similar a Arduino, un buen conjunto de fuentes de ejemplo que puedes cargar directamente desde el IDE con la opción "Import SDK Example(s)", no hay nada parecido (que yo sepa) con los STM32.
Y si echas algo en falta, basta con ponerte en contacto con NXP y te lo facilitan. Hace poco necesitaba saber como leer el número de seríe único de los micros RT1020, no encontré nada en el SDK, así que pedí ayuda a NXP. Me contestaron en 24 horas, que me preparaban un ejemplo, y así fué, al día siguiente me lo enviaron por email, además de darme indicaciones sobre la información necesaria en el manual de referencia.
Lo he comentado en otras ocasiones, lo MAS importante es que un entorno de desarrollo vaya equipado con una buena colección de programas ejemplo para manejar los periféricos más usuales. No se puede dar un IDE pelao y que el usuario se las apañe buscando por ahí. Eso, y que el entorno de desarrollo, compilador incluido, sean gratuitos, es la clave para que un producto triunfe.
Un ejemplo de producto fallido, por ejemplo, es Atmel Studio. Lo probé hace tiempo porque quería usar los SAM Cortex M7, y al final lo desestimé por lo desastroso que resultaba encontrar algún fuente de ejemplo, para las cosas que quería hacer. Al final lo abandoné y busqué otro producto. Es un producto que daba la sensación de estar medio abandonado, con poca y mala documentación, unos pocos programas de ejemplo y solo para algunos de sus micros, desesperante.
-
Gracias de nuevo.
De momento me he decidido por comenzar con los PIC32, ya que tengo el hardware no creo que pierda nada, de hecho ya tengo varios códigos corriendo. Mas adelante ya daré el salto a otras plataformas.
El tiempo es un recurso valioso, si vas a empezar con un microcontrolador de 32 bits yo me iría directo a ARM como te han comentado donde tienen en común las soluciones de muchos fabricantes, no invertiría tiempo en los PIC32.
-
Sobre NXP y MCUXpresso, es todo lo contrario, solo hay que importar el SDK del micro y te encuentras con una cantidad ingente de código fuente de ejemplo, para hacer prácticamente cualquier cosa. En ese sentido es similar a Arduino, un buen conjunto de fuentes de ejemplo que puedes cargar directamente desde el IDE con la opción "Import SDK Example(s)", no hay nada parecido (que yo sepa) con los STM32.
En el repositorio del CubeMX (ubicado en la carpeta donde se instala) hay muchísimos ejemplos clasificados para todas las placas discovery y nucleo. Hay ejemplos de todos o casi todos los periféricos usando polling, interrupcions, transferència mediante DMA, etc... También son proyectos listos para importar en keil y el system workbench. Con todo eso más el reference manual puede ir saliendo todo.
-
En el repositorio del CubeMX (ubicado en la carpeta donde se instala) hay muchísimos ejemplos clasificados para todas las placas discovery y nucleo. Hay ejemplos de todos o casi todos los periféricos usando polling, interrupcions, transferència mediante DMA, etc... También son proyectos listos para importar en keil y el system workbench. Con todo eso más el reference manual puede ir saliendo todo.
El sistema de importación o apertura de ejemplos, de haberlo, no es nada intuitivo, porque a simple vista no aparece por ninguna parte, a diferencia de Arduino y MCUXpresso, que lo tienen bien visible.
Que hayan ejemplos, pero estén tan escondidos, es otro fallo garrafal de diseño del entorno de desarrollo de ST.
Así de accesible, rápido e intuitivo es la apertura de cualquiera de los múltiples ejemplos de código fuente en Arduino y MCUXpresso:
(https://i.imgur.com/KxgFqQ2.jpg)
(https://i.imgur.com/YMrwUty.jpg)
(https://i.imgur.com/wxAWAuV.jpg)
-
Ahora, veamos el System Workbench de ST, como diría un mago, "Nada por aquí, nada por allá". Estar, estarán (o no), pero en el rincón más recóndito imaginable, nada visible a la vista.
Fatal por parte de ST, es algo que debería de arreglar con urgencia.
¿ Alguien ve una opción que ponga "Abrir ejemplos", "Importar ejemplos" o similar, que le pinchemos a esa opción y nos salgan toneladas de fuentes de ejemplo ?, yo no, ni en el editor de C++, ni en el de Cubemx.
Ya se que por los directorios de instalación hay algo, pero eso no son maneras de presentarlo, por ahí escondido y dejado de la mano de dios, para que el usuario se busque la vida y averigüe como importarlos, si es que se llega a enterar de que existen.
(https://i.imgur.com/Qc5Mhd4.jpg)
(https://i.imgur.com/Fq3pMET.jpg)
(https://i.imgur.com/zjic5sj.jpg)
-
No voy a inclinarme por uno u otro, ya que me dan lo mismo.. Voy a opinar sobre los IDEs y ejemplos.
Primero no es ciencia espacial importar un proyecto. El IDE de Arduino es mejor pegarse un tiro en la entrepierna cuando queres hacer algo un poquito mas avanzado.
Segundo:
Vos tenes que recordar que son 2 cosas distintas...
Uno es un IDE preparado POR la empresa para sus micros.
El/Los otros son IDEs de terceros que dan soporte o son para esos micros. Pero NO son de la empresa.. Como el System Worbench, el Atollic, CoIDE, etc. son todos de 3eros, por eso existen varios IDEs para los STM32... Los ejemplos de los perifericos son geniales, los demas ejemplos son de la comunidad.
Distinto al de NXP que te da ese IDE directamente.. Algo asi como CCS de Texas Instrument. En el Code Composer Studio tenes la pantalla de bienvenida, donde seleccionas el micro y podes buscar ejemplos desde internet, con un click bajarlos e importarlos y es Eclipse. Necesito otro programa para configurar los pines es lo feo.
Fatal por parte de ST, es algo que debería de arreglar con urgencia.
No es de ST...
-
Distinto al de NXP que te da ese IDE directamente.. Algo asi como CCS de Texas Instrument. En el Code Composer Studio tenes la pantalla de bienvenida, donde seleccionas el micro y podes buscar ejemplos desde internet, con un click bajarlos e importarlos y es Eclipse. Necesito otro programa para configurar los pines es lo feo.
MCUXpresso es Eclipse, igual que el System Workbench de ST, solo que está mucho mejor hecho.
Fatal por parte de ST, es algo que debería de arreglar con urgencia.
No es de ST...
Es un producto, auspiciado y publicitado por ST, que es lo mismo.
Antes de que ST comprara Atollic, no tenían nada propio hasta que AC6 sacó el plugin del System Workbench. Hay videos por Youtube, donde representantes oficiales de ST presentan el System Workbench, así que algo de responsabilidad tendrán, ¿ no ?.
-
Ahora, veamos el System Workbench de ST, como diría un mago, "Nada por aquí, nada por allá". Estar, estarán (o no), pero en el rincón más recóndito imaginable, nada visible a la vista.
Fatal por parte de ST, es algo que debería de arreglar con urgencia.
¿ Alguien ve una opción que ponga "Abrir ejemplos", "Importar ejemplos" o similar, que le pinchemos a esa opción y nos salgan toneladas de fuentes de ejemplo ?, yo no, ni en el editor de C++, ni en el de Cubemx.
Ya se que por los directorios de instalación hay algo, pero eso no son maneras de presentarlo, por ahí escondido y dejado de la mano de dios, para que el usuario se busque la vida y averigüe como importarlos, si es que se llega a enterar de que existen.
(https://i.imgur.com/Qc5Mhd4.jpg)
(https://i.imgur.com/Fq3pMET.jpg)
(https://i.imgur.com/zjic5sj.jpg)
Buenas. Si que es verdad que no están tan a la vista como en NXP por lo que veo pero sólo buscando un poco en su web te puedes descargar decenas de proyectos listos para usar de todas las variantes de ARM que tienen. También mirando el blog de atollic explican como importarlos todos de manera fácil.
http://blog.atollic.com/how-to-import-thousands-of-stm32cube-example-projects-into-truestudio
Todo y así por mi parte yo solo trabajo con editor de texto (sublime/atom/visual studio code) junto con make ya que el CubeMX lo genera y para mi es lo más cómodo, los IDE son pesados, lentos y con demasiada parafernalia que no sirve para nada o sólo se usa cada mucho tiempo. Sólo recurro al uso de atollic si tengo que depurar algo muy complicado, pero por norma general si el programa está bien estructurado con prints vía uart/usb ya voy bien. Algo que también me gusta de ST es que el CubeProg permite ejecutarlo vía comandos y por lo tanto se pueden integrar las órdenes en el makefile, automatizando todo el proceso de compilación y carga del programa permitiéndome probar las modificaciones de forma muy rápida.
Al final lo importante es estar cómodo en una plataforma para avanzar rápido con los menos problemas posibles, pero está bien comentar todo esto para ver las distintas opciones.
-
No se si lo han notado, pero MCHP no ha sacado un nuevos PIC32 con núcleo MIPS, está dando más impulso a los SAM32 (Atmel) inclusive hay futuros SAM32 que aún no salen a la luz.
Las nuevas herramientas de desarrollo como el PICkit 4 tienen como CPU un SAM32 y parece que van a renombralos PIC32C...
También hay rumores que con la nueva arquitectura RISC-V, MCHP podría sacar nuevos MCU de 32 bits pero que no serán MIPS, ni ARM.