Dificultad con resta de 2 registros 16 bits con niple 6.1

[svanapic]

Estimados, le escribo nuevamente, ya con la nueva version de niple instalada (6.1) Sigo teniendo el mismo problema en la resta de 2 registros 16 bits. No la realiza correctamente y entrega un valor oscilante.
Les adjunto la rutinita en niple, el circuito en proteus y el .hex.


Basicamente lo que debe hacer es convertir en digital (10bits) 4 valores analogicos(Ra0,Ra1,Ra2 y Ra3) , los escalo, y resto 2 de los registros escalados (Ra2-Ra3).  El resultado que obtengo no es correcto.

Para guiarlos, la conversion del ra2 es la que figura en la pantalla =consumo=, debajo de la palabra "total", la conversion deRa3 es la que figura en  la pantalla =consumo=  arriba de donde dice Acc, y la resta de ambos, aparece en  la pantalla =bateria= arriba de donde dice Acc.

Por otra parte probé restando los registros antes de escalar y escalar luego el resultado de la resta, tampoco obteniendo un resultado satisfactorio. 

Ojalá puedan ayudarme a resolver este inconveniente ya que estoy apurado por terminar un proyecto. en el que incluyo esta rutina.

Este mismo problema encontré en la version 6.0.3 plus Tal vez puedan ayudarme a ver si el problema es mio o del calculo del niple.

Gracias de antemano.

[Fer_TACA]

Amigo,
te dejo un fichero simple de la conversión de los canales RA3 y RA2 como los que has usado.. He utilizado tu mismo esquema de proteus y la diferencia en la resta si es correcta. Puedes verlo en le fichero adjunto.

Lo que si veo en tu esquema cosas que no están muy claras como es la configuración del puerto A. Niple no te permite tener configurado el puerto A con 4 canales analógicos y el resto salidas digitales.
Creo que este proyecto fue realizado con una versión anterior a la 6.1. Aquí estuvimos bastante tiempo comprobando las operaciones matemáticas, que es cierto que en anteriores fallaban. Si es así te aconsejo rehacer el proyecto con la versión 6.1 o mandarla a soporte@niplesoft.net para que te la actualicen, pues como veras la diferencia en loa resta funciona OK.

[svanapic]

Hola Fer. Dede ya gracias por tu ayuda. Mirá, el pryecto de hecho lo reescribí completo con la version 6.1.0 plus (tal cual figura en la parte suerior izquierda del programa, y adjunto un print screen ). Ahora, me llama la atención lo que mencionas. escribiendo en el programa desde cero, SI me deja setear 4 ntradas con AD y las otras como salidas.  Pero entiendo que por lo que decis no es lo correcto?  como debería hacerlo? 

Puede que no sea la ULTIMA version la que yo tengo?


De cualquier manera, investigaré el ejemplo de resta que me mandaste para ver si hay algo que no estoy haciendo bien.

Te mantengo al tanto.

GRACIAS

[Fer_TACA]

Amigo,

no dudo lo que dices respecto a la versión pero si hay una diferencia pues los bloques de asignación son de color fucsia y a ti te aparecen de color azul.

Con lo de las analógicas, ahí tienes tu razón me equivoque y empecé a realizar el programa con el 877 y luego lo migré al 887 que era el que utilizabas.
He repasado y rehecho tu programa y te lo adjunto ahora creo que funciona. No he realizado nada especial. Solamente cree todos los registros que ibas a utilizar de una vez antes de nada. De esa forma todos quedan en la primera pagina de memoria.

Bueno están un poco desordenados los bloques al ir realizando toda la revisión. No se porque no te funcionaba la resta. Todas las veces que he probado y de distintas maneras siempre me funciona.
Revisa lo que te adjunto y ya me dices. Si va bien quizás deberías de enviarlo(lo que tu tenias realizado) a soporte@niplesoft.net para saber, al menos que pasaba y tenerlo en cuenta para otras ocasiones.
Espero tus comentarios.

[svanapic]

FER, gracias amigo por tu ayuda.  Acabo de hacer la consulta a soporte acerca de la version. Para asegurarme tener la última.  Por lo que veo, los bloques fucsia son los de asignacion de valor al bit. y eso lo hace. Solo que al compilarlo los pone color celeste. Pero mas allá de eso, logré que funcione correctamente la resta y la conversion AD.  gracias totales por eso.  Evidentemente tiene relevancia que no todos los registros esten en la pagina 0 de la memoria.
con lo que estoy teniendo problema, es con la conversion luego de retornar de una rutina de interrupcion. Es como que se cuelga completamente la conversion ad cuando se vuelve de la rutina de interrupcion por INT rb0 o cambio de estado de alguna entrada del puerto b.
tenes idea que puede ser que genere esto? 

te adjunto el circuito en proteus, y los programas de los 2 pics que componen dicho proyecto.  Vas a ver que al comenzar te muestra (sin mucho formato) los 4 valores de la conversion que le manda el segundo PIC, pero al presionar cualquiera de los 2 pulsadores y meterte en la interrupcion, los valores se disparan y deja de funcionar la conversion.  seguramente es alguna macana mía, pero ojalá con tu experiencia puedas darme una mano ya que no puedo entender el porque.

agradezco nuevamente tu ayuda.  toos los días un paso adelante con este maravilloso programa que me ayuda tanto.

un abrazo.

[Fer_TACA]

Bueno a lo largo del dia le echo un vistazo y te voy diciendo.

[svanapic]

GRACIAS FER!  Perdón por lo del doble post. Pensé en realidad que sería difícil compartir esta experiencia estado hecha la consulta dentro de otra cosa que poco tiene que ver.  Un saludo. y gracias de nuevo.  Espero entonces tus comentarios.

