60 min en Wokwi + 10 de entregable. Parejas, rotación cada 10 min.

Paso 0 · Preparación (5 min)

Duplicar el proyecto saboteado: tres tareas corriendo (sensor lento, sensor rápido, heartbeat) y un LED de heartbeat que debe parpadear a 1 Hz exacto.

Paso 1 · Caza de bugs (20 min)

Síntoma: el heartbeat se congela por tramos largos y vuelve; los timestamps del sensor rápido tienen huecos.

Bug raíz (uno solo): una tarea usa delay() bloqueante donde debería usar vTaskDelay().

Procedimiento:

1. Medir primero: imprimir el intervalo real entre latidos del heartbeat durante 20 s. Cuantificar el problema antes de buscarlo.
2. Correlacionar: ¿el congelamiento coincide con el ciclo de alguna tarea en particular? Ese es el sospechoso.
3. Hipótesis por escrito.
4. Cambiar solo la llamada bloqueante. Volver a medir el intervalo. Comparar antes/después con números, no con "ya se ve mejor".
5. Bitácora: síntoma → hipótesis → evidencia → causa raíz → arreglo, con las dos mediciones.

Paso 2 · Medición de jitter (15 min)

1. En la tarea de muestreo rápido, guardar el timestamp (esp_timer_get_time()) de cada muestra e imprimir el delta entre consecutivas.
2. Correr 30 s y sacar: delta medio, mínimo, máximo y desviación. Calcular el jitter como porcentaje del periodo nominal.
3. Cambiar vTaskDelay por vTaskDelayUntil y repetir la medición. Reportar ambas tablas — la diferencia es el contenido de la sesión.
4. Subir la prioridad de una tarea competidora y medir otra vez. Anotar qué se degrada.

Paso 3 · Plan de tareas del coche (20 min)

Una fila por sensor real de MadRams: