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

Aprobechando las posiblidades que ofrece Gedit con su sistema de plugins, he hecho uno para poder compilar y grabar PICs (gracias a aztk por sus consejos de Python).

El plugin crea algunas entradas en la barra de herramientas y el menú con las acciones más habituales: compilar, grabar, leer, verificar, etc:



El plugin también crea un panel en la parte inferior donde se muestra la información generada por las acciones.

En el menú hay una opción que abre esta ventana de configuración donde se seleccionan y configuran el programador, compilador y PIC:



En esta ventana de configuración se establecen los comandos que se ejecutan. Para incluir archivo de salida, carpeta de includes y PIC se usan las expresiones:
%OUT- archivo de salida (mismo nombre de archivo pero con extension .hex)
%INC - nombre de carpeta donde está el archivo actual
%PIC - modelo de pic actualmente seleccionado

Por ejemplo para GPasm la linea de comando podría ser esta:
gpasm -L -w1 -i -o%OUT -I%INC -p%PIC -ainhx32

Para grabar con PicKit2 se puede poner:
pk2cmd -P%PIC -M -F

El nombre del archivo actual en Gedit se anexa al final del comando.

En la configuración por defecto vienen GPasm y GcBasic en compiladores y PicKIt2 en programadores. Si crean nuevas configuraciones pueden postearlas para ir añadiéndolas.


El resaltado de código en C ya funciona en Gedit por defecto, para añadir
resaltado ASM y GcBasic ver este tema:
https://pic-linux.forosactivos.net/gedit-f27/resaltado-de-codigo-para-gcbasic-y-asm-en-gedit-t147.htm#444

Los archivos del plugin están en la seccion de descargas (GEDIT/Gedit_Pic-IDE), solo hay que descomprimir y ejecutar el instalador.sh, o si lo prefieren copiar los archivos a mano al directorio: /home/usuario/.gnome2/gedit/plugins/

Una vez copiados los archivos hay que iniciar Gedit (cerrarlo antes si estaba abierto) y en el menú Editar-Preferencias-Complementos activar el plugin llamado Pic-IDE; en ese momento aparecerán los elementos en la barra de herramientas, menús, etc.
Para volver a dejar Gedit como estaba solo hay que desactivar el plugin y desaparecerá todo.



Esto es una primera versión, todavía hay muchas cosas por pulir y es facil que tenga fallos... si encuentras alguno postéalo porfavor. También cualquier duda o sugerencia.


Saludos.

Lo instalé pero no puedo abrir la ventana de configuración. Ejecutando gedit en una terminal, al intentar ejecutar la opción configuración sale esto:

Traceback (most recent call last):
File "/home/josejorge/.gnome2/gedit/plugins/Pic-IDE.py", line 130, in on_configurar
self.ejecutar(accion)
File "/home/josejorge/.gnome2/gedit/plugins/Pic-IDE.py", line 215, in ejecutar
salida = proc.communicate()[0] #Leer mensajes de subproceso
File "/usr/lib/python2.6/subprocess.py", line 655, in communicate
stdout = self.stdout.read()
ValueError: I/O operation on closed file

Por si es necesario, uso Ubuntu 9.04 64 bits

Gracias por la información.

Voy a mirármelo, pero no creo que sea por la versión de Ubuntu, yo solo lo he probado con Hardy, a ver si instalo 9.04 y pruebo. Aunque si alguien lo ha probado ya en Jaunty y le funciona estaría bién que informara.

Una cosa que sería interesante es probar a lanzar la ventana de configuración desde teminal:

/home/josejorge/.gnome2/gedit/plugins/Pic-IDE/configura.py

.... Ahora que lo pienso seguramente para ejecutarlo hace falta tener instalado wxpython... bueno... casi seguro que es esto.

Entonces quizás debería compilar el configura.py y poner un binario en vez del .py... no?
... o quizás hacerlo en gtk en vez de wxpython...

Si... es un problema esto... tengo que hacerlo de otra manera.

Que opinais??

EDITO:
Pero te salen los iconos en la barra de herramientas y la nueva entrada de menú??

