setup() suele ser la primera función que aprendemos a escribir. Su nombre y su posición en el sketch hacen que parezca el principio de una historia sencilla: configurar un pin, iniciar un puerto y empezar.
La realidad es un poco más interesante. Antes de que el bucle principal haga nada, el microcontrolador ya ha tenido que arrancar, negociar su reloj y dejar el sistema en un estado que podamos entender. Explorar ese camino no vuelve más difícil la programación; cambia la pregunta de «¿qué línea escribo?» a «¿qué está ocurriendo y por qué?».
El arranque también es una decisión
El nombre setup() describe una intención, no todo el proceso. En muchas plataformas hay trabajo antes de llegar a esa función: reset, carga del programa, inicialización de periféricos y configuración de relojes. El entorno puede esconder esos pasos para que el primer ejemplo sea breve, pero el hardware sigue existiendo.
Esa diferencia importa cuando algo falla. Un LED que no parpadea puede estar apagado por una configuración de pin, puede estar conectado al pin incorrecto o puede tener un problema de alimentación que el sketch no puede ver. Sin un mapa mental del arranque, el debug se convierte en una colección de intentos.
Del pin al mundo físico
Un pin no es una salida abstracta. Puede estar conectado a un transistor, una resistencia, un sensor o un periférico que tiene sus propios límites. La configuración del microcontrolador es sólo el primer lado de la relación.
La diferencia entre código y circuito
const uint8_t ledPin = 13;
void setup() {
pinMode(ledPin, OUTPUT);
}
void loop() {
digitalWrite(ledPin, HIGH);
delay(500);
digitalWrite(ledPin, LOW);
delay(500);
}El código parece completo, pero todavía estamos asumiendo que el LED está conectado al pin correcto, que la resistencia limita la corriente y que la diferencia de tensión es suficiente. Esa es una buena oportunidad para separar lo que el programa controla de lo que el circuito debe garantizar.
Qué conviene observar
Antes de añadir una librería o probar una variación del sketch, podemos hacer tres preguntas:
| Capa | Pregunta útil |
|---|---|
| Arranque | ¿Qué ha tenido que inicializarse para llegar a setup()? |
| Periférico | ¿Qué recurso está usando el pin y cuáles son sus límites? |
| Comportamiento | ¿Qué evidencia observable confirma que el sistema funciona? |
La lista es deliberadamente sencilla. No intenta sustituir una buena instrumentación; intenta evitar que el proceso empiece por una optimización sin un fenómeno que explicar.
Una práctica para el próximo experimento
La próxima vez que una placa no se comporte como esperamos, podemos registrar el proceso en una nota de laboratorio:
- Anotar la alimentación, el estado del reset y el pin utilizado.
- Separar la configuración del programa de las conexiones del circuito.
- Reducir el caso hasta que el comportamiento pueda medirse o verse.
- Anotar qué cambió respecto al experimento anterior.
El objetivo no es convertir cada proyecto en un tratado de electrónica. Es conservar una ruta desde el síntoma hasta la causa. Esa ruta es la diferencia entre copiar un sketch y comprender un sistema.
La siguiente pregunta natural es cómo decidir qué parte merece una optimización. Para eso conviene empezar por medir antes de optimizar.