Ktechlab-gcb

Bueno, esto se trata del ktechlab modificado de este tema: http://pic-linux.foroactivo.net/ktechlab-f6/ktechlab-037-modificado-t216.htm

Entonces para distinguirlo se le puede llamar Ktechlab-gcb, en referencia a ktechalab y gcbasic.

La idea es ir informando y discutiendo ideas de los cambios que se van a hacer y de los que se podrían o los que pensais que sería bueno hacer.
Por ahora hay un par de pequeñas novedades (aunque todavía no publicadas):

-Solucionado el error al cargar directamente flowcode a un pic.

-Se han añadido varios ejemplos de circuitos con Pic, en Ayuda/Ejemplos.

-Hay paquetes deb para amd64, tanto de Ktechlab como GcBasic.

-Las entradas analógicas funcionan 100% sin afectar a las entradas digitales, en la actual version existe la opción de habilitar/deshabilitar el modo analógico, ya que al habilitarlo las entradas digitales se actualizan al mismo ritmo que las analógicas (100 us) y esto supone un seria limitación si que quieren usar ambas.
Para hacer que esto funcione hubo que modificar Gpsim y añadirle alguna que otra función que infroma de si una entrada está siendo usada como analógica. Pero creo que la posiblidad de usar sin limitaciones ambos tipos de entrada vale la pena.

-Al añadir un Pic al circuito aparece directamente un pic16f84 y se puede seleccionar el modelo de pic sin haber cargado un programa.
Una de las cosas que no me gustaba mucho es que para hacer un circuito con pic primero hay que cargar un programa y luego puedes hacer el circuito, pero no puedes hacer un circuito con pic sin programa cargado.
Esto tiene sus ventajas e inconvenientes, y aún tengo muchas dudas:

Debe el modelo de pic cambiarse automaticamente al cargar un programa??
...Pués a mí esto me ha fastidiado algún circuito, ya que si por error cargas un programa de otro modelo de pic totalmente distinto, el circuito se te vá al traste... quizás sería mejor que si cargas un programa con un modelo distinto te salga un mensaje de error, pero que deje las cosas tal y como están, y que sea el usuario el que determine el modelo del pic.

¿Que opinais de esto?

¿Que otras cosas creeis que se podrían añadir/quitar/mejorar?



Saludos

Estas cosas ya están en snv:

-Solucionado el error al cargar directamente flowcode a un pic.
-Se han añadido varios ejemplos de circuitos con Pic, aparecen en Ayuda/Ejemplos.

Ademas se han resuelto y suvbido a svn estas:

-Borra archivos temporales al cerrar ktecglab (antes nunca se borraban).
-En flowcode los nombres de variables ahora son largos, antes eran "x" y daban problemas con GcBasic.
-Flowpart delay: fuerza a valores enteros entre 1 y 65535, además se puede usar un "spinbox". Antes se podía introducir un valor con decimales, lo cual daba problemas.
-Aparecen correctamente los iconos referentes a GcBasic.

También he subido a svn el tema de seleccionar el modelo de pic, así se puede ir probando y ver ventajas e inconvenientes.
Entonces se pueden hacer circuitos con pics sin cargar el programa.
Por defecto al poner un pic en el circuito sale un 16f84.
El modelo de pic se selecciona de una lista desplegable con todos los modelos soportados.
Si se intenta cargar un programa para un modelo de pic distinto sale una ventana de aviso, pero no cambia el circuito ni carga el programa. Solo el usuario puede cambiar el modelo y solo un programa para ese modelo puede ser cargado al pic.



Siguiente posible paso: poder configurar los componentes digitales individualmente.
se podrían configurar estos valores:
-Voltaje de salida en estado alto.
-Voltaje de cambio a estado alto (rissing trigger).
-Voltaje de cambio a estado bajo (falling trigger).
-Impedancia de salida en estado alto.
-Impedancia de salida en estado bajo.

De esta manera se podrían tener componentes schmith-trigger junto con edge-trigger o colector abierto o distintos voltajes y potencias de salida en el mismo circuito.

Esto podría ser un paso hacia configuraciones predefinidas: cmos, ttl, etc..
Incluso hacia chips predefinidos... por ejemplo colocar un buffer simple en el circuito y poder selecionar distintos modelos de una lista.... pero esto son solo divagaciones.. por ahora.


Saludos.

Hola pikitin y a los demas, me parece bien separar el hilo porque practicamente lo vas a convertir en un programa casi nuevo. Yo ando mu liado para seguir con el tema que traia, espero poder ayudar pronto. Un saludo

zivago40: ok.. de todas formas ya tengo tus archivos para el tema de usart, faltaría alguno más, pero el trabajo ya está empezado.

Ya he subido a svn el tema de configurar las puertas lógicas individualmente, por ahora no todos los componentes, solo puertas lógicas, se pueden configurar estos valores:

-Voltaje de salida en estado alto.
-Voltaje de cambio a estado alto (rissing trigger).
-Voltaje de cambio a estado bajo (falling trigger).
-Impedancia de salida en estado alto.
-Impedancia de salida en estado bajo.

En cualquier momento se puede "resetear" a los valores de la configuración general.

También he modificado los buffer e inversores para poder seleccionar el número de elementos, por defecto este número es 1 y aparece igual que antes.. una sola puerta, si se pone un número mayor aparece como un "circuito integrado" con el número de elementos seleccionado, de esta manera es más facil "imitar" ICs como 74HC04, 74Hc244, etc. basta con elegir el número de puertas y configurar adecuadamente los valores.


