vault backup: 2025-02-20 10:32:35
49
.obsidian/workspace.json
vendored
@@ -4,21 +4,19 @@
|
||||
"type": "split",
|
||||
"children": [
|
||||
{
|
||||
"id": "2c84e434243956f6",
|
||||
"id": "6defc7c0173df765",
|
||||
"type": "tabs",
|
||||
"children": [
|
||||
{
|
||||
"id": "a3da3cbd7273dcb3",
|
||||
"id": "9ea8f5c88c43bf23",
|
||||
"type": "leaf",
|
||||
"state": {
|
||||
"type": "markdown",
|
||||
"type": "image",
|
||||
"state": {
|
||||
"file": "TERCERO/DAD/Teoria_2425.md",
|
||||
"mode": "source",
|
||||
"source": false
|
||||
"file": "TERCERO/SETR1/Pasted image 20250213120645.png"
|
||||
},
|
||||
"icon": "lucide-file",
|
||||
"title": "Teoria_2425"
|
||||
"icon": "lucide-image",
|
||||
"title": "Pasted image 20250213120645"
|
||||
}
|
||||
}
|
||||
]
|
||||
@@ -175,32 +173,34 @@
|
||||
"obsidian-git:Open Git source control": false
|
||||
}
|
||||
},
|
||||
"active": "a3da3cbd7273dcb3",
|
||||
"active": "a4eac8e6613b153b",
|
||||
"lastOpenFiles": [
|
||||
"Pasted image 20250203115240.png",
|
||||
"Pasted image 20250203115222.png",
|
||||
"Pasted image 20250203115134.png",
|
||||
"Pasted image 20250203114652.png",
|
||||
"TERCERO/DAD/Presentación 24-25.md",
|
||||
"TERCERO/PI/Pasted image 20250218110255.png",
|
||||
"TERCERO/PI/Pasted image 20250218110130.png",
|
||||
"TERCERO/PI/Pasted image 20250218110027.png",
|
||||
"TERCERO/PI/Pasted image 20250218110013.png",
|
||||
"TERCERO/PI/Pasted image 20250218105957.png",
|
||||
"TERCERO/SETR1/Pasted image 20250213105732.png",
|
||||
"TERCERO/SETR1/Pasted image 20250213110517.png",
|
||||
"TERCERO/SETR1/Pasted image 20250213120645.png",
|
||||
"TERCERO/PI/Teoria_2425.md",
|
||||
"TERCERO/DAD/Teoria_2425.md",
|
||||
"TERCERO/ATR2/Teoria_2425.md",
|
||||
"TERCERO/SETR1/Teoria_2425.md",
|
||||
"SEGUNDO/RC/Teoría_2324.md",
|
||||
"TERCERO/DAD/images/Pasted image 20250206105144.png",
|
||||
"conflict-files-obsidian-git.md",
|
||||
"TERCERO/DAD/images/Pasted image 20250206122521.png",
|
||||
"TERCERO/DAD/images",
|
||||
"TERCERO/DAD/Presentación 24-25.md",
|
||||
"TERCERO/ATR2",
|
||||
"Untitled",
|
||||
"conflict-files-obsidian-git.md",
|
||||
"TERCERO/DAD",
|
||||
"TERCERO/PI/Presentación 24-25.md",
|
||||
"TERCERO/SETR1/Presentación 24-25.md",
|
||||
"TERCERO/SETR1",
|
||||
"TERCERO/PI",
|
||||
"TERCERO/ATR1/images/Pasted image 20241211115747.png",
|
||||
"TERCERO/SPD/images/arriba.png",
|
||||
"TERCERO/SPD/images/abajo.png",
|
||||
"TERCERO/SPD/images/Pasted image 20241209194450.png",
|
||||
"TERCERO/SPD/images/Pasted image 20241209194420.png",
|
||||
"TERCERO/SPD/images/Pasted image 20241209181348.png",
|
||||
"TERCERO/SPD/images/Pasted image 20241209180114.png",
|
||||
"TERCERO/ATR1/Teoría_2425.md",
|
||||
"SEGUNDO/RC/Teoría_2324.md",
|
||||
"TERCERO/IA/Teoría_2425.md",
|
||||
"TERCERO/SPD/Teoría_2425.md",
|
||||
"TERCERO/SS/SS 24-25.md",
|
||||
@@ -217,12 +217,9 @@
|
||||
"TERCERO/IA/images",
|
||||
"TERCERO/ATR1/images",
|
||||
"TERCERO/ATR1/Welcome.md",
|
||||
"SEGUNDO/ADDA/MemoriaPI4_SMT4497.docx",
|
||||
"SEGUNDO/ADDA/ADDA 23-24.md",
|
||||
"SEGUNDO/ADDA/MODELOS.md",
|
||||
"SEGUNDO/ADDA/ADDA 15-05.md",
|
||||
"SEGUNDO/ADDA/ADDA 15-03.md",
|
||||
"SEGUNDO/ADDA/ADDA 13-03.md",
|
||||
"SEGUNDO/SO/Sin título.canvas"
|
||||
]
|
||||
}
|
||||
@@ -7,6 +7,7 @@ Establece las herramientas necesarias para **enrutar**, es decir, definir el cam
|
||||
Todo dispositivo en una red debe poseer una dirección IP para poder transmitir datos usando TCP/IP. Hay dos versiones de IP: IPv4 (32b) e IPv6 (128b). Las direcciones se pueden configurar de dos formas:
|
||||
- **Estática:** El usuario configura la IP en el host suministrada por el administrador de la red.
|
||||
- **Dinámica:** Se asigna automáticamente una IP al host mediante DHCP.
|
||||
La dirección IPv4 **NO ES LO MISMO** que la configuración IPv4. Para decir que un equipo tiene una configuración IPv4 correcta debe tener como mínimo dirección IP y máscara de red. Adicionalmente se suele especificar la dirección IP del gateway/puerta de enlace/router frontera.
|
||||
## <mark style="background: #ADCCFFA6;">2. Configuración dinámica de direcciones</mark>
|
||||
### <mark style="background: #FFB86CA6;">DHCP</mark>
|
||||
Hay varias formas de asignación dinámica de direcciones IP:
|
||||
@@ -45,3 +46,8 @@ Es usado por hosts y routers para comunicar información a nivel de red (informe
|
||||
| 5 | 0 | Redireccionamiento |
|
||||
| 8 | 0 | Petición de eco (ping) |
|
||||
| 11 | 0 | TTL excedido |
|
||||
## <mark style="background: #ADCCFFA6;">4. Traducción de direcciones</mark>
|
||||
Hay dos alternativas:
|
||||
- **Dinámica:** El router NAT asignará de forma temporal las IPs públicas cuando haya necesidad de "saltar" a internet.
|
||||
- El router tiene un rango de IPs asignables y además una tabla para guardar dichas asignaciones de IPs.
|
||||
- **Estática:** Se configuran las asignaciones de forma permanente por el administrador de la red.
|
||||
|
||||
@@ -80,4 +80,77 @@ Recursos virtualizados alojados en el centro de datos del proveedor. Para el usu
|
||||
- **Formato de los datos**
|
||||
- **Disponibilidad de los servidores**
|
||||
- **Acceso a los sistemas de forma remota**
|
||||
- **Posibilidad de ver los datos por muchas personas**
|
||||
- **Posibilidad de ver los datos por muchas personas**
|
||||
# <mark style="background: #FFF3A3A6;">TEMA 2: Modelos y arquitecturas</mark>
|
||||
## <mark style="background: #ADCCFFA6;">1. Introducción</mark>
|
||||
- Cómo interaccionan los módulos
|
||||
- Qué roles ejercen los procesos involucrados
|
||||
- Cuál es su correspondencia con nodos físicos
|
||||
- "Topología" de la aplicación distribuida
|
||||
### <mark style="background: #FFB86CA6;">Patrones más conocidos</mark>
|
||||
Las arquitecturas más frecuentes en SSDD son:
|
||||
- Cliente/Servidor
|
||||
- P2P
|
||||
- Editor/Subscriptor
|
||||
- Arquitectura de varios niveles
|
||||
## <mark style="background: #ADCCFFA6;">2. Arquitectura Cliente/Servidor</mark>
|
||||
Un equipo llamado servidor, realiza ciertas tareas denominadas **servicios**, como pueden ser ofrecer archivos, ejecutar comandos, enrutar datos a una impresora, etc. El cliente es el equipo que **solicita los servicios**.
|
||||
### <mark style="background: #FFB86CA6;">Desventajas</mark>
|
||||
El servidor, a medida que se necesita escalabilidad, puede transformarse en un cuello de botella y por tanto convirtiéndose el servidor en un punto crítico de fallo.
|
||||
### <mark style="background: #FFB86CA6;">Características varias</mark>
|
||||
El servidor ofrece una colección de servicios que el cliente debe conocer. Normalmente se realizan peticiones específicas al servidor: recurso, operación, etc.
|
||||
### <mark style="background: #FFB86CA6;">Reparto de funcionalidad</mark>
|
||||
Respecto al "grosor" (cantidad de trabajo que realiza) del cliente:
|
||||
- **Ligeros (Thin/Lean/Slim Client):**
|
||||
- Menor coste de operación y mantenimiento
|
||||
- Mejor seguridad
|
||||
- **Pesados (Thick/Fat/Rich Client):**
|
||||
- Mayor autonomía a cambio de gastar más recursos locales
|
||||
- Mejor escalabilidad: el cliente gasta menos recursos de red y servidor
|
||||
- Más ágil en respuesta al usuario
|
||||
### <mark style="background: #FFB86CA6;">Conexiones</mark>
|
||||
En el caso de usar esquema con conexión:
|
||||
- 1 conexión por cada petición: 1 operación C-S
|
||||
- Más sencillo pero mayor sobrecarga (9 mensajes TCP por petición)
|
||||
Como solución: varias peticiones usan una misma conexión
|
||||
- Más complejo pero menor sobrecarga
|
||||
- 1 cliente 1 conexión
|
||||
### <mark style="background: #FFB86CA6;">Estados</mark>
|
||||
- **Ventajas de servicios con estado**
|
||||
- Mensajes de petición más cortos
|
||||
- Mejor rendimiento (pero información en memoria)
|
||||
- Favorece optimización del servicio con predicciones
|
||||
- **Ventajas de servicio sin estado**
|
||||
- Más tolerante a fallos
|
||||
- Peticiones autocontenidas
|
||||
- Reduce el nº de mensajes
|
||||
- Más económicos para el servidor (menos uso de memoria)
|
||||
- **Servicio sin estado (stateless) de la propuesta REST**
|
||||
- El estado que se almacena lo hace el cliente y lo envía al servidor (ej: HTTP+cookies)
|
||||
## <mark style="background: #ADCCFFA6;">2. Arquitectura Publisher/Subscriber</mark>
|
||||
Es un sistema de eventos distribuidos:
|
||||
- Un subscriptor S (subscriber) muestra interés por eventos y se subscribe a ciertos eventos.
|
||||
- Un editor P (publisher) genera un evento y se lo envía a subscriptores interesados en el mismo.
|
||||
- Operaciones:
|
||||
- Subscribir \[alta/baja\] (S$\rightarrow$)
|
||||
- Publicar (P$\rightarrow$)
|
||||
- Notificar ($\rightarrow$S)
|
||||
### <mark style="background: #FFB86CA6;">Características</mark>
|
||||
- Paradigma asíncrono y desacoplado espacialmente
|
||||
- Editores y subscriptores no se conocen entre sí (a diferencia de C-S)
|
||||
- En algunos casos también desacoplado temporalmente
|
||||
- Normalmente es _push_ (subscriptor recibe notificaciones), y como alternativa está el _pull_ subscriptor pregunta si hay mensajes, pero no es nada escalable.
|
||||
## <mark style="background: #ADCCFFA6;">3. Arquitectura P2P</mark>
|
||||
- **Desestructurados:**
|
||||
- Ubicación de recursos impredecible
|
||||
- Cada nodo posee recursos
|
||||
- Corresponden a sistemas con nodos más autónomos
|
||||
- **Estructurados:**
|
||||
- Ubicación de recursos predecibles y dependiente de la topología
|
||||
- Generalmente definida por función hash distribuida para buscar la máquina que posee el recurso
|
||||
- Corresponden a sistemas con nodos más cooperativos
|
||||
# <mark style="background: #FFF3A3A6;">TEMA 3: Procesos locales</mark>
|
||||
## <mark style="background: #ADCCFFA6;">1. Sockets</mark>
|
||||
Un **socket** es un método para comunicar programas entre sí mediante el paradigma C-S. Un socket también es una dirección en internet tipo IP:puerto.
|
||||
## <mark style="background: #ADCCFFA6;">2. Servlets</mark>
|
||||
Programa Java que se ejecuta en un servidor Web y construye o sirve páginas web. De esta forma se pueden construir páginas dinámicas, basadas en diferentes fuentes variables.
|
||||
|
Before Width: | Height: | Size: 344 KiB After Width: | Height: | Size: 344 KiB |
|
Before Width: | Height: | Size: 168 KiB After Width: | Height: | Size: 168 KiB |
|
Before Width: | Height: | Size: 330 KiB After Width: | Height: | Size: 330 KiB |
|
Before Width: | Height: | Size: 268 KiB After Width: | Height: | Size: 268 KiB |
BIN
TERCERO/DAD/images/Pasted image 20250206105144.png
Normal file
|
After Width: | Height: | Size: 8.7 KiB |
BIN
TERCERO/DAD/images/Pasted image 20250206111909.png
Normal file
|
After Width: | Height: | Size: 81 KiB |
BIN
TERCERO/DAD/images/Pasted image 20250206122521.png
Normal file
|
After Width: | Height: | Size: 79 KiB |
BIN
TERCERO/PI/Pasted image 20250218105957.png
Normal file
|
After Width: | Height: | Size: 101 KiB |
BIN
TERCERO/PI/Pasted image 20250218110013.png
Normal file
|
After Width: | Height: | Size: 88 KiB |
BIN
TERCERO/PI/Pasted image 20250218110027.png
Normal file
|
After Width: | Height: | Size: 97 KiB |
BIN
TERCERO/PI/Pasted image 20250218110130.png
Normal file
|
After Width: | Height: | Size: 70 KiB |
BIN
TERCERO/PI/Pasted image 20250218110255.png
Normal file
|
After Width: | Height: | Size: 63 KiB |
32
TERCERO/PI/Teoria_2425.md
Normal file
@@ -0,0 +1,32 @@
|
||||
# <mark style="background: #FFF3A3A6;">TEMA 1: Introducción</mark>
|
||||
## <mark style="background: #ADCCFFA6;">1. Estructura básica de un computador</mark>
|
||||
![[Pasted image 20250218105957.png|400]]
|
||||
![[Pasted image 20250218110013.png|400]]
|
||||
![[Pasted image 20250218110027.png|450]]
|
||||
## <mark style="background: #ADCCFFA6;">2. Entrada/Salida</mark>
|
||||
![[Pasted image 20250218110130.png|500]]
|
||||
El sistema de E/S tiene varias funciones:
|
||||
- **Direccionamiento:** para seleccionar el dispositivo
|
||||
- **Sincronización:** para iniciar la transferencia
|
||||
- **Transferencia:** método de transferencia
|
||||
#### <mark style="background: #D2B3FFA6;">Interfaz E/S (simplificada)</mark>
|
||||
|
||||
![[Pasted image 20250218110255.png|500]]
|
||||
### <mark style="background: #FFB86CA6;">Entrada/Salida programada</mark>
|
||||
- La comunicación siempre la inicia la CPU
|
||||
- Método de _queries_ para conocer el estado del módulo E/S
|
||||
- **Inconvenientes:**
|
||||
- La CPU tiene que gastar tiempo de ejecución en atender a los procesos E/S
|
||||
- **Ventajas:**
|
||||
- Alta velocidad
|
||||
Hay dos tipos de direccionamiento:
|
||||
- **Mapeado en memoria:** la CPU ve los dispositivos E/S como posiciones de memoria. Es más sencillo pero se pierde espacio de memoria.
|
||||
- **Aislado:** las direcciones E/S se diferencian mediante una señal de control.
|
||||
### <mark style="background: #FFB86CA6;">Entrada/Salida por interrupciones</mark>
|
||||
- Un dispositivo puede llamar la atención de la CPU:
|
||||
- El módulo E/S provoca la interrupción
|
||||
- La CPU le comunica un orden de E/S y vuelve a lo suyo (cambio de contexto)
|
||||
- Cuando la subrutina de E/S se ejecuta el módulo de E/S lo comunica para que el CPU decida cuál será su próxima acción y estado.
|
||||
- **Ventajas:**
|
||||
- Atención inmediata
|
||||
- El CPU puede hacer otras cosas mientras el dispositivo E/S está ocupado
|
||||
BIN
TERCERO/SETR1/Pasted image 20250213105732.png
Normal file
|
After Width: | Height: | Size: 4.3 KiB |
BIN
TERCERO/SETR1/Pasted image 20250213110517.png
Normal file
|
After Width: | Height: | Size: 61 KiB |
BIN
TERCERO/SETR1/Pasted image 20250213120645.png
Normal file
|
After Width: | Height: | Size: 109 KiB |
123
TERCERO/SETR1/Teoria_2425.md
Normal file
@@ -0,0 +1,123 @@
|
||||
# <mark style="background: #FFF3A3A6;">TEMA 1: Introducción y conceptos básicos</mark>
|
||||
## <mark style="background: #ADCCFFA6;">1. Clasificación</mark>
|
||||
Los sistemas de propósito general se pueden diferenciar de los sistemas empotrados, pero no es una clasificación estricta sino más bien un rango o gradiente.
|
||||
![[Pasted image 20250206105144.png]]
|
||||
- **Sistema tiempo real VS Sistema convencional:** Freno ABS frente a procesador de texto.
|
||||
- **Sistema de uso industrial VS Producto de consumo:** Máquina de empaquetado de patatas fritas frente a consola de videojuegos.
|
||||
- **Sistema dirigido por eventos VS Sistema dirigido por datos:** Freno ABS frente a MP3.
|
||||
- Procesadores digitales de señal (DSP): para procesar flujos de datos.
|
||||
- **Sistema artesanal/prototipo VS Sistema industrializado:** Puerta de garaje autoconstrucción frente a lavadora comercial.
|
||||
### <mark style="background: #FFB86CA6;">Dispositivos comunes</mark>
|
||||
- PC sobremesa.
|
||||
- Autómatas Programables Industriales (API) o Controladores Lógicos Programables (PLC).
|
||||
- Microcontroladores.
|
||||
- Procesadores Digitales de Señal (DSP).
|
||||
- Lógica programable (FPGAs, PLDs).
|
||||
- Sistemas _Full Custom_.
|
||||
### <mark style="background: #FFB86CA6;">Principales diferencias GPC VS Embedded System</mark>
|
||||
<strong><span style="color:red;">[EXAMEN]</span></strong>
|
||||
![[Pasted image 20250206111909.png]]
|
||||
## <mark style="background: #ADCCFFA6;">2. Características especiales de los sistemas empotrados</mark>
|
||||
### <mark style="background: #FFB86CA6;">Memoria</mark>
|
||||
- Siempre ejecutan el mismo código: necesitan normalmente más ROM que RAM, el código se encuentra en la ROM y el _stack_ en la RAM, aunque algunos no tienen.
|
||||
- <strong><span style="color:red;">[EXAMEN]</span></strong> Las variables en la ROM son constantes, pero ¿las globales en RAM se inicializan explícitamente?
|
||||
- Si la variable la declaramos e inicializamos a la vez, mientras tengamos el microcontrolador conectado al IDE, es válido. Sin embargo, al funcionar el microcontrolador independientemente, si queremos inicializar una variable global, deberíamos declararla y luego inicializarla dentro del código, ya que no hay intérprete ni nada que la inicialice en tiempo de ejecución. **ACTUALMENTE** se soluciona con un código _startup_ antes del `main` para inicializar este tipo de variables globales. En el código _startup_ también se inicializan punteros de pila.
|
||||
- Se puede usar la palabra reservada `const` para establecer que ese código está en ROM, y en este caso se podría inicializar en la declaración.
|
||||
- No requiere soporte de almacenamiento tipo HD.
|
||||
- Pueden poseer o no protección para acceder a datos/código internos.
|
||||
- Por compatibilidad y limitaciones, uso de bancos de memoria.
|
||||
### <mark style="background: #FFB86CA6;">Datos e instrucciones</mark>
|
||||
- Preparados para manipulación de bits
|
||||
- El ISA suele ser recortado: instrucciones de salto condicional, instrucciones aritméticas, signo, modos de direccionamiento, registro de estado "pobre"...
|
||||
### <mark style="background: #FFB86CA6;">Fallos y robustez</mark>
|
||||
- No suelen ser sistemas atendidos, el usuario no es consciente de que es un computador.
|
||||
- Implementan sistemas de tolerancia y recuperación de fallos
|
||||
- Se han ampliado los rangos de funcionamiento en cuanto a temperatura, radiación, niveles de alimentación, etc
|
||||
### <mark style="background: #FFB86CA6;">Consumo</mark>
|
||||
- Optimizados para bajo consumo
|
||||
- Utilización en aplicaciones móviles modos de bajo consumo (ej: mando a distancia)
|
||||
### <mark style="background: #FFB86CA6;">Programación y desarrollo</mark>
|
||||
- Difícil de depurar
|
||||
- Siempre ejecutan el mismo software
|
||||
- Los programas no suelen acabar `while(1) {...}`
|
||||
### <mark style="background: #FFB86CA6;">Tamaño y precio</mark>
|
||||
- En grandes cantidades son muy baratos
|
||||
- Multitud de formatos para satisfacer la industria
|
||||
## <mark style="background: #ADCCFFA6;">3. Sistemas tiempo real</mark>
|
||||
|
||||
![[Pasted image 20250206122521.png]]
|
||||
### <mark style="background: #FFB86CA6;">Sistema Tiempo Real</mark>
|
||||
Sistema informático en el que la corrección del resultado depende tanto de su validez lógica como del instante en que se produce.
|
||||
### <mark style="background: #FFB86CA6;">Computador Empotrado</mark>
|
||||
Computador integrado en algún mecanismo físico para implementar un tipo de control de procesos o toma de datos.
|
||||
### <mark style="background: #FFB86CA6;">Sistema Empotrado Tiempo Real</mark>
|
||||
Sistema informático que ejecuta alguna aplicación de tiempo real y tiene al menos un elemento que sea un computador empotrado.
|
||||
<div class="nota">
|
||||
<h1>Variables en C</h1>
|
||||
<ul>
|
||||
<li><strong>Estáticas: </strong><code>heap</code>, memoria principal</li>
|
||||
<li><strong>Automáticas: </strong>pila</li>
|
||||
<li><strong>Dinámicas: </strong>asignación y liberación de memoria con <code>malloc</code> y <code>free</code><br>Como ejemplo de esto:<br><code>int* a = malloc(10*sizeof(int));</code></li><h3>¿Se puede reservar dinámicamente en SSEE?</h3><p>Como la cantidad de memoria en los SSEE es limitada, no es que no se pueda usar, pero hay que tener mucho cuidado al usar la asignación dinámica ya que puede llegar un momento en que se pida reservar más memoria de la disponible. Para asegurar que el sistema sea seguro, se recomienda usar <strong>variables estáticas</strong></p>
|
||||
</ul>
|
||||
</div>
|
||||
### <mark style="background: #FFB86CA6;">Tareas</mark>
|
||||
Esencialmente hay dos tipos de tareas:
|
||||
- **Esencial:** presenta restricciones temporales
|
||||
- **Críticas:** SIEMPRE se debe completar dentro del plazo
|
||||
- **Acríticas:** puede completarse fuera de plazo "sin problemas"
|
||||
- **No esencial:** no presenta restricciones temporales
|
||||
Dadas estas definiciones, se pueden clasificar los sistemas de tiempo real en **duros** y **blandos**:
|
||||
- **STR Duro:** al menos posee una tarea crítica
|
||||
- **STR Blando:** todas sus tareas son acríticas
|
||||
### <mark style="background: #FFB86CA6;">Técnicas de programación</mark>
|
||||
#### 1. Procesamiento secuencial (`while(1)`)
|
||||
```C
|
||||
int main()
|
||||
{
|
||||
while(1)
|
||||
{
|
||||
TareaA();
|
||||
TareaB();
|
||||
TareaC();
|
||||
TareaI(); // añadida temporización
|
||||
}
|
||||
}
|
||||
```
|
||||
#### 2. Foreground/Background
|
||||
![[Pasted image 20250213110517.png|500]]
|
||||
#### 3. RTOS
|
||||
|
||||
# <mark style="background: #FFF3A3A6;">TEMA 2: Estructura de los μC</mark>
|
||||
## <mark style="background: #ADCCFFA6;">1. Conceptos generales</mark>
|
||||
### <mark style="background: #FFB86CA6;">Familias de μC</mark>
|
||||
- Al igual que los GPP, se agrupan en familias.
|
||||
- Suelen poseer un núcleo común, pero hay más diversidad dentro de las familias.
|
||||
- Los fabricantes sacan una gran variedad para cubrir cada necesidad.
|
||||
- Familias históricas 8 bits: Intel 8051, Motorola 68XX, Atmel AVR, etc.
|
||||
- Familias 32 bits: ARM, Freescale 683XX, etc.
|
||||
### <mark style="background: #FFB86CA6;">Estructura de memoria</mark>
|
||||
- Desde el punto de vista del programador, hay al menos dos tipos de memoria (ROM y RAM).
|
||||
- Si se usa la arquitectura Harvard, las instrucciones para acceder a código o datos pueden ser distintas, y a los registros internos se le pueden asociar punteros de diversos tamaños.
|
||||
![[Pasted image 20250213120645.png|500]]
|
||||
La más adecuada para μC es la de Harvard ya que los μC suelen tener ROM/Flash para código y memoria de datos.
|
||||
- En un μC puede estar justificado el que haya múltiples elementos con buses de direcciones distintos:
|
||||
- Memoria Programa Interna
|
||||
- Memoria Datos Interna
|
||||
- Memoria Programa Externa
|
||||
- Memoria Datos Externa
|
||||
- Registros E/S
|
||||
- Direccionamiento bit a bit en memoria y periféricos
|
||||
<div class="nota">
|
||||
<h1>Nota</h1>
|
||||
<p><strong>Single Chip (Microcontrolador, MCU): </strong>RAM y ROM internas</p>
|
||||
<p><strong>Modo expandido (Microprocesador, MPU): </strong>se sacan desde el chip buses de datos, direcciones y líneas de control hacia fuera para RAM y ROM externas</p>
|
||||
</div>
|
||||
|
||||
## <mark style="background: #ADCCFFA6;">2. Intel 8051</mark>
|
||||
|
||||
## <mark style="background: #ADCCFFA6;">3. Cortex M</mark>
|
||||
|
||||
## <mark style="background: #ADCCFFA6;">4. Manipulación de bits</mark>
|
||||
|
||||
## <mark style="background: #ADCCFFA6;">5. Interrupciones</mark>
|
||||
|
||||
@@ -1,17 +0,0 @@
|
||||
# Conflicts
|
||||
Please resolve them and commit them using the commands `Git: Commit all changes` followed by `Git: Push`
|
||||
(This file will automatically be deleted before commit)
|
||||
[[#Additional Instructions]] available below file list
|
||||
|
||||
- Not a file: .obsidian/workspace.json
|
||||
|
||||
# Additional Instructions
|
||||
I strongly recommend to use "Source mode" for viewing the conflicted files. For simple conflicts, in each file listed above replace every occurrence of the following text blocks with the desired text.
|
||||
|
||||
```diff
|
||||
<<<<<<< HEAD
|
||||
File changes in local repository
|
||||
=======
|
||||
File changes in remote repository
|
||||
>>>>>>> origin/main
|
||||
```
|
||||