commit e0bd1819493085c2c62cc0bf6b31b35fedec8769
parent 892c739c9af018840a689585cda3e7b31edfc668
Author: Martin Kloeckner <mjkloeckner@gmail.com>
Date: Wed, 22 Jul 2026 23:58:27 -0300
Agregar imágenes de las placas perforadas
Diffstat:
4 files changed, 48 insertions(+), 29 deletions(-)
diff --git a/MEMORIA.md b/MEMORIA.md
@@ -383,6 +383,25 @@ placa y al conector IDC.
<p><em>Figura 3.4: Placa perforada principal.</em></p>
</div>
+A continuación en las figuras 3.5, 3.6 y 3.7 se muestran imágenes de las placas
+armadas en placa perforada experimental, como se indico previamente en las
+figuras 3.3 y 3.4.
+
+<div align="center">
+ <img src="img/vista_sup_placa_con_modulos.jpg" style="padding: 10px;" width="600">
+ <p align="center"><em>Figura 3.5: Vista superior de placas con modulos en los zócalos.</em></p>
+</div>
+
+<div align="center">
+ <img src="img/vista_sup_placa_sin_modulos.jpg" style="padding: 10px;" width="600">
+ <p align="center"><em>Figura 3.6: Vista superior de placas sin modulos en los zócalos.</em></p>
+</div>
+
+<div align="center">
+ <img src="img/vista_inf_placa_sin_modulos.jpg" style="padding: 10px;" width="600">
+ <p align="center"><em>Figura 3.7: Vista inferior de placas sin modulos en los zócalos.</em></p>
+</div>
+
### 3.1.1. Placa NUCLEO
Como bien se mencionó, el trabajo se desarrolló utilizando la placa NUCLEO, esta
@@ -399,13 +418,13 @@ particular los periféricos que se utilizaron son los siguientes:
- GPIO: Botones (PC13, PA10, PB5, PB4), LEDs (PA5, PB10).
- DMA: Acceso directo a memoria para reducir uso de CPU.
-A continuación, en la figura 3.5 se muestra una imagen de los pines utilizados
+A continuación, en la figura 3.8 se muestra una imagen de los pines utilizados
del microcontrolador. Luego en la tabla 3.1 se muestran los nombres asignados y
las funciones para los que fueron utilizados.
<div align="center">
<img src="img/stm32_pinout_view.png" style="padding: 10px" align=center width="500px">
- <p><em>Figura 3.5: Pines utilizados de microcontrolador STM32F103RBT6.</em></p>
+ <p><em>Figura 3.8: Pines utilizados de microcontrolador STM32F103RBT6.</em></p>
</div>
| Pin | Etiqueta | Función |
@@ -493,7 +512,7 @@ mA y 250 mA, con picos de corriente durante la transmisión Wi-Fi de hasta 430 m
a 3,3 V, y dado que la corriente maxima suministrada por el regulador de la
placa NUCLEO es de 500 mA, se decidió utilizar un regulador externo de 3,3 V, el
AIC1117-33PT, montado sobre la misma placa perforada principal, suministrada por
-los 12 V de la fuente de tension externa.
+los 12 V de la fuente de tensión externa.
El firmware del modulo es ajeno al trabajo, pero se desarrollo de todas formas
utilizando PlatformIO y el framework Arduino. El firmware se desarrolló para que
@@ -525,22 +544,22 @@ temperatura considerablemente. Para solucionar esto se implementó un driver par
controlar el MOSFET con una señal PWM de mayor tensión, en particular 12 V de la
fuente externa. El driver utiliza un transistor TBJ 2N3904 actuando como llave
controlador por la señal PWM de la placa NUCLEO, como se puede ver en el
-esquemático de la figura 3.6.
+esquemático de la figura 3.9.
<div align="center">
<img src="img/npn_inv_mosfet_driver.png" style="padding: 10px" align=center width="700px">
- <p><em>Figura 3.6: Driver para el MOSFET que controla el calefactor.</em></p>
+ <p><em>Figura 3.9: Driver para el MOSFET que controla el calefactor.</em></p>
</div>
Este circuito es simple de implementar, pero invierte la señal PWM como se
-observar en la figura 3.7 a continuación. Existen versiones del circuito que
-agregan un circuito inversor implementado con otro transistor, pero en este caso
+observar en la figura 3.10 a continuación. Existe la posibilidad de agregar una
+etapa adicional inversora, implementado con otro transistor, pero en este caso
no es necesario ya que se puede invertir la polaridad de la señal PWM desde el
firmware de la placa NUCLEO.
<div align="center">
<img src="img/npn_inv_mosfet_driver_plot.png" style="padding: 10px" align=center width="700px">
- <p><em>Figura 3.7: Simulación del driver para el MOSFET que controla el calefactor.</em></p>
+ <p><em>Figura 3.10: Simulación del driver para el MOSFET que controla el calefactor.</em></p>
</div>
El calefactor del derretidor de miel se modeló como una carga resistiva pura,
@@ -556,13 +575,13 @@ que se obtienen mejores resultados con entre 30 mA y 45 mA de corriente.
Para suministrar esta corriente y evitar sobrecargar el regulador de la placa
NUCLEO, se implementó un circuito driver para alimentar al LED con la fuente de
-tension de 12 V externa, controlando solo el estado del led mediante una pequeña
+tensión de 12 V externa, controlando solo el estado del led mediante una pequeña
corriente subintrada por la placa NUCLEO. El circuito resultante se muestra en
-la figura 3.8 a continuación.
+la figura 3.11 a continuación.
<div align="center">
<img src="img/npn_led_driver.png" style="padding: 10px" align=center width="550px">
- <p><em>Figura 3.8: Driver para las luces indicadoras.</em></p>
+ <p><em>Figura 3.11: Driver para las luces indicadoras.</em></p>
</div>
El resistor RC se elige de manera tal que la corriente sobre el LED sea de
@@ -598,14 +617,14 @@ El firmware de la placa NUCLEO se compone de una aplicación que implementa un
ejecutor cíclico con 8 tareas asociadas. Estas tareas se organizan de acuerdo al
rol que cumplen: actuador, sensor o lógica del sistema.
-A continuación en la figura 3.9 se muestra un diagrama de bloques de las tareas
-del sistema y como interactúan entre ellas. La interacción puede ser a traves de
+A continuación en la figura 3.12 se muestra un diagrama de bloques de las tareas
+del sistema y como interactúan entre ellas. La interacción puede ser a través de
eventos o mediante la estructura global compartida `shared_data`.
<div align="center">
<img src="img/diagrama_de_bloques_firmware_nucleo_TA134.png" style="padding: 10px" align=center width="650px">
- <p><em>Figura 3.9: Diagrama de bloques firmware del sistema.</em></p>
+ <p><em>Figura 3.12: Diagrama de bloques firmware del sistema.</em></p>
</div>
<!--
@@ -650,14 +669,14 @@ estados o lógica correspondiente, si no hay ticks pendientes no hace nada.
Las tareas se comunican entre sí mediante dos mecanismos: eventos, a través de
buffers circulares con una interfaz dedicada para cada tarea; o mediante la
estructura global compartida `shared_data`. Que mecanismo utiliza cada tarea se
-puede observar en la figura 3.9, en la cual las flechas con lineas punteadas
+puede observar en la figura 3.12, en la cual las flechas con lineas punteadas
indican el mecanismo de acceso a la variable compartida y las flechas con lineas
continuas indican el mecanismo de eventos.
### 3.2.2. Tarea central
La tarea central, `task_system`, gestiona la lógica del sistema y la máquina de
-estados principal. A continuación en la figura 3.10 se muestra un diagrama de
+estados principal. A continuación en la figura 3.13 se muestra un diagrama de
estados de la maquina que implementa la tarea. Este diagrama es una versión
simplificada de la lógica que se implementa en la tarea, ya que no se muestran
los eventos que se envían a otras tareas, pero sirve para mostrar como se cambia
@@ -665,7 +684,7 @@ la funcionalidad de los botones de acuerdo al estado.
<div align="center">
<img src="img/system_statechart.png" style="padding: 10px" align=center width="800px">
- <p><em>Figura 3.10: Diagrama de estados de tarea central. Version simplificada.</em></p>
+ <p><em>Figura 3.13: Diagrama de estados de tarea central. Version simplificada.</em></p>
</div>
Se tienen los siguientes estados:
@@ -695,20 +714,20 @@ Además en esta tarea se gestiona:
### 3.2.3. Tarea para botones
En la tarea `task_buttons` se implementa una máquina de estados de anti-rebote
-para cada uno de los botones. En la figura 3.11 a continuación se muestra un
+para cada uno de los botones. En la figura 3.14 a continuación se muestra un
diagrama de estados de la maquina.
<div align="center">
<img src="img/button_statechart.png" style="padding: 10px" align=center width="700px">
- <p><em>Figura 3.11: Diagrama de estados para botones.</em></p>
+ <p><em>Figura 3.14: Diagrama de estados para botones.</em></p>
</div>
Al detectar una pulsación válida (flanco ascendente o descendente confirmado) se
-envía un evento a `task_system` y, aunque no se muestra en la figura 3.11, se
+envía un evento a `task_system` y, aunque no se muestra en la figura 3.14, se
envían eventos directamente a `task_buzzer` para que inmediatamente luego de
presionar el botón se active el buzzer, sin interactuar con la tarea central
`task_system`. Esto se observa también en el diagrama de bloques del firmware de
-la figura 3.9.
+la figura 3.12.
### 3.2.4. Tarea para el buzzer
@@ -719,11 +738,11 @@ calefactor).
Para controlar el buzzer se implementa una maquina de estados con los estados
`ST_BUZ_XX_OFF` y `ST_BUZ_XX_ON` con auto-apagado por timeout, tal como se
-observa en la figura 3.12 a continuación.
+observa en la figura 3.15 a continuación.
<div align="center">
<img src="img/buzzer_statechart.png" style="padding: 10px" align=center width="600px">
- <p><em>Figura 3.12: Diagrama de estados de buzzer.</em></p>
+ <p><em>Figura 3.15: Diagrama de estados de buzzer.</em></p>
</div>
### 3.2.5. Tarea para luces indicadoras
@@ -731,7 +750,7 @@ observa en la figura 3.12 a continuación.
En la tarea `task_leds` se controlan las luces indicadoras o LEDs (LD2, LD3)
permitiendo los modos: encendido, apagado, intermitente y un único pulso. Para
esto se implementa la maquina de estados cuyo diagrama de estados se muestra en
-la figura 3.13 a continuación, con los siguientes estados:
+la figura 3.16 a continuación, con los siguientes estados:
- `ST_LED_XX_OFF`: LED apagado.
- `ST_LED_XX_ON`: LED encendido fijo.
@@ -740,7 +759,7 @@ la figura 3.13 a continuación, con los siguientes estados:
<div align="center">
<img src="img/led_statechart.png" style="padding: 10px" align=center width="800px">
- <p><em>Figura 3.13: Diagrama de estados de luces indicadoras.</em></p>
+ <p><em>Figura 3.16: Diagrama de estados de luces indicadoras.</em></p>
</div>
El modo intermitente se utiliza para cuando el calefactor está activo, indicando
@@ -753,11 +772,11 @@ La tarea `task_menu`, gestiona la actualización del display LCD 16x2 según el
estado actual del sistema. Se implementa también una maquina de estados similar
a la implementada para el sistema, con estados similares, de manera tal que cada
estado del sistema tiene su correspondiente estado del menú y cada estado del
-menú define su contenido del display. En la figura 3.14 se muestran diferentes
+menú define su contenido del display. En la figura 3.17 se muestran diferentes
contenidos del display para diferentes estados.
Por ejemplo en estado reposo (estado del sistema `ST_SYS_IDLE`) con el
-calefactor apagado y un timer programado, como se muestra en la figura 3.14(b),
+calefactor apagado y un timer programado, como se muestra en la figura 3.17(b),
en la primer linea se muestra el estado del calefactor ("Off"), y en la segunda
linea el estado del timer ("[P]" si activo, " ", si no), la temperatura
actual, la temperatura deseada (entre paréntesis) y la unidad de la temperatura.
@@ -816,7 +835,7 @@ actual, la temperatura deseada (entre paréntesis) y la unidad de la temperatura
</table>
-<em>Figura 3.14: Interfaces mostradas en el display LCD 16x2.</em>
+<em>Figura 3.17: Interfaces mostradas en el display LCD 16x2.</em>
</div>
La comunicación con el LCD es asíncrona: las operaciones se encolan y se
@@ -919,7 +938,7 @@ siempre que DMA haya terminado, se enviando los bytes.
</table>
-<p><em>Figura 3.15: Pagina web del modulo remoto. Esquema de colores adaptado al
+<p><em>Figura 3.18: Pagina web del modulo remoto. Esquema de colores adaptado al
dispositivo.</em></p>
</div>
diff --git a/img/vista_inf_placa_sin_modulos.jpg b/img/vista_inf_placa_sin_modulos.jpg
Binary files differ.
diff --git a/img/vista_sup_placa_con_modulos.jpg b/img/vista_sup_placa_con_modulos.jpg
Binary files differ.
diff --git a/img/vista_sup_placa_sin_modulos.jpg b/img/vista_sup_placa_sin_modulos.jpg
Binary files differ.