Siguiente paso: añadir un registro de desplazamiento.. este componente lo he necesitado en varias ocasiones, ahora lo tengo como subcircuito, pero esto resulta muy ineficiente, ya que cada uno de estos subcircuitos contine varios componentes y la simulación se complica; hice una prueba con 8 de estos y la simulación se hace muy pesada, pero es lógico ya que esto supone cerca de 100 componentes en el circuito. creando un registro de despalzamiento directamente la cosa se simplifica mucho.

También hay que hacer una modificación de la ventana de configuración del pic en flowcode, yo lo he intentado, pero me estrello contra QT... no tengo ni idea y no consigo hacer las cosas más simples, así que si alguien conoce de QT y quiere ayudar con esto...

Luego hay una idea en mente: eliminar las dependencias de KDE... esto supone mucho trabajo y conocimientos (que yo no tengo), entonces aquí pido ayuda... si alguien está dispuesto a colaborar no tiene más que comentarlo por aquí.
El objetivo es dejar una aplicación solo dependiente de QT, y el camino es ir eliminando depencias de KDE paso a paso, sin que ktechlab-gcb deje de funcionar. Aquí es imprescindible la ayuda de gente que tenga conocimientos de C++ y si es posible de KDE.

Otra idea es hacer una versión en C del compilador GcBasic, que actualmente está escrito en Basic. Si alguien está dispuesto a meterse con esto pues estupendo. En principio se trataría de "traducir" de Basic a C.


Saludos.

Eliminar las dependencias de KDE creo que es lo mejor que se puede hacer, aunque seguramente sera a cambio de añadir mucho código al programa. De todas formas si conseguimos que este programa sea independiente del escritorio habremos dado un paso importante. Se podría incluso portar a Windows si alguien lo necesitara.
Despues de eliminar las dependencias ya sera otro programa distinto, que tal TechLab de nombre?

Hay que hacer antes que nada algo esencial, si podemos claro, convertirlo a Qt4, porque está en Qt3 y ya está demasiado desfasado.

Bueno... he añadido un registro de desplazamiento, por ahora de tamaño fijo 8 bits, tiene output enable... es el primer intento de triestado: con output enable a 1 (deshabilitado) la salida está a 0 y alta impedancia (10 Mohm), aunque hay un registro interno donde se siguen guardando los datos recibidos.

He sacado una rama (branch) para mantener Ktechlab con KDE como estaba antes, en la otra estamos haciendo los cambios kde->qt y algunas cosas están cambiando de aspecto (a peor.. claro) y aparecen en inglés, etc. Puede que también algún diálogo no funcione correctamente.
Así que la versión más estable es la de "branches".

Eliminar las dependencias de KDE creo que es lo mejor que se puede
hacer, aunque seguramente sera a cambio de añadir mucho código al
programa. De todas formas si conseguimos que este programa sea
independiente del escritorio habremos dado un paso importante. Se
podría incluso portar a Windows si alguien lo necesitara.

Si, yo creo que podría ser bueno.
Hay muchas cosas que se pueden cambiar de K a Q sin grandes problemas y sin añadir mucho código, aunque para mantener exactamente todas las funcionalidades a veces habría que crear nuevos widgets personalizados para sustituir algunos de KDE (por ejemplo), por ahora estoy optando por perder algunos detalles y cuando esté todo en QT plantearse el añadir o no funcionalidades.

Luego hay unas cuantas cosas que simplemente no existen en QT, habría que implementarlas o plantearse variantes. Por ejemplo la configuración por defecto, donde se guardan todos los datos de configuraciones del programa, archivos recientes, etc... no veo nada parecido en QT.. aunque quizás exista. He visto algunas implementaciones que se han hecho por ahí.. quizás se puedan usar. Si alguien tiene alguna idea.........

Hay que hacer antes que nada algo esencial, si podemos claro,
convertirlo a Qt4, porque está en Qt3 y ya está demasiado desfasado.

Si... la idea es pasar de K a QT3 y luego QT3 a 4,
El problema que veo es que KDE3 trabaja sobre QT3, entonces no se puede pasar a QT4 teniendo todavía KDE3... o si?? ... si se pudiera sería lo mejor: pasar de KDE3 a QT4 directamente.

Pero aquí me faltan muchos conocimientos... en teoría sería posible tener funciones de QT3 y 4 conviviendo en una app, pero actualmente el proyecto está configurado para compilar con QT3... ¿se podría hacer para que compilara para QT3 y QT4 a la vez??... quizás solo es una cuestón de incluir la ruta a las librerías QT4... pero no tengo ni idea... sugerencias?

Por ahora solo estamos cambiando algunos diálogos y cosillas así... a ver que problemas ván surgiendo.


Saludos.

Por lo que tengo entendido, pasar de Qt3 a Qt4 lo que haces es poner los widgets de la libreria support a qt3 que tiene qt4, pero yo he intentado pasar un programa sencillito y no es tan facil como pensaba

Has probado qt3to4 ?
Te pasa muchas funciones y te pone los #includes necesarios. solo tienes que ejecutarlo en la carpeta de las fuentes, primero con el nombre de cualquier archivo fuente que haya y entonces seleccionas "All", te convierte todos los archivos recursivamente y te genera un archivo de informe en cada carpeta con todos los cambios que ha hecho.

Ya he hecho alguna prueba. pero no sé donde poner la ruta de las librerías de QT4 para poder compilar.

Si lo que había probado era lo de qt3to4, pero utilizando un archivo .pro de QMake, sin este archivo no sabia como funcionaba.
Puedes tener las librerias de Qt3 y Qt4 a la vez? Porque creo que tienen competencias excluyentes, entonces nose como hay que hacerlo.
Porcierto pikitin estás usando svn para esto?