Tenes que pensar que la comunicacion se realiza por un solo hilo. Para evitar problemas las salidas deberian ser colector abierto. Y la linea de datos poseer una resistencia a VCC.
Una salida a colector abierto tiene 2 estados, alta impedancia y ponerlo a 0V. En el caso del PIC para simular esto seria, ponerle como entrada ( colector abierto ) y ponerlo como salida y 0.
Ya que si pones a 1 la salida del PIC corres el riesgo que el DHT22 ponga a 0 la salida de datos produciendose un cortocircuito. Uniendo 5V con 0V.
Con esto dicho voy por los pasos que enviaste. y los corrigo si veo algo malo
1-El micro le manda una señal baja durante 20 ms para decirle al dht que va a empezar a sensar - Es correcto
2-luego le manda una señal alta durante 20 US - La señal "alta" es en realidad el pin puesto en alta impedancia (entrada), la resistencia de pull-up lo lleva a 5V
3-Luego le responde el DHT con una señal baja durante 85us. Correcto, aunque lo vi en 80us al igual que abajo
4-Luego le responde el DHT con una señal alta durante 85us.
ahora mi duda es la siguiente para que me sirve el paso 3 y 4 osea yo tengo que leer esas 2 y preguntarle si mando un 0 o un 1? para seguir o como seria esa parte... nose si me explico.
El paso 3 y 4 a vos no te sirve de mucho, solo para saber que el DHT22 recibio la orden de envio de los datos, igual al final de los 40bits se envia un pulso bajo mas si no tengo mal entendido. La mayoria termina haciendo algo asi:
output_low(PIN_xx); // Si esta en standart_io lo pasa a salida solo
delay_ms(20);
input(PIN_xx); // Si esta en standart_io lo pasa a entrada solo, sino cambiar el tris aca.
delay_us(10);
while(input(PIN_xx)!=0); // Espero que se ponga en 0
while(input(PIN_xx)!=1); // Terminado el 0 espero que se ponga en 1.
// Aca recibo los datos
Luego leer los datos es facil tambien. Por que lo unico que varia del dato es el tiempo que esta en "1", por lo tanto, esperas que se ponga en 0, luego que se ponga en 1, usas un delay por ejemplo de 30us y lees de nuevo, Si es 0 es por que paso al otro bit (el 0 tarda entre 26-28us) y corresponde a un 0 leido, si todavia sigue en 1 ( como tarda 70us ) entonces es un 1.
Para recibir el otro volves a repetir esto, es decir esperas el 0, que en el caso que hubiera sido un 0 antes ya estaria. y luego el 1.
OJO. Por ahi dependiendo de la velocidad de tu PIC ( si por ejemplo elegis usarlo a 4Mhz ) tal ves te quedes corto haciendolo en C. Es decir que le tomaria mas tiempo. Para mejorar un poco mas el tiempo deberias usar FAST_IO y no STANDART_IO, y tambien aumentar la frecuencia (o directamente aumentar la frecuencia solo), En ASM una persona lo pidio hace poco y no quedaba demasiado tiempo libre con 4Mhz.
Una cosa mas que me olvidaba, al comienzo hay que esperar un buen tiempo antes de pedirle los datos, creo que 1 segundo desde que se la da tension a todo y luego Cada 2 segundos actualiza todo dentro el DHT22, Por lo cual no te sirve de nada leerlo 100 veces en 1 segundo.
Respecto al compilador, C es lo mismo en cualquier compilador, nomas que CCS como te decia tiene algunas cosas que lo hace por detras del usuario, ejemplo con STANDART_IO cada ves que usar output_high/low/a/b/c/d, o input, inserta codigo para cambiarle el estado al pin. Esto lo podes notar cuando queres tener una salida a un valor y luego preguntar el valor de esa salida.
Con STANDART_IO:
output_low(PIN_B0); // Aca lo pone como salida
//... varias instrucciones
if(input(PIN_B0)==0){} // Al usar input, lo convierte en entrada pasandolo a alta impedancia, y no es lo que queriamos hacer
Con FAST_IO:
#use FAST_IO(b)
set_tris_b(0b00000000); // Todas salidas
output_low(PIN_B0); // Aca simplemente cambia la salida
//... varias instrucciones
if(input(PIN_B0)==0){} // Al usar input, esta ves solamente lee el estado de la salida, sin pasarlo a entrada
Otras cosas mas que tambien ocurren creo que es la limpieza de la flag de interrupcion. Al menos estoy acostumbrado a XC8 y esto no ocurre.
