10 años de profundidad en microcontroladores. Confía en nosotros.

Para un proyecto de microcontrolador, el chip es sólo una parte de la decisión. El verdadero desafío comienza cuando el producto debe funcionar con energía limitada, espacio reducido, temperaturas cambiantes, ciclos de producción largos y un objetivo de costo fijo. He trabajado con microcontroladores durante 10 años y he aprendido que una MCU adecuada no siempre es la que tiene la mayor velocidad o la mayor memoria. La mejor elección suele ser adaptar el dispositivo a las necesidades reales del producto. Es posible que un tablero de control pequeño necesite solo unos pocos pines GPIO, un temporizador y un puerto de comunicación simple. Un sistema de control de motor puede requerir un procesamiento más rápido, PWM preciso, rendimiento ADC y funciones de protección estables. Seleccionar la misma MCU para ambos productos puede crear costos innecesarios o límites de diseño. Mi enfoque comienza con la aplicación. Miro la velocidad de procesamiento requerida, el tamaño de la memoria, el voltaje de operación, las interfaces de comunicación, el presupuesto de energía, el tipo de paquete y el volumen de producción esperado. Estos detalles ayudan a limitar la selección antes de que comience el trabajo esquemático. El uso de energía a menudo afecta el diseño final más de lo esperado. Un sensor que funciona con batería puede pasar la mayor parte del tiempo en modo de suspensión y despertarse sólo para recopilar o enviar datos. Un microcontrolador con modos adecuados de bajo consumo puede ayudar a reducir el consumo de batería. El firmware también importa. Un control de activación deficiente o una transmisión de datos frecuente pueden aumentar el uso de energía incluso cuando la propia MCU tiene una especificación de baja potencia. Las necesidades de comunicación deben comprobarse tempranamente. UART puede ser suficiente para un módulo simple. SPI puede admitir una comunicación más rápida con pantallas, dispositivos de memoria o sensores. I²C puede reducir el cableado de varios dispositivos de baja velocidad. CAN se utiliza a menudo en sistemas de control industrial y de vehículos donde se necesita una comunicación estable entre nodos. Un ejemplo práctico es una unidad de control de temperatura para una cámara frigorífica. El diseño puede incluir un sensor digital, una pequeña pantalla, salida de alarma y conexión de datos. La MCU no necesita una gran potencia informática, pero sí una sincronización estable, una comunicación fiable del sensor y un bajo consumo de energía durante largos períodos de funcionamiento. Un dispositivo de bajo costo con periféricos adecuados puede ser mejor que una MCU más grande con funciones que el producto nunca utilizará. La planificación de la memoria también merece atención. El programa puede ajustarse al tamaño actual de Flash durante las primeras pruebas, pero las actualizaciones posteriores pueden agregar funciones de comunicación, registros de fallas o soporte de visualización. Normalmente dejo un espacio razonable para cambios de firmware en lugar de seleccionar un dispositivo que ya está cerca de su límite. El proceso de desarrollo se puede organizar en pasos claros: - Definir la función del producto y el entorno de trabajo. - Enumerar los periféricos y puertos de comunicación necesarios. - Estimar las necesidades de Flash, RAM y procesamiento. - Verifique el voltaje, el rango de temperatura, el paquete y los requisitos de energía. - Revisar herramientas de software, documentación y placas de desarrollo disponibles. - Confirmar condiciones de suministro y alternativas aprobadas. - Probar el MCU con los principales sensores, cargas y dispositivos de comunicación. - Revisar el diseño nuevamente antes de pasar a una producción mayor. La planificación del suministro forma parte de la decisión técnica. Un componente puede cumplir con los requisitos eléctricos pero aun así causar problemas si el canal de suministro cambia con frecuencia o el paquete es difícil de conseguir. Prefiero discutir el plan de producción esperado al principio, ya que una elección de etapa de muestra puede no ser adecuada para la fabricación a largo plazo. El soporte también afecta el tiempo de desarrollo. Las descripciones claras de los pines, los diseños de referencia, los ejemplos de software y la comunicación técnica receptiva pueden ayudar a los ingenieros a encontrar problemas antes. Cuando un cliente comparte los detalles de la aplicación, puedo centrar la recomendación en el diseño real en lugar de enviar una lista general de productos. Un error frecuente es elegir una MCU únicamente por la velocidad del núcleo. Un núcleo más rápido no resuelve todos los problemas. Si el dispositivo carece de los canales ADC, funciones de temporizador, puertos de comunicación u opciones de paquete necesarios, es posible que el proyecto necesite componentes adicionales o un rediseño de la placa. Otro error es esperar demasiado para probar el sistema completo. Una MCU puede parecer adecuada en el papel y aun así presentar problemas cuando se conecta a un motor, un cable largo, una fuente de alimentación ruidosa o un sensor con estrictos requisitos de sincronización. Las pruebas tempranas le dan tiempo al equipo de ingeniería para ajustar el circuito y el firmware antes de que resulte difícil cambiar el diseño. Mi experiencia ha dado forma a una visión simple: el microcontrolador adecuado debe respaldar el producto sin agregar costos no utilizados ni trabajo de diseño evitable. La selección debe basarse en la aplicación completa, no en una única especificación. Después de 10 años en este campo, sigo tratando cada proyecto como una nueva tarea de ingeniería. Un dispositivo sensor, un controlador de motor, un medidor inteligente y un panel industrial pueden utilizar microcontroladores, pero sus requisitos pueden ser muy diferentes. Preguntas detalladas, pruebas prácticas y una comunicación técnica clara ayudan a convertir la elección de un componente en un diseño de producto viable.

Elegir un microcontrolador para un producto no es sólo una cuestión de comprobar el tamaño de la memoria o la velocidad del reloj. El dispositivo debe coincidir con el plan de energía, la carga del sensor, las necesidades de comunicación, la estructura del software y los objetivos de producción. Una pequeña discrepancia puede provocar lecturas inestables, un arranque lento, un uso excesivo de energía o cambios costosos en la placa. Trabajo con estos detalles desde el principio. Mi objetivo es ayudar a convertir la idea de un producto en un sistema de microcontrolador que pueda construirse, probarse y mantenerse con confianza. ## Donde los proyectos a menudo se vuelven difíciles Un prototipo puede funcionar en una mesa de laboratorio y aun así enfrentar problemas en el uso diario. Un sensor que funciona con batería puede perder energía más rápido de lo esperado porque la MCU nunca entra en un modo de suspensión adecuado. Un controlador de motor puede reiniciarse cuando cambia la carga. Un dispositivo conectado puede pasar una prueba básica pero fallar cuando se ejecutan varias tareas de comunicación al mismo tiempo. Estos problemas a menudo provienen de decisiones tomadas al principio del diseño: - La MCU tiene muy poca RAM para el software planeado - El paquete seleccionado es difícil de ensamblar a escala de producción - Las asignaciones de pines no dejan espacio para funciones posteriores - Las interrupciones no se planifican en función de las necesidades de sincronización - El firmware depende de una sola característica de hardware - El acceso de depuración es difícil después de que la placa está cerrada - Los modos de energía se prueban solo en condiciones ideales. Miro el sistema completo en lugar de tratar el microcontrolador como una parte aislada. ## Una forma práctica de seleccionar la MCU. Empiezo con los requisitos del producto en lenguaje sencillo. ¿Qué mide el dispositivo? ¿Con qué frecuencia debe responder? ¿Se conectará a través de UART, SPI, I²C, CAN, USB, Ethernet o un módulo inalámbrico? ¿Necesita almacenamiento seguro, un temporizador de hardware, un procesador de señal digital o una pequeña interfaz de pantalla? Las respuestas crean una lista funcional de requisitos: - Velocidad de procesamiento - Capacidad de memoria flash y RAM - Voltaje de funcionamiento - Número y tipo de pines GPIO - Precisión de entrada analógica - Canales de temporizador y PWM - Interfaces de comunicación - Comportamiento de suspensión y activación - Límites de paquete y ensamblaje - Método de actualización de firmware - Vida útil esperada del producto Dejo algo de espacio para el crecimiento del software. Un diseño que utiliza casi toda la memoria disponible puede funcionar durante una fase de prototipo y luego resultar difícil de actualizar cuando se agregan diagnósticos, manejo de errores o una nueva característica de comunicación. ## La estructura del firmware importa tanto como el hardware. Una MCU capaz no resuelve un sistema de firmware mal planificado. Por lo general, separo el firmware en capas claras: 1. Inicialización de hardware 2. Controladores de dispositivos 3. Manejo de comunicaciones 4. Lógica de aplicación 5. Detección y recuperación de fallas 6. Soporte de registro y actualización Esta estructura me ayuda a probar cada parte sin cambiar todo el programa. También facilita el mantenimiento cuando cambia un sensor, pantalla o módulo de comunicación. Para un dispositivo de monitoreo de temperatura, el firmware puede leer un sensor en un intervalo fijo, verificar si el valor está dentro de un rango seguro, almacenar datos seleccionados y enviar una alerta a través de un módulo de comunicación. Cada tarea necesita una regla de tiempo definida. Un diseño basado en retrasos puede ser suficiente para una prueba sencilla, pero puede bloquear otras tareas a medida que el producto crece. Una programación basada en temporizador o un pequeño sistema operativo en tiempo real pueden adaptarse mejor cuando se deben ejecutar varias tareas juntas. La elección correcta depende de los límites de tiempo, el uso de la memoria, la experiencia del equipo y las necesidades del producto. ## El uso de energía necesita pruebas reales. Las afirmaciones de bajo consumo de energía deben provenir de mediciones, no solo de una hoja de datos. Verifico la corriente utilizada durante: - Inicio - Funcionamiento normal - Medición del sensor - Transmisión inalámbrica - Períodos de inactividad - Modo de suspensión - Despertar y recuperación Un dispositivo con batería puede parecer eficiente mientras su módulo de radio esté activo durante demasiado tiempo. Un sensor también puede consumir corriente entre mediciones si su línea eléctrica no está controlada. Una prueba útil registra la corriente a lo largo del tiempo en lugar de depender de la lectura de un medidor. Esto muestra picos cortos que pueden afectar la vida útil de la batería o provocar caídas de voltaje. También ayuda a identificar si la MCU está durmiendo según lo planeado. Por ejemplo, un sensor de suelo remoto puede despertarse cada diez minutos, recopilar datos de humedad, enviar un mensaje corto y volver a dormir. Si el firmware deja activa la interfaz de comunicación después de la transmisión, el resultado de la batería puede diferir mucho de la estimación inicial. ## El diseño de la comunicación necesita límites claros Muchos productos integrados dependen de más de una interfaz. Un controlador puede usar I²C para un sensor, SPI para memoria externa, UART para un módem y señales GPIO para control de estado o activación. Cada interfaz necesita su propio plan: - Formato de datos - Manejo de errores - Comportamiento de tiempo de espera - Reglas de reintento - Recuperación del bus - Tamaño del mensaje - Compatibilidad de actualización - Acceso de prueba Presto mucha atención al comportamiento de falla. Un sensor desconectado no debería congelar el dispositivo completo. Un mensaje serial perdido no debería dejar un motor funcionando sin supervisión. Un paquete de datos dañado debe rechazarse en lugar de tratarse como información válida. Los productos basados ​​en CAN a menudo necesitan atención a la prioridad de los mensajes y la terminación del bus. Los diseños I²C pueden necesitar valores pull-up que coincidan con la velocidad, el voltaje y la capacitancia total del bus. Estos pequeños detalles afectan si un sistema permanece estable fuera del laboratorio. ## Las pruebas deben reflejar el uso real. Un plan de prueba debe seguir la forma en que funcionará el producto. Utilizo comprobaciones como: - Pruebas de encendido y reinicio - Operación de larga duración - Desconexión del sensor - Pérdida de comunicación - Comportamiento de bajo voltaje - Recuperación de vigilancia - Uso de flash y RAM - Cambios relacionados con la temperatura - Actualizaciones de firmware repetidas - Inicio después de un corte de energía inesperado Un controlador que funciona durante cinco minutos aún puede fallar después de varios días. Un mecanismo de vigilancia puede ayudar a recuperarse de algunas fallas de software, pero necesita un tiempo de espera claro, un motivo de reinicio registrado y una prueba que demuestre que la ruta de recuperación funciona. También mantengo acceso de depuración en el diseño. Los paneles de prueba, los encabezados de programación, los registros en serie y los controles de reinicio pueden ahorrar muchas horas durante el desarrollo. Estas características deben planificarse antes de que se completen el recinto y los accesorios de producción. ## Un ejemplo de diseño realista Imagine una herramienta de inspección portátil que lee varios sensores, muestra los resultados en una pequeña pantalla, almacena registros y envía datos seleccionados a una computadora. El proyecto puede necesitar: - Modo de espera de bajo consumo - Lecturas analógicas estables - Control de pantalla - Memoria externa - Comunicación USB o UART - Una interfaz de usuario sencilla - Soporte de actualización de firmware Una pequeña MCU de 8 bits puede manejar el trabajo básico del sensor, pero puede verse limitado cuando el manejo de la pantalla, el almacenamiento de datos y la comunicación están activos juntos. Una MCU de 32 bits con más RAM podría proporcionar espacio para estas tareas, aunque puede requerir una configuración de desarrollo y una revisión de energía diferentes. Compararía ambas opciones con necesidades mensurables en lugar de seleccionarlas basándose únicamente en la velocidad del procesador. La decisión incluiría esfuerzo de software, disponibilidad de suministro, elección de paquete, acceso de depuración y cambios esperados en el producto. ## Cómo apoyo un proyecto Mi trabajo puede cubrir las partes que afectan el rendimiento de la MCU y la confiabilidad del producto: - Selección de MCU - Planificación de pines y periféricos - Revisión esquemática - Arquitectura de firmware - Desarrollo de controladores - Operación de bajo consumo - Protocolos de comunicación - Diseño de cargador de arranque y actualización - Depuración y análisis de fallas - Planificación de pruebas - Revisión de prototipos - Soporte de producción Prefiero registros técnicos claros. Mapas de pines, notas de interfaz, reglas de sincronización, mediciones de potencia y limitaciones conocidas ayudan al equipo a tomar decisiones sin depender de la memoria. Una buena ingeniería de microcontroladores no se trata de elegir el dispositivo más grande o agregar más funciones de las que necesita el producto. Se trata de hacer coincidir el controlador con la carga de trabajo real, dejar un espacio razonable para el cambio y probar las condiciones que pueden exponer puntos débiles. Cuando reviso un diseño, busco los problemas que pueden aparecer después de la etapa de prototipo: memoria limitada, depuración difícil, comportamiento de recuperación deficiente, comunicación inestable y uso de energía que no coincide con el objetivo. Abordar esos puntos tempranamente le da al producto un camino más claro desde el banco de trabajo hasta el uso regular.

