Del kit de desarrollo a la PCB propia: qué cambia realmente

Por qué un prototipo que funciona no siempre sirve para el producto

Cuando estamos desarrollando un producto electrónico, una placa de desarrollo permite avanzar muy rápido. Podemos conectar un microcontrolador, añadir un sensor, probar una comunicación y tener una primera versión funcional sin diseñar todavía una PCB propia.

Ese primer resultado es importante: nos permite comprobar que la tecnología funciona y detectar problemas antes de invertir tiempo y recursos en un diseño definitivo.

Pero existe una diferencia importante entre conseguir que un prototipo funcione y diseñar una electrónica adecuada para un producto.

Una placa de desarrollo está pensada para experimentar. El producto final, en cambio, tiene que cumplir unos requisitos concretos de tamaño, consumo, coste, fiabilidad, fabricación y condiciones de funcionamiento.

Por eso, cuando llega el momento de pasar del prototipo a una PCB propia, la pregunta no debería ser simplemente:

¿Cómo podemos copiar lo que ya funciona?

La pregunta debería ser:

¿Qué parte de esta solución sigue siendo adecuada para el producto que queremos fabricar?

Esta diferencia puede hacer que algunos elementos del prototipo se mantengan prácticamente sin cambios, mientras que otros tengan que rediseñarse por completo.

Un prototipo y un producto no tienen los mismos objetivos

Durante las primeras etapas de un proyecto, el objetivo principal suele ser reducir la incertidumbre.

Necesitamos comprobar si un microcontrolador puede comunicarse con un sensor, si una determinada radio ofrece el alcance necesario o si el firmware es capaz de ejecutar el algoritmo que hemos planteado.

Para ello, una placa de desarrollo resulta especialmente útil. Ya incorpora buena parte de la electrónica necesaria y permite concentrarnos en la funcionalidad que queremos probar.

En esta fase puede tener sentido utilizar una placa grande, conectar sensores mediante cables, alimentar el sistema con una fuente externa o utilizar módulos comerciales.

Nada de esto significa que el diseño sea incorrecto. Simplemente significa que está optimizado para otra finalidad.

La prioridad deja de ser únicamente “hacer que funcione” y pasa a ser “hacer que funcione de forma fiable dentro de las condiciones para las que se ha diseñado”.

Por ejemplo, durante el prototipo puede ser perfectamente razonable utilizar una placa de desarrollo de un microcontrolador. Sin embargo, si el producto final necesita ocupar mucho menos espacio, consumir menos energía y reducir el coste de fabricación, mantener esa misma placa puede dejar de tener sentido.

Lo mismo ocurre con muchos otros elementos.

Un cable puede ser perfecto para una prueba de laboratorio, pero no para un producto que tendrá que fabricarse en grandes cantidades. Una fuente externa puede simplificar las primeras pruebas, pero no necesariamente será adecuada para la alimentación definitiva. Un módulo puede permitir validar rápidamente una comunicación, aunque integrar directamente el componente pueda ser una solución más adecuada para el producto final.

Por tanto, el hecho de que una solución funcione durante el prototipo no demuestra que sea la solución óptima para el producto.

Y esta es precisamente la razón por la que pasar de una placa de desarrollo a una PCB propia no debería entenderse como un simple proceso de copiar el circuito y hacerlo más pequeño.

Se trata de revisar las decisiones tomadas durante el prototipo y adaptarlas a los requisitos reales del producto.

Que funcione no significa que sea la solución adecuada

Una de las ventajas de las placas de desarrollo es que permiten evitar muchas decisiones durante las primeras etapas del proyecto.

El fabricante ya ha resuelto aspectos como la alimentación, programación, conectividad, reloj o determinadas interfaces. Nosotros podemos utilizar esas funciones directamente y concentrarnos en desarrollar la aplicación.

Esto es precisamente lo que hace que sean tan útiles para crear un prototipo.

Pero también puede generar una situación engañosa: podemos terminar asociando el funcionamiento del prototipo con una arquitectura que nunca fue diseñada para el producto final.

Imaginemos, por ejemplo, que desarrollamos un dispositivo utilizando una ESP32 DevKit.

