La computación física relaciona instrucciones con elementos del mundo material. Una entrada aporta información, como el estado de un botón o una lectura de movimiento. El controlador ejecuta el programa que interpreta ese dato. Una salida comunica o provoca un efecto: encender un LED, mostrar un símbolo o mover un mecanismo. Un sensor obtiene información sobre una característica física; un actuador produce un efecto físico. Estas funciones se relacionan, pero no son intercambiables. Que un componente esté conectado no implica que el programa lo consulte ni que exista una respuesta preparada.

La cadena entrada, procesamiento y salida describe información. La alimentación proporciona energía para funcionar y debe representarse por separado cuando dibujamos conexiones. Un cable USB puede cumplir ambas funciones, pero recibir energía no demuestra que el programa nuevo se haya transferido. Antes de montar, identifica qué cambio quieres detectar y quién interpretará el resultado. Si nadie comprende el aviso, una salida técnicamente correcta puede ser poco útil. El esquema funcional permite revisar la idea sin confundir la cantidad de piezas con la calidad de la solución.

La micro:bit integra una matriz de LED, botones y sensores que podemos programar desde MakeCode. La versión de la placa importa: micrófono y altavoz incorporados pertenecen a versiones que los incluyen, no a cualquier micro:bit. Identifica el equipo disponible antes de escoger entradas y salidas. En MakeCode, al iniciar prepara una respuesta una vez y los eventos de botón ejecutan sus instrucciones cuando se producen. Podemos empezar con un símbolo sencillo para comprobar que reconocemos el entorno y sabemos qué debería verse al arrancar.

El simulador representa la placa y permite modificar entradas para ensayar la lógica. No comprueba alimentación, cables ni el comportamiento de todos los componentes físicos. Transferir carga el programa en la placa mediante el procedimiento disponible en el aula; después hay que probarlo allí. Un cable solo de carga puede dar energía sin transportar datos. Si queda un programa antiguo, revisamos archivo y transferencia antes de rehacer el algoritmo. Conserva una copia que puedas reabrir en MakeCode y comprueba su contenido. El nombre o una fotografía no garantizan que hayas guardado la última versión.

Una lectura es el dato que obtenemos al consultar una entrada. La micro:bit usa parte de su matriz de LED para detectar luz y MakeCode la representa de 0 a 255. Es una escala relativa de lectura, no una medición en lux. Orientación, sombras y ubicación influyen en el resultado. La referencia de MakeCode advierte que la primera consulta devuelve cero al activar la detección; observa lecturas posteriores antes de concluir que hay oscuridad. Un cero inicial y un cero medido después no deben interpretarse sin contexto.

La temperatura se estima desde el sensor del procesador y se expresa en grados Celsius, pero no convierte la placa en termómetro clínico. El acelerómetro aporta información de aceleración y permite reconocer gestos; una sacudida no describe cualquier posición exacta. Si el modelo incluye entrada de sonido, también hay que consultar qué representa su escala antes de asignarle unidades. Recoge varias lecturas manteniendo condiciones semejantes. Registrar cinco por condición permite observar variación y posibles solapamientos. La tabla debe indicar cómo se obtuvo cada dato y distinguir medición física de control simulado.

Un umbral es un valor que elegimos para separar casos y dar una respuesta distinta a cada uno. La comparación determina dónde está la frontera: si preguntamos si la lectura es menor que el umbral, un valor exactamente igual no cumple esa condición. Pertenece a la otra alternativa. Una estructura si / si no asigna respuesta a ambos casos. Entender esa relación permite explicar el comportamiento en el límite, en lugar de dejar la igualdad sin una decisión prevista.

El valor elegido necesita una justificación. En el ensayo numérico usamos 50 y comprobamos 49, 50 y 51 para estudiar la regla con entradas conocidas. Esas cifras son simuladas, no mediciones del aula ni una configuración válida para cualquier dispositivo. El umbral físico se decide a partir de las series observadas, con cinco lecturas por condición. Si las series se solapan mucho, una frontera puede distinguirlas mal; revisar las condiciones de medida ayuda a comprender el problema antes de cambiar la cifra.

Además de comparar correctamente, el programa necesita información actual. Una variable conserva lo último que guardamos: consultar el sensor solo antes de para siempre hace que las decisiones repetidas utilicen un dato antiguo. Dentro del bucle, leer, guardar, comparar y actualizar la salida conecta cada respuesta con una nueva consulta. Una pausa breve facilita observar el aviso, pero retrasa la siguiente comprobación de esa secuencia. Su duración depende del uso ensayado. Todo este automatismo aplica una regla escrita por personas; no supone entrenar una inteligencia artificial.

