Este artículo está dedicado a una aventura de aventura emocionante que tuve que atravesar en el proceso de crear un sensor externo actualizado para la estación meteorológica descrita
aquí en este artículo hace un año y medio. De acuerdo con la experiencia operativa de la versión anterior, realmente quería crear un sensor con una pantalla de control para que fuera posible verificar periódicamente (y verificar) el componente más caprichoso de la estación: el sensor de velocidad del viento. Las aventuras comenzaron cuando comencé a seleccionar una pantalla para este propósito y, por varias razones, sobre las cuales, me decidí por los productos de mi MELT nativo. Pero antes de continuar describiendo las
técnicas de las formas
sexuales no tradicionales para hacer frente a los productos de esta compañía que he elegido, vale la pena considerar brevemente la razón principal de toda esta grandiosa modernización que comencé.
En los comentarios a ese artículo, me señalaron correctamente sobre el diseño de los sensores que el eje de dicho dispositivo debe tener una punta sólida y descansar sobre una base igualmente sólida (recuerde un reloj de pulsera "en tantas piedras"). Por supuesto, lo sabía, pero no podía pensar en una forma de proporcionar un eje de luz con un punto afilado de suficiente dureza, por lo tanto, por el contrario, tomé el camino de minimizar la fricción sumergiendo una punta de latón (para veleta) o dural (para sensor de velocidad) en un PTFE suave (ver Dibujante en el artículo especificado). En pleno entendimiento, que esta decisión es temporal y de corta duración y en el futuro cercano será necesario llegar a algo más sustantivo.
Sin embargo, el resultado de las últimas dos temporadas de operación mostró que tal solución es bastante adecuada para una veleta, que, por supuesto, aserró la base fluoroplástica al metal con un eje de latón, pero no lo lastimó en absoluto: no se requiere fricción mínima allí, incluso parcialmente al revés. Fue peor con un sensor de velocidad, en el cual no solo se cortó el fluoroplástico en la base, sino también la punta misma de un duraluminio suave borrado de dos milímetros de longitud. Como resultado, en primer lugar, el umbral para comenzar se incrementó inaceptablemente y el sensor tuvo que modernizarse. El anemómetro en sí también se sometió a modernización, ya que el disco compacto láser sobre cuya base se estratificó del sol y adquirió una apariencia desordenada (tampoco sabía anteriormente que los discos compactos constan de dos capas).
Espero contarle más sobre el nuevo sensor más tarde, después de que esté al menos un poco en funcionamiento y pueda asegurarse de que no tenga que modificar nada a la vez (es decir, no antes del comienzo del verano). Y ahora solo algunos detalles sobre los cambios en el circuito de medición, ya que están relacionados con el tema principal de este artículo.
Sobre el circuito de medición del sensor
En relación con la disminución del umbral de inicio, surgió la cuestión del considerable tiempo que lleva medir las bajas frecuencias que provienen del sensor de velocidad (para más detalles, consulte
esta publicación sobre métodos para medir bajas frecuencias). Para no limitar el umbral de arranque artificial, en este caso debemos medir frecuencias a partir de 1-2 hertzios: teniendo en cuenta que el sensor tiene 16 agujeros en un círculo (ver foto del sensor
en el artículo original ), esto corresponde a aproximadamente una revolución en 8-16 segundos, que obviamente es más bajo que cualquier umbral para comenzar. Es decir, el tiempo de espera para esperar la llegada del siguiente pulso de frecuencia debe ser de al menos 1 s (consulte el artículo indicado sobre los métodos de medición), lo que tiene sentido de la historia de ahorro de energía: para obtener un tiempo de actualización aceptable y al mismo tiempo lograr promediar los datos para evitar la charla en la pantalla, Tenemos que activar el controlador cada dos segundos. Y si la mitad de ellos se tomará el tiempo de esperar los pulsos, entonces no habrá ahorro de energía, teniendo en cuenta el hecho de que el LED emisor del sensor ha estado funcionando todo este tiempo, consumiendo aproximadamente 20 mA.
Algunos detalles entre paréntesisObservo entre paréntesis que, en relación con este problema, recordé de inmediato el medidor actual que fue diseñado en nuestra oficina de diseño a principios de los años ochenta, incluso antes de la aparición de todo tipo de controladores. En él se implementó el promedio real de vectores: a saber, la grabación de todas las lecturas fue sincronizada por la señal de la plataforma giratoria del sensor de velocidad, un análogo aproximado del despertar de una interrupción externa. En otras palabras, si no hay corriente, entonces no se realizó ninguna grabación y el circuito no consumió nada: solo funcionaban los relojes en tiempo real. El umbral para el inicio de ese plato giratorio, hecho en forma de
impulsor con flotabilidad cero, era, para decir la verdad, 2-3 cm / seg, y el medidor indicaba la dirección girando todo el cuerpo. ¡Entonces está en el agua, que es 700 veces más densa que el aire! Durante el tiempo promedio, que ascendió a horas, un molinete de este tipo giraba al menos una vez, porque allí casi no había mediciones vacías. Y para una estación meteorológica,
como ya se mencionó , un método de promedio matemáticamente correcto no es adecuado, ya que en ausencia de viento debería mostrar algo real. Por lo tanto, aquí no podemos prescindir de un tiempo de espera artificialmente limitado para esperar pulsos del sensor.
Es posible equipar el control complejo del despertar del controlador desde dos fuentes: normalmente, desde una interrupción externa del sensor de velocidad (es decir, mientras se esperan pulsos del sensor, el controlador también pasa al modo de ahorro de energía), y en ausencia de viento, el Watchdog lo fuerza. Esto tendría sentido solo cuando se cambia el principio de leer el sensor de velocidad de circuitos ópticos a circuitos que consumen menos energía (que aún deben buscarse; el sensor Hall, por ejemplo, consume 5-10 mA, que es fundamentalmente menos que el diseño óptico). Pero todo se simplificó debido al hecho de que mi sensor ahora funciona con una batería solar, lo que me permitió simplemente abandonar el modo de ahorro de energía.
Para ver las lecturas, no me molesté con los temporizadores ni conté Arduino millis (), sino que simplemente configuré un generador de frecuencia externo primitivo con un período de aproximadamente 1.5 segundos en el temporizador 555:
Como recordamos, el circuito del sensor usa el controlador Atmega328 "desnudo" en el paquete DIP, programado a través de Uno e instalado en el zócalo; Arduino se usa solo para la creación de prototipos. La salida del generador se ajustó a la salida de interrupción INT0, pin 4 del microcircuito (pin D2 de la placa Uno). La interrupción de diferencia positiva (RISING) establece un determinado indicador, según el cual se toma la siguiente lectura en el ciclo principal. La frecuencia del sensor también se mide mediante el método de interrupción (la salida del sensor está conectada a la entrada de interrupción INT1, pin 4 (D3), consulte el último método
en el mismo artículo ), porque el tiempo de espera total máximo es el doble del período de la frecuencia medida. Con un tiempo de espera de 1 segundo, la frecuencia mínima medida es de 2 Hz (una revolución del anemómetro en 8 segundos). En cada cuarto ciclo, se produce un promedio y los datos terminados se envían al módulo principal, es decir, las lecturas se actualizan aproximadamente cada 6 segundos.
Toda la historia con un sensor actualizado tendrá que calibrarse y verificarse periódicamente para ver si la fricción ha aumentado, comparando las lecturas con un anemómetro manual. Por lo tanto, es muy inconveniente cuando las lecturas se muestran en un lugar (en la casa) y el sensor externo se instala en un lugar completamente diferente: en la glorieta del jardín. Surgió la pregunta sobre la instalación de una pantalla LCD de control en la carcasa del sensor. Dado que aquí no se requiere belleza, los requisitos de información para ella son mínimos: una pantalla de 10 caracteres de una sola línea es suficiente. Pero los requisitos geométricos son bastante estrictos: la pantalla debe caber en el ancho del gabinete existente, que es de 70 mm. Debo decir que debido a mi aversión orgánica por las pantallas LCD (tenue, de bajo contraste, con letras minúsculas, repugnante calidad de la luz de fondo y también consume mucho, más sobre eso más adelante), casi no soy consciente del rango disponible en el comercio minorista. Y de inmediato quedó claro que las pantallas que necesitaba tenían que ser muy buscadas a la venta: la pantalla LCD estándar de 16x2, que es dominante en las tiendas, tiene una placa de 80 mm de largo y no puede caber en mi sensor, y todos los demás tipos son incluso más grandes, independientemente de la empresa En la naturaleza, por supuesto, hay variedades más pequeñas, pero luego en la naturaleza, y no en el comercio minorista nacional.
Solución: ¡oh, MELT!
Al final, descubrí dos MELT a la vez que encajaban maravillosamente en mi tarea. El primero de ellos es un MT-10S1 de 10 caracteres de una sola línea con un controlador que, según los fabricantes, "es
similar al HD44780 de HITACHI y KS0066 de SAMSUNG ". Tiene caracteres bastante grandes: más de 8 mm de altura, lo que en realidad es característico de las pantallas chinas de tamaños mucho más grandes. El ancho del tablero es de 66 mm, las dimensiones de la pantalla sobresaliente (externa) son 62x19.5. El consumo en este caso no me molesta mucho (porque el sensor externo está alimentado por una batería solar de una potencia obviamente mayor que la necesaria), pero por costumbre, al mirar la línea en la hoja de datos, descubrí que también es más pequeño de lo habitual: 0,7 mA (todas las pantallas LCD comunes) pantallas en análogos de HD44780 consumen desde 1.2 mA y superior). Todavía hay una luz de fondo en el montón, como es habitual para todos estos tipos, bastante miserable y al mismo tiempo consume mucha energía.
La segunda pantalla del MT-10T7 es aún más sorprendente: exactamente en las mismas dimensiones caben 10 dígitos de siete segmentos con una altura de hasta 13 mm. Algunas sospechas fueron causadas por una interfaz no estándar y, aparentemente, una interfaz propia (para la cual el ejemplo de programación en pseudocódigo verbal incluso se da en la hoja de datos). La pantalla no contiene un controlador real: hay un conjunto de disparadores estáticos controlados por lógica combinacional. Pero gracias a esta simplicidad, todo este diseño consume solo 30 μA, es decir, es realmente adecuado para dispositivos que funcionan con batería durante todo el día (el consumo de 1.4 mA en pantallas convencionales e incluso 0.7 mA en MT-10S1 es mucho más alto de lo permitido para tales dispositivos). aplicación del valor: calcule por sí mismo cuánto tiempo funcionará dicha pantalla, incluso sin tener en cuenta los componentes restantes del dispositivo, por ejemplo, de baterías AAA con una capacidad de aproximadamente 1500 mAh).
En resumen, ¡da dos!
MT-10T7
Un intento de reproducir independientemente el algoritmo para MT-10T7, descrito en la hoja de datos (tanto en Arduino como en ensamblador puro), no condujo al éxito. Lo que se hizo mal, no lo entendí, porque me encontré con
esta publicación , donde el autor (eshkinkot) dio un ejemplo muy bien escrito y bien ejecutado del manejo del MT-10T7, después de lo cual todo funcionó de inmediato. Si alguien está interesado,
aquí hay un ejemplo modificado de eshkinkot, complementado con todos los símbolos significativos que son válidos en los indicadores de siete dígitos, incluidas las letras que no coinciden con los números:
En estas imágenes, el contraste de la pantalla se distorsiona ligeramente al configurar el divisor para que produzca Vo - 18 kOhm (a potencia): 10 kOhm (a tierra), aunque sin él el contraste "predeterminado" es bastante aceptable.
Luego agregué al ejemplo indicado una función que reproduce un número arbitrario en la pantalla dentro de tres a cuatro decimales: positivo o negativo, entero o coma flotante, es decir, el número total de caracteres puede llegar a cinco: "-12.7", por ejemplo. Dado que el punto en el código de siete segmentos no ocupa una familiaridad separada, el número máximo de bits que se muestra es 4. Los parámetros de entrada para esta función son: a) una matriz (char buf [5]) que contiene una representación ACSII del número, b) el número real de caracteres que contiene (ii de 1 a 5) yc) la posición (pos de 0 a 9) donde colocar el primer signo (izquierdo) del número (para las funciones y la notación utilizadas en el camino, consulte la publicación indicada por eshkinkot o en el ejemplo por referencia):
Código de funciónvoid writeASCIIdig_serial(char buf[5], byte ii, byte pos)
El módulo MT-10T7 para la salida de control de valores numéricos es más conveniente que las pantallas de matriz de línea ordinarias: tiene dígitos grandes y el punto decimal no ocupa una familiaridad separada y, por lo tanto, puede colocar un carácter más en las mismas posiciones. Pero para mis propósitos es más conveniente si existe la posibilidad de generar letras (de lo contrario, la dirección tendrá que mostrarse en grados de brújula, lo cual es algo inusual). Por lo tanto, para este caso, volví mis ojos a la matriz de una sola línea de tamaño idéntico MT-10S1, que, a pesar de una serie de inconvenientes, migró al diseño terminado. Al mismo tiempo, él ya tiene una luz de fondo, que carece de MT-10T7 (para esto era necesario comprar MT-10T8 de inmediato), y decidí que en este caso su presencia no dolería.
MT-10S1
La pantalla MT-10S1 tiene letras una vez y media más pequeñas, pero también un tamaño bastante decente. Además, su pantalla está económicamente empaquetada en dimensiones generales: no hay contrapartes de importación de 10 dígitos, pero en el Winstar WH1601L (donde los caracteres son incluso un poco más cortos en altura) un milímetro completo es más de un signo de la longitud total del tablero y la pantalla. Bueno, el consumo del controlador está casi a la mitad (en comparación con el mismo WH1601L). En realidad, las ventajas terminan allí, luego comienzan las "características".
El módulo se jacta de que, como ya se mencionó, tiene un controlador compatible con HD44780 de HITACHI. Es decir, debería trabajar con su amado Cristal Líquido sin un estrés excesivo. Además, la página de codificación "predeterminada" coincide con la página en inglés-cirílico de HD44780 y sus muchos análogos, es decir, MT-10S1 debería funcionar con Liquid Crystal Rus sin ningún problema, no se requieren páginas de códigos para que esto se cambie. Y él realmente hace todo esto, pero con matices.
El primer matiz es que en la versión de una sola línea, los desarrolladores aparentemente ahorran en registros, y solo 8 caracteres de una cadena (direcciones 00h - 07h) están en la memoria por registro (los dos caracteres restantes ya están en otro registro (40h-41h). Es decir, la pantalla de facto es de dos líneas, solo ambas líneas están ubicadas físicamente en una línea. Tras un examen más detallado, resultó que lo mismo es cierto para WH1601 (solo allí el segundo registro toma ocho dígitos completos). No está claro por qué se hace de manera tan inconveniente, en general los registros de pantallas de 16x2 son de dieciséis bits, y tal truncamiento apenas hace que el producto sea más barato, más bien, por el contrario, debido a la necesidad de producir diferentes versiones del controlador (si son diferentes, de lo que no estoy seguro). Pensé que estaba asociado con un consumo menor de lo habitual de MT-10S1, pero el mismo WH1601 consume 1.2-1.4 mA, es decir, no es diferente de sus homólogos avanzados.
Bueno, parece que está bien, en Liquid Crystal Rus, se encontraron la función setDRAMModel () y la constante constante LCD_DRAM_WH1601. Para este modo, la biblioteca tiene una traducción de dirección obvia:
if (ac>7 && ac<0x14) command(LCD_SETDDRAMADDR | (0x40+ac-8));
Pero no sé cómo funciona en otras pantallas de una sola línea, y el MT-10S1 se niega completamente a funcionar en este modo: la pantalla permanece en blanco. Como estamos hablando de direccionamiento, no podrá arreglar esto con una simple función autoescrita en la parte superior de la biblioteca, pero no busqué en la biblioteca y descubrí cuál es el problema: ya tengo más de media docena de opciones corregidas de cristal líquido, no quiero producirlas y más lejos
La pantalla del MT-10S1 debe declararse como de dos líneas: lcd.begin (16, 2); (en lugar de 16 puede sustituir 10 o 12, nada cambiará, ya que el número real de caracteres en una línea sigue siendo 8). Un intento de inicializarlo como una sola línea (número 1 en la segunda posición) conducirá a una falla: el fondo se oscurecerá. Y los números de varios dígitos se pueden mostrar solo dentro de 8 caracteres, para líneas más largas, los caracteres extremos más allá de 8 simplemente desaparecerán. Por lo tanto, los caracteres 9 y 10 solo son adecuados para mostrar cantidades auxiliares (unidades de medida, por ejemplo), o necesita dividir el número de línea en dígitos separados, y al ir más allá del octavo carácter, cambie la posición del cursor al primer carácter de la segunda línea.
Para los pacientes
, aquí puede descargar un boceto de prueba para esta pantalla (conexión de cables, en el texto del boceto o en el diagrama a continuación). Por cierto, el contraste (sobre el cual no hay una palabra en el conjunto de datos de fábrica, y la salida de Vo se designa como NC) se ajusta de la manera habitual aquí, pero realmente no necesita hacer esto: en ausencia de retroiluminación, el fondo parece un poco oscuro, pero cuando intenta aclararlo conectando el divisor a la salida de Vo el contraste se pierde notablemente cuando se enciende la luz de fondo.
Interfaz con controlador
Después de verificar que todo funciona como debería, surgió la pregunta sobre cómo conectar todo esto al controlador del sensor. Por supuesto, no había suficientes conclusiones libres para que el controlador del sensor proporcionara control desde él, pero realmente no quería cercar la ciudad con controladores grandes: es más conveniente cuando el sistema es modular y la salida a la pantalla no interfiere con el funcionamiento del algoritmo básico que ya se depuró anteriormente. Quedaba por usar cualquiera de las interfaces seriales.
Esto exige la solución I
2 C basada en PCF8574 (o sus muchos análogos), especialmente porque este chip en sí mismo es solo un registro de desplazamiento engañado, y por lo tanto consume varias decenas de microamperios en el trabajo y menos de 10 microamperios en reposo. Junto con MT-10T7, forman un excelente par para crear dispositivos de baja potencia con indicadores, y MELT incluso tiene una opción preparada para este caso:
MT-10T11 con un consumo total de 30 μA.
Pero para MT-10S1 no existe una solución tan conveniente: por alguna razón, solo las versiones con una configuración 20x4 se suministran con una adición en forma de un análogo de PCF8574 entre las pantallas de línea MELT (
UPD: en los comentarios sugirieron que también hay una configuración MT-16S2H de 16x4 con la misma interfaz, sin embargo , sus dimensiones están más allá de las dimensiones que necesito). El módulo terminado del tipo descrito
en este artículo es incómodo de usar en este caso, ya que la segunda característica desagradable de la pantalla MT-10S1 es su pinout no estándar. Las conclusiones son las mismas (HD44780, sin embargo, más precisamente, su contraparte doméstica, KB1013VG6), pero están ubicadas en un orden completamente no estándar. En aras del interés, verifiqué los importados 16x1 y MELT de dos / cuatro líneas: todos tienen un orden de salida estándar, y el MT-10S1 se destaca en este contexto por alguna razón. Entonces debes tomar una decisión propia.
Como resultado, puse trivialmente el mismo controlador ATmega328 en la pantalla, programado de la misma manera, a través de UNO, y luego insertado en el zócalo en una placa separada, equipado solo con los accesorios necesarios para comenzar: cuarzo con conductores, fuente de alimentación y circuito RC Restablezca la salida (consulte el circuito del sensor
en el artículo original , donde el controlador está conectado de manera similar).
Hablando de reiniciar el encadenamientoPor cierto, sobre el circuito de reinicio: tengo un condensador tan pequeño como 1 μF en la resistencia de varios kOhms, es decir, el tiempo de retraso al encender la alimentación es de unos pocos milisegundos. Cuantas El manual nos enseña que, como para toda la familia Mega, aquí no se requiere una cadena externa, se supone que el circuito interno debe llevar a cabo el arranque correcto, y mucho más rápido. Pero el hábito de poner una cadena RC externa en el pin 1 del controlador para el inicio retrasado cuando lo encendí permaneció conmigo desde el momento de la familia AVR Classic ya olvidada, donde el controlador podría no iniciarse correctamente si el voltaje de suministro no aumentara lo suficientemente rápido. Y en la familia Mega Brown-out Detector puede que no funcione muy bien. En casos críticos, todavía vale la pena instalar un monitor de energía externo, bueno, pero aquí la cadena RC no hace daño a nada, pero puede ayudar en casos con malas fuentes de energía. Los desarrolladores de placas Arduino, por cierto, son muy conscientes de esto, porque en la placa Uno, por ejemplo, existe la misma cadena de 10 kOhm / 100 nF.
Y Dios mismo ordenó que dos controladores AVR idénticos se acoplaran a través de la interfaz serial habitual, que de todos modos, excepto por el proceso de programación, no se usa en ningún otro lugar en este proyecto, y para el uso de los cuales todo ya está a la mano. Por cierto, tal solución no difiere en precio de los componentes basados en PCF8574 y puede competir con ella en términos de ahorro de energía en la variante con MT-10T7, en caso de que el MT-10T11 mencionado anteriormente no esté disponible.
En total, el circuito del módulo MT-10S1 con el controlador es el siguiente (en el diagrama, la designación de las conclusiones de ATmega328 se da entre paréntesis después de las conclusiones de la placa Arduino):
En el controlador, apliqué el modo de ahorro de energía (bueno, sí, no es realmente necesario aquí, pero ¿por qué mantener el chip encendido innecesariamente?). Además, la activación se produce de acuerdo con la señal del mismo generador de onda cuadrada en el chip 555 que el reloj del controlador principal, solo que esta vez a lo largo del borde descendente (FALLING) para separar ligeramente las funciones de medición y transferencia de datos.
El misterio de la naturalezaUn misterio de la naturaleza está relacionado con esto, que no pude resolver. Se sabe que Mega solo puede ser sacado del sueño profundo por una interrupción asincrónica externa, ya que el reloj está apagado y la interrupción sincrónica simplemente no puede suceder. Y toda la familia de controladores AVR de 28 pines, liderando su árbol genealógico desde ATmega8 (48/88/168/328), tiene como tal solo interrupciones de bajo nivel INT0 e INT1 (e interrupción PCINT, pero no se usa en Arduino). Todas las recomendaciones oficiales están relacionadas con esto tanto en los materiales de Atmel como en los sitios de Arduino. El ejemplo en el sitio web arduino.cc dice explícitamente: "
En todos, excepto en los modos de reposo IDLE, solo se puede usar BAJO ". Y esto, por así decirlo, no está en duda, por ejemplo, Monk repite lo mismo con más detalle
en su libro : “
Tenga en cuenta que se selecciona el tipo de interrupción BAJO. Este es el único tipo de interrupción que se puede usar en este ejemplo. Los tipos RISING, FALLING y CHANGE no funcionarán ".
La interrupción a un nivel bajo es muy incómoda de usar, ya que una vez que ocurre, con este nivel más bajo en la salida, ocurrirá una y otra vez, y se deben tomar medidas especiales para deshacerse de los desencadenantes innecesarios. Entonces, hurgando en los foros en busca de varias soluciones a este problema, de repente me encontré con un par de ejemplos de código en los que INT0 del tipo RISING o FALLING se usa explícitamente para salir del sueño. Por supuesto, atribuí esto al analfabetismo de los autores. Pero cuando tropecé
aquí con la frase: "
Aunque puede usar cualquier otro tipo de interrupción (LEVANTARSE, CAERSE, CAMBIARSE), todos sacarán el procesador del sueño ", entonces decidí, a pesar de los enemigos, realizar un experimento en vivo; fue bueno para eso a mano
Y, para mi sorpresa, todo funcionó a la perfección. Modo de ahorro de energía: SLEEP_MODE_PWR_DOWN; debido a la inutilidad, aquí no tomé medidas para reducir aún más el consumo deshabilitando todas las demás funciones, pero aún así el generador de reloj está obviamente apagado. Sin embargo, el controlador se despierta regularmente en el flanco descendente, solicita datos, los muestra en la pantalla y se duerme nuevamente. Para la pureza del experimento, quité el MK de la placa UNO y lo inserté en mi zócalo con el cuarzo conectado, y aún así todo siguió funcionando. Esto se puede ver en el consumo: casi 17 mA en modo normal y 0.9-1 mA con ahorro de energía activado (de los cuales 0.7 mA deben atribuirse a la pantalla).
Sin salir de mi asombro, leí las hojas de datos de Atmel, busqué en el libro de Evstifeev (con su traducción), incluso miré el antiguo manual de Atmel sobre la familia Clásica, luego pasé medio día buscando al menos alguna explicación de lo que estaba sucediendo (tanto en ruso como en ruso). en inglés) en dos buscadores conocidos, pero en ninguna parte no encontramos ni una pista. A menos que sea útil en las Notas de aplicación de Atmel, porque es dudoso que allí se haya publicado algo contrario a las hojas de datos. Seré feliz si alguien que sabe sabe lo que no entiendo.
UPD: la verificación del ensamblador en vivo (ATmega8) mostró el pleno cumplimiento de las hojas de datos, es decir, solo funciona la interrupción de nivel. La única explicación que viene a la mente es que Arduino de alguna manera conectó la interrupción PCINT a una interrupción regular. Un intento de aclarar la situación estudiando el texto de las bibliotecas del sistema Arduino no arrojó nada: allí el diablo se rompería la pierna.
La transferencia de datos desde el controlador del sensor al controlador de pantalla a través de UART se organiza en forma de diálogo. Al despertar, cada cuarta interrupción, el controlador de pantalla solicita datos a su vez:
. . . . . if (flag==1) {
Aquí buft, bufhh, bufss y bufd son matrices (¡no cadenas!) De cinco bytes, que contienen datos sobre temperatura, humedad, velocidad y dirección en forma de descomposición ASCII de los números correspondientes. Para no aceptar demasiado, la configuración especifica un tiempo de espera abreviado para la recepción:
. . . . . Serial.begin(9600); Serial.setTimeout(10);
Es más conveniente mostrar: en primer lugar, inmediatamente tiene la longitud del número recibido y, en segundo lugar, la función Serial.print () envía una cadena ASCII desde el lado del controlador del sensor, con pausas establecidas en los mismos 10 ms entre envíos :
. . . . .
El cálculo de la velocidad en m / s aquí es idéntico al realizado en el módulo principal de la estación (el umbral de inicio se establece al azar en 0.3 m / s) y también deberá cambiarse de acuerdo con los resultados de la calibración.
Si intenta aceptar los datos con el Serial.read () habitual y luego muestra el resultado de la recepción en una pantalla con una función como lcd.print (t, 1), donde t es la temperatura en grados, igual, por ejemplo, a 12.7, luego MT-10S1 en respuesta a esto el comando generará "49.5". Adivinado, o sugerir? Estos son los primeros tres caracteres en la secuencia "49 50 46 55", es decir, en la expansión ASCII del número "12.7". Por lo tanto, es más fácil aceptar de inmediato una matriz de caracteres y mostrar directamente tantos caracteres como se enviaron (el recuento es un contador que aumenta en uno cada interrupción):
. . . . if (count%8==0){
La última línea necesita ser descifrada. El hecho es que los datos de dirección se envían en el código 0-15 (al que todavía se transfieren del código Gray cuando se implementa
el promedio de vectores ). En el caso de la pantalla MT-10T7 de siete segmentos, se tradujeron a grados de brújula:
. . . . . dd=atoi(bufd);
Y aquí podemos escribir directamente en letras rusas, de la misma manera que en el módulo principal de la estación meteorológica (por lo que, de hecho, se eligió esta pantalla):
. . . . . void dir_dd(char dd[]) {switch(atoi(dd)) { case 0: {lcd.print(""); break;} case 1: {lcd.print("C"); break;} case 2: {lcd.print("C"); break;} case 3: {lcd.print("C"); break;} case 4: {lcd.print(""); break;} case 5: {lcd.print(""); break;} case 6: {lcd.print(""); break;} case 7: {lcd.print(""); break;} case 8: {lcd.print(""); break;} case 9: {lcd.print(""); break;} case 10: {lcd.print(""); break;} case 11: {lcd.print(""); break;} case 12: {lcd.print(""); break;} case 13: {lcd.print("C"); break;} case 14: {lcd.print("C"); break;} case 15: {lcd.print("C"); break;} }
Apariencia
La foto muestra la apariencia de la pantalla con el controlador conectado en condiciones de funcionamiento:
Así es como se ve el conjunto del sensor modificado:
Los parámetros de retroiluminación son los indicados en el diagrama anterior. Dado que la caída de voltaje a través de la luz de fondo en los módulos MELT es de 4.5 V, con una fuente de alimentación de 12 V, la corriente de luz de fondo es de 50 mA (como máximo para este módulo de 60 mA).
La carcasa está sellada al máximo para evitar que entre aire húmedo (el marco negro de la pantalla es de la cubierta de goma de un cable delgado). La placa blanca a la derecha es el recinto del sensor de temperatura y humedad SHT-75, sacado de la caja (el sensor se encuentra detrás de él). El cable amarillo de arriba es la antena transmisora de 433 MHz. A la izquierda están los conectores donde están conectados los sensores de velocidad y dirección.
Y así es como se ven las lecturas en la pantalla del módulo principal de la estación meteorológica (el módulo negro con la antena blanca a la derecha es el receptor de 433 MHz):