Durante el prototipo podemos utilizar:

• El conector USB de la placa.
• El conversor USB-UART.
• El regulador integrado.
• Los LEDs.
• Los pulsadores.
• Los conectores de expansión.
• Los diferentes componentes auxiliares de la placa.

Todo funciona y podemos desarrollar el firmware sin problemas.

Cuando diseñamos el producto, sin embargo, podemos descubrir que solamente necesitamos el microcontrolador, determinada memoria, una interfaz de comunicación y algunos componentes de alimentación.

El resto de elementos estaban allí para facilitar el desarrollo, no porque fueran necesarios para el producto.

Por tanto, copiar la DevKit no sería necesariamente la mejor solución.

El diseño de la PCB propia debe partir de otra pregunta:

¿Qué necesita realmente nuestro producto?

A partir de ahí podemos decidir qué elementos del prototipo merece la pena mantener, cuáles deben modificarse y cuáles pueden desaparecer completamente.

Esta forma de trabajar permite aprovechar todo lo aprendido durante el prototipo sin convertir las decisiones tomadas para experimentar en limitaciones del producto final.

El paso de una placa de desarrollo a una PCB propia no implica necesariamente cambiar todos los componentes utilizados durante el prototipo. En algunos casos, buena parte de la arquitectura puede mantenerse.

Lo que cambia es que ahora cada decisión tiene que responder a los requisitos del producto.

Durante el prototipado podemos aceptar determinadas soluciones porque nos permiten avanzar rápidamente. En un producto, esas mismas soluciones pueden introducir costes, limitaciones de tamaño, problemas de consumo o dificultades de fabricación.

Por eso, antes de diseñar la PCB conviene revisar el prototipo desde una perspectiva diferente.

La diferencia no está solamente en el hardware.

También cambia la forma de evaluar el diseño. Una solución que durante el prototipo era la más rápida puede dejar de serlo cuando tenemos que fabricar cientos o miles de unidades.

Por eso, el prototipo no debería convertirse automáticamente en la arquitectura del producto. Debería utilizarse como fuente de información para tomar mejores decisiones en la siguiente etapa.

Una de las primeras cosas que conviene revisar es qué elementos de la placa de desarrollo son realmente necesarios.

Cuando utilizamos una DevKit, tenemos a nuestra disposición muchas funciones que facilitan el desarrollo, pero que no necesariamente necesita el producto final.

Por ejemplo, una placa puede incorporar interfaces de programación, conectores, LEDs, botones, reguladores o circuitos auxiliares que resultan muy útiles durante las pruebas.

El producto pide además otras cosas: coste, consumo, encapsulado, disponibilidad, alternativas y vida útil. La selección de componentes electrónicos debe tener en cuenta todos estos factores desde las primeras fases del desarrollo

En una PCB propia podemos decidir cuáles de esos elementos necesitamos realmente.

Alimentación

Durante el prototipo es habitual utilizar USB, una fuente de laboratorio o un módulo de alimentación externo.

Es una solución cómoda porque permite empezar a trabajar rápidamente sin tener que diseñar desde el principio toda la alimentación del sistema.

En el producto, sin embargo, la alimentación puede tener que cumplir requisitos mucho más concretos. Puede existir una batería, una entrada industrial, una limitación de consumo o determinadas condiciones de funcionamiento.

La arquitectura de alimentación pasa entonces a formar parte del propio producto.

No significa que la alimentación utilizada durante el prototipo estuviera mal planteada. Simplemente estaba resolviendo un problema diferente: permitir desarrollar y validar el sistema de forma rápida.

Una alimentación adecuada para desarrollar un prototipo no tiene por qué ser la alimentación adecuada para fabricar el producto.

Microcontrolador y componentes

Algo similar ocurre con el microcontrolador y el resto de componentes.

Durante el prototipo podemos elegir un dispositivo porque dispone de una placa de desarrollo disponible, porque facilita la programación o porque permite acceder rápidamente a los periféricos que necesitamos.

Cuando el producto está definido aparecen otras preguntas:

