Aumentar eficacia de Proteus simulando varios PIC

Aunque no sabía exactamente donde colocar el tema, lo coloque aquí.
el caso es el siguiente, he diseñado un sistema en el que un PIC controla el 90% de las funciones del sistema y el resto lo controla otro PIC que se encarga solo de una función, controlar el teclado, una de las funciones del PIC principal(el del 90%) es controlar una pantalla LCD 4x20, el fin del ensayo o circuito era probar el protocolo de comunicaciones entre ambos PIC y que el código de la tecla pulsada apareciera en la pantalla LCD, al principio no funciono, luego de corregir varios problemas con los programas y el circuito, logre que funcionara, sin embargo con el tiempo fallaba lo cual no era lógico ya que las variables no cambiaban si estas no pasaban por los buses, lo cual me llevo a que Proteus a través del tiempo cometía errores en el programa, supuse que era debido a que ocupaba mis 2 núcleos y Windows le quitaba tiempo y los errores se acumulaban y en fin. pensé que se debía que usaba la frecuencia real de diseño, y lo que ise fue reducir la frecuencia en ambos microcontroladores a otra frecuencia, la real era de 20MHz y la reduje a 1MHz, aunque todos los tiempos que Proteus consideraba real sé que son una veinteava parte de lo real para mí, funciona perfectamente...

Los protocolos de comunicaciones funcionan indistintamente de la frecuencia, pero mi preocupación es que reducir la frecuencia afecte a la pantalla LCD, ya que este si depende del tiempo, pero como la frecuencia fue reducida y no aumentada no deberían haber problemas.

La pregunta es si acaso afecto a algo más haciendo esto... si crea errores o algo en el diseño... o simplemente sus opiniones si esto es una buena técnica...
 
Última edición:
Para mi lo unico que sucede cuando le bajas a la velocidad del pic en proteus es que ejecutara el programa mas lento y se tardara mas en mostrar los caracteres en el lcd y la verdad nunca he tenido problemas en proteus con los pics por que si la simulacion me falla en proteus 100% seguro que me falla en la practica
 
pues esa es la grasia de disminuir la frecuencia, si el codigo se ejecuta mas lentamente ocupa menos tiempo del procesador y aumenta el tiempo libre, por lo que si en algun instante como cuando se necesita accesar a harware externo al pic se tiene disponible inmediatamente, asi que la simulacion es mas precisa. ademas, recuerda que proteus lo hisieron humanos, asi que es muy posible que tenga errores en sus codigos, aunque estos sean muy raros.

ademas, se me ocurrio algo, proteus se podra montar en multiples PC de tal manera que trabajen juntos para simular un mismo circuito o bien hacer un cluster moxis sobre linux y montar sobre este wondows e instalar proteus en ese windows y aprobechar todos los recursos de todos los PC del cluster?, se que suena enrredado, pero esto aumentara la eficiencia de proteus?.
y otra cosa, abra alguna manera de disminuir la carga que presenta proteus sobre el sistema?, com puede ser reducir los fotogramas u otras cosas...
 
Creo que es mas enredado que nada, yo pienso que proteus sirve para simular no para emular ¿O era al reves? jejejeje. Cual es el afan de verlo trabajar en ese simulador pudiendo verlo en la vida real?

Para estan los debuger !O como se escriba¡ Y cuanto aparato te imagines para medir.

jejej Humilde opinion mia, solo eso.
 
enredada? que parte?,

y respecto de porque usar un simulador, porque si por algun error en el siseño provocase un error en los buses como una contencion o algo por el estilo, y eso podria quemar el pic utilizado, es decir, 15 mil CLP a la basura por no simular el circuito antes de armarlo...
 
Nada es independiente de la frecuencia, los protocolos tampoco. Vos pensas que es el proteus el que te introdujo errores y puede ser, pero hay otra opcion, y es que tu SW no este funcionando bien a alta frecuencia.

para no seguir adivinando, tendrias que dar mas detalles de tu implementacion. Por empezar hablas de colisiones y eso ya da que pensar, si estuiera en tu lugar utilizaria un simple protocolo serie con linea dedicada de rx y tx con el que nunca pueden haber colisiones. Pero mejor... pone tu implementacion, aunque sea a nivel de bloques.
 
enredada? que parte?,

y respecto de porque usar un simulador, porque si por algun error en el siseño provocase un error en los buses como una contencion o algo por el estilo, y eso podria quemar el pic utilizado, es decir, 15 mil CLP a la basura por no simular el circuito antes de armarlo...


Dije enredado porque tu mismo lo dijiste.

Si tu miedo es cometer errores y quemar el IC puedes recurrir a poner resistores de bajo valor como 100 o 68 ohms sobre las lineas que hacen conexion de un IC al otro, asi si llega a ocurrir una contencion no pasa mucho y ademas rara ves podra modificar caracteristicas de la señal "bueno siempre y cuando tu comunicacion sea relativamente baja"

O podrias simular por partes tu circuito, si quieres ver que funcione tu protocolo de comunicacion entonces simula solo esta seccion y quitale los demas componentes que no se usan "amplificadores, lcd, botones, motores etc"

Pero de ahi a usar 2 o 3 computadoras interconectando sus procesadores y haciendo todo lo que dijiste :unsure:.... mejor intento hacer lo de que te digo. Al final solo es una opinion y sugerencia la que te doy. O espera haber si alguien mas lo soluciono de otro modo.

Por cierto proteus trae una simulacion de un mini linux sobre un ARM7 y funciona :)
 
al principio pensé en utilizar un protocolo serial para transmitir los datos, pero este aunque ocupa menos líneas ocupa más tiempo, y en el proyecto el tiempo es algo muy importante, ya que el PIC principal tiene que ejecutar todo su código por lo menos unas 10 veces por segundo y eso aunque parece poco para un PIC es harto, ya que tiene varia funciones, tomar datos con el conversor A/D, luego con esos datos hacer cálculos y modificar un conversor D/A, cerciorarse de las condiciones de 15 líneas muy importantes, actualizar una pantalla LCD 4X20 que está llena, etc... Por lo que gastar 10ms en una rutina serial sería perjudicial, aunque la ocurrencia de la comunicación es bastante baja por tratarse de un teclado.

en cuanto a simularlo por partes, no me parece una muy buena idea, ya que varias cambian durante el tiempo, y respecto de las comunicaciones, el PIC principal controla 4 74HC374 más 2 74HC245, estos comunican el PIC con el resto del sistema, aunque cree subrutinas para estas comunicaciones se utilizan muy a menudo...

también he investigado, puedo montar un clúster mosix sobre Linux, instalarle Wine e instalar sobre este último Proteus, así no tengo para que montar una máquina virtual Windows... ahora ya no es tan enredado...

gracias por tus sugerencias, se agradecen, dejo adjunto mi diseño, carguen los .hex según corresponda, prueben primero con relojes de 20MHz que son los originales y luego redúzcanlos a 1MHz y verán una notable diferencian los resultados.
 

Adjuntos

  • simulacion proteus.rar
    85.7 KB · Visitas: 95
  • Programas PIC.rar
    1.5 KB · Visitas: 56
Última edición:
Pues la verdad no hace nada ni a 20Mhz ni a 1Mhz para manejar un teclado basta con el MM74C922 y en el pic usas solo 4 puertos y 6 para el LCD te quedan en el 84A hasta 2 pines libres para comunicarse con el otro pic que creo que lo pretende es como controlar la velocidad del motor?
 
de hecho el proyecto es mucho más complejo, el control de velocidad del ventilador es una función menor, ese es el diseño de una fuente variable digital, se ven el regulador patrón, el conversor d/a y el PIC controlador de teclado, también el PIC principal que es el 877, el programa está hecho para hacer avanzar la velocidad del ventilador, hacer avanzar el voltaje de salida del conversor de manera continua y además responder al teclado y mostrar en la pantalla LCD el código de la tecla presionada... es decir, varias cosas, así que no se puede decir que no se haga nada, el circuito lo estoy armando por partes...
 
Última edición:
No pues ovio que hace pero cuando lo simule en proteus no hizo nada salvo al inicio que decia tecla 0 o algo asi pero de alli aunque presionara una tecla no hacia nada, tienes que usar el 74HC139 por que asi te lo pidieron en tu proyecto por que miro muy complicado estar barriendo cada columna para luego irte al 74HC151 que te lo convierta en 4 o puedes usar algo mas simple? como el MM74C922
 
seria ideal reemplazar el pic por el MM74C922, pero estoy sujeto a disponivilidad de componentes, y los pic son mas comunes que estos integrados tan especializados...
cuando presiones una tecla, asegurate que la presionas cuando el pic empezo el rastreo, porque tiene un retrazo al arranque para asegurar la alimentacion, ademas, asegurate que el tiempo de la simulacion podria ir muy lento y si tu presionas una tecla como si fuese real, el pic no alcanzaria a leerla...

en la pantalla deveria aparecer en la primera linea un texto que dice "valor 0", este es del conversor A/D del pic principal, si quieres probarlo, coloca un potenciometro en la entrada ra0 y veras el resultado de la convercion en el display, en la segunda linea aparece "TECLA 0", el 0 cambia cada vez que presionas una tecla, el cero es reemplazado por el codigo numerico, por ejemplo, la primera tecla superior ezquierda tiene el codigo 1, la inferior el 2, y asi sucesibamente...
he ejecutado nuevamente la simulacion, y el taclado funciona perfectamente...
 
intentare conseguirlo entonces, talves lo encuentre... pero volviendo al tema, sera una buena idea disminuir el reloj de los pic para permitir una simulacion mas "amena"?
 
La frecuencia no afecta, solo se va apreciar mas lento todo, hay elementos que tal ves necesiten una temporizacion exacta, aunque la mayoria aceptan que los tiempos sean mayores pero no menores, es decir la LCD va a funcionar aunque el micro valla muy lento, cosa que no pasaria si el micro fuera muy rapido. Aun asi yo recomendaria quitar algunas cosas que no son esenciales, ya que cada cosa que pones consume recursos, ademas si le das clic izquierdo dentro de las propiedades de algunos componentes puedes ajustar la frecuencia de trabajo y la frecuencia de refrescado etc etc.
 
Gracias, al fin una respuesta al tema. En cuanto a quitar algunas partes, creo que es contraproducente, porque como dije en otro mensaje todos los circuitos de cada función dependen unos de otros, por lo que deben ser simulados juntos para observar su comportamiento....

Se verá algún cambio en el rendimiento si simulo en un pc con procesador dual core de 2.1GHz que en uno dual core 2.6GHz, el primeros con Win7 y el segundo con XP?

Gracias por sus sugerencias...
 
Última edición:
No se pero si usas win7 quitales los temas aero, porque consumen muchos recursos, tambien puedes hacer varios ajustes en windows para ejecutar programas mas rapidamente, yo he notado diferencias al quitar la memoria virtual y detener procesos como los antivirus
 
tengo instalado el TuneUp, lo configure para detener todos los servicios que no necesito(el modo turbo), y siempre me fijo si algún proceso consume mucho tiempo de procesador, pero por desgracia tengo cierta adicción a ver series mientras trabajo en circuitos y el reproductor que uso ocupa la mitad del CPU(el Splash PRO)...

pero tienes razón, cuando hice todos los cambios deshabilitando el tema y cambiándolo por otro más simple note un aumento en el rendimiento.... en cuanto a deshabilitar la memoria virtual, no me parece buena idea, lo que hice fue reducirla porque cuando me regalaron la notebook era de 5GB y el disco duro se volvía loco, así que la reduje a 1GB y mi disco duro empezó a descansar (creo que por eso mi pc es más rápido en comparación con los pc de mis amigos, y eso que los de ellos son nuevos y el mío tiene 4 años....)

en cuanto a los ajustes que mencionas para que los programas se ejecuten más rápido dime donde se hacen, para aplicarlos en mi notebook...
 
He buscado como usar sub circuitos en Proteus, ya he aprendido a usarlos, pero me pregunto si el hecho de usar sub circuitos disminuye o aumenta la carga en el procesador, o si es lo mismo... ¿qué opinan?
 
He buscado como usar sub circuitos en Proteus, ya he aprendido a usarlos, pero me pregunto si el hecho de usar sub circuitos disminuye o aumenta la carga en el procesador, o si es lo mismo... ¿qué opinan?

Hola.
Básicamente es lo mismo pero depende; por ejemplo.

Si tienes muchos elementos que interactúan con el usuario ya sean LED's, LCD's, teclados, etc... el proceso de renderizado (pintar el ambiente de diseño) consume algo o mucho del procesador si lo tienes en modo GDI+ pero menos si lo tienes en modo DirectDraw u OpenGL que utiliza directamente la aceleración del dibujo por hardware (tarjetas de video independientes).

Si la cantidad de componentes animados es reducida corre a mejor velocidad en cuanto al dibujo.

Si se tiene microcontroladores... cada proceso del firmware consume poco o mucho del procesador ya que el programa debe de realizar las instrucciones emulando el comportamiento del mismo (si son complejas se va a demorar más en dar un resultado) y ajustarlo para que sea casi en tiempo real (aquí trabaja la frecuencia del Osc al cuál se configura).

Seria bueno que el subcircuito se pueda compilar, de ese modo se simularía en segundo plano y seria tratado como otro dispositivo de la librería pero no... es igual que cuando se crea un circuito en varias hojas.

Circuitos análogos no se, el echo de que sea análogo requiere de algo más de cálculos de parte del procesador y se van a notar en cuanto hayan más componentes.

Entre otros detalles y personalmente he preferido reducir la parte interactiva y correr el programa paso a paso o con breakpoints digitales y análogos, así básicamente lo uso para analizar ciertos puntos del programa o utilizar gráficas para ver las señales resultantes...

Saludos.
 
Atrás
Arriba