Conectando Ktechlab con un circuito real.

Hace un tiempo que le estaba dando vueltas al tema de las simulaciones y todo eso, en parte por eso le puse al plugin de gedit la parte de comunicación serie, porque así puedo ejecutar el código en un pic real, ver los registros funcionando y modificarlos mientras se ejecuta el programa en un pic real.

Pues resulta que el Ktechlab también se puede conectar con un pic real (o cualquier otro circuito), de manera que se podría ejecutar el código en el pic real y conectarlo a un circuito virtual de Ktechlab.

El tema está en los puertos serie y paralelo, que se encuentran en la lista de componentes, en la sección "conexiones".
Se trata de controlar los pines de los puertos directamente, de la misma manera que lo hace un software que controla un programador directo como piklab o el mismo ktechlab.

Entonces solo hay que conectar el circuito que estemos simulando al puerto que hemos sacado de "conexiones" y conectar un pic o lo que sea al puerto real del PC.

Por ahora he hecho algunas pruebas con el puerto serie y funciona bién, pero lo ideal sería el puerto paralelo ya que tiene muchos más pines disponibles... pero resulta que con el puerto paralelo no me funciona.
Tengo que probar con otras versiones de ktechlab a ver si resulelvo el tema.

Porque sería estupendo poder tener el puerto paralelo conectando un circuito virtual a los puertos del pic y el puerto serie para visualizar y modificar registros mientras se ejecuta el programa...

O sea simular solo el circuito externo al pic, pero el programa corriendo en un pic real.

Seguramente hay muchas limitaciones, pienso sobre todo en la velocidad.... pero creo que se podrían hacer cosas interesantes.


Saludos.

Cuando empecé a utilizar el puerto serie en los pics, hacia simulaciones con el proteus donde tambien podias poner el puerto serie y teniamos comunicacion con el exterior, luego conectabamos ese puerto serie con el otro que tenia el PC y podiamos recivir la señal de la simulación. No sabia que se podia hacer esto con ktechlab pero es muy util.

Si.. creo que es muy util.

Por cierto ya me están funcionando las entradas por el puerto paralelo.
Lo bueno de este puerto es que se pueden conectar dos puertos completros del pic al circuito simulado.
Tal y como está ahora los registros data(8 pines) y control(4 pines) funcionan como salidas y el registro status(5 pines) funciona como entrada, en total se pueden conectar 17 pines del pic a un circuito de ktechlab... bueno no tiene porqué ser un pic,... se podría conectar cualquier circuito real con otro virtual... eso si... solo en digital.

También se podría hacer que las lineas data funcionen como entradas, pero esto está por hacer.

podria hacerse comunicacion usb con ktchlab???

Que tal manuelzazu?

podria hacerse comunicacion usb con ktchlab???

Pues por ahora no hay nada con USB en Ktechlab.

Aprobecho que estoy aquí para divagar un poco:

De todas formas esta diea de conectar ktechlab con un circuito no se refiere a usar p.serie o paralelo en modo comunicaciones (aunque se podría hacer), simplemente es usar las lineas como "cables" para conectar a un circuito externo (tipico ejemplo: manejar leds por p.paralelo).

Por ejemplo lo he usado para no simular PIC, sino correr el programa en un PIC real y conectarlo a un circuito simulado... me ahorro hacer el circuito, pero puedo probar el programa funcionando en un pic real, que siempre es mas fiable que simularlo; la simulación del circuito normalmente no es tan crítica como la del PIC.

Aunque también se podría hacer al revés o con cualquier otra cosa, por ejemplo un circuito controlador de motor por pwm simulado en Ktechlab lo puedes conectar a un motor real (a través de lo elementos de potencia necesarios).
O una serie de sensores o cualquier entrada de información en el mundo real lo puedes conectar a un circuito que procese todo eso (simulado en Ktechlab) y luego volvelo a conectar a una serie de actuadores otra vez en el mundo real, osea.. simular un circuito de domótica, pero conectado a actuadores y sensores reales.

Cuando digo conectar no me refiero a comunicación rs232 o lo que sea, simplemente conectar un cable entre el circuito simulado y el exterior (real). Por ejemplo con un interruptor real encender un led simulado en Ktechlab... o al revés... y quien dice un led dice un acelerador de partículas..

Y funciona, aunque con algunas limitaciones, principalmente el problema son los tiempos. Y este problema viene del tiempo de latencia (no sé si es el termino correcto) del Kernel Linux, que normalmente es bastante alto (del orden de varios mS) y que es la causa de que la versión original de Ktechlab no funcione en tiempo real en la mayoría de los Linux.

En mi PC, y dependiendo de la carga de CPU, el tiempo que funciona bién son 10 mS, osea cualquier señal mandada al exterior que vaya más rápido que eso no vá a estar bién sincronizada, y cualquier señal del exterior más rápida puede incluso no ser recibida, simplemente se pierde; para estar seguro de que una señal es recibida tiene que durar + de 10 ms.

