Implementaci
´
on de un Adaptador de Video por
Software en Microcontrolador de Doble N
´
ucleo
Implementation of a Software Video Adapter in Dual Core Microcontroller
Santiago Germino
Laboratorio de Sistemas Embebidos
Facultad de Ingenier
´
ıa - UBA
Buenos Aires, Argentina
sgermino@retro-ciaa.com
Resumen—En este art
´
ıculo se presentan las consideraciones
y t
´
ecnicas utilizadas para el dise
˜
no e implementaci
´
on por
software de un adaptador de video de alta performance en
un kit de desarrollo con microcontrolador de doble n
´
ucleo. Se
utiliza un n
´
ucleo exclusivamente para tal fin mientras que el
segundo ejecuta la aplicaci
´
on de forma concurrente.
Palabras clave: computaci
´
on gr
´
afica; adaptador de video por
software; doble n
´
ucleo.
Abstract—This article presents the considerations and
techniques used for the design and software implementation
of a high-performance video adapter in a development kit
with a dual-core microcontroller, dedicating a core exclusively
for that purpose while the second one is used to execute the
application.
Keywords: computer graphics; software video adapter;
dual core.
I. INTRODUCCI
´
ON
Un adaptador de video integra memoria para contener
al menos una pantalla completa o cuadro de animaci
´
on,
capacidad de generar una se
˜
nal de video y un puerto para
conectar dicha se
˜
nal a un monitor compatible [1].
Su implementaci
´
on por software requiere un uso intensivo
de recursos de memoria, manejo de puertos de E/S y
temporizado preciso. Estas tareas pueden exigir hasta el
95 % del tiempo de un n
´
ucleo del microcontrolador. Por
este motivo, un microcontrolador con al menos dos n
´
ucleos
permite una implementaci
´
on eficaz.
El kit de desarrollo educativo EDU-CIAA-NXP [2] (Fig.
1) pertenece al proyecto CIAA o Computadora Indus-
trial Abierta Argentina. Integra un microcontrolador NXP
LPC4337JBD144 de 204 MHz, un n
´
ucleo ARM Cortex-M0,
un n
´
ucleo ARM Cortex-M4F, 136 KiB de SRAM y 1 MiB
de Flash. La memoria SRAM y Flash es compartida por
ambos n
´
ucleos [3].
El proyecto RETRO-CIAA [4] es una placa de expansi
´
on
o ((poncho)) (Fig. 2) que suma conectividad y un nuevo
firmware en donde se implement
´
o un adaptador de video
de alta prestaci
´
on corriendo en el n
´
ucleo Cortex-M0 de la
EDU-CIAA-NXP.
II. MOTIVACI
´
ON Y OBJETIVOS
El uso de una interfaz gr
´
afica de usuario est
´
a ampliamente
extendido en sistemas embebidos. Aun as
´
ı, debido a las res-
tricciones de memoria, procesamiento o consumo de energ
´
ıa,
Fig. 1. Kit de desarrollo EDU-CIAA-NXP.
Fig. 2. Placa de expansi
´
on RETRO-CIAA sobre EDU-CIAA-NXP.
no siempre es factible utilizar librer
´
ıas gr
´
aficas no dise
˜
nadas
u optimizadas para funcionar con dichas limitaciones.
La computaci
´
on gr
´
afica trata sobre las t
´
ecnicas y algorit-
mos utilizados para generar gr
´
aficos por computadora. Pro-
mover su conocimiento y pr
´
actica seria imprescindible para
lograr una eficiente implementaci
´
on de funciones gr
´
aficas
en sistemas con escasos recursos.
El kit EDU-CIAA-NXP se utiliza como herramienta edu-
cativa en diferentes secundarios, terciarios y carreras uni-
versitarias. A la fecha, mas de 2500 unidades se encuentran
en poder de instituciones y particulares. La mayor
´
ıa de
proyectos, ejemplos y ejercicios disponibles [5], [6] solo
utilizan el n
´
ucleo Cortex-M4F mientras que el Cortex-M0
se mantiene continuamente en estado de reset.
Estas observaciones motivaron a la b
´
usqueda de agregar
valor y prestaciones a la EDU-CIAA-NXP, utilizando sus
capacidades ociosas para incrementar su utilidad como he-
rramienta did
´
actica y posibilitar la pr
´
actica de computaci
´
on
gr
´
afica.
El objetivo planteado se logr
´
o sum
´
andole al kit un
Recibido: 30/09/19; Aceptado: 13/01/20
https://doi.org/10.37537/rev.elektron.4.1.91.2020
Original Article
Creative Commons License - Attribution-NonCommercial-
NoDerivatives 4.0 International (CC BY-NC-ND 4.0)
Revista elektron, Vol. 4, No. 1, pp. 21-26 (2020)
ISSN 2525-0159
21
TABLA I
BANCOS CONTIGUOS DE MEMORIA SRAM EN EL
MICROCONTROLADOR LPC4337JBD144 DE NXP.
Tama
˜
no Bus Direcci
´
on
32 KiB LOCAL 10 00 00 00 h
40 KiB LOCAL 10 08 00 00 h
64 KiB AHB 20 00 00 00 h
adaptador de video por software -entre otras capacidades
multimedia- mediante una expansi
´
on de bajo costo desarro-
llada por el proyecto RETRO-CIAA. Este art
´
ıculo presenta
la t
´
ecnica en base a las decisiones de dise
˜
no del proyecto.
III. DISE
˜
NO E IMPLEMENTACI
´
ON
A continuaci
´
on se enumeran los elementos que componen
esta implementaci
´
on y los criterios de dise
˜
no utilizados.
III-A. Memoria de video
El framebuffer es un segmento contiguo en memoria que
contiene los pixeles (m
´
ınima unidad de una imagen digital)
que componen el cuadro de animaci
´
on a visualizar [1].
Modificar la memoria del cuadro visible produce inesta-
bilidad en la imagen en pantalla. Modificar s
´
olo en los
per
´
ıodos inactivos de la se
˜
nal de video reduce la capacidad
de dibujo en un 95 %. En consecuencia se decidi
´
o utilizar
un esquema superador denominado double-buffering [1]: dos
buffers iguales, uno visible y otro oculto en proceso de
actualizaci
´
on. Los buffers intercambian roles toda vez que
la se
˜
nal de video termina de emitir un cuadro de animaci
´
on.
Al ser una relaci
´
on de compromiso, con esta t
´
ecnica
se gana en estabilidad y fluidez, pero se sacrifican otros
aspectos como una mayor cantidad de memoria disponible
para la aplicaci
´
on o una mayor resoluci
´
on en un solo
framebuffer de mayor tama
˜
no.
III-B. Resoluci
´
on
La resoluci
´
on de una imagen se define como su cantidad
de pixeles en ancho y alto. En esta implementaci
´
on cada uno
de los dos framebuffers tienen una resoluci
´
on de 256x144
pixeles. Esta resoluci
´
on surge como compromiso entre la
escasa SRAM en el microcontrolador LPC4337JBD144 de
NXP y los bancos de memoria disponibles seg
´
un se observa
en la Tabla I.
Ademas, la resoluci
´
on utilizada es coherente con la capa-
cidad del microprocesador para manejar cierta cantidad de
pixeles con soltura y es m
´
ultiplo de la resoluci
´
on de la se
˜
nal
de video generada por el adaptador.
III-C. Formato de pixel
Un pixel contiene la informaci
´
on de color en un punto
discreto de la imagen digital. El formato refiere a la cantidad
total de bits por pixel y al reparto de esos bits entre
los componentes rojo, verde y azul que describen color
mediante la intensidad de primarios aditivos.
Para este proyecto se decidi
´
o utilizar un formato de pixel
de 8 bit repartidos en 3 bit para rojo, 3 bit para verde y
2 bit para azul, lo que configura un formato RGB 3:3:2 tal
como se observa en la Fig. 3. Con 8 bit se obtiene una
combinaci
´
on total de 2
8
= 256 colores disponibles.
4
G2
5
R0
6
R1
7
R2
0
B0
1
B1
2
G0
3
G1
MSB LSB
Framebu er[0]
Pixel 0
4
G2
5
R0
6
R1
7
R2
0
B0
1
B1
2
G0
3
G1
MSB LSB
Framebu er[1]
Pixel 1
4
G2
5
R0
6
R1
7
R2
0
B0
1
B1
2
G0
3
G1
MSB LSB
Framebu er[n]
Pixel n
...
Fig. 3. Formato de pixel y pixeles en el framebuffer.
400 450 500 550 600 650 700
Longitud de onda (nm)
Respuesta
S M L
Fig. 4. Respuesta normalizada de los conos tipo S, M y L del ojo humano.
Scanline
HSYNC
H. Front Porch
V. Front Porch
V. Back Porch
Area visible
H. Back Porch
VSYNC
Fig. 5. Escaneo raster de una se
˜
nal de video.
Se asignan 2 bit al componente azul debido a que la
sensibilidad del ojo humano (conos tipo S) es menor en
ese rango de longitud de onda del espectro visible [7]. Esto
puede apreciarse en la Fig. 4.
En este punto ya es posible calcular la cantidad de
SRAM necesaria para implementar el adaptador de video
por software (1) donde F
res
es la resoluci
´
on del framebuffer,
F
n
la cantidad de framebuffers y P
bits
la cantidad de bits del
formato de pixel.
F
res
× F
n
× P
bits
8
=
(256 × 144) × 2 × 8
8
= 72 KiB (1)
A continuaci
´
on se revisan las se
˜
nales de video necesarias
y su interfaz el
´
ectrica.
III-D. Raster scan
El proceso conocido como raster scan [1] define el tem-
porizado de los elementos de una se
˜
nal de video. La se
˜
nal
recorre la pantalla de izquierda a derecha -cada recorrido
es una linea de pixeles o scanline- y de arriba hacia abajo
-donde un barrido completo de todas las scanlines completa
un cuadro de imagen-. Al final de cada linea se genera
una demora que se denomina horizontal blanking interval.
Del mismo modo, al terminar cada cuadro se genera una
demora denominada vertical blanking interval. Los blanking
intervals son
´
areas inactivas en donde no se dibujan pixeles.
El intervalo de blanking horizontal se divide en tres par-
tes: front porch, pulso de sincronismo horizontal (HSYNC)
y back porch. El intervalo de blanking vertical se divide en
front porch, pulso de sincronismo vertical (VSYNC) y back
porch. En la Fig. 5 se observa esta din
´
amica.
Revista elektron, Vol. 4, No. 1, pp. 21-26 (2020)
ISSN 2525-0159
22
http://elektron.fi.uba.ar
Fig. 6. Simulaci
´
on del efecto de escalado en televisores LCD. (A) Frag-
mento de 74x110 de una se
˜
nal de baja resoluci
´
on en un monitor CRT. (B)
Mismo contenido en una pantalla HDTV. Captura parcial de pantalla del
emblem
´
atico videojuego Super Mario Bros. (Nintendo, 1985) para consola
Nintendo Famicom.
III-E. Calidad de imagen
Durante varias d
´
ecadas los tubos de rayos cat
´
odicos o
CRT fueron utilizados para visualizar contenido en baja
resoluci
´
on, pero actualmente esa tecnolog
´
ıa es obsoleta y
fue completamente reemplazada por pantallas LCD HDTV.
La actualizaci
´
on de la pantalla en televisores o monitores
CRT es anal
´
ogica por naturaleza y permite representar diver-
sas resoluciones con buena fidelidad [8]. En contrapartida,
los LCD poseen una resoluci
´
on nativa o cantidad fija de
pixeles tanto en horizontal como en vertical y deben aplicar
un algoritmo de escalado digital si la se
˜
nal no coincide con
esta resoluci
´
on, lo que produce distorsiones en la imagen
original.
Como se observa en la Fig. 6, las im
´
agenes en baja
resoluci
´
on generadas por computadora son particularmente
propensas a visualizarse de forma suavizada o difuminada
en un monitor LCD HDTV.
Por este motivo, a fin de obtener en pantalla una fiel
representaci
´
on de los pixeles en el framebuffer de baja
resoluci
´
on, es necesario generar una se
˜
nal de video de alta
definici
´
on escalando el contenido del framebuffer desde el
mismo adaptador de video.
III-F. Se
˜
nal de video
Se gener
´
o un modo de video compatible con el est
´
andar
de televisi
´
on de pantalla ancha y alta definici
´
on.
El modo elegido es 720p@60 Hz o un
´
area activa de
1280x720 pixeles y frecuencia de actualizaci
´
on de pantalla
de 60 Hz o 60 cuadros por segundo [9].
En la Fig. 7 se observa un diagrama completo de los ele-
mentos que componen la se
˜
nal de video. La se
˜
nal especifica
una cantidad de pixeles mayor al modo de video elegido ya
que se suman los intervalos de blanking al final de cada
linea y de cada cuadro. Estos nuevos pixeles, inactivos son
parte del temporizado y no se visualizan en pantalla.
Para generar el temporizado de la se
˜
nal se utiliz
´
o el
est
´
andar VESA CVT [10]. Como resultado se obtuvo una
frecuencia de sincronismo vertical o VSYNC de 59,86 Hz
y una frecuencia de sincronismo horizontal o HSYNC de
44,77 kHz. Los pulsos de sincronismo son activo-bajo para
HSYNC y activo-alto para VSYNC. En la Tabla II se lista
el temporizado de cada elemento.
Area activa
1280x720
Front Porch
Señal de sincronismo
Back Porch
HSYNCFP BPACTIVE WIDTH
Horizontal Blanking Interval
ACTIVE HEIGHT
FPVSYNCBP
Vertical Blanking Interval
Total de pixeles: 1664x748
Señal HSYNC
Señal VSYNC
Fig. 7. Elementos de temporizado de la se
˜
nal de video.
TABLA II
INTERVALOS DE TIEMPO DE LA SE
˜
NAL DE VIDEO.
Par
´
ametro Cantidad Tiempo
Horizontal Total (Line) 1664 pixeles 22,333 75 µs
Horizontal Active Pixels 1280 pixeles 17,179 80 µs
Horizontal Blanking Interval 384 pixeles 5,153 94 µs
Horizontal Front Porch 64 pixeles 0,858 99 µs
Horizontal Sync Width 128 pixeles 1,717 98 µs
Horizontal Back Porch 192 pixeles 2,576 97 µs
Vertical Total Lines 748 lineas 16,705 64 ms
Vertical Active Lines 720 lineas 16,080 30 ms
Vertical Blanking Interval 28 lineas 0,625 34 ms
Vertical Front Porch 3 lineas 0,067 00 ms
Vertical Sync Width 5 lineas 0,111 66 ms
Vertical Back Porch 20 lineas 0,446 67 ms
La cantidad total de pixeles de la se
˜
nal de video es de
1664x748. Se calcula sumando los pixeles el
´
area visible y
los intervalos de blanking o pixeles no visibles.
El reloj de pixel o PCLK es la frecuencia a la cual el
adaptador de video debe ser capaz de procesar pixeles. Se
calcula teniendo en cuenta los visibles, los no visibles o
areas de blanking y la frecuencia de actualizaci
´
on de la
pantalla (2).
PCLK = (1664 × 748) × 59,86 Hz = 74,50 MHz (2)
En la ecuaci
´
on 3 se calcula el periodo de un solo pixel o
TPIXEL.
TPIXEL =
1
74,50 MHz
= 13,421 72 ns (3)
De las interfaces de video m
´
as comunes como HDMI,
DVI, DisplayPort o VGA se eligi
´
o esta ultima -incluso a
pesar de su obsolescencia- por el bajo costo de implementa-
ci
´
on del hardware necesario para emitir se
˜
nales compatibles.
La interfaz VGA es anal
´
ogica. Define la intensidad indi-
vidual de los componentes de color rojo, verde y azul en un
rango de tensi
´
on de 0 a 0,7 Vpp a 75 Ω de impedancia. Las
se
˜
nales de sincronismo horizontal y vertical son TTL [8].
RETRO-CIAA s
´
olo utiliza la interfaz el
´
ectrica del
est
´
andar VGA y el modo de video de alta resoluci
´
on no
es parte de dicho est
´
andar. Aun as
´
ı, los monitores LCD,
televisores HDTV o adaptadores VGA a HDMI no tienen
inconveniente en admitir la se
˜
nal generada.
La se
˜
nal anal
´
ogica de componentes de color se implemen-
ta mediante un DAC ad-hoc simple y econ
´
omico utilizando
Revista elektron, Vol. 4, No. 1, pp. 21-26 (2020)
ISSN 2525-0159
23
http://elektron.fi.uba.ar
Adaptador de video Cable VGA Monitor
Lineas de transmisión
coaxial 75 ohms
Lineas TTL
R
G
B
Fig. 8. Interfaz el
´
ectrica de la se
˜
nal de video.
B G R
V H
Fig. 9. Disposici
´
on de pines del conector est
´
andar VGA.
8 salidas digitales y resistencias en paralelo, configurando
un divisor de tensi
´
on en conjunto con la resistencia de
terminaci
´
on de 75 Ω del monitor. La posici
´
on de cada bit
de m
´
as a menos significativo tiene un peso o aporte relativo
equivalente en tensi
´
on. En la Fig. 8 se observa un esquema
de la interfaz el
´
ectrica.
Las se
˜
nales digitales TTL se generan con 3,3 V para sim-
plificar el dise
˜
no y ahorrar en componentes. Esta soluci
´
on es
similar a la utilizada en los kits de desarrollo FPGA Nexys
con puerto VGA [11].
III-G. Puerto de video
El puerto expone las se
˜
nales de video al exterior. En
este caso se utiliza el puerto est
´
andar VGA con conector
DB-15HD hembra. En la Fig. 9 se observa la disposici
´
on
de pines, donde (B, G, R) son los componentes de color
anal
´
ogicos azul, verde, rojo y (V, H) las se
˜
nales de sincro-
nismo vertical y horizontal TTL [8].
III-H. Escalado
En relaci
´
on a la se
˜
nal de video, el framebuffer contiene
cinco veces menos pixeles tanto en horizontal como en
vertical. Por este motivo, el adaptador de video implementa
un m
´
etodo de escalado.
Cada pixel emitido en la se
˜
nal de video se genera repitien-
do cinco veces el valor de cada pixel en el framebuffer. A
su vez, la lectura de cada linea de pixeles en el framebuffer
se repite cinco veces para generar cinco lineas sucesivas e
iguales en la se
˜
nal de video. El resultado de esta operaci
´
on
es un escalado ((al vuelo)) del framebuffer con un factor
de cinco en ambas dimensiones y una se
˜
nal de video de
alta resoluci
´
on cuya imagen resultante es fiel al framebuffer
original.
IV. CALCULO DE FACTIBILIDAD
La elecci
´
on de los par
´
ametros de dise
˜
no del adaptador de
video -en particular el modo de video y la se
˜
nal a generar-
esta restringida por la velocidad de reloj y las caracter
´
ısticas
de la arquitectura en donde se implementar
´
a el sistema.
El n
´
ucleo Cortex-M0 implementa la arquitectura ARMv6-
M. La mayor
´
ıa de las instrucciones se ejecutan de uno, dos
o tres ciclos de reloj [12].
La cantidad de ciclos de reloj necesarios para generar una
linea o scanline de la se
˜
nal de video depende de la habilidad
del programador para optimizar el c
´
odigo. No obstante, se
pueden identificar algunas tareas necesarias y la cantidad
m
´
ınima de ciclos, siendo doce el total resultante:
1. La lectura del framebuffer en memoria SRAM requie-
re de dos ciclos de reloj y se realiza mediante la
instrucci
´
on de assembler LDR.
2. El reordenamiento de los bits a los puertos de E/S
seg
´
un restricciones del proyecto RETRO-CIAA [13]
requiere de tres ciclos de reloj: dos ciclos para dos
operaciones de corrimiento de bits y un ciclo para un
OR binario (instrucciones LSRS, LSLS y ORRS).
3. La escritura de pines de E/S requiere dos ciclos si los
pines se encuentran en el mismo puerto.
4. El incremento del puntero al framebuffer demanda un
ciclo (instrucci
´
on ADDS).
5. El decremento de la cantidad de pixeles pendientes en
la l
´
ınea del framebuffer insume un ciclo (instrucci
´
on
SUBS).
6. Si la cantidad de pixeles es mayor a 0, el inicio de una
nueva iteraci
´
on requiere tres ciclos (instrucci
´
on BNE).
En las ecuaciones (4) y (5) se calcula el periodo de cada
ciclo de reloj que permitir
´
a evaluar si el modo de video
elegido es factible de implementar.
MCU
clock
= 204 MHz (4)
MCU
cycle
=
1
MCU
clock
=
1
204 MHz
= 4,901 96 ns (5)
En el apartado sobre la se
˜
nal de video se calcul
´
o la
constante TPIXEL. En la ecuaci
´
on (6) se calcula la cantidad
de ciclos del microcontrolador por cada pixel de la se
˜
nal de
video o CPIXEL.
CPIXEL =
TPIXEL
MCU
cycle
=
13,421 72 ns
4,901 96 ns
= 2,73803 (6)
La se
˜
nal de video contiene 1280x720 pixeles visibles. En
el temporizado calculado se disponen de 2 ciclos de reloj
por pixel en esa resoluci
´
on, por lo tanto su implementaci
´
on
no es viable.
Sin embargo, seg
´
un las decisiones de dise
˜
no tomadas
teniendo en cuenta las restricciones de memoria y procesa-
miento, cada linea del framebuffer de 256 pixeles se repite
5 veces para generar una linea de 1280 pixeles. En cada
iteraci
´
on, un pixel del framebuffer genera 5 pixeles de la
se
˜
nal de video. En consecuencia, se dispone de cinco veces
el tiempo calculado para TPIXEL. La nueva cantidad de
ciclos se calcula en la ecuaci
´
on (7).
CPIXEL5 =
TPIXEL × 5
MCU
cycle
=
67,1086 ns
4,901 96 ns
= 13,69015 (7)
De esta forma se disponen de 13 o 14 ciclos, volviendo
viable su implementaci
´
on.
En la memoria del proyecto RETRO-CIAA [13] se revisa
en detalle las implicancias de un n
´
umero no entero de ciclos
en la generaci
´
on de la se
˜
nal de video.
Revista elektron, Vol. 4, No. 1, pp. 21-26 (2020)
ISSN 2525-0159
24
http://elektron.fi.uba.ar
Fig. 10. Video por streaming desde tarjeta microSD y transcoding de 24 a
60 cuadros por segundo en el n
´
ucleo Cortex-M4F mientras el Cortex-M0
genera la se
˜
nal de video.
Fig. 11. Videojuego de ejemplo. La funciones de dibujo de lineas e
im
´
agenes corren sobre el n
´
ucleo Cortex-M4F. El desplazamiento sobre el
mapa es suave y fluido [14].
V. RESULTADOS OBTENIDOS
La se
˜
nal est
´
andar de alta definici
´
on es compatible con
televisores LCD HDTV y adaptadores VGA a HDMI. La
imagen resultante es similar a la producida por las consolas
de videojuegos de los a
˜
nos ’80s. Ponderando la calidad de
imagen resultante en un televisor LCD HDTV [14] contra
proyectos similares [13] puede afirmarse que la fluidez,
nitidez y estabilidad obtenida es sobresaliente para un sis-
tema de este tipo. El n
´
ucleo Cortex-M4F queda totalmente
disponible para ejecutar la aplicaci
´
on y la memoria SRAM
compartida permite que este n
´
ucleo dibuje sobre el
´
area del
framebuffer no visible utilizando instrucciones DSP y SIMD.
Estos resultados pueden apreciarse en las Figuras 10, 11,
12 y 13 que consisten en fotografi
´
as de im
´
agenes generadas
por el proyecto RETRO-CIAA tomadas directamente de una
pantalla LCD.
VI. CONCLUSIONES
La t
´
ecnica revisada posibilita agregar valor a un proyecto
existente implementando una salida de video por software y
sumando unas pocas resistencias y un conector para la se
˜
nal.
Tambi
´
en permite bajar costos utilizando un microcontrola-
dor sin soporte de video
´
o cubrir una necesidad especifica
como puede ser generar una se
˜
nal de alta definici
´
on desde un
framebuffer de baja resoluci
´
on, utilizar un formato de pixel
especifico, generar una se
˜
nal de video no est
´
andar, etc.
Fig. 12. Efectos aplicados ((al vuelo)) por el n
´
ucleo Cortex-M0 mientras
genera la se
˜
nal de video: scanlines de monitor CRT y filtros de color a
pantalla completa.
Fig. 13. Se grafican variables de un aceler
´
ometro en tiempo real. La
resoluci
´
on del framebuffer es adecuada para trabajos educativos.
Si bien esta t
´
ecnica no es nueva, su uso junto a un
framebuffer doble es poco com
´
un. Y generar una se
˜
nal
de alta definici
´
on realizando un escalado ((al vuelo)) de un
framebuffer de baja resoluci
´
on, es un enfoque novedoso.
El proyecto RETRO-CIAA agrega valor a la EDU-CIAA-
NXP mediante la implementaci
´
on de un adaptador de vi-
deo por software, sin impacto para el n
´
ucleo utilizado
com
´
unmente por las aplicaciones y con un costo de me-
moria SRAM significativo, pero aun as
´
ı justificado en la
posibilidad de contar con video de alta prestaci
´
on.
Las decisiones de dise
˜
no fueron requerimientos del pro-
yecto RETRO-CIAA. Otros proyectos pueden adaptar el uso
de memoria, resoluci
´
on, interfaz y modo de video seg
´
un
requerimientos particulares que modifiquen el balance de
los recursos disponibles.
VII. TRABAJO FUTURO
Como trabajo futuro se plantea promover este proyecto
en la comunidad de usuarios del kit EDU-CIAA-NXP y la
creaci
´
on de ejemplos y material did
´
actico.
VIII. AGRADECIMIENTOS
El autor agradece a Ariel Lutenberg y a Pablo Gomez por
sus valiosos aportes, consejos y devoluciones, a Eric Pernia
por su buena predisposici
´
on e ideas para dar a conocer el
Revista elektron, Vol. 4, No. 1, pp. 21-26 (2020)
ISSN 2525-0159
25
http://elektron.fi.uba.ar
proyecto RETRO-CIAA y al Simposio y Congreso Argen-
tino de Sistemas Embebidos (SASE/CASE) por brindar la
posibilidad de difundir este trabajo.
REFERENCIAS
[1] Foley, van Dam, Feiner, Hughes, ((Computer Graphics, Principles and
practice - Second edition in C)), Addison Wesley, 1997.
[2] Proyecto CIAA, ((Computadora Industria Abierta Argentina -
EDU-CIAA-NXP)), http://www.proyecto-ciaa.com.ar/devwiki/doku.
php?id=desarrollo:edu-ciaa:edu-ciaa-nxp.
[3] NXP Semiconductors, ((LPC43xx/LPC43Sxx ARM Cortex-M4/M0
multi-core microcontroller)), version 2.3, July 2017.
[4] Santiago Germino, ((P
´
agina principal del proyecto RETRO-CIAA)),
http://www.retro-ciaa.com.
[5] Eric Pernia, Martin Ribelotta y contribuidores, ((Repositorio GitHub
de la futura version 3 del firmware del proyecto CIAA)), 3/12/2018,
https://github.com/epernia/cese-edu-ciaa-template.
[6] Proyecto CIAA, ((Ejemplos de uso de la CIAA)), http://www.
proyecto-ciaa.com.ar/index quees ejemplosuso.html.
[7] Stockman, MacLeod y Johnson, ((2-deg cone fundamentals (based
on the Stiles and Burch 2-deg CMFs)), 1993, http://www.cvrl.org/
database/text/cones/smj2.htm.
[8] Robert L. Myers, ((Display Interfaces - Fundamentals and standards)),
Wiley-SID, 2002.
[9] The Advanced Television Systems Committee, Inc., ((ATSC Digital
Television Standard)), A/53 Parts 1 - 6, 2007.
[10] Video Electronics Standards Association, ((VESA Coordinated Video
Timings (CVT) Standard)), version 1.2, February 2013.
[11] Digilent Inc., ((Nexys A7: FPGA Trainer Board Recom-
mended for ECE Curriculum)) https://store.digilentinc.com/
nexys-a7-fpga-trainer-board-recommended-for-ece-curriculum.
[12] Joseph Yiu, ((The Definitive Guide to ARM Cortex-M0 and Cortex-
M0+ Processors - 2nd Ed.)), Elsevier Inc, 2015.
[13] Santiago Germino, ((RETRO-CIAA: Consola de videojuegos
basada en EDU-CIAA-NXP)), http://laboratorios.fi.uba.ar/lse/tesis/
LSE-FIUBA-Trabajo-Final-CESE-Santiago-Germino-2018.pdf
[14] Santiago Germino, ((RETRO-CIAA: Consola de videojuegos basada
en EDU-CIAA-NXP - Demostraci
´
on Defensa TF CESE)), https:
//www.youtube.com/watch?v=tJM6
TdOuKQ.
Revista elektron, Vol. 4, No. 1, pp. 21-26 (2020)
ISSN 2525-0159
26
http://elektron.fi.uba.ar
Enlaces de Referencia
- Por el momento, no existen enlaces de referencia
Copyright (c) 2020 Santiago Germino
This work is licensed under a Creative Commons Attribution-NonCommercial-NoDerivatives 4.0 International License.
Revista elektron, ISSN-L 2525-0159
Facultad de Ingeniería. Universidad de Buenos Aires
Paseo Colón 850, 3er piso
C1063ACV - Buenos Aires - Argentina
revista.elektron@fi.uba.ar
+54 (11) 528-50889