PIC18F46K22 y problema raro del ADC

[dogflu66]

Volviendo al tema anterior de la entrada ADC, las entradas cmos no se pueden dejar al aire, es una regla básica. Tienen que estar polarizadas ya sea por el circuito externo que le conectes, o por un circuito propio de acople, ya sea una simple resistencia, red rc, etc, como bien te indica el amigo forero.

El tema de que un micro te haga lectura o no es por la familia o serie a la que pertenece, por eso hay tantos para elegir según la aplicación. Yo uso desde hace años el Pic18F46K22 y para mis aplicaciones es el idóneo. Este es un micro mejorado que tiene alta impedancia de entrada y por eso te mide cualquier estática del ambiente o cableado cercano, mientras que el otro su impedancia de entrada es muy inferior y no se ve afectado tan directamente. Tanto el uno como el otro tienen su razón de ser.

[Nocturno]

Eso se usa cuando puedes tener una transición muy rápida y quieres estar seguro que la señal estuvo activa un tiempo mínimo.
Es un recurso muy utilizado porque evitas colocar código más complicado.

A eso yo le llamo código redundante necesario. 

Pero tendría sentido si tuviera un delay de algún tipo; al no tenerlo he descartado que busquen esa redundancia con tiempo mínimo.

[DominusDRR]

Eso se usa cuando puedes tener una transición muy rápida y quieres estar seguro que la señal estuvo activa un tiempo mínimo.
Es un recurso muy utilizado porque evitas colocar código más complicado.

A eso yo le llamo código redundante necesario. 

¿Pero cómo evitas que el compilador lo optimice?

Porque si haces eso, un buen compilador determina la redundancia y lo simplifica a un sólo if.

Al menos que trabajes sin optimizaciones de código y/o sea un pésimo compilador.

Y eso que indicas de una transición rápida, hay otras maneras de determinar si realmente esta activa presente un mínimo de tiempo.

[dogflu66]

Pues eso Manolo; si quieres más tiempo insertas delay del tipo que sea y vuelves ha hacer la comprobación. Todo es cuestión de la aplicación. 

Tengo algunos automatismos funcionando en las que las salidas activan reles y dependen de alguna entrada, estas entradas están asociadas a funciones que cuentan el tiempo por interrupciones, como es normal para no entorpecer el buen flujo del programa. Pero esto lo uso para tiempos largos, para tiempos mínimos uso esos recursos.

[dogflu66]

Eso se usa cuando puedes tener una transición muy rápida y quieres estar seguro que la señal estuvo activa un tiempo mínimo.
Es un recurso muy utilizado porque evitas colocar código más complicado.

A eso yo le llamo código redundante necesario. 

¿Pero cómo evitas que el compilador lo optimice?

Porque si haces eso, un buen compilador determina la redundancia y lo simplifica a un sólo if.

Al menos que trabajes sin optimizaciones de código y/o sea un pésimo compilador.

Y eso que indicas de una transición rápida, hay otras maneras de determinar si realmente esta activa presente un mínimo de tiempo.

Bueno, te entiendo; en mí caso que el compilador me cambie el código no es una buena opción.
Yo realizo pequeños y medianos automatismos desde hace mucho pero muchos años, y si no cuento las librerías propias mi código principal no suele ocupar más de varios cientos de líneas. Que el compilador avise de algo redundante esta bien, y lo suprimiré según me interesa o no.

PD: De todas formas si colocas algo entre los dos IF, como una operación de no hagas nada durante un ciclo de reloj, tu compilador debería compilar ese tipo de código.

[DominusDRR]

PD: De todas formas si colocas algo entre los dos IF, como una operación de no hagas nada durante un ciclo de reloj, tu compilador debería compilar ese tipo de código.

Obviamente, si pones algo entre los dos if como una instrucción NOP o un delay, el compilador mantendrá los dos if por separado, pero como indicó el OP, ni con la optimización en el nivel más bajo, pienso que se mantendrá por redundancia.  Sería de analizar el ensamblador para determinar si ocurre eso o no.