Como mantener proyectos paralelos con el mismo codigo?

[Marttyn]

Hola!
Me encuentro en el punto en el que tengo 2 proyectos que son paralelos y que comparten el 95% del codigo.
Tener ambos proyectos separados me supone que cada vez que hago un cambio en uno de ellos, debo aplicarlo tambien al otro.
Me gustaria saber de que manera se puede hacer esto, de forma sencilla...
Imaginemos un software cualquiera que tiene una version gratis y otra de pago. El desarrollador no suele tener que mantener ambas distribuciones por separado, sino que las actualizaciones se aplican a ambas al mismo tiempo, solo que una tiene mas funciones que otra.
Llevado al mundo de los PICs, me ocurre algo similar, tengo 2 circuitos funcionalmente iguales, pero uno tiene mas salidas que otro ya que uno tiene mas pines que el otro. Me gustaria programar de manera que solo programe 1 vez, y que los cambios sean compartidos.

Se me ocurrio que puedo hacer 2 proyectos en MPLABX, uno para cada PIC, y usar archivos compartidos como el main, las funciones, o los header principales, pero tener archivos separados para los fuses o la configuracion del pic. Ademas, tener compilaciones condicionales en los puntos donde el codigo es diferente para uno y otro pic:

Código: C

1. #if getenv(DEVICE) == "PIC12F1840"
2. //codigo especifico para este pic
3. #endif
4.  
5. #if getenv(DEVICE) == "PIC16F1825"
6. //codigo especifico para este pic
7. #endif

La opcion creo que es viable, aunque un poco engorrosa.
Alguien conoce alguna otra forma de hacerlo?
Un saludo!

[Picuino]

Se puede hacer con compilaciones condicionales como has dicho.
Pero yo lo haría con un sólo proyecto nada más, que tuviese todos los archivos compartidos.

Si las diferencias de código van a ser grandes, puedes hacerlo a partir de librerías.
Puedes mantener un nucleo de funciones comunes convertidos en librería (ahora no tengo claro cómo hacerlo con el compilador del pic, pero todos los compiladores de c tienen la instrucción lib para eso). Luego los demás proyectos utilizan esa librería común. Esto es útil para un código que se modifica poco.

Por último puede que te sea util manejar los proyectos con un sistema de control de revisiones. Yo estoy aprendiendo ahora Git y es una maravilla para gestionar versiones, modificaciones, proyectos en paralelo como el tuyo y muchas más funciones. Es un poco difícil al principio, pero merece la pena.

Si tu proyecto te parece complejo de manejar, imagínate el núcleo de Linux. Git lo escribió Linus Torvalds y lo utiliza el grupo de programación del núcleo Linux:
https://es.wikipedia.org/wiki/Git


También puedes utilizar las tres soluciones a la vez.


Un saludo.

[Marttyn]

Gracias Picu!

Pero yo lo haría con un sólo proyecto nada más, que tuviese todos los archivos compartidos.

Un solo proyecto no puedo crear para dos PICs diferentes, ya que MPLAB y PICKIT necesitan saber que micro estas usando. Y no puedes seleccionar mas de 1 PIC (creo).

Puedes mantener un nucleo de funciones comunes convertidos en librería (ahora no tengo claro cómo hacerlo con el compilador del pic, pero todos los compiladores de c tienen la instrucción lib para eso).

No encuentro nada de instruccion "lib" en CCS, ni se muy bien a que te refieres. Puedo incluir librerias con #include, te refieres a eso?

Por último puede que te sea util manejar los proyectos con un sistema de control de revisiones. Yo estoy aprendiendo ahora Git y es una maravilla para gestionar versiones, modificaciones, proyectos en paralelo como el tuyo y muchas más funciones. Es un poco difícil al principio, pero merece la pena.

Yo tambien estuve mirando unos cuantos videos sobre GIT, pero no consigo entender bien el funcionamiento ni la implementacion. Especialmente me parece engorroso que hay que hacerlo por linea de comandos... en serio!!?? en 2017 linea de comandos???!!!
He creado varias librerias bastante interesantes y me gustaria ponerlas en Github, para que las puedan usar otros, a la vez que mejorar y corregir si hace falta. Pero todavia no pude

[tsk]

Si el MPLAB no permite seleccionar más de un PIC entonces la mejor alternativa es usar Make, es mucho más flexible

Por otro lado, con git puedes trabajar con submódulos.

https://github.com/blog/2104-working-with-submodules

Además no necesariamente tienes que hacer todo por línea de comandos, también existen GUIs para usar GIT, y, aunque no creas, todavía en 2017 se sigue usando la línea de comandos ya que para ciertas actividades es mucho más eficiente.

Saludos

[Picuino]

Un solo proyecto no puedo crear para dos PICs diferentes, ya que MPLAB y PICKIT necesitan saber que micro estas usando. Y no puedes seleccionar mas de 1 PIC (creo).

Cada vez que cambias de micro en el proyecto, el código lo detecta y cambia, como tu ejemplo de antes.

No encuentro nada de instruccion "lib" en CCS, ni se muy bien a que te refieres. Puedo incluir librerias con #include, te refieres a eso?

Si. El include puede incluir una librería del compilador o una librería hecha por tí mismo.
https://gustavovelascoh.wordpress.com/2015/07/28/creating-a-c-library-in-ccs-code-composer-studio/

Yo tambien estuve mirando unos cuantos videos sobre GIT, pero no consigo entender bien el funcionamiento ni la implementacion. Especialmente me parece engorroso que hay que hacerlo por linea de comandos... en serio!!?? en 2017 linea de comandos???!!!
He creado varias librerias bastante interesantes y me gustaria ponerlas en Github, para que las puedan usar otros, a la vez que mejorar y corregir si hace falta. Pero todavia no pude

Yo utilizo Git Extensions para Windows. Hay muchos más GUIs que facilitan la tarea. No es fácil, pero hay mucha documentación y aquí te pueden ayudar. En un par de días aprendes lo básico.
Lo más importante es entender todos los estados de los ficheros (el flujo de trabajo) y las palabras clave de las acciones que se pueden hacer (commit, branch, etc).


En cuanto a la línea de comandos, es programación. Es lo que tú mismo haces con el pic. ¿Te imagínas programar el pic a base de ratón? (sigo echando en falta el emoticono de ahorcarse)

Un saludo.

[Marttyn]

Si el MPLAB no permite seleccionar más de un PIC entonces la mejor alternativa es usar Make, es mucho más flexible

Por otro lado, con git puedes trabajar con submódulos.
https://github.com/blog/2104-working-with-submodules

Además no necesariamente tienes que hacer todo por línea de comandos, también existen GUIs para usar GIT, y, aunque no creas, todavía en 2017 se sigue usando la línea de comandos ya que para ciertas actividades es mucho más eficiente.

Gracias tsk por la info! Pero a que te refieres con usar Make? Te refieres con los botones "make" y "build all" ? Normalmente uso Make, excepto que quiera limpiar por algun cambio en los archivos. Pero Make solo me permitira compilar, pero no podre programar.

Lo de los submodulos me parece estupendo! Acabo de leerme el articulo y le da muchas mas posibilidades a Git

Con respecto a la linea de comandos, estoy de acuerdo que es mas eficiente para ciertas cosas, pero me refiero a GIT en particular. No habra una manera mas "user friendly" de hacerlo? Dropbox te permite mantener un historial de revisiones de un archivo, y lo hace de manera automatica y transparente. Se que con Git no es exactamente lo mismo, pero estoy seguro que tiene que haber algo mas facil...

Cada vez que cambias de micro en el proyecto, el código lo detecta y cambia, como tu ejemplo de antes.

Si. El include puede incluir una librería del compilador o una librería hecha por tí mismo.
https://gustavovelascoh.wordpress.com/2015/07/28/creating-a-c-library-in-ccs-code-composer-studio/

Yo utilizo Git Extensions para Windows. Hay muchos más GUIs que facilitan la tarea. No es fácil, pero hay mucha documentación y aquí te pueden ayudar. En un par de días aprendes lo básico.
Lo más importante es entender todos los estados de los ficheros (el flujo de trabajo) y las palabras clave de las acciones que se pueden hacer (commit, branch, etc).

En cuanto a la línea de comandos, es programación. Es lo que tú mismo haces con el pic. ¿Te imagínas programar el pic a base de ratón? (sigo echando en falta el emoticono de ahorcarse)

Acabo de hacer la prueba, y aunque cambies el PIC en #include <MODELO_PIC.h>, el MPLAB no cambia, ni tampoco el programador. Hay que cambiarlo manualmente. Aunque compilar si que compila, ya que a CCS le da igual los paramtros de MPLAB, simplemente compila lo que diga el codigo.

Lo de incluir librerias propias o del compilador lo tengo claro.