Se me pasó verificar eso . Yo uso wxWidgets, y di por sentado que tenía también instalada la versión para python, ahora mismo estoy instalando el paquete python-wxgtk2.8, en cuanto pueda probar comento de nuevo.

Si, los botones extra en la barra si aparecen.
------------------
Edición:

Efectivamente, el problema era que no tenía instalado wxpython.

Ahora, estoy intentando configurarlo para usar el compilador CCS (por el problema que tengo para usarlo con Wine y que mencioné en el foro de CCS). Coloco la opción %FILE pero CCSC me devuelve que no encontró el archivo %FILE, lo que me indica que no se ha hecho la sustitución por el nombre de archivo en turno, ¿sabes porqué puede ser? En cuanto pueda le daré una mirada al código, no he usado Python pero en C/C++ me muevo bastante bien .

Ok... espero que sea eso.

De todas formas tendré que incluir el binario para que pueda ejecutarse aunque no se tenga instalado wxpython.

Bueno... ya lo he corregido y he actualizado el Pic-IDE.tar.gz en la seccion de descargas. Con descargar y volver a instalar (instalar.sh) o copiar los archivos debería funcionar.

Gracias Geo.

EDITO:
Nada... ni binario ni nada... si no está instalado wxpython no hay nada que hacer....

Entonces... para una mayor compatiblidad, sería mejor hacerlo directamente en gtk?
A ver los que saben de programación que piensan de esto...

No entiendo, nuevamente tengo los mismos errores .

python-wxgtk si está instalado:

$ aptitude search python-wxgtk
p python-wxgtk2.4 - wxWindows Cross-platform C++ GUI toolkit (
p python-wxgtk2.6 - wxWidgets Cross-platform C++ GUI toolkit (
p python-wxgtk2.6-dbg - wxWidgets Cross-platform C++ GUI toolkit (
i python-wxgtk2.8 - wxWidgets Cross-platform C++ GUI toolkit (
p python-wxgtk2.8-dbg - wxWidgets Cross-platform C++ GUI toolkit (

Ejecuto gedit y al momento de intentar abrir la ventana de configuración:
$ gedit
Traceback (most recent call last):
File "/home/josejorge/.gnome2/gedit/plugins/Pic-IDE.py", line 130, in on_configurar
self.ejecutar(accion)
File "/home/josejorge/.gnome2/gedit/plugins/Pic-IDE.py", line 215, in ejecutar
salida = proc.communicate()[0] #Leer mensajes de subproceso
File "/usr/lib/python2.6/subprocess.py", line 655, in communicate
stdout = self.stdout.read()
ValueError: I/O operation on closed file

Desde la terminal si puedo visualizar la ventana de configuración con

$ .gnome2/gedit/plugins/Pic-IDE/configura.py

También, para el resto de comandos, me sale un error de que path.get_uri() no tiene un miembro replace:

Traceback (most recent call last):
File "/home/josejorge/.gnome2/gedit/plugins/Pic-IDE.py", line 148, in on_verificar
self.programador("[VERIFICAR]:")
File "/home/josejorge/.gnome2/gedit/plugins/Pic-IDE.py", line 164, in programador
path = path.get_uri().replace("file://", "")
AttributeError: 'NoneType' object has no attribute 'replace'

Este error:

Traceback (most recent call last):
File "/home/josejorge/.gnome2/gedit/plugins/Pic-IDE.py", line 148, in on_verificar
self.programador("[VERIFICAR]:")
File "/home/josejorge/.gnome2/gedit/plugins/Pic-IDE.py", line 164, in programador
path = path.get_uri().replace("file://", "")
AttributeError: 'NoneType' object has no attribute 'replace'

Es porque seguramente estás ejecutando los comandos sin singún archivo abierto en Gedit.
Ya lo tengo apuntado para arreglarlo.

Pero si abres algún archivo debería ir bién.


y Este....

Traceback (most recent call last):
File "/home/josejorge/.gnome2/gedit/plugins/Pic-IDE.py", line 130, in on_configurar
self.ejecutar(accion)
File "/home/josejorge/.gnome2/gedit/plugins/Pic-IDE.py", line 215, in ejecutar
salida = proc.communicate()[0] #Leer mensajes de subproceso
File "/usr/lib/python2.6/subprocess.py", line 655, in communicate
stdout = self.stdout.read()
ValueError: I/O operation on closed file

No tengo ni idea...

De todas formas el tema de la ventana de configuración lo voy a hacer en gtk, porque en wx es un rollo, he conseguido compilarlo de verdad y obtener un ejecutable, perome crea una carpeta con una copia de las librerías de wx...

A mi me gusta wxWidgets, pero supongo que GTK sería lo más adecuado para evitar la necesidad de más dependencias.

Tras instalar la última versión que subiste, al hacer clic en configuración me salía esto en la terminal y no se mostraba la ventana de configuración:

Traceback (most recent call last):
File "/home/josejorge/.gnome2/gedit/plugins/Pic-IDE.py", line 130, in on_configurar
self.ejecutar(accion)
File "/home/josejorge/.gnome2/gedit/plugins/Pic-IDE.py", line 215, in ejecutar
salida = proc.communicate()[0] #Leer mensajes de subproceso
File "/usr/lib/python2.6/subprocess.py", line 655, in communicate
stdout = self.stdout.read()
ValueError: I/O operation on closed file

Cambié a la versión .py en lugar de la compilada .pyc y pued ver nuevamente la ventana, aunque el error me sigue apareciendo cada que ejecuto algún comando. Me parece que está relacionado únicamente con la captura de mensajes de los subprocesos, por lo que por el momento no veo ningún problema en que continúes usando wxWidgets .

Ahorita he estado haciendo pruebas para intentar compilar con CCS, pero he encontrado varios detalles pues Python no me reconoce correctamente los caracteres acentuados en los nombres de directorios, el archivo que intento compilar se encuentra en
/media/José Jorge/Documentos/...
En el código de Pic-IDE.py agregué la impresión de la variable path que me muestra esto:
/media/Datos/Jos%C3%A9%20Jorge/Documents/...
y ccs me lanza una ventana para que indique el archivo a compilar, es decir, no lo reconoce correctamente :S.

El problema es que tampoco con rutas sin espacios trabaja, pues entonces me dice que la opción no es válida porque no maneja las rutas de Linux correctamente .
--------------------------
Edición
Finalmente, tras estarle moviendo al código fuente pude compilar con CCS y cargar el programa al PIC usando PICkit2 . Aunque me ha tocado batallar (sobre todo por mi nulo conocimiento de Python), al final creo que opté por la opción adecuada (en Piklab también tengo problemas para poder compilar con CCS, por detalles con el manejo de las barras diagonales en los nombres de archivo, pero estaba buscando una opción más sencilla que tener que modificar el código fuente de Piklab y un poco más amigable que crear scripts ).

Me ha gustado bastante este plugin, aunque en casos como el mío, en que pretendo hacer uso de software de Windows mediante wine, habría que agregar una forma más de manejar las opciones para agregar herramientas, por los detalles como el de los directorios.

Quizás para aplicaciones completas wx vaya bien, el problema aquí es integrarlo con Gedit... también pasa que la ventana de configuración congela el Gedit y se no se actualiza la ventana. De todas formas una ventana mas o menos sencilla como esa se puede hacer con gtk sin mucho problema... elmayor problema es mi ignorancia..

El fallo del subproceso creo que ya sé de donde viene.... es que lo hice bastante chapucero y el plugin intenta comunicarse con el subproceso cuando este ya está terminado.... no hay nada que controle la señal de que el proceso ha finalizado.
De todas formas creo que esto también lo voy a hacer distinto, ya estoy probando otro sistema, que es aprobechar las funciones de "herramientas externas", que tiene todo el tema de subprocesos bien hecho y además la salida vá al mismo panel inferior de herramientas externas, que está mucho más trabajado, con tipos de letra y un botón para detener el proceso si se queda colgado o lo que sea. Así queda un plugin mucho más sencillo... es casi como una extensión de herramientas externas.

También tengo que cambiar algunas cosas... por ejemplo siempre busca el documento actual aunque no haga falta... y algunas cosillas por el estilo...

También creo que habría que poner una entrada más donde introducir la ruta de los ejecutables, en vez de poner en cada comando toda la ruta.

La parte del linker todavía ni la he intentado, así que esa linea todavía está de adorno..

El tema del tratamiento de cadenas también habrá que verlo... ahora trata todo como cadenas normales, pero creo que se pueden tratar como UTF-8... supongo que esto arreglaría lo de los acentos, todavía no me he puesto a mirar como hacerlo, pero son detalles importantes... al final los detalles son los que complican la cosa...

Lo de las rutas de windows no lo tengo muy claro, la verdad es que he usado muy poco el wine y a veces he tenido líos con las rutas... todavía no tengo muy claro como lo hace el wine...
Por ejemplo, ¿qué le pones en linea de comandos para compilar un archivo con CCS?

Si me dices qué has cambiado para compilar con CCS lo tendré en cuenta... quizás hay que añadir más cosas a la ventana de configuración y al programa.

Dime todas las cosillas que veas que se pueden cambiar o mejorar, o cosas que faltan; porque voy a cambiarlo casi todo y todavía hay algunas cosas que no tengo claro como hacerlas.

Con SDCC tampoco he probado, pero en principio no debería haber mucho problema... a ver que pasa...

Pikitin escribió:
Lo de las rutas de windows no lo tengo muy claro, la verdad es que he usado muy poco el wine y a veces he tenido líos con las rutas... todavía no tengo muy claro como lo hace el wine...
Por ejemplo, ¿qué le pones en linea de comandos para compilar un archivo con CCS?

Si me dices qué has cambiado para compilar con CCS lo tendré en cuenta... quizás hay que añadir más cosas a la ventana de configuración y al programa.

Dime todas las cosillas que veas que se pueden cambiar o mejorar, o cosas que faltan; porque voy a cambiarlo casi todo y todavía hay algunas cosas que no tengo claro como hacerlas.

Wine agrega unidades virtuales, colocando z: como equivalente a /, lo que hice fue agregar al path antes de ejecutar el comando la letra de unidad:

Código:

if compilar != "":
    #compilar = compilar+" "+path+"\n"
    compilar = compilar+" z:"+path+"\n"


En cuanto a la configuración para llamar al compilador CCS, en la ventana de configuración del plugin puse esto:

wine ccsc +STDOUT +EA -P +DF +LSlst +O8hex +M -J -A +FH I+="/home/josejorge/ccspath/Devices"

La mayoría de los argumentos los tomé como los usan en Piklab (estaba buscando algún manual para usar CCS por línea de comandos, como no encontré pronto mejor eché un vistazo en Piklab ).
ccspath es un enlace simbólico a donde se encuentra instalado PICC, que sería más o menos
~/.wine/drive_c/Archivos de programa/PICC/
usé el enlace simbólico para evitar los problemas con los espacios en las rutas.
Lo extraño es que la forma de indicar la ruta (sin letra de unidad) me funciona para los directorios a incluir con la instrucción I+=, pero no para indicar el archivo a compilar (como comenté antes). Lo que me falta, es una forma de obtener el directorio en donde se encuentra el archivo actual, para también agregarlo a los directorios a incluir, que sería necesario en caso de que en el proyecto se utilice más de un archivo (por ejemplo, algún archivo .h extra). Por ahora lo estoy haciendo "a mano" ¿Cómo podría obtener dicha ruta? ¿hay algo como window.get_active_directory? Lo que por ahora pienso es obtener el path con window.get_active_document() y luego eliminar la parte que corresponde al nombre del archivo, pero repito, conozco muy poco de python y menos aún de las funciones de las que pueda hacer uso en gedit.

Lo siguiente que pensaba probar es con el plugin de herramientas externas, para checar qué tanto se puede configurar .

Para obtener la ruta, carpeta y nombre uso estas lineas (solo en Gedit):

Código:


        document = view.get_buffer()
        uri = document.get_uri()
        ruta = uri.replace("file://", "")
        nombre = os.path.basename(ruta)
        carpeta = os.path.dirname(ruta)



Pero yo tampoco se mucho... seguro que hay otras formas.
Creo que también se puede sacar directamente de:

document = view.get_buffer()
uri = document.get_uri()
carpeta = os.path.dirname(uri)


No había visto una edición de un mensaje donde hablabas del problema con "%FILE", y ciertamente hay un fallo ahí,, en el caso del programador y el assembler si hacía la sustitución, pero en el compilador faltaba la linea que hace la sustitución... un despiste.

Lo que me falta, es una forma de obtener el directorio en donde se
encuentra el archivo actual, para también agregarlo a los directorios a
incluir, que sería necesario en caso de que en el proyecto se utilice
más de un archivo (por ejemplo, algún archivo .h extra). Por ahora lo
estoy haciendo "a mano" ¿Cómo podría obtener dicha ruta? ¿hay algo como
window.get_active_directory? Lo que por ahora pienso es obtener el path
con window.get_active_document() y luego eliminar la parte que
corresponde al nombre del archivo,

En la nueva versión que estoy haciendo he añadido esa opción y otros "comodines" de estos:

%FILEPATH = ruta completa al archivo actual, ejemplo: /home/usuario/proyecto/codigo.c
%FILEDIR = ruta a la carpeta del archivo actual, ejemplo: /home/usuario/proyecto
%FILENAME = nombre completo del archivo, ejemplo: codigo.c
%NAME = nombre del archivo sin extensión, ejemplo: codigo
%PIC = modelo de pic en la ventana de configuracion, ejemplo: pic16f876a
%HEXTEMP = archivo temporal para visualizar .hex leido del PIC, crea el temporal en: /tmp/hextemp.hex

si ven que haría falta alguno más comentenlo.

Yo creo que la unidad la podrás poner en la misma ventana de configuración, por ejemplo:

wine ccsc -argumentos I+="/home/josejorge/ccspath/Devices" z:%FILEPATH

El comando ejecutado sería este:
wine ccsc -argumentos I+="/home/josejorge/ccspath/Devices" z:/home/usuario/proyecto/codigo.c

Al final lo que queda es una suma de todas las cadenas de texto, las comillas tambien las trata bién... yo pensaba que podría haber problema con esto, pero parece que funciona.

Este es otro ejemplo de como se podrá utilizar:
gpasm -L -w1 -i -o/home/otra/carpeta/%NAME.hex -I%FILEDIR -p%PIC -ainhx32 %FILEPATH


La ventana de configuración la voy a poner incrustada en el panel lateral... que les parece?




Ventajas?... inconvenientes?

También, cuando compila o lee el PIC abre el archivo.hex generado... aunque esto todavía tengo que pulirlo un poco.

No sé... si les ocurre otras cosas coméntenlas.


Saludos.

Tienes razón, se puede agregar la letra de unidad en la línea de configuración, se me pasó .

En cuanto a la ventana de configuración, no le veo ningún problema a que sea una ventana separada o como panel lateral, lo que me agrada del panel lateral es que la selección de herramientas se encuentra más "a la mano", aunque tampoco se esperaría que se cambien muy a menudo estas opciones. La que es probable que cambie más a menudo, es la del PIC a utilizar, y en tal caso está muy bien que se tenga a la vista y pueda editarse más rápidamente.

Como problema, los comandos largos serán más difíciles de visualizar al momento de la configuración.

Los "comodines" me parecen adecuados, viene bien el %NAME que me hacía falta en la parte de configuración del programador, para poder indicar que se descargue un archivo con el mismo nombre del fuente pero con extensión .hex. Eso y que todas las sustituciones se hagan para todas las opciones, de manera que sea "uniforme", está muy bien .

Ahorita he probado con el plugin de herramientas externas y fue bastante fácil la configuración porque se puede escribir los comandos a la manera de un script bash.

Como problema, los comandos largos serán más difíciles de visualizar al momento de la configuración.

Bueno... si, normalmente las opciones no se leen completas,pero el panel lateral se puede hacer del tamaño que quieras, osea que cuando haga falta escribir o leer opciones largas pues se puede ensanchar un poco el panel .

Ahorita he probado con el plugin de herramientas externas y fue
bastante fácil la configuración porque se puede escribir los comandos a
la manera de un script bash.

Si... el plugin "herramientas externas" está muy bien, es lo que yo estaba usando, pero todo lo coloca en el mismo menú... si vas a usar varios programadores y compiladores al final tienes un monton de cosas en el menú y es un lio. Y para compilar y programar hay que estar abriendo el menú, buscar la entrada que corresponde al compilador o programador que estes usando entre un monton de opciones, etc... y te lo pone todo mezclado con otras herramientas externas que tengas. LLega a ser un poco lioso, por eso me puse a hacer este plugin.
Además para cambiar las opciones de un compilador o programador hay que estar editando el script y es un poco menos comodo.

El caso es que al final he hecho otra versión que utiliza las funciones de ejecución de "herramientas externas" y va mucho mejor que los subprocesos chapuceros que yo había hecho.

Ya he colgado la primera prueba de esta versión en el panel de descargas, es: Gedit_Pic-IDE.1.0.tar.gz

IMPORTANTE!!: Hay que tener el plugin "Herramientas Externas" activado, sinó este plugin no funcionará; esto funciona casi como una extensión de herramientas externas.

El instalador.sh borra todos los archivos de la version anteior para que no haya confusiones... si alguien quiere conservarlos que les haga una copia y los coloque en otro lugar, pero el archivo Pic-IDE.py no puede quedar en la carpeta $HOME/.gnome2/gedit/plugins porque esta version usa otro esquema de archivos: el ejecutable está en la carpeta $HOME/.gnome2/gedit/plugins/Pic-IDE junto con los archivos de configuración y se llama "__init__.py" , así la carpeta de plugins queda más limpia.
Pero es importante que el archivo Pic-IDE.py de la anterior versión no esté en la carpeta de plugins.

Esta versión también va añadiendo los modelos de PICs que vas usando a una lista desplegable, así es facil de seleccionar el modelo, pero solo entre los que vas usando en vez de una lista de cientos de PIC.

Los comodines son los que comenté en el post anterior.

Para añadir nuevos compiladores y programadores solo hay que escribir el nombre y rellenar las opciones.

SIEMPRE que se haga un cambio hay que darle al botón "Guardar Cambios" para que estos se tomen en cuenta.

Y por ahora no se me ocurre nada más que haya que saber... cualquier duda pregunten. Y los fallos que vayan apareciendo o cosas que se puedan mejorar o que creais que faltan, pues también.

Saludos.

Ya lo probé y debo decir que va quedando muy bien . Sin embargo, me encontré con un problema al momento de mostrar el panel lateral, la ventana se "semicongela" y no responde adecuadamente, cuando abro un archivo teniendo la ventana de gedit maximizada, ésta se reduce y ya no es posible modificar su tamaño, tengo que ocultar el panel lateral (F9), ajustar el tamaño y entonces puedo mostrar nuevamente el panel.

Saludos .

El comportamiento extraño ese me pasó una vez que intenté añadirle al panel todas las explicaciones sobre los "comodines", pero ahora nunca me lo dá; he intentado provocar el fallo de todas las formas que se me ha ocurrido, pero nada...

De todas formas no he entendido bien en que situación te da el fallo,... simplemente con Gedit maximizado y abrir un archivo?

Que resolución de pantalla estás usando?
Tienes los efectos de escritorio activados?

He limpiado un poco el código y ahora he configurado todos los gidgets que van en el panel lateral como "flexibles" y he corregido algun fallito. Espero que esto corrija el error.

Voy a corregir otro fallo que es que siempre abre el archivo.hex aunque la compilación o la lectura hayan fallado. Entonces subiré todo a descargas.



EDITO:
Ya he subido los archivos con algunas correcciones.

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.