Como es una cuestion manejada por el Kernel, no hay manera sencilla de solucionar esto (que yo sepa), peero... ahí está el Ubuntu Studio, que usa un Kernel modificado con muy bajos tiempos de latencia (tipicamente <50 uS); con ese Kernel debería ser posible manejar señales de al menos 50 uS de largo.. tampoco es la panacéa, pero ya cae dentro de lo utilizable.

Tengo que hacer algunas pruebas a ver que pasa...


Saludos.

Además de usar un kernel realtime se pueden reorganizar las prioridades del kernel para darle la maxima prioridad a la interrupción del puerto paralelo o serie. Doy por hecho que sabies lo que es una interrupción Os dejo un enlace a la mejor explicación que he visto nunca sobre el kernel-rt, ventajas e inconvenientes y como modificar las prioridades. Pero aclaro una cosa, en este foro sus prioridades son para la targeta de audio pues es un foro de música para nosotros lo interesante serian los puertos serie y paralelo.

http://www.hispasonic.com/comunidad/introduccion-kernel-t276319.html#p2337963
Tengo que mirar este tema un poco mas a ver si saco tiempo.

Que tal litox9?, Gracias por el enlace, quiero enterarme un poco mejor de esto, a ver cómo trabaja realmente el tema.

De todas formas, en el caso de Ktechlab no sólo interesaría las prioridades de los puertos, porque el simulador usa un timer que depende del tiempo de latencia del kernel; osea, aunque ktechlab pida un timer de 1 ms, el kernel no le devuelve el control hasta que se hayan terminado todas las operaciones por orden de prioridad... esto en el caso de mi PC, (2x3.4 GHz) no pasa antes de 5 ms y muchas veces tarda más de 10 ms (todo esto sin mucha carga de CPU).

Entonces el simulador (en ktl-gcb) usa un timer de 10ms, y realiza 10000 pasos de la simulación todos seguidos y espera al timer de nuevo; estos 10000 pasos, según lo compleja que sea la simulación pueden tardar 1 uS, 1 ms o 10 ms.. o lo que sea, pero no están uniformemente distribuidos en el tiempo. Osea, el simulador ejecuta 10E6 pasos por segundo, pero no los ejecuta cada 1 uS... puede que ejecute 10E4 pasos en 10 uS y luego esté más de 9 mS sin hacer nada. Entonces, si en esos 9 mS pasa algo, el simulador ni se entera.

Para los componentes internos a la simulación esto dá igual porque están sincronizados entre ellos (cuando se ejecuta un paso se actualizan todos los componentes) pero si la simulación tiene que estar sincronizada con una señal exterior entonces la cosa cambia.

Lo ideal sería que la simulación ejecutara un paso cada 1 uS, esto por ahora parece complicado, pero si se ejecutara cada 50 uS sería mucho mejor que cada 10 ms.

Según lo que yo he leido, el Kernel-rt cambia las prioridades, pero no solo del hardware, ya que el software que maneja las tarjetas también tiene que ser capaz de mantener altas velocidades de "muestreo". Entonces el tiempo de latencia, osea, el tiempo que cualquier tarea (hasta la de menor prioridad) tarda en recuperar el control de la CPU es mucho menor. Osea cualquier tarea toma el control más veces, pero por menos tiempos tiempo cada vez. Pero ya te digo que apenas tengo idea de esto... tengo que leer más.


Saludos.

Por lo visto se puede aplicar un parche a cualquier Kernel, compilar y yá tenemos un Kernel-rt, no hace falta instalar Ubuntu-Studio: http://www.net-mdq.com.ar/blog/2009/10/como-compilar-nuestro-propio-kernel-rt-en-deb/

Kernel-rt Wiki: http://rt.wiki.kernel.org/index.php/Frequently_Asked_Questions

Más sobre aplicaciones usando rt: http://rt.wiki.kernel.org/index.php/HOWTO:_Build_an_RT-application



Interesante...

En ubuntu también podemos instalarnos el paquete precompilado "linux-image-rt", pero a mi no me va y no se porque, aunque tampoco me funciona el ultimo kernel que salió. Cosas de las novedades, probaré el 2.6.28 a ver si ese me funciona o que.

Que bueno!!!... era más facil de lo que me pensaba. Ahora mismo lo estoy instalando, a ver que pasa..

Gracias por el dato!!

Pues mejor, pero no tanto como yo esperaba.

Lo primero: el kernel-rt de los repositorios (Ubuntu Hardy) me ha funcionado, pero tuve que re-instalar el driver de la tarjeta gráfica; la primera vez me inició en modo baja resolución. Pero después de esto parece que vá bién.

Luego, con el Ktechlab se nota una mejora, pero lo mínimo que me funciona bién es con el timer a 2 mS, a 1 mS lleva un poco de retraso.. un reloj de 1 Hz vá a 1.1 Seg mas o menos. Con timer a 2 ms vá a 1 Seg exacto.

Osea he pasado de 10 mS a 2 mS, no está mal, pero me esperaba algo más.

De todas formas este es un kernel precompilado, quizás compilando con determinadas opciones se pueda mejorar. Pero para lo sencillo que es instalarlo no está mal.


A ver si me entero algo más.