Gedit_Pic-IDE: plugin para convertir Gedit en una IDE para PIC

Ya probé la última versión y el fallo ha desaparecido, aunque no estoy seguro de a qué atribuírselo. No tenía habilitados los efectos de escritorio aunque si estaba utilizando los drivers restringidos para mi tarjeta nVidia, (los cuales he tenido que deshabilitar por un bug: https://bugs.launchpad.net/ubuntu/+source/nvidia-graphics-drivers-180/+bug/377120).

Ahora me funciona bastante bien, ¡qué buen trabajo!

Bién.... me alegro de que vaya funcionando.

Todavía hay una cosa que no tengo clara:
En la parte del compilador hay tres entradas:

-Compilar
-Ensamblar (assembler)
-Linker

Esto todavía no lo tengo claro...
-La entrada "Compilar" es solo para compilar, osea la salida es un archivo .asm, y ejecuta la accion y nada más.
-La entrada "Ensamblar" es para una acción con un archivo .hex como salida, ejecuta la accion y si no ha habido errores abre el archivo .hex generado.
-La entrada "Linker" por ahora no hace nada... esto no lo tengo tan claro.

En realidad el plugin simplemente ejecuta las dos acciones, sean lo que sean, con la diferencia de que si hay algo en la entrada "Ensamblar" abre el archivo .hex


Entonces ... por ejemplo con SDCC para compilar un archivo.c sin usar linker ni nada, con un archivo .hex como salida, la orden habría que ponerla en "Ensamblar"... esto si queremos que nos habra el .hex generado. Sería por ejemplo así:

Código:


-Compilar:
-Ensamblar: sdcc -mpic14 -p%PIC -V --debug -I%FILEDIR-Wl-o%NAME.hex -Wl-m -Wl-ainhx32 %FILENAME
-Linker:



También funciona si la orden la ponemos en la entrada "Compilar", pero no abriría el .hex generado.

Pero si queremos usar SDCC con el Linker, entonces tenemos dos órdenes, la primera genera un .o y la segunda genera un .hex . Entonces Se podría poner de esta manera:

Código:


-Compilar: sdcc -mpic14 -p%PIC -V --debug -I%FILEDIR -c %FILENAME
-Ensamblar: sdcc -mpic14 -p%PIC -V --debug -Wl-c -Wl-m -I%FILEDIR -o%NAME.hex %NAME.o
-Linker:



De esta manera ejecuta la acción contenida en "Compilar", luego la de "Ensamblar" y si todo va bién abriría el .hex generado.


Osea... en realidad solo harían falta dos entradas, una para ordenes que dán ".asm", ".o", o lo que sea que use la segunda acción y otra para órdenes que dán .hex como salida, independientemente de cual sea la acción.

Entonces estoy pensando que debería dejar solamente esas dos entradas, o dejar la tercera para añadir una acción adicional, por ejemplo grabar el PIC directamente si el compilado ha ido bién... o quizás simplemente Accion1, Acción2 y Acción3... no sé... opiniones??

También estoy pensando en añadir una opción para que muestre el archivo generado o no... muchas veces solamente compilo para comprobar que no hay fallos y no necesito el archivo.hex para nada, pero si quiero grabar es más cómodo si se abre el .hex automaticamente.

Geo... como lo haces con el CCS?...

En mi caso, no me interesa abrir el .hex salvo cuando lo desee hacer explícitamente. Tanto en SDCC como con CSS, solamente utilizo una línea, la de "compilar", por el momento que he probado con archivos de un solo fuente. En cuanto deba hacer uso de múltiples archivos, supongo que utilizaré "compilar" y "linker", que sería lo "adecuado", claro, hablando estrictamente de los nombres que se le están asignando a las acciones, pues puedo usar "compilar" como "assembler" con las mismas instrucciones, con la única diferencia de que en "assembler" abre el .hex generado.

Los entornos de desarrollo manejan estos pasos por separado y cuentan con una instrucción "construir" que ejecuta una tras otra. Pero tanto SDCC como CCS (los que he usado), son capaces de crear el archivo .hex (que al final es el objetivo, el código a descargar al pic) con una sola ejecución. Como yo lo veo, los que son equivalentes son "assembler" y "linker", en que se supone que para ambos, el resultado es un archivo .hex.

Lo que me parece es que deberíamos hacer un resumen del modo de trabajar para varias herramientas con las que se pretenda trabajar, si el compilador de X lenguaje genera .asm, lo "adecuado" es usar entonces la opción "assembler" y dejar vacía la "linker". Pero si el compilador genera archivos de código objeto (.o), como es posible en los compiladores de lenguaje C, entonces se utilizaría "linker" y se dejaría vacía la opción "assembler".

Sin embargo, al final, la opción de utilizar el "linker" para el caso de tener múltiples archivos objeto (que para mi sería el único caso en que realmente tendría sentido usarlo), no tiene tanto sentido en Gedit al no trabajar en base a proyectos y no contar con una lista de las "unidades" que componen el proyecto.

OK... ya me voy aclarando un poco.

Lo que creo es que todo depende mucho del compilador, incluso dentro de un compilador hay muchas posibles maneras de hacer las cosas.
Entonces quizás la mejor opción es no hacer definiones de antemano, sino simplemente dejar las tres entradas como paso1, paso2, paso3 o algo así y que cada uno las use como le parezca bién. luego el plugin simplemente ejecuta las tres acciones en ese orden y ya está.

Como se pueden usar todo tipo de comandos de bash es facil conseguir ciertas cosas, por ejemplo si queremos que una linea solo se ejecute si la anterior terminó sin errores podemos usar "&&" , ejemplos:

Compilar con SDDC usando linker:

-Paso1: sdcc -mpic14 -p%PIC -V --debug -I%FILEDIR -c %FILENAME &&
-Paso2: sdcc -mpic14 -p%PIC -V --debug -Wl-c -Wl-m -I%FILEDIR -o%NAME.hex %NAME.o &&
-Paso3: gedit %NAME.hex

Ejecuta cada paso solo si el anterior terminó sin errores, al final abre el .hex generado (si no hubo errores)

También podemos combinar varias acciones en una sola linea, por ejemplo:
Leer PIC con PicKit2:

-Leer: pk2cmd -P -GF%HEXTEMP && gedit %HEXTEMP

Lee el PIC y si no ha habido error abre el archivo.


O también si la cosa es algo más complicada llamar a un script con los comodines como parámetros.
Por ejemplo para grabar con PicKit2 yo uso esta estrada en el plugin:

-Grabar: $HOME/scripts/PicKit2/grabar_pic.sh %PIC %FILEPATH

Osea lanzo el script pasándole %PIC y %FILEPATH como parámetros

y el script es esto:

Código:


#!/bin/sh

error=`pk2cmd -p$1 -i | grep "mismatch"`

if [ "$error" = "" ] ; then
    pk2cmd -p$1 -x -m -f$2  # en $1 y $2 tenemos los parametros: PIC y  archivo
else
    echo $error
    exit 10000        #Esto es para que salga del script con un error por stderr
fi



Lo que hace es que si el PIC detectado no coincide con el que tengo seleccionado, entonces no graba el .hex

El programa lanzado no tiene porqué ser un script bash, puede ser cualquier programa.

Creo que de esta manera el usuario tiene total libertad para componérselas como crea.

Opiniones??

Pikitin escribió:OK... ya me voy aclarando un poco.

Lo que creo es que todo depende mucho del compilador, incluso dentro de un compilador hay muchas posibles maneras de hacer las cosas.
Entonces quizás la mejor opción es no hacer definiones de antemano, sino simplemente dejar las tres entradas como paso1, paso2, paso3 o algo así y que cada uno las use como le parezca bién. luego el plugin simplemente ejecuta las tres acciones en ese orden y ya está.

Me gusta la idea. Puede quedar como primer paso el compilador y como segundo el assembler o linker según se requiera, y tener un tercer paso para cualquier otra cosa .

Pikitin escribió:
Como se pueden usar todo tipo de comandos de bash es facil conseguir ciertas cosas, por ejemplo si queremos que una linea solo se ejecute si la anterior terminó sin errores podemos usar "&&"...
...
Creo que de esta manera el usuario tiene total libertad para componérselas como crea.

También me agrada esta cuestión de personalización, permite muchas cosas y da libertad.

Ahora viene lo bueno, hay que conseguir que más gente lo use para que también opine y haya más ideas para ir mejorándolo .

Hey kamaradas!

Aún no pruebo el plugin, pero por sus comentarios se nota que está quedando de lujo! muy buen trabajo el que hacen!
Y disculpa Pikitin, por ausentarme de este proyecto, pero es que me chingue (reprobé) una materia y estuve/estoy estudiando para aprobarla.
Deja ver que tal anda su plugin, aunque no lo probaré al 100% ya que no tengo un programador que funcione en ubuntu ni he instalado el SDDC. Pero cualquier ayuda que pueda aportar lo haré con gusto.

Buena Vibra!

Otra cosa que podría hacerse es, tener un botón que ejecute el paso 1, otro el paso 2, etc.
Y uno que ejecute todos los pasos uno tras otro.

De esta forma, podría solamente compilarse y, posteriormente, enlazar. Esto es necesario para los casos en que se trabaje en algún proyecto con varios archivos; o también, para trabajar en uno de los pasos (p. ej. compilación) hasta dejarlo listo y posteriormente pasar al siguiente.

Pues sí... me gusta la idea de un boton para cada cosa, aunque estaba pensando que quizás se le podría poner algo tipo check-box en vez de botones, así se podrían seleccionar los pasos que se van a ejecutar al darle a compilar....

Incluso ponerle un paso más... por ejemplo a mi a veces me interesa solo compilar; otras: compilar y abrir el .asm; otras: compilar y ensamblar; otras: compilar, ensamblar y abrir el .hex; ahora lo hago cambiando algunas cosiilas en las entradas, pero con 4 "pasos" podría elegir cual ejecutar según el caso.

También se pueden tener varias versiones de cada compilador, por ejemplo SDCC, SDCC+linker...

Aunque volvieno a lo de los botones...
Otra posiblidad es poner todo los botones en el panel lateral en vez de en la barra de herramientas... osea, ahora a la izquierda de cada entrada está el nombre: Grabar, Leer... Compilar... etc, entonces se podría poner un botón en vez de solo el nombre. Entonces quitar los botones de la barra de herramientas y dejar todo en el panel lateral con un botón para cada entrada.


aztk:
Pues nada... dale duro a esa materia que ya habrá tiempo de meterse con los PIC.
Aunque si pruebas el plugin y dás tu opinión pues estupendo; como dice Geo hacen falta opiniones e ideas, cuantas más mejor.

Por curiosidad.. ¿que programador usas?


Saludos.

Estoy intentando lo de poner los botones para ejecutar cada paso de la compilación en el panel lateral, pero no me está resultando nada facil... además el código está creciendo demasiado, así que voy a reorganizarlo y separarlo en varios archivos porque me estoy haciendo un lío.

En cuanto lo tenga más organizado sigo con esto.

Bueno... ya he reorganizado el tema y le he puesto botones en cada paso de la compilación para poder ejecutar un solo paso si queremos.

Ahora al darle al botón "compila" de la barra de herramientas se ejecutan todos los pasos que contengan algo, pero si alguno de ellos dá un error, el siguiente paso NO se ejecuta, osea que lo que comenté anteriormente de ponerle && al final ya no hace falta... es más, si se lo ponemos nos dará un error.

Si queremos que uno de los pasos no se ejecute le podemos poner almoadilla: # al principio, por ejemplo:

Paso1: comando1 -argumento -f%FILEPATH
Paso2: #comando2 -argumento
Paso3: comando3 -argumento

Solo ejecutará los pasos 1 y 3.

El tar.gz está en la zona de descargas con el nombre Gedit_Pic-IDE.1.0.1

Si la zona de descargas no va bién también podeis descargarlo de AQUI

Solo teneis que darle a donde pone: Download GNU tarball

Si es la primera vez que lo instalais podeis ejecutar: "instala.sh", si teneis la versión anterior y quereis conservar los archivos de configuracion podeis ejecutar: actualiza.sh; o copiar los archivos manualmente a la carpeta: $HOME/.gnome2/gedit/plugins

No sé qué pasa que no me está funcionando el widget de descargas, a vosotros os funciona?


Saludos.

Pues las posiblidades de Gedit con los plugins me tienen sorprendido... se puede hacer lo que quieras.

Ahora le he añadido otro juguetito al plugin... bueno todavía está en lo más básico, pero creo que se pueden hacer muchas cosas.

Se trata de una especie de terminal serie para conectar con el PIC, pedirle los valores de los registros que queramos y representarlos numericamente y graficamente, algo parecido al Liberlab, pero se le pueden pedir los registros que queramos sobre la marcha, con el PIC funcionando. AQUI podeis ver un video para que os hagais una idea, es cortito y está en formato GIF, así que la calidad no es la mejor, pero bueno.

Se vé un poco como funciona el plugin, compilar, grabar el pic y abrir la terminal y panel de graficos y ver algunos registros en accion.

Ahora funciona de manera continua y solo lee registros, pero la idea es que en el programa se puedan poner "breakpoints" y además de leer, poder también cambiar los valores de los registros en el pic y ese tipo de cosas.



No sé... se pueden hacer muchas cosas...

Para usar la terminal, ¿se necesita de agregar instrucciones especiales al código del programa del PIC?

Para usar la terminal, ¿se necesita de agregar instrucciones especiales al código del programa del PIC?

Si, por ahora es una rutina muy sencilla:

Hay que iniciar usart en el pic.
Habilitar interrupciones por recepcion Usart.
El pic atiende los datos recibidos por interrupciones, cuando recibe un dato lo lee y responde con el contenido de esa direccion de memoria.

en Basic es algo así:

Código:

Sub interrupt
    If PIR1.RCIF on then
        HserSend(PEEK(RCREG))
    End if
End Sub

Muy sencillito.

La idea más adelante es que el PC envie un comando y luego un dato, para poder tanto leer como escribir en memoria, eeprom e incluso flash...

La transmisión es puro byte, nada de ascii, así se hace más rápido.


Ideas?


EDITO:
Para no estar con lios de versiones voy a ir haciendo los cambios en este repositorio SVN:
http://piclinux.svn.sourceforge.net/viewvc/piclinux/Gedit_Pic-IDE/

Actualizado (20/10/09):
La ultima versión se puede descargar de aquí: Gedit_Pic-IDE.tar.gz

En "branches" está la versión anterior sin la terminal y en "trunk" los ultimos cambios que voy haciendo.

Pues ya he dado algunos pasitos más con el tema de la terminal, Ahora se manda al pic una instrucción y los datos, sigue siendo puro byte, cuando el pic recibe algo por usart salta una interrupción, ese primer dato siempre es una instrucción, según su valor hace una cosa u otra.
En el pic hay que #incluir el archivo terminal-pic.h donde están las rutinas que manejan todo esto.


Entonces por ahora lo que se puede hacer es:

-Leer registros del pic (en el rango 0-255):
Se puede usar directamente la direccion de memoria en decimal o su nombre, incluidas las variables usadas en el programa, por ejemplo en la columna "Registros" podemos poner: PORTA, porta, portA, STATUS, OPTION_REG....etc. o bien el nombre de cualquier variable que hayamos usado en nuestro programa.
Para esto es necesario tener como documento activo el programa en cuestión... puede ser el código en C, Basic, etc o el .asm o el .lst o el que sea.
El valor se muestra en decimal y binario.


-Modificar el valor de registros del pic (en el rango 0-255):
Para esto hay que pausar la lectura, modificar el valor en la columna de valores y darle al botón "Graba Regs".
Durante este tiempo el pic sigue corriendo; si queremos parar la ejecución del programa, por ahora solo se puede hacer añadiendo "breakpoints" en el código del pic... aunque quizás se debería añadir otro botón... uno para pausar la lectura y otro para pausar lectura y ejecución en el pic... nosé.
Aunque estemos en un breakpoint hay que pausar la lectura para poder escribir el nuevo valor del registro... esto creo que también lo tengo que cambiar... no tiene mucho sentido seguir leyendo valores mientras estamos en un breakpoint... aunque a veces si que puede tenerlo...


-Añadir "breakpoints" en el código del pic:
En el programa del pic se puede añadir un breakpoint haciendo una llamada a la subrutina "breakpoint" con un número como argumento, por ejemplo en GcBasic simplemente:

codigo
....
breakpoint 1
....
más código
....
breakpoint 2
....

En otros lenguajes usar la sintaxis de llamar a subrutina.

En Gedit podemos saber en que breakpoint estamos visualizando la variable "breakcount"

Hay un botón que activa la parada en los breakpoints llamado "Activar BP", si lo activamos el pic parará en cada breakpoint hasta que le demos al botón "Next BP".
Si lo desactivamos el pic no parará en los breakpoints.


-Cambiar la frecuencia con que se leen los registros:
Por defecto la lectura se hace cada 50 ms, es lo suficientemente rápido como para que parezca una lectura continua, sobre todo en cuanto a los gráficos, pero no afecta demasiado a la ejecución del programa en el pic... si ponemos un valor muy bajo entonces el pic está entrando en interrupciones muchas veces y esto puede afectar al programa que se esté ejecutando... pero todo depende de cada caso, así que añadí una entrada para poder cambiar el valor.


-Bueno... y también cambiar el puerto y velocidad... hay un botón que escanea y muestra todos los puertos serie disponibles en el PC y ahí podremos seleccionar el que estemos usando.
La velocidad está por defecto a 115200... esto es importante... una velocidad muy baja vá a afectar la ejecución del programa en el pic, así que mientras no sea estrictamente necesario lo mejor es dejar la velocidad a 115200.
Si queremos cambiar la velocidad también hay que cambiarla en el pic... esto se hace en el archvo donde están las rutinas de interrupciones, breakpoints, inicio de usart, etc. que deberemos #incluir en el programa que se ejecuta en el pic, o bien meter directamente las subrutinas en nuestro programa.
Como yo estoy usando GcBasic este archivo (terminal-pic.h) está hecho para GcBasic, pero se puede adaptar para otros lenguajes... por ahora es cortito.


Bueno... a ver si tengo un rato y hago un video... lo mejor es verlo para hacerse una idea de como funciona.

Actualizado (20/10/09):
La ultima versión se puede descargar de aquí: Gedit_Pic-IDE.tar.gz
Estoy añadiendo información de uso, etc aquí: http://piclinux.sourceforge.net



Saludos.