Versiones de Hardware de la EDU-CIAA

[Santiago Germino]

Buenas noches! donde podria buscar la documentacion sobre los cambios en cada una de las diferentes revisiones de hardware de la EDU-CIAA?
Consulto ya que por ejemplo mi EDU-CIAA es v0.2 y un compañero tiene la v1.1. No tenia idea de que hubiese tantas versiones.

Gracias!
Santiago.

[Juan Manuel Cruz Beaufrere]

Santiago, toda la documentación del proyecto CIAA está en: http://www.proyecto-ciaa.com.ar/devwiki/doku.php?id=start

y la de la EDU-CIAA-NXP en particular en: http://www.proyecto-ciaa.com.ar/devwiki/doku.php?id=desarrollo:edu-ciaa:edu-ciaa-nxp

Saludos, Juan

--
-- Recibiste este mensaje porque estás suscripto al Grupo Google Embebidos32. Para postear en este grupo, escribe un email a embeb...@googlegroups.com. Para des-suscribirte, envía un email a embebidos32...@googlegroups.com. Para más opciones, visita el sitio del grupo en https://groups.google.com/d/forum/embebidos32?hl=es
---
Has recibido este mensaje porque estás suscrito al grupo "Embebidos32" de Grupos de Google.
Para cancelar la suscripción a este grupo y dejar de recibir sus mensajes, envía un correo electrónico a embebidos32...@googlegroups.com.
Para acceder a más opciones, visita https://groups.google.com/d/optout.

[Eric Pernia]

Cambio de armador y cambiaron un led de lugar con otro para que queden ordenados como semáforo. El pcb es idéntico. 

Saludos.

Eric.

[Santiago Germino]

Muchas gracias por sus respuestas! Ya habia buscado en los wikis/repos y no hay (o no encontre) ningun documento que detalle cambios entre todas las versiones de la Edu-CIAA (o entre la 0.2v que tengo yo y las demas, que es lo que me importa). Solo hay uno que detalla cambios de la nueva v1.2 (desde la v1.1, supongo).

Que paso entre la 0.2v y la 1.1v? No es un salto muy grande para no cambiar nada?

No vi esquematicos o archivos de KiCad para las versiones antiguas, aun si el cambio solo fuese el silk indicando fabricante (que no, porque la mia a simple vista tiene un cap que las demas no tienen).

Incluso pense que se habia quemado el led G del RGB porque no prende con el firmware_v2 (define LED_GREEN). Pero al mantener el reset SI prende, lo cual me indica que estaria mapeado a otra salida.

Alguna idea de todo esto?
Gracias!
Santiago.

[Eric Pernia]

Si usas la biblioteca sAPI están mapeados como LEDR, LEDG, LEDB, LED1, LED2 y LED3. Si usas LPC Open, hay que revisar el mapeo que eso lo subimos esta semana y no lo probé yo al menos.

En los PCB No más diferencias más allá de las que te pasé del pivoteo de leds (es un cambio de rollos de leds en el armador).

Así que lo que no funcione avisnos que es probable que sea de soft.

La capa board de la EDU-CIAA (de LPCOpen) se subió esta semana a pedido de JM Cruz, pero no se testeo. Recomiendo que usen la sAPI.

Saludos.

Eric.

--
-- Recibiste este mensaje porque estás suscripto al Grupo Google Embebidos32. Para postear en este grupo, escribe un email a embeb...@googlegroups.com. Para des-suscribirte, envía un email a embebidos32+unsubscribe@googlegroups.com. Para más opciones, visita el sitio del grupo en https://groups.google.com/d/forum/embebidos32?hl=es

---
Has recibido este mensaje porque estás suscrito al grupo "Embebidos32" de Grupos de Google.

Para cancelar la suscripción a este grupo y dejar de recibir sus mensajes, envía un correo electrónico a embebidos32+unsubscribe@googlegroups.com.

[Santiago Germino]

Gracias Eric, es bueno saberlo! efectivamente estoy usando LPCOpen.

Igual stuve chequeando y si, LEDG/LED_GREEN esta fisicamente conectado a la pata 81, GPIO5[1]. El problema debe ser mio porque la pista esta ok y el transistor y led funcionan, el problema es el pin del micro que parece estar muerto, al hacer esto no da tension:

    Chip_GPIO_SetPinDIROutput(LPC_GPIO_PORT, 5, 1);

    Chip_GPIO_SetPinState(LPC_GPIO_PORT, 5, 1, true);

Consulta: por que no se mapearon los pulsadores TEC_1/4 en board.c? Solo estan los leds?
El tema de board en LPCOpen esta un poco abandonado? Si se necesita lo puedo completar.

Gracias!
Santiago.

Has recibido este mensaje porque estás suscrito a un tema del grupo "Embebidos32" de Grupos de Google.
Para cancelar la suscripción a este tema, visita https://groups.google.com/d/topic/embebidos32/0KRaFIQnPRo/unsubscribe.
Para cancelar la suscripción a este grupo y a todos sus temas, envía un correo electrónico a embebidos32+unsubscribe@googlegroups.com.

[Eugenio Orosco]

hola, previos a usar el gpio tenes q decirle q se comporte como gpio, pin_mux  del scu  sino me equivoco.

Supongo q lo estas haciendo.

Eugenio

Eugenio C. Orosco
Dr. Ingeniero

Ingeniero Electrónico
Técnico en Electrotecnia

[Santiago Germino]

Hola Eugenio, gracias. Si, en realidad hice un copy paste simplificado de lo que ahora hace board.c (el codigo de la board EduCIAA en LPCOpen). En realidad si era necesario configurar el MUX para que funcione ese led:

Chip_SCU_PinMuxSet (2, 1, SCU_MODE_INACT | SCU_MODE_FUNC4);

lo extraño es que:

1) Esa linea no esta en el codigo original.
2) Los demas leds parecen no necesitarlo ya que si prenden normalmente con la configuracion "por defecto" (sin tocar el MUX)!

Nuevamente, si necesitan alguien que mantenga el codigo LPCOpen de EduCIAA, aca estoy :)

Saludos!
Santiago.

[Eugenio Orosco]

El problema de suponer los default sin configurar lo q necesitas es los códigos del lcp de inicialización o booteo cambian cosas respecto del default. A mí me pase hasta q me di cuenta, no me acuerdo con q pero me pasó.

Bueno espero q se solucione

