otro simulador

Hola a todos.

Después de pelear un tiempo con el ktechlab pensé que estaría bién un programa que sea solo simulador de circuitos, mucho más sencillo y que fuera más facil de mantener y encontrar fallos y todo eso.

Entonces en eso estoy liado: un simulador que toma algunas ideas del funcionamiento (y algo de código) de ktechlab, pero es muchísimo más sencillo (por ahora) y no está basado en kde, sino en Qt4.

Por ahora solo hay un par de cosas básicas; pero ya está funcionando, al menos para circuitos digitales, aunque solo hay unos pocos componentes, los mínimos para probar el funcionamiento.

En principio voy a empezar solo simulaciones digitales, aunque basadas en voltajes, de manera que en un futuro se integre con lo analógico (si llego) y además que la simulación tenga en cuenta las impedancias de entrada y salida y todo eso.

Estoy pensando en incluir también los tiempos de retardo de las puertas y poder ajustar el tiempo entre pasos de simulación, poder simular paso a paso o en continuo pero con una escala de tiempo.. por ejemplo ajustar el paso a 1 uS y simular en continuo un paso cada 1 segundo o simular paso a paso; así se podrían simular circuitos con puertas y ver bién como se comportan.

La idea es añadir también los Pic (y quizás AVR), pero todavía hay cosas básicas que resolver...

Tal y como está ahora, no existe un simulador propiamente dicho, todo vá con señales/slots, así que se simplifica bastante la cosa. No sé si este sistema se podría aplicar a la parte analógica, osea.. que no hayan cálculos de mallas y todo eso sino que cada componente calcule lo suyo y emita señales conectadas a slots de los demás componentes... lo veo dificil, le he dado un par de vueltas al tema y está complicado, pero quizás se pueda hacer algo.

Hay unas pocas cosas importantes que todavía no he resuelto, la principal es el tema de guardar y abrir los circuitos, todavía no tengo idea de cómo hacerlo...

Les dejo unos vidiecitos para que vean como vá la cosa:

https://www.youtube.com/watch?v=qryIxUeZNnk
https://www.youtube.com/watch?v=sHdmI_9nkl4

Se me olvidaba: el enrutado de los conectores es siempre manual y se pueden mover tanto los componentes como los "cables", así se puede reajustar el circuito tanto como se quiera.

Comentarios, ideas, soluciones?....


Saludos.

Por donde empezar .
obviamente mis felicitaciónes por iniciar este proyecto muy bueno, me gusto mucho, cada día me sorprendo mas, pikitin puedes enviar el codigo fuente para analizarlo, yo no soy un experto en programación pero he estudiado algo últimamente. y me gustaría participar en este proyecto.


RiSanti

Me alegro que lo veas interesante, todavía tengo que limpiar un poco el código para que se entienda un poco, pero estamos en contacto.

Saludos.

Bueno, ahí dejo otro video para que se vea como va la cosa.

Es un intento de simular el circuito de un biestable j-k, por ahora solo funciona paso a paso, y los elementos, tanto puertas como nodos y conexiones cambian de color para ver como se van transmitiendo las señales.

Video

Saludos.

Bueno... sigo poniendo vidiecitos de los avances, aquí la primera simulación con un Pic:

Video

Típico led parpadeante.

El código es el mismo de Ktechlab (inerface con Gpsim), adaptado y bastante simplificado. Y a diferencia del Ktechlab-gcb no necesita un Gpsim modificado para que funcionen las entradas analógicas.

Diferencias con Ktechlab:
todos los pines funcionan (casi todos), de hecho no tiene botones para iniciar, resetear y eso, el pic funciona cuando se le dá alimentación; en los pics con pin mclr este también funciona para resetear.

El programa se carga desde el menú que sale con el botón derecho del ratón

Una pasada los videos (en ogg, los primeros que veo ), cuando podremos deleitarnos con el codigo fuente? Lo estas programando con QtCreator, a pelo o como?
Me encanta el programita, le veo muchas mas posibilidades que a ktechlab.
Un saludo y animo con este proyecto.

Que tal litox9?

Si, ya me voy haciendo al Qt Creator y la verdad es que dá muchas facilidades y se avanza rápido, aunque siempre echo mano de algún otro, por ejemplo el creator no tiene para reemplazar texto en en varios archivos y eso a veces es necesario, así que tiro de Gedit o de Kdevelop, aunque también he provado el Code::Blocks, otro entorno a base de plugins que está muy bién.