• ¿El coste es adecuado para el volumen previsto?
• ¿El consumo es compatible con el producto?
• ¿El encapsulado es adecuado?
• ¿Está disponible a largo plazo?
• ¿Necesitamos realmente todas sus prestaciones?
• ¿Existen alternativas más adecuadas?

En algunos casos, incluso puede tener sentido cambiar el componente utilizado durante el prototipo.

Por eso, el componente que permitió demostrar que la tecnología funciona no tiene por qué ser necesariamente el componente que termine dentro del producto.

Conectores y cableado

Los cables son otro buen ejemplo.

Durante las primeras pruebas resulta muy práctico conectar un sensor mediante un cable o utilizar un módulo externo. Podemos modificar rápidamente las conexiones y sustituir componentes sin rediseñar una placa.

Pero en un producto final, cada conexión tiene que responder a otros criterios.

El conector debe ocupar un determinado espacio, soportar las condiciones de uso y permitir fabricar y montar el producto de forma repetible.

En algunos casos, incluso puede desaparecer completamente porque la conexión que durante el prototipo se realizaba mediante un cable puede resolverse directamente dentro de la PCB.

Sensores y periféricos

La misma situación puede aparecer con los sensores y otros periféricos.

Un sensor puede funcionar perfectamente conectado a una placa de desarrollo mediante unos cables y una interfaz determinada. Sin embargo, al diseñar el producto pueden cambiar su ubicación, la longitud de las conexiones, la alimentación disponible o incluso la interfaz utilizada.

Por eso, el objetivo de la PCB propia no debería ser reproducir exactamente las conexiones del prototipo.

Debe conseguir que cada bloque funcione correctamente dentro de las condiciones reales en las que tendrá que trabajar el producto.

El layout puede convertir una solución que funciona en una solución problemática

Durante el prototipado, muchos elementos permanecen separados. Podemos tener una placa de desarrollo por un lado, un sensor por otro, un módulo de comunicación conectado mediante cables y una fuente de alimentación externa. Esto facilita enormemente las pruebas. Cuando todos esos elementos pasan a una PCB, dejan de estar aislados físicamente.

La alimentación, las señales digitales, las comunicaciones, los sensores y otros circuitos comparten el mismo espacio y empiezan a interactuar entre ellos.

Por eso, una solución que funcionaba correctamente durante el prototipo puede comportarse de forma diferente cuando se integra en una única placa.

“La distribución física empieza a formar parte del funcionamiento eléctrico del producto, especialmente cuando aparecen señales rápidas, comunicaciones o bloques de potencia; por eso, el enrutamiento de una PCB requiere tener en cuenta desde el principio la integridad de señal, el ruido y la compatibilidad electromagnética

Aquí es donde conceptos como integridad de señal, desacoplo, distribución de alimentación o EMC dejan de ser cuestiones independientes y pasan a formar parte de una misma decisión de diseño.

No se trata de resolver todos estos problemas en la fase de prototipo. Precisamente una de las funciones del prototipo es ayudarnos a descubrir qué requisitos tendrá que cumplir la electrónica definitiva.

La PCB propia es el momento en el que esas necesidades se convierten en decisiones concretas de diseño.

Uno de los cambios más importantes al pasar de un prototipo a un producto es que ya no basta con comprobar que el sistema funciona en unas condiciones concretas.

Durante el prototipado podemos estar interesados en responder preguntas como:

¿El sensor funciona con este microcontrolador?

¿Podemos enviar los datos mediante esta comunicación?

¿El firmware ejecuta correctamente esta función?

Una vez que el diseño se convierte en un producto, las preguntas son diferentes:

¿Seguirá funcionando cuando cambie la temperatura?

¿Qué ocurre cuando aumenta el consumo?

¿Cómo se comportará después de miles de ciclos de funcionamiento?

¿Qué sucede si aparece ruido o una perturbación en la alimentación?

El objetivo pasa de demostrar una funcionalidad a demostrar que esa funcionalidad es estable, repetible y adecuada para las condiciones reales de uso.