La iluminación puede cambiar gradualmente aunque un aviso solo muestre dos respuestas. Para comprender esa diferencia distinguimos la característica física, la señal del sensor y el dato que utiliza el programa. El sensor transforma una variación del entorno en una señal: una señal analógica representa variaciones dentro de un rango; una digital utiliza estados definidos. Al consultar la entrada obtenemos una representación manejable, como un número. Que aparezcan números enteros no significa que la iluminación real se haya reducido a encendida o apagada.

La reducción a dos casos ocurre cuando aplicamos una regla. Varias lecturas diferentes pueden corresponder al mismo aviso porque permanecen al mismo lado del umbral. Por eso el número puede cambiar y el icono seguir igual sin que exista una avería. Mostrar la lectura permite investigar variaciones; mostrar un símbolo puede facilitar que alguien interprete qué hacer. Ambas presentaciones responden a necesidades distintas. Conservar los datos de los ensayos permite justificar la decisión incluso cuando la interfaz cotidiana muestra solamente el aviso.

Para interpretar el dato necesitamos conocer la entrada concreta. Su documentación explica qué señal utiliza y qué significa el resultado; analógico o digital no indica por sí solo la tensión admitida por una conexión. Un cero tampoco demuestra siempre ausencia de dispositivo: puede ser una lectura válida o un comportamiento inicial documentado. Esta información permite relacionar lo que cambia en el entorno con lo que vemos en pantalla, y elegir una respuesta basada en el significado del dato.

Un componente externo necesita conexiones adecuadas para alimentación, referencia y señal según su modelo. GND es la referencia común de potencial del circuito. La tensión de alimentación y el nivel permitido en la señal son datos diferentes: alimentar correctamente un módulo no garantiza que su señal sea compatible con la placa. El aspecto del conector o la marca del kit tampoco lo demuestran. La ficha debe identificar referencia exacta, conexiones, adaptador y entorno de programación. Sin esa información no podemos dibujar una conexión como si estuviera validada.

Los motores y servos pueden necesitar alimentación y controladores específicos. Un pin que envía una orden no sustituye una fuente capaz de suministrar la energía necesaria. En las estaciones ACEBOTT se utiliza únicamente el montaje y adaptador revisados por el docente. Echidna Black2 se estudia con sus propias conexiones y entorno; comparar entradas y salidas no hace intercambiables los programas. Monta sin alimentación y pide revisión antes de conectar. Si falta compatibilidad comprobada, utiliza sensores integrados o la estación independiente preparada y deja constancia de esa alternativa en el registro.

Un prototipo es una versión que permite comprobar una idea antes de considerarla terminada. Parte de una necesidad concreta y un destinatario: quién necesita el aviso, en qué situación y qué debe hacer al verlo. Esa descripción permite elegir entrada y salida con sentido. Una pantalla más llamativa no mejora necesariamente la comprensión. El símbolo, la posición y las instrucciones deben comunicar qué significa el aviso y qué límites tiene. Podemos pedir a otra pareja que lo interprete sin explicar antes nuestra intención.

La construcción también influye en el funcionamiento. Una sujeción que cambia la orientación del sensor puede alterar las lecturas, y una carcasa puede ocultar la pantalla. Debemos conservar acceso a controles y evitar forzar piezas. Define una mejora y una prueba relacionada: comprensión si cambias un mensaje, estabilidad si cambias posición. Repite condiciones comparables antes y después. Al cerrar, prevé desmontaje y reutilización de placa y materiales. Explicar una limitación observada es parte del diseño: distinguir dos condiciones ensayadas no demuestra que el dispositivo funcione en cualquier lugar.

Una prueba de aceptación compara el prototipo con un requisito escrito antes. Para un aviso que responde al entorno, una sola fotografía no demuestra automatismo. Necesitamos observar al menos dos condiciones y volver a una anterior sin reiniciar. Ese retorno ayuda a descubrir si la lectura se actualiza o el programa queda bloqueado. Registra condición, dato, respuesta esperada, respuesta observada y conclusión. Los casos numéricos del límite pueden ensayarse mediante entradas simuladas conocidas, sin presentarlos como medidas físicas que hayas logrado reproducir exactamente en la placa.

La evidencia debe indicar dónde se ejecutó cada prueba. El simulador sirve para investigar la lógica; la placa aporta evidencia de interacción material. Si falta equipo, documenta lo realizado y lo pendiente sin sustituir etiquetas. Una ausencia o lectura no interpretable se estudia con el procedimiento preparado, sin desconectar módulos alimentados ni inventar valores de error. Para depurar, cambia una causa cada vez y repite el caso. A01 reúne diseño y primera microprueba física; A02 incorpora dispositivo, registro, instrucciones y mejora. Cada integrante debe explicar la cadena funcional y una decisión propia.