Has recibido este mensaje porque estás suscrito a un tema del grupo "Embebidos32" de Grupos de Google.
Para cancelar la suscripción a este tema, visita https://groups.google.com/d/topic/embebidos32/0KRaFIQnPRo/unsubscribe.

Para cancelar la suscripción a este grupo y a todos sus temas, envía un correo electrónico a embebidos32...@googlegroups.com.

Para acceder a más opciones, visita https://groups.google.com/d/optout.

--
-- Recibiste este mensaje porque estás suscripto al Grupo Google Embebidos32. Para postear en este grupo, escribe un email a embeb...@googlegroups.com. Para des-suscribirte, envía un email a embebidos32...@googlegroups.com. Para más opciones, visita el sitio del grupo en https://groups.google.com/d/forum/embebidos32?hl=es
---
Has recibido este mensaje porque estás suscrito al grupo "Embebidos32" de Grupos de Google.
Para cancelar la suscripción a este grupo y dejar de recibir sus mensajes, envía un correo electrónico a embebidos32...@googlegroups.com.
Para acceder a más opciones, visita https://groups.google.com/d/optout.

--

Eugenio C. Orosco
Dr. Ingeniero

Ingeniero Electrónico
Técnico en Electrotecnia

--

-- Recibiste este mensaje porque estás suscripto al Grupo Google Embebidos32. Para postear en este grupo, escribe un email a embeb...@googlegroups.com. Para des-suscribirte, envía un email a embebidos32...@googlegroups.com. Para más opciones, visita el sitio del grupo en https://groups.google.com/d/forum/embebidos32?hl=es
---

Has recibido este mensaje porque estás suscrito a un tema del grupo "Embebidos32" de Grupos de Google.
Para cancelar la suscripción a este tema, visita https://groups.google.com/d/topic/embebidos32/0KRaFIQnPRo/unsubscribe.

Para cancelar la suscripción a este grupo y a todos sus temas, envía un correo electrónico a embebidos32...@googlegroups.com.

Para acceder a más opciones, visita https://groups.google.com/d/optout.

[Eric Pernia]

Buenas tardes, todo este código de manejo de pines podes ver como está implementado en los archivos de sAPI, como en este caso sapi_gpio.c y sapi_gpio.h, la capa board de LPCOpen se que lo había subido Martin R. a Frimware_v2 igual no me convence mucho como está encarada por eso no la uso y armé la biblioreca sAPI. Uso LPCOpen pero con esa capa de abtracción por encima.

Para cualquier periférico en LPCOpen primero tenes que decirle para que va a ser tal pin en la SCU y luego configurar el periférico. Como era un embole buscar en als 1400 paginas del User Manual me armé este documento con el rsumen de pines y funcionalidades:

https://github.com/ciaa/firmware_v2/blob/master/documentation/PlataformasCIAA/LPC4337/EDU-CIAA-NXP/EDU-CIAA-NXP%20Asignacion%20de%20pines%20v4r3_ES.pdf

Fijate que en el primer pin (LED_R) de la segunda página marca que valores van en SCU y cuales en GPIO.

Saludos.

Eric.

--
-- Recibiste este mensaje porque estás suscripto al Grupo Google Embebidos32. Para postear en este grupo, escribe un email a embeb...@googlegroups.com. Para des-suscribirte, envía un email a embebidos32+unsubscribe@googlegroups.com. Para más opciones, visita el sitio del grupo en https://groups.google.com/d/forum/embebidos32?hl=es

---
Has recibido este mensaje porque estás suscrito al grupo "Embebidos32" de Grupos de Google.

Para cancelar la suscripción a este grupo y dejar de recibir sus mensajes, envía un correo electrónico a embebidos32+unsubscribe@googlegroups.com.

Para acceder a más opciones, visita https://groups.google.com/d/optout.

--
-- Recibiste este mensaje porque estás suscripto al Grupo Google Embebidos32. Para postear en este grupo, escribe un email a embeb...@googlegroups.com. Para des-suscribirte, envía un email a embebidos32+unsubscribe@googlegroups.com. Para más opciones, visita el sitio del grupo en https://groups.google.com/d/forum/embebidos32?hl=es
---

Has recibido este mensaje porque estás suscrito a un tema del grupo "Embebidos32" de Grupos de Google.
Para cancelar la suscripción a este tema, visita https://groups.google.com/d/topic/embebidos32/0KRaFIQnPRo/unsubscribe.

Para cancelar la suscripción a este grupo y a todos sus temas, envía un correo electrónico a embebidos32+unsubscribe@googlegroups.com.

Para acceder a más opciones, visita https://groups.google.com/d/optout.

--
-- Recibiste este mensaje porque estás suscripto al Grupo Google Embebidos32. Para postear en este grupo, escribe un email a embeb...@googlegroups.com. Para des-suscribirte, envía un email a embebidos32+unsubscribe@googlegroups.com. Para más opciones, visita el sitio del grupo en https://groups.google.com/d/forum/embebidos32?hl=es

---
Has recibido este mensaje porque estás suscrito al grupo "Embebidos32" de Grupos de Google.

Para cancelar la suscripción a este grupo y dejar de recibir sus mensajes, envía un correo electrónico a embebidos32+unsubscribe@googlegroups.com.

Para acceder a más opciones, visita https://groups.google.com/d/optout.

--

Eugenio C. Orosco
Dr. Ingeniero

Ingeniero Electrónico
Técnico en Electrotecnia

--
-- Recibiste este mensaje porque estás suscripto al Grupo Google Embebidos32. Para postear en este grupo, escribe un email a embeb...@googlegroups.com. Para des-suscribirte, envía un email a embebidos32+unsubscribe@googlegroups.com. Para más opciones, visita el sitio del grupo en https://groups.google.com/d/forum/embebidos32?hl=es

---
Has recibido este mensaje porque estás suscrito a un tema del grupo "Embebidos32" de Grupos de Google.
Para cancelar la suscripción a este tema, visita https://groups.google.com/d/topic/embebidos32/0KRaFIQnPRo/unsubscribe.

Para cancelar la suscripción a este grupo y a todos sus temas, envía un correo electrónico a embebidos32+unsubscribe@googlegroups.com.

Para acceder a más opciones, visita https://groups.google.com/d/optout.

