SimutronD, solo circuitos digitales y micros

Hola a todos, vuelvo con el tema del simulador este.

Como la parte analógica está complicada he decidido quedarme en un simulador de circuitos digitales por ahora, he hecho una versión sólo digital que tienen la ventaja de que es más simple y más rápida.

Hay una serie de componentes básicos que se compilan con la aplicación, pero se pueden añadir nuevos componentes como plugins sin tener que compilar de nuevo el programa.

Hay una plantilla para crear nuevos componentes, es bastante facil para crear componentes combinacionales sencillos, aunque también se pueden hacer secuenciales, sólo hay que definir nombres del plugin y componente, tamaño, pines de entrada y salida y funciones lógicas de las salidas, en un rato se puede hacer un flip flop un sumador o cosas de ese estilo sin apenas escribir código. Hay un ejemplo hecho de un sumador binario completo de 1 bit. Se compila en 30 segs. y al arrancar de nuevo el programa el componente ya está ahí.

La parte de micros todavía no la he adaptado, pero he subido el programa básico a sourceforge:
Enlace para descarga.

He subido también el ejecutable compilado en UBUNTU 10.4, está en la carpeta trunk/bin; si no funciona o quereis compilar el programa, sólo entrar en la carpeta trunk/src y hacer "make", no hay que instalar, el ejecutable se copia a bin.

Para tener funcionando el sumador de ejemplo hay que compilar el plugin si o si ya que no puedo subir librerías, sólo hay que entrar en la carpeta trunk/plugins/full_adder y ejecutar ./compile, las librerías se copian a trunk/lib.

Para crear nuevos componentes hay que hacer una copia de la carpeta trunk/plugins/logic_comb_template, ponerle el nombre que queramos (y dejarla en trunk/plugins) y modificar estos archivos :

- definitions.h y defpro : sólo son nombres del plugin y del componente. Cuidado!! el nombre del plugin tiene que ser exactamente el mismo en los dos archivos.

- paint : se puede dejar tal y como está, sólo  modificar para cambiar el aspecto, por defecto un cuadrado con los nombres de los pins.

- construct : definición de los pines y tamaño del componente. El ejemplo del sumador es así:

width  = 4; // 4 casillas de ancho x 6 casillas de alto
height = 6;

pinList
// Inputs:
<< "IL02A"  // Este pin es Input, esta a la izquierda Left, posición 02, nombre "A"
<< "IL04B"
<< "IR01 Ci"

// Outputs:
<< "OR03  S"
<< "OR05Co"
;

- savestate : definición de las funciones de salida. En el ejemplo del sumador es esto:

       bool X  = m_inPin[0]->state();
       bool Y  = m_inPin[1]->state();
       bool Ci = m_inPin[2]->state();

       m_outValue[0] =  (X ^ Y) ^ Ci;      // Suma
       
       m_outValue[1] = (X & Ci) | (Y & Ci) | (X & Y);  // Carry out

El aspecto que tiene el sumador creado se puede ver en este circuito sumador de 3 bits:

https://www.youtube.com/watch?v=AqlNjB1tnFc

Si alguien le da por probarlo y quiere más detalles o no tiene claro cómo crear componentes pues no tiene más que preguntar.

También se pueden hacer secuenciales, memorias o lo que haga falta.


Saludos.

Muy interesante, pero tengo una duda. ¿Con que "lenguaje" se definen los componentes? Porque existen lenguajes de descripción de hardware, Verilog y VHDL principalmente, que podrian utilizarse para este caso añadiendo así una forma estándar de crear los componentes y pudiendo aceder a muchisimos componentes ya escritos. Para esto se podria utilizar un interprete de VHDL por ejemplo para crear los plugins (hay uno con licencia GPL pero no lo he probado).

Los componentes usan Qt (c++), simplemente es crear librerías dinámicas en vez de compilarlos con la aplicación y cargarlas al arrancar el programa.

Y luego hice el sistema ese de editar algunos archivos para no tener que estar escribiendo clases enteras cada vez que se crea un componente. Esos archivos simplemente estan incluidos en el código de la plantilla, ahorra mucho trabajo, pero al fin y al cabo es editar un programa en C++ y compilarlo como librería compartida.

De VHDL y demás no tengo idea, sé que son lenguajes de descripción de hardware, pero.. ¿que hace un interprete de VHDL?