Hace una década, los sistemas integrados a menudo se construían en torno a una tarea limitada: leer un sensor, controlar una máquina o mostrar una pequeña cantidad de datos. Hoy, los usuarios esperan más. Quieren equipos que puedan conectarse con otros dispositivos, utilizar la energía con cuidado, responder a condiciones cambiantes y permanecer estables durante años de servicio. He visto a muchos equipos enfrentar el mismo problema. Su producto funciona durante las pruebas, pero el uso en el campo genera nueva presión. El hardware debe soportar el calor, la vibración, la energía limitada, los cambios de red, las actualizaciones de software y los largos ciclos de mantenimiento. Una solución integrada inteligente debe abordar estas necesidades desde el principio. Nuestro enfoque comienza con las condiciones reales de trabajo del producto. Analizamos el entorno operativo, las tareas del usuario, el flujo de datos, los límites de energía y el plan de servicio. Un dispositivo instalado en una fábrica puede necesitar una carcasa resistente y una comunicación estable. Un dispositivo médico portátil puede necesitar un bajo consumo de energía, una interfaz sencilla y un manejo cuidadoso de los datos. Un panel de control conectado puede necesitar actualizaciones remotas y mensajes de error claros. El diseño correcto depende del trabajo. Un proyecto integrado práctico a menudo sigue este camino: - Definir la función principal y las necesidades del usuario - Seleccionar un procesador, memoria, sensor, pantalla y método de comunicación - Construir un prototipo funcional - Probar el rendimiento en las condiciones esperadas - Verificar el uso de energía, el calor, la calidad de la señal y el tiempo de respuesta - Mejorar el diseño para la producción y el servicio - Preparar actualizaciones de software y herramientas de mantenimiento Este proceso ayuda a prevenir un error común: elegir el hardware antes de comprender el producto. Un componente de bajo costo puede parecer atractivo al principio, pero puede crear límites cuando el producto necesita más memoria, una comunicación más sólida o un soporte más prolongado. También creo que el software debería considerarse parte del producto, no una tarea separada. El estado claro del dispositivo, los registros de errores, el acceso seguro y las actualizaciones controladas pueden reducir el trabajo de servicio. Cuando un operador puede ver lo que sucedió, el proceso de reparación se vuelve más fácil de gestionar. Un ejemplo familiar es una unidad inteligente de monitoreo de temperatura utilizada en una instalación de almacenamiento. Es posible que un dispositivo básico solo muestre la temperatura actual. Un sistema integrado más útil puede registrar cambios, enviar una advertencia cuando las lecturas se salgan del rango establecido, continuar trabajando durante una breve interrupción de la red y ayudar al personal a revisar la causa de un problema. El valor proviene del sistema completo, no de un solo componente. El apoyo a largo plazo también es importante. Los productos pueden permanecer en el campo durante muchos años. Un diseño que depende de un componente con disponibilidad limitada puede crear problemas para la producción futura. Prefiero revisar las opciones de suministro, soporte de software, herramientas de prueba y métodos de reparación antes de que el producto entre en fabricación a gran escala. Una década de progreso en tecnología integrada ha cambiado las expectativas de los usuarios, pero el objetivo básico sigue siendo el mismo: construir equipos que funcionen bien en su entorno real y que su mantenimiento sea práctico. Inteligente no siempre significa añadir más funciones. A veces significa utilizar menos energía, hacer que las fallas sean más fáciles de encontrar o brindar a los usuarios la información correcta en el momento adecuado. Ahí es donde un cuidadoso diseño integrado crea un valor duradero.