--
-- Recibiste este mensaje porque estás suscripto al Grupo Google Embebidos32. Para postear en este grupo, escribe un email a embeb...@googlegroups.com. Para des-suscribirte, envía un email a embebidos32+unsubscribe@googlegroups.com. Para más opciones, visita el sitio del grupo en https://groups.google.com/d/forum/embebidos32?hl=es

---
Has recibido este mensaje porque estás suscrito al grupo "Embebidos32" de Grupos de Google.

Para cancelar la suscripción a este grupo y dejar de recibir sus mensajes, envía un correo electrónico a embebidos32+unsubscribe@googlegroups.com.

Para acceder a más opciones, visita https://groups.google.com/d/optout.

--
-- Recibiste este mensaje porque estás suscripto al Grupo Google Embebidos32. Para postear en este grupo, escribe un email a embeb...@googlegroups.com. Para des-suscribirte, envía un email a embebidos32+unsubscribe@googlegroups.com. Para más opciones, visita el sitio del grupo en https://groups.google.com/d/forum/embebidos32?hl=es

---
Has recibido este mensaje porque estás suscrito al grupo "Embebidos32" de Grupos de Google.

Para cancelar la suscripción a este grupo y dejar de recibir sus mensajes, envía un correo electrónico a embebidos32+unsubscribe@googlegroups.com.

[Eric Pernia]

Esta familia de micros en aprticular es medio extraña como desdobla hasta el modo gpio como un periférico aparte, los modelos más nuevos volvieron a que el modo GPIO es mel modo base del pin y luego si queres que salga otro periférico lo tenés que configurar. Este trata al modo gpio como un periférico aparte más. Hay muchos pines que por defecto son GPIO Output sin configurar nada...

[Santiago Germino]

Buenas tardes Eric, muchas gracias por toda la aclaracion! Ya encontre el bug en lpc_board_ciaa_edu_4337/board.c y voy a reimplementar todo. Despues lo mando a ver si les sirve, aunque por lo que comentas, entiendo que no es prioridad del proyecto Edu-CIAA usar LPCOpen directo, sino a traves de sAPI.

El diagrama de mapeo de pines esta muy bueno! usaste algun programa opensource para diseñarlo?

Saludos y felices pascuas!

[Eric Pernia]

En cuanto a LPCOpen tiene varios problemas de diseño, sobre todo esa capa board lo de los periféricos casi que le pega a registros con Macros así que está bien.

La idea de la sAPI es que se extienda a todas las placas, tal a tenemos para la EDU-CIAA-NXP, CIAA-NXP y CIAA-Z3R0 (la vesión que incluye más periféricos es la EDU-CIAA-NXP). De esta amnera un progama es fácilmente potable entre las distintas placas, lo único que debería cambiar es qué cantidad de cada uno de los periféricos tendrías. La siguiente placa es la PicoCIAA, se está trabajando. En paralelo se está trabajando en una nueva especificación de la API de la sAPI para mejorar cosas que con el uso nos hemos dado cuenta e incluir más funcionalidades.

En cuanto al diagrama de conexión, ese diagrama en particular lo hice con Corel Draw, mi viejo tiene imprenta y lo manejo desde los 6 años, pero se puede hacer igual con inkscape (https://inkscape.org/es/), de hecho cuando estoy en Linux uso Inkscape y cuando estoy en Windows a veces Corel y otras veces Inkscape, es un tema más de año de manejo y velocidad de uso que de capacidades de los programas.

Ambos son programas de diseño vectorial de propósito general (lo mismo que el Adobe Ilustrator) pero me gusta armár diagramas incluso en la secundaria hacía diseños de PCBs y tengo dibujados un montón de componentes.
El estilo de diseño de como resume los pines lo copié de los diagramas de Alberto Piganti (Pighixxx): http://pighixxx.com/nanopdf.pdf que ahora tiene la web principal caida... Le pregunté con qué los hacía y me dijo que los ahcía en Ilustrator.

Usando Frinzing (http://fritzing.org/home/) podés armar diagramas de conexión fácilmente (de hecho tenemos el diseño de la EDU-CIAA-NXP como componente) pero no tiene algo así para informar pines y sus tipos. En los cursos CAPSE nos vino muy bien para mostrar como se conectaban displays 7 segmentos de 4 dígitos y otras cosas así con muchos cables entre la placa y el periférico.

En el de la CIAA-Z3R0 además me importé las pistas de Kicad y se las agregué al dibujo en Corel quedando mucho mejor:
http://www.proyecto-ciaa.com.ar/devwiki/lib/exe/fetch.php?hash=2b9183&media=https%3A%2F%2Fgithub.com%2Fepernia%2FsAPI%2Fraw%2Fdevelop%2Fdocumentation%2FCIAA-Z3R0%2FCIAA-Z3R0%2520Board%2520-%2520Conexion%2520y%2520Pines.pdf

Cuando tenga tiempo le agregaré las pistas al de la EDU- CIAA-NXP y CIAA-NXP.

Felices pascuas para vos y tu familia! Lo mismo para el resto de la gente de la lista!

Saludos.

Eric.

[Santiago Germino]

Gracias! Te hago otra consulta: Hay algun ejemplo de multicore funcionando en la Edu-CIAA?

Agregando y quitando cosas "hice funcionar" el ejemplo en examples/multicore (o sea, desresetear el M0 y que corra codigo), pero parece que no andan las interrupciones en el M0.

Saludos!
Santiago.

[Santiago Germino]

Me corrijo, si andan las interrupciones.. pero parece que el SystTick no esta implementado en el M0 del 4337 aunque el ejemplo si lo utiliza (ese ejemplo en firmware_v2 seria para otro micro).

Para colmo tenias razon Eric.. LPCOpen es un despelote y la documentacion es poca. A quien se le ocurrio usar micros de NXP? :)

Saludos!
Santiago.

[martin ribelotta]

El 2 de abril de 2018, 21:45, Santiago Germino <royc...@gmail.com> escribió:

Me corrijo, si andan las interrupciones.. pero parece que el SystTick no esta implementado en el M0 del 4337 aunque el ejemplo si lo utiliza (ese ejemplo en firmware_v2 seria para otro micro).

Hola, para el SysTick en el M0 debes usar el periferico del RIT. Algo poco mencionado es que los M0 no tienen la obligacion de implementar el periferico systick (no asi los M0+)

 

Para colmo tenias razon Eric.. LPCOpen es un despelote y la documentacion es poca. A quien se le ocurrio usar micros de NXP? :)

