面试踩坑实录：自称精通 STM32+FreeRTOS，基础题直接露怯

[小聪同学]

Hoy entrevisté a un candidato cuyo currículum indicaba “dominio en desarrollo STM32 y aplicaciones FreeRTOS”. Pensaba que podría cumplir nuestros requisitos, pero tras unas preguntas básicas de sistemas embebidos, su nivel real quedó al descubierto. He recopilado las preguntas clave y análisis profesionales para advertir tanto a profesionales como a novatos: ¡si las bases no son sólidas, un currículum llamativo es en vano!

I. Preguntas y respuestas fatales (con análisis profesional)

1. Pregunta: ¿Cuál es la diferencia fundamental entre const y volatile en sistemas embebidos?

Respuesta del candidato: const no permite modificaciones, volatile sí…

Solo menciona lo superficial, sin tocar la esencia
Análisis profesional:

• const garantiza a nivel de compilador que no se modifique, se usa para constantes o variables de solo lectura, evitando escrituras accidentales
• volatile ordena al compilador que no optimice la variable, evitando que el compilador la considere invariable y omita lecturas/escrituras. Tres escenarios clave:
  • Acceso a registros de hardware (ej: volatile uint32_t *reg = (uint32_t*)0x40000000;, el valor puede cambiar por hardware)
  • Variables compartidas entre hilos/tareas (evita inconsistencias de sincronización)
  • Variables globales compartidas entre ISR y programa principal
    Complemento: const volatile uint32_t *reg representa registros de hardware de solo lectura (hardware escribe, software lee, evita modificaciones accidentales y optimizaciones)

2. Pregunta: ¿Por qué no se debe llamar a printf() en una ISR?

Respuesta del candidato: Porque es lento para imprimir…

Solo menciona la apariencia, no el riesgo fatal
Explicación completa:
printf() en ISR tiene 3 problemas críticos, no solo velocidad:

1. Puede activar operaciones de memoria dinámica (malloc/free), que no son reentrantes, causando corrupción de memoria entre ISR y programa principal
2. Contiene llamadas al sistema que podrían activar cambios de contexto, rompiendo la atomicidad de la ISR
3. Tiempo de ejecución impredecible, violando requisitos de tiempo real y bloqueando interrupciones prioritarias
   Alternativas prácticas:

• Usar buffer circular para registrar logs, solo escritura en ISR y procesamiento en bucle principal
• Usar banderas detectadas por el programa principal para activar salida
• Integrar componentes de registro ligeros (evitando memoria dinámica)

3. Pregunta: ¿Cómo garantizar seguridad al leer/escribir una variable de 32 bits entre ISR y programa principal?

Respuesta del candidato: ¿Usar un mutex?

Error común: Mutex en ISR puede causar deadlocks, y los mutex de FreeRTOS no soportan ISRs por defecto
Soluciones estándar:

1. Deshabilitar interrupciones: __disable_irq() → operación → __enable_irq() (simple pero limitar tiempo de deshabilitación)
2. Operaciones atómicas: Funciones ARM __atomic_load_32()/__atomic_store_32() para garantizar lectura/escritura en un ciclo
3. División en bytes: Dividir la variable en 4 bytes (útil para núcleos de 8/16 bits, opcional en 32 bits)
4. Instrucciones hardware: LDREX/STREX en Cortex-M para acceso exclusivo (previene condiciones de carrera)
   Nota: En ARM, acceso no alineado a variables de 32 bits puede activar HardFault, hay que evitarlo

4. Pregunta: ¿Cómo manejar prioridades entre DMA e interrupciones?

Respuesta del candidato: ¿DMA debería tener mayor prioridad?

Suposición ciega, ignora el mecanismo de 3 niveles
Análisis profundo:
Prioridades en sistemas embebidos requieren considerar 3 niveles:

1. Prioridad hardware: Configuración del controlador NVIC (número IRQn, menor valor = mayor prioridad)
2. Prioridad software: Prioridad de tareas/ISRs en RTOS (ej: vTaskPrioritySet en FreeRTOS)
3. Prioridad de flujo de datos: En STM32, el registro DMA_CCRx permite configurar prioridades entre flujos de datos en el mismo canal DMA
   Caso práctico:
   En muestreo ADC con DMA y búfer doble, DMA debe tener mayor prioridad que ADC para evitar que la interrupción ADC se active antes de completar el cambio de búfer DMA, causando pérdida de datos

II. Lecciones aprendidas (aplicable a novatos, HR y entrevistadores)

1. Zonas peligrosas en currículums (si se mencionan, se profundizará)

• Evitar “dominio” sin respaldo:
  • “Dominio en STM32” → preguntas técnicas como verificación CRC en SPI, manejo de timeout en I2C, configuración de dead-time en temporizadores
  • “Dominio en FreeRTOS” → mecanismos de planificación, diferencias entre semáforos y mutex, detección de overflow de pila
• Proyectos concretos, no vaguedades:
  • No solo “desarrollo de drivers”, sino ejemplos como: “Detecté carrera en bus I2C usando analizador lógico, resuelto con mutex + reintentos con timeout”
• Habilidades realistas:
  • Usar bibliotecas ≠ dominio. Debe demostrar desarrollo de drivers desde cero y resolución de bugs de hardware-software

2. Preguntas “mortales” en entrevistas de embebidos (fallar en ellas es fatal)

1. Dibujar el flujo completo de interrupciones en su proyecto (incluyendo contexto y anidamiento)
2. ¿Cómo verificar ausencia de condiciones de carrera o deadlocks en drivers? (con ejemplos prácticos como analizador lógico o impresión de estado de pila)
3. Describir el bug de hardware más complejo resuelto, proceso de diagnóstico y solución
4. ¿Cómo funciona internamente el cambio de tareas en FreeRTOS? ¿Qué hace la interrupción PendSV en Cortex-M?
5. ¿Qué detalles considerar al configurar GPIOs en modo multifunción en STM32? (ej: resistencias pull-up/down, velocidad de salida, mapeo AF)

III. Intercambio comunitario

¿Qué otros casos de “currículum vs. habilidades reales” han experimentado en entrevistas? ¿O qué preguntas clave añadirían para entrevistas de sistemas embebidos? ¡Compartan en comentarios! Espero que los nuevos profesionales prioricen las bases técnicas, eviten usar “dominio” sin fundamento y construyan una carrera sólida sobre conocimiento real.