Sistemas Embebidos

Diego R. Páez Ardila

Msc. Ing. Biomédica

de 47
 AGENDA
Entorno de desarrollo Depuración

• Como se desarrollan aplicaciones • Simulación y depuración

• Jtag – pickit 3

El Hardware

• Características

Proyecto de Software

• Debugging
• Compilador

de 47
 Introducción

El objetivo es hacer que el diseño sea robusto, fácil

de mantener y flexible.

de 47
 Restricciones de Diseño en Sistemas Embebidos
A diferencia del software de escritura para una computadora de uso general, un sistema embebido
generalmente se envía ya integrado con todo el hardware que necesita

de 47
 Evolución del desarrollo de los sistemas embebidos
Lenguajes de programación

de 47 https://www.embedded.com/how-embedded-development-has-evolved-over-the-past-two-decades/
 Evolución del desarrollo de los sistemas embebidos
Arquitectura Procesadores

de 47 https://www.embedded.com/how-embedded-development-has-evolved-over-the-past-two-decades/
 Evolución del desarrollo de los sistemas embebidos
Arquitectura - Procesadores singlecore vs Dispositivos Multicore

de 47 https://www.embedded.com/how-embedded-development-has-evolved-over-the-past-two-decades/
 Evolución del desarrollo de los sistemas embebidos
Razones para la selección del procesador

de 47 https://www.embedded.com/how-embedded-development-has-evolved-over-the-past-two-decades/
 Evolución del desarrollo de los sistemas embebidos
Desafíos tecnológicos

de 47 https://www.embedded.com/how-embedded-development-has-evolved-over-the-past-two-decades/
 REQUERIMIENTOS - REQUIREMENTS
Los requisitos deben actuar como un plan para el desarrollo, con cada asignación de requisitos de
software de alto nivel a un requisito, diseño e implementación de nivel inferior.

0 de 47
 REQUERIMIENTOS - REQUIREMENTS
Surgen desafíos adicionales en el desarrollo de aplicaciones para automóviles conectados, dispositivos
médicos interactivos o aplicaciones industriales de IoT que cuestionan cuando el proceso de desarrollo
llega a su fin.

1 de 47
 REQUERIMIENTOS - REQUIREMENTS
Cualquier vulnerabilidad o compromiso descubierto en el sistema implica un requisito adicional para
contrarrestarlo, trayendo consigo un nuevo énfasis en la trazabilidad incluso en la fase de
mantenimiento del producto.
En este punto se requiere establecer un contrato a largo plazo, construir vínculos de seguimiento entre
los requisitos y los componentes de desarrollo desde el comienzo del proyecto.

2 de 47
 REQUERIMIENTOS - REQUIREMENTS
La implementación de un proceso de trazabilidad de requisitos integral, estratégico y automatizado
influye en los plazos y presupuestos del proyecto, puede evitar brechas entre la visión de la aplicación
de las partes interesadas y lo que finalmente se entrega, y resulta en un vehículo de soporte efectivo
para los sistemas conectados implementados.

La trazabilidad de los requerimientos garantiza que se implementen todos los requisitos y que todos los
elementos de desarrollo se puedan rastrear a uno más requisitos.

3 de 47
 RAZONES QUE PUEDE HACER FALLAR UN
PROYECTO
1. No hay suficientes recursos asignados a un proyecto: Un proyecto de 1 millón de líneas de
código requiere un staff de 2500 personas por mes. (1)
2. Iniciar la programación rápidamente: Funcionalidad y Diseño claramente definidos.
(Requirements).
3. El uso indisciplinado de C y C ++: Guiarse por un estándar - MISRA C; CERT-C 51.
4. Desconocer La Ciencia del Problema a Resolver: Ejemplo (Requirements).
5. Interfaz analógica-digital inadecuada: A menudo es mejor usar un diseño analógico cuidadoso
para minimizar el ruido antes de que llegue a un ADC. Es importante determinar los acoples de
impedancias o protecciones (circuitos aislados) entre las diferentes etapas de un sistema.

1. Programming Productivity, Capers Jones

https://www.embedded.com/how-embedded-projects-run-into-trouble-jacks-top-ten-number-ten/
4 de 47
 RAZONES QUE PUEDE HACER FALLAR UN
PROYECTO
6. Gerentes o lideres de equipo débiles: El gerente lidera el equipo. Redirige el esfuerzo cuando las
cosas se desvían. Se Asegura de que todos cumplan con las reglas. Aplicar: Planear: establezca los
objetivos y parámetros utilizados para alcanzarlos. Hacer: hacer el trabajo. Comprobar: asegúrese
de que el trabajo se realizó correctamente. Actuar: tomar medidas correctivas si es necesario.
7. Escribir código optimista: Suponer que todo va a salir bien, que no hay posibilidad de error.
Siempre diseñar pensando en el peor escenario.
8. Mala Planificación de Recursos: Una regla de oro sugiere, cuando los presupuestos lo permitan,
es recomendable duplicar las necesidades iniciales de recursos. Memoria extra, capacidad de
procesamiento, puertos de entrada/salida.
9. Cronograma Irreal:

(2) W. Edwards Deming : Plan-Do-Check-Act (PDCA)

5 de 47
https://www.embedded.com/how-embedded-projects-run-into-trouble-jacks-top-ten-number-ten/
 Desarrollo de un Sistema Embebido

6 de 47
 Desarrollo de un Sistema Embebido

El desarrollo de aplicaciones de escritorio se cuenta con IDE configurados para dicho proceso,
¿En un sistema embebido?

7 de 47
 Desarrollo de un Sistema Embebido
Un proyecto de sistemas embebidos se abordar por etapas y cada una de ellas debe contemplar:
Diseño, implementación y testeo (Depuración).

• Diseño • Diseño Producto • Diseño

Modelo • Implementación Prototipado • Implementación
Final
• Implementación
• Test
• Test • Test

Etapa de Simulación Etapa de Prototipado Etapa de Pre-Producción

8 de 47
 Desarrollo de un Sistema Embebido
En los sistemas Embebidos el desarrollo se hace en un sistema diferente (el "host") del que se va a
ejecutar (el "objetivo").

9 de 47
 Desarrollo de un Sistema Embebido - Debugging
- Depuración: En un PC se compila y hace depuración en el mismo PC. El sistema tiene recursos
suficientes para ejecutar el programa y para soportar la depuración al mismo tiempo. Todo el
proceso se realiza por medio de software.

0 de 47
 Desarrollo de un Sistema Embebido - Debugging
- Depuración: Para realizar depuración en un sistema embebido se debe contar con un Cross
Compiler y un Cross Debugger. El proceso se ejecuta desde el computador y se requiere una
interfaz como ICE o JTAG.

1 de 47
 Desarrollo de un Sistema Embebido - Debugging
- Depuración:
- Cross Compiler: Compilador capaz de crear código ejecutable para otra plataforma distinta a
aquella en la que el compilador se ejecuta.
- Cross Debugger: El depurador se ejecuta en el host y controla el programa que se está
ejecutando en el target. JTAG/ICE

2 de 47
 Desarrollo de un Sistema Embebido - Debugging
- Depuración: El microprocesador requiere entonces dedicar recursos para realizar la
depuración (Precio Aumenta). Por ejemplo, agregar un Breakpoint modifica el código para
que se detenga en un lugar especifico.
- Es posible utilizar un emulador (Precio Aumenta) o simulador (Limitaciones para CX,
ADC… )
- Es posible utilizar el printf como una forma ligera de depuración.

3 de 47
 Desarrollo de un Sistema Embebido - Debugging
- Técnicas de depuración: De forma general es importante asegurar el correcto funcionamiento
del hardware – PCB – antes de proceder a evaluar el firmware.
1. Simplificar Información Compleja: Reemplazar señales analógicas por digitales.
2. Evaluación por módulos (Divide y vencerás): Dividir el código en diferentes módulos
de los cuales se pueda esperar una respuesta que genera una acción en otro modulo.
3. Reducir los tiempos de ejecución: Modificar la frecuencia del reloj, es posible que algún
elemento no se esté sincronizando correctamente.
4. Cambiar una variable a la vez: Observar la respuesta del sistema ante el cambio de una
variable.
5. Crear modelos independientes: Crear funciones.
6. Iniciar la depuración desde un estado conocido: Incrementar los valores de entras que
hasta identificar el punto en donde el sistema genera un error.

4 de 47
 Herramientas para el Desarrollo
Para seleccionar las herramientas de desarrollo adecuadas es importante conocer el hardware base
que se utilizará:

5 de 47