Hace un tiempo estoy por colgar el código en algún servidor SVN o por el estilo, pero el caso es que todavía estoy haciendo muchos cambios drásticos y hasta que no consiga definir cual va a ser la estructura definitiva no sé si es conveniente subirlo.

Por ejemplo ayer estube probando algunos timers para poder simular con mayor resolución, actualmente usa el mismo sistema que Ktechlab: un Qtimer, pero estos timer solo tienen una resolución garantizada de unos 20 mS aunque con 10 mS funciona bién, pero sigue siendo muy poco.

Al final conseguí echar a andar un timer Posix con granularidad de nanosegundo y a 500 uS va +- bién; a 100 uS funciona pero el problema es la GUI.
Estube haciendo algunas mediciones de tiempos, por ejemplo la llamada al componente-Pic para que ejecute una serie de pasos de Gpsim toma una media de menos de 800 nS (nanosegundos) cuando la GUI está totalmente en reposo, pero con solo mover el ratón por el circuito este tiempo sube por encima de 2.000.000 nS, osea unos 2 mS.
Esto es solo la llamada a la función sin que esta haga nada, luego Gpsim es muy rápido, incluso ejecutándose dentro del mismo proceso que la GUI puede ejecutar 100 pasos en poco más de 10 uS, esto es con el led parapadeante, ADC u otras cosas puede tomar más tiempo.

Entoces creo que es esencial separar la simulación de la GUI en dos procesos independientes, para que la simulación pueda correr a su máxima velocidad sin ser bloqueada por la GUI, luego esta debería leer los datos que necesite para repintar el circuito cuando sea necesario, o quizás a una frecuencia constante, pero entre 10-20 veces por segundo.
También se puede dar al proceso simulador la máxima prioridad y quizás así se pueda implementar un timer de unos pocos uS, el límite está en la máxima resolución que el Kernel pueda dar.

Esto supone replantearme todo el programa, incluidos los componentes; quizás cada componente tenga dos clases: una para la GUI y otra para la simulación... no sé...

En cualquier caso a mi no me importa subir el código tal y como está, pero todavía es inestable y hay ciertas cosas que no se pueden hacer, además de que seguramente muchas cosas ván a cambiar totalmente.


Saludos.

Interesante y complicada la simulación en tiempo real, pues si, aclara tus ideas y organizate primero antes que nada, porque sinó es tiempo perdido, pero aún así lo veo muy bien y espero ver mas abances.
Saludos

Felicitaciones por el emprendimiento, la verdad que esta muy muy bueno.... Hacia tiempo que no entraba al foro, por problemas de tiempo y porque hacia bastante que no podía jugar con los pics.
Me gusta la dirección que le querés dar al proyecto. Como consejo te podría decir que trates de bajar el nivel de las partes lo mas abajo posible, para poder sacar el máximo provecho del CPU y porque no GPU...
Por ahí implementar como bien decis, el GUI y la simulación por separado, podría ser con hilos, usando pthreads por ejemplo y aprovechar micros multicore. En el caso de acelerar la GUI podes ver algo de OpenGL, no es muy complicado usarlo. Se que es para 3D, pero podes lograr muy buena velocidad de 2D ya que lo que trabaja es la GPU.
Fijate si podes crear un proyecto en SourceForge o alguno de estos sitios, así otra gente puede colaborar. A mi me gustaría...
Por ahí si querés hacer algo colaborativo, podrías llamar a una lluvia de ideas e ir dándole un RoadMap al proyecto... Por ahí hay gente que conoce librerías que solucionarían algún problema fácilmente, o mas eficientemente.

De nuevo Felicitaciones por la iniciativa.

Que tal MarkU? me alegro de leerte de nuevo..

Como consejo te podría decir que trates de bajar el nivel de las partes
lo mas abajo posible, para poder sacar el máximo provecho del CPU y
porque no GPU...

Si, eso sería lo mejor, pero yo no se gran cosa de programación y estoy usando todos los recursos posibles de Qt, quizás muchas cosas se podrían hacer más eficientes programadas directamente a más bajo nivel, pero para eso hay que saber programar...

Por ahí implementar como bien decis, el GUI y la simulación por
separado, podría ser con hilos, usando pthreads por ejemplo y aprovechar
micros multicore.

