[Aporte] Capacímetro Autorango con PIC16F628A

[D@rkbytes]

Era obvio que no funcionaría a la primera, ya que voy a ciegas.

Puedes usar el archivo de simulación en proteus para ver los resultados de la programación.

Aunque no funcione, sí que tengo curiosidad en saber si el tamaño del programa se ha reducido o no. En el programa lo dejé con dos llamadas para conversión y división a punto flotante. Según lo bueno que fuera el compilador debería haber ahorrado algunos bytes.

Era obvio que el tamaño se redujera, pues se omitieron las variables float.
No muy drásticamente pero si se obtuvo reducción, aunque no buenos resultados.

Tampoco se mejoró el porcentaje de memoria ROM usada con Proton IDE (71.78% Usando variables Float)

Dejo adjuntos los cambios obtenidos.

 

[Miembro eliminado 356005]

Bueno... al menos lo hemos conseguido reducir en 300 bytes...

Me he bajado la simulación y funciona perfectamente con el cof, pero al ejecutarlo con el cof que viene con el fuente en C, no sale nada, y se ve por las señales que está en una especie de bucle sin fin.

No puedo hacer una compilación nueva, porque no tengo el mismo compilador que el tuyo, pero podría adaptarlo al mío (SDCC + GPUtils).

 

[luisdlahuerta]

Hola de nuevo chicos
ayer monté la pcb y funciona muy bien.
estoy pensando como montarla en una cajita o similar para finalizar el montaje.

Una duda que tengo es a la hora de calibrar no llega a cero, a no ser que le ponga las puntas en las manos, ¿hay que conectarle un condensador para esto? si es asi, ¿de que valor?.

Muchas gracias de nuevo Darkbytes.

Os dejo una captura de pantalla de como queda mas o menos la placa, estoy aprendiendo a usar Proteus, asi que disculpad si los packages no están muy bien

 

[D@rkbytes]

Hola de nuevo chicos
ayer monté la pcb y funciona muy bien.
estoy pensando como montarla en una cajita o similar para finalizar el montaje.

Una duda que tengo es a la hora de calibrar no llega a cero, a no ser que le ponga las puntas en las manos, ¿hay que conectarle un condensador para esto? si es así, ¿de que valor?.

Muchas gracias de nuevo Darkbytes.

Os dejo una captura de pantalla de como queda mas o menos la placa, estoy aprendiendo a usar Proteus, asi que disculpad si los packages no están muy bien

El procedimiento de calibración está en el post #1.
Para calibrar el capacímetro no tiene que tener ningún capacitor conectado en las terminales de prueba.
Se supone que se debe calibrar a 0.00pF.
Revisa bien las conexiones de los transistores, que no estés usando el archivo *.hex de simulación y verifica bien el correcto funcionamiento del preset multivueltas.
También se puede usar un preset normal pero cuesta más trabajo el ajuste y con el tiempo se puede desajustar.

Suerte.

 

[Miembro eliminado 356005]

Darkbytes, ¿has mirado lo que te ponía en mi último mensaje? ¿O es que quizás no funciona el diseño del proteus para los dos .cof publicados?

Gracias.

 

[D@rkbytes]

Darkbytes, ¿has mirado lo que te ponía en mi último mensaje? ¿O es que quizás no funciona el diseño del proteus para los dos .cof publicados?

Gracias.

Compilé el código que subiste y lo probé tanto en simulación como físicamente.
En ambos casos muestra valores incorrectos y no se puede lograr la autocalibración.
Se puede decir que tan solo funciona la lectura del capacitor de 47nF.
El capacitor de 470uF lo mide como 24.xxuF. El de 1000uF. como 4.xx y el de 2200uF. como 0.xxuF.

Con el código que subí en C si funciona el *.cof, si se puede lograr la autocalibración y los valores mostrados en simulación y en físico son correctos.

Nota:
Ahora he logrado reducir el código a un 79.8% aún con float y funciona a la perfección.

 