Concretamente yo lo sugerí y convencí a todos que era una buena opción. Opinión que mantengo hasta ahora (contando el desfazaje en tiempo que tiene el micro, era nuevo en el 2012-2013)

NXP es un buen fabricante, solo que hay que saber leer los datasheet que te proveen.

Los datasheet de ST son igual de caóticos que los de NXP (o al menos están en el mismo orden de caos) sumándole que las librerías ST-HAL no son un dechado de virtudes (directamente son caca pinchada de un palo)

Atmel/Microchip es lento para sacar librerías en sus piezas nuevas (Los SAMG5/E5 no están del todo soportados por sus librerias de perifericos teniendo que recurrir a tocar registros)

TI es un puto desgraciado con su datasheet, de hecho hay toda una sección que dice "Para leer esto firmanos un NDA vendiendonos tu alma". Ni hablar de lo asqueroso que es tener que llamar a rutinas en ROM para trabajar con los perifericos (Alguien dijo CC3200???)

Silicon Lab (EFM32) tiene librerias un tanto mejor aunque los micros distan mucho de la potencia esperada para este tipo de CPU

Infineon tiene buenos micros pero su ecosistema no es el mejor (de hecho es asombrosamente chico comparado con lo buenos que son. Eso si, para el momento que se eligió el micro era una opcion casi inexistente)

Cypress tiene los PSOC que son un chiste de lo cerrados (aunque ciertamente interesantes por la logica programable que llevan al lado) y los FM3/FM4 que recien en el 2015 anunciaron algo competitivo y fuerte (de hecho muy fuerte) en el mercado. Eso si, con poco ecosistema y herramientas cerradas (el bootloader en ROM es fucking cerrado)

Pero el punto mas importante por lo que nos decantamos por el LPC43xx fue el doble núcleo. En el momento que que salio, algo con IMX6 era imposible de fabricar aca (A9+M4) y otros micros eran single core. La idea mia era correr linux non-mmu en el M4 haciendo los trabajos de interfaz pesados y complejos y dejar al M0 como micro de Hard-RT. Desgraciadamente todo se torció bastante y terminamos en lo que tenemos ahora.

Es cierto que las LPCOpen no son el entorno amigable de arduino, pero las STM-HAL tampoco, las periphlib de TI mucho menos (y vienen en ROM) y la mayoria de los fabricantes dejan bastante que desear en soporte de firmware, por eso es importante hacer cosas como la sAPI.

[Ariel Lutenberg]

Hola,

Completo lo que escribió El Ruso...

Pueden darle un vistazo a este documento que busqué en el cajón de los recuerdos: CIAA-Hardware-v1.2.docx

Leyendo eso se puede ver que se empezó a trabajar en tres micros a la vez y se impuso el grupo que primero terminó y le pudo poner más trabajo voluntario al tema.

Saludos,

Ariel.

[Santiago Germino]

El datasheet es como cualquier datasheet. El palo a NXP fue a raiz de que ayer fui a buscar info particular de los perifericos del 4337 y me encuentro que no estarian muy bien documentados. Y el IPC nuevo en LPCOpen es criptico, rebuscado y tampoco bien documentado. No cuesta hacer uno, el tema es.. por que tanto ruido innecesario y falta de simplicidad? El ejemplo de IPC tiene compilacion condicional para 2 o 3 RToses metidos en el mismo codigo!

Si bien el salto que dio ST con su nuevo HAL, middleware (CUBE) y herramientas es reciente y es destacable que su API sea suficientemente bajo nivel y al mismo tiempo (en mi opinion y gusto) coherente a nivel diseño, yo me referia en particular a las notas de aplicacion y ejemplos de perifericos y casos de uso de NXP. en ST siempre fueron muchas mas. Y algo que hizo muy bien ST fue regalar sus kits (8, 10 dolares c/u, 30 con pantalla LCD, etc). Por eso hay tantos hobbystas e instituciones educativas usandolos y por ende muchos mas ejemplos disponibles en la web. NXP es bueno y funciona, pero se hace un poco mas cuesta arriba, mas aun si no se usa MCUXpresso.

Lo del dual core es genial y muy util a nivel pedagogico, pero.. hay alguien que lo este usando? Entiendo que en el firmware de la Edu-CIAA no hay ejemplo que compile.

Lo que hizo que Arduino fuese lo que es, es su API. No estaria mal que Edu-CIAA, con la sAPI, se convirtiese en el arduino de los Cortex! Se esta apuntando a eso?

Disclaimer: ST no me paga, aunque si lo hiciese no me enojo :)

Saludos!
Santiago.

[Eric Pernia]

Lo que opino de las bibliotecas lo escribí en el paper de la sAPI https://github.com/epernia/sAPI/blob/develop/documentation/paper/PID4903829.pdf) y coincido bastante con Martín.

En firmwarte v2 funciona el ejemplo multicore y el OSEK muticore de Pablo Ridolfi,e so no está protado a la nueva estructura aún...