Esto es especialmente importante porque muchas de las condiciones que afectan al producto todavía no están presentes durante las primeras pruebas. Una placa puede funcionar perfectamente sobre una mesa de laboratorio y presentar problemas cuando se instala dentro de una carcasa, trabaja con una batería o comparte alimentación con otros elementos.

Por eso, la transición a una PCB propia también implica definir en qué condiciones tendrá que funcionar realmente el producto.

Temperatura, alimentación, consumo, vibraciones, humedad, interferencias o tiempo de funcionamiento pueden convertirse en requisitos de diseño que no eran relevantes durante las primeras pruebas.

El prototipo permite descubrir la funcionalidad.

La PCB de producto debe permitir convertir esa funcionalidad en un sistema robusto.

El firmware del prototipo no debería depender de la DevKit

La aplicación debería centrarse en lo que necesita hacer y no, siempre que sea posible, en los detalles físicos de la placa.

Por ejemplo, la aplicación puede necesitar simplemente:

“Leer el acelerómetro”

Mientras que la forma concreta de hacerlo puede quedar resuelta en una capa inferior encargada de gestionar el dispositivo y el hardware.

Esta separación permite que una modificación de la PCB no implique necesariamente modificar toda la aplicación.

Una arquitectura basada en drivers y una capa de adaptación al hardware, como un Board Support Package (BSP), puede facilitar esta transición.

El objetivo no es evitar todos los cambios de firmware. Es conseguir que los cambios necesarios queden localizados en las partes del software que realmente dependen del hardware.

Una de las preguntas más útiles al diseñar una PCB propia es precisamente esta:

¿Qué elementos de la placa de desarrollo ya no necesita nuestro producto?

Una DevKit está diseñada para facilitar el acceso al hardware. Por eso suele incluir componentes y conexiones que son muy útiles durante el desarrollo, pero que pueden ser innecesarios en el producto final.

Dependiendo de la plataforma utilizada, una placa de desarrollo puede incorporar muchos elementos destinados a facilitar las pruebas y la programación. Es habitual encontrar conectores USB, conversores USB-UART, LEDs de usuario, pulsadores o pines de expansión que permiten acceder fácilmente a diferentes funciones del microcontrolador. También puede incluir reguladores adicionales, interfaces de programación y otros componentes auxiliares que simplifican la conexión y depuración durante el desarrollo.

Todos estos elementos pueden ser muy útiles mientras estamos trabajando con el prototipo. Permiten programar la placa rápidamente, observar el estado del sistema, conectar periféricos o acceder a diferentes señales sin tener que diseñar toda esa infraestructura.

Sin embargo, cuando diseñamos la PCB del producto, hay que preguntarse cuáles de esos elementos siguen siendo necesarios. Algunos pueden desaparecer porque ya no aportan ninguna funcionalidad al usuario, mientras que otros pueden integrarse de una forma diferente o mantenerse únicamente como elementos de programación y test.

La cuestión no es eliminar componentes por reducir el tamaño de la placa, sino distinguir qué elementos necesita realmente el producto de aquellos que estaban presentes únicamente para facilitar su desarrollo.

En la PCB final, algunos pueden desaparecer, otros pueden integrarse y otros pueden sustituirse por una solución más adecuada.

Esto puede reducir el tamaño de la placa, simplificar el diseño, disminuir el coste y adaptar la electrónica a las necesidades reales del producto.

Por eso, la PCB propia no debería entenderse como una DevKit a la que simplemente se le han quitado algunos conectores.

La pregunta correcta es qué arquitectura electrónica necesita realmente el producto.

Cuando trabajamos con una placa de desarrollo, gran parte de la infraestructura necesaria para poner en marcha el sistema ya viene resuelta. Podemos conectar la alimentación, programar el microcontrolador y añadir periféricos sin tener que tomar todavía todas las decisiones que exige una PCB propia.

Al diseñar el producto, esa infraestructura deja de estar implícita y pasa a formar parte del diseño. Hay que decidir cómo se alimentará la placa, cómo se programará, qué conectores tendrá, cómo se realizará el reset, qué señales estarán disponibles para diagnóstico y cómo se podrá comprobar el funcionamiento durante la fabricación.