Si, estoy usando threads, en este caso QThreads, como siempre aprobechando todas las facilidades de Qt, he conseguido separar la GUI de la "simulación" y basicamente funciona, aunque a veces el programa se queda colgado.

Entonces el thread "Simulador" lanza un timer Posix y en cada evento del timer se emite una señal para que todos los componentes se actualicen, los componentes tienen dos "partes", en realidad son dos objetos diferentes, uno es la parte gráfica y "vive" en el thread de la GUI y el otro es el que hace los cálculos eléctricos y vive en el thread "simulador"; esta última emite una señal conectada a la parte GUI informándole de los nuevos datos.

Con el tema de los threads hay un par de problemas, por ejemplo hay que asegurar el acceso "en serie" a los datos: si dos threads tratan de acceder a la vez al mismo dato hay problemas, Qt tiene soluciones para esto, pero se vé que todavía hay cosas que hago mal.

El timer parece funcionar bién a partir de 100 uS, tampoco es nada espectacular, pero mucho mejor que 10 mS, pero lo más importante es que mantiene la regularidad aunque la GUI esté muy cargada.

En el caso de acelerar la GUI podes ver algo de OpenGL, no es muy
complicado usarlo. Se que es para 3D, pero podes lograr muy buena
velocidad de 2D ya que lo que trabaja es la GPU.

También he probado esto y se nota la diferencia, el problema es que para esto es necesario tener instalado los drivers adecuados de la tarjeta gráfica; si se intenta usar opengl sin aceleración gráfica el programa dá errores, se queda bloqueado o simplemente no funciona.
Entonces para usar opengl habría que poner alguna rutina que detectara si el sistema dispone de opengl y entonces habilitar esta opción.
Qt dispone de facilidades para opengl y además dispone de otra opción que también acelera los gráficos por software sin tener opengl.

Fijate si podes crear un proyecto en SourceForge o alguno de estos
sitios, así otra gente puede colaborar. A mi me gustaría...

Al final he creado un proyecto en Sourceforge: https://sourceforge.net/projects/simutron/

He subido el código con el sistema de los threads, aunque casi no tiene componentes, solo una fuente de voltage y un buffer, cuando todo el tema de los threads esté funcionando bién ya se podrán añadir más componentes.

En las fuentes se incluye el archivo de proyecto para Qt Creator.

Es necesario tener instaladas las librerías de Qt 4.6 ( por defecto en Ubuntu 10.04 ).

Por ahí si querés hacer algo colaborativo, podrías llamar a una lluvia
de ideas e ir dándole un RoadMap al proyecto... Por ahí hay gente que
conoce librerías que solucionarían algún problema fácilmente, o mas
eficientemente.

Claro, esto me parecería estupendo, cualquier idea o solución, incluso las más locas o sin sentido pueden dar lugar a cosas interesantes.

Todavía se está a tiempo incluso de cambiar cosas básicas del funcionamiento del programa o lo que sea, y si hace falta replantearse todo desde 0 para conseguir un diseño más eficiente pues se hace.... así que cualquiera que se anime es bienvenido.


Saludos.

Muy bueno el programita, baje el código de SVN y estuve viendo algo, no entiendo mucho de QT, pero algo entendí.

Como ideas tiro lo siguiente:

1. Por lo que estuve leyendo, QT es bastante completo y las herramientas ayudan a programar rápidamente, pero como contra, le ven que el código no es muy legible y que no es muy eficiente en Velocidad.
   Algo similar decian de GTK, como desventaja de GTK es que es para C, aunque se puede usar GTKMM, pero tiene los mismos problemas que QT, en cuanto a que no es muy legible y que no es muy eficiente.
   Acá propongo tener el cuenta el Toolkit FLTK, como su nombre lo dice Fast Light Tool Kit, esta diseñado para ser rápido y liviano. Por lo que vi hay 2 versiones en desarrollo, la 1.3 y la 2, la diferencia entre ambas es que la 2 tiene una API distinta mas legible. También tiene un creador de aplicaciones que se llama FLUID, que permite crear de forma sencilla las ventanas.
   Estuve haciendo algunas pruebas sobre este framework hace 2 años, la verdad es que es muy simple de utilizar y es muy pequeño en tamaño. Estaba buscando algo liviano, que se vea bien y que sea facil para desarrollar una aplicación para un modulo de CONECTCORE-WI de DIGI, que tiene un micro ARM a 155Mhz, y este Toolkit andaba muy bien.
   
   
