Organizacin del Conocimiento

1
Organización del Conocimiento

• Pontificia Universidad Católica de Chile
• Departamento de Ciencia de la Computación
• IIC3552 Sistemas Embebidos de Tiempo Real
• Gerardo León Pablo Straub

2
Objetivo

• Aprender a revisar los detalles para iniciar un
  diseño
• En esta clase veremos
• Necesidad de organizar el conocimiento de
  detalles desde el comienzo
• Replantear especificaciones de hardware
• Entender las secuencias de operaciones
• Supuestos del sistema operativo

3
Necesidad de organizar detalles

• En el diseño tradicional de sistemas de
  información se parte del diagrama de contexto
  (flujos de datos a nivel cero) y se elaboran cada
  una de las burbujas a varios niveles
• Esto no funciona cuando hay una gran dependencia
  de los detalles de bajo nivel, como en todos los
  sistemas embebidos
• Por consiguiente debemos entender primero los
  detalles de bajo nivel
• Además casi siempre debemos aprender algo del
  software o del hardware

4
Detalles de bajo nivel

• Interesa tener una idea clara de
• Interfaces de hardware
• Interrupciones
• Memoria cantidad, tipo, mapas de memoria
• Sistema operativo, si corresponde
• Otros
• Cuando las herramientas de software o hardware
  son nuevas para nosotros, debemos entender
• Capacidades de la herramienta
• Instalación/configuración, hello-world
• Uso detallado de la herramienta

5
Por qué detalles ahora?

• Va en contra del diseño de arriba hacia abajo
  (top-down)
• En realidad es más bien de abajo hacia arriba
  (bottom-up)
• Después de esto volvemos al diseño top-down
• La razones principales son
• Hay una fuerte dependencia en el bajo nivel,
  incluyendo las capacidades del hardware
• Nuestro diseño debe adaptarse al hardware y RTOS
  disponibles
• Debemos aprender lo básico antes de diseñar

6
Paso 1. Especificaciones de hardware

• Propósito Documentar las interfaces de hardware
  desde el punto de vista del software
• Algunos temas documentados
• Interrupciones y qué eventos las disparan
• Cómo discriminar el evento que originó una
  interrupción
• Cómo detectar eventos mediante polling (qué
  cambia)
• Mapas de memoria
• Registros de interfaz de los dispositivos
• Esto debe documentarse en forma breve y con
  referencias a las especificaciones de hardware

7
Detalles de hardware

• El control de dispositivos se hace a través de
  registros
• Registros de escritura, lectura, y lectoescritura
• Para dar un comando el dispositivo se escribe en
  un registro
• Para averiguar la respuesta o el estado se lee de
  un registro
• El mapa de memoria dice dónde está la memoria RAM
  y ROM, y los registros del hardware
• Una interrupciónes usualmente se producen por
  varios eventos distintos
• Mediante los registros se averigua la causa
  específica

8
Paso 2. Secuencias de operaciones

• Propósito Verificar que sabemos cómo el software
  opera los dispositivos de hardware
• Se usan dos técnicas
• Diagrama de escenarios de uso
• Secuencias de pasos de eventos
• El diagrama de escenarios de uso muestra más
  claramente las causalidades y los iniciadores de
  eventos, pero es más difícil de editar
• Lo ideal es complementar esto con comentarios sí
  y sólo si estos son necesarios para entender los
  diagramas o secuencias

9
Escenarios/secuencias de uso

• Deben especificarse a lo menos
• Inicialización y/o reinicialización
• Uso de operaciones más típicas
• Uso de operaciones más complejas
• Ejemplo Módulo MCT5100 para TV digital
• Inicialización
• Cambio de canal
• Cambio de sub canal

10
Paso 3. Supuestos del RTOS

• Propósito Entender los servicios que se pueden
  dar por hechos
• Si se usa un RTOS, debemos enumerar los
  principales servicios que usaremos y referenciar
  la documentación relevante
• Si no, tendremos que hacer funciones de bajo
  nivel para accesar el hardware, usar relojes,
  tener múltiples procesos, etc.
• Debemos documentar qué tipos de estas funciones
  haremos los detalles de su uso los dejamos para
  después, en modo bottom-up

11
Resumen

• Antes de iniciar un diseño de arriba hacia abajo
  es necesario mirar el hardware desde el punto de
  vista del software
• Como el software depende mucho del hardware, no
  podemos hacer requisitos independientes de la
  máquina
• Es imprescindible entender cómo el software
  controla al hardware antes de diseñar el software
• Interrupciones, registros, secuencias de eventos,
  uso del sistema operativo
• La documentación de todo esto debe ser breve y
  completa usar tablas más que prosa