Esto también afecta a la forma de pensar la electrónica. Una PCB de producto no solo tiene que ejecutar el circuito diseñado, sino que debe permitir fabricarlo, probarlo y mantenerlo. Por eso, pueden aparecer elementos que nunca fueron necesarios durante el prototipo, como puntos de test, interfaces de programación, mecanismos de recuperación o conexiones específicas para las pruebas de producción.

Es un cambio importante porque el diseño deja de estar pensado únicamente para el desarrollador. La PCB empieza a formar parte de un proceso mucho más amplio en el que intervienen fabricación, montaje, validación, instalación, mantenimiento y, dependiendo del producto, actualizaciones durante años.

Una de las diferencias más importantes entre un prototipo y un producto aparece cuando dejamos de probar el sistema durante unos minutos o unas horas y empezamos a pensar en cómo va a comportarse durante toda su vida útil.

En el laboratorio podemos aceptar determinadas condiciones que serían difíciles de justificar en un producto. Podemos utilizar una fuente externa, cambiar un cable, reiniciar manualmente el equipo o incluso intervenir directamente sobre la placa cuando algo no funciona. Durante el desarrollo, estas situaciones forman parte del proceso de aprendizaje.

En un producto instalado, la situación es diferente. El dispositivo tiene que arrancar correctamente, soportar las condiciones previstas y mantener su funcionamiento sin depender de que alguien pueda intervenir físicamente sobre él. Una solución que funciona perfectamente durante una demostración puede revelar problemas cuando cambia la temperatura, aumenta el ruido eléctrico, se alarga un cable o el equipo permanece funcionando durante meses.

Por eso, pasar a una PCB propia implica empezar a validar algo más que la funcionalidad. Hay que comprobar que la solución mantiene un comportamiento estable bajo las condiciones para las que ha sido diseñada.

Esta diferencia es especialmente importante en aspectos como la alimentación, la temperatura, las comunicaciones, la compatibilidad electromagnética o el consumo. No es necesario resolver todos estos problemas durante la primera prueba de concepto, pero sí tenerlos presentes antes de considerar que el diseño está preparado para convertirse en producto.

El prototipo demuestra que el sistema puede funcionar. La validación del producto debe demostrar que puede hacerlo de forma repetible y fiable.

El paso a una PCB propia tampoco consiste únicamente en trasladar el circuito eléctrico a otro formato. Aunque buena parte del firmware desarrollado durante el prototipo pueda reutilizarse, el hardware definitivo introduce nuevas condiciones que pueden obligar a modificarlo.

Durante el desarrollo es habitual utilizar interfaces de programación, puertos USB, LEDs o diferentes periféricos de la placa para facilitar las pruebas. Cuando estos elementos desaparecen o cambian, el firmware puede necesitar otros mecanismos para detectar estados, realizar diagnósticos o recuperar el equipo.

También pueden cambiar los tiempos de arranque, las fuentes de alimentación disponibles, las entradas y salidas utilizadas o la forma en la que se conectan determinados periféricos. Incluso una modificación aparentemente pequeña del hardware puede tener consecuencias en la inicialización del sistema o en la gestión de errores.

Además, cuando el dispositivo se convierte en un producto aparece una necesidad que durante el prototipo puede pasar desapercibida: mantener el firmware a lo largo de la vida útil del equipo. Ya no basta con poder cargar una versión nueva desde el ordenador del desarrollador. Hay que plantear cómo se actualizará el dispositivo, cómo se recuperará si una actualización falla y cómo se podrá identificar el estado del equipo cuando esté instalado.

Por eso, hardware y firmware deberían evolucionar conjuntamente durante esta transición. El objetivo no es simplemente conseguir que el código que funcionaba sobre la placa de desarrollo siga ejecutándose en la PCB final, sino comprobar que ambos forman una arquitectura adecuada para el producto.

Uno de los errores más habituales al dar este paso es interpretar la placa de desarrollo como si fuera el diseño de referencia del producto final.

Si un sistema funciona utilizando una determinada placa, parece lógico intentar reproducirla sobre una PCB propia. Sin embargo, esto puede llevar a conservar componentes, conexiones o decisiones que tenían sentido durante el desarrollo, pero que ya no son necesarias.