2. Lo que me parece que le quita potencia al programa es que los componentes estén hardcodeados, por ahí estaría bueno ver la forma de poder implementar archivos que sean los componentes o una base de datos donde se importen los componentes, algo como los txt de spice, o alguna librería. Esto nos permitiría agregar mas componentes fácilmente, hacer que personas no programadoras agreguen componentes, y poder escalar a futuro otras cosas ampliando estos archivos (se me ocurre algo loco de agregar soporte para PCB mas adelante y correr la simulación en la placa en 3D). Otra opción es que los componentes sean echos en código, pero sean cargados tipo plugins, cosa de poder tener algunos de los beneficios de tener "librerías" de componentes.
   Lo bueno de lo 1º es que es mucho mas fácil hacer un componente una ves planteado el archivo, seria posible seguir algún estándar tipo Spice3, y así poder usar los que proveen varios fabricantes. Lo malo es que habría un retardo en la interpretación del componente, por ahí hacer un "compilado" de todos los componentes cuando se agregan, o algo por el estilo, podría acelerar la aplicación.
   
   
3. Por ultimo, me parece muy importante hacer el un buen planteamento y diseño antes de comenzar en serio. Estaria bueno plantear los UML para hacer un desarrollo ordenado y prolijo. No conozco mucho de Ingenieria del Software, ya que estudio Ing. Electronica, y aprendemos a programar porque nos hace falta, no como los Ing en computacion o en Software que aprenden bien y ven todas las etapas del diseño.
   Donde trabajo hay 2 ing en Software y siempre comienzan planteando todos los UML y viendo bien todo antes de codificar, por ahí demoran un poco mas al comienzo, pero una vez todo ordenado obtienen muy buenos resultados.
   

Bueno, esas son mis pequeñas ideas, por lo pronto creo que podemos ir probando distintas cosas, por mi lado creo que voy a realizar/buscar algunos test de velocidad de los distintos frameworks y widgets de dibujo, después les planteo mis conclusiones.

Te comento mi opinión según los temas que planteas:

1- La verdad que no me había planteado a fondo el tema del framework a usar, pero Qt me ha gustado y me puse sin pensar demasiado.
La idea de usar un toolkit ligero en principio suena bién, la cuestión es que Qt, Gtk, etc son pesados porque implementan un montón de cosas que no tienen otros más sencillos; entonces todo depende del tipo de aplicación que se vaya a desarrollar, para aplicaciones sencillas en la que no se vayan a utilizar todos esos recursos quizás valga la pena usar Fltk u otro de ese estilo, pero en este caso la parte de dibujo tiene mucho peso y requiere de mucha interacción, no se trata solo de dibujar cosas en un widget, sino de manipular objetos gráficos que aparte del dibujo tienen otra serie de propiedades.

He estado mirando el Fltk y creo que implementar todo esto requeriría mucho trabajo, el código sería mucho más grande y complejo y además es muy posible que fuera incluso menos eficiente que la implementación de Qt.

Por ejemplo Qt tiene widgets específicos para gráficos y tiene clases para objetos de tipo gráfico, de manera que es muy sencillo manipular objetos gráficos, tanto las transformaciones gráficas: mover, rotar, etc, como manejo de eventos del ratón, como lista de objetos en la escena, colisión entre objetos y muchas cosas de este tipo que en Fltk habría que implementar desde 0.

Implementar todo esto sería un trabajo tremendo para alguien que sepa de programación.. yo ni me lo planteo.
También habría que ver si al final vale la pena lo que se gana en eficiencia.

Aunque quizás no es tan complicado como yo lo veo, pero habría que estudiarlo bién.


2- El tema de los componentes hardcodeados me lo había planteado alguna vez, había pensado varias cosas, más o menos en la linea que comentas; una era hacer librerías de componentes tipo plugin, de manera que no hubiera que recompilar todo para añadir nuevos elementos, aunque al fin y al cabo habría que escribirlos hardcodeados, aunque independientes de la aplicación; no sería demasiado complicado de implentar porque al fin y al cabo sería compilar mas o menos el mismo código pero por separado.
Otra era usar algún sistema "descriptivo", tipo un archivo xml que describiera los elementos y propiedades del componente y que se leyera en el momento de crear el objeto. Esto sería lo mejor en cuanto a usabilidad, sería facil crear nuevos componentes o editar los existentes; pero lo veo complicado de implementar, hay varias cosas que no sabría como solucionar si no es escribiendo código.