Hace un par de semanas instale Git, y he mirado unos cuantos videos de Youtube intentando aprender... Y la verdad he entendido un poco el funcionamiento, pero no termino de sentirme comodo. Y quiero empezar con la linea de comandos, por que dice que si empiezas desde ahi, luego los GUI son mas faciles. Y si lo haces al reves luego da mucho lugar a problemas por no entender el funcionamiento.

Lo de la linea de comandos, tal como le dije a tsk, tiene que haber algo mas simple... Ahora, y a falta de empezara usar Git, cada vez que modifico una parte del programa con la que me quedo "contento", creo una copia del archivo fuente y lo guardo en una carpeta con el numero de version que seria... Un Git hecho a mano 

Me pasa como con Eagle... Aprender a usarlo es UNA PU** MIE***!!! Es contraintuitivo. Pero luego de pasar la curva de aprendizaje y tenerlo dominado, entonces va muy bien. Pero hace poco quise explicarle a un amigo que queria aprender Eagle, y me acorde lo dificil que fue, ya que veia en el lo mismo que me paso a mi hace años.
Aun a dia de hoy, cuando hago librerias a veces maldigo a los de Cadsoft pensando por que lo habran hecho tan "diferente", cuando era mas simple hacerlo como todo lo demas.

[Picuino]

Si utilizas windows, prueba con Git Extensions.
Es un interface gráfico open-source, bastante intuitivo (si conoces el vocabulario), y tiene una consola para usar git en linea de comandos. Vamos, que lo tiene todo.
Tardas pocas horas en aprender a usarlo (te recomiendo que hagas pruebas con un programa de prueba)

Yo no creo que haga falta aprender primero la línea de comandos (aunque yo también la utilizo), lo más importante es aprender qué significa cada acción.





Un saludo.

[colotron]

Hola Marttyn.
Normalmente uso Eclipse para mis proyectos, y éste incorpora plugins (Egit) que permite manejar repositorios haciendo clicks y nada más. En los videos (que ojala pueda retomar pronto) de mi canal lo mostré pero son un poco largos
Pero es Eclipse, mplabx si mal no recuerdo está basado en netbeans que seguro debe tener algún plugin para manejar repositorios con git.

Busco mplabx con git:
http://stackoverflow.com/questions/23778873/how-to-integrate-git-on-mplab-x
http://www.nbgit.org/
nbgit sería el plugin para Netbeans, y hasta ahí llego, internet por celular es estar casi desconectado.

Suerte!!!

[pablomanieri]

En el siguiente enlace puedes encontrar lo que buscas: MPLAB X IDE User's Guide - Microchip
http://ww1.microchip.com/downloads/en/DeviceDoc/50002027C.pdf

Sección:
6.4 WORK WITH  MULTIPLE  CONFIGURATIONS
(para trabajar con distintos pics y configuraciones)

 5.19 CONTROL  SOURCE CODE
(para trabajar con repositorios y hacer control de versiones).

Suerte

[Marttyn]

En el siguiente enlace puedes encontrar lo que buscas: MPLAB X IDE User's Guide - Microchip
http://ww1.microchip.com/downloads/en/DeviceDoc/50002027C.pdf

Sección:
6.4 WORK WITH  MULTIPLE  CONFIGURATIONS
(para trabajar con distintos pics y configuraciones)

 5.19 CONTROL  SOURCE CODE
(para trabajar con repositorios y hacer control de versiones).

[Marttyn]

Ayer estuve haciendo pruebas y parece que funciona!
Hay que crear perfiles diferentes y asignar uno o más macros de preprocesador para luego poder hacer uso de la compilación condicional.
Esto permite tener un mismo proyecto con varios PICs, y también permitiria un proyecto con el mismo PIC pero con diferentes funcionalidades, el equivalente a la versión de prueba y la versión de pago de un mismo software.

Luego explico en detalle cómo funciona, pero me parece super interesante!

Lo siguiente que tengo que averiguar es cómo funciona GIT dentro de MPLAB.

[elgarbe]

Con respecto a la linea de comandos, estoy de acuerdo que es mas eficiente para ciertas cosas, pero me refiero a GIT en particular. No habra una manera mas "user friendly" de hacerlo? Dropbox te permite mantener un historial de revisiones de un archivo, y lo hace de manera automatica y transparente. Se que con Git no es exactamente lo mismo, pero estoy seguro que tiene que haber algo mas facil...