[Miembro eliminado 356005]

No, no me refiero a mi código, que sabemos que está mal. Se trata del último comentario que hice (#24) sobre que no era capaz de correr uno de tus cof en tu propia simulación del Proteus (los dos publicados antes).

Es decir: el cof que acompaña a la simulación, funciona, pero el cof que acompaña al código C publicado, no. O al menos, en la simulación, no funciona.

Voy a probar este último aporte que has subido.

Gracias.

Edito: ya lo he probado y funciona bien. Como también has subido el código en C, ya puedo intentar mejorarlo (si puedo).

Este es otro intento. Sólo he cambiado un par de cosillas de sitio, así que no creo que haya mucho ahorro. Lo interesante es que funcione igual y el siguiente intento.

 

[D@rkbytes]

No, no me refiero a mi código, que sabemos que está mal. Se trata del último comentario que hice (#24) sobre que no era capaz de correr uno de tus cof en tu propia simulación del Proteus (los dos publicados antes).

Es decir: el cof que acompaña a la simulación, funciona, pero el cof que acompaña al código C publicado, no. O al menos, en la simulación, no funciona.

Tal vez fue porque utilizaste un archivo de simulación anterior, recuerda que en PICC se tiene que usar el pin RW de la pantalla y en los esquemas anteriores este pin está conectado hacia Vss.
No existe otra razón para que no funcionen los coff, ya que son los que he usado para las simulaciones.

Este es otro intento. Sólo he cambiado un par de cosillas de sitio, así que no creo que haya mucho ahorro. Lo interesante es que funcione igual y el siguiente intento.

Si funciona bien, no hay ahorro pero ya se ven menos GoTo.

 

[Miembro eliminado 356005]

Siguiente versión. Tampoco hay ahorro de espacio, pero cambiados algunos goto por bucles while o subrutinas.

 

[D@rkbytes]

Siguiente versión. Tampoco hay ahorro de espacio, pero cambiados algunos goto por bucles while o subrutinas.

Ya está mejor la versión en C y funciona bien
Gracias Joaquín por seguir mejorando esta versión del código.

 

[Miembro eliminado 356005]

Otra versión. Vamos poco a poco, pero al menos vamos seguros de que funciona.

Esta versión tiene más limpieza del código, algún comentario más y algún comentario recortado. También están formateados con tabuladores, que ayuda en la edición de las sentencias que les preceden.

Hay también un par de cambios importantes, que es posible que lo hagan fallar, sobre todo el bucle de la línea 144 a 162.

Se ha sacado aparte el procedimiento de Calibrado.

Si tuviera claro el funcionamiento de esas líneas, creo que se podrían simplificar un poco más.

Si me dices que esta versión funciona, entonces el siguiente paso será quitar el uso de punto flotante, donde se debería apreciar ahorro de bytes.

 

[D@rkbytes]

Se ha sacado aparte el procedimiento de Calibrado.

Si tuviera claro el funcionamiento de esas líneas, creo que se podrían simplificar un poco más.

Ese procedimiento sirve para no hacer una recalibración cuando Cx = 0.00 pF.
Únicamente ha faltado declarar este procedimiento en la cabecera, pero agregándolo ya se puede compilar.

Si me dices que esta versión funciona, entonces el siguiente paso será quitar el uso de punto flotante, donde se debería apreciar ahorro de bytes.

Si funciona correctamente y los valores mostrados son correctos.
También se ha mejorado la resolución en la escala baja.

 

[Miembro eliminado 356005]

Otra versión. Y ésta seguro que falla.

Ponme el error que salga.

He comenzado a simplificar código creando más subrutinas.

La duda que tengo es en el paso de valores por las subrutinas. Lo he escrito en C estándar.

¿La librería lcd.c es pública? O mándame un enlace si está por Internet.

¿Cómo se define una variable de 32 bits? ¿long, long int, int32?

 

[D@rkbytes]

Otra versión. Y ésta seguro que falla.

Ponme el error que salga.
La duda que tengo es en el paso de valores por las subrutinas. Lo he escrito en C estándar.

Aparece error en la rutina void Pinta_Txt (char *Texto)
*** Error 90 "CapMeter JHD 162A.c" Line 81(41,42): Attempt to create a pointer to a constant
Y es porque char acepta únicamente 8 bits (unsigned int8) y no una cadena de caracteres.

¿La librería lcd.c es pública? O mándame un enlace si está por Internet.

Es la que viene por defecto con el compilador.

¿Cómo se define una variable de 32 bits? ¿long, long int, int32?

Se define como int32
Adjunto los tipos y la librería actual.

 

[Miembro eliminado 356005]

No, eso no es lo que quiere decir el error. Ya sé que char es para 8 bits, lo que he puesto en la declaración de la función Pinta_Txt es char *, que es la forma estándar para definir punteros a cadenas de caracteres.

Lo que dice el mensaje de error es que no se puede crear un puntero a una cadena de caracteres constante.

Entrando en la web de CSS, dice que hay que poner 'const' delante del 'char *' para indicar que se va a apuntar a texto que está en la memoria del programa.

Prueba a poner

const char *

tanto en la declaración de función en la línea 34, como en la definición de función de la línea 179.

Si no funciona, entonces pon esta línea al principio y vuelve a probar:

#device PASS_STRINGS=IN_RAM

y nos cuentas qué tal.

Lo he sacado de aquí: https://www.ccsinfo.com/content.php?page=compiler-features

 

[D@rkbytes]

Prueba a poner

const char *

tanto en la declaración de función en la línea 34, como en la definición de función de la línea 179.

Si no funciona, entonces pon esta línea al principio y vuelve a probar:

#device PASS_STRINGS=IN_RAM

y nos cuentas qué tal.

Lo he sacado de aquí: https://www.ccsinfo.com/content.php?page=compiler-features

Con poner #device PASS_STRINGS=IN_RAM ya compila.
Pero ahora se ha elevado el consumo de ROM a 93% y el de RAM a un 34%

El nuevo procedimiento Pinta_Txt sigue sin funcionar, muestra una tilde "'" en vez de "*CALIBRACION OK*"
Y un 8 en vez de "!FUERA DE RANGO!"

No lo veo necesario, pero eso es lo que está pasando ahora.

Edit:
También utilicé const char calib[] = "*CALIBRACION OK*"; y pasando esta cadena a la rutina, sin éxito.

 

[Miembro eliminado 356005]

He intentado instalar la demo del compilador, pero no me funciona con el emulador de Windows que tengo.

He dado un paso atrás y he quitado la Pinta_txt() hasta que sepamos cómo abreviarlo.

Aquí hay otra versión, en la que debería desaparecer el código relativo al punto flotante, y notarse más el aumento de velocidad y el ahorro de bytes.

 

[D@rkbytes]

Aquí hay otra versión, en la que debería desaparecer el código relativo al punto flotante, y notarse más el aumento de velocidad y el ahorro de bytes.

Si disminuyó el uso de ROM a 59% y el de RAM a un 17% pero ahora dejó de funcionar el muestreo bajo.
Los valores leídos inferiores a 47 nF muestran 0.00 pF.

Por ahora de los códigos que has modificado, el que mejor va es el del post #33

Aquí unas fotos de las pruebas del código funcional sobre protoboard.

 

[Miembro eliminado 356005]

Aquí va una versión basada en la #33, pero con alguna mejora, y con la parte de flotante puesta de nuevo.

Estoy intentando conseguir un CCS para Linux

 

[D@rkbytes]

Aquí va una versión basada en la #33, pero con alguna mejora, y con la parte de flotante puesta de nuevo.

Esta versión también funciona bien, mejor en físico que en simulación, pero finalmente es de lo que se trata.
76% de ROM y 17% de RAM.

Estoy intentando conseguir un CCS para Linux

Por aquí hablan sobre eso: Compilador CCS con Wine