[Fer_TACA]

Ayer se me complicó el dia y no pude verlo. Mas rade lo reviso.

[svanapic]

Te entiendo. No hay problema.  Y te agradezco tu ayuda.  un saludo.

[Fer_TACA]

Veo algunas cosas que no entiendo y paso a contarte:

1º Rutina principal
Cuando haces la primera comprobación si detecta D0=0) que hace una cosa sigues el curso y si no chequeas el D1 pero si no se cumple este prácticamente repites el lo mismo que si está activado D0 pero con mas tiempo. ¿Por qué si dentro de las rutinas de tiempo solo has puesto el retraso sin hacer nada mas, no colocas sólo la temporización por ciclos? Te ahorrarías 3 saltos de subrutinas que al final consumen tiempo.
Claro que entonces hasta que no terminen el micro se queda como parado y si no quieres eso debes de meter los tiempos en una interrupción por ejemplo de TMR0 que creo que no la estas usando. Ahí realizas una pequeña base de tiempos y cuando alcance los valores deseados se termina el tiempo y listo.

2º Rutinas de interrupción
No se si estas seguro de lo que pretendes, ya que dentro de la rutina de interrupción de RB0 chequeas el pin de RB7 y viceversa dentro de la interrupción de cambio de estado de RB0 a RB7 chequeas el estado de RB0. ¿Es esto lo que quieres? ¿Si ya tienes habilitada por otro lado la detección por flanco del propio pin RB0Date cuenta que cuando están en una interrupción se deshabilitan el resto de interrupciones.

[svanapic]

Hola Fer. Para el punto 1 le respuesta es, que ese tiempo puede ser modificable dependiendo de la aplicación del programa, entonces esa es la manera en la que enocntré de modificar solo una vez el tiempo.  Me explico? Es decir, esa misma rutina, la uso en varias partes del programa. En algún caso, ese "tiempo entre pantallas", puede ser 2 segundos,  y en otro caso, podría llegar a se 1 ó 3 segundo.  No obstante, estoy aprendiendo, por lo que si encontrás cualquier cosa no recomendable por X motivo, me encantaría saberla.   Para quedarme tranquilo, vos ves algún inconveniente en que lo haga de esta manera? Si así fuero podría perfectamente insertar tiempo individuales en varios puntos del programa

En el punto 2 , hoy me fijaré ni bien llegue a casa, ya que no tengo niple en la PC en la que estoy ahora. Pero no recuerdo esto que decís.  Si recuerdo que en la interrupción por cambio de estado de las patas del pto B checkeo el RB7, y activé otra interrupción por flanco descendente del RB0.

Agradezco muchísimo tu ayuda y recomendaciónes.

Pudiste verificar la "malfuncion" del la conversion cuando te metés en la rutina de interrupción?

VOs crees que puede tener algo que ver lo que mencionas en el punto 2?

GRACIAS por tu tiempo FER!

Aguardo tus comentarios

[svanapic]

Hola Fer, Buen día. Ahí me fijé y entendí a qué me hacías referencia. En el caso de la interrupcion por RB0, cuando se mete dentro de la rutina, le agregue un tiempo para obligar al usuario a mantener presionado el boton durante 1 segundo antes de realizar el cambio en el equipo. Es para evitar cambios accidentales.

Y en la rutina de cambio de estado de rb7, lo mismo, solo que ese pulsador cumple una doble función, si lo presionas menos de 1 segundo, anula un buzzer indicador de alarma, y si lo mantenés presionado te muestra una pantalla con datos del equipo.

Espero se entienda. 

un saludo y gracias.



 

[svanapic]

Hola Gente del Foro, quería contarles que encontré el problema que originaba la malfunción. Antes que nada, gracias a la ayuda de FER TACA, encontré un error mío (había puesto la rutina de la interrupción por flanco descendente de RB0 dentro de la de cambio de estado de RB7 y viceversa).  GRACIAS FER POR ESTO. 

Ahora, el problema en la muestra de los valores (conversión AD + ESCALADO + Posterior operación matemática se tildaba).  Lo que originaba esto era una demora de 1 segundo dentro de la rutina de interrupción. 

Se solucionó ni bien quité dicho tiempo, y ahora mide perfectamente.

Espero ayudar a alguien con esto algún día.

Ahora les pregunto, como se les ocurre que puedo hacer que para que se produzca un cambio (interrupcion por RB0 por flanco, o cambio de estado en RB7) pero solo si la persona mantiene presionado mas de 1 segundo el botón?

Esto lo había logrado con una demora por ciclos dentro de la interrupción, y luego una toma de decisión (Rb0=0? es decir, presionado?) y recién, si la respuesta era afirmativa cambiaba el estado de un registro.

Tienen alguna idea?

GRACIAS AMIGOS!

 

[Fer_TACA]

Estoy fuera por motivo laborales y no me puedo conectar de forma continua. Tampoco dispongo en la Tablet el programa Niple. Cuando regrese en unos 8-10 días me pongo con ello, si antes no logras encontrar la forma de solucionarlo.

[lucegiar2005]

Si estás checando ese pin y al determinar un estado por x segundos querés que se produsca una interrupción, podés hacerte tu "interrupción" propia sin que sea de las que ya están incluidas. Llamala como desees a la rutina, una vez comprobada su permanencia en el estado de disparo de ella tenés que desactivar las interrupciones, ejecutar la rutina que ahora no podrá ser interrumpida, re-activar las interrupciones normales. Es solo una idea que funcionó en mi caso en un proyecto. Un abrazo