Pero este es un tema a estudiar; tampoco conozco los estándares, será cuestión de echar un ojo por ahí a ver como funciona la cosa.


3- Si, hacer un diseño previo sería lo bueno, pero como dices para eso hace falta gente que conozca el tema; no solo de ingeniera de software sino de simulación de circuitos.

Yo no sé de ninguna de las dos y al fin y al cabo esto me está sirviendo para aprender sobre el tema, ir probando cosas, etc.

De todas formas para hacer un diseño es imprescindible tener una idea clara de lo que se quiere, qué tiene que hacer y qué no tiene que hacer el programa; incluso esto no está bién definido y quizás sería el primer tema a discutir.

En principio me planteé hacer algo muy sencillo y si te has descargado el código habrás visto que son unos pocos archivos.


Pero creo que es importante explicar qué es lo que hace y lo que no hace este programa:

El método que uso para la simalación es también muy sencillo, de hecho el circuito no se calcula en ningún sitio, por ahora lo que hay es un sistema de signal/slot de manera que cada componente "informa" a los siguientes de los cambios que hay:
Las señales siempre parten de las fuentes de voltaje, se transmiten por los componentes y mueren en otras fuentes ( ground se considera una fuente de 0 volt ).
Las señales transmiten dos datos: uno de voltaje y otro de resistencia.
Cuando una fuente emite una señal con su voltaje y su impedancia, el componente siguiente la retransmite, manteniendo el voltaje y añadiendo su propia impedancia a la recibida, de esta forma cada componente sabe que hay una fuente de tantos voltios y hay tanta impedancia hasta esa fuente, esto pasa por los dos lados, de manera que el componente sabe su voltaje y resistencia de Thevenin.
Esto funciona bién y se vé claro cuando el circuito es una sola linea entre dos fuentes de voltaje, pero la cosa se complica cuando hay bifurcaciones, entonces hice una generalización: en un circuito con un solo nudo ( conexión entre 3 "cables" ) la resistencia de Thevenin de una de las ramas se calcula a partir de la resultante de las otras dos en paralelo y el voltaje de Thevenin se calcula a partir del voltaje en el nudo; para mi sorpresa esto parecía funcionar para solucionar redes, al menos en ciertos casos, ejemplos:
pantallazo
video

Pero no siempre, por ejemplo si en el circuito del pantallazo se le añade otra resistencia justo después de la fuente de voltaje entonces dá errores; no sé porqué falla... el caso es que ni siquiera sé porqué funciona en redes sencillas...

Pero aunque funcionara bién hay otro problema: el número de señales que recorre el circuito crece exponencialmente con el número de nudos, de manera que si a ese circuito se le añaden unos pocos nudos más interconectando varias mallas puede tardar hasta varios segundos en resolverse.

Entonces este programa no calcula circuitos, aunque puede resolver redes simples de resistencias y por tanto de cualquier componente que se pueda representar como una impedancia o como una fuente de voltaje.

Con circuitos de puertas lógicas no hay problema porque cada entrada o salida se considera como una fuente con una impedancia, de manera que cada paso entre puertas funciona como un circuito independiente.

Con el tema de microcontroladores la idea podría ser crear "dispositivos" para conectar directamente al micro de manera que no fuera necesario crear circuitos complejos, por ejemplo habría un bloque de 7-segmentos donde se podría elegir el número de dígitos que se quiera, del bloque saldrían 8 pines comunes y un pin por cada dígito para multiplexar, de manera que se consideraría que tiene los transistores y resistencias "dentro" y los pines se podrían conectar directamente al micro.
Sería como crear dispositivos con controlador incluido o algo así.

Entonces hay dos opciones: mantener este sistema simple y hacer un simulador simple para circuitos digitales con algunos dispositivos analógicos o hacer un simulador de verdad que pueda resolver cualquier circuito, para lo cual habría que implementar todo el tema de hacer los cálculos de las redes y todo eso.
Y en el segundo caso: copiar directamente de Ktechlab o algún otro, o desarrollar algo desde 0, o utilizar algún simulador que se pueda conectar de alguna manera a este programa al estilo de la interface con Gpsim ???....

Mi planteamiento en principio es el primero, a no ser que dé con alguna manera de resolver circuitos complejos con el sistema este.


A ver que ideas salen por ahí...

o utilizar algún simulador que se pueda conectar de alguna manera a este
programa al estilo de la interface con Gpsim ???....