Fijate el User Manual del micro (https://github.com/epernia/cese-edu-ciaa-template/blob/master/documentation/PlataformasCIAA/LPC4337/Informaci%C3%B3n%20del%20fabricante%20del%20microcontrolador%20LPC4337/UM10503.pdf) para ver que periféricos podés tocar desde cada core, el Sistyck viene amalgamado al M4 en este caso, si te fijas es el único periférico parte de la arquitectura de Cortex M (teniendo en cuenta lo que dijo Martin), los demás son propios del fabricante.

Pablo Ridolfi armó el ejemplo de firmware_v2 de doble núcleo de este micro e implementó el OSEK multicore (http://laboratorios.fi.uba.ar/lse/tesis/LSE-FIUBA-Trabajo-Final-CESE-Pablo-Ridolfi-2015.pdf) así que seguro el va a poder colaborar mucho más que yo con ese tema (vean el Copyright de cada ejemplo que somos todos gente de la lista y pueden escribirnos sin problema).

La idea es a futuro buscar una buena abstracción para eso, por ahora no está hecho así que a arremangarse y laburar como ya nos tocó a nosotros con otras cosas :P

Te recomiendo que vayas más tranqui, hace una semana estabas configurando un GPIO con LPCOpen y ahora querés hacer multicore, andá más despacio y a paso firme porque tiene millones de particularidades este micro y muy variadas, como el periférico SCT y muchas otras más... No en vano tiene más 1400 páginas el User Manual.

Por otro lado te recomiendo leer los siguientes libros (y en ese orden):

• Ing. Sergio Caprile - Desarrollo con microcontroladores ARM Cortex-M3 (http://ldir.com.ar/libros/armando/). (Sergio, el autor, está en esta lista de mails! es el libro más copado para arrancar con la arquitectura ARM).
• Joseph Yiu - The Definitive Guide to ARM® Cortex®-M0 and Cortex-M0+ Processors
• Joseph Yiu - The Definitive Guide to ARM Cortex-M3 and Cortex-M4 Processors

Saludos.

Eric.

 

El 3 de abril de 2018, 14:46, martin ribelotta <martinr...@gmail.com> escribió:

[Santiago Germino]

Que grande, gracias Eric!! Actualmente estoy cursando el CESE (la semana pasada vi una presentacion tuya en programacion de micros!) y en realidad tengo mucha exp. programando en si y hace tiempo uso micros de toda la gama de ST. Voy rapido porque quiero entender los objetivos del proyecto Edu-CIAA (estoy muy afuera social y laboralmente de todo lo que es el ambiente de desarrollo local) y ver si puedo aportar algo a la causa o si este micro de NXP me serviria para algo personal o profesional. Gracias por tenerme paciencia!

Saludos!
Santiago.

[martin ribelotta]

El 3 de abril de 2018, 15:55, Santiago Germino <royc...@gmail.com> escribió:

El datasheet es como cualquier datasheet. El palo a NXP fue a raiz de que ayer fui a buscar info particular de los perifericos del 4337 y me encuentro que no estarian muy bien documentados. Y el IPC nuevo en LPCOpen es criptico, rebuscado y tampoco bien documentado. No cuesta hacer uno, el tema es.. por que tanto ruido innecesario y falta de simplicidad? El ejemplo de IPC tiene compilacion condicional para 2 o 3 RToses metidos en el mismo codigo!

No drama, yo puntualiso que los demas fabricantes no son un dechado de virtudes y al final hay que convivir con lo malo del firmware que se puede mejorar. Lo que no se puede mejorar el el silicio una vez que lo comprates.

 

Si bien el salto que dio ST con su nuevo HAL, middleware (CUBE) y herramientas es reciente y es destacable que su API sea suficientemente bajo nivel y al mismo tiempo (en mi opinion y gusto) coherente a nivel diseño, yo me referia en particular a las notas de aplicacion y ejemplos de perifericos y casos de uso de NXP. en ST siempre fueron muchas mas. Y algo que hizo muy bien ST fue regalar sus kits (8, 10 dolares c/u, 30 con pantalla LCD, etc). Por eso hay tantos hobbystas e instituciones educativas usandolos y por ende muchos mas ejemplos disponibles en la web. NXP es bueno y funciona, pero se hace un poco mas cuesta arriba, mas aun si no se usa MCUXpresso.

ST lo que hizo fue armar una buena red de makers donde basarse. Eso genera ejemplos y tutoriales. Es la estrategia microchip. Es cierto que podriamos haber usado ST en ese tiempo, pero mi punto era simple:

- Para que usar ST si ya todos lo usan, hagamos algo nuevo que aproveche las capacidades tecnicas de lo mejor que encontremos en el mercado.

Es decir, en ningun momento tuvo peso la documentacion o las facilidades que diera el fabricante para programar el micro. Siempre que las diera claro esta.

La idea era que este gap entre la informacion del fabricante y el usuario medio final estuviera cubierta por nosotros, cosa que como vez esta pasando a medias.

 

Lo del dual core es genial y muy util a nivel pedagogico, pero.. hay alguien que lo este usando? Entiendo que en el firmware de la Edu-CIAA no hay ejemplo que compile.

Como te dije, la idea del dual core era correr linux en el m4 y los algoritmos RT en el M0. Eso murio con la idea de usar la CIAA industrial en ese aspecto. Ya Eric te dio una punta para mirar los ejemplos que compilan.

De todas formas sigue siendo un tanto truculento el mecanismo de dual core con los dos micros en bare metal,

 

Lo que hizo que Arduino fuese lo que es, es su API. No estaria mal que Edu-CIAA, con la sAPI, se convirtiese en el arduino de los Cortex! Se esta apuntando a eso?

Como bien indica el nombre sAPI (Simple API), su idea es simplificar el uso de lo que corra por debajo de ella. No se hasta donde podemos llegar las pocas personas involucradas en esto pero es la idea.

Ya que tenes experiencia en ST (yo espero que algo de tiempo) estaria bueno proponer un port de sAPI a STM32. Aunque esperaria que se evitara en lo posible el uso de STM-HAL y se fuera directamente a STM-LL.

 

Disclaimer: ST no me paga, aunque si lo hiciese no me enojo :)

No ataco para nada a ST, de hecho es lo que uso continuamente en el trabajo. Simplemente que como explique mas arriba, no peso en absoluto que tan bueno o malo fuera el soporte del fabricante mientras diera la informacon necesaria para tocar los perifericos.

Eso fue asi, porque pensamos que teniamos el material humano para generar drivers para cualquier micro desde datasheet, por desgracia los colaboradores de CIAA cada vez somos menos y se dificulta pensar en eso hoy por hoy.

[Eric Pernia]

Respondo entre líneas:

El 3 de abril de 2018, 15:55, Santiago Germino <royc...@gmail.com> escribió:

El datasheet es como cualquier datasheet. El palo a NXP fue a raiz de que ayer fui a buscar info particular de los perifericos del 4337 y me encuentro que no estarian muy bien documentados. Y el IPC nuevo en LPCOpen es criptico, rebuscado y tampoco bien documentado. No cuesta hacer uno, el tema es.. por que tanto ruido innecesario y falta de simplicidad? El ejemplo de IPC tiene compilacion condicional para 2 o 3 RToses metidos en el mismo codigo!

Si, LPCOpen está fea, pero sin embargo las bibliotecas que le pegan directo a los periféricos funcionan bien, al capa de board es la más fulera.
 

Si bien el salto que dio ST con su nuevo HAL, middleware (CUBE) y herramientas es reciente y es destacable que su API sea suficientemente bajo nivel y al mismo tiempo (en mi opinion y gusto) coherente a nivel diseño, yo me referia en particular a las notas de aplicacion y ejemplos de perifericos y casos de uso de NXP. en ST siempre fueron muchas mas. Y algo que hizo muy bien ST fue regalar sus kits (8, 10 dolares c/u, 30 con pantalla LCD, etc). Por eso hay tantos hobbystas e instituciones educativas usandolos y por ende muchos mas ejemplos disponibles en la web. NXP es bueno y funciona, pero se hace un poco mas cuesta arriba, mas aun si no se usa MCUXpresso.

Esto va en gustos, insisto que el mciro es muy complicado y tiene demasiaaaaados periféricos, entonces lleva mucho tiempo conocerlo completo, no hay ejemplos, AN, guias que alcancen. No es lo mismo que un micro de 8 bits con 3 o 4 periféricos.

Para tener una placa más "beginer 32 bits friendly" y barata hice la CIAA-Z3R0 que es un muy buen paso intermedio entre 8 bits (un AVR como la mayoría de los Arduino) y un micro de 32 bits, el de la EDU-CIAA es un monstruo gigante al lado de esos. También los de Silicon Labls metieron muchas Notas de Aplicación, ejmplos y demás y por eso se eligió ese micro en CIAA-Z3R0 (http://www.proyecto-ciaa.com.ar/devwiki/doku.php?id=desarrollo:ciaa-z3r0).

Lo del dual core es genial y muy util a nivel pedagogico, pero.. hay alguien que lo este usando? Entiendo que en el firmware de la Edu-CIAA no hay ejemplo que compile.

Ver ejemplos de Firmware v2 que nombro en el mail anterior y la tesis de Pablo.

Lo que hizo que Arduino fuese lo que es, es su API. No estaria mal que Edu-CIAA, con la sAPI, se convirtiese en el arduino de los Cortex! Se esta apuntando a eso?

Se está a puntando a tener una biblioteca independiente del microcontrolador con el proyecto de sAPI, pero con bases de diseño más claras que la de Arduino, leyendo mucha info de mcuhas bibliotecas y poniéndole muchas horas de laburo, la cual está orientada a abstraer periféricos, si hubiese más gente colaborando el proyecto iría más rápido.

De hecho hay una propuesta de tener una versión de la sAPI para un micro de ST y darle soporte también.

En el proyecto CIAA tratamos todos los días de mejorar las herramientas en nuestor tiempo libre y requier mucho tiempo y esfuerzo. Lo hacemos por que nos gusta, así que las cosas que faltan pedimos colaboración para que las agreguen.

[Eric Pernia]

Si estás cursando de manera presencial en Cadieel me podés encontrar los lunes y si estás de manera remota me vas a tener que soportar en RTOS I de profesor...

La sAPI surgió como ejemplo de capa de abstracción pare el curso Programación de Microprocesadores de la CESE (FI-UBA) que daba yo antes, y de la materia Sistemas Digitales que estoy en UNQ, sumado al proyecto donde la necesité para que ande Java con la CIAA, luego se fue ampliando con otros cursos que di y algunas colaboraciones (todas en los.c y.h de la biblo).

La idea fue simplificar un poco porque había un salto muy alto entre lo que uno hacía en 8 bits y lo que planteaba la estructura de drivers Posix de Firmware v1. Entonces lo que pasaba era que para entrar a hacer algo con la CIAA tenías que tomar mucha sopa antes. Con la sAPI se simplificó mucho todo eso aunque está lejos de estar completa y se va mejorando. Como en cualquier proyecto de software libre, las herramientas evolucionan todos los días y hay que tratar de estar atento a las novedades así como aprotar donde ves algo flaco ya que vos usaste todo el resto sin poner un peso y entre la comunidad todo tiende a mejorar.

Lo mismo estamos haicendo con el proyecto de Embedded IDE de Martín para que sea sencillo crear proyecto y demás para los que arrancan. A nivel especialización decidimos ir directamente con Eclipse porque la idea es que puedan usar algo más aprecido a lo que van a encontrar en el mercado.

Por supuesto que podés aportar. Más que bienvenido!

Saludos.

Eric.

[Santiago Germino]

Entonces seguro en algun momento nos cruzamos en Cadieel! Lo que consulte ya lo solucione.. quiza para uds que son habitues de ciertos lugares comunes del firmware sea obvio donde meterse o donde no.. o que funciona y que no... y no se metan en los recovecos como yo. Pero yo, que vengo de afuera y digo bueno, voy a usar LPCOpen directo, de repente uso board y esta bugeada. Busco ejemplos de multicore y no compilan... por eso me ofreci a mantener eso, porque ya lo tengo resuelto! y es chocante o desmoralizador para gente que viene de afuera (como yo) querer usar algo que esta, pero no funciona. Y al mismo tiempo es cierto que esto se construye entre todos los usuarios!

Por ejemplo, siempre hablando del firmware_v2 y la Edu-CIAA (LPC4337), en examples/multicore, en el main del M4, se hace mencion a un simbolo que no existe en el linker script y una funcion que tampoco existe en LPCOpen. Ademas (y salvando esos temas menores de ser ejemplo de otro micro), en el M0 se esta usando SysTick y eso tampoco existe en el 4337!

Todo eso produce que venga gente a molestar en la lista preguntando pavadas :)

En cuanto a la IDE, yo (objetor de conciencia) para la cursada estoy usando QtCreator como IDE y LPCOpen en vez de sAPI, mas que nada porque mi religion me prohibe usar Eclipse y para sacarle el jugo todo lo posible al hecho de estar viendo NXP y meterme de lleno en las bases de la Edu-CIAA (los ejercicios compilan igual, pero tuve q parchear la board en el mismo codigo que entrego).

La IDE la uso porque soy heavy y jodido xD, por preferencia (QtCreator tiene mil ventajas) pero tmb por conveniencia; en Debian 9 se levanta un entorno de desarrollo Edu-CIAA (el QtCreator, OpenOCD y el toolchain ARM) en 5 minutos y sin compilar nada. Cuando termine la cursada me gustaria sugerirlo, ya que el problema que tienen los profes es que se consume demasiado tiempo bajando, compilando y configurando la IDE y todo el entorno.

Saludos!
Santiago.

[martin ribelotta]

El 3 de abril de 2018, 17:16, Santiago Germino <royc...@gmail.com> escribió:

Entonces seguro en algun momento nos cruzamos en Cadieel! Lo que consulte ya lo solucione.. quiza para uds que son habitues de ciertos lugares comunes del firmware sea obvio donde meterse o donde no.. o que funciona y que no... y no se metan en los recovecos como yo. Pero yo, que vengo de afuera y digo bueno, voy a usar LPCOpen directo, de repente uso board y esta bugeada. Busco ejemplos de multicore y no compilan... por eso me ofreci a mantener eso, porque ya lo tengo resuelto! y es chocante o desmoralizador para gente que viene de afuera (como yo) querer usar algo que esta, pero no funciona. Y al mismo tiempo es cierto que esto se construye entre todos los usuarios!

Por ejemplo, siempre hablando del firmware_v2 y la Edu-CIAA (LPC4337), en examples/multicore, en el main del M4, se hace mencion a un simbolo que no existe en el linker script y una funcion que tampoco existe en LPCOpen. Ademas (y salvando esos temas menores de ser ejemplo de otro micro), en el M0 se esta usando SysTick y eso tampoco existe en el 4337!

Todo eso produce que venga gente a molestar en la lista preguntando pavadas :)

En cuanto a la IDE, yo (objetor de conciencia) para la cursada estoy usando QtCreator como IDE y LPCOpen en vez de sAPI, mas que nada porque mi religion me prohibe usar Eclipse y para sacarle el jugo todo lo posible al hecho de estar viendo NXP y meterme de lleno en las bases de la Edu-CIAA (los ejercicios compilan igual, pero tuve q parchear la board en el mismo codigo que entrego).

La IDE la uso porque soy heavy y jodido xD, por preferencia (QtCreator tiene mil ventajas) pero tmb por conveniencia; en Debian 9 se levanta un entorno de desarrollo Edu-CIAA (el QtCreator, OpenOCD y el toolchain ARM) en 5 minutos y sin compilar nada. Cuando termine la cursada me gustaria sugerirlo, ya que el problema que tienen los profes es que se consume demasiado tiempo bajando, compilando y configurando la IDE y todo el entorno.

Entiendo que QtCreator tenga mas ventajas que Embedded-IDE (por ejemplo el debug integrado que en v0.7 espero tener andando -incidentalmente, portando el código de qtcreator a este) pero si te fijas, CIAA-Suite es bajarlo, darle permisos de ejecución y hacerle doble click.

Si logras que configurar QtCreator con el plugin de bare metal tenga esas ventajas entonces estamos a disposición.

De hecho, es una de las propuestas, basar el próximo embedded-ide en la infraestructura de qt creator (debugger, plugins, editores, etc) pero igual aparece como una opción pesada al lado de lo que tenemos ahora (no eclipse obviamente)

[Eric Pernia]

Respondo entre lineas:

El 3 de abril de 2018, 17:16, Santiago Germino <royc...@gmail.com> escribió:

Entonces seguro en algun momento nos cruzamos en Cadieel! Lo que consulte ya lo solucione.. quiza para uds que son habitues de ciertos lugares comunes del firmware sea obvio donde meterse o donde no.. o que funciona y que no... y no se metan en los recovecos como yo. Pero yo, que vengo de afuera y digo bueno, voy a usar LPCOpen directo, de repente uso board y esta bugeada.

Es que la capa board viene para su board NXP Xplore... No está portada en este repo (https://github.com/epernia/cese-edu-ciaa-template).

 

Busco ejemplos de multicore y no compilan...

En Firmware v2 deberían andar (https://github.com/ciaa/firmware_v2). En el repo nuevo (https://github.com/epernia/cese-edu-ciaa-template) aún no están portados. El nuevo es un repo mío propio que ni si quiera es oficial del proyecto CIAA aún...

 

por eso me ofreci a mantener eso, porque ya lo tengo resuelto! y es chocante o desmoralizador para gente que viene de afuera (como yo) querer usar algo que esta, pero no funciona. Y al mismo tiempo es cierto que esto se construye entre todos los usuarios!

Forkea y Commitea los cambios a https://github.com/epernia/cese-edu-ciaa-template.

Por ejemplo, siempre hablando del firmware_v2 y la Edu-CIAA (LPC4337), en examples/multicore, en el main del M4, se hace mencion a un simbolo que no existe en el linker script y una funcion que tampoco existe en LPCOpen. Ademas (y salvando esos temas menores de ser ejemplo de otro micro), en el M0 se esta usando SysTick y eso tampoco existe en el 4337!

Esos ejemplos no los mantengo yo, los voy a revisar.

 

Todo eso produce que venga gente a molestar en la lista preguntando pavadas :)

En cuanto a la IDE, yo (objetor de conciencia) para la cursada estoy usando QtCreator como IDE y LPCOpen en vez de sAPI, mas que nada porque mi religion me prohibe usar Eclipse y para sacarle el jugo todo lo posible al hecho de estar viendo NXP y meterme de lleno en las bases de la Edu-CIAA (los ejercicios compilan igual, pero tuve q parchear la board en el mismo codigo que entrego).

Te recomiendo que hagas las cosas como te piden los profesores porque si no automáticamente te quedás sin soporte de ellos... Es bastante darle soporte a 15 o 20 personas y si sumamos las particularidades de cada uno no alcanza el tiempo humano. Así que si querés trabajar así vas a quedar a lazo abierto, sin soporte...

Yo eso lo haría para mi para aprender en tu lugar, pero lo que respecta a las entregas lo haría usando lo que me piden (aunque no me guste), ya que ellos cuidan que todo cierre y no te metas en "senderos oscuros" como vos decis.

De hecho nos hemos reunido todos los profesores de la especialización para decidir que entorno usar en conjunto en las materias para evitar problemes y Martín también colaboró en eso.

 

La IDE la uso porque soy heavy y jodido xD, por preferencia (QtCreator tiene mil ventajas) pero tmb por conveniencia; en Debian 9 se levanta un entorno de desarrollo Edu-CIAA (el QtCreator, OpenOCD y el toolchain ARM) en 5 minutos y sin compilar nada. Cuando termine la cursada me gustaria sugerirlo, ya que el problema que tienen los profes es que se consume demasiado tiempo bajando, compilando y configurando la IDE y todo el entorno.

El Entorno de Desarrollo Integrado, se usa Eclipse por que es lo quemás usan los fabricantes. Podrías usar incluso VSCode, línea de comando o lo que quieras, pero otra vez, quedás a lazo abierto...

Saludos.

Eric.

[Santiago Germino]

En cuanto a lo de forkear y comitear, dalo por hecho, en estos dias subo los cambios.

Veo que en este repositorio (que es el que usamos para Arquitectura de Micros) el ejemplo multicore al que hago mencion esta marcado como que no funciona. En firmware_v2 es un ejemplo mas como cualquier otro.

Si me permitis la observacion, otro problema que encuentro (y que me desorienta, aunque quiza es tema mio) es la cantidad de repos y makefiles que hay para la Edu-CIAA y en particular que usamos en la cursada. Esta el repo que me pasaste, otro que usamos en programacion, y el de Ingenieria que es firmware_v2. Cada uno tiene un makefile distinto y el hecho de tener que indicar por parametro que proyecto compilar (en variables que en cada makefile de repo se llaman distinto), no ayuda.

En cuanto a lo que me comentas es muy cierto, ya me lo observaron exactamente igual que haces vos (dicho sea de paso, destaco la calidad de los profes!). La cuestion es que tengo que balancear mi tiempo libre con el de la cursada y mi necesidad de sacarle el maximo redito posible al tiempo y siempre empujar un poco mas. Los entregables compilan igual. Casi fallo en la 1er entrega porque el codigo estaba perfecto, pero el led verde RGB no prendia! (mi primer consulta aca!). Lo solucione en un dia y ese fue el disparador para esta hablando aca y solucionar varias cosas. De no haberlo hecho, solo en mi tiempo libre o en lo profesional, jamas hubiese tocado ese codigo. Hoy por hoy ya todo funciona (comprobado, me juego la carrera jaja) y si los parches del repo se aceptan, los profes van a tener un board no bugeado y yo voy a poder usar LPCOpen sin parchear nada!

Ya lo hable con los profes y, mientras a ellos no les signifique trabajo extra (lo cual seria injusto e incorrecto), lo demas, de mi parte, es un compromiso aceptable.

Saludos!
Santiago.

[Eric Pernia]

El 3 de abril de 2018, 18:07, Santiago Germino <royc...@gmail.com> escribió:

En cuanto a lo de forkear y comitear, dalo por hecho, en estos dias subo los cambios.

Veo que en este repositorio (que es el que usamos para Arquitectura de Micros) el ejemplo multicore al que hago mencion esta marcado como que no funciona. En firmware_v2 es un ejemplo mas como cualquier otro.

Si, es lo que trataba que entiendas.

Si me permitis la observacion, otro problema que encuentro (y que me desorienta, aunque quiza es tema mio) es la cantidad de repos y makefiles que hay para la Edu-CIAA y en particular que usamos en la cursada. Esta el repo que me pasaste, otro que usamos en programacion, y el de Ingenieria que es firmware_v2. Cada uno tiene un makefile distinto y el hecho de tener que indicar por parametro que proyecto compilar (en variables que en cada makefile de repo se llaman distinto), no ayuda.

En el proyecto CIAA hay 2 repositorios de manera oficial, Firmware y Firmware_v2, se mantiene Firmware v1 en existencia por retrocompatibilidad y porque uno tiene cosas que el otro no con sus ventajas y desventajas.

Para las materias de CESE se consensuó que ibamos a usar la plantilla de cese para que todas las materias para evitar los diferentes cambios y que sea un repo más sencillo debido a la menor cantidad de arquitecturas, facilidad de agregar nuevas bibliotecas y demás. Así que esa materia se ve que aún no se actualizó.

El repo de CESE es candidato a convertirse en Firmware_v3 en este momento debido a sus ventajas frente a v2 (ver https://groups.google.com/forum/#!topic/ciaa-firmware/Oqg4c56C39g).

En cuanto a lo que me comentas es muy cierto, ya me lo observaron exactamente igual que haces vos (dicho sea de paso, destaco la calidad de los profes!). La cuestion es que tengo que balancear mi tiempo libre con el de la cursada y mi necesidad de sacarle el maximo redito posible al tiempo y siempre empujar un poco mas. Los entregables compilan igual. Casi fallo en la 1er entrega porque el codigo estaba perfecto, pero el led verde RGB no prendia! (mi primer consulta aca!). Lo solucione en un dia y ese fue el disparador para esta hablando aca y solucionar varias cosas. De no haberlo hecho, solo en mi tiempo libre o en lo profesional, jamas hubiese tocado ese codigo. Hoy por hoy ya todo funciona (comprobado, me juego la carrera jaja) y si los parches del repo se aceptan, los profes van a tener un board no bugeado y yo voy a poder usar LPCOpen sin parchear nada!

Ya lo hable con los profes y, mientras a ellos no les signifique trabajo extra (lo cual seria injusto e incorrecto), lo demas, de mi parte, es un compromiso aceptable.

Exactamente, a eso me refería.

[Santiago Germino]

Hola! simplemente queria avisar que deje el pull request de lo hablado y de cambios menores como consecuencia a este.

Saludos!
Santiago.

--
Has recibido este mensaje porque estás suscrito al grupo "Comunidad Posgrado Embebidos" de Grupos de Google.
Para cancelar la suscripción a este grupo y dejar de recibir sus mensajes, envía un correo electrónico a comunidad-posgrado-embebidos+unsub...@googlegroups.com.
Para publicar en este grupo, envía un correo electrónico a comunidad-posgrado-embebidos@googlegroups.com.
Para ver esta conversación en el sitio web, visita https://groups.google.com/d/msgid/comunidad-posgrado-embebidos/CAFuYegSVYz9Ly-d3z%3Dj8ztmvPWuYadV6OVUCmkeJCtUt24uLAA%40mail.gmail.com.

[Eric Pernia]

Gracias por la contribución!

Hemos hecho variso comentarios con Martín:

https://github.com/epernia/cese-edu-ciaa-template/pull/4

Saludos.

Eric.

Para cancelar la suscripción a este grupo y dejar de recibir sus mensajes, envía un correo electrónico a comunidad-posgrado-embebidos+unsubs...@googlegroups.com.

Para publicar en este grupo, envía un correo electrónico a comunidad-posgrado-embebidos@googlegroups.com.
Para ver esta conversación en el sitio web, visita https://groups.google.com/d/msgid/comunidad-posgrado-embebidos/CAFuYegSVYz9Ly-d3z%3Dj8ztmvPWuYadV6OVUCmkeJCtUt24uLAA%40mail.gmail.com.