La placa de desarrollo fue creada para resolver un problema diferente. Su objetivo es proporcionar al desarrollador una plataforma flexible y accesible sobre la que experimentar. El producto, en cambio, necesita una solución adaptada a sus requisitos concretos.

Por eso, diseñar la primera PCB no debería consistir en copiar el kit y eliminar algunos elementos. El proceso debería empezar revisando qué se ha aprendido durante el prototipo y qué necesita realmente el producto.

Quizá el microcontrolador utilizado inicialmente siga siendo la mejor opción. Pero también puede ocurrir que otro encapsulado, otra variante del mismo componente o incluso otro dispositivo resulte más adecuado cuando entran en juego el coste, el consumo, el tamaño o la disponibilidad.

Lo mismo sucede con la alimentación, las comunicaciones, los conectores o los sensores. El prototipo proporciona información para tomar estas decisiones, pero no obliga a mantener exactamente las mismas soluciones.

La PCB propia debería ser, por tanto, una evolución del prototipo y no una reproducción del mismo.

Otra diferencia que aparece al abandonar la placa de desarrollo es que el diseño empieza a estar condicionado por la forma en la que se fabricará.

Mientras trabajamos con una unidad de prototipo, determinadas decisiones tienen poca importancia. Podemos montar componentes manualmente, cambiar una pieza o modificar una conexión para realizar una prueba. Cuando queremos fabricar decenas, cientos o miles de unidades, esas mismas decisiones pueden afectar directamente al coste, al tiempo de montaje y a la fiabilidad del producto.

La selección de encapsulados, la disponibilidad de los componentes, la facilidad de montaje y las posibilidades de test pasan a formar parte del diseño electrónico. Una solución técnicamente correcta puede dejar de ser interesante si resulta demasiado costosa o complicada de fabricar.

También cambia la forma de detectar errores. En un prototipo, el desarrollador puede conectar un programador, medir una señal o utilizar un instrumento de laboratorio para comprobar qué está ocurriendo. En producción, el proceso debe ser mucho más repetible. La placa debe poder programarse y comprobarse siguiendo un procedimiento definido.

Esto hace que conceptos como los puntos de test, la programación durante fabricación o las pruebas funcionales adquieran importancia incluso aunque nunca hayan sido necesarios durante las primeras pruebas.

La industrialización no empieza cuando termina el diseño electrónico. Muchas de las decisiones que facilitan la fabricación y validación deben tenerse en cuenta mientras se diseña la PCB.

Una placa de desarrollo es una herramienta excelente para reducir riesgos, pero no sustituye a la PCB propia.

La diferencia es fundamental:

La placa de desarrollo demuestra que una tecnología puede funcionar.

La PCB propia demuestra que puede funcionar dentro del producto que estamos diseñando.

El paso de una placa de desarrollo a una PCB propia representa mucho más que cambiar una placa por otra más pequeña.

Durante el prototipo, el objetivo principal es aprender. Queremos descubrir si el microcontrolador elegido puede realizar la tarea, si los sensores proporcionan los datos esperados, si las comunicaciones funcionan y si la arquitectura general tiene sentido.

Cuando ese conocimiento ya existe, las preguntas cambian. ¿Podemos fabricar esta solución de forma repetible? ¿Podemos reducir su consumo? ¿Tiene el tamaño adecuado? ¿Podemos mantenerla durante años? ¿Está preparada para las condiciones de instalación? ¿Podemos probarla durante la fabricación? ¿Qué ocurre si un componente deja de estar disponible?

Es en ese momento cuando tiene sentido comenzar a diseñar una PCB propia.

La transición no consiste en abandonar todo lo que se ha hecho durante el prototipo. Al contrario, el prototipo proporciona información muy valiosa para tomar decisiones con menos incertidumbre. Pero esa información debe utilizarse para replantear la arquitectura desde las necesidades reales del producto.

La mejor PCB no es necesariamente la que más se parece a la placa con la que conseguimos que funcionara el primer prototipo. Es la que conserva aquello que demostró funcionar y elimina o modifica todo lo que solo era necesario para desarrollar y probar el sistema.

