Ktechlab-gcb

Ya está totalmente resuelto el tema de la generación de código para 7segmentos en flowcode, ahora debería guardar bién el mapeo de conexiones y generar los #defines para todos los pines.

Saludos de nuevo pikitin!

Código:


Ya está totalmente resuelto el tema de la generación de código para
7segmentos en flowcode, ahora debería guardar bién el mapeo de
conexiones y generar los #defines para todos los pines.


Muchas gracias!!, y ya lo probe descargando tarball desde
http://piclinux.svn.sourceforge.net/viewvc/piclinux/ktechlab-Gcb/branches/ktechlab-gcb-0.3.7-0/
tal cual me sugieres mas arriba, ademas veo que hay una version 0.3.7-1 que supongo que es la que estan trabajando.

bueno pues con la novedad de que trabaja muy bien, solo que al igual, al hacer el make marca un error, en el archivo flowcode.cpp en la linea 371, que se encuentra en ./src/languages
*notese que lleva un punto, no se por que ,pero ahi lo encontre y en efecto en esa linea es donde pones los reemplazos de los nombres para la generación de los pines
i ahi estan las siguientes líneas

Código:


                        asval = QChar('A'+i);
                        if (i == 7)      addCode("#define DISP_SEG_DOT "+ name);
                        else if (i == 8) addCode("#define DISP_SEL_1 "+ name);
                        else            addCode("#define DISP_SEG_"+asval+" "+ name );
                        i++;


en la parte de arriba en la línea 361 tienes declarada la variable entera indic, y pues revisando lo demás del código usas la variable llamada 'indic'

asi que lo único que hice fue hacer el cambio por dicha variable quedando así

Código:



                        asval = QChar('A'+indic);
                        if (indic == 7)      addCode("#define DISP_SEG_DOT "+ name);
                        else if (indic == 8) addCode("#define DISP_SEL_1 "+ name);
                        else            addCode("#define DISP_SEG_"+asval+" "+ name );
                        indic++;


con esta pequeña modificación, me ha compilado muy bien make y make install
ahora ya me ha generado muy bien los numeros de los pines, pero veo que la lectura del adc ma manda bien lejos ahora

marcandome los siguientes errores

Código:


Construyendo: /tmp/kde-mike/ktechlab7MI4rb.gcb
*** Generación de código GcBasic correcta ***

Construyendo: /tmp/kde-mike/ktechlabNGyD5b.hex
gcbasic -O:/tmp/kde-mike/ktechlabdaHwaa.asm -NP /tmp/kde-mike/ktechlab0YyM1b.gcb
Great Cow BASIC (0.9 12/8/2009)
Compilando /tmp/kde-mike/ktechlab0YyM1b.gcb ...
Errores han sido encontrados:
/tmp/kde-mike/ktechlab0YyM1b.gcb (34): Precaucion: Simple letra como
variable: X
/usr/share/GcBasic/include/lowlevel/a-d.h (95): Error: Parametro incorrecto
en Set, esperado: Set variable.bit status
/usr/share/GcBasic/include/lowlevel/a-d.h (96): Error: Parametro incorrecto
en Set, esperado: Set variable.bit status
/usr/share/GcBasic/include/lowlevel/a-d.h (97): Error: Parametro incorrecto
en Set, esperado: Set variable.bit status
El mensaje ha sido escrito al archivo Errors.txt.
*** Compilación fallida ***


el codigo que ha generado el ktechlab ha sido este (ke por cierto se ve muy a todo dar )

Código:



'_____________________________________________________

' Código GcBasic generado por Ktechlab-Flowcode
'_____________________________________________________

' Modelo de chip y velocidad de reloj:
#chip P16F628A, 20 'MHz

' Mapa de pins Siete-segmentos: dos
#define DISP_SEG_A PORTB.0
#define DISP_SEG_B PORTB.1
#define DISP_SEG_C PORTB.2
#define DISP_SEG_D PORTB.4
#define DISP_SEG_E PORTB.5
#define DISP_SEG_F PORTB.6
#define DISP_SEG_G PORTB.7

' Mapa de pins Siete-segmentos: uno
#define DISP_SEG_A PORTB.5
#define DISP_SEG_B PORTB.6

' Valores iniciales:
variable1 = 0

TRISA = 126
TRISB = 0

PORTA = 0
PORTB = 0

' Inicio: _____________________________________________

Do While x = 1
    variable1 = ReadAD(AN0)
    DisplayValue 1, variable1
Loop

end



y el flowcode del cual ha sido generado es el siguiente

bueno pues con la novedad de que trabaja muy bien, solo que al igual,
al hacer el make marca un error, en el archivo flowcode.cpp en la linea
371, que se encuentra en ./src/languages
*notese que lleva un
punto, no se por que ,pero ahi lo encontre y en efecto en esa linea es
donde pones los reemplazos de los nombres para la generación de los
pines
i ahi estan las siguientes líneas...

Pues sí... tienes toda la razón. Gracias por el aviso, ya lo he corregido y suvido a svn.

Respecto al segundo fallo no es tal fallo... es que el p16f628a no tiene ADC. Prueba con un p16f876a por ejemplo.

Lo que me extraña el mapeo de pines que tienes:

Código:

' Mapa de pins Siete-segmentos: dos
#define DISP_SEG_A PORTB.0
#define DISP_SEG_B PORTB.1
#define DISP_SEG_C PORTB.2
#define DISP_SEG_D PORTB.4
#define DISP_SEG_E PORTB.5
#define DISP_SEG_F PORTB.6
#define DISP_SEG_G PORTB.7

' Mapa de pins Siete-segmentos: uno
#define DISP_SEG_A PORTB.5
#define DISP_SEG_B PORTB.6

uno completo debería ser así (por ejemplo):

Código:

'Sevensegment pin map: uno
#define DISP_SEG_A PORTB.0
#define DISP_SEG_B PORTB.1
#define DISP_SEG_C PORTB.2
#define DISP_SEG_D PORTB.3
#define DISP_SEG_E PORTB.4
#define DISP_SEG_F PORTB.5
#define DISP_SEG_G PORTB.6

#define DISP_SEG_DOT PORTA.2
#define DISP_SEL_1 PORTA.3

En el tuyo falta el punto que no es imprescindible (solo si lo vas a usar) pero también falta el común: DISP_SEL_1 este pin deberías conectarlo para que funcione... ¿o lo has conectado pero no te genera esa linea?
Si quieres usar varios displays esto todavía no está implementado en flowcode, pero tendrías que añadir un define para el display 2:

Código:

#define DISP_SEG_A PORTB.0
#define DISP_SEG_B PORTB.1
#define DISP_SEG_C PORTB.2
#define DISP_SEG_D PORTB.3
#define DISP_SEG_E PORTB.4
#define DISP_SEG_F PORTB.5
#define DISP_SEG_G PORTB.6
#define DISP_SEG_DOT PORTA.0
#define DISP_SEL_1 PORTA.1

#define DISP_SEL_2 PORTA.2

Y conectar los dos displays multiplexados, como en en el ejemplo del voltímetro: voltimetro

Otra cosa: mejor no uses variables de una sola letra: "X"
En principio algunas variables salian por defecto como X en flowcode, pero esto creo que lo cambié.. aunque quizás fué solo en 0.3.7-1... tengo que revisarlo.

En principio no hay problema por usar variables de una sola letra, Gcbasic solo debería dar un "warning", pero tal y como está ahora se detiene tanto en errores como en warnings... estó será corregido cuando suba la nueva actualización de GcBasic que acaba de salir,... pero voy a esperar unos días a que salgan y se corrijan los posibles fallos de esta actualización.

Por ahora todo funciona si no usas variables de una sola letra.

Saludos.

Respecto al segundo fallo no es tal fallo... es que el p16f628a no tiene ADC. Prueba con un p16f876a por ejemplo.

Tienes toda la razon se me olvido por completo que el pic16f628 no tiene adc, me emocione

mmmm interesante lo de los dos display, solo que no fue mi intención usar dos display multiplexados, lo que sucedió es que primero había hecho ya una definición de bits, pero no válida posteriormente, aplique una nueva disposición de pines, la que se indica como dos. y me encimo ambas, no me había percatado de dicho problema.
bueno voy a revisar de nuevo y veamos que sale.

Gracias.

Por lo que veo ktechlab usa una ventana de kate para la ventana principal, si queremos quitar todo lo k, esto va a ser lo mas importante y también lo mas dificil.

Código:


KTechlab::KTechlab()
    : KateMDI::MainWindow( 0, "KTechlab" )
{
   

¿Alguna idea de como solucionar esto? Bueno la solución cutre seria copiar la libreria necesaria de KDE al src de kTechlab :S

Por lo que veo ktechlab usa una ventana de kate para la ventana principal, si queremos quitar todo lo k, esto va a ser lo mas importante y también lo mas dificil.

Bueno.. en realidad no es que use Kate, KateMDI crea de las vistas de documentos, panales y todo eso; pero ni siquiera usa la librería de kde sino esta: src/katemdi.h
Aunque es bastante parecida a la original, no sé porqué lo harán así.

¿Alguna idea de como solucionar esto? Bueno la solución cutre seria copiar la libreria necesaria de KDE al src de kTechlab :S

Pues eso es que hace actualmente ktechlab: src/katemdi.h


Lo que habría que hacer es buscar sustitutos para las funciones "K" y que la cosa siga funcionando...
Pero aquí se va complicando la cosa...

vale, estaba equivocado yo, y son muchas las funciones "K"??

hoy termine de crear el file hex con ktechlab.tengo que cargarlo en el pic 16F876A para provar
pero me di cuenta que en el elenco de pic no esta el 16F767 .en mi caso es el master.hay por caso un update chipdata??

pero me di cuenta que en el elenco de pic no esta el 16F767 .en mi caso es el master.hay por caso un update chipdata??

Pues en Ktechlab ese pic no se puede simular, pero en GcBasic si está soportado, entonces no deberías tener problemas para compilar y todo eso.

Aprobecho para comentar algunos cosas nuevas:

Todo esto se refiere a la versión de "branches" de svn.

Se ha corregido un fallo que había al simular algunas interrupciones, por ejemplo: interrupcion por PORTB,0 y PORTB-Change.

Se han añadido algunos flowparts:

- Operaciones matemáticas: +, -, *, /.
- Operaciones lógicas: AND, OR, XOR, NOT.
- Interrupciones: comparadores, eeprom, PortB0, PortB, Timers, Usart.

Saludos.

Las actualizaciones están en las direcciones que me diste anteriormente??

Digo para compilar lo que hay de nuevo y probar
Saludos!

Si, creo que si, pero por si acaso está aquí: http://piclinux.svn.sourceforge.net/viewvc/piclinux/ktechlab-Gcb/branches/ktechlab-gcb-0.3.7-0/

En la parte de abajo, click en: Download GNU tarball (o aquí mismo )




Saludetes...

Ok gracias!!

Lo dejare para luego por que mi mujer ya me llama,:p se me hizo temprano (son las 3:05am)

Saludos

Será bueno poner este fork que estas realizando en la wikipedia??
Saludos

Pués nosé... quizás estaría bién, aunque todavía hay algunas cosas que están un poco verdes y yo ultimamente tengo muy poco tiempo para esto.

Precisamente estoy en el tema de publicar otra versión con los últimos cambios, la última versión de GcBasic y una versión de Gpsim que soluciona definitivamente el problema de las entradas analógicas, pero me gustaría solucionar algunas cosillas y que todo se aproxime un poco más a los estándares de Linux y debian. Pero vá muy despacio.

Si lo dices porque estás dispuesto a hacerlo pues creo que estaría bién.


Saludos.

Si alguien quiere ir probando (e informando de fallos, etc) lo que será la próxima versión, he subido unos instaladores .deb aquí: http://www.box.net/shared/qknbjx9fjy en el tar.gz están los 3 .deb (compilado en Ubuntu Hardy 32 bits)

No son paquetes .deb propiamente dichos, solo instaladores, entonces es
posible que no vayan bién en sistemas donde nunca se instalaron
ktechlab o gpsim (estos instaladores no comprueban dependencias).
Entonces si nó los tenías, primero instala Ktechlab y Gpsim de
repositorios, para que se instalen dependencias y sobre eso instalas
estos paquetes. Con GcBasic no hay problema.

Está la última versión de GcBasic, Gpsim-0.24.0 modificado para que funcionen normalmente las entradas analógicas y Ktechlab-gcb que utiliza esta modificación de Gpsim ( esto no está en svn) además de todas las modificaciones comentadas ultimamente (basada en svn/branches).

En la versión final quizás se añada algún que otro cambio, pero todo lo que sea probar y localizar errores es muy util.


Algunas notas sobre esta versión (que recuerde ahora):

-
Desaparece "modo analógico", ya no es necesario, ahora entradas
analógicas funcionan OK siempre (con este gpsim, que está un poco
modificado, con Gpsim de repositorios no funciona).... este es un tema
delicado... que piensas?

- Nuevos componentes: steeper, shift register.

- Componentes
modificados: 7seg: luz sobre negro y pines arriba y abajo, matriz-led:
luz sobre fondo negro; puertas lógicas: características editables para
cada componente, buffer e inversor: se puede elegir el nª de elementos
(simula chip).

- Colores en componentes.

- Flowcode, nuevas partes: interrupción, operacion matemática, operación lógica.

- Flowcode, implementado 100% uso de 7seg y keypad.


Saludos.

¿Has pensado en crear un repositorio para los .deb? No creo que sea muy dificil, que yo sepa solo es un servidor http y no creo que hoy en dia sea muy dificil encontrar un hosting gratuito.

¿Has pensado en crear un repositorio para los .deb? No creo que sea muy
dificil, que yo sepa solo es un servidor http y no creo que hoy en dia
sea muy dificil encontrar un hosting gratuito.

Pues no había pensado en eso, pero parece buena idea; aunque nunca he hecho nada parecido.

Pero no sólo está el tema del alojamiento, mantener un repositorio creo que tiene su tema, estándares y demás... y yo no sé nada sobre estas cosas, pero es cuestión de pensárselo o de que alguien que tenga idea se ponga a ello.

Queda apuntada la idea...


Saludos.

Pikitin, piensas cambiarle el nombre al fork este de ktechlab, no se si sería muy difícil, pero facilitaría las cosas a la hora de probarlo, problemas con otros paquetes(siempre tengo que hacer un hold al paquete) y ademas facilitaría el poder crear un repositorio.
Sobretodo es por esto ultimo, si le cambias el nombre, me pondré a mirar como hacer el repo.
Un saludo

Pikitin, piensas cambiarle el nombre al fork este de ktechlab, no se si
sería muy difícil, pero facilitaría las cosas a la hora de probarlo,
problemas con otros paquetes(siempre tengo que hacer un hold al
paquete) y ademas facilitaría el poder crear un repositorio.

Pues me parece buena idea, facilitaría algunas cosas y además se podría tener tanto Ktechlab como este fork a la vez.

LLeva un poco de trabajo, porque tendría que ser una aplicación nueva, con nuevos archivos de configuración, traducciones, etc.. que se instalaran en distintas carpetas y demás.


Pero me voy a poner a ello... a ver que sale.

Si necesitas ayuda, todo lo que pueda hacer dímelo.

Gracias por el ofrecimiento.

Para lo del cambio de nombre no ha hecho falta, al final no era para tanto.

He hecho una versión llamada "eleclab" (es lo primero que se me ocurrió) y funciona bién, se instala en su propio directorio,etc.

Si quieres verte lo del repositorio sería estupendo. Aunque todavía hay algunos detalles que solucionar, pero se podría ir adelentando.
Respecto al alojamiento, creo que podríamos usar el espacio de la cuenta piclinux en sourceforge.


Saludos.

Ultimamente le he estado dando muchas vueltas a lo de ktechlab... y lo que veo es que es una aplicación muy compleja, es muy dificil encontrar errores, dificil de mantener y es un verdadero lío intentar entender algo en la maraña de clases y el montón de archivos que hay que ver.

Entonces he pensado que quizás estaría mejor tener algo más simple, que sea más facil de depurar y mantener y no repetir cosas que ya hacen otras aplicaciones.

Por ejemplo, para compilar, depurar y grabar al pic ya están piklab, pikdev, gpsim y otras IDEs o editores.

Entonces podría estar bién un programa que solo sea simulador de circuitos que incluya PICs (y creo que se podría incluir AVRs) y quizás otro programa para flowcode.

La cosa se simplificaría muchísimo, se podría hacer un simulador más eficiente y mucho más ligero y sería muchísimo más facil eliminar las dependencias de KDE y convertirlo en una app QT pura.

Que opinais al respecto??


Saludos.

Ktechlab, por lo que me parece es un remix un poco destartalado de las antiguas aplicaciones de electronica de kde como ktechlab, por eso es tan lioso y complejo, pero si quieres comenzar un proyecto nuevo para simulación de circuitos y micros, puede ser interesante. Pero antes que nada yo intentaria buscar la máxima integración con otros proyectos como pueden ser gEDA, gnucap o fritzing, por que si pensamos las cosas puede salir algo muy bueno, si no mejor nos quedamos con ktechlab y menos complicación.
Por otra parte yo ahora estoy trabajando con el 8051 y creo que no hay ningun simulador para éste en linux, se que del 8086 si que hay pero este no lo conozco, seria interesante saber si puedo adaptar gpsim para que me lo simule y si lo consigo poder integrarlo con esta nueva herramienta que estas pensando.
Un saludo

Pero antes que nada yo intentaria buscar la máxima integración con
otros proyectos como pueden ser gEDA, gnucap o fritzing, por que si
pensamos las cosas puede salir algo muy bueno, si no mejor nos quedamos
con ktechlab y menos complicación.

Si, eso estaría muy bién, pero habría que conocerse bién el tema.
Había pensado algo parcecido con Qucs, que me parece que hace buenas simulaciones; bastante precisas, mirando por ahí ví que el máximo error en intensidades está por defecto a 1 pA... no está mal...
Además se puede acceder al simulador (qustator o algo así) directamente por linea de comandos o integrarlo en otro programa. Pero claro, no iría en tiempo real ni de lejos. Aunque quizás disminuyendo la precisión se pueda hacer algo...

Nosé... se podrían hacer muchas cosas, pero por ahora estoy en hacer una versión muy básica, pero lo más eficiente posible sólo del simulador de circuitos de ktechlab (quizás añadiendo AVR más adelante) y que no dependa de KDE.

Cuando entieda un poco cocmo funciona pués ya veremos. Pero con esto tengo para entretenerme un rato.

Por ahora tengo una versión sólo el simulador (todavía KDE aunque con muchas cosas pasadas a QT), que ya compila y funciona bién. Pero sigue manteniendo la misma estructura de clases.

Luego comenté todo lo que queda de KDE (mayormente para la GUI) y le puse un main.c QT, y compila y funciona, aunque no hace nada porque muchas cosas estan desactivadas, pero es una aplicación QT3 pura y todo compila y el programa arranca y muestra la lista de componentes... Al fin y al cabo ya estamos hablando de Qtechlab..

Ahora estoy haciendo una GUI QT4 y le estoy añadiendo cosas, mientras las paso a QT4 y simplificando clases; esto está complicado, pero creo que poco a poco irá funcionando. Ya me saca la lista de componentes... aunque solo con una resistencia..

En cualquier caso El ktechlab original y el fork este siguen ahí, pero es un lío seguir haciendo cosas con estos.

Lo que me gustaría es un simulador lo más sencillo posible, pero que funcione más o menos bién y que sea más facil de mantener, de encontrar errores y de añadir componentes y algunas funcionalidades.


A ver que sale...

He subido los últimos cambios de Ktechlab-gcb al proyecto en sourceforge, con el nombre de aplicación "ktechlab-gcb", así que se instala en otra carpeta que el ktechlab original, así se pueden tener las dos versiones a la vez.

Esto es el Ktechlab-gcb normal, no los experimentos de los que hemos hablado en los últimos mensajes.

Cuando tenga un poco de tiempo a ver si recopilo información sobre todos los cambios que se han hecho. La mayoría los he comentado por aquí, pero algunos creo que no.
Que me acuerde ahora se ha modificado el componente "RAM" para que las salidas sean realmente triestado, así se pueden unir entradas y salidas de datos directamente y conectar las dos a un bus de datos, he subido un ejemplo de un bloque de memoria a la sección descargas/ktechlab/circuitos/digital.


Como hay que descargar e instalar 3 paquetes (ktechlab, gpsim y gcbasic) he subido también un sencillo script que descarga e instala los deb correctos (últimas versiones), evita errores y se hace más sencillo para el usuario.

El script se puede descargar de aquí:
https://sourceforge.net/projects/piclinux/files/Ktechlab-Gcb/Ktechlab-gcb%20_installer/download

No sé porqué, pero no se añade la entrada al menú (al menos a mi no me ha funcionado), así que hay que lanzar desde terminal o añadir al menú manualmente.


Saludos.