Yo conozco para esto gnucap y ngspice, son dos clones de spice y tienen algunas interfaces graficas para poder montar y simular circuitos con ellos aunque todas son demasiado espartanas, si se pudiera integrar uno de estos motores para simulación en tiempo real, tendriamos una gran herramienta y además con la facilidad de poder integrar los componentes tipicos de spice.
Saludos

Yo conozco para esto gnucap y ngspice, son dos clones de spice y
tienen algunas interfaces graficas para poder montar y simular circuitos
con ellos aunque todas son demasiado espartanas, si se pudiera integrar
uno de estos motores para simulación en tiempo real, tendriamos una
gran herramienta y además con la facilidad de poder integrar los
componentes tipicos de spice.

El problema que le veo a esto es que los simuladores spice están más bién orientados a análisis precisos de circuitos y no a tiempo real; el tema al final está en la velocidad; haciendo algunas mediciones de tiempo la cosa anda por los milisegundos para un paso de simulación con un circuito sencillo, aunque las mediciones no son nada fiables y están hechas ejecutando ngspice como un proceso externo y un poco por la cuenta de la vieja; pero es que no veo que estos simuladores se puedan integrar como librerías compartidas, sino ejecutar por linea de comandos, entonces los procesos son asíncronos y todo es mucho más lento. Aunque quizás exista la forma de hacerlo; todavía no he probado con el Gnucap, pero tampoco le veo librerías compartidas, solo linea de comandos.

De todas formas esto me trae algunas ideas; por ejemplo una de las cosas es el tema de tiempo real: ¿es realmente necesario simulación en tiempo real?
Una de las ideas que tenía en mente es que el tiempo en la simulación se pudiera "escalar", osea ver la simulación en "cámara lenta" o paso a paso con un cierto salto en el tiempo; esto es casi imprescindible para ver como funcionan ciertos circuitos digitales.
Entonce en ciertos casos una simulación en "camara lenta" y con un indicador de tiempo también podría valer, incluso podría ser util.

Si haría falta tiempo real si se quiere conectar la simulación con un circuito o señal externa, por ejemplo un puerto serie o paralelo.

Otra posiblidad es que el programa pudiera generar netlist para simular en otros programas o que pudiera lanzarlos directamente.

Nosé que pensarán ustedes de todo esto.. hay varias posiblidades.


También he estado mirando el tema de hacer las descripciones de componentes en archivos y no directamente en el código, Oregano por ejemplo lo hace así y creo que puede usar componentes de spice; se podría usar el mismo formato para que fuera compatible con estos programas.


Saludos.

Oregano es uno de esos front-ends de ngspice o gnucap que me referia

Si, el oregano creo que puede usar tanto ngspice como gnucap.

Pero el problema está en la velocidad, por un lado porque no veo otra forma de usarlos que no sea asíncrona, entonces estamos a expensas de cuando el sistema considera que le toca ejecutar el comando, pero aún así el tiempo de cálculo es bastante largo, he estado haciendo unas pruebas con el gnucap y lo mismo, tarda varios milisegundos en ejecutar 100 pasos, dependiendo del circuito puede tardar decenas de mS, aunque seguramente los retardos del sistema tengan mucho que ver en esto.

En principio se podría usar a tiempo real pero con pasos muy largos, por ejemplo que ejecutara un paso por milisegundo o incluso cada 10 mS, y si se quiere más resolución pues verlo mas lento, pero esto no serviría para circuitos con microcontroladores donde haría falta al menos una resolución de microsegundo...

La única solución que le veo a usar uno de estos es hacer la simulación también asíncrona: mandar al spice que resuelva el circuito y cuando termine llamar a Gpsim que resuelva el pic y tener un indicador del tiempo de simulación, en circuitos sencillos irá más rápido y otros irá más lento, aunque nunca en tiempo real.

Esto es solo una idea que nose si es posible, pero y porque no usar las librerias de gnucap o ngspice del codigo del propio programa, para utilizarlas directamente, es decir compilarlas en el proyecto, seguro que así ganabas velocidad, aunque claro, se pierde la modularidad típica de los programas unix y tan util en muchos casos.

Pues sí... sería una posible solución.. y esto me ha llevado a otra pregunta: ¿sería posible compilar gnucap como librería compartida?