No existe un momento idéntico para todos los proyectos. En algunos casos tiene sentido diseñar una PCB propia muy pronto, mientras que en otros es preferible utilizar diferentes placas de desarrollo y módulos hasta reducir suficientemente las incertidumbres técnicas.

Una buena señal es que las principales decisiones funcionales ya estén razonablemente claras. Si todavía estamos cambiando de microcontrolador, sensor, tecnología de comunicación o arquitectura, probablemente una placa de desarrollo siga siendo una herramienta más eficiente.

Cuando la funcionalidad principal ya está validada y empiezan a aparecer requisitos relacionados con tamaño, consumo, coste, integración, fabricación o instalación, la PCB propia deja de ser simplemente una optimización y empieza a formar parte del propio desarrollo del producto.

También es importante no esperar demasiado. Si la PCB definitiva se plantea únicamente al final del proyecto, algunas decisiones tomadas durante el prototipo pueden resultar difíciles o costosas de trasladar al diseño final.

La transición ideal se produce cuando ya sabemos qué debe hacer el producto, pero todavía estamos a tiempo de replantear cómo debe construirse.

Pasar de una placa de desarrollo a una PCB propia es uno de los momentos en los que un proyecto electrónico cambia de naturaleza.

La placa de desarrollo permite avanzar rápido, experimentar y reducir la incertidumbre. Es una herramienta fundamental para demostrar que una determinada tecnología puede resolver el problema. Pero las decisiones que funcionan durante esa etapa no tienen por qué ser las decisiones adecuadas para un producto.

Cuando llega el momento de diseñar la PCB, aparecen nuevas prioridades: tamaño, consumo, coste, fiabilidad, disponibilidad de componentes, fabricación, test, mantenimiento y comportamiento en las condiciones reales de funcionamiento.

Por eso, la pregunta no debería ser simplemente cómo copiar en una PCB lo que ya funciona. La pregunta correcta es qué hemos aprendido con el prototipo y qué parte de esa solución merece realmente formar parte del producto.

Que una solución funcione durante el prototipo demuestra que la tecnología es viable. No demuestra que esa solución sea la adecuada para fabricar el producto.

El prototipo demuestra una idea. La PCB demuestra un producto.

Preguntas frecuentes

¿Puedo reutilizar el firmware de una placa de desarrollo en una PCB propia?

En muchos proyectos sí. Sin embargo, el firmware puede necesitar modificaciones cuando cambian los periféricos, las conexiones, la alimentación, el sistema de programación o las condiciones de funcionamiento. La reutilización del código depende de cuánto se mantenga la arquitectura de hardware original.

¿Es necesario diseñar una PCB propia si el prototipo funciona correctamente?

No siempre. Si el volumen es muy reducido o el producto no tiene restricciones importantes de tamaño, coste o integración, una placa de desarrollo puede ser suficiente. Cuando estas restricciones empiezan a ser relevantes, una PCB propia permite adaptar la electrónica a las necesidades reales del producto.

¿Por qué no puedo copiar directamente una placa de desarrollo?

Porque una placa de desarrollo está optimizada para facilitar el desarrollo y las pruebas, no necesariamente para el producto final. Puede incluir interfaces, conectores, reguladores o componentes auxiliares que son útiles durante el desarrollo pero innecesarios en el dispositivo definitivo.

¿Qué problemas pueden aparecer al pasar del prototipo a la PCB?

Pueden aparecer problemas relacionados con la alimentación, el consumo, el ruido eléctrico, la integridad de señal, la temperatura, las comunicaciones o la fabricación. También pueden surgir necesidades que no eran evidentes durante el prototipo, como disponer de puntos de test, mecanismos de actualización o sistemas de diagnóstico.

¿Cuándo debería empezar a diseñar mi PCB propia?

Lo habitual es comenzar cuando la arquitectura funcional está suficientemente validada y empiezan a ser importantes requisitos como tamaño, coste, consumo, integración o fabricación. No es necesario esperar a tener el producto completamente definido, ya que el propio diseño de la PCB puede ayudar a cerrar algunas decisiones de arquitectura.