Cuando elijo un microcontrolador para un producto, miro más allá de la velocidad del reloj, el tamaño de la memoria y las listas de funciones. Una placa puede funcionar bien durante una prueba breve y aun así crear problemas una vez que comienza la producción. Las actualizaciones de firmware, el suministro de componentes, el ruido eléctrico, el calor, la documentación y el soporte a largo plazo dan forma al resultado. El conocimiento confiable sobre microcontroladores proviene de trabajar en estos detalles a lo largo del tiempo. Me ayuda a tomar decisiones que se ajusten al producto, al equipo y a las personas que utilizarán el dispositivo. ## Comience con la tarea del producto. Empiezo escribiendo lo que debe hacer el microcontrolador. Un monitor de temperatura pequeño puede necesitar: - Algunas entradas digitales - Una interfaz de sensor - Un modo de suspensión de bajo consumo - Control de pantalla simple - Operación confiable después de una pérdida de energía Un controlador de motor industrial puede necesitar: - Temporizadores rápidos - Lecturas analógicas precisas - Detección de fallas - Comunicación a través de CAN o RS-485 - Rendimiento estable cerca del ruido eléctrico Estos productos no deben usar el mismo microcontrolador simplemente porque ambos necesitan un procesador. La elección correcta comienza con el trabajo. También defino las condiciones de funcionamiento. Los equipos de batería, los controles de fábrica, los accesorios médicos y los electrodomésticos pueden imponer exigencias muy diferentes al mismo dispositivo. El voltaje de suministro, el rango de temperatura, la vibración, el comportamiento de reinicio y la vida útil esperada pertenecen a la discusión inicial. ## Haga coincidir la memoria con el firmware Las necesidades de memoria son fáciles de subestimar. Verifico el tamaño del código de la aplicación, el gestor de arranque, la pila de comunicación, los datos de calibración, los registros de errores y las actualizaciones futuras. Un diseño que utiliza casi todo el flash disponible puede funcionar durante el desarrollo pero deja poco espacio para el mantenimiento. La RAM merece la misma atención. Los buffers de comunicación, los datos de los sensores, el control de la pantalla y los cálculos temporales pueden consumir memoria más rápido de lo esperado. Prefiero dejar espacio práctico para cambios en lugar de utilizar cada byte en la primera versión. Un método de planificación simple es registrar: 1. Uso actual de flash 2. Uso actual de RAM 3. Tamaño del cargador de arranque 4. Necesidades de almacenamiento de datos 5. Espacio estimado para cambios de firmware posteriores Esto le brinda al equipo de ingeniería una imagen más clara antes de que se congele el hardware. ## Revise las herramientas de desarrollo Un microcontrolador solo es útil cuando el equipo puede construir, probar y mantener el software que lo rodea. Reviso el compilador, el depurador, las bibliotecas de software, los proyectos de ejemplo, las placas de desarrollo y las herramientas de programación. También compruebo si las herramientas son fáciles de obtener y si varios ingenieros pueden utilizar la misma configuración sin tener que realizar repetidos trabajos de configuración. La documentación importa todos los días. Un breve ejemplo de configuración de un temporizador puede ahorrar horas durante un proyecto sensible a la programación. Las especificaciones eléctricas claras ayudan a evitar errores en el diseño de circuitos. Las descripciones de los registros deben explicar no sólo qué hace un bit, sino también cuándo se puede cambiar y qué sucede después del reinicio. Presto mucha atención a los pequeños detalles. La falta de un diagrama de sincronización o una condición de inicio poco clara pueden crear una falla difícil de reproducir. ## Verifique el historial del producto con evidencia Una larga presencia en el mercado puede proporcionar información útil, pero la edad por sí sola no prueba que un microcontrolador se ajuste a un nuevo diseño. Busco evidencia como: - Historial de revisiones publicadas - Herramientas de desarrollo estables - Uso de producción documentado - Avisos de erratas claros - Políticas de soporte de productos definidas - Diseños de referencia disponibles - Información consistente del distribuidor También pregunto qué ha cambiado en las revisiones de dispositivos. Una pieza de repuesto puede compartir el nombre de un producto al mismo tiempo que cambia las opciones del paquete, el comportamiento de los periféricos o los requisitos de software. Cuando es posible, construyo un pequeño sistema de evaluación antes de comprometerme con una producción más grande. Una placa de prueba puede revelar el comportamiento de inicio, el consumo de energía, el tiempo de interrupción y el rendimiento de la comunicación en condiciones cercanas al producto de destino. ## Pruebe las condiciones que causan problemas Las pruebas en banco suelen utilizar energía limpia, cables cortos y un entorno silencioso. Los productos rara vez disfrutan de esas condiciones después del envío. Pruebo el microcontrolador durante: - Interrupción y recuperación de energía - Cambios lentos de voltaje - Reinicios repetidos - Condiciones de temperatura alta y baja - Errores de comunicación - Desconexión del sensor - Conmutación de motor o relé - Largos períodos de operación continua Por ejemplo, un controlador de bomba puede parecer estable durante la operación normal. Un motor que arranca cerca puede crear una perturbación de voltaje que reinicia el tablero. Una prueba útil comprueba si el firmware detecta el reinicio, registra la falla y regresa a un estado seguro. Este tipo de pruebas no elimina todos los riesgos. Le brinda al equipo mejor información antes de que los clientes encuentren el mismo problema. ## Plan de suministro y vida útil Un producto puede permanecer en uso durante muchos años. El plan del microcontrolador debe reflejar ese período. Pregunto si el dispositivo tiene más de una ruta de suministro aprobada, si el paquete seguirá siendo práctico para el ensamblaje y si el firmware puede pasar a una pieza relacionada si cambian las condiciones de suministro. También mantengo archivos de programación de producción, procedimientos de calibración y registros de pruebas bajo una gestión de versiones controlada. Un plan de reemplazo no debe iniciarse después de que resulta difícil conseguir una pieza. Es más fácil prepararse cuando el diseño original, la estructura del software y el proceso de prueba están bien documentados. ## Utilice un proceso de selección claro. Mi proceso preferido es simple: 1. Describir la tarea del producto y el entorno operativo. 2. Enumere los periféricos e interfaces necesarios. 3. Calcule las necesidades de flash, RAM, velocidad, potencia y paquetes. 4. Revisar herramientas, documentación, soporte e historial del producto. 5. Pruebe una placa de evaluación en las condiciones de estrés esperadas. 6. Registre las razones detrás de la elección final. 7. Mantener un plan de reposición y mantenimiento. Este proceso ayuda a prevenir un error común: seleccionar una pieza de una tabla de características sin verificar cómo se comporta dentro del producto completo. El conocimiento confiable sobre los microcontroladores se construye a través de un trabajo de diseño repetido, pruebas cuidadosas y registros honestos. Un dispositivo adecuado no necesita la lista de funciones más larga. Debe realizar las tareas requeridas, trabajar con las herramientas del equipo y seguir siendo manejable durante toda la vida útil del producto. Contáctenos hoy para obtener más información Huang: mr.huang@foyotrobotclaw.com/WhatsApp +8613600570999.

Referencias Joseph Yiu 2015 La guía definitiva de los procesadores ARM Cortex-M3 y Cortex-M4 Michael Barr y Anthony Massa 2006 Programación de sistemas integrados Jean J Labrosse 2016 Bloques de construcción de sistemas integrados Dispositivos Arm Cortex-M23 Arm 2023 Guía genérica del usuario Semiconductores NXP 2021 Especificación y manual del usuario del bus I2C IEEE 2016 Estándar IEEE para Especificación del protocolo de comunicación CAN de la red de área del controlador