Don Eyles nos explica el código fuente del módulo lunar

Hace unas semanas estaba en una fiesta donde con mi ojo noté cómo se ve una guía telefónica gigante sentada abierta sobre una mesa. Estaba impresa con papel perforado verde y blanco encuadernado en una carpeta, cuya cubierta se veía un poco peor por el desgaste. Miré más de cerca con mi amigo James Kinsey. Lo que leímos fue asombroso; Programa 63, 64, 65, descenso y aterrizaje lunar. Códigos de error 1201, 1202. Comentarios impresos en el código, segmentos de código marcados con un círculo apresuradamente con un bolígrafo. ¿Es esto lo que pensamos que estábamos viendo? ¿Y quién trae esto a una fiesta?

Observamos lo que se dice que es la única copia en papel que queda del código fuente del Módulo Lunar. Este es el libro de código fuente utilizado por Don Eyles durante las misiones Apollo y para el desarrollo. Don fue responsable de escribir un código para el Módulo Lunar, específicamente alrededor de 2000 líneas que realmente llevaron a un hombre a la luna. Apareció en el Club de Docentes del MIT en junio y trajo esta impresión original, por supuesto, en su propia maleta.

Cómo funciona

Tanto el Módulo de Comando de Apolo (CM) como el Módulo Lunar (LM) fueron los primeros aviones de vuelo por cable de la humanidad. Esto significa que el hombre no lo vuela realmente a mano con un palo, la computadora es la que controla el acelerador, los controladores, el cardán (que son servomotores que controlan la dirección de los controladores más grandes), en tiempo real. Esto se hizo por necesidad. La gente no podía volar estas naves espaciales a mano, especialmente el LM durante el descenso, que era muy inestable.

Una página por milisegundo

El núcleo del sistema era el Apollo Guidance Computer (AGC). Sistema operativo en parte en tiempo real, en parte Sistema Nacional de Adquisición de Datos Instrumentales, el AGC era una computadora de múltiples subprocesos y un sistema de control de retroalimentación en comunicación con todo, desde radares hasta telescopios, giroscopios y acelerómetros que controlaban motores espaciales masivos y realizaba todas las tareas en tiempo real. . Muchos programas compartían ciclos de CPU, un programa ejecutivo rastreaba y priorizaba todo. Puede leerlo usted mismo, el mejor libro sobre este tema es Digital Apollo.

Don amablemente nos guió a través de un recorrido por el código, donde explicó los problemas con varias misiones y cómo se resolvieron en el código. Un ejemplo fue un problema con las respuestas de frecuencia de un motor LM. El fabricante no especificó una función de transferencia precisa para el acelerador del motor, lo que provocó que el sistema fuera inestable. Recuerde, este es un sistema de control de retroalimentación, esto sería equivalente a no conocer la respuesta de frecuencia en el circuito de salida de un amperio de observación.

Los códigos de error que mencioné anteriormente (1201, 1202 y así sucesivamente) se mostraron durante el aterrizaje del Apolo 11. Estos hicieron que Neil Armstrong se pusiera muy nervioso durante la última parte del aterrizaje lunar. Don explicó que estos errores se debían al radar del acelerador. Desafortunadamente, este escenario nunca se ha simulado ni practicado in situ.

El radar del garaje envió muchas interrupciones al procesador quitando ciclos preciosos que llevaron al AGC a advertir a Neil Armstrong que está sobrecargado y que detendrá algunos programas no esenciales. Los programas esenciales, como volar y mantener la estabilidad del LM y la navegación, permanecieron, los programas no esenciales, como la actualización de DSKY, se pausaron.

Aunque la imagen en el video a continuación a veces puede ser borrosa, escuche lo que Don tiene que decir donde brilla. Además de los ejemplos anteriores, menciona tantos detalles interesantes como la regla del dedo durante el desarrollo del código; cada página de código necesita aproximadamente 1 ms de tiempo de CPU. En este clip, Dana Yoerger hace la mayoría de las preguntas.

Años setenta: ¡Un nerd de aspecto extraño salva al Apolo 14!

Don era un rebelde que trabajaba para el complejo industrial militar sabiendo que estaba ayudando a un objetivo más grande, que era la primera vez que ayudaba a la humanidad a aterrizar en otro mundo. Esta pieza de la revista Rolling Stone de 1971 ofrece una perspectiva fascinante de lo que motivó a piratas informáticos como Don a finales de los sesenta.