Y resulta que sí y además ya hubo un tipo que le dió por ahí:
http://old.nabble.com/Python-plugin-for-Gnucap-td23499158.html
El lo hizo con otras intenciones, pero al fin y al cabo compila gnucap como librería compartida, así que sus funciones se pueden usar directamente desde este simulador (creo...).

Código fuente:
http://github.com/henjo/gnucap

Me lo he bajado y me ha compilado sin problema y ya tengo instalado gnucap como librería compartida, ahora toca ver como usarla desde el simulador.

Por si alguien quiere compilarla hay que seguir estos pasos (sudo en Debians):

./autogen.sh
./configure
make
sudo make install

Por defecto instala todo en /usr/local , en Ubuntu dá un problema de que no encuentra la librería, entonces en Ubuntu mejor ejecutar el configure con:

./configure -prefix=/usr

Así no dá ningún problema.


En cuanto haga algunas pruebas (a ver si doy con la manera de utilizar esto) comento los resultados.



Saludos.

Aunque pensándolo bien... usar gnucap como librería compartida implica que la librería vaya con el programa, porque por ahora no se distribuye de esta manera (lo cual estaría muy bién), sin embargo usar directamente el código de gnucap tiene la ventaja de que solo se utilizaría una parte de las funciones de gnucap y creo que una pequeña parte porque en principio solo haría falta usar el análisis en transitorio y quizás ningun otro comando porque igual se podrían usar punteros a las estructuras de datos que use gnucap para guardar los resultados.

Osea que tu idea (litox9) quizás sea la más conveniente... no?

No se si mi idea es la mas conveniente o que, solo era una idea mas, aunque si puedes llevarla a cabo puede estar muy bien.
Tengo ganas de ver avances o algo.
Saludos

Hola de nuevo... ultimamente tengo poca oportunidad de conectarme, así que resumo:

Lo de usar spice o similar por ahora lo tengo aparcado.

Ahora los micros se pueden añadir a un archivo xml en vez de estar "harcodeados"

El tiempo de simulación se controla con una "escala" y el simulador calcula el timer y nº de ticks necesarios.

He añadido simulacion para AVR:
Video1


Aquí se ve el tema de la escala de tiempo, escala 1 es tiempo real, cuado se aunmenta la escala lo vemos en camara lenta, si se aunmenta la escala lo suficiente se ve el comportamiento a nivel de puertas.

El programa solo pone la salida portb3 igual a potrc0 que es entrada:
Video2


Saludos.

Cada dia pinta mejor, lo unico que te recomiendo es que en vez de el desplegable para elegir entre simulación continua y paso a paso pongas un boton de abanzar un paso además del boton de play y stop que ya tienes, creo que será mas sencillo de esa forma y no se si será posible pero estaría bien otro boton para retroceder un paso, que siempre es útil.
Saludos

lo unico que te recomiendo es que en vez de el desplegable para elegir entre simulación continua y paso a paso pongas un boton de abanzar un paso además del boton de play y stop que ya tienes,

Pues si... tienes toda la razón sería más facil de usar.

y no se si será posible pero estaría bien otro boton para retroceder un paso, que siempre es útil.

Esto ya sería más dificil, no lo veo nada claro; para los micros creo que sí se podría, peri si hablamos de la simulación en general ya es otro tema.

Pero queda apuntado a ver si surge alguna solución.


Saludos.

Hola de nuevo.

Como hacía tiempo que no comentaba nada sobre el programita este voy a poner un vidiecito corto.
He cambiado algunas cosillas, pero lo más visible es el tema de conectores, que creo que lo tengo casi listo; ahora creo que se puede hacer casi cualquier cosa para dejar el circuito como uno quiera, modificar la forma del conector, mover componentes o grupos de componentes junto con partes de conectores, etc.

También lo de poder elegir si las etiquetas de los componentes se ven o no se ven.
Los iconos de la lista de componentes los estoy cambiando por unos que se vean mejor.

Las puntas de prueba ahora no hace falta conectarlas, sólo con arrimarlas a un conector te marca el voltaje y estado lógico.

Hay leds (simula pwm también), condensadores (todavia experimental) y diodos.

Tambien algun componente lógico más y display 7seg, pero todo eso lo estoy cambiando así que no salen, también puse un componente "neurona" para experimentar con redes neuronales, pero también lo tengo que cambiar, aunque sólo era un experimento para jugar un poco, pero hacía sus cosillas interesantes.

Video

Saludos.

Muy bueno pikitin!!!, ya tiene bastante mas forma, felicitaciones!