¿Cuál es la diferencia entre hacer un sistema embebido y simplemente programar periféricos básicos (temporizador, SPI, I2C, UART, etc.)?

Mi opinión es que el verdadero punto del término “sistemas integrados” es la organización más que las habilidades. Pone el trabajo de los diseñadores de circuitos bajo el mismo techo que los desarrolladores de firmware, que es como debería ser, porque están mejor desarrollados y depurados conjuntamente. Elegir el microcontrolador adecuado hace la vida mucho más fácil para el desarrollador de firmware. Idealmente, un buen programador de sistema integrado no solo sabe cómo escribir código C, sino también cómo usar un osciloscopio para depurar un protocolo en serie, conoce las diversas opciones inalámbricas y sus implicaciones de seguridad y uso de energía, si el ADC integrado podrá ejecute usando DMA mientras el procesador está en reposo profundo, etc. A veces, si tiene mucha suerte, puede encontrar una gran persona integrada que haga tanto el diseño del firmware como la placa EE, pero a menudo necesita dos personas separadas con él. habilidades para encontrarse en el medio.

Dicho esto, aprender esos periféricos es el pan de cada día de un buen desarrollador de firmware.

No me queda claro qué distinción estás intentando hacer. ¿Qué quiere decir con “hacer un sistema integrado”?

(Por lo demás, no siempre está claro cuál es la distinción entre un “sistema integrado” y una “computadora” en estos días, ya que muchos sistemas integrados son solo PC de factor de forma pequeño, pero esa es una discusión diferente).

Si está escribiendo código para un sistema que está incrustado, por ejemplo, no es una computadora genérica independiente, está trabajando en un sistema embebido, independientemente de los periféricos que esté utilizando o no.

Muchos trabajadores de sistemas integrados están involucrados con el diseño del sistema desde el principio. Por lo tanto, comprender íntimamente los detalles de la aplicación y contribuir a las piezas que satisfacen de manera óptima los requisitos es parte del trato. Cuando esto es parte de su rol, otra tarea común de sistemas embebidos es abrir una placa. Hay una placa, diseñada de acuerdo con las especificaciones de las que puede o no haber estado al tanto, pero no tiene un código que funcione y, de hecho, no se ha demostrado que funcione según lo previsto. Los errores en el diseño del tablero no son infrecuentes, y las piezas no siempre funcionan exactamente como se especifica, o puede haber descuidos en el diseño. Debe poder obtener código que funcione y ejercite todos los elementos de la (s) placa (s). Los objetivos son validar el diseño y la implementación, y posiblemente crear un código que valide el funcionamiento correcto de todas las instancias de producción de la placa. Su código inicial también puede constituir la base de algún tipo de código de controlador formal que se convierte en parte de la aplicación final. Debe poder depurar el diseño de la placa cuando las cosas no funcionan. Eso significa poder interpretar las hojas de datos de todas las partes y determinar dónde existen errores en el diseño. Por lo general, no tiene mucho que usar para ver dónde funciona o no funciona el código, excepto un seguimiento de alcance o dos y quizás un par de LED.

El resto no es muy diferente de lo que usted describe.