Lo que pocos entienden de GIT es que es un SISTEMA DE CONTROL DE VERSIONES. Por lo que esta pensado no para backup de archivos ni para compartir archivos entre varias PC ni para llevar historial de archivos.
Si bien hace todo eso, no es la funcion para la que fue hecho.
Cualquiera que use GIT y no haga decenas de commits y trabaje con varias branchs en una jornada de trabajo, pues no esta usando GIT.
La idea detras de GIT es que tu programes y hagas commits explicando lo que has cambiado, para que dentro de un año sepas por que hiciste lo que hiciste. Tambien esta pensado para que en tu proyecto, hagas nuevas branchs cuando quieras probar algo nuevo para tu proyecto, programas, commit, programas, commit.... cuando esta listo lo testeas, si te gusta lo "mergeas" al master... puedes trabajar con barias branchs a la vez, probando diversas cosas que quieres agregar a tu proyecto y a medida que van funcionando ono haces los merge o no.
Dentro de 3 años vas a cambiar una funcion en un archivo .c y te preguntas que caraj... quisiste hacer ahí, pues git te da todo el historial del mismo, con los mensajes de cada commit.
Alguien quiere ayudarte agregando nuevas funciones a tu proyecto, pues le vasta mirar un poco el historial de commits como para entender por donde va el proyecto, luego hace sus cambios y te pide incluirlos en el master.... En fin, GIT es para trabajo en grupo, colaborativo, es para tener un control preciso de los cambios en el código.

Perdon por el off topic.

Lo que dice tsk con make es que se crea un archivo llamado makefile (mplab lo crea, de echo) y con la aplicacion make puedes hacer compilacion condicional. Por ejemplo puedes poner make -PIC24xxxx (no es un ejemplo real) y make compilara todo lo referente a PIC24xxxx igual si pasas otro parámetro.

GIT dentro de MPLAB es interesante para hacer los commits. Piensa que todo el tiempo deberías estar programando/haciendo commits entonces si configuras MPLAB lo haces desde adentro. Luego para hacer branchs o push o merge yo prefiero sourcetree.
Pero insisto, usa git si quieres un exaustivo control de versiones. si no, es perder el tiempo.

Saludos!

[Picuino]

Yo utilizo Git Extensions como interface para Git. Hay muchos más, como Sourcetree. Eso es lo que pedías.

Además de lo que ha comentado elgarbe, con Git puedes tener dos ramas paralelas. En una rama haces todo lo que comentaba elgarbe y cuando la has actualizado y todo funciona bien, puedes trasladar los cambios que te interesen (solo los que tu quieras) a la otra rama. Eso también vale en sentido inverso.
Mientras los proyectos se parezcan, puedes trasladar código de uno a otro.

También se puede hacer entre dos proyectos distintos de Git. Si se parecen, puedes intercambiar entre ellos modificaciones (añadir código o eliminar código, vale para los dos)

Es mucho más flexible que las macros, porque se hace en automático y cada rama/proyecto solo contiene su código diferente, no los dos codigos a la vez.

Piensa en una versión 2.5 que está lanzada y estable (rama 1)
Otra versión 3.2 lanzada y estable. Con muchos añadidos y que ha eliminado código para mas eficiencia (rama 2).
Descubres un bug en 3.2. Lo arreglas en una rama 3 distinta y lo mezclas con la versión 3.2. Este bug también lo tiene la 2.5 así que te llevas la modificación a la 2.5 de forma automática con Git (ya no escribes código), testeas y todo va bien. Lanzas las versiones 2.5.1 y 3.2.1 que arreglan el bug.

Imagina Win home y Win pro o Ubuntu y Kubuntu, etc. Muchos proyectos manejan en paralelo versiones modificadas y hay que hacer cambios comunes y otros que no lo son. Con Git lo manejas mejor.

P.D. Git no comprime ni compara bien los binarios y los proyectos por encima de 1giga comienzan a ser demasiado grandes.

Un saludo.

[Marttyn]

Gracias a ambos por explicar GIT un poco mejor. Aprender e implementar GIT es una tarea que esta en proceso de maduracion y aprendizaje. Ya tengo instalado GIT extensions, y de a poco voy probando con alguna cosita pequeña.

Pero el motivo de este hilo es el de mantener un mismo proyecto con diferentes funcionalidades, y si bien con GIT se puede aproximar, realmente eso se consigue con lo que comento pablo:

MPLAB X IDE User's Guide - Microchip
http://ww1.microchip.com/downloads/en/DeviceDoc/50002027C.pdf

Sección:
6.4 WORK WITH  MULTIPLE  CONFIGURATIONS
(para trabajar con distintos pics y configuraciones)

Imaginemos que estamos creando un Analizador Logico de 8 entradas con un PIC "X", ya lo tenemos funcionando, y ahora queremos crear otro proyecto paralelo que tenga 16 entradas con un PIC "Y". Ambos proyectos coexisten, comparten el codigo pero solo se diferencian en el PIC utilizado ya que uno necesita mas pines que el otro.

1. Parto del supuesto que ya tenemos un proyecto creado y configurado (PIC, compilador, programador...)
2. Ir a "Project properties"
3. Click en "Manage Configurations"
4. Renombrar nuestra configuracion "default" a un nombre mas apropiado, por ejemplo "8 entradas"
5. Duplicar esta configuracion y ponerle otro nombre apropiado, por ejemplo "16 entradas"
6. Ahora tenemos 2 configuraciones identicas, pero con distinto nombre, vamos a configurar cada una de ellas.
7. Escoger el PIC correspondiente para cada configuracion
8. En "Compiler Options>Preprocessor Macros" hay que crear una constante diferente para cada una de las configuraciones
    -En la configuracion de 8 entradas ponemos ANALIZADOR_8_ENTRADAS
    -En la configuracion de 16 entradas ponemos ANALIZADOR_16_ENTRADAS
9. Ahora tenemos que agregar compilacion condicional a nuestro proyecto
10. Empezamos incluyendo la cabecera correspondiente a nuestro PIC

Código: C

1. #ifdef ANALIZADOR_8_ENTRADAS
2. #include <16Fxxxx.h>
3. #endif
4.  
5. #ifdef ANALIZADOR_16_ENTRADAS
6. #include <16Fyyyyy.h>
7. #endif

11. Y a lo largo de nuestro proyecto iremos poniendo partes de codigo especificas para cada uno de los PICs:

Código: C

1. #ifdef ANALIZADOR_8_ENTRADAS
2.     //codigo especifico para PIC "X"
3.     ...
4. #endif
5.  
6. #ifdef ANALIZADOR_16_ENTRADAS
7.     //codigo especifico para PIC "Y"
8.     ...
9. #endif

12. Al lado del boton "Build" tenemos un desplegable con las configuraciones que hemos creado. Podemos seleccionar la que queramos antes de compilar, y solo compilara lo correspondiente al proyecto seleccionado

 

Otra variante seria una misma placa, con mismo PIC, pero con diferentes funcionalidades. Por ejemplo un data logger que se conecta a un PC por serial, bluetooth o wifi...
En este caso el PIC serial el mismo, pero la comunicacion con el periferico puede variar de una a otra, pero el resto del codigo es el mismo. Creariamos una configuracion para cada una de las variantes, cada una con su macro de preprocesador, y en el codigo pondriamos la compilacion condicional para que solo compile lo correspondiente a la version seleccionada.

De momento ya tengo 3 proyectos que se van a beneficiar de esta funcionalidad. La verdad que me siento bastante aliviado de no tener que repetir codigo ni andar comprobar que los proyectos corren en paralelo o si me he olvidado de implementar algun cambio.

Gracias Pablo por el dato, estoy muy contento!
Y espero que esto sea util para otros tambien

[Picuino]

No es que Git se aproxime, es que puede hacer eso mismo y mucho más, aunque de otra forma.

Creo que lo mejor es que aprendas Git (en una semana o dos sabrás lo suficiente) y luego eliges el mejor método.
O los dos a la vez porque no son incompatibles, son complementarios.

La ventaja + inconveniente del método de los #defines es que mantiene los dos códigos en un mismo archivo.
Si hay poca diferencia, no importa. Si hay muchas diferencias, comienza a ser engorroso y difícil de mantener.

Otro método comentado son las librerías. Todo el código común lo colocas en unos archivos (la librería) y todo el código diferente lo colocas en otros archivos, que sólo contengan las diferencias. Cuando mantengas el código común tienes que probarlo para las dos versiones. Eso te obliga a pensar muy bien en lo que quieres hacer, estructurarlo y dar servicios genéricos comunes a través de la librería.

Todos los métodos son compatibles entre sí y complementarios. Todos tienen sus fortalezas y utilizarlos todos a la vez te obliga a programar con buenas prácticas (analizar bien el problema, estructurarlo, documentar cambios y mantener su historial, comentar bien el código, etc.)

Un saludo.