Per andare sul sicuro io inserirei il sensore in un oscillatore fatto con un 555 in versione CMOS, come quello che appare a pag. 3 del datasheet che hai linkato, eventualmente eliminando il potenziometro di taratura, se fai la taratura via firmware. Questo oscillatore sarà progettato per generare una frequenza tra 5 e 300 kHz, per rispettare i limiti imposti dal datasheet sulla frequenza di lavoro del sensore.
Poi collegherei l'uscita (piedino 3) del 555 a un divisore di frequenza CMOS (per esempio un CD4020 o un CD4060), e da uno dei piedini d'uscita preleverei la frequenza divisa, da inviare a un ingresso dell'atmega.
Il fattore di divisione dipende dalla frequenza di oscillazione e da quante letture al secondo vuoi fare.
L'ingresso dell'atmega, all'arrivo (per esempio) di un fronte di discesa, genererà una interruzione.
Nella procedura di risposta a interruzione dovrai leggere quanto tempo è passato dal fronte di discesa precedente. Questo tempo corrisponde al periodo, che a sua volta è proporzionale alla capacità del sensore.
Poi con una tabella di calibrazione fai la conversione periodo/umidità relativa.
Il divisore di frequenza esterno serve per non "stressare" con troppi interrupt l'atmega. Volendo si potrebbe eliminare e collegare direttamente l'uscita del 555 all'atmega, se calcoli le resistenze per una frequenza di poco più di 5 kHz e fai una routine di risposta a interruzione snella. Potresti fare la divisione di frequenza nel firmware, cioè, per esempio, ogni 1024 interrupt potresti andare a calcolare quanto tempo è passato.
Inviato: 20 mar 2012, 21:01