Lo único que veo sería hacer un "traductor" que leyera vhdl y creara un componente para este simulador, pero.. ¿que pasaría con la posición de los pines y todo el tema gráfico?

Estaría interesante, pero no tengo ni idea del tema.. alguna orientación??

Vale, si están escritos en C++ e incrustados directamente en el programa, tal y como tu dices la opción viable sería hacer un traductor de VHDL a C++.
Lo del interprete (no se si se llama interprete) en realidad es un programa de simulación digital que interpreta directamente en VHDL, hace lo mismo que tu programa pero con VHDL y de una forma menos "física", la interfaz sería esquemática.
Toda la capa física que no se encuentre en VHDL para ese traductor se podría añadir como comentarios en VLDH que procese el traductor.

Lo del VHDL está interesante, además sería buena cosa aprenderlo... queda apuntado en la lista de cosas por hacer, quizás algún día me ponga a ello.

Aunque quizás haya algún traductor a c++... si ya existe alguno habría que verlo y sería más viable.

EDITO:
Si que los hay: acabo de ver este por ejemplo : freehdl-v2cc
y en los repos de ubuntu está ghdl .. "que usa tecnología GCC".. que será esto??

Eso iba a decir yo, que he encontrado esta página , y tambien sería útil la versión contraria c a vhdl, aqui hay un proyecto muy aclarador.
ghdl supongo que será una especie de c para descripción de hardware.

Le voy a echar un ojo a los enlaces, por lo pronto freehdl-v2cc está en los repos de ubuntu y lo acabo de probar, genera código C++ a partir de VHDL, pero parece orientado a su simulador.. a ver si puede ser util.

VHDL
es decir que se escribe los circuitos electrónicas en un lenguaje informática que parece al C o pascal pero es muy diferente porque los bloques funcionan en paralelo, es decir no se trata como un PIC o microcontrolador de tratar paso a paso, es como circuitos lógicos.
Un ejemplo : http://es.wikipedia.org/wiki/VHDL
Este ejemplo simula un multiplexor de dos entradas. Es un ejemplo sencillo que muestra como describir un elemento a partir de su funcionamiento.

entity MUX2a1 is
port( a: in std_logic;
b: in std_logic;
sel: in std_logic;
z: out std_logic);
end entity

architecture dataflow of MUX2a1 is
begin
z <= a when sel='0' else b;
end dataflow;

entity es el componente (entradas, salidas) y architecture lo que hay dentro.

Se puede usar GHDL y GTKWAVE (software libre GNU GPL)
Hay un sitio muy interesante en español : http://fpgalibre.sourceforge.net/
También http://www.iearobotics.com/personal/juan/publicaciones/art6/

si le interesa tengo ejemplos sencillos en VHDL con GHDL y GTKWAVE.

Un saludo,
Per

Hola Per, gracias por las aclaraciones, ya voy entendiendo un poco cómo va esto.

Habrá que ir aprendiendo poco a poco, pero lo veo muy complicado para un simulador sencillito como este.

Me gustaría probarlo, mi problema es que actualmente no tengo linux, mi grafica está estropeada y por alguna razón linux no la puede usar mientras que windows sí. He intentado compilarlo en windows abriendo el proyecto con QtCreator y compilando, pero me salen unos cuantos warnings y un error.
Warnings:

Código:

C:\[...]\simutronqt4-build-desktop\Makefile.Debug:171: warning: overriding commands for target `build/*.o'

Código:

C:\[..]\simutronqt4-build-desktop\Makefile.Debug:168: warning: ignoring old commands for target `build/*.o'

Error:

Código:

:-1: error: No rule to make target `src/*.cpp', needed by `build/*.o'.  Stop.

¿Alguna idea de como lo puedo compilar?
Saludos

Puedes probar con una terminal en la carpeta descomprimida

$ qmake

$ make

El qmake te genera el makefile, que parece que es lo que falla... por ahora .. jejej.
El ejecutable lo genera en la carpeta bin.

Pero nunca lo he probado en windos, ya me contarás. Por cierto.. que windos usas?

Uso Windows XP.
Gracias Pikitin me has dado una idea de por donde empezar porque por desgracia Windows no es tan sencillo como linux, los pasos que he seguido son estos.
-Abrir una terminal Qt 4.7.3 Desktop(MinGW)
-Ir a la carpeta trunk
$ qmake
$ mingw32-make

Y en teoria así te lo compila. ¿En la practica? No lo he podido compilar porque el sistema utilizado para cargar las librerias dinamicas no funciona en Windows, solo en sistemas unix, estoy investigando como hacer lo mismo en windows.
La solución está aquí, a ver si lo puedo aplicar a este caso.

Claro... el dlopen...

De todas formas puedes probar a compilarlo sin los plugins.
En el archivo src/itemlibrary.cpp, lineas 100 a 142 tienes el código que carga las librerías, si comentas esa parte debería funcionarte sin plugins.. por si quieres probar.

Si quieres echarle un ojo y adaptarlo a win, alguna info:
Fíjate que primero uso dlopen ( lin 114 ) para cargar la librería que contiene al componente en sí , y luego con QPluginLoader se carga el "librayItem" que basicamente contiene un puntero al constructor del componente y alguna info y es lo que vá en el selector de componentes a la izda.

Osea cada componente tiene 2 librerías:
libnombreplugin.so : se carga con QPluginLoader, contiene un librayItem que va en la lista.
libnombre.so.1: se carga con dlopen, contiene el código del componente.

Cuando seleccionas el librayItem de la lista de componentes y lo sueltas en el circuito, esta llama al constructor del componente que está en libnombre.so.1

La parte del QPluinloader debería funcionar tambien en win... supongo.



EDITO:
Ahora que lo pienso hay varias cosas, una es compilar las libs y otra la carga de las dll en el programa.

Las libs se compilan independientemente en la carpeta plugins/nombre, lo mismo: qmake, make ( o equivalente ) y quedan en lib/libnombre.so

Realmente no sabía como lo tenías montado, he visto el error y me he dedicado a comentar todo lo relacionado con dlopen, no sabía para que lo usabas, así quitando 4 ó 5 lineas me funciona. ¿No se pueden cargar las dos librerias con QPluginLoader? De esta forma si funcinaría en Windows.
Bueno ahora me queda aprender como compilar los plugins en Windows

Las librerías compartidas segun la documentación de QT deberían compilar en win, ya que incluye un macro que selecciona el código según el sistema.

los plugins también porque usan QPluginloader y se compilan como plugin de Qt.

Ten en cuenta que cada componente tiene una dll y un plugin Qt. El problema creo que podría estar en la carga de la dll, que yo uso dlopen que es Unix. Mírate esto:
http://en.wikipedia.org/wiki/Dynamic_loading

Cuando consigas compilar las librerías prueba a cambiar "dlopen" por "LoadLibrary" (ajustando la sintaxis), por ejempo algo así:

void* libComp = dlopen( libName.toAscii(), RTLD_LAZY ); // Unix

HMODULE libComp = LoadLibrary( libName.toAscii() ); //Windos

También creo que habría que cambiar los .so por .dll

Losuyo sería un #ifdef windos o algo del estilo
...

¿No se pueden cargar las dos librerias con QPluginLoader?

Pues... es lioso el tema, de todas formas hacen falta dos "cosas" el "libraryItem" y el componente en sí, y no consegía meter dos clases en un sólo plugin.
Además habría que hacer una interface nueva (clase abstracta pura) para cada componente y esto complica mucho la cosa, no se podría usar este "sistema facil".

De esta forma sólo se hace una interface para el libraryItem que es común para todos los componentes, y la librería compartida sólo hay que cargarla, no hay que tocarla más, ya que el libraryItem tiene un puntero a un método estático que llama al constructor del componente y nos dá una instancia de este, así que no hay que hacer lo de: extern "C".

Bueno pues vayamos por partes. Primero el plugin. He mirado un poco el código y lo único que veo para modificar es en el template_plugin.pro la linea de LIBS, que pasaría a ser así.

Código:

win32:CONFIG(release, debug|release): LIBS  += $${DESTDIR}/lib$${PLUGIN_NAME}.dll
else:unix: LIBS  += $${DESTDIR}/lib$${PLUGIN_NAME}.so

Porque supongo que las librerias que crea cuando compilas en windows son dll.
Intento compilar y me sale lo siguiente:

Código:

C:\[...]\trunk\plugins\full_adder\plugin\template_plugin.cpp:33: error: undefined reference to `_imp___ZN9FullAdder9constructEP7QObject7QStringS2_'
C:\[...]\trunk\plugins\full_adder\plugin\template_plugin.cpp:33: error: undefined reference to `LibraryItem::LibraryItem(QString const&, QString const&, QString const&, QString, Component* (*)(QObject*, QString, QString))'
:-1: error: collect2: ld returned 1 exit status

No tengo ni idea de lo que pasa :S

Upss... perdona, se me había olvidado una cosa: primero hay que compilar la librería compartida que está en la carpeta "comp_lib", luego el plugin.

Lo mejor quizás es que edites el script: plugins/FullAdder/compile que compila por orden o crees el tuyo adaptado para windows. O simplemente compila primero comp_lib y luego plugin

El tema es que el plugin nesesita la dll ya compilada, porque tiene una referencia al método estático "construct" del componente, que está en la dll.

La linea: LIBS += $${DESTDIR}/lib$${PLUGIN_NAME}.so

Hace referencia a esa dll, que como no se ha creado previamente te da el error:
error: undefined reference to `_imp___ZN9FullAdder9constructEP7QObject7QStringS2_'

Que es el método "construct" del componente "FullAdder" y no existe.

Pues justamente había empezado por el plugin porque la libreria no se por donde cojerla, tengo tantos errores en el template.cpp...
Pero posiblemente todos estén relacionados con este primero:

Código:

C:\[...]\trunk\plugins\full_adder\comp_lib\template.cpp:30: error: undefined reference to `LogicCombinational::LogicCombinational(QObject*, QString, QString)'

Estoy tan perdido como el compilador, ¿de donde sale LogicCombinational?
Se agradecerían comentarios en el código.
Un Saludo

Pues a ver.... otra cosa más que no recordaba..

habías compilado ya el simulador.. no? Al menos eso entendí, que comentando lo del dlopen te compilaba.

Si no prueba a compilar primero el simulador, pasa lo mismo que con el plugin, para compilar la dll tiene que estar compilado el simulador.

Si lo habías compilado entonces se lia la cosa...
El tema está en que al compilar el simulador se hace con un flag para que exporte sus funciones y así estén disponibles "desde fuera", en el archivo simutronqt4.pro, la linea:

# Exporta símbolos de la propia App
QMAKE_LFLAGS_RELEASE += -Wl,-export-dynamic

No sé si esto también funciona en windos..



LogicCombinational sale de que estos componentes "son" LogicCombinational:
template.h:
class MYSHAREDLIB_EXPORT CompName : public LogicCombinational

y lo primero que se hace al llamar al constructor del componente es llamar al constructor del "padre":
template.cpp:
CompName::CompName( QObject* parent, QString type, QString id )
: LogicCombinational( parent, type, id )

La verdad es que casi no hay comentarios, es una de las cosas que tengo que hacer.

Pues he conseguido un windos y he hecho algunas pruebas y parece que si se puede, al menos compilar las dll y plugins.

Lo primero es que al abrir los archivos .pro nosé porqué me pone como raiz del proyecto una carpeta que se inventa... hay que cambiarlo en la pestaña "Projects" en Build Directory.

El simulador si el tema del dlopen también me compila sin problemas y funciona!!..

Ahora viene el tema del plugin... hay que cambiar un par de cosas:

en plugins/commoncomp.pro hay que añadir esta linea:

LIBS += ../../../build/*.o

y cambiar estas 2 :

OBJECTS_DIR = ../../../build/buildplugin
MOC_DIR = ../../../build/buildplugin

Esto soluciona el último problema que tenías de "undefined reference to LogicCombinational::...etc" y ahora debería compilar la dll, osea lo que está en la carpeta comp_lib.

Ahora hay algunas diferencias en los nombres de la dll generada, en linux genera libfulladder.so y en win fulladder.dll , así que para compilar el plugin (carpeta plugin) hay que cambiar en el archivo template_plugin.pro esta linea (quitarle el "lib" y cambiar a .dll):

LIBS += $${DESTDIR}/lib$${PLUGIN_NAME}.so // linux

LIBS += $${DESTDIR}/$${PLUGIN_NAME}.dll // windos

Con esto se puede compilar el plugin que también lo genera sin el "lib" al principio: fulladderplugin.dll en vez de libfulladderplugin.so

Y creo que no se me olvida nada...

La diferencia es que hacen falta los archivos objeto incluidos como librerías, en linux parece que con las cabeceras le basta.

.. y ahora "solo" falta conseguir que se carguen los plugins en el programa principal...

He hecho esos cambios y ahora cuando compilo la libreria me sale error de definición multiple. Creo que ya he cambiado tantas cosas que la he liado Igual empezando desde el principio...

Es que si tienes el template.o de antes en la carpeta build te va a dar ese error, por eso el cambio este:
OBJECTS_DIR = ../../../build/buildplugin
MOC_DIR = ../../../build/buildplugin

Para que dll y plugin compilen en otra carpeta y no se encuentren con los archivos que ellos mismos ha generado, ya que precisamente incluimos los .o de esa carpeta:
LIBS += ../../../build/*.o

Si has hecho los cambios entonces el "clean" no te ha borrado esos archivos, si empiezas en limpio, descompriomiendo de nuevo las fuentes ok, pero si usas las mismas de antes mira que la carpeta build esté vacía, sino borra todo lo que haya.

De todas formas es posible que se me haya pasado algo, voy a comprobarlo.

Vale, ya tengo la libreria compilada, gracias. Pero ahora me da problemas el plugin.
C:\[...]\SimutronD\trunk\plugins\full_adder\plugin\template_plugin.cpp:33: error: undefined reference to `_imp___ZN9FullAdder9constructEP7QObject7QStringS2_'

Ese es el error que me da y justo debajo de la linea donde me da error está subrayado en color verde como si hubiera algo mal, esto:
Q_EXPORT_PLUGIN2(plugnameplugin, CompNamePlugin );
¿No debería estar esa función dentro de alguna? Y entiendo que plugnameplugin es el nombre del plugin pero ¿donde está esta variable?

Estoy haciendolo de tal forma que se pueda compilar tanto en linux como en windows mediante las etiquetas del preprocesador, así tendremos una unica versión.

También estoy con lo del LoadLibrary, pero no se porqué cuando hago libName.toAscii(), me da error, me dice que la conversión es ambigua.

Este error creo que es porque no encuentra la dll:
error: undefined reference to `_imp___ZN9FullAdder9constructEP7QObject7QStringS2_'

Mira en la carpeta trunk/lib a ver si tienes fulladder.dll
y comprueba que en template_plugin.pro hayas cambiado esta linea;

LIBS += $${DESTDIR}/$${PLUGIN_NAME}.dll

fijate que antes era así:

LIBS += $${DESTDIR}/lib$${PLUGIN_NAME}.so

Si tienes algo distinto piensa que $${PLUGIN_NAME} se sustituye por "fulladder", osea que si pusieras:

LIBS += $${DESTDIR}/blablabla$${PLUGIN_NAME}talquecual.dll

Te va a buscar la librería: blablablafulladdertalquecual.dll

_____________

Q_EXPORT_PLUGIN2(plugnameplugin, CompNamePlugin );

Esto es una macro de Qt y hay que ponerla al final según dice la documentación, pero no veo la relacion...


_____________

Para el LoadLibrary prueba con TEXT( ".." ) , quizás por ahora mejor usar la ruta absoluta para evitar confusiones, luego ya se cambiará:

LoadLibrary( TEXT( "C:\...\..\..\trunk\lib\fulladder.dll" ) )

Pues no hay manera...

He probado a cargar las librerías con Loadlibrary y funciona, aparece el fulladder en la lista de componentes, pero al añadir uno al circuito el programa casca.

El caso es que tanto la dll como el plugin parece que cargan bien y funcionan, si pongo un
qDebug() << " Hola desde la dll ";
en el método construct de la dll, aparece el mensaje en la consola del Qtcreator cuando añado un fulladder al circuito, pero al llamar a new CompName() casca...

Ya no se que más hacer... a ver si a ti se te ocurre algo.



EDITO:

Pues el caso es que si hago la dll con una clase que no derive de ninguna del programa principal todo funciona bién, se llama al constructor y se crea una instancia.

Osea que estamos como al principio, el tema de incluir los .o no sirve para nada:
LIBS += ../../../build/*.o



EDITO2:

Pues parece que esto no funciona en windos ni de coña:
http://developer.qt.nokia.com/forums/viewthread/4219
Por lo visto la única forma sería compilar las clases base como dlls, pero esto es casi compilar el programa entero como dll ( o igual estoy exagerando un poco ).