Hazlo bien, saldrá mal
La razón de la publicación fue reciente (cuando comencé a escribir esta publicación, era realmente reciente, pero algo sucedió durante mucho tiempo en la carpeta Unfinished) en Habré sobre aspectos de la implementación del software UART en el MK de AVR. Las preguntas planteadas por ellos mismos no carecen de interés, pero se dan respuestas tan extrañas que consideraron que era su deber hacer las explicaciones necesarias. El tema está marcado, aquellos que quieran leer sobre "reyes, repollo y zapatos", es decir, los requisitos de los estándares, leer la documentación técnica (correcta) y los registros en la programación en lenguaje ensamblador para AVR, pueden hacer clic en el botón a continuación.
Esbocemos la pregunta con más detalle: ¿es posible implementar IRPS (el nombre habitual de la interfaz, en nombre de UART), en un AVR tipo MK (específicamente, fue Tiny13) cuando se trabaja desde un generador interno. El hecho es que este generador no tiene muy buenos indicadores de la precisión de retención de frecuencia, por lo que surge esta pregunta. Debo hacer una reserva de inmediato que no importa si consideramos una implementación de software (como se sugiere en la publicación original) o si usamos bloques de hardware MK. Los resultados de un método (en términos de parámetros de precisión en el tiempo) se traducen casi por completo a otro.
La pregunta fundamental es si el generador interno puede proporcionar la precisión de operación requerida, ya que en el caso de una respuesta negativa a esta pregunta, los estudios adicionales no tienen sentido. Para comparar las dos cantidades independientes, necesitamos conocer ambas, por lo que comenzaremos por determinar la precisión requerida del confinamiento de frecuencia y las capacidades proporcionadas por este MK en particular en esta parte. Una observación importante a la oración anterior: esto no significa una instancia específica, "dada a nosotros en sensaciones", sino un tipo específico de MK, que se presenta por su descripción técnica.
Para empezar, encontraremos algo que es más fácil de encontrar (bueno, pensé que sí): requisitos para la precisión de los parámetros de tiempo de la interfaz. Abriremos el estándar para RS232 y veremos todo lo que necesita de inmediato. Resultó que "no puedes tomarlo y ..." porque el estándar está pagado y todas las copias en la Web son ilegales. De acuerdo, llevamos la versión doméstica de GOST a la articulación C2 y no encontramos ningún parámetro de tiempo allí, a excepción de la duración del frente y el corte del pulso. Al principio, esto causó una ligera ráfaga, como podría ser, pero luego se dio cuenta de que la junta C2 describe solo la parte de la interfaz del IRPS y los requisitos deberían estar en la última. En principio, todo es lógico, no está claro solo por qué esto no se describe explícitamente en GOST, sino que, al final, a veces puedes pensar por ti mismo, aunque todavía "de alguna manera no está bien obtenido".
Por supuesto, conociendo el protocolo de transmisión, es posible, por consideraciones generales, encontrar el desajuste máximo permitido entre las velocidades del transmisor y el receptor (0.5 / 9.5 = 5.2%), pero esto será una investigación del caballo esférico que sabe dónde, porque:
- los requisitos de la norma pueden y deben ser más estrictos que un cálculo teórico similar del desajuste máximo permitido;
- conocer la cifra final de desajuste de ninguna manera nos dará el presupuesto del transmisor y el receptor.
Vagar por Internet condujo a la AppNote de Atmel (bueno, ya que todavía usamos el MK de esta compañía), que habla explícitamente de un desajuste permisible del 2% con un presupuesto igual, lo que lleva al requisito de precisión de mantener la frecuencia del transmisor del 1%. Confiaremos en una empresa de buena reputación y supondremos que tienen acceso a materiales clasificados y esta cifra es correcta, especialmente porque parece plausible. Entiendo la vulnerabilidad de tal posición, pero para ser honesto, estoy cansado de buscar la respuesta exacta a una pregunta tan simple, y no puedo esperar para pasar a la siguiente parte.
La siguiente mitad de la respuesta se encuentra dentro del MK y está determinada por la documentación técnica correspondiente. Primero, un poco sobre el dispositivo del generador interno, especialmente porque está más o menos descrito. El generador utiliza una cadena RC como elemento de temporización y, dado que la tarea de formar un condensador integrado de un condensador exacto y una resistencia exacta, es muy no trivial, la frecuencia final de una instancia a otra del MC variará significativamente. Para hacer que este parámetro sea más predecible, los fabricantes agregaron un nodo de hardware controlado a través de un byte de calibración. Esta unidad le permite cambiar la frecuencia del generador en un amplio rango y, en consecuencia, obtener el valor deseado con mucha mayor precisión.
Sería interesante saber exactamente cómo se implementa el control en el hardware, veo una opción ya sea con controlar el voltaje de carga del condensador a través del DAC o controlar el voltaje de comparación en el comparador. Sin embargo, ambas opciones conducen a una no linealidad significativa de las características de control, aunque son simples de implementar. Pero establecer la implementación interna del generador no es parte de nuestra tarea, estamos interesados en sus parámetros externos.
Así que abrimos la documentación (puede abrir el archivo en el visor, pero tengo una versión tipográfica de la descripción impresa por el propio fabricante, sí, solía ser) y buscamos la sección correspondiente. Los parámetros que nos interesan están en la sección "Oscilador RC interno calibrado", luego siga los enlaces si es necesario. Y aquí nosotros (por supuesto, no estoy seguro de ti) estábamos esperando la primera decepción: he estado trabajando con productos Atmel durante mucho tiempo (unos 15 años) y siempre he creído que tienen buena documentación para MK. Según los psiquiatras, "no hay personas sanas, no hay personas inexploradas" y un estudio cuidadoso de la sección relevante confirmó esta verdad, ya que no pude notar tales fallas en la documentación antes. En mi defensa, solo puedo decir que:
- Nunca utilicé un generador interno en los datos de MK, por lo que no lo estudié con especial cuidado;
- cuando comencé a trabajar con estos MK (hace mucho más de 10 años) era joven (bueno, definitivamente más joven que ahora) y estúpido y no entendía completamente la necesidad de una buena documentación (comprensible, exhaustiva y sin ambigüedades);
- Estoy listo para perdonarme mucho, simplemente porque me perdono mucho a mí mismo, y todas mis deficiencias no son fatales (el último argumento es especialmente convincente, ¿no?).
Entonces, después de terminar de sacudirme la cabeza con cenizas, comenzaré a presentar mis reclamos a la documentación y no puede haber excusas para el fabricante. Abrimos la sección anterior y comenzamos a estudiarla detenidamente, yendo a las páginas necesarias si es necesario (aún hace clic en los enlaces). Juntos buscaremos los siguientes parámetros que caracterizan las características de tiempo del generador: precisión nominal, influencia del voltaje de alimentación, influencia de la temperatura y parámetros de envejecimiento: este es el conjunto mínimo necesario para evaluar los parámetros de precisión de cualquier generador.
La primera parte del ballet Marleson es la precisión nominal.
Inmediatamente encontramos el parámetro deseado: la tabla de precisión de sintonización del generador, en la que vemos dos líneas "Calibrado de fábrica" con el valor especificado ± 10% y "Calibración manual" con el mismo parámetro ± 2%.
Con respecto a estos datos, surgen inmediatamente una serie de preguntas: qué significan y cómo son las mediciones de este parámetro. Para la primera fila, la tabla indica la temperatura (del entorno o de la propia MK, no está claro, pero esto es un capricho de mi parte) y el voltaje de suministro, además, la nota dice (en mi opinión, es innecesario) que esta medición se lleva a cabo en un punto específico en el espacio condiciones externas Uno puede adivinar que en este caso deberíamos usar el factor de calibración registrado en el fabricante, aunque sería mejor indicarlo explícitamente en la nota. Todo está más o menos claro y se interpreta de manera casi inequívoca (aunque en el contexto del estudio de la documentación técnica se debe decir que todo es confuso y permite variaciones en las interpretaciones, y esto es inaceptable, pero si lo hacemos, el tema de discusión adicional simplemente desaparece (y lo que sigue) escribir, no está claro, por lo tanto, mostrar indulgencia).
Pero con la segunda línea del caso, es peor: se dan los límites de los cambios en la temperatura y el voltaje de suministro y se argumenta que al usar algún tipo de procedimiento de calibración mágica puede lograr significativamente mejor que el resultado de fábrica en todo el rango. Mi pregunta surge de inmediato: si esto se puede lograr en todas partes (en cualquier punto de la temperatura y la fuente de alimentación) y el fabricante sabe cómo hacerlo, entonces ¿por qué no lo hizo ella misma en la calibración de fábrica en un punto específico de las condiciones? Pasamos a la descripción del byte de calibración y vemos que toma 128 valores y esto cubre el rango del 50% al 200% del valor nominal, que corresponde a 150/128 ~ 1.17% del cambio de frecuencia por valor de calibración de la unidad, lo que debería dar la precisión esperada mejor que en 1% Pero entonces deberíamos tener en cuenta que la característica de ajuste claramente no es lineal y en la región de valores de calibración grandes tenemos 60% / 32 ~ 2% del paso (datos tomados del gráfico, he expresado repetidamente mi actitud hacia un método similar de representación de parámetros técnicos, pero repito: esto es inaceptable el método, aunque, por supuesto, es mejor que nada), que proporciona una precisión del 1% y si tenemos en cuenta la monotonicidad de la característica de ajuste (sí, eso es lo que dice la documentación, no está dibujada en el gráfico, pero está claramente indicada en el texto. Me niego categóricamente a entender a a, y lo más importante por qué, la compañía quería que sea una ley de ajuste, pero logró), que queda bien claro en las directrices, es necesario tener en cuenta la precisión del 2% es muy fácil de lograr. Realmente no me gusta que haya tenido que mirar el gráfico, pero esto no es necesario y los datos tabulares son suficientes. En esta parte, la documentación debe considerarse completamente comprensible y consistente, el criterio de corrección se encuentra fuera del alcance de nuestra competencia.
La segunda parte del ballet Marlezon. - La influencia de las condiciones externas.
Y luego comienza "basura, humos y sodomía". En lugar de tablas de valores, estamos invitados a mirar imágenes (por alguna razón se llaman gráficos de valores típicos en la documentación) y, como saben, "la principal ventaja de la representación gráfica de la información es su visibilidad, y no tiene otras ventajas". Sería posible utilizar incluso dicha información y eliminar los valores límite del gráfico ("aunque esto sea ofensivo para el equipo") si este gráfico no se proporcionara en la sección "Características típicas". No sé cómo alguien, personalmente, estoy profundamente convencido de que indicar significados típicos (o típicos, no sé cómo ser más correctos, en una película decían "apariencia típica"), al menos en forma de gráfico, incluso en la tabla, simplemente no indica nada. No pueden guiarse en el diseño, porque estos parámetros no tienen claro qué significan y cualquier desviación de los valores típicos es aceptable, en contraste con los valores mínimos y máximos, cuya transición indica un mal funcionamiento del dispositivo.
Bueno, hemos pasado, trataremos de extraer al menos algo de información y veremos que cuando la temperatura cambia de -40 a + 80 ° , la frecuencia del generador cambia en un ± 4%. Una imagen similar con el voltaje de suministro: solo gráficos típicos y el error resultante en -6 + 2% de 3.3 a 5.5. Los datos sobre el envejecimiento del generador simplemente no se dan, lo que, en general, es lógico, ya que en el contexto de los parámetros ya dados, la precisión del uno por ciento durante 5 años (un valor característico para el silicio) no molesta a nadie.
Ahora tenemos todos los datos para responder a nuestra pregunta inicial: durante la calibración de fábrica, el generador no cumple con los requisitos de precisión de la interfaz, cuando se calibra para condiciones de aplicación específicas, cumple con los requisitos de límite, pero no cumple con el estándar. También se debe tener en cuenta que si se puede calibrar el voltaje de suministro y un MK específico en la fabricación del dispositivo y esperar que no cambien a tiempo, entonces la temperatura solo se puede tener en cuenta sobre la marcha y requiere un estándar de tiempo externo de precisión adecuada. Dado que el desarrollo de dispositivos debe guiarse por la regla "creemos en Dios, todo lo demás requiere pruebas", y no hemos demostrado la posibilidad de cumplir con los requisitos, la respuesta correcta es que es imposible garantizar la implementación de IRPS que cumpla con los requisitos de la norma en este MC con un generador interno. Tenga en cuenta que llegamos a la conclusión anterior al analizar la documentación y la formulamos de tal manera que enfaticemos que en una instancia específica de MK todo puede y resultará si las estrellas se elevan con éxito. Es decir, nuestra conclusión contradice la publicación mencionada anteriormente, ¿cómo podría suceder esto, porque todo funciona muy bien para una persona? Vamos a resolverlo.
Ahora comenzará la crítica de la publicación anterior. Primero, pensemos en cómo podemos asegurarnos de que se verifique que el dispositivo cumpla con los requisitos de una interfaz en particular. Puedo sugerir las siguientes formas:
- Una buena manera es medir los parámetros críticos de la interfaz del dispositivo y compararlos con los requisitos del estándar; esto se puede hacer utilizando instrumentos universales (en nuestro caso, el osciloscopio y la longitud del intervalo de bits o la transmisión completa), o utilizando un dispositivo especializado certificado para probar esta interfaz.
- Modo regular: para organizar la interacción con otro dispositivo que implementa la parte de respuesta de la interfaz y está probada (cumple con los requisitos del estándar). Por supuesto, tal verificación es completamente insuficiente, y más bien, se puede aplicar más para confirmar el mal funcionamiento del dispositivo bajo prueba, pero al menos hace algo.
- La mala manera es implementar independientemente la parte de respuesta de la interfaz (en el mismo dispositivo o en otro) e interactuar con ella. Dado que ambos dispositivos obviamente no están probados, la utilidad de tal verificación es muy, muy dudosa. Un buen ejemplo de este enfoque es el "eco" en un canal serie, que no prueba nada e informa poco más que nada sobre la velocidad del dispositivo, en principio, no está roto y es capaz de transmitir algo de alguna manera.
- Una forma terrible es tomar como probador un dispositivo que no cumple con los requisitos del estándar (o más bien, que los contradice) y funcionar como en el párrafo anterior.
Es el último método que se utilizó en la publicación que se está considerando: se implementa un receptor de software de canal en serie que, contrariamente a los requisitos del estándar, cambia su frecuencia para adaptarse a la señal de entrada (específicamente, la longitud del bit de inicio), lo que permite una recepción estable de una señal de baja calidad en términos de parámetros de tiempo. Esto no quiere decir que esto nunca deba hacerse, además, en los módems analógicos, se adoptó el ajuste para la velocidad entrante, que se implementó de manera similar, pero fue precisamente cambiar la frecuencia al cambiar el divisor, y claramente este no es nuestro caso. Y es en esta versión que todo se obtiene perfectamente y la información se transmite de manera estable bajo cualquier condición externa. Por lo tanto, si hablamos de la posibilidad de transmitir información entre dos MC que funcionan desde generadores internos utilizando una interfaz que recuerda remotamente a IRPS, entonces la respuesta es sí. Si hablamos de interactuar con dispositivos externos que cumplen con los requisitos del estándar y nada más, entonces esperaremos muchas sorpresas desagradables.
La conclusión general de lo anterior:
- al diseñar dispositivos, debe centrarse en la documentación (RTFM),
- necesita estudiar la documentación e interpretar correctamente lo que lee (RTFMF),
- tenga en cuenta que en nuestro tiempo la documentación puede ser malentendidos, imprecisiones (e incluso errores), por lo tanto
- verificar la información recibida para obtener consistencia y credibilidad, y
- use la información obtenida experimentalmente solo para confirmar las conclusiones obtenidas del análisis de la documentación, mientras
- elija cuidadosamente los métodos de experimentos para probar equipos para obtener un resultado confiable.
Bueno, en conclusión, como se prometió, un pequeño ensamblador. Me permití reescribir el fragmento de código citado por el autor en forma normal, porque el ensamblador integrado en GCC no es más que una burla del programador, puedo nombrarlo. No, por supuesto, entiendo que los desarrolladores del compilador se guiaron por buenas razones, pero el resultado se parece mucho a la frase "bueno, funciona".
.equ delay=15 TX_Byte: cli ; ld r18,Z+ ; cp r18,r1 ; breq Exit_Transmit ; dec r1 cbi port, TX_line Delay_TX: ldi r16,delay Do_Delay_TX: nop dec r16 brne Do_Delay_TX TX_Bit: sbrc r18,0 sbi port,TX_line sbrs r18,0 cbi port,TX_line lsr r18 lsr r17 brcs Delay_TX sbi port, TX_line ldi r16,delay Stop_Bit_TX: nop dec r16 brne Stop_Bit_TX Sei
E inmediatamente un error en el programa llama la atención: en la línea 3 (comentada) el valor del registro 1 debe ser cero, pero la asignación no está explícitamente escrita en la función. Después de completar un ciclo de transferencia de un solo byte, este valor está garantizado por la línea 12, pero no en la primera pasada. Por lo tanto, se debe agregar la inicialización, lo que requerirá un aumento en el tamaño del código.
El segundo inconveniente es la formación real del nivel en las líneas 4-7, ya que el método adoptado por el autor para emitir el siguiente bit conducirá a fluctuaciones frontales durante 2 ciclos de reloj en diferentes transiciones (0-1 y 1-0), lo que implicará un aumento en los requisitos para la precisión de mantener la frecuencia. No es que esto tenga una influencia muy fuerte, pero si puede corregir una falla sin extender el programa, entonces, ¿por qué no? Vea el epígrafe. La versión original tomó 4 palabras y se realizó en 4 medidas, la nueva tomó 4 palabras y se realizó en las mismas 4 medidas. Sí, la versión corregida requiere un estudio más profundo de la arquitectura MK, pero quién dijo que sería fácil. Por otro lado, en la primera versión, la modificación del puerto es atómica, y en la segunda no lo es, en este caso no importa (prohibimos explícitamente las interrupciones), pero el sedimento permanece. Si el MK en cuestión tenía un procesador de bits real, como en la arquitectura 51, entonces podríamos escribir un fragmento ideal que combine todas las ventajas de ambos enfoques (e incluso ser un poco más corto), pero ¿qué podemos soñar con un sueño imposible?
El tercer inconveniente es la cuestión de más estilo. Repetidamente he expresado mi actitud hacia las constantes mágicas que vemos en el preámbulo de este programa. Destaco una vez más: por el hecho de que el autor establece una constante en el preámbulo del programa y no directamente en el operador, la "magia callejera ordinaria" no va a ninguna parte. El hecho es que debemos presentar explícitamente al lector el método de formar un valor específico, y no crear un sinónimo del valor obtenido de una manera desconocida. Por supuesto, puede escribir un comentario en una línea con un valor para especificar la fórmula de cálculo, pero es mejor usar explícitamente la fórmula de cálculo para formar la constante y luego simplemente no necesita un comentario (por supuesto, con los nombres de las constantes aplicadas). Esto se hace en el texto a continuación, y tenga en cuenta que convertimos a un número entero solo en el último momento y redondeamos correctamente, lo que nos permite no perder la precisión del resultado.
Hay otro error: la longitud del bit de inicio es algo diferente del intervalo de bits para los datos. Aunque la desviación no es demasiado significativa (3 ciclos de reloj), sin embargo, a altas velocidades de bits, donde el intervalo de bits dura aproximadamente 90 ciclos de reloj, esto ya es un pequeño porcentaje de error, lo cual es inaceptable. Este error puede corregirse fácilmente agregando comandos para generar un retraso adicional, pero esto aumentará la duración del programa, por lo que solo corregiremos su presencia y luego nos aseguraremos de que la arquitectura correcta del programa (es decir, incluso este corto plazo se aplique) se elimina automáticamente.
Bueno, ahora que hemos solucionado los errores (excepto el último), intentaremos mejorar el programa en el sentido del criterio principal (para lograr un registro, en este caso particular): la longitud del código. Lo primero que llama la atención es la presencia de dos retrasos, lo cual es malo porque viola el principio DRY (requisito general) y aumenta el tamaño del código (requisito específico). Sería posible organizar este fragmento en forma de una subrutina y aún así ganaríamos en longitud, ya que agregamos 3 palabras de código (1 para cada llamada en dos lugares y 1 para la devolución), y guardamos 4, pero hay una manera mucho más hermosa: ordenada La organización del ciclo de transmisión de bytes, que se puede ver en el siguiente texto.
.equ delay=15 TX_Byte: cli sec ; - clt ; - TransBit: ; in r17,port bld r17,Tx_line out port,r17 Delay_TX: ; ldi r17,delay Do_Delay_TX: nop dec r17 brne Do_Delay_TX TX_Bit: bst r16,0 ror r16 clc brne TransBit ; brcs TransBit ; - Exit_Transmit: Sei
Observe cómo usamos el byte transmitido junto con el bit de acarreo como un contador de bits, una solución hermosa, pero tiene un inconveniente: la duración del último bit de datos será varios (2 ciclos) más larga que el resto, debido al retraso de la transición. Si estuviéramos hablando de un bit de parada, entonces "no nos importa un comino y olvidamos", ya que no se nos ha dado el intervalo mínimo entre transferencias, pero este es un bit significativo, y acabamos de criticar el programa original por tal comportamiento. No seremos comparados con el carácter bíblico de la parábola de la mota a los ojos de los demás y tomaremos medidas para eliminarlo. Este fenómeno podría compensarse fácilmente mediante la introducción de un retraso de 2 medidas, pero la longitud del código aumentará, y este es un parámetro clave. Por lo tanto, sigamos el camino clásico y cambiemos el tiempo de la memoria: utilizamos un registro separado para organizar el contador de bits transmitidos, y obtenemos exactamente los mismos intervalos de bits con el mismo tamaño de código.
La siguiente mejora está asociada con la formación de la duración del intervalo de bits, que en el programa original se realiza en un ciclo de 4 ciclos. Si hacemos 3 horas (la más pequeña posible en este MK), podemos guardar un byte de código y potencialmente podemos mejorar los parámetros de precisión, ya que la discreción de la demora será menor (la desviación no excede la mitad del tamaño del discreto con el redondeo adecuado). Pero debe tenerse en cuenta que, en un caso particular, podemos perder precisión, todo depende de los datos de origen. Otra circunstancia que podría afectar la elección de tal duración de ciclo: el tamaño máximo de retraso para un contador de bytes es de 256 valores; para la opción disponible, puede usar velocidades de 9600 baudios y más, pero con un retraso de 3 ciclos esto no es posible. Sería muy agradable reflejar esta circunstancia (la velocidad de puerto mínima permitida) en los comentarios al programa y al mismo tiempo mostrar un mensaje de advertencia en caso de incumplimiento de este requisito. Bueno, haga las modificaciones apropiadas a las macros de formación de parámetros para formar un retraso, sin olvidar usar nombres "parlantes" para indicar variables.
.equ Freq = 8000000 .equ BaudRate = 115200 .equ PayLoad = 9 ; .equ CycleTime = 3 ; .equ delay=((Freq*2/BaudRate - PayLoad*2)+CycleTime)/(CycleTime*2) TX_Byte: cli ldi r18,10 sec ; - clt ; - TransBit: in r17,port bld r17,Tx_line out port,r17 Delay_TX: ldi r17,delay Do_Delay_TX: dec r17 brne Do_Delay_TX TX_Bit: bst r16,0 ror r16 dec r18 brne TransBit Exit_Transmit: sei
Ahora veamos el resultado: el tamaño del código disminuyó de 20 a 16 palabras (si tomamos en cuenta solo la transmisión en sí, entonces aún más sorprendente: de 18 a 14, desapareció la fluctuación de los frentes (por supuesto, solo el componente de fluctuación de fase, que es causado por las características del programa, en el componente de hardware, nosotros no estamos infringiendo), la precisión del mantenimiento de los intervalos de tiempo ha mejorado, el programa se ha vuelto más visible y más fácil de entender (debido a los comentarios, ya que incluso un programa ensamblador bien escrito generalmente no está auto documentado).
La conclusión de la última parte es que si vamos a establecer récords mundiales en la programación en lenguaje ensamblador, entonces debemos estudiar la arquitectura de un MK particular muy profundamente y aplicar el conocimiento obtenido para obtener el resultado ideal, prestando atención a todas las sutilezas.
Bueno y, en conclusión, la tarea de escribir código del tamaño mínimo hoy en día parece algo artificial, pero, de manera inesperada, recibe la confirmación de su vitalidad. A finales del año pasado (2016, este es el tiempo que esta publicación ha estado esperando su turno), se anunció un nuevo MK de la familia MSP430, que junto con el precio excepcionalmente bajo (26 centavos, estamos esperando la aparición de dispositivos chinos basados en él) también tiene un tamaño de memoria de programa excepcionalmente pequeño: 512 byte (no, no me equivoqué, la letra "k" inmediatamente después del número no lo es). Por lo tanto, el tamaño del código puede resultar crítico cuando se usa este dispositivo, y en general escribir programas tan extremos requiere un estudio en profundidad de MK, y "el trabajo en sí mismo es una bendición".