Algunas personas que leen mi pregunta pueden estar familiarizadas con una serie de preguntas (la última es esta ) donde he estado preguntando acerca de cómo descodificar datos de un módulo receptor de RF tipo ASK / OOK de banda ISM. Una de las excelentes técnicas que aprendí de una de las respuestas fue usar el cambio de pin para depurar mi programa, usando un analizador lógico. La plataforma uC de mi elección es Arduino (a 20MHz).
Ahora desde mi publicación anterior sería Ten en claro que estaba tratando con la situación en la que los datos válidos recibidos (codificados) se encontraban en un flujo de datos que parecía muy ruidoso con señales de alta frecuencia, y pensé que había encontrado una razón satisfactoria para ignorar la alta frecuencia señales descartándolas en el software si la duración en ese estado fue menor que la de las señales válidas esperadas. Esto pareció ir bien por un tiempo y empecé a hacer algunos progresos.
Al depurar algunos de los problemas a los que me enfrentaba, terminé agregando 5 líneas adicionales al analizador lógico (además de los datos de RF Rx que van del módulo de RF a uC). Estas líneas adicionales alternarían en software basado en varias condiciones de tiempo de ejecución en el programa, s.a. Invocación ISR, cada 100.a invocación del bucle principal (), cumpliendo algunas condiciones, etc. Para mi sorpresa, noté que con esto, mi "ruidosa" línea de datos RF-RX se había solucionado, o más bien en lugar del ruido de alta frecuencia, estaba viendo ruido de baja frecuencia, y las longitudes de las marcas / espacios se han vuelto mucho más largas que las de la señal de datos de RF válida. Así que para validar mi observación, conecté mis líneas de pines de depuración. De paso, la ruidosa charla había vuelto. Calculé la duración del pulso más pequeño y también la duración típica del pulso en ambos casos, y hay un orden de diferencia de magnitud. La observación es altamente repetible.
Mi circuito está en el tablero de pruebas, y estoy usando conectores hechos en casa (entre 6 cm y 15 cm), es decir, el cable de cobre rígido de una hebra, que se encuentra en los cables Ethernet (CAT-5). Las entradas no utilizadas de mi analizador lógico están conectadas a tierra. Es el Openbench Logic Sniffer.
Mi pregunta es, ¿cómo explico esto?
Editar: Gracias a muchos de los consejos, pistas que recibí aquí, creo que he logrado aislar el comportamiento del uso del Pin # 13 en Arduino, aunque no puedo (todavía!) identificarlo, es decir, qué exactamente la razón del comportamiento.
Confirmé mediante varias rondas de pruebas que, si tengo mi lógica ISR () asignada al Pin # 13, s.t. cada vez que se activa una interrupción externa particular (# 0) en el flanco ascendente o descendente, uso el pin # 13 para hacer la forma de onda en consecuencia, es decir, para seguir el estado del pin con la interrupción externa # 0.
Si en lugar del Pin # 13, utilizo cualquier otro pin de E / S digital, observo que el ruido vuelve a ser un ruido de alta frecuencia, pero si uso el pin # 13 para el propósito mencionado anteriormente , luego el ruido regresa al ruido de baja frecuencia.
Leyendo el manual de referencia de Arduino, veo este texto, pero creo que no es relevante, ya que en mi caso el pin está configurado para SALIDA, no ENTRADA.
NOTA: el pin digital 13 es más difícil de usar como entrada digital que el Otros pines digitales porque tiene un LED y una resistencia unidos que se suelda a la placa en la mayoría de las tablas. Si habilitas su Resistencia interna de 20k pull-up, se cuelga a alrededor de 1.7 V en lugar de el esperado 5V porque el LED a bordo y la resistencia en serie tiran del nivel de voltaje hacia abajo, lo que significa que siempre devuelve BAJO. Si debe usar pin 13 como entrada digital, use una resistencia de bajada externa.