Es realmente espectacular conocer a ingenieros de estos proyectos de cambio mundial y escuchar lo que tienen que decir. Si usted es uno de esos ingenieros, o puede conectarnos con uno, no dude en ponerse en contacto a través de la línea de asesoramiento de artículos.

Código fuente muy pesado

No oculté mi entusiasmo por esta lección de historia. Creo que por eso Don me preguntó si quería devolver el código a su coche. Estaba bromeando, pero aproveché la oportunidad para abordar un artefacto que se sellará detrás de un vidrio y se exhibirá en un museo tarde o temprano. El código fuente era muy pesado, tuve que intercambiar armas unas tres veces durante un viaje de solo dos cuadras de la ciudad.

De izquierda a derecha; James Kinsey, Dana Yoerger, Don Eyles, Gregory L. Charvat. En primer plano, es posible la última copia en papel del código fuente del Módulo Lunar.

Como muchos participantes en el programa Apollo, Don es muy agradable, de buen corazón, no se jacta de sí mismo y es reacio a aceptar el crédito. Esta es una actitud refrescante en una era de reality shows y autopromoción. Pronto aprenderemos más, preste atención al libro de Don, que se publicará durante el próximo año.

Biografía del autor: Gregory L. Charvat aprovecha cada oportunidad para aprender de aquellos que han participado en el programa Apollo. El autor de Greg se puede encontrar aquí.

  • CJ Rose dice:

    ¡Umph! O en un lenguaje sencillo: esto es algo con lo que me encantaría tener un contacto práctico y poder leer con mis propios ojos ... Gracias por este artículo.

  • Circuito más corto dice:

    Siempre es reconfortante ver a personas que se han ganado el derecho a ser humildes. Es fascinante escucharlo, y tengo el libro AGC de 430 páginas 🙂

  • Hirudinea dice:

    Dado que la mayoría de nosotros nunca podremos poner nuestras manitas sucias en esto, ¿hay una copia en línea de este código fuente? Además, el Avro Arrow tenía un sistema de pre-vuelo frente a Apollo, solo decía.

    • codewritinfool (@codewritinfool) dice:

      http://www.ibiblio.org/apollo/links.html#Software_manuals_and_listings
      ... es solo uno de los recursos en línea.

    • lwatcdr dice:

      El Arrow tenía un sistema analógico no digital, más o menos simplemente reemplazaba el sistema hidráulico por cables. Apollo tenía un sistema FBW digital.

    • Gregory L. Charvat dice:

      Está en github, le di un enlace en el texto.

    • Farrell McGovern dice:

      Y recuerde, cuando se canceló el Avro Arrow, muchos de los mejores ingenieros de Avro fueron reclutados por la NASA y ayudaron a formar el núcleo del Programa Espacial de EE. UU. Recomiendo el libro de Chris Gainor "Arrows to the Moon" para una mirada en profundidad.

      Wikipedia también dice:
      Tras la cancelación del proyecto Avro Arrow, el aerodinámico jefe del CF-105 Jim Chamberlin dirigió un equipo de 25 ingenieros del Grupo de Trabajo Espacial de la NASA para convertirse en ingenieros en jefe, programadores e ingenieros en jefe en los programas espaciales tripulados de la NASA: Mercury, proyectos Gemini y Apollo.[93] El equipo del Space Task Group finalmente creció a 32 ingenieros y técnicos de Avro, y se convirtió en un emblema de lo que muchos canadienses vieron como una "fuga de cerebros" a los Estados Unidos.[93] Entre los antiguos ingenieros de Arrow que se dirigían al sur estaban Tecwyn Roberts (el primer oficial de vuelo dinámico de la NASA en el Proyecto Mercury y luego director de redes en el Centro Espacial Goddard) John Hodge (director de vuelo y administrador del proyecto Space Freedom cancelado), Dennis Fieldman (director del Fuerza de Tarea de la Estación Espacial, más tarde la Estación Espacial), Owen Maynard (jefe de la oficina de ingeniería de LM en la Oficina del Programa Apolo) y Rod Rose (asistente técnico del programa del Transbordador Espacial). "

  • Quinn Dunki dice:

    No olvidemos a Margaret Hamilton, la increíble ingeniera de software que dirigió el equipo que escribió ese código, y el resto de aproximadamente medio millón de líneas de código en Apollo.

    • gg dice:

      Antes de mencionar a Hamilton, ¿por qué no a Laning y Klumpp? Quiero decir, antes de lanzar nombres al azar, es posible que primero tenga que ocuparse de las personas más estrechamente asociadas con el resultado.

      • Onz dice:

        Vea esta historia de 1979 de los sistemas de navegación y guía integrados de Apollo por el director técnico del Laboratorio de Instrumentación del MIT, David G. Hoag: http://klabs.org/history/history_docs/mit_docs/1711.pdf

        Específico (p18-19):

        > Partes de la programación de computadoras se lograron temprano y esencialmente independientes de los objetivos de la misión. Estos incluían el código básico para el sistema operativo de la computadora, el control secuencial, las estructuras de temporización e interrupción, sin cambios desde el diseño original del Dr. Laning, y la gestión de las interfaces con la pantalla de la computadora y la unidad de teclado, telemetría, etc. estaba
        las complejas pero no críticas rutinas de procesamiento de datos de navegación, orientación de orientación, extrapolación de trayectorias y cálculos de efemérides lunares. Gran parte de la base analítica y algorítmica proviene del trabajo anterior de Battin para los estudios de misiones espaciales no tripuladas. Para Apollo, el Dr. Battin, el Dr. James Miller y Norman Sears, y otros analistas, han logrado mejoras significativas en la efectividad y el desempeño de estas rutinas, muchas de las cuales han tenido un significado fundamental.

        ...

        > Los primeros programas para los primeros vuelos de prueba orbitales terroristas no tripulados fueron elaborados por un pequeño grupo dedicado dirigido por un ingeniero programador jefe. Para el primer vuelo del módulo de comando, Alex Kosmala pasó muchas semanas de largas horas liderando el diseño y codificación del programa CORONA. Asimismo, el gran esfuerzo personal de Daniel Lickly produjo el programa SOLARIUM. Cada uno de estos fue un recorrido maravilloso que no fue práctico para las misiones pilotadas más complejas. Cada una de estas misiones posteriores recibió la responsabilidad de un ingeniero superior que asumió una función administrativa más técnica para el programa.

        > La tarea fue, en primer lugar, dividir el trabajo de manera adecuada para los analistas, redactores de especificaciones, programadores, ingenieros de pruebas y especialistas en documentación. El líder estableció cronogramas e hitos de progreso, reasignó recursos para resolver problemas inevitables y, en general, fue responsable de la calidad del programa. Los nombres notables aquí son Dr. James Miller para el primer programa SUNBURST del módulo lunar, Dr. Frederic Martin para el programa Command Command Modus COLOSSUS y George Cherry para el programa Lunar Module LUMINARY. Estos dos últimos fueron los programas utilizados para las misiones de alunizaje. Martin y Cherry también jugaron un papel importante
        del diseño de las funciones de control de vuelo eléctrico para estos programas. Alan Klumpp ha hecho importantes contribuciones al programa de aterrizaje
        en el Módulo Lunar. Daniel Lickly estableció el proyecto de entrada atmosférica para el Módulo de Comando.

        > Gran parte del código detallado de estos programas fue escrito por un equipo de especialistas dirigido por Margaret Hamilton. Las asignaciones de tareas a estos las personas incluyeron, además de escribir el código, las pruebas para certificar que el elemento del programa cumplía con los requisitos. La prueba general de la colección compuesta de elementos de software necesariamente requirió el uso de considerables recursos humanos y mecánicos. Los programas debían ser
        tan infalible como fuera posible y cualquier anomalía tenía que ser entendida y registrada para un posible impacto en la misión. De hecho, nunca se descubrieron errores de software durante las misiones.

        • gg dice:

          ¡Ay, una fuente maravillosa! Gracias. Estoy perplejo en cuanto a por qué me perdí eso, u olvidé que lo tenía en algún lugar aquí, asumiendo que realmente lo es. El libro de Mindell es generalmente mi fuente para el liderazgo y el dominio de Apolo. Ahora veo que este es uno de los remedios mencionados al final.

      • portafolio dice:

        Richard "Dick" Horace Battin también fue uno de los líderes del proyecto Apollo.

    • kb dice:

      Eso merece una conexión.
      https://en.wikipedia.org/wiki/Margaret_Hamilton_(scientist)

    • portafolio dice:

      http://www.klabs.org/history/apollo_11_alarms/eyles_2004/eyles_2004.htm
      El enlace anterior ni siquiera menciona a M. Hamilton, cuyo papel en el proyecto informático Apollo fue exagerado.

      • Andrés dice:

        ¿Es porque "ya está aquí"? (Piense en Franklin y el ADN).

        • gg dice:

          Improbable. Es porque 1) ella tenía muy poco que ver con las cosas descritas, y de todos modos, 2) hasta 400 personas trabajaron en esa cosa a la vez, por lo que incluso una mención aleatoria de ella no relacionada sería extremadamente improbable.

  • codewritinfool (@codewritinfool) dice:

    ¡Gran artículo como siempre, Greg!

  • RoboMonkey dice:

    ¡No somos dignos!

    La velocidad con la que hizo la modificación del código del Apolo 14 para arreglar la solicitud de aborto aleatorio Y darle a la tripulación un manual de aborto es increíble. ¡Hombre de misiles de ojos de acero!

    • Gregory L. Charvat dice:

      "No nos lo merecemos" es exactamente lo que le dije a Don que es un buen tipo. Ojalá publique su libro pronto, sea una lectura fascinante.

  • James Newton dice:

    ¿Te preguntas si alguien escribió en el intérprete? Según la descripción del video, sonaba como un intérprete de hilo (una lista de direcciones de subprograma), que es un método comúnmente utilizado en FORTH. Me gustaría saber por qué usaron eso; dice algo al respecto cuando se trata de matemáticas matriciales, pero eso no parece ser apropiado para el código de subprocesos. ¿Por compresión? El código enhebrado ocupa menos espacio al eliminar las instrucciones CALL repetidas. Si las rutinas matemáticas matriciales terminaron principalmente en una lista de llamadas a subrutinas (multiplique esto por esto, ahora por aquello, etc.), entonces tiene sentido.

    • Gregory L. Charvat dice:

      Sí, también me gustaría aprender más sobre esto. Si alguien puede llamarlo, sería muy agradable.

      • Lee Hutchinson dice:

        Sugeriría consultar el texto de O’Brien, "The Apollo Guidance Computer: Architecture and Operation" (https://www.amazon.com/Apollo-Guidance-Computer-Architecture-Operation/dp/1441908765), para obtener detalles sobre esto que nivel.

        La función principal del intérprete era crear una máquina virtual con arquitectura e instrucciones independientes del hardware AGC físico real. Esto permitió realizar funciones complejas en el hardware limitado del AGC, incluidas operaciones vectoriales y funciones trascendentales, y también permitió manejar tipos de datos más complejos (como variables, vectores y matrices de precisión simple, doble o triple).

        Cita de O'Brien:

        “El intérprete completa en lugar de reemplazar la codificación básica de AGC, ya que no todos los programas de misión requieren las habilidades del intérprete. Además, los programas de misión siguen siendo completamente dependientes de las rutinas administrativas para la gestión de procesos, E / S, interrupciones y otras funciones a nivel del sistema. Como tal, aunque el intérprete tiene muchas funciones en común con una CPU de hardware, es menos un emulador de máquina que una extensión del entorno de programación. Los programas pueden comenzar con instrucciones básicas de AGC y luego ingresar al intérprete para evaluar una expresión compleja, solo para volver a cumplir con las instrucciones básicas cuando se completa el cálculo. Fundamentalmente, la función del intérprete es ampliar la arquitectura del AGC a través de software escrito en el código nativo del AGC. Elementos como registros específicos o bits de estado que no se encuentran en la máquina física se implementan en almacenamiento extraíble, utilizando la lógica del programa para definir los módulos de su funcionamiento. "

        O’Brien dedica unas 50 páginas a desglosar el formato de instrucción del intérprete, su codificación y direccionamiento de código, sus instrucciones, su indexación, cómo ejecuta las instrucciones, cómo realiza cálculos vectoriales, cómo almacena datos y mucho, mucho más.

        • sbrk dice:

          Uno se pregunta si este no es el tipo de pensamiento que llevó a Wozniak a desarrollar SWEET16 durante los días de Apple.

  • James Newton dice:

    Aunque está vinculado en el artículo anterior, la página:
    http://www.doneyles.com/LM/Tales.html
    Debería recibir más atención por parte de todos los que estén realmente interesados ​​en lo que sucedió con esos códigos 1201, 1202 y POR QUÉ aparecieron. NO fue un error de lista de verificación. Según los informes, dejar el radar encendido era bastante aceptable, por lo que no había ninguna entrada en la lista de verificación que les dijera a los astronautas que lo apagaran. Fue un error de documento que dio lugar a la posibilidad de un error de fase de la señal que se producía aleatoriamente en un sensor de posición de la antena. La computadora pasó todo su tiempo libre tratando de colocar esa antena en el lugar correcto porque el sensor estaba enviando datos basura. Realmente vale la pena leerlo.

    • Lee Hutchinson dice:

      Vale la pena enfatizar esto, ya que es una de las grandes leyendas urbanas de la era Apolo (ahí arriba con "¡Todos los planes de Saturno V han sido destruidos!"). Como el propio Eyles explica a ese respecto, Aldrin cambiar el interruptor del radar de encuentro a la posición SLEW antes del aterrizaje NO fue un error de lista de verificación, fue un procedimiento establecido. Si la tripulación iniciara un aborto durante el aterrizaje, se necesitaría el radar de encuentro para recuperar la posición del CM y obtener esa información en el PGNCS o AGS. Sin embargo, se predijo que en caso de un aborto la tripulación estaría realmente muy ocupada, por lo que el procedimiento consistía en encender el radar antes de aterrizar para que ya funcionara si ocurría un aborto y la tripulación tuviera un interruptor menos. preocuparse.

      Luego, Eyles explica que los errores 1201 y 1202 no se debieron a una lista de verificación o un error de procedimiento, sino a un error de documento erróneo sobre un proyecto: varios elementos del radar de encuentro y la computadora de LM no estaban alineados eléctricamente en fase, aunque presumiblemente lo estaban. Los componentes que proporcionaban potencias fuera de fase no eran algo que pudiera simularse en los grandes entrenadores de cabina (aunque el problema se duplicó en los sistemas terrestres de plena potencia después de la misión), por lo que no era algo planeado.

      Las dos fuentes de energía obsoletas enviaron un eje no válido y valores angulares prominentes del radar de encuentro a los componentes de la computadora responsables de monitorear el estado del radar, que a su vez comenzó a emitir aproximadamente 12,800 interrupciones incrementales / decrecientes por segundo a la guía de la computadora LM ., intentando hacer que la computadora mueva el radar a una posición válida. Lidiar con esas 12.800 interrupciones extra inesperadas por segundo requirió tanta capacidad de tareas libre como la computadora de aviso de LM tuvo que ahorrar.

      El flujo del programa en el AGC está estrictamente regulado y la cantidad de tiempo de almacenamiento proyectada en el hardware fue una función del flujo del programa esperado. Debido a que se suponía que no era posible que ocurrieran estas interrupciones adicionales y debido a que a la computadora se le dio más que hacer durante su ciclo de tiempo de lo que podía, las tareas se salieron de su plato. Se llenaron dos almacenes temporales separados: primero los acumuladores de vectores (que activaron la alarma 1202) y luego los conjuntos de núcleos (que activaron el 1201). Afortunadamente, el brillante diseño del AGC Executive dejó que el AGC despejara sus almacenes de tiempo excedente y reanudara su lista de tareas pendientes sin romper nada, y cuando el rellano dejó P64 y se trasladó a P66, los problemas desaparecieron.

      Tengo un informe sobre todo el evento, que incluye un poco más de explicación y qué pasaría si, aquí mismo: http://arstechnica.com/science/2015/07/no-a-checklist-error-did-not -almost- descarrilar-el-primer-aterrizaje-en-la-luna / Sin embargo, Eyles es absolutamente la autoridad y yo diría que su explicación (http://www.doneyles.com/LM/Tales.html) es la definitiva.

    • Andrés dice:

      Bueno, lo que quiero saber es cómo se recuerda a Steve Bales por no llamar a un aborto con las alarmas 1202 y salvar el percance, pero Jack Garman nunca se menciona en los documentales, aunque Bales aparentemente solo entrega palabra por palabra, lo que Garman le dice: digamos, no suena tan seguro al respecto e incluso lo malinterpreta una vez, provocando una corrección sarcástica ...

      • NelC dice:

        "Sarcónico" - ¿una mezcla de sarcástico y sardónico?

  • Pasty Jerk (@pastyjerk) dice:

    TIL las instrucciones para la parte superior del alcance humano se utilizan como montaña rusa para fiestas nerd en lugar de guardarse en un museo.

  • HackJack dice:

    ¿Qué tipo de "fiesta" espera ver en el código fuente impreso?

    • pelusa dice:

      ¡Mi tipo de fiesta!

  • gumo (@agumonkey) dice:

    Hoy mismo, Alto casi se lanzó: https://www.youtube.com/watch?v=PR5LkQugBE0

    70 años atrás!

  • Mandevil dice:

    LLRV fue en realidad el primer avión Digital Fly By Wire, creo. Voló varios años antes que Apollo CM o LM, y al igual que el LM, era tan inestable que necesitaba ese FBW. ¿No estás seguro de si usó el mismo código que LM?

    • DainBramage dice:

      Cayendo con estilo ...

  • Umbumbólogo dice:

    ¿Por qué debería sellarse para su exhibición? ¡Al menos nuestro tipo favorito de OCR escanea las páginas en PDF y las pone en línea como referencia histórica!

  • José dice:

    La lista completa de códigos fuente de Luma que se muestra en las fotos de arriba, más de 1800 páginas, ha estado disponible en línea durante casi dos décadas.

    • Umbumbólogo dice:

      ¡Gracias por el consejo!

      http://lambda-the-ultimate.org/node/3522

  • Alabama dice:

    Tengo curiosidad por pensar un poco en el diseño de la electrónica interna y la plomería, porque tenían que funcionar después o durante un vacío total cuando la escotilla se abrió para excursiones. La mayoría de los condensadores de electrólisis de esa época probablemente no funcionarían en el vacío por mucho tiempo.

    • jtl dice:

      Los únicos condensadores electrolíticos a bordo eran probablemente tantalios de caracol húmedo herméticamente sellados.

  • James Beauchamp dice:

    Me encantaría ver este documento escaneado y disponible en algún lugar. Enseñé montaje en la universidad y me encantaría verlo.

  • paul r dice:

    “Tanto el Módulo de Comando Apolo (CM) como el Módulo Luna (LM) fueron el primer avión de vuelo por cable de la humanidad. "No sé si fueron las primeras implementaciones fly-by-wire, ¡pero no eran aviones!" ¡No hay aire por donde volaron!

    • notarealemail dice:

      Jajaja, simétrico. Realmente lo atrapaste esta vez, lol.
      http://www.ascii-code.com/ascii-art/vehicles/airplanes.php

    • Andrés dice:

      El F16 siguió solo unos años después ...

  • John U dice:

    2000 líneas aterrizarán en la maldita luna y aquí estoy hasta mis pezones en 200,000 líneas de mierda para generar un XML hinchado ...

    • Antron Argaiv dice:

      Desarrolladores reales ... 🙂
      http://web.mit.edu/humor/Computers/real.programmers

  • Escéptico lunar dice:

    Ummm, nunca fuimos a la luna

    • Enno dice:

      Vete a casa chico troll ...

    • notarealemail dice:

      Bueno, NOSOTROS no fuimos a la Luna sino a una docena de personas muy inteligentes.

      Si no fuimos a la Luna, ¿de dónde vinieron los focos y las huellas de los neumáticos? o_O

  • Me dice:

    Me encantaría ver las palabras "escaneamos las páginas para que nuestros espectadores puedan leerlas en línea". : PAG

  • Matthew T. Adams dice:

    Hacer. Tute. Fresco.

  • Mephito dice:

    pioneros

  • luisflores dice:

    ¡Buen artículo! ¿Sabes qué sería genial? colocando una foto vieja de Don Eyles sentado en el centro de mando durante el aterrizaje .. leyendo el código, me gustaría ver eso. Sin embargo, gracias por la historia.

  • Chip Parker dice:

    Ahora en github: https://github.com/chrislgarry/Apollo-11

  • Akseli Aït Lozanna (@ kmanitou81) dice:

    Mentiras que simplemente no morirán.

Eva Jiménez
Eva Jiménez

Deja una respuesta

Tu dirección de correo electrónico no será publicada.