qi-hardware/nn-usb-fpga
1
0
Fork 0
mirror of git://projects.qi-hardware.com/nn-usb-fpga.git synced 2025-04-21 12:27:27 +03:00
Code Activity

aaa

Browse Source
This commit is contained in:
Carlos Camargo
2010-09-12 19:57:04 -05:00
parent d01e4f4f47
commit 0975cd73dc
74 changed files with 23913 additions and 20 deletions
Download Patch File Download Diff File Expand all files Collapse all files

32
course/.docs/cambio_categoria/biblio.log Normal file
View File

@@ -0,0 +1,32 @@
This is pdfeTeX, Version 3.141592-1.21a-2.2 (Web2C 7.5.4) (format=pdflatex 2006.8.24) 2 OCT 2006 15:54
entering extended mode
**biblio.tex
(./biblio.tex
LaTeX2e <2003/12/01>
Babel <v3.8d> and hyphenation patterns for american, french, german, ngerman, b
ahasa, basque, bulgarian, catalan, croatian, czech, danish, dutch, esperanto, e
stonian, finnish, greek, icelandic, irish, italian, latin, magyar, norsk, polis
h, portuges, romanian, russian, serbian, slovak, slovene, spanish, swedish, tur
kish, ukrainian, nohyphenation, loaded.
\bibdata{biblio_EL}
No file biblio.bbl.
)
! Emergency stop.
<*> biblio.tex
*** (job aborted, no legal \end found)
Here is how much of TeX's memory you used:
6 strings out of 94500
122 string characters out of 1175788
48348 words of memory out of 1000000
3273 multiletter control sequences out of 10000+50000
3640 words of font info for 14 fonts, out of 500000 for 2000
580 hyphenation exceptions out of 8191
5i,0n,3p,37b,8s stack positions out of 1500i,500n,5000p,200000b,5000s
PDF statistics:
0 PDF objects out of 300000
0 named destinations out of 131072
1 words of extra memory for PDF output out of 65536
No pages of output.

2
course/.docs/cambio_categoria/biblio.tex Normal file
View File

@@ -0,0 +1,2 @@

2
course/.docs/cambio_categoria/biblio.tex.backup Normal file
View File

@@ -0,0 +1,2 @@

2
course/.docs/cambio_categoria/biblio.tex~ Normal file
View File

@@ -0,0 +1,2 @@
\bibliography{biblio_EL}

190
course/.docs/cambio_categoria/biblio_EL.bib Normal file
View File

@@ -0,0 +1,190 @@
@comment{This file has been generated by Pybliographer}
@Misc{LSC08,
Author = {{Lattice Semiconductor Corporation}},
Title = {Lattice{M}ico32 {O}pen, {F}ree 32-{B}it {S}oft
{P}rocessor},
HowPublished = {URL:
http://www.latticesemi.com/products/intellectualproperty/ipcores/mico32/index.cfm},
year = 2008
}
@Misc{Wik,
Author = {Wikipedia},
Title = {Wikipedia, the free encyclopedia},
HowPublished = {http://en.wikipedia.org/}
}
@Misc{LD02,
Author = {{L. Doolittle}},
Title = {Building {L}inux for the nano{E}ngine},
HowPublished = {http://recycle.lbl.gov/~ldoolitt/bse/},
month = {26 } # jun,
year = 2002
}
@Misc{MLH98,
Author = {{Michael L. Haungs}},
Title = {The {E}xecutable and {L}inking {F}ormat ({ELF})},
HowPublished = {http://www.cs.ucdavis.edu/~haungs/paper/node1.html},
month = {21 } # sep,
year = 1998
}
@Article{OPPS05,
Author = {{O. Pomerantz} and {P. Salzman} and {M. Burian}},
Title = {The {L}inux {K}ernel {M}odule {P}rogramming {G}uide
ver 2.6.1},
Journal = {The Linux Documentation Project http://www.tldp.org/},
month = {26 } # may,
year = 2005
}
@Misc{entry-0,
Title = {An {I}ntroduction to the {L}inux {A}rchitecture},
HowPublished = {http://wiki.cs.uiuc.edu/cs427/An+Introduction+to+the+Linux+Architecture}
}
@Misc{CS04,
Author = {{C. S\'eveillac}},
Title = {Build {Q}t/{E}mbedded and {O}pie on a {L}inux, x86
architecture, for {ARM} target architecture.},
HowPublished = {http://dudu.dyn.2-h.org/nist/qt-notes.php},
month = {20 } # nov,
year = 2004
}
@Misc{Mo05,
Author = {{M. opdenacker}},
Title = {Embedded {L}inux {K}ernel and driver development},
HowPublished = {http://free-electrons.com},
month = {14 } # aug,
year = 2005
}
@Misc{BG,
Author = {{Bill Gatliff}},
Title = {Porting and {U}sing {N}ewlib in {E}mbedded {S}ystems},
HowPublished = {http://venus.billgatliff.com/node/3}
}
@Article{MB03,
Author = {{M. Barr}},
Title = {How to {C}hoose a {R}eal-{T}ime {O}perating {S}ystem},
Journal = {Embedded Systems Programming},
month = jan,
year = 2003
}
@Misc{IBSS98,
Author = {{I. Bowman} and {S. Siddiqi} and {M. Tanuan}},
Title = {Concrete {A}rchitecture of the {L}inux {K}ernel},
HowPublished = {http://plg.uwaterloo.ca/~itbowman/CS746G/a2},
month = {12 } # feb,
year = 1998
}
@Article{JT04,
Author = {{J. Turley}},
Title = {Embedded systems survey: {O}perating systems up for
grabs},
Journal = {Embedded Systems Programming},
month = may,
year = 2004
}
@Book{JCAR05,
Author = {{J. Corbet} and {A. Rubini} and {G. Kroah-Hartman}},
Title = {Linux {D}evice {D}rivers, {T}hird {E}dition},
Publisher = {O'Reilly},
year = 2005
}
@Misc{AO,
Author = {{Aleph One}},
Title = {Porting the {L}inux {K}ernel to a {N}ew {ARM}
{P}latform},
HowPublished = {http://www.aleph1.co.uk}
}
@Book{CH02,
Author = {{Craig Hollabaugh.}},
Title = {Embedded {L}inux: {H}ardware, {S}oftware, and
{I}nterfacing},
Publisher = {Addison Wesley Professional.},
month = {7 } # mar,
year = 2002
}
@Misc{VDC06,
Author = {{Venture Development Corp.}},
Title = {Small teams dominate embedded software development},
HowPublished = {http://www.linuxdevices.com/articles/AT7019328497.html},
month = {1 } # jun,
year = 2006
}
@Article{JT05,
Author = {{J. Turley}},
Title = {Five irreversible decisions},
Journal = {Embedded Systems Programming},
month = {27 } # jan,
year = 2005
}
@Misc{SR08,
Author = {{S. Rhoads}},
Title = {Plasma - most {MIPS} {I}({TM}) opcodes},
HowPublished = {URL: http://opencores.org/project,plasma},
year = 2008
}
@Misc{A1,
Author = {{Aleph 1}},
Title = {Building the {T}oolchain},
HowPublished = {http://www.aleph1.co.uk/node/279}
}
@Misc{Ale01,
Author = {Aleph1},
Title = {Boot {L}oader {G}uide},
HowPublished = {http://www.aleph1.co.uk/armlinux/docs/ARM
booting/t1.html},
month = {7 } # sep,
year = 2001
}
@Misc{DK06,
Author = {{Dan Kegel}},
Title = {Building and {T}esting gcc/glibc cross toolchains},
HowPublished = {http://www.kegel.com/crosstool/},
month = {20 } # feb,
year = 2006
}
@Misc{IB98,
Author = {{I. Bowman}},
Title = {Conceptual {A}rchitecture of the {L}inux {K}ernel},
HowPublished = {http://www.grad.math.uwaterloo.ca/~itbowman/CS746G/a1/},
year = 1998
}
@Article{Lin05,
Author = {Linuxdevices},
Title = {Embedded {L}inux market snapshot, 2005},
Journal = {http://www.linuxdevices.com},
month = {4 } # may,
year = 2005
}
@Article{CLSB05,
Author = {{C. Lanfear} and {S. Balacco} and {M. Volckmann}},
Title = {The 2005 {E}mbedded {S}oftware {S}trategic {M}arket
{I}ntelligence {P}rogram},
Journal = {Venture Development Corporation
http://www.vdc-corp.com},
month = aug,
year = 2005
}

181
course/.docs/cambio_categoria/biblio_EL.bib.bak Normal file
View File

@@ -0,0 +1,181 @@
@comment{This file has been generated by Pybliographer}
@Misc{Wik,
Author = {Wikipedia},
Title = {Wikipedia, the free encyclopedia},
HowPublished = {http://en.wikipedia.org/}
}
@Misc{LD02,
Author = {{L. Doolittle}},
Title = {Building {L}inux for the nano{E}ngine},
HowPublished = {http://recycle.lbl.gov/~ldoolitt/bse/},
month = {26 } # jun,
year = 2002
}
@Misc{MLH98,
Author = {{Michael L. Haungs}},
Title = {The {E}xecutable and {L}inking {F}ormat ({ELF})},
HowPublished = {http://www.cs.ucdavis.edu/~haungs/paper/node1.html},
month = {21 } # sep,
year = 1998
}
@Article{OPPS05,
Author = {{O. Pomerantz} and {P. Salzman} and {M. Burian}},
Title = {The {L}inux {K}ernel {M}odule {P}rogramming {G}uide
ver 2.6.1},
Journal = {The Linux Documentation Project http://www.tldp.org/},
month = {26 } # may,
year = 2005
}
@Misc{entry-0,
Title = {An {I}ntroduction to the {L}inux {A}rchitecture},
HowPublished = {http://wiki.cs.uiuc.edu/cs427/An+Introduction+to+the+Linux+Architecture}
}
@Misc{CS04,
Author = {{C. S\'eveillac}},
Title = {Build {Q}t/{E}mbedded and {O}pie on a {L}inux, x86
architecture, for {ARM} target architecture.},
HowPublished = {http://dudu.dyn.2-h.org/nist/qt-notes.php},
month = {20 } # nov,
year = 2004
}
@Misc{Mo05,
Author = {{M. opdenacker}},
Title = {Embedded {L}inux {K}ernel and driver development},
HowPublished = {http://free-electrons.com},
month = {14 } # aug,
year = 2005
}
@Misc{BG,
Author = {{Bill Gatliff}},
Title = {Porting and {U}sing {N}ewlib in {E}mbedded {S}ystems},
HowPublished = {http://venus.billgatliff.com/node/3}
}
@Article{MB03,
Author = {{M. Barr}},
Title = {How to {C}hoose a {R}eal-{T}ime {O}perating {S}ystem},
Journal = {Embedded Systems Programming},
month = jan,
year = 2003
}
@Misc{IBSS98,
Author = {{I. Bowman} and {S. Siddiqi} and {M. Tanuan}},
Title = {Concrete {A}rchitecture of the {L}inux {K}ernel},
HowPublished = {http://plg.uwaterloo.ca/~itbowman/CS746G/a2},
month = {12 } # feb,
year = 1998
}
@Article{JT04,
Author = {{J. Turley}},
Title = {Embedded systems survey: {O}perating systems up for
grabs},
Journal = {Embedded Systems Programming},
month = may,
year = 2004
}
@Book{JCAR05,
Author = {{J. Corbet} and {A. Rubini} and {G. Kroah-Hartman}},
Title = {Linux {D}evice {D}rivers, {T}hird {E}dition},
Publisher = {O'Reilly},
year = 2005
}
@Misc{AO,
Author = {{Aleph One}},
Title = {Porting the {L}inux {K}ernel to a {N}ew {ARM}
{P}latform},
HowPublished = {http://www.aleph1.co.uk}
}
@Book{CH02,
Author = {{Craig Hollabaugh.}},
Title = {Embedded {L}inux: {H}ardware, {S}oftware, and
{I}nterfacing},
Publisher = {Addison Wesley Professional.},
month = {7 } # mar,
year = 2002
}
@Misc{VDC06,
Author = {{Venture Development Corp.}},
Title = {Small teams dominate embedded software development},
HowPublished = {http://www.linuxdevices.com/articles/AT7019328497.html},
month = {1 } # jun,
year = 2006
}
@Article{JT05,
Author = {{J. Turley}},
Title = {Five irreversible decisions},
Journal = {Embedded Systems Programming},
month = {27 } # jan,
year = 2005
}
@Misc{SR08,
Author = {{S. Rhoads}},
Title = {Plasma - most {MIPS} {I}({TM}) opcodes},
HowPublished = {URL: http://opencores.org/project,plasma},
year = 2008
}
@Misc{A1,
Author = {{Aleph 1}},
Title = {Building the {T}oolchain},
HowPublished = {http://www.aleph1.co.uk/node/279}
}
@Misc{Ale01,
Author = {Aleph1},
Title = {Boot {L}oader {G}uide},
HowPublished = {http://www.aleph1.co.uk/armlinux/docs/ARM
booting/t1.html},
month = {7 } # sep,
year = 2001
}
@Misc{DK06,
Author = {{Dan Kegel}},
Title = {Building and {T}esting gcc/glibc cross toolchains},
HowPublished = {http://www.kegel.com/crosstool/},
month = {20 } # feb,
year = 2006
}
@Misc{IB98,
Author = {{I. Bowman}},
Title = {Conceptual {A}rchitecture of the {L}inux {K}ernel},
HowPublished = {http://www.grad.math.uwaterloo.ca/~itbowman/CS746G/a1/},
year = 1998
}
@Article{Lin05,
Author = {Linuxdevices},
Title = {Embedded {L}inux market snapshot, 2005},
Journal = {http://www.linuxdevices.com},
month = {4 } # may,
year = 2005
}
@Article{CLSB05,
Author = {{C. Lanfear} and {S. Balacco} and {M. Volckmann}},
Title = {The 2005 {E}mbedded {S}oftware {S}trategic {M}arket
{I}ntelligence {P}rogram},
Journal = {Venture Development Corporation
http://www.vdc-corp.com},
month = aug,
year = 2005
}

666
course/.docs/cambio_categoria/chapter1.tex Normal file
View File

@@ -0,0 +1,666 @@
\chapter{Dise<EFBFBD>o de Sistemas Embebidos}
\section{Definici<EFBFBD>n}
Un Sistema Embebidos es un sistema de prop<6F>sito espec<65>fico en el cual, el computador es encapsulado completamente por el dispositivo que el controla. A diferencia de los computadores de prop<6F>sito general, un Sistema Embebido realiza tareas pre-definidas, lo cual permite su optimizaci<63>n, reduciendo el tama<6D>o y costo del producto \cite{Wik}
\section{Caracter<EFBFBD>sticas}
\begin{itemize}
\item Los sistemas embebidos son dise<73>ados para una aplicaci<63>n
espec\'{\i}fica, es decir, estos sistemas realizan un grupo de funciones
previamente definidasm y una vez el sistema es dise<73>ado, no se puede cambiar
su funcionalidad. Por ejemplo, el control de un asensor siempre realizar\'a
las mismas acciones durante su vida \'util.
\item Debido a su interacci<63>n con el entorno los ES deben cumplir
esctr<74>ctamente restricciones temporales. El t\'ermino {\textit{Sistemas
de Tiempo Real}} es utilizado para enfatizar este aspecto.
\item Los Sistemas Embebidos son heterog\'eneos, es decir, est\'an
compuestos por componentes Hardware y Software. Los componentes Hardware,
como ASICs y Dispositivos L\'ogicos Programables (PLD) proporcionan la
velocidad de ejecuci\'on y el cosumo de potencia necesarios en algunas
aplicaciones.
\item Los Sitemas Embebidos tienen grandes requerimientos en t\'erminos de
confiabilidad. Errores en aplicaciones como la aviaci\'on y el
automovilismo, pueden tener consecuencias desastrosas.
\end{itemize}
\section{Arquitectura}
Una arquitectura t<>pica para un Sistema Embebido se muestra en la Figura \ref{es_arch}; La cual integra un componente hardware, implementado ya sea en un PLD (CPLD, FPGA) o en un ASIC, conocido con el nombre de perif<69>ricos y un componente software (procesador o DSP) cap<61>z de ejecutar software, la parte del procesador est<73> dividida en la CPU (En algunos casos posee una cach<63>) y las unidades de Memoria.
\begin{figure}[h]
\begin{center} \includegraphics[scale=.6]{./images/ES_Architecture} \end{center}
\caption{Arquitectura de un Sistema Embebido}\label{es_arch}
\end{figure}
Podemos utilziar
\begin{itemize}
\item Componente HW y SW Integrado en un dispositivo semiconductor (SoC): En la actualidad existen muchas compa<70><61>as que fabrican procesadores de 32 bits integrados a una gran variedad de perif<69>ricos, lo cual simplifica el dise<73>o y reduce costos (menos componentes y menos <20>rea de circuito impreso) \footnote{http://www.sharpsma.com, http://www.atmel.com, http://www.cirrus.com, http://www.samsung.com, http://www.freescale.com, etc}.
\item Componente SW en un SoC y componente HW en una FPGA: Cuando no existen en el mercado SoC con la cantidad de perif<69>ricos requerida para una determinada aplicaci<63>n, es necesario recurrir a la utilizaci<63>n de dispositivos comerciales que implementen dicha operaci<63>n, en algunas ocaciones el perif<69>rico puede relizar funciones muy espec<65>ficas de modo que no existe en el mercado, la soluci<63>n es entonces implementar estos dispositivos en una FPGA, tambi<62>n se recomienda la utilizaci<63>n de FPGAs en sistemas que requieren una gran cantidad y variedad de perif<69>ricos ya que reduce la complejidad y costo del sistema.
\item Componente SW y HW en una FPGA: Esta es tal vez la opci<63>n m<>s econ<6F>mica y flexible, pero la de menor desempe<70>o, ya que al utilizar los recursos l<>gicos de la FPGA para la implementaci<63>n del procesador (softcore) la lngitud de los caminos de interconexi<78>n entre los bloques l<>gicos aumentan el retardo de las se<73>ales . Los procesadores \textit{softcore} m<>s populares en la actualidad son:
\begin{itemize}
\item Microblaze de Xilinx\footnote{http://www.xilinx.com}
\item Leon de Gaisler Research \footnote{http://www.gaisler.com/}
\item LatticeMico32 de Lattice Semiconductors\footnote{http://www.latticesemi.com}
\item OpenRisc \footnote{http://www.opencores.com}
\end{itemize}
\end{itemize}
\section{Metodolog<EFBFBD>a de Dise<73>o}
La Figura \ref{des_flow}, muestra un diagrama de flujo gen<65>rico para dise<73>o para sistemas embebidos {\cite{Cor05}}
\begin{figure}[H]
\begin{center} \includegraphics[scale=.55]{./images/design_flow} \end{center}
\caption{Flujo de Dise<73>o de un Sistema Embebido}\label{des_flow}
\end{figure}
El proceso comienza con la {\textit{especificaci\'on del sistema}}, en este punto se describe la funcionalidad y se definen las restricciones f\'{\i}sicas, el\'ectricas y econ\'omicas. Esta especificaci\'on debe ser muy general y no deben existir dependencias (tecnol\'ogicas, metodol\'ogicas) de ning\'un tipo, se suele utilizar lenguajes de alto nivel, como UML, C++. La especificaci\'on puede ser verificada a trav\'es de una serie de pasos de an\'alisis cuyo objetivo es determinar la validez de los algor\'{\i}tmos seleccionados, por ejemplo, determinar si el algoritmo siempre termina, los resultados satisfacen las especificaciones. Desde el punto de vista de la re-utilizaci\'on, algunas partes del funcionamiento global deben tomarse de una librer\'{\i}a de algor\'{\i}tmos existentes.
Una vez definidas las especificaciones del sistema se debe realizar un modelamiento que permita extraer de estas la funcionalidad. El modelamiento es crucial en el dise<73>o ya que de \'el depende el paso existoso de la especificaci\'on a la implementaci\'on. Es importante definir que modelo matem\'atico debe soportar el entorno de dise<73>o. Los modelos m\'as utilizados son: M\'aquinas de estados finitos, diagramas de flujos de datos, Sistemad de Eventos Discretos y Redes de Petri. Cada modelo posee propiedades matem\'aticas que pueden explotarse de forma eficiente para responder preguntas sobre la funcionalidad del sistema sin llevar a cabo dispendiosas tareas de verificaci\'on. \ Todo modelo obtenido debe ser verificado para comprobar que cumple con las restricciones del sistema.
Una vez se ha obtenido el modelo del sistema se procede a determinar su {\textit{arquitectura}}, esto es, el n\'umero y tipo de componentes y su inter-conexi\'on. Este paso no es m\'as que una exploraci\'on del espacio de dise<73>o en b\'usqueda de soluciones que permitan la implementaci\'on de una funcionalidad dada, y puede realizarse con varios criterios en mente: Costos, confiabilidad, viabilidad comercial.
Utilizando como base la arquitectura obtenida en el paso anterior las tareas del modelo del sistemas son mapeadas dentro de los componentes. Esto es,
asignaci\'on de funciones a los componentes de la arquitectura. Existen dos opciones a la hora de implementar las tareas o procesos:
\begin{enumerate}
\item Implementaci\'on Software: La tarea se va a ejecutar en un procesador.
\item Implementaci\'on Hardware: La tarea se va a ejecutar en un dispositivo l<>gico programable.
\end{enumerate}
Para cumplir las especificaciones del sistema algunas tareas deben ser implementadas en Hardware, esto con el f\'{\i}n de no ocupar al procesador en tareas c\'{\i}clicas, un ejemplo t\'{\i}pico de estas tareas es la generaci\'on de bases de tiempos. La decisi\'on de que tareas se implementan en SW y que tareas se implementan en HW recibe el nombre de {\textit{particionamiento}}, esta selecci\'on es fuertemente dependiente de restricciones econ\'omicas y temporales.
Las tareas Software deben compartir los recursos que existan en el sistema (procesador y memoria), por lo tanto se deben hacer decisiones sobre el orden de ejecuci\'on y la prioridad de estas. Este proceso recibe el nombre de {\textit{planificaci\'on}}. En este punto del dise<73>o el modelo debe incluir informaci\'on sobre el mapeo, el particionamiento y la planificaci\'on del sistema.
Las siguientes fases corresponden a la implementaci\'on del modelo, para esto las tareas hardware deben ser llevadas al dispositivo elegido (ASIC o FPGA) y
se debe obtener el $''$ejecutable$''$ de las tareas software, este proceso recibe el nombre de {\textit{s\'{\i}ntesis}} HW y SW respectivamente, as\'{\i}
mismo se deben sintetizar los mecanismos de comunicaci\'on.
El proceso de prototipado consiste en la realizaci\'on f\'{\i}sica del sistema, finalmente el sistema f\'{\i}sico debe someterse a pruebas para verificar que se cumplen con las especificaciones iniciales.
Como puede verse en el flujo de dise<73>o existen realimentaciones, estas realimentaciones permiten depurar el resultado de pasos anteriores en el caso de no cumplirse las especificaciones iniciales
\section{Herramientas de Dise<73>o Software}
En el mercado existe una gran variedad de herramientas de desarrollo para Sistemas Embebidos, sin embargo, en este estudio nos centraremos en el uso de las herramientas de libre distribuci<63>n; esta elecci<63>n se debe a que la mayor<6F>a de los productos comerciales utilizan el toolchain de GNU\footnote{http://www.gnu.org} internamente y proporcionan un entorno gr<67>fico para su f<>cil manejo. Otro factor considerado a la hora de realizar nuestra elecci<63>n es el econ<6F>mico, ya que la mayor<6F>a de los productos comerciales son costosos y poseen soporte limitado. Por otro lado, el toolchain de GNU es utilizado ampliamente en el medio de los dise<73>adores de sistemas embebidos y se encuentra un gran soporte en m<>ltiples foros de discusi<73>n (ver Figura \ref{tools}).
\begin{figure}[H]
\begin{center} \includegraphics[scale=.7]{./images/embedded-linux-tool-trends-sm} \end{center}
\caption{Tendencia de utilizaci<63>n de herramientas de desarrollo}\label{tools}
\end{figure}
\subsection{Componentes del \textit{GNU toolchain} }
\subsubsection{GNU binutils\cite{A1}}
Son una colecci<63>n de utilidades para archivos binarios y estan compuestas por:
\begin{itemize}
\item \textbf{addr2line} Convierte direcciones de un programa en nombres de archivos y n<>meros de l<>nea. Dada una direcci<63>n y un ejecutable, usa la informaci<63>n de depuraci<63>n en el ejecutabe para determinar que nombre de atchivo y n<>mero de lpinea est<73> asociado con la direcci<63>n dada.
\item \textbf{ar} Esta utilidad crea, modifica y extrae desde ficheros. Un fichero es una colecci<63>n de otros archivos en una estructura que hace posible obtener los archivos individuales miembros del archivo.
\item \textbf{as} Utilidad que compila la salida del compilador de C (GCC).
\item \textbf{c++filt} Este program realiza un mapeo inverso: Decodifica nombres de bajo-nivel en nombres a nivel de usuario, de tal forma que el linker pueda mantener estas funciones sobrecargadas (overloaded) ``from clashing''.
\item \textbf{gasp} GNU Assembler Macro Preprocessor
\item \textbf{ld} El \textit{linker} GNU combina un n<>mero de objetos y ficheros, re-localiza sus datos y los relaciona con referencias. Normalmente el <20>ltimo paso en la construcci<63>n de un nuevo programa compilado es el llamado a ld.
\item \textbf{nm} Realiza un listado de s<>mbolos de archivos tipo objeto.
\item \textbf{objcopy} Copia los contenidos de un archivo tipo objeto a otro. \textit{objcopy} utiliza la librer<65>a GNU BFD para leer y escribir el archivo tipo objeto. Permite esccribibr el archivo destino en un formato diferente al del archivo fuente.
\item \textbf{objdump} Despliega informaci<63>n sobre archivos tipo objeto.
\item \textbf{ranlib} Genera un <20>ndice de contenidos de un fichero, y lo almacena en <20>l.
\item \textbf{readelf} Interpreta encabezados de un archivo ELF.
\item \textbf{size} Lista el tama<6D>o de las secciones y el tama<6D>o total de un archivo tipo objeto.
\item \textbf{strings} Imprime las secuencias de caracteres imprimibles de almenos 4 caracteres de longitud.
\item \textbf{strip} Elimina todos los s<>mbolos de un archivo tipo objeto.
\end{itemize}
\subsubsection{GNU Compiler Collection\cite{Wik}}
El \textit{GNU Compiler Collection} normalmente llamado GCC, es un grupo de compiladores de lenguajes de programaci<63>n producido por el proyecto GNU. Es el compilador standard para el software libre de los sistemas operativos basados en Unix y algunos propietarios como Mac OS de Apple.
\subsubsection{Lenguajes}
GCC soporta los siguientes lenguajes:
\begin{itemize}
\item \textbf{ADA}
\item \textbf{C}
\item \textbf{C++}
\item \textbf{Fortran}
\item \textbf{Java}
\item \textbf{Objective-C}
\item \textbf{Objective-C++}
\end{itemize}
\subsubsection{Arquitecturas}
\begin{itemize}
\item \textbf{Alpha}
\item \textbf{ARM}
\item \textbf{Atmel AVR}
\item \textbf{Blackfin}
\item \textbf{H8/300}
\item \textbf{System/370, System/390}
\item \textbf{IA-32 (x86) and x86-64}
\item \textbf{IA-64 i.e. the "Itanium"}
\item \textbf{Motorola 68000}
\item \textbf{Motorola 88000}
\item \textbf{MIPS}
\item \textbf{PA-RISC}
\item \textbf{PDP-11}
\item \textbf{PowerPC}
\item \textbf{SuperH}
\item \textbf{SPARC}
\item \textbf{VAX}
\item \textbf{Renesas R8C/M16C/M32C}
\item \textbf{MorphoSys}
\end{itemize}
Como puede verse GCC soporta una gran cantidad de lenguajes de programaci<63>n, sin embargo, en el presente estudio solo lo utilizaremos como herramienta de compilaci<63>n para C y C++. Una caracter<65>stica de resaltar de GCC es la gran cantidad de plataformas que soporta, esto lo hace una herramienta Universal para el desarrollo de sistemas embebidos, el c<>digo escrito en una plataforma (en un lenguaje de alto nivel) puede ser implementado en otra sin mayores cambios, esto elimina la dependencia entre el c<>digo fuente y el HW\footnote{Esto recibe el nombre de re-utilizaci<63>n de c<>digo}, lo cual no ocurre al utilizar lenguaje ensamblador.
Por otro lado, el tiempo requerido para realizar aplicaciones utilizando C o C++ disminuye, ya que no es necesario aprender las instrucciones en assembler de una plataforma determinada; adem<65>s, la disponibilidad de librer<65>as de m<>ltiples prop<6F>sitos reduce a<>n m<>s los tiempos de desarrollo, permitiendo de esta forma tener bajos tiempos \textit{time to market} y reducir de forma considerable el costo del desarrollo. Una consecuencia de esto se refleja en el n<>mero de desarrolladores en un grupo de trabajo, en la actualidad casi el 60\% de las empresas desarrolladoras de dispositivos embebidos tiene grupos con menos de 10 desarrolladores \ref{group}.
\begin{figure}[H]
\begin{center} \includegraphics[scale=.2]{./images/vdc_embedded_dev_company_size} \end{center}
\caption{N<EFBFBD>mero promedio de desarrolladores por compa<70><61>a. Fuente Venture Development Corp}\label{group}
\end{figure}
\subsubsection{GNU Debugger}
El depurador oficial de GNU (GDB), es un depurador que al igual que GCC tiene soporte para m<>ltiples lenguajes y plataformas. GDB permite al usuario monitorear y modificar las variables internas del programa y hacer llamado a funciones de forma independiente a la ejecuci<63>n normal del mismo. Adem<65>s, permite establecer sesiones remotas utilizando el puerto serie o TCP/IP. Aunque GDB no posee una interfaz gr<67>fica, se han desarrollado varios front-ends como DDD o GDB/Insight. A continuaci<63>n se muestra un ejemplo de una sesi<73>n con gdb.
\begin{lstlisting}[firstnumber=40]
GNU gdb Red Hat Linux (6.3.0.0-1.21rh)
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "i386-redhat-linux-gnu"...Using host libthread_db
library "/lib/libthread_db.so.1".
(gdb) run
Starting program: /home/sam/programming/crash
Reading symbols from shared object read from target memory...done.
Loaded system supplied DSO at 0xc11000
This program will demonstrate gdb
Program received signal SIGSEGV, Segmentation fault.
0x08048428 in function_2 (x=24) at crash.c:22
22 return *y;
(gdb) edit
(gdb) shell gcc crash.c -o crash -gstabs+
(gdb) run
The program being debugged has been started already.
Start it from the beginning? (y or n) y
warning: cannot close "shared object read from target memory": File in wrong format
`/home/sam/programming/crash' has changed; re-reading symbols.
Starting program: /home/sam/programming/crash
Reading symbols from shared object read from target memory...done.
Loaded system supplied DSO at 0xa3e000
This program will demonstrate gdb
24
Program exited normally.
(gdb) quit
\end{lstlisting}
\subsubsection{C Libraries}
Adicionalmente es necesario contar con una librer<65>a que proporcione las librer<65>as standard de C: stdio, stdlib, math; las m<>s utilizadas en sistemas embebidos son:
\begin{itemize}
\item \textbf{glibc\footnote{http://www.gnu.org/software/libc/}} Es la librer<65>a C oficial del proyecto GNU. Uno de los inconvenientes al trabajar con esta librer<65>a en sistemas embebidos es que genera ejecutables de mayor tama<6D>o que los generados a partir de otras librer<65>as, lo cual no la hace muy atractiva para este tipo de aplicaciones.
\item \textbf{uClibc\footnote{http://uclibc.org/}} Es una librer<65>a dise<73>ada especialmente para sistemas embebidos, es mucho m<>s peque<75>a que \textbf{glibc}.
\item \textbf{newlib\footnote{http://sources.redhat.com/newlib/}} Al igual que \textbf{uClibc}, est<73> dise<73>ada para sistemas embebidos. El t<>pico ``Hello, world!'' ocupa menos de 30k en un entorno basado en newlib, mientras que en uno basado en glibc, puede ocupar 380k \cite{BG}.
\item \textbf{diet libc\footnote{http://www.fefe.de/dietlibc/}} Es una versi<73>n de \textit{libc} optimizada en tama<6D>o, puede ser utilizada para crear ejecutables est<73>ticamente enlazados para linux en plataformas alpha, arm, hppa, ia64, i386, mips, s390, sparc, sparc64, ppc y x86\_64.
\end{itemize}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% SECCION Obtenci<63>n y utilizaci<63>n del GNU toolchain
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\section{Desarrollo Software}
El primer paso en nuestro estudio consiste en tener una cadena de herramientas funcional que soporte la familia de procesadores a utilizar. La arquitectura sobre la cual realizaremos nuestro estudio inicial es la ARM (Advanced Risc Machines), ya que la m<>s utilizada en la actualidad por los dise<73>adores de sistemas embebidos (ver figura \ref{arch}) y se encuentran disponibles una gran variedad de herramientas para esta arquitectura. Sin embargo, lo contenido en esta secci<63>n es aplicable a cualquier familia de procesadores soportada por la cadena de herrmientas GNU. Existen dos formas de obtener la cadena de herramientas GNU:
\begin{figure}
\begin{center} \includegraphics[scale=.8]{./images/embedded-processor-trends-sm} \end{center}
\caption{Tendencia del mercado de procesadores para sistemas embebidos. Fuente:\cite{Lin05} }\label{arch}
\end{figure}
\begin{enumerate}
\item Utilizar una distribuci<63>n precompilada: Esta es la via m<>s r<>pida, sin embargo, hay que tener cuidado al momento de instalarlas, ya que debe hacerse en un directorio con el mismo \textit{path} con el que fueron creadas. por ejemplo \textit{/usr/local/gnutools}; si esto no se cumple, las herramientas no funcionar<61>n de forma adecuada.
\item Utilizar un script de compilaci<63>n: Existen disponibles en la red una serie de \textit{scripts} que permiten descargar, configurar, compilar e instalar la cadena de herramientas, la ventaja de utilizar este m<>todo es que es posible elegir las versiones de las herramientas instaladas, al igual que el directorio de instalaci<63>n. En este estudio utilizaremos los \textit{scripts} creados por Dan Kegel \cite{DK06}.
\end{enumerate}
\subsection{Flujo de dise<73>o software}
En la figura \ref{toolchain_flow} se ilustra la secuencia de pasos que se realizan desde la creaci<63>n de un archivo de texto que posee el c<>digo fuente que implementa la funcionalidad de una tarea software utilizando un lenguaje de alto nivel como C o C++, hasta su programaci<63>n en una memoria permanente en la plataforma f<>sica. Los pasos necesarios para crear un archivo que pueda ser programado en dicha memoria son:
\begin{figure}
\begin{center} \includegraphics[scale=.6]{./images/SW_design_flow} \end{center}
\caption{Tendencia del mercado de procesadores para sistemas embebidos. Fuente:\cite{Lin05} }\label{toolchain_flow}
\end{figure}
\begin{enumerate}
\item \textbf{Escritura del c<>digo fuente:} Creaci<63>n del c<>digo fuente en cualquier editor de texto utilizando un lenguaje de alto nivel como C o C++.
\item \textbf{Compilaci<EFBFBD>n:} Utilizando un compilador (GCC en nuestro caso) se crea un \textit{objeto} que contiene las instrucciones en \textit{lenguaje de m<>quina} del procesador a utilizar (uno diferente al que realiza la compilaci<63>n que normalmente es de la familia x86); en este punto el compilador solo busca en los encabezados (\textit{headers}) la definici<63>n de una determinada funci<63>n, esto es, la forma en que debe ser utilizada, el tipo de datos y el n<>mero de par<61>metros con que debe ser invocada, por ejemplo, la funci<63>n \textit{printf} esta declarada en el archivo \textit{stdio.h} como: \textit{ int printf (const char *template, ...)}. Esta declaraci<63>n es utilizada por el compilador para verificar el correcto uso de esta funci<63>n.
\item \textbf{Enlazado:} En esta etapa se realizan dos tareas:
\begin{enumerate}
\item Se enlazan los archivos tipo objeto del proyecto, junto con librer<65>as precompiladas para el procesador de la plataforma, si una determinada funci<63>n no es definida en ninguna de estas librer<65>as, el \textit{enlazador} generar<61> un error y no se generar<61> el ejecutable.
\item Se definen las posici<63>nes f<>sicas de las secciones que componen el archivo ejecutable (tipo ELF), esto se realiza a trav<61>s de un link de enlazado en el que se define de forma expl<70>cita su localizaci<63>n.
\end{enumerate}
\item \textbf{Extracci<EFBFBD>n del archivo de programaci<63>n} En algunas aplicaciones (cuando no se cuenta con un sistema operativo) es necesario extraer las secciones del ejecutable que residen en los medios de almacenamiento no vol<6F>til, que como veremos m<>s adelante representan el conjunto de instrucciones que debe ejecutar el procesador de la plataforma y las constantes del programa. Esto se realiza con la herramiento \textit{objcopy}, la cual, nos permite generar archivos en la mayor<6F>a de los formatos soportados por los programadores de memorias y procesadores, como S19 e Intel Hex.
\item \textbf{Descarga del programa a la plataforma}. Dependiendo de la plataforma existen varios m<>todos para descargar el archivo de programaci<63>n a la memoria de la plataforma:
\begin{enumerate}
\item Utilizando un \textit{loader}: El \textit{loader} es una aplicaci<63>n que reside en un medio de almacenamiento no vol<6F>til y permite la descarga de archivos utilizando el puerto serie, USB, o una interfaz de red.
\item Utilizando el puerto JTAG: El puerto JTAG (Joint Test Action Group) proporciona una interfaz capaz de controlar los registros internos del procesador, y de esta forma, acceder a las memorias de la plataforma y ejecutar un programa residente en una determinada posici<63>n de memoria.
\end{enumerate}
\item \textbf{Depuraci<EFBFBD>n} Una vez se descarga la aplicaci<63>n a la plataforma es necesario someterla a una serie de pruebas con el f<>n de probar su correcto funcionamiento. Esto se puede realizar con el depurador GNU (GDB) y una interfaz de comunicaci<63>n que puede ser un puerto serie, USB o un adaptador de red.
\end{enumerate}
\subsection{El formato \textbf{ELF}}
El formato ELF (\textit{Executable and Linkable Format}) Es un st<73>ndard para objetos, librer<65>as y ejecutables y es el formato que genera las herramientas GNU. Como puede verse en la figura \ref{elf1} est<73> compuesto por varias secciones (\textit{link view}) o segmentos (\textit{execution view}). Si un programador est<73> interesado en obtener informaci<63>n de secciones sobre tablas de s<>mbolos, c<>digo ejecutable espec<65>fico o informaci<63>n de enlazado din<69>mico debe utilizar \textit{link view}. Pero si busca informaci<63>n sobre segmentos, como por ejemplo, la localizaci<63>n de los segmentos \textit{text} o \textit{data} debe utilizar \textit{execution view}. El encabezado describe el layout del archivo, proporcionando informaci<63>n de la forma de acceder a las secciones \cite{MLH98}.
\begin{figure}
\begin{center} \includegraphics[scale=.4]{./images/ELF_Link_exec1} \end{center}
\caption{Formato ELF}\label{elf1}
\end{figure}
Las secciones pueden almacenar c<>digo ejecutable, datos, informaci<63>n de enlazado din<69>mico, datos de depuraci<63>n, tablas de s<>mbolos,comentarios, tablas de strings, y notas. Las secciones m<>s importantes son las siguientes:
\begin{itemize}
\item \textbf{.bss} Datos no inicializados. (RAM)
\item \textbf{.comment} Informaci<63>n de la versi<73>n.
\item \textbf{.data y .data1} Datos inicializados. (RAM)
\item \textbf{.debug} Informaci<63>n para depuraci<63>n simb<6D>lica.
\item \textbf{.dynamic} Informaci<63>n sobre enlace din<69>mico
\item \textbf{.dynstr} Strings necesarios para el enlacedin<69>mico
\item \textbf{.dynsym} Tabla de s<>mbolos utilizada para enlace din<69>mico.
\item \textbf{.fini} C<>digo de terminaci<63>n de proceso.
\item \textbf{.init} C<>digo de inicializaci<63>n de proceso.
\item \textbf{.line} Informaci<63>n de n<>mero de l<>nea para depuraci<63>n simb<6D>lica.
\item \textbf{.rodata y .rodta1} Datos de solo-lectura (ROM)
\item \textbf{.shstrtab} Nombres de secciones.
\item \textbf{.symtab} Tabla de s<>mbolos.
\item \textbf{.text} Instrucciones ejecutables (ROM)
\end{itemize}
Para aclarar un poco este concepto, escribamos una aplicaci<63>n sencilla:
\begin{lstlisting}
#include <stdio.h>
int global;
int global_1 = 1;
int main(void)
{
int i; // Variable no inicializada
int j = 2; // Variable inicializada
for(i=0; i<10; i++){
printf("Printing %d\n", i*j); // Caracteres constantes
j = j + 1;
global = i;
global_1 = i+j;
}
return 0;
}
\end{lstlisting}
Generemos el objeto compil<69>ndolo con el siguiente comando:
\textit{arm-none-eabi-gcc -c hello.c}
Examinemos que tipo de secciones tiene este ejecutable
\textit{arm-none-eabi-readelf -S hello.o}
\begin{lstlisting}
Section Headers:
[Nr] Name Type Addr Off Size ES Flg Lk Inf Al
[ 0] NULL 00000000 000000 000000 00 0 0 0
[ 1] .text PROGBITS 00000000 000034 00009c 00 AX 0 0 4
[ 2] .rel.text REL 00000000 000484 000020 08 9 1 4
[ 3] .data PROGBITS 00000000 0000d0 000004 00 WA 0 0 4
[ 4] .bss NOBITS 00000000 0000d4 000000 00 WA 0 0 1
[ 5] .rodata PROGBITS 00000000 0000d4 000010 00 A 0 0 4
[ 6] .comment PROGBITS 00000000 0000e4 00004d 00 0 0 1
[ 7] .ARM.attributes ARM_ATTRIBUTES 00000000 000131 00002e 00 0 0 1
[ 8] .shstrtab STRTAB 00000000 00015f 000051 00 0 0 1
[ 9] .symtab SYMTAB 00000000 000368 0000f0 10 10 11 4
[10] .strtab STRTAB 00000000 000458 00002b 00 0 0 1
Key to Flags:
W (write), A (alloc), X (execute), M (merge), S (strings)
I (info), L (link order), G (group), x (unknown)
O (extra OS processing required) o (OS specific), p (processor specific)
\end{lstlisting}
La secci<63>n \textit{.text}, como se dijo anteriormente contiene las instrucciones ejecutables, por esta raz<61>n se marca como ejecutable \textit{``X''} en la columna \textit{Flg}. Es posible ver las instrucciones que se ejecutan en esta secci<63>n:
\textit{arm-none-eabi-objdump -d -j .text hello.o}
\begin{lstlisting}
00000000 <main>:
0: e92d4800 stmdb sp!, {fp, lr}
4: e28db004 add fp, sp, #4 ; 0x4
8: e24dd008 sub sp, sp, #8 ; 0x8
c: e3a03002 mov r3, #2 ; 0x2
10: e50b3008 str r3, [fp, #-8]
14: e3a03000 mov r3, #0 ; 0x0
18: e50b300c str r3, [fp, #-12]
1c: ea000013 b 70 <main+0x70>
20: e51b200c ldr r2, [fp, #-12]
24: e51b3008 ldr r3, [fp, #-8]
28: e0030392 mul r3, r2, r3
2c: e59f005c ldr r0, [pc, #92] ; 90 <.text+0x90>
30: e1a01003 mov r1, r3
34: ebfffffe bl 0 <printf>
38: e51b3008 ldr r3, [fp, #-8]
3c: e2833001 add r3, r3, #1 ; 0x1
40: e50b3008 str r3, [fp, #-8]
44: e59f2048 ldr r2, [pc, #72] ; 94 <.text+0x94>
48: e51b300c ldr r3, [fp, #-12]
4c: e5823000 str r3, [r2]
50: e51b200c ldr r2, [fp, #-12]
54: e51b3008 ldr r3, [fp, #-8]
58: e0822003 add r2, r2, r3
5c: e59f3034 ldr r3, [pc, #52] ; 98 <.text+0x98>
60: e5832000 str r2, [r3]
64: e51b300c ldr r3, [fp, #-12]
68: e2833001 add r3, r3, #1 ; 0x1
6c: e50b300c str r3, [fp, #-12]
70: e51b300c ldr r3, [fp, #-12]
74: e3530009 cmp r3, #9 ; 0x9
78: daffffe8 ble 20 <main+0x20>
7c: e3a03000 mov r3, #0 ; 0x0
80: e1a00003 mov r0, r3
84: e24bd004 sub sp, fp, #4 ; 0x4
88: e8bd4800 ldmia sp!, {fp, lr}
8c: e12fff1e bx lr
\end{lstlisting}
La secci<63>n \textit{.data} mantiene las variables inicializadas, y contiene:
\textit{arm-none-eabi-objdump -d -j .data hello.o}
\begin{lstlisting}
00000000 <global_1>:
0: 01 00 00 00
\end{lstlisting}
Como vemos, la secci<63>n \textit{.data} contiene \'unicamente el valor de inicializaci\'on de la variable \textit{global\_1} (1) y no muestra informaci<63>\'on acerca de la variable \textit{j}, esto se debe a que la informaci\'on est\'a en el \textit{stack} del proceso. Si observamos el contenido de la secci<63>n \textit{.text} observamos que esta variable es asignada en tiempo de ejecuci<63>n, en la l<>nea \textit{0c:} se ve la asignaci<63>n de esta variable.
\begin{lstlisting}
0c: e3a03002 mov r3, #2 ; 0x2
10: e50b3008 str r3, [fp, #-8]
\end{lstlisting}
La secci<63>n \textit{.bss} mantiene la informaci\'on de las variables no incializadas (En Linux todas las variables no inicializadas, se inicializadan en cero):
\textit{arm-none-eabi-objdump -d -j .bss hello}
\begin{lstlisting}
000145c4 <global>:
145c4: 00000000
\end{lstlisting}
La secci<63>n \textit{.rodata} mantiene los datos que no cambian durante la ejecuci<63>n del programa, es decir, de solo lectura, si examinamos esta secci<63>n obtenemos:
\textit{hexdump -C hello.o | grep -i 000000d0} (la secci<63>n \textit{.rodata} comienza en la posici<63>n de memoria 0xd4)
\begin{lstlisting}
000000d0 01 00 00 00 50 72 69 6e 74 69 6e 67 20 25 64 0a |....Printing %d.|
000000e0 00 00 00 00 00 47 43 43 3a 20 28 43 6f 64 65 53 |.....GCC: (CodeS|
\end{lstlisting}
En el contenido de esta secci<63>n aparece la cadena de caracteres \textit{Printing \%d\\n}, es decir, los datos que no cambian durante la ejecuci<63>n.
\subsection{Herramienta de compilaci<63>n make}
Como pudo verse en la secci<63>n es necesario realizar una serie de pasos para poder descargar una aplicaci<63>n a una plataforma embebida. Debido a que las herramientas GNU solo poseen entrada por consola, es necesario esribir una serie de comandos cada vez que se realiza un cambio en el c<>digo fuente, lo cual resulta poco pr<70>ctico. Para realizar este proceso de forma autom<6F>tica se cre<72> la herramienta \textit{make}, la cual recibe como entrada un archivo que normalmente tiene el nombre \textit{Makefile} o \textit{makefile} y determina que archivos han sido modificados desde la <20>ltima compilaci<63>n y ejecuta los comandos necesarios para recompilarlos. Un ejemplo de este tipo de archivo se muestra a continuaci<63>n:
\begin{lstlisting}[numbers=left]
SHELL = /bin/sh
basetoolsdir = /home/at91/gcc-3.4.5-glibc-2.3.6/arm-softfloat-linux-gnu
bindir = ${basetoolsdir}/bin
libdir = ${basetoolsdir}/lib/gcc/arm-softfloat-linux-gnu/3.4.5
CC = arm-softfloat-linux-gnu-gcc
AS = arm-softfloat-linux-gnu-as
LD = arm-softfloat-linux-gnu-ld
OBJCOPY = arm-softfloat-linux-gnu-objcopy
CFLAGS =-mcpu=arm920t -I. -Wall
LDFLAGS =-L${libdir} -l gcc
OBJS = \
main.o \
debug_io.o \
at91rm9200_lowlevel.o \
p_string.o
ASFILES = arm_init.o
LIBS=${libdir}/
all: hello_world
hello_world: ${OBJS} ${ASFILES} ${LIBS}
${LD} -e 0 -o hello_world.elf -T linker.cfg ${ASFILES} ${OBJS} ${LDFLAGS}
${OBJCOPY} -O binary hello_world.elf hello_world.bin
clean:
rm -f *.o *~ hello_world.*
PREPROCESS.c = $(CC) $(CPPFLAGS) $(TARGET_ARCH) -E -Wp,-C,-dD,-dI
%.pp : %.c FORCE
$(PREPROCESS.c) $< > $@
\end{lstlisting}
En las l<>neas 3-5 se definen algunas variables globales que ser<65>n utilizadas a lo largo del archivo; en las l<>neas 7 - 10 se definen las herramientas de compilaci<63>n a utilizar, espec<65>ficamente el compilador C (CC), el ensamblador (AS), el enlazador (LD) y la utilidad objcopy. A partir de la l<>nea 15 se definen los objetos que forman parte del proyecto, en este caso: \textit{main.o, debug\_io.o, at91rm9200\_lowlevel.o y p\_string.o}; en la l<>nea 21 se definen los archivos en assembler que contiene el proyecto, para este ejemplo \textit{arm\_init.o}. Las l<>neas 12 y 13 definen dos variables especiales que se pasan directamente al compilador C (CFLAGS) y al enlazador (LDFLAGS) y definen par<61>metros de comportamiento de estas herramientas.
\begin{lstlisting}
CFLAGS =-mcpu=arm920t -I. -Wall
\end{lstlisting}
El par<61>metro \textit{-mcpu} le indica al compilador C para arquitecturas \textit{ARM} que utilice la familia \textit{arm920}; el par<61>metro \textit{-I} le indica un directorio donde puede buscar los encabezados, en este caso el caracter "." le indica que busque en el mismo sitio donde se encuentran los archivos fuente; el par<61>metro \textit{-Wall} le indica que imprima todos los mensajes de errores y advertencias.
\begin{lstlisting}
LDFLAGS =-L${libdir} -l gcc
\end{lstlisting}
El par<61>metro \textit{-L} le indica al enlazador la ruta del directorio donde se encuentran las librer<65>as, en este ejemplo apunta a la variable textit{libdir} que se encuentra declarado como \textit{\${basetoolsdir}/lib/gcc/arm-softfloat-linux-gnu/3.4.5}; el par<61>metro \textit{-l} le indica al enlazador que debe utilizar la librer<65>a \textit{gcc} que se encuentra en el directorio definido previamente. En realidad el archivo de la librer<65>a tienen el nombre \textit{libgcc.a}, pero como todas las librer<65>as tienen el nombre \textit{libXXXX.a} se eliminan el encabezado y la extensi<73>n del archivo.
En las l<>neas 25, 27 y 31 aparecen unas etiquetas de la forma: \textit{nombre:} estos labels permiten ejecutar de forma independiente el conjunto de instrucciones asociadas a ellas, por ejemplo, si se ejecuta:
\\ \bigskip
\textit{make clean}\\ \bigskip
make ejecutar<61> el comando:\\ \bigskip
\textit{rm -f *.o *~ hello\_world.*}
Observemos los comandos asociados a la etiqueta \textit{hello\_world:} En la misma l<>nea aparecen \textit{\${OBJS} \${ASFILES} \${LIBS}} esto le indica a la herramienta \textit{make} que antes de ejecutar los comandos asociados a este label, debe realizar las acciones necesarias para generar \textit{\${OBJS} \${ASFILES} \${LIBS}} o lo que es lo mismo: \textit{main.o, debug\_io.o, at91rm9200\_lowlevel.o, p\_string.o, arm\_init.o y libgcc.a}. Para esto, \textit{make} tiene predefinidas una serie de reglas para compilar los archivos .c la regla es de la forma:
\begin{lstlisting}
.c.o:
$(CC) $(CFLAGS) -c $<
.c:
$(CC) $(CFLAGS) $@.c $(LDFLAGS) -o $@
\end{lstlisting}
Lo cual le indica a la herramienta make que para generar un archivo \textit{.o} a partir de uno \textit{.c} es necesario ejecutar \textit{\$(CC) \$(CFLAGS) -c \$<}; de aqui la importancia de definir bien la variable de entorno \textit{CC} cuando trabajamos con compiladores cruzados\footnote{Un compilador cruzado genera c<>digo para una plataforma diferente en la que se est<73> ejecutando, por ejemplo, genera ejecutables para ARM pero se ejecuta en un x86}. Hasta este punto al ejecutar el comando: \textit{make hello\_world}, \textit{make} realizar<61>a las siguientes operaciones: \\
\begin{lstlisting}
arm-softfloat-linux-gnu-gcc -mcpu=arm920t -I. -Wall -c -o main.o main.c
arm-softfloat-linux-gnu-gcc -mcpu=arm920t -I. -Wall -c -o debug_io.o debug_io.c
arm-softfloat-linux-gnu-gcc -mcpu=arm920t -I. -Wall -c -o at91rm9200_lowlevel.o at91rm9200_lowlevel.c
arm-softfloat-linux-gnu-gcc -mcpu=arm920t -I. -Wall -c -o p_string.o p_string.c
arm-softfloat-linux-gnu-as -o arm_init.o arm_init.s
\end{lstlisting}
En las l<>neas 28 se realiza el proceso de enlazado; al \textit{enlazador} se le pasan los par<61>metros:
\begin{itemize}
\item \textbf{-e 0}: Punto de entrada , utiliza la direcci<63>n de memoria 0 como punto de entrada.
\item \textbf{-o hello\_world.elf}: Nombre del archivo de salida \textit{hello\_world}
\item \textbf{-T linker.cfg}: Utilice el archivo de enlace \textit{linker.cfg} para definir las posiciones de memoria de las secciones del ejecutable.
\item \textbf{\${ASFILES} \${OBJS} \${LDFLAGS}}: Lista de objetos y librer<65>as para crear el ejecutable.
\end{itemize}
En la l<>nea 29 se utiliza la herramienta \textit{objcopy} para generar un archivo binario (\textit{-O binary}) con la informaci<63>n necesaria para cargar en una memoria no vol<6F>til.
\subsection{Archivo de enlace}
Como vimos anteriormente, el enlazador o \textit{linker} es el encargado de agrupar todos los archivos objeto \textit{.o}, y las librer<65>as necesarias para crear el ejecutable, adicionalmente, permite definir donde ser<65>n ubicados los diferentes segmentos del archivo ELF en un archivo de enlace \textit{linker script}. De esta forma podemos ajustar el ejecutable a plataformas con diferentes configuraciones de memoria, lo que proporciona un grado mayor de flexibilidaad de la cadena de herramientas GNU. Cuando se dispone de un sistema operativo como Linux no es necesario definir este archivo, ya que el sistema operativo se encarga del manejo de las diferentes secciones, sin embargo, es necesario tenerlo presente ya que como veremos m<>s adelante existe un momento en el que el sistema operativo no ha sido cargado en la plataforma y las aplicaciones que se ejecuten deben proporcionar esta informaci<63>n. A continuaci<63>n se muestra un ejemplo de este archivo:
\begin{lstlisting}
/* identify the Entry Point (_vec_reset is defined in file crt.s) */
ENTRY(_vec_reset)
/* specify the memory areas */
MEMORY
{
flash : ORIGIN = 0, LENGTH = 256K /* FLASH EPROM */
ram : ORIGIN = 0x00200000, LENGTH = 64K /* static RAM area */
}
/* define a global symbol _stack_end */
_stack_end = 0x20FFFC;
/* now define the output sections */
SECTIONS
{
. = 0; /* set location counter to address zero */
.text : /* collect all sections that should go into FLASH after startup */
{
*(.text) /* all .text sections (code) */
*(.rodata) /* all .rodata sections (constants, strings, etc.) */
*(.rodata*) /* all .rodata* sections (constants, strings, etc.) */
*(.glue_7) /* all .glue_7 sections (no idea what these are) */
*(.glue_7t) /* all .glue_7t sections (no idea what these are) */
_etext = .; /* define a global symbol _etext just after the last code byte */
} >flash /* put all the above into FLASH */
.data : /* collect all initialized .data sections that go into RAM */
{
_data = .; /* create a global symbol marking the start of the .data section */
*(.data) /* all .data sections */
_edata = .; /* define a global symbol marking the end of the .data section */
} >ram AT >flash /* put all the above into RAM (but load the LMA initializer copy into FLASH) */
.bss : /* collect all uninitialized .bss sections that go into RAM */
{
_bss_start = .; /* define a global symbol marking the start of the .bss section */
*(.bss) /* all .bss sections */
} >ram /* put all the above in RAM (it will be cleared in the startup code */
. = ALIGN(4); /* advance location counter to the next 32-bit boundary */
_bss_end = . ; /* define a global symbol marking the end of the .bss section */
}
_end = .; /* define a global symbol marking the end of application RAM */
\end{lstlisting}
En las primeras l<>neas del archivo aparece la declaraci<63>n de las memorias de la plataforma, en este ejemplo tenemos una memoria RAM de 64kB que comienza en la posici<63>n de memoria 0x00200000 y una memoria flash de 256k que comienza en la posici<63>n 0x0. A continuacion se definen las secciones y el lugar donde ser<65>n almacenadas; En este caso, las secciones \textit{.text} (c<EFBFBD>digo ejecutable) y \textit{.rodata} (datos de solo lectura) se almacenan en una memoria no vol<6F>til la flash. Cuando el sistema sea energizado el procesador ejecutar<61> el c<>digo almacenado en su memoria no vol<6F>til. Las secciones \textit{.data} (variables inicializadas) y \textit{.bss} (variables no inicializadas) se almacenar<61>n en la memoria vol<6F>til RAM, ya que el acceso a las memorias no vol<6F>tiles son m<>s lentas y tienen ciclos de lectura/escritura finitos.
\section{Herramientas hardware}
En esta subsecci<63>n se realizar<61> una breve descripci<63>n de los dispositivos semiconductores m<>s utilizados para la implementaci<63>n de dispositivos digitales, esto, con el f<>n de determinar el estado actual de la industria de los semiconductores y entender los componentes b<>sicos con los que se pueden implementar dispositivos digitlaes modernos.
\subsection{SoC}
La Figura \ref{at91rm} muestra la arquitectura de un SoC actual, espec<65>ficamente del AT91RM920 de Atmel. En este diagrama podemos observar el n<>cleo central un procesador ARM920T de 180MHz y los perif<69>ricos asociados a <20>l. En la actualidad podemos encontrar una gran variedad de SoC dise<73>ados para diferentes aplicaciones: Multimedia, Comunicaciones, Asistentes Digitales; los perif<69>ricos incluidos en cada SoC buscan minimizar el n<>mero de componentes externos, y de esta forma reducir los costos. Este SoC en particular fu<66> uno de los primeros que dise<73>o ATMEL y est<73> enfocado a tareas en las que se requiere una conexi<78>n de red. La arquitectura de estos SoC evoluciona muy r<>pido acomod<6F>ndose a los requerimientos de nuevas aplicaciones, b<>sicamente, los cambios se producen en la velocidad del procesador central y la adici<63>n de perif<69>ricos que permiten el control directo de nuevos perif<69>ricos, como por ejemplo, la adici<63>n de controladores de pantallas de cristal l<>quido o salidas de video. Dentro de estos perif<69>ricos encontramos:
\begin{itemize}
\item Controlador para memorias: NAND flash, DataFlash, SDRAM, DDR, SD/MMC
\item Puertos USB host o device.
\item Puerto I2C
\item Interfaz Ethernet 10/100.
\item Interfaz high speed USB 2.0
\item Puertos SPI.
\item Puertos seriales (RS232).
\item Soporte JTAG.
\item Interf<72>z de Bus externo (EBI).
\item Controlador de LCD.
\item Driver de video.
\item Tarjetas de sonido.
\end{itemize}
\begin{figure}
\begin{center} \includegraphics[scale=.7]{./images/at91rm9200} \end{center}
\caption{SoC AT91RM9200 fuente: Hoja de Especificaciones AT91RM9200, ATMEL} \label{at91rm}
\end{figure}
Existen una serie de perif<69>ricos que son indispensables en todo Sistema Embebido, los cuales facilitan la programaci<63>n de aplicaciones y la depuraci<63>n de las mismas. Uno de los m<>s importantes y que est<73>n presentes en todos los SoC actuales es el controlador de memorias, este perif<69>rico permite controlar los medios de almecenamiento que son vitales para la correcta oepraci<63>n del dispositivo, a continuaci<63>n se hace un breve recuento de las memorias disponibles para el desarrollo de aplicaciones embebidas.
\subsection{Memorias Vol<6F>tiles}
Como se estudi<64> anteriormente existen secciones de un ejecutable que deben ser almacenadas en memorias vol<6F>tiles o en memorias no vol<6F>tiles. Debido a esto, la mayor<6F>a de los SoC incluyen perif<69>ricos dedicados a controlar diferentes tipos de memoria, las memorias vol<6F>tiles son utilizadas como memoria de acceso aleatorio (RAM) gracias a su bajo tiempo de accesso y al ilimitado n<>mero de ciclos de lectura/escritura.
\subsubsection{memoria SDRAM}
El tipo de memoria m<>s utilizado en los sistemas embebidos actuales es la memoria SDRAM; la cual est<73> organizada como una matriz de celdas, con un n<>mero de bits dedicados al direccionamiento de las filas y un n<>mero dedicado a direccionar columnas (ver Figura \ref{sdram_basics}).
\begin{figure}
\begin{center} \includegraphics[scale=.6]{./images/sdram_basics} \end{center}
\caption{Diagrama de Bloques de una memoria SDRAM fuente: Hoja de Especificaciones MT48LC16M16, Micron Technology} \label{sdram_basics}
\end{figure}
Una celda de memoria SDRAM esta compuesta por un transistor y un condensador; el transistor suministra la carga y el condensador almacena el estado de cada celda, esta carga en el condensador desaparece con el tiempo, raz<61>n por la cual es necesario recargar estos condensadores peri<72>dicamente, este proceso recibe el nombre de \textit{Refresco}. Un ciclo de refresco es un ciclo especial en el que no se escribe ni se lee informaci<63>n, solo se recargan los condensadores para mantener la informaci<63>n.
Un ejemplo simplificado de una operaci<63>n de lectura es el siguiente: Una posici<63>n de memoria se determina colocando la direcci<63>n de la fila y la de la columna en las l<>neas de direcci<63>n de fila y columna respectivamente, un tiempo despu<70>s el dato almacenado aparecer<65> en el bus de datos. El procesador coloca la direcci<63>n de la fila en el bus de direcciones y despu<70>s activa la se<73>al \textit{RAS} (Row Access Strobe). Despu<70>s de un retardo de tiempo predeterminado para permitir que el circuito de la SDRAM capture la direcci<63>n de la fila, el procesador coloca la direcci<63>n de la columna en el bus de direcciones y activa la se<73>al \textit{CAS} (Column Access Strobe). El perif<69>rico que controla la SDRAM est<73> encargado de garantizar los ciclos de refresco de acuerdo con los requerimientos de la SDRAM \cite{CH06}.
\subsection{Memorias No Vol<6F>tiles}
La memorias no vol<6F>tiles almacenan por largos per<65>odos de tiempo la informaci<63>n necesaria para la operaci<63>n de un Sistema Embebido, pueden ser vistos como discos duros de estado s<>lido. Existen dos tipos de memoria las NOR y las NAND; las dos poseen la capacidad de ser escritas y borradas utilizando control de software, con lo que no es necesario utilizar programadores externos y pueden ser modificadas una vez sean instaladas en el circuito impreso. Una desventaja de estas memorias es que los tiempos de escritura y borrado son muy largos en comparaci<63>n con los de las memorias RAM y que presentan un n<>mero finito de ciclos de borrado y exritura.
\subsubsection{Memorias NOR}
Las memorias NOR poseen buses de datos y direcci<63>n, con lo que es posible acceder de forma f<>cil a cada byte almacenado en ella. Los bits almacenados pueden ser cambiados de 0 a 1 utilizando el control de software un byte a la vez, sin embargo, para cambiar un bit de 1 a 0 es necesario borrar una serie de unidades de borrado que reciben el nombre de bloques, lo que reduce el tiempo de borrado de la memoria. Debido a que el borrado y escritura de una memoria ROM se puede realizar utilizando el control software (ver Figura \ref{nor_prog}) no es necesario contar con un perif<69>rico especializado para su manejo. Las memorias NOR son utilizadas en aplicaciones donde se necesiten altas velocidades de lectura y baja densidad, debido a que los tiempos de escritura y lectura son muy grandes, se utilizan como memorias ROM.
\begin{figure}
\begin{center} \includegraphics[scale=.6]{./images/nor_prog} \end{center}
\caption{Ciclos de escritura y borrado de una memoria flash NOR} \label{nor_prog}
\end{figure}
\subsubsection{Memorias NAND}
Las memorias NAND disminuyen los tiempos de escritura y aumentan la capacidad de almacenamiento, ideales para aplicaciones donde se requiera almacenamiento de informaci<63>n. Adicionalmente las memorias NAND consumen menos potencia que las memorias NAND, por esta raz<61>n este tipo de memorias son utilizadas en casi todos los dispositivos de almacenamiento modernos como las memorias SD y las memorias USB, los cuales integran una memoria NAND con un circuito encargado de controlarlas e implementar el protocolo de comunicaci<63>n. A diferencia de las flash tipo NOR, los dispositivos NAND se acceden de forma serial utilizando interfaces complejas; su operaci<63>n se asemeja a un disco duro tradicional. Se accede a la informaci<63>n utilizando bloques (m<EFBFBD>s peque<75>os que los bloques NOR). Los ciclos de escritura de las flash NAND son mayores en un orden de magnitud que los de las memorias NOR.
Un problema al momento de trabajar con las memorias tipo NAND es que requieren el uso de un \textit{manejo de bloques defectuosos}, esto es necesario ya que las celdas de memoria pueden da<64>arse de forma espont<6E>nea durante la operaci<63>n normal. Debido a esto se debe tener un determinado n<>mero de bloques que se encargen de almacenar tablas de mapeo para manejar los bloques defectuosos; o puede hacerse un chequeo en cada inicializaci<63>n del sistema de toda la RAM para actualizar esta lista de sectores defectuosos. El algoritmo de ECC (Error-Correcting Code) debe ser cap<61>z de corregir errores tan peque<75>os como un bit de cada 2048 bits, hasta 22 bits de cada 2048. Este algor<6F>tmo es capaz de detectar bloques defectuosos en la fase de programac<61><63>n comparando la informaci<63>n almacenada con la que debe ser almacenada (verificaci<EFBFBD>n), si encuentra un error marca el bloque como defectuoso y utiliza un bloque sin defactos para almacenar la informaci<63>n.
La tabla \ref{flash_comp} resume las principales caracter<65>sticas de los diferentes tipos de memoria flash y muestra sus aplicaciones t<>picas.
\begin{center}
\begin{table}[ht]
\begin{tabular}{|l|c|c|c|}
\hline
& \textbf{SLC NAND} & \textbf{MLC NAND} & MLC NOR \\ \hline
Densidad & 512Mbits - 4GBits & 1Gbits - 16GBits & 16MBits - 1GBit \\ \hline
Velocidad de Lectura & 24MB/s & 18.6MB/s & 103MB/s \\ \hline
Velocidad de escritura& 8 MB/s & 2.4MB/s & 0,47MB/s \\ \hline
Tiempo de borrado & 2ms & 2ms & 900ms \\ \hline
Interfaz & Acceso Indirecto & Acceso Indirecto & Acceso Aleatorio\\ \hline
Aplicaci<63>n & Almacenamiento & Almacenamiento & Solo lectura \\ \hline
\end{tabular}
\caption{Cuadro de comparaci<63>n de las memorias flash NAND y NOR} \label{flash_comp}
\end{table}
\end{center}
Adicionalmente, se encuentran dispoibles las memorias DATAFLASH, estos dispositivos son b<>sicamente una memoria flash tipo NOR con una interfaz SPI, permite una velocidad de lectura de hasta 66MHz utilizando solamente 4 pines para la comunicaci<63>n con el procesador.

658
course/.docs/cambio_categoria/chapter1.tex.backup Normal file
View File

@@ -0,0 +1,658 @@
\chapter{Dise<73>o de Sistemas Embebidos}
\section{Definici<63>n}
Un Sistema Embebidos es un sistema de prop<6F>sito espec<65>fico en el cual, el computador es encapsulado completamente por el dispositivo que el controla. A diferencia de los computadores de prop<6F>sito general, un Sistema Embebido realiza tareas pre-definidas, lo cual permite su optimizaci<63>n, reduciendo el tama<6D>o y costo del producto \cite{Wik}
\section{Caracter<65>sticas}
\begin{itemize}
\item Los sistemas embebidos son dise<73>ados para una aplicaci<63>n
espec\'{\i}fica, es decir, estos sistemas realizan un grupo de funciones
previamente definidasm y una vez el sistema es dise<73>ado, no se puede cambiar
su funcionalidad. Por ejemplo, el control de un asensor siempre realizar\'a
las mismas acciones durante su vida \'util.
\item Debido a su interacci<63>n con el entorno los ES deben cumplir
esctr<74>ctamente restricciones temporales. El t\'ermino {\textit{Sistemas
de Tiempo Real}} es utilizado para enfatizar este aspecto.
\item Los Sistemas Embebidos son heterog\'eneos, es decir, est\'an
compuestos por componentes Hardware y Software. Los componentes Hardware,
como ASICs y Dispositivos L\'ogicos Programables (PLD) proporcionan la
velocidad de ejecuci\'on y el cosumo de potencia necesarios en algunas
aplicaciones.
\item Los Sitemas Embebidos tienen grandes requerimientos en t\'erminos de
confiabilidad. Errores en aplicaciones como la aviaci\'on y el
automovilismo, pueden tener consecuencias desastrosas.
\end{itemize}
\section{Arquitectura}
Una arquitectura t<>pica para un Sistema Embebido se muestra en la Figura \ref{es_arch}; La cual integra un componente hardware, implementado ya sea en un PLD (CPLD, FPGA) o en un ASIC, conocido con el nombre de perif<69>ricos y un componente software (procesador o DSP) cap<61>z de ejecutar software, la parte del procesador est<73> dividida en la CPU (En algunos casos posee una cach<63>) y las unidades de Memoria.
\begin{figure}
\begin{center} \includegraphics[scale=.6]{./images/ES_Architecture} \end{center}
\caption{Arquitectura de un Sistema Embebido}\label{es_arch}
\end{figure}
Al momento de dise<73>ar un Sistema Embebido encontramos las siguientes opciones:
\begin{itemize}
\item Componente HW y SW Integrado en un dispositivo semiconductor (SoC): En la actualidad existen muchas compa<70><61>as que fabrican procesadores de 32 bits integrados a una gran variedad de perif<69>ricos, lo cual simplifica el dise<73>o y reduce costos (menos componentes y menos <20>rea de circuito impreso) \footnote{http://www.sharpsma.com, http://www.atmel.com, http://www.cirrus.com, http://www.samsung.com, http://www.freescale.com, etc}.
\item Componente SW en un SoC y componente HW en una FPGA: Cuando no existen en el mercado SoC con la cantidad de perif<69>ricos requerida para una determinada aplicaci<63>n, es necesario recurrir a la utilizaci<63>n de dispositivos comerciales que implementen dicha operaci<63>n, en algunas ocaciones el perif<69>rico puede relizar funciones muy espec<65>ficas de modo que no existe en el mercado, la soluci<63>n es entonces implementar estos dispositivos en una FPGA, tambi<62>n se recomienda la utilizaci<63>n de FPGAs en sistemas que requieren una gran cantidad y variedad de perif<69>ricos ya que reduce la complejidad y costo del sistema.
\item Componente SW y HW en una FPGA: Esta es tal vez la opci<63>n m<>s econ<6F>mica y flexible, pero la de menor desempe<70>o, ya que al utilizar los recursos l<>gicos de la FPGA para la implementaci<63>n del procesador (softcore) la lngitud de los caminos de interconexi<78>n entre los bloques l<>gicos aumentan el retardo de las se<73>ales . Los procesadores \textit{softcore} m<>s populares en la actualidad son:
\begin{itemize}
\item Microblaze de Xilinx\footnote{http://www.xilinx.com}
\item Leon de Gaisler Research \footnote{http://www.gaisler.com/}
\item LatticeMico32 de Lattice Semiconductors\footnote{http://www.latticesemi.com}
\item OpenRisc \footnote{http://www.opencores.com}
\end{itemize}
\end{itemize}
\section{Metodolog<6F>a de Dise<73>o}
La Figura \ref{des_flow}, muestra un diagrama de flujo gen<65>rico para dise<73>o para sistemas embebidos {\cite{Cor05}}
\begin{figure}
\begin{center} \includegraphics[scale=.55]{./images/design_flow} \end{center}
\caption{Flujo de Dise<73>o de un Sistema Embebido}\label{des_flow}
\end{figure}
El proceso comienza con la {\textit{especificaci\'on del sistema}}, en este punto se describe la funcionalidad y se definen las restricciones f\'{\i}sicas, el\'ectricas y econ\'omicas. Esta especificaci\'on debe ser muy general y no deben existir dependencias (tecnol\'ogicas, metodol\'ogicas) de ning\'un tipo, se suele utilizar lenguajes de alto nivel, como UML, C++. La especificaci\'on puede ser verificada a trav\'es de una serie de pasos de an\'alisis cuyo objetivo es determinar la validez de los algor\'{\i}tmos seleccionados, por ejemplo, determinar si el algoritmo siempre termina, los resultados satisfacen las especificaciones. Desde el punto de vista de la re-utilizaci\'on, algunas partes del funcionamiento global deben tomarse de una librer\'{\i}a de algor\'{\i}tmos existentes.
Una vez definidas las especificaciones del sistema se debe realizar un modelamiento que permita extraer de estas la funcionalidad. El modelamiento es crucial en el dise<73>o ya que de \'el depende el paso existoso de la especificaci\'on a la implementaci\'on. Es importante definir que modelo matem\'atico debe soportar el entorno de dise<73>o. Los modelos m\'as utilizados son: M\'aquinas de estados finitos, diagramas de flujos de datos, Sistemad de Eventos Discretos y Redes de Petri. Cada modelo posee propiedades matem\'aticas que pueden explotarse de forma eficiente para responder preguntas sobre la funcionalidad del sistema sin llevar a cabo dispendiosas tareas de verificaci\'on. \ Todo modelo obtenido debe ser verificado para comprobar que cumple con las restricciones del sistema.
Una vez se ha obtenido el modelo del sistema se procede a determinar su {\textit{arquitectura}}, esto es, el n\'umero y tipo de componentes y su inter-conexi\'on. Este paso no es m\'as que una exploraci\'on del espacio de dise<73>o en b\'usqueda de soluciones que permitan la implementaci\'on de una funcionalidad dada, y puede realizarse con varios criterios en mente: Costos, confiabilidad, viabilidad comercial.
Utilizando como base la arquitectura obtenida en el paso anterior las tareas del modelo del sistemas son mapeadas dentro de los componentes. Esto es,
asignaci\'on de funciones a los componentes de la arquitectura. Existen dos opciones a la hora de implementar las tareas o procesos:
\begin{enumerate}
\item Implementaci\'on Software: La tarea se va a ejecutar en un procesador.
\item Implementaci\'on Hardware: La tarea se va a ejecutar en un dispositivo l<>gico programable.
\end{enumerate}
Para cumplir las especificaciones del sistema algunas tareas deben ser implementadas en Hardware, esto con el f\'{\i}n de no ocupar al procesador en tareas c\'{\i}clicas, un ejemplo t\'{\i}pico de estas tareas es la generaci\'on de bases de tiempos. La decisi\'on de que tareas se implementan en SW y que tareas se implementan en HW recibe el nombre de {\textit{particionamiento}}, esta selecci\'on es fuertemente dependiente de restricciones econ\'omicas y temporales.
Las tareas Software deben compartir los recursos que existan en el sistema (procesador y memoria), por lo tanto se deben hacer decisiones sobre el orden de ejecuci\'on y la prioridad de estas. Este proceso recibe el nombre de {\textit{planificaci\'on}}. En este punto del dise<73>o el modelo debe incluir informaci\'on sobre el mapeo, el particionamiento y la planificaci\'on del sistema.
Las siguientes fases corresponden a la implementaci\'on del modelo, para esto las tareas hardware deben ser llevadas al dispositivo elegido (ASIC o FPGA) y
se debe obtener el $''$ejecutable$''$ de las tareas software, este proceso recibe el nombre de {\textit{s\'{\i}ntesis}} HW y SW respectivamente, as\'{\i}
mismo se deben sintetizar los mecanismos de comunicaci\'on.
El proceso de prototipado consiste en la realizaci\'on f\'{\i}sica del sistema, finalmente el sistema f\'{\i}sico debe someterse a pruebas para verificar que se cumplen con las especificaciones iniciales.
Como puede verse en el flujo de dise<73>o existen realimentaciones, estas realimentaciones permiten depurar el resultado de pasos anteriores en el caso de no cumplirse las especificaciones iniciales
\section{Herramientas de Dise<73>o Software}
En el mercado existe una gran variedad de herramientas de desarrollo para Sistemas Embebidos, sin embargo, en este estudio nos centraremos en el uso de las herramientas de libre distribuci<63>n; esta elecci<63>n se debe a que la mayor<6F>a de los productos comerciales utilizan el toolchain de GNU\footnote{http://www.gnu.org} internamente y proporcionan un entorno gr<67>fico para su f<>cil manejo. Otro factor considerado a la hora de realizar nuestra elecci<63>n es el econ<6F>mico, ya que la mayor<6F>a de los productos comerciales son costosos y poseen soporte limitado. Por otro lado, el toolchain de GNU es utilizado ampliamente en el medio de los dise<73>adores de sistemas embebidos y se encuentra un gran soporte en m<>ltiples foros de discusi<73>n (ver Figura \ref{tools}).
\begin{figure}
\begin{center} \includegraphics[scale=.7]{./images/embedded-linux-tool-trends-sm} \end{center}
\caption{Tendencia de utilizaci<63>n de herramientas de desarrollo}\label{tools}
\end{figure}
\subsection{Componentes del \textit{GNU toolchain} }
\subsubsection{GNU binutils\cite{A1}}
Son una colecci<63>n de utilidades para archivos binarios y estan compuestas por:
\begin{itemize}
\item \textbf{addr2line} Convierte direcciones de un programa en nombres de archivos y n<>meros de l<>nea. Dada una direcci<63>n y un ejecutable, usa la informaci<63>n de depuraci<63>n en el ejecutabe para determinar que nombre de atchivo y n<>mero de lpinea est<73> asociado con la direcci<63>n dada.
\item \textbf{ar} Esta utilidad crea, modifica y extrae desde ficheros. Un fichero es una colecci<63>n de otros archivos en una estructura que hace posible obtener los archivos individuales miembros del archivo.
\item \textbf{as} Utilidad que compila la salida del compilador de C (GCC).
\item \textbf{c++filt} Este program realiza un mapeo inverso: Decodifica nombres de bajo-nivel en nombres a nivel de usuario, de tal forma que el linker pueda mantener estas funciones sobrecargadas (overloaded) ``from clashing''.
\item \textbf{gasp} GNU Assembler Macro Preprocessor
\item \textbf{ld} El \textit{linker} GNU combina un n<>mero de objetos y ficheros, re-localiza sus datos y los relaciona con referencias. Normalmente el <20>ltimo paso en la construcci<63>n de un nuevo programa compilado es el llamado a ld.
\item \textbf{nm} Realiza un listado de s<>mbolos de archivos tipo objeto.
\item \textbf{objcopy} Copia los contenidos de un archivo tipo objeto a otro. \textit{objcopy} utiliza la librer<65>a GNU BFD para leer y escribir el archivo tipo objeto. Permite esccribibr el archivo destino en un formato diferente al del archivo fuente.
\item \textbf{objdump} Despliega informaci<63>n sobre archivos tipo objeto.
\item \textbf{ranlib} Genera un <20>ndice de contenidos de un fichero, y lo almacena en <20>l.
\item \textbf{readelf} Interpreta encabezados de un archivo ELF.
\item \textbf{size} Lista el tama<6D>o de las secciones y el tama<6D>o total de un archivo tipo objeto.
\item \textbf{strings} Imprime las secuencias de caracteres imprimibles de almenos 4 caracteres de longitud.
\item \textbf{strip} Elimina todos los s<>mbolos de un archivo tipo objeto.
\end{itemize}
\subsubsection{GNU Compiler Collection\cite{Wik}}
El \textit{GNU Compiler Collection} normalmente llamado GCC, es un grupo de compiladores de lenguajes de programaci<63>n producido por el proyecto GNU. Es el compilador standard para el software libre de los sistemas operativos basados en Unix y algunos propietarios como Mac OS de Apple.
\subsubsection{Lenguajes}
GCC soporta los siguientes lenguajes:
\begin{itemize}
\item \textbf{ADA}
\item \textbf{C}
\item \textbf{C++}
\item \textbf{Fortran}
\item \textbf{Java}
\item \textbf{Objective-C}
\item \textbf{Objective-C++}
\end{itemize}
\subsubsection{Arquitecturas}
\begin{itemize}
\item \textbf{Alpha}
\item \textbf{ARM}
\item \textbf{Atmel AVR}
\item \textbf{Blackfin}
\item \textbf{H8/300}
\item \textbf{System/370, System/390}
\item \textbf{IA-32 (x86) and x86-64}
\item \textbf{IA-64 i.e. the "Itanium"}
\item \textbf{Motorola 68000}
\item \textbf{Motorola 88000}
\item \textbf{MIPS}
\item \textbf{PA-RISC}
\item \textbf{PDP-11}
\item \textbf{PowerPC}
\item \textbf{SuperH}
\item \textbf{SPARC}
\item \textbf{VAX}
\item \textbf{Renesas R8C/M16C/M32C}
\item \textbf{MorphoSys}
\end{itemize}
Como puede verse GCC soporta una gran cantidad de lenguajes de programaci<63>n, sin embargo, en el presente estudio solo lo utilizaremos como herramienta de compilaci<63>n para C y C++. Una caracter<65>stica de resaltar de GCC es la gran cantidad de plataformas que soporta, esto lo hace una herramienta Universal para el desarrollo de sistemas embebidos, el c<>digo escrito en una plataforma (en un lenguaje de alto nivel) puede ser implementado en otra sin mayores cambios, esto elimina la dependencia entre el c<>digo fuente y el HW\footnote{Esto recibe el nombre de re-utilizaci<63>n de c<>digo}, lo cual no ocurre al utilizar lenguaje ensamblador.
Por otro lado, el tiempo requerido para realizar aplicaciones utilizando C o C++ disminuye, ya que no es necesario aprender las instrucciones en assembler de una plataforma determinada; adem<65>s, la disponibilidad de librer<65>as de m<>ltiples prop<6F>sitos reduce a<>n m<>s los tiempos de desarrollo, permitiendo de esta forma tener bajos tiempos \textit{time to market} y reducir de forma considerable el costo del desarrollo. Una consecuencia de esto se refleja en el n<>mero de desarrolladores en un grupo de trabajo, en la actualidad casi el 60\% de las empresas desarrolladoras de dispositivos embebidos tiene grupos con menos de 10 desarrolladores \ref{group}.
\begin{figure}
\begin{center} \includegraphics[scale=.2]{./images/vdc_embedded_dev_company_size} \end{center}
\caption{N<>mero promedio de desarrolladores por compa<70><61>a. Fuente Venture Development Corp}\label{group}
\end{figure}
\subsubsection{GNU Debugger}
El depurador oficial de GNU (GDB), es un depurador que al igual que GCC tiene soporte para m<>ltiples lenguajes y plataformas. GDB permite al usuario monitorear y modificar las variables internas del programa y hacer llamado a funciones de forma independiente a la ejecuci<63>n normal del mismo. Adem<65>s, permite establecer sesiones remotas utilizando el puerto serie o TCP/IP. Aunque GDB no posee una interfaz gr<67>fica, se han desarrollado varios front-ends como DDD o GDB/Insight. A continuaci<63>n se muestra un ejemplo de una sesi<73>n con gdb.
\footnotesize
\begin{lstlisting}[firstnumber=40]
GNU gdb Red Hat Linux (6.3.0.0-1.21rh)
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "i386-redhat-linux-gnu"...Using host libthread_db
library "/lib/libthread_db.so.1".
(gdb) run
Starting program: /home/sam/programming/crash
Reading symbols from shared object read from target memory...done.
Loaded system supplied DSO at 0xc11000
This program will demonstrate gdb
Program received signal SIGSEGV, Segmentation fault.
0x08048428 in function_2 (x=24) at crash.c:22
22 return *y;
(gdb) edit
(gdb) shell gcc crash.c -o crash -gstabs+
(gdb) run
The program being debugged has been started already.
Start it from the beginning? (y or n) y
warning: cannot close "shared object read from target memory": File in wrong format
`/home/sam/programming/crash' has changed; re-reading symbols.
Starting program: /home/sam/programming/crash
Reading symbols from shared object read from target memory...done.
Loaded system supplied DSO at 0xa3e000
This program will demonstrate gdb
24
Program exited normally.
(gdb) quit
\end{lstlisting}
\subsubsection{C Libraries}
Adicionalmente es necesario contar con una librer<65>a que proporcione las librer<65>as standard de C: stdio, stdlib, math; las m<>s utilizadas en sistemas embebidos son:
\begin{itemize}
\item \textbf{glibc\footnote{http://www.gnu.org/software/libc/}} Es la librer<65>a C oficial del proyecto GNU. Uno de los inconvenientes al trabajar con esta librer<65>a en sistemas embebidos es que genera ejecutables de mayor tama<6D>o que los generados a partir de otras librer<65>as, lo cual no la hace muy atractiva para este tipo de aplicaciones.
\item \textbf{uClibc\footnote{http://uclibc.org/}} Es una librer<65>a dise<73>ada especialmente para sistemas embebidos, es mucho m<>s peque<75>a que \textbf{glibc}.
\item \textbf{newlib\footnote{http://sources.redhat.com/newlib/}} Al igual que \textbf{uClibc}, est<73> dise<73>ada para sistemas embebidos. El t<>pico ``Hello, world!'' ocupa menos de 30k en un entorno basado en newlib, mientras que en uno basado en glibc, puede ocupar 380k \cite{BG}.
\item \textbf{diet libc\footnote{http://www.fefe.de/dietlibc/}} Es una versi<73>n de \textit{libc} optimizada en tama<6D>o, puede ser utilizada para crear ejecutables est<73>ticamente enlazados para linux en plataformas alpha, arm, hppa, ia64, i386, mips, s390, sparc, sparc64, ppc y x86\_64.
\end{itemize}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% SECCION Obtenci<63>n y utilizaci<63>n del GNU toolchain
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\section{Desarrollo Software}
El primer paso en nuestro estudio consiste en tener una cadena de herramientas funcional que soporte la familia de procesadores a utilizar. La arquitectura sobre la cual realizaremos nuestro estudio inicial es la ARM (Advanced Risc Machines), ya que la m<>s utilizada en la actualidad por los dise<73>adores de sistemas embebidos (ver figura \ref{arch}) y se encuentran disponibles una gran variedad de herramientas para esta arquitectura. Sin embargo, lo contenido en esta secci<63>n es aplicable a cualquier familia de procesadores soportada por la cadena de herrmientas GNU. Existen dos formas de obtener la cadena de herramientas GNU:
\begin{figure}
\begin{center} \includegraphics[scale=.8]{./images/embedded-processor-trends-sm} \end{center}
\caption{Tendencia del mercado de procesadores para sistemas embebidos. Fuente:\cite{Lin05} }\label{arch}
\end{figure}
\begin{enumerate}
\item Utilizar una distribuci<63>n precompilada: Esta es la via m<>s r<>pida, sin embargo, hay que tener cuidado al momento de instalarlas, ya que debe hacerse en un directorio con el mismo \textit{path} con el que fueron creadas. por ejemplo \textit{/usr/local/gnutools}; si esto no se cumple, las herramientas no funcionar<61>n de forma adecuada.
\item Utilizar un script de compilaci<63>n: Existen disponibles en la red una serie de \textit{scripts} que permiten descargar, configurar, compilar e instalar la cadena de herramientas, la ventaja de utilizar este m<>todo es que es posible elegir las versiones de las herramientas instaladas, al igual que el directorio de instalaci<63>n. En este estudio utilizaremos los \textit{scripts} creados por Dan Kegel \cite{DK06}.
\end{enumerate}
\subsection{Flujo de dise<73>o software}
En la figura \ref{toolchain_flow} se ilustra la secuencia de pasos que se realizan desde la creaci<63>n de un archivo de texto que posee el c<>digo fuente que implementa la funcionalidad de una tarea software utilizando un lenguaje de alto nivel como C o C++, hasta su programaci<63>n en una memoria permanente en la plataforma f<>sica. Los pasos necesarios para crear un archivo que pueda ser programado en dicha memoria son:
\begin{figure}
\begin{center} \includegraphics[scale=.6]{./images/SW_design_flow} \end{center}
\caption{Tendencia del mercado de procesadores para sistemas embebidos. Fuente:\cite{Lin05} }\label{toolchain_flow}
\end{figure}
\begin{enumerate}
\item \textbf{Escritura del c<>digo fuente:} Creaci<63>n del c<>digo fuente en cualquier editor de texto utilizando un lenguaje de alto nivel como C o C++.
\item \textbf{Compilaci<63>n:} Utilizando un compilador (GCC en nuestro caso) se crea un \textit{objeto} que contiene las instrucciones en \textit{lenguaje de m<>quina} del procesador a utilizar (uno diferente al que realiza la compilaci<63>n que normalmente es de la familia x86); en este punto el compilador solo busca en los encabezados (\textit{headers}) la definici<63>n de una determinada funci<63>n, esto es, la forma en que debe ser utilizada, el tipo de datos y el n<>mero de par<61>metros con que debe ser invocada, por ejemplo, la funci<63>n \textit{printf} esta declarada en el archivo \textit{stdio.h} como: \textit{ int printf (const char *template, ...)}. Esta declaraci<63>n es utilizada por el compilador para verificar el correcto uso de esta funci<63>n.
\item \textbf{Enlazado:} En esta etapa se realizan dos tareas:
\begin{enumerate}
\item Se enlazan los archivos tipo objeto del proyecto, junto con librer<65>as precompiladas para el procesador de la plataforma, si una determinada funci<63>n no es definida en ninguna de estas librer<65>as, el \textit{enlazador} generar<61> un error y no se generar<61> el ejecutable.
\item Se definen las posici<63>nes f<>sicas de las secciones que componen el archivo ejecutable (tipo ELF), esto se realiza a trav<61>s de un link de enlazado en el que se define de forma expl<70>cita su localizaci<63>n.
\end{enumerate}
\item \textbf{Extracci<63>n del archivo de programaci<63>n} En algunas aplicaciones (cuando no se cuenta con un sistema operativo) es necesario extraer las secciones del ejecutable que residen en los medios de almacenamiento no vol<6F>til, que como veremos m<>s adelante representan el conjunto de instrucciones que debe ejecutar el procesador de la plataforma y las constantes del programa. Esto se realiza con la herramiento \textit{objcopy}, la cual, nos permite generar archivos en la mayor<6F>a de los formatos soportados por los programadores de memorias y procesadores, como S19 e Intel Hex.
\item \textbf{Descarga del programa a la plataforma}. Dependiendo de la plataforma existen varios m<>todos para descargar el archivo de programaci<63>n a la memoria de la plataforma:
\begin{enumerate}
\item Utilizando un \textit{loader}: El \textit{loader} es una aplicaci<63>n que reside en un medio de almacenamiento no vol<6F>til y permite la descarga de archivos utilizando el puerto serie, USB, o una interfaz de red.
\item Utilizando el puerto JTAG: El puerto JTAG (Joint Test Action Group) proporciona una interfaz capaz de controlar los registros internos del procesador, y de esta forma, acceder a las memorias de la plataforma y ejecutar un programa residente en una determinada posici<63>n de memoria.
\end{enumerate}
\item \textbf{Depuraci<63>n} Una vez se descarga la aplicaci<63>n a la plataforma es necesario someterla a una serie de pruebas con el f<>n de probar su correcto funcionamiento. Esto se puede realizar con el depurador GNU (GDB) y una interfaz de comunicaci<63>n que puede ser un puerto serie, USB o un adaptador de red.
\end{enumerate}
\subsection{El formato \textbf{ELF}}
El formato ELF (\textit{Executable and Linkable Format}) Es un st<73>ndard para objetos, librer<65>as y ejecutables y es el formato que genera las herramientas GNU. Como puede verse en la figura \ref{elf1} est<73> compuesto por varias secciones (\textit{link view}) o segmentos (\textit{execution view}). Si un programador est<73> interesado en obtener informaci<63>n de secciones sobre tablas de s<>mbolos, c<>digo ejecutable espec<65>fico o informaci<63>n de enlazado din<69>mico debe utilizar \textit{link view}. Pero si busca informaci<63>n sobre segmentos, como por ejemplo, la localizaci<63>n de los segmentos \textit{text} o \textit{data} debe utilizar \textit{execution view}. El encabezado describe el layout del archivo, proporcionando informaci<63>n de la forma de acceder a las secciones \cite{MLH98}.
\begin{figure}
\begin{center} \includegraphics[scale=.4]{./images/ELF_Link_exec1} \end{center}
\caption{Formato ELF}\label{elf1}
\end{figure}
Las secciones pueden almacenar c<>digo ejecutable, datos, informaci<63>n de enlazado din<69>mico, datos de depuraci<63>n, tablas de s<>mbolos,comentarios, tablas de strings, y notas. Las secciones m<>s importantes son las siguientes:
\begin{itemize}
\item \textbf{.bss} Datos no inicializados. (RAM)
\item \textbf{.comment} Informaci<63>n de la versi<73>n.
\item \textbf{.data y .data1} Datos inicializados. (RAM)
\item \textbf{.debug} Informaci<63>n para depuraci<63>n simb<6D>lica.
\item \textbf{.dynamic} Informaci<63>n sobre enlace din<69>mico
\item \textbf{.dynstr} Strings necesarios para el enlacedin<69>mico
\item \textbf{.dynsym} Tabla de s<>mbolos utilizada para enlace din<69>mico.
\item \textbf{.fini} C<>digo de terminaci<63>n de proceso.
\item \textbf{.init} C<>digo de inicializaci<63>n de proceso.
\item \textbf{.line} Informaci<63>n de n<>mero de l<>nea para depuraci<63>n simb<6D>lica.
\item \textbf{.rodata y .rodta1} Datos de solo-lectura (ROM)
\item \textbf{.shstrtab} Nombres de secciones.
\item \textbf{.symtab} Tabla de s<>mbolos.
\item \textbf{.text} Instrucciones ejecutables (ROM)
\end{itemize}
Para aclarar un poco este concepto, escribamos una aplicaci<63>n sencilla:
\begin{lstlisting}
#include <stdio.h>
int global;
int global_1 = 1;
int main(void)
{
int i; // Variable no inicializada
int j = 2; // Variable inicializada
for(i=0; i<10; i++){
printf("Printing %d\n", i*j); // Caracteres constantes
j = j + 1;
global = i;
global_1 = i+j;
}
return 0;
}
\end{lstlisting}
Generemos el objeto compil<69>ndolo con el siguiente comando:
\textit{arm-none-eabi-gcc -c hello.c}
Examinemos que tipo de secciones tiene este ejecutable
\textit{arm-none-eabi-readelf -S hello.o}
\begin{lstlisting}
Section Headers:
[Nr] Name Type Addr Off Size ES Flg Lk Inf Al
[ 0] NULL 00000000 000000 000000 00 0 0 0
[ 1] .text PROGBITS 00000000 000034 00009c 00 AX 0 0 4
[ 2] .rel.text REL 00000000 000484 000020 08 9 1 4
[ 3] .data PROGBITS 00000000 0000d0 000004 00 WA 0 0 4
[ 4] .bss NOBITS 00000000 0000d4 000000 00 WA 0 0 1
[ 5] .rodata PROGBITS 00000000 0000d4 000010 00 A 0 0 4
[ 6] .comment PROGBITS 00000000 0000e4 00004d 00 0 0 1
[ 7] .ARM.attributes ARM_ATTRIBUTES 00000000 000131 00002e 00 0 0 1
[ 8] .shstrtab STRTAB 00000000 00015f 000051 00 0 0 1
[ 9] .symtab SYMTAB 00000000 000368 0000f0 10 10 11 4
[10] .strtab STRTAB 00000000 000458 00002b 00 0 0 1
Key to Flags:
W (write), A (alloc), X (execute), M (merge), S (strings)
I (info), L (link order), G (group), x (unknown)
O (extra OS processing required) o (OS specific), p (processor specific)
\end{lstlisting}
La secci<63>n \textit{.text}, como se dijo anteriormente contiene las instrucciones ejecutables, por esta raz<61>n se marca como ejecutable \textit{``X''} en la columna \textit{Flg}. Es posible ver las instrucciones que se ejecutan en esta secci<63>n:
\textit{arm-none-eabi-objdump -d -j .text hello.o}
\begin{lstlisting}
00000000 <main>:
0: e92d4800 stmdb sp!, {fp, lr}
4: e28db004 add fp, sp, #4 ; 0x4
8: e24dd008 sub sp, sp, #8 ; 0x8
c: e3a03002 mov r3, #2 ; 0x2
10: e50b3008 str r3, [fp, #-8]
14: e3a03000 mov r3, #0 ; 0x0
18: e50b300c str r3, [fp, #-12]
1c: ea000013 b 70 <main+0x70>
20: e51b200c ldr r2, [fp, #-12]
24: e51b3008 ldr r3, [fp, #-8]
28: e0030392 mul r3, r2, r3
2c: e59f005c ldr r0, [pc, #92] ; 90 <.text+0x90>
30: e1a01003 mov r1, r3
34: ebfffffe bl 0 <printf>
38: e51b3008 ldr r3, [fp, #-8]
3c: e2833001 add r3, r3, #1 ; 0x1
40: e50b3008 str r3, [fp, #-8]
44: e59f2048 ldr r2, [pc, #72] ; 94 <.text+0x94>
48: e51b300c ldr r3, [fp, #-12]
4c: e5823000 str r3, [r2]
50: e51b200c ldr r2, [fp, #-12]
54: e51b3008 ldr r3, [fp, #-8]
58: e0822003 add r2, r2, r3
5c: e59f3034 ldr r3, [pc, #52] ; 98 <.text+0x98>
60: e5832000 str r2, [r3]
64: e51b300c ldr r3, [fp, #-12]
68: e2833001 add r3, r3, #1 ; 0x1
6c: e50b300c str r3, [fp, #-12]
70: e51b300c ldr r3, [fp, #-12]
74: e3530009 cmp r3, #9 ; 0x9
78: daffffe8 ble 20 <main+0x20>
7c: e3a03000 mov r3, #0 ; 0x0
80: e1a00003 mov r0, r3
84: e24bd004 sub sp, fp, #4 ; 0x4
88: e8bd4800 ldmia sp!, {fp, lr}
8c: e12fff1e bx lr
\end{lstlisting}
La secci<63>n \textit{.data} mantiene las variables inicializadas, y contiene:
\textit{arm-none-eabi-objdump -d -j .data hello.o}
\begin{lstlisting}
00000000 <global_1>:
0: 01 00 00 00
\end{lstlisting}
Como vemos, la secci<63>n \textit{.data} contiene \'unicamente el valor de inicializaci\'on de la variable \textit{global\_1} (1) y no muestra informaci<63>\'on acerca de la variable \textit{j}, esto se debe a que la informaci\'on est\'a en el \textit{stack} del proceso. Si observamos el contenido de la secci<63>n \textit{.text} observamos que esta variable es asignada en tiempo de ejecuci<63>n, en la l<>nea \textit{0c:} se ve la asignaci<63>n de esta variable.
\begin{lstlisting}
0c: e3a03002 mov r3, #2 ; 0x2
10: e50b3008 str r3, [fp, #-8]
\end{lstlisting}
La secci<63>n \textit{.bss} mantiene la informaci\'on de las variables no incializadas (En Linux todas las variables no inicializadas, se inicializadan en cero):
\textit{arm-none-eabi-objdump -d -j .bss hello}
\begin{lstlisting}
000145c4 <global>:
145c4: 00000000
\end{lstlisting}
La secci<63>n \textit{.rodata} mantiene los datos que no cambian durante la ejecuci<63>n del programa, es decir, de solo lectura, si examinamos esta secci<63>n obtenemos:
\textit{hexdump -C hello.o | grep -i 000000d0} (la secci<63>n \textit{.rodata} comienza en la posici<63>n de memoria 0xd4)
\begin{lstlisting}
000000d0 01 00 00 00 50 72 69 6e 74 69 6e 67 20 25 64 0a |....Printing %d.|
000000e0 00 00 00 00 00 47 43 43 3a 20 28 43 6f 64 65 53 |.....GCC: (CodeS|
\end{lstlisting}
En el contenido de esta secci<63>n aparece la cadena de caracteres \textit{Printing \%d\\n}, es decir, los datos que no cambian durante la ejecuci<63>n.
\subsection{Herramienta de compilaci<63>n make}
Como pudo verse en la secci<63>n es necesario realizar una serie de pasos para poder descargar una aplicaci<63>n a una plataforma embebida. Debido a que las herramientas GNU solo poseen entrada por consola, es necesario esribir una serie de comandos cada vez que se realiza un cambio en el c<>digo fuente, lo cual resulta poco pr<70>ctico. Para realizar este proceso de forma autom<6F>tica se cre<72> la herramienta \textit{make}, la cual recibe como entrada un archivo que normalmente tiene el nombre \textit{Makefile} o \textit{makefile} y determina que archivos han sido modificados desde la <20>ltima compilaci<63>n y ejecuta los comandos necesarios para recompilarlos. Un ejemplo de este tipo de archivo se muestra a continuaci<63>n:
\begin{lstlisting}[numbers=left]
SHELL = /bin/sh
basetoolsdir = /home/at91/gcc-3.4.5-glibc-2.3.6/arm-softfloat-linux-gnu
bindir = ${basetoolsdir}/bin
libdir = ${basetoolsdir}/lib/gcc/arm-softfloat-linux-gnu/3.4.5
CC = arm-softfloat-linux-gnu-gcc
AS = arm-softfloat-linux-gnu-as
LD = arm-softfloat-linux-gnu-ld
OBJCOPY = arm-softfloat-linux-gnu-objcopy
CFLAGS =-mcpu=arm920t -I. -Wall
LDFLAGS =-L${libdir} -l gcc
OBJS = \
main.o \
debug_io.o \
at91rm9200_lowlevel.o \
p_string.o
ASFILES = arm_init.o
LIBS=${libdir}/
all: hello_world
hello_world: ${OBJS} ${ASFILES} ${LIBS}
${LD} -e 0 -o hello_world.elf -T linker.cfg ${ASFILES} ${OBJS} ${LDFLAGS}
${OBJCOPY} -O binary hello_world.elf hello_world.bin
clean:
rm -f *.o *~ hello_world.*
PREPROCESS.c = $(CC) $(CPPFLAGS) $(TARGET_ARCH) -E -Wp,-C,-dD,-dI
%.pp : %.c FORCE
$(PREPROCESS.c) $< > $@
\end{lstlisting}
En las l<>neas 3-5 se definen algunas variables globales que ser<65>n utilizadas a lo largo del archivo; en las l<>neas 7 - 10 se definen las herramientas de compilaci<63>n a utilizar, espec<65>ficamente el compilador C (CC), el ensamblador (AS), el enlazador (LD) y la utilidad objcopy. A partir de la l<>nea 15 se definen los objetos que forman parte del proyecto, en este caso: \textit{main.o, debug\_io.o, at91rm9200\_lowlevel.o y p\_string.o}; en la l<>nea 21 se definen los archivos en assembler que contiene el proyecto, para este ejemplo \textit{arm\_init.o}. Las l<>neas 12 y 13 definen dos variables especiales que se pasan directamente al compilador C (CFLAGS) y al enlazador (LDFLAGS) y definen par<61>metros de comportamiento de estas herramientas.
\begin{lstlisting}
CFLAGS =-mcpu=arm920t -I. -Wall
\end{lstlisting}
El par<61>metro \textit{-mcpu} le indica al compilador C para arquitecturas \textit{ARM} que utilice la familia \textit{arm920}; el par<61>metro \textit{-I} le indica un directorio donde puede buscar los encabezados, en este caso el caracter "." le indica que busque en el mismo sitio donde se encuentran los archivos fuente; el par<61>metro \textit{-Wall} le indica que imprima todos los mensajes de errores y advertencias.
\begin{lstlisting}
LDFLAGS =-L${libdir} -l gcc
\end{lstlisting}
El par<61>metro \textit{-L} le indica al enlazador la ruta del directorio donde se encuentran las librer<65>as, en este ejemplo apunta a la variable textit{libdir} que se encuentra declarado como \textit{\${basetoolsdir}/lib/gcc/arm-softfloat-linux-gnu/3.4.5}; el par<61>metro \textit{-l} le indica al enlazador que debe utilizar la librer<65>a \textit{gcc} que se encuentra en el directorio definido previamente. En realidad el archivo de la librer<65>a tienen el nombre \textit{libgcc.a}, pero como todas las librer<65>as tienen el nombre \textit{libXXXX.a} se eliminan el encabezado y la extensi<73>n del archivo.
En las l<>neas 25, 27 y 31 aparecen unas etiquetas de la forma: \textit{nombre:} estos labels permiten ejecutar de forma independiente el conjunto de instrucciones asociadas a ellas, por ejemplo, si se ejecuta:
\\ \bigskip
\textit{make clean}\\ \bigskip
make ejecutar<61> el comando:\\ \bigskip
\textit{rm -f *.o *~ hello\_world.*}
Observemos los comandos asociados a la etiqueta \textit{hello\_world:} En la misma l<>nea aparecen \textit{\${OBJS} \${ASFILES} \${LIBS}} esto le indica a la herramienta \textit{make} que antes de ejecutar los comandos asociados a este label, debe realizar las acciones necesarias para generar \textit{\${OBJS} \${ASFILES} \${LIBS}} o lo que es lo mismo: \textit{main.o, debug\_io.o, at91rm9200\_lowlevel.o, p\_string.o, arm\_init.o y libgcc.a}. Para esto, \textit{make} tiene predefinidas una serie de reglas para compilar los archivos .c la regla es de la forma:
\begin{lstlisting}
.c.o:
$(CC) $(CFLAGS) -c $<
.c:
$(CC) $(CFLAGS) $@.c $(LDFLAGS) -o $@
\end{lstlisting}
Lo cual le indica a la herramienta make que para generar un archivo \textit{.o} a partir de uno \textit{.c} es necesario ejecutar \textit{\$(CC) \$(CFLAGS) -c \$<}; de aqui la importancia de definir bien la variable de entorno \textit{CC} cuando trabajamos con compiladores cruzados\footnote{Un compilador cruzado genera c<>digo para una plataforma diferente en la que se est<73> ejecutando, por ejemplo, genera ejecutables para ARM pero se ejecuta en un x86}. Hasta este punto al ejecutar el comando: \textit{make hello\_world}, \textit{make} realizar<61>a las siguientes operaciones: \\
\begin{lstlisting}
arm-softfloat-linux-gnu-gcc -mcpu=arm920t -I. -Wall -c -o main.o main.c
arm-softfloat-linux-gnu-gcc -mcpu=arm920t -I. -Wall -c -o debug_io.o debug_io.c
arm-softfloat-linux-gnu-gcc -mcpu=arm920t -I. -Wall -c -o at91rm9200_lowlevel.o at91rm9200_lowlevel.c
arm-softfloat-linux-gnu-gcc -mcpu=arm920t -I. -Wall -c -o p_string.o p_string.c
arm-softfloat-linux-gnu-as -o arm_init.o arm_init.s
\end{lstlisting}
En las l<>neas 28 se realiza el proceso de enlazado; al \textit{enlazador} se le pasan los par<61>metros:
\begin{itemize}
\item \textbf{-e 0}: Punto de entrada , utiliza la direcci<63>n de memoria 0 como punto de entrada.
\item \textbf{-o hello\_world.elf}: Nombre del archivo de salida \textit{hello\_world}
\item \textbf{-T linker.cfg}: Utilice el archivo de enlace \textit{linker.cfg} para definir las posiciones de memoria de las secciones del ejecutable.
\item \textbf{\${ASFILES} \${OBJS} \${LDFLAGS}}: Lista de objetos y librer<65>as para crear el ejecutable.
\end{itemize}
En la l<>nea 29 se utiliza la herramienta \textit{objcopy} para generar un archivo binario (\textit{-O binary}) con la informaci<63>n necesaria para cargar en una memoria no vol<6F>til.
\subsection{Archivo de enlace}
Como vimos anteriormente, el enlazador o \textit{linker} es el encargado de agrupar todos los archivos objeto \textit{.o}, y las librer<65>as necesarias para crear el ejecutable, adicionalmente, permite definir donde ser<65>n ubicados los diferentes segmentos del archivo ELF en un archivo de enlace \textit{linker script}. De esta forma podemos ajustar el ejecutable a plataformas con diferentes configuraciones de memoria, lo que proporciona un grado mayor de flexibilidaad de la cadena de herramientas GNU. Cuando se dispone de un sistema operativo como Linux no es necesario definir este archivo, ya que el sistema operativo se encarga del manejo de las diferentes secciones, sin embargo, es necesario tenerlo presente ya que como veremos m<>s adelante existe un momento en el que el sistema operativo no ha sido cargado en la plataforma y las aplicaciones que se ejecuten deben proporcionar esta informaci<63>n. A continuaci<63>n se muestra un ejemplo de este archivo:
\begin{lstlisting}
/* identify the Entry Point (_vec_reset is defined in file crt.s) */
ENTRY(_vec_reset)
/* specify the memory areas */
MEMORY
{
flash : ORIGIN = 0, LENGTH = 256K /* FLASH EPROM */
ram : ORIGIN = 0x00200000, LENGTH = 64K /* static RAM area */
}
/* define a global symbol _stack_end */
_stack_end = 0x20FFFC;
/* now define the output sections */
SECTIONS
{
. = 0; /* set location counter to address zero */
.text : /* collect all sections that should go into FLASH after startup */
{
*(.text) /* all .text sections (code) */
*(.rodata) /* all .rodata sections (constants, strings, etc.) */
*(.rodata*) /* all .rodata* sections (constants, strings, etc.) */
*(.glue_7) /* all .glue_7 sections (no idea what these are) */
*(.glue_7t) /* all .glue_7t sections (no idea what these are) */
_etext = .; /* define a global symbol _etext just after the last code byte */
} >flash /* put all the above into FLASH */
.data : /* collect all initialized .data sections that go into RAM */
{
_data = .; /* create a global symbol marking the start of the .data section */
*(.data) /* all .data sections */
_edata = .; /* define a global symbol marking the end of the .data section */
} >ram AT >flash /* put all the above into RAM (but load the LMA initializer copy into FLASH) */
.bss : /* collect all uninitialized .bss sections that go into RAM */
{
_bss_start = .; /* define a global symbol marking the start of the .bss section */
*(.bss) /* all .bss sections */
} >ram /* put all the above in RAM (it will be cleared in the startup code */
. = ALIGN(4); /* advance location counter to the next 32-bit boundary */
_bss_end = . ; /* define a global symbol marking the end of the .bss section */
}
_end = .; /* define a global symbol marking the end of application RAM */
\end{lstlisting}
En las primeras l<>neas del archivo aparece la declaraci<63>n de las memorias de la plataforma, en este ejemplo tenemos una memoria RAM de 64kB que comienza en la posici<63>n de memoria 0x00200000 y una memoria flash de 256k que comienza en la posici<63>n 0x0. A continuacion se definen las secciones y el lugar donde ser<65>n almacenadas; En este caso, las secciones \textit{.text} (c<>digo ejecutable) y \textit{.rodata} (datos de solo lectura) se almacenan en una memoria no vol<6F>til la flash. Cuando el sistema sea energizado el procesador ejecutar<61> el c<>digo almacenado en su memoria no vol<6F>til. Las secciones \textit{.data} (variables inicializadas) y \textit{.bss} (variables no inicializadas) se almacenar<61>n en la memoria vol<6F>til RAM, ya que el acceso a las memorias no vol<6F>tiles son m<>s lentas y tienen ciclos de lectura/escritura finitos.
\section{Herramientas hardware}
En esta subsecci<63>n se realizar<61> una breve descripci<63>n de los dispositivos semiconductores m<>s utilizados para la implementaci<63>n de dispositivos digitales, esto, con el f<>n de determinar el estado actual de la industria de los semiconductores y entender los componentes b<>sicos con los que se pueden implementar dispositivos digitlaes modernos.
\subsubsection{SoC}
La Figura \ref{at91rm} muestra la arquitectura de un SoC actual, espec<65>ficamente del AT91RM920 de Atmel. En este diagrama podemos observar el n<>cleo central un procesador ARM920T de 180MHz y los perif<69>ricos asociados a <20>l. En la actualidad podemos encontrar una gran variedad de SoC dise<73>ados para diferentes aplicaciones: Multimedia, Comunicaciones, Asistentes Digitales; los perif<69>ricos incluidos en cada SoC buscan minimizar el n<>mero de componentes externos, y de esta forma reducir los costos. Este SoC en particular fu<66> uno de los primeros que dise<73>o ATMEL y est<73> enfocado a tareas en las que se requiere una conexi<78>n de red. La arquitectura de estos SoC evoluciona muy r<>pido acomod<6F>ndose a los requerimientos de nuevas aplicaciones, b<>sicamente, los cambios se producen en la velocidad del procesador central y la adici<63>n de perif<69>ricos que permiten el control directo de nuevos perif<69>ricos, como por ejemplo, la adici<63>n de controladores de pantallas de cristal l<>quido o salidas de video. Dentro de estos perif<69>ricos encontramos:
\begin{itemize}
\item Controlador para memorias: NAND flash, DataFlash, SDRAM, SD/MMC
\item Puerto USB 2.0 host.
\item Puerto I2C
\item Interfaz Ethernet 10/100.
\item Interfaz high speed USB 2.0
\item Puertos SPI.
\item Puertos seriales (RS232).
\item Soporte JTAG.
\item Interf<72>z de Bus externo (EBI).
\item Controlador de LCD.
\item
\end{itemize}
\begin{figure}
\begin{center} \includegraphics[scale=.7]{./images/at91rm9200} \end{center}
\caption{SoC AT91RM9200 fuente: Hoja de Especificaciones AT91RM9200, ATMEL} \label{at91rm}
\end{figure}
Existen una serie de perif<69>ricos que son indispensables en todo Sistema Embebido, los cuales facilitan la programaci<63>n de aplicaciones y la depuraci<63>n de las mismas. A continuaci<63>n se realizar<61> una descripci<63>n de los diferentes perif<69>ricos que se encuentran disponibles en este SoC, indicando los que fueron utilizados en la plataforma de desarrollo.
\subsubsection{Memorias Vol<6F>tiles}
Como se estudi<64> anteriormente existen secciones del ejecutable que deben ser almacenadas en memorias vol<6F>tiles o en memorias no vol<6F>tiles. Debido a esto la mayor<6F>a de los SoC incluyen perif<69>ricos dedicados a controlar diferentes tipos de memoria, las memorias vol<6F>tiles son utilizadas como memoria de acceso aleatorio (RAM) gracias a su bajo tiempo de accesso y al ilimitado n<>mero de ciclos de lectura/escritura.
El tipo de memoria m<>s utilizado en los sistemas embebidos actuales es la memoria SDRAM; la cual est<73> organizada como una matriz de celdas, con un n<>mero de bits dedicados al direccionamiento de las filas y un n<>mero dedicado a direccionar columnas (ver Figura \ref{sdram_basics}).
\begin{figure}
\begin{center} \includegraphics[scale=.6]{./images/sdram_basics} \end{center}
\caption{Diagrama de Bloques de una memoria SDRAM fuente: Hoja de Especificaciones MT48LC16M16, Micron Technology} \label{sdram_basics}
\end{figure}
Un ejemplo simplificado de una operaci<63>n de lectura es el siguiente: Una posici<63>n de memoria se determina colocando la direcci<63>n de la fila y la de la columna en las l<>neas de direcci<63>n de fila y columna respectivamente, un tiempo despu<70>s el dato almacenado aparecer<65> en el bus de datos. El procesador coloca la direcci<63>n de la fila en el bus de direcciones y despu<70>s activa la se<73>al \textit{RAS} (Row Access Strobe). Despu<70>s de un retardo de tiempo predeterminado para permitir que el circuito de la SDRAM capture la direcci<63>n de la fila, el procesador coloca la direcci<63>n de la columna en el bus de direcciones y activa la se<73>al \textit{CAS} (Column Access Strobe). Una celda de memoria SDRAM esta compuesta por un transistor y un condensador; el transistor suministra la carga y el condensador almacena el estado de cada celda, esta carga en el condensador desaparece con el tiempo, raz<61>n por la cual es necesario recargar estos condensadores peri<72>dicamente, este proceso recibe el nombre de \textit{Refresco}. Un ciclo de refresco es un ciclo especial en el que no se escribe ni se lee informaci<63>n, solo se recargan los condensadores para mantener la informaci<63>n. El perif<69>rico que controla la SDRAM est<73> encargado de garantizar los ciclos de refresco de acuerdo con los requerimientos de la SDRAM \cite{CH06}.
\subsubsection{Memorias No Vol<6F>tiles}
La memorias no vol<6F>tiles almacenan por largos per<65>odos de tiempo informaci<63>n necesaria para la operaci<63>n de un Sistema Embebido, pueden ser vistos como discos duros de estado s<>lido; existen dos tipos de memoria las memorias NOR y las NAND; las dos poseen la capacidad de ser escritas y borradas utilizando control de software, con lo que no es necesario utilizar programadores externos y puedens er modificadas una vez instaladas en el circuito integrado. Una desventaja de estas memorias es que los tiempos de escritura y borrado son muy largos en comparaci<63>n con los requeridos por las memorias RAM.
Las memorias NOR poseen buses de datos y direcci<63>n, con lo que es posible acceder de forma f<>cil a cada byte almacenado en ella. Los bits datos pueden ser cambiados de 0 a 1 utilizando el control de software un byte a la vez, sin embargo, para cambiar un bit de 1 a 0 es necesario borrar una serie de unidades de borrado que reciben el nombre de bloques, lo que permite reducir el tiempo de borrado de la memoria. Debido a que el borrado y escritura de una memoria ROM se puede realizar utilizando el control software (ver Figura \ref{nor_prog}) no es necesario contar con un perif<69>rico especializado para su manejo.
\begin{figure}
\begin{center} \includegraphics[scale=.6]{./images/nor_prog} \end{center}
\caption{Ciclos de escritura y borrado de una memoria flash NOR} \label{nor_prog}
\end{figure}
Las memorias NOR son utilizadas en aplicaciones donde se necesiten altas velocidades de lectura y baja densidad, debido a que los tiempos de escritura y lectura son muy grandes se utilizan como memorias ROM. Las memorias NAND disminuyen los tiempos de escritura y aumentan la capacidad de almacenamiento, ideales para aplicaciones donde se requiera almacenamiento de informaci<63>n. Adicionalmente las memorias NAND consumen menos potencia que las memorias NAND, por esta raz<61>n este tipo de memorias son utilizadas en casi todos los dispositivos de almacenamiento modernos como las memorias SD y las memorias USB, los cuales integran una memoria NAND con un circuito encargado de controlarlas e implementar el protocolo de comunicaci<63>n. A diferencia de las flash tipo NOR, los dispositivos NAND se acceden de forma serial utilizando interfaces complejas; su operaci<63>n se asemeja a un disco duro tradicional. Se accede a la informaci<63>n utilizando bloques (m<>s peque<75>os que los bloques NOR). Los ciclos de escritura de las flash NAND son mayores en un orden de magnitud que los de las memorias NOR.
Un problema al momento de trabajar con las memorias tipo NAND es que requieren el uso de un \textit{manejo de bloques defectuosos}, esto es necesario ya que las celdas de memoria pueden da<64>arse de forma espont<6E>nea durante la operaci<63>n normal. Debido a esto se debe tener un determinado n<>mero de bloques que se encargen de almacenar tablas de mapeo para manejar los bloques defectuosos; o puede hacerse un chequeo en cada inicializaci<63>n del sistema de toda la RAM para actualizar esta lista de sectores defectuosos. El algoritmo de ECC (Error-Correcting Code) debe ser cap<61>z de corregir errores tan peque<75>os como un bit de cada 2048 bits, hasta 22 bits de cada 2048. Este algor<6F>tmo es capaz de detectar bloques defectuosos en la fase de programac<61><63>n comparando la informaci<63>n almacenada con la que debe ser almacenada (verificaci<63>n), si encuentra un error marca el bloque como defectuoso y utiliza un bloque sin defactos para almacenar la informaci<63>n.
La tabla \ref{flash_comp} resume las principales caracter<65>sticas de los diferentes tipos de memoria flash.
\begin{center}
\begin{table}[ht]
\begin{tabular}{|l|c|c|c|}
\hline
& \textbf{SLC NAND} & \textbf{MLC NAND} & MLC NOR \\ \hline
Densidad & 512Mbits - 4GBits & 1Gbits - 16GBits & 16MBits - 1GBit \\ \hline
Velocidad de Lectura & 24MB/s & 18.6MB/s & 103MB/s \\ \hline
Velocidad de escritura& 8 MB/s & 2.4MB/s & 0,47MB/s \\ \hline
Tiempo de borrado & 2ms & 2ms & 900ms \\ \hline
Interfaz & Acceso Indirecto & Acceso Indirecto & Acceso Aleatorio\\ \hline
Aplicaci<63>n & Almacenamiento & Almacenamiento & Solo lectura \\ \hline
\end{tabular}
\caption{Cuadro de comparaci<63>n de las memorias flash NAND y NOR} \label{flash_comp}
\end{table}
\end{center}
Adicionalmente, se encuentran dispoibles las memorias DATAFLASH, estos dispositivos son b<>sicamente una memoria flash tipo NOR con una interfaz SPI, permite una velocidad de lectura de hasta 66MHz utilizando solamente 4 pines para la comunicaci<63>n con el procesador.

512
course/.docs/cambio_categoria/chapter1.tex~ Normal file
View File

@@ -0,0 +1,512 @@
\chapter{Conceptos B<>sicos de los Sistemas Embebidos}
\section{Definici<EFBFBD>n}
Un Sistema Embebidos es un sistema de prop<6F>sito espec<65>fico en el cual, el computador es encapsulado completamente por el dispositivo que el controla. A diferencia de los computadores de prop<6F>sito general, un Sistema Embebido realiza tareas pre-definidas, lo cual permite su optimizaci<63>n, reduciendo el tama<6D>o y costo del producto \cite{Wik}
\section{Caracter<EFBFBD>sticas}
\begin{itemize}
\item Los sistemas embebidos son dise<73>ados para una aplicaci<63>n
espec\'{\i}fica, es decir, estos sistemas realizan un grupo de funciones
previamente definidasm y una vez el sistema es dise<73>ado, no se puede cambiar
su funcionalidad. Por ejemplo, el control de un asensor siempre realizar\'a
las mismas acciones durante su vida \'util.
\item Debido a su interacci<63>n con el entorno los ES deben cumplir
esctr<74>ctamente restricciones temporales. El t\'ermino {\textit{Sistemas
de Tiempo Real}} es utilizado para enfatizar este aspecto.
\item Los Sistemas Embebidos son heterog\'eneos, es decir, est\'an
compuestos por componentes Hardware y Software. Los componentes Hardware,
como ASICs y Dispositivos L\'ogicos Programables (PLD) proporcionan la
velocidad de ejecuci\'on y el cosumo de potencia necesarios en algunas
aplicaciones.
\item Los Sitemas Embebidos tienen grandes requerimientos en t\'erminos de
confiabilidad. Errores en aplicaciones como la aviaci\'on y el
automovilismo, pueden tener consecuencias desastrosas.
\end{itemize}
\section{Arquitectura}
Una arquitectura t<>pica para un Sistema Embebido se muestra en la Figura \ref{es_arch}; La cual integra un componente hardware, implementado ya sea en un PLD (CPLD, FPGA) o en un ASIC, conocido con el nombre de perif<69>ricos y un componente software (procesador o DSP) cap<61>z de ejecutar software, la parte del procesador est<73> dividida en la CPU (En algunos casos posee una cach<63>) y las unidades de Memoria.
\begin{figure}
\begin{center} \includegraphics[scale=.6]{./images/ES_Architecture} \end{center}
\caption{Arquitectura de un Sistema Embebido}\label{es_arch}
\end{figure}
Al momento de dise<73>ar un Sistema Embebido encontramos las siguientes opciones:
\begin{itemize}
\item Componente HW y SW Integrado en un dispositivo semiconductor (SoC): En la actualidad existen muchas compa<70><61>as que fabrican procesadores de 32 bits integrados a una gran variedad de perif<69>ricos, lo cual simplifica el dise<73>o y reduce costos (menos componentes y menos <20>rea de circuito impreso) \footnote{http://www.sharpsma.com, http://www.atmel.com, http://www.cirrus.com, http://www.samsung.com, http://www.freescale.com, etc}.
\item Componente SW en un SoC y componente HW en una FPGA: Cuando no existen en el mercado SoC con la cantidad de perif<69>ricos requerida para una determinada aplicaci<63>n, es necesario recurrir a la utilizaci<63>n de dispositivos comerciales que implementen dicha operaci<63>n, en algunas ocaciones el perif<69>rico puede relizar funciones muy espec<65>ficas de modo que no existe en el mercado, la soluci<63>n es entonces implementar estos dispositivos en una FPGA, tambi<62>n se recomienda la utilizaci<63>n de FPGAs en sistemas que requieren una gran cantidad y variedad de perif<69>ricos ya que reduce la complejidad y costo del sistema.
\item Componente SW y HW en una FPGA: Esta es tal vez la opci<63>n m<>s econ<6F>mica y flexible, pero la de menor desempe<70>o, ya que al utilizar los recursos l<>gicos de la FPGA para la implementaci<63>n del procesador (softcore) la lngitud de los caminos de interconexi<78>n entre los bloques l<>gicos aumentan el retardo de las se<73>ales . Los procesadores \textit{softcore} m<>s populares en la actualidad son:
\begin{itemize}
\item Microblaze de Xilinx\footnote{http://www.xilinx.com}
\item Leon de Gaisler Research \footnote{http://www.gaisler.com/}
\item LatticeMico32 de Lattice Semiconductors\footnote{http://www.latticesemi.com}
\item OpenRisc \footnote{http://www.opencores.com}
\end{itemize}
\end{itemize}
\section{Metodolog<EFBFBD>a de Dise<73>o}
La Figura \ref{des_flow}, muestra un diagrama de flujo de dise<73>o gen<65>rico para sistemas
embebidos {\cite{Cor05}}
\begin{figure}
\begin{center} \includegraphics[scale=.55]{./images/design_flow} \end{center}
\caption{Flujo de Dise<73>o de un Sistema Embebido}\label{des_flow}
\end{figure}
El proceso comienza con la {\textit{especificaci\'on del sistema}}, en este
punto se describe la funcionalidad y se definen las restricciones
f\'{\i}sicas, el\'ectricas y econ\'omicas. Esta especificaci\'on debe ser muy
general y no deben existir dependencias (tecnol\'ogicas, metodol\'ogicas) de
ning\'un tipo, se suele utilizar lenguajes de alto nivel, como UML, C++. La
especificaci\'on puede ser verificada a trav\'es de una serie de pasos de
an\'alisis cuyo objetivo es determinar la validez de los algor\'{\i}tmos
seleccionados, por ejemplo, determinar si el algoritmo siempre termina, los
resultados satisfacen las especificaciones. Desde el punto de vista de la
re-utilizaci\'on, algunas partes del funcionamiento global deben tomarse de
una librer\'{\i}a de algor\'{\i}tmos existentes.
Una vez definidas las especificaciones del sistema se debe realizar un
modelamiento que permita extraer de estas la funcionalidad. El modelamiento es
crucial en el dise<73>o ya que de \'el depende el paso existoso de la
especificaci\'on a la implementaci\'on. Es importante definir que modelo
matem\'atico debe soportar el entorno de dise<73>o. Los modelos m\'as utilizados
son: M\'aquinas de estados finitos, diagramas de flujos de datos, Sistemad de
Eventos Discretos y Redes de Petri. Cada modelo posee propiedades
matem\'aticas que pueden explotarse de forma eficiente para responder
preguntas sobre la funcionalidad del sistema sin llevar a cabo dispendiosas
tareas de verificaci\'on. \ Todo modelo obtenido debe ser verificado para
comprobar que cumple con las restricciones del sistema.
Una vez se ha obtenido el modelo del sistema se procede a determinar su
{\textit{arquitectura}}, esto es, el n\'umero y tipo de componentes y su
inter-conexi\'on. Este paso no es m\'as que una exploraci\'on del espacio de
dise<EFBFBD>o en b\'usqueda de soluciones que permitan la implementaci\'on de una
funcionalidad dada, y puede realizarse con varios criterios en mente: Costos,
confiabilidad, viabilidad comercial.
Utilizando como base la arquitectura obtenida en el paso anterior las tareas
del modelo del sistemas son mapeadas dentro de los componentes. Esto es,
asignaci\'on de funciones a los componentes de la arquitectura. Existen dos
opciones a la hora de implementar las tareas o procesos:
\begin{enumerate}
\item Implementaci\'on Software: La tarea se va a ejecutar en un procesador.
\item Implementaci\'on Hardware: La tarea se va a ejecutar en un sistema
digital dedicado.
\end{enumerate}
Para cumplir las especificaciones del sistema algunas tareas deben ser
implementadas en Hardware, esto con el f\'{\i}n de no ocupar al procesador en
tareas c\'{\i}clicas, un ejemplo t\'{\i}pico de estas tareas es la
generaci\'on de bases de tiempos. La decisi\'on de que tareas se implementan
en SW y que tareas se implementan en HW recibe el nombre de
{\textit{particionamiento}}, esta selecci\'on es fuertemente dependiente de
restricciones econ\'omicas y temporales.
Las tareas Software deben compartir los recursos que existan en el sistema
(procesador y memoria), por lo tanto se deben hacer decisiones sobre el orden
de ejecuci\'on y la prioridad de estas. Este proceso recibe el nombre de
{\textit{planificaci\'on}}. En este punto del dise<73>o el modelo debe incluir
informaci\'on sobre el mapeo, el particionamiento y la planificaci\'on del
sistema.
Las siguientes fases corresponden a la implementaci\'on del modelo, para esto
las tareas hardware deben ser llevadas al dispositivo elegido (ASIC o FPGA) y
se debe obtener el $''$ejecutable$''$ de las tareas software, este proceso
recibe el nombre de {\textit{s\'{\i}ntesis}} HW y SW respectivamente, as\'{\i}
mismo se deben sintetizar los mecanismos de comunicaci\'on.
El proceso de prototipado consiste en la realizaci\'on f\'{\i}sica del
sistema, finalmente el sistema f\'{\i}sico debe someterse a pruebas para
verificar que se cumplen con las especificaciones iniciales.
Como puede verse en el flujo de dise<73>o existen realimentaciones, estas
realimentaciones permiten depurar el resultado de pasos anteriores en el caso
de no cumplirse las especificaciones iniciales
\subsection{Herramientas Software de libre distribuci<63>n \textit{GNU toolchain}}
En el mercado existe una gran variedad de herramientas de desarrollo para Sistemas Embebidos,
sin embargo, en este estudio nos centraremos en el uso de las herramientas de libre distribuci<63>n;
esta elecci<63>n se debe a que la mayor<6F>a de los productos comerciales utilizan el toolchain de GNU\footnote{http://www.gnu.org} internamente y proporcionan un entorno gr<67>fico para su f<>cil manejo. Otro factor considerado a la hora de realizar nuestra elecci<63>n es el econ<6F>mico, ya que la mayor<6F>a de los productos comerciales son costosos y poseen soporte limitado. Por otro lado, el toolchain de GNU es utilizado ampliamente en el medio de los dise<73>adores de sistemas embebidos y se encuentra un gran soporte en m<>ltiples foros de discusi<73>n (ver Figura \ref{tools}).
\begin{figure}[h]
\begin{center} \includegraphics[scale=.7]{./images/embedded-linux-tool-trends-sm} \end{center}
\caption{Tendencia de utilizaci<63>n de herramientas de desarrollo}\label{tools}
\end{figure}
\subsection{Componentes del \textit{GNU toolchain} }
\subsection{GNU binutils\cite{A1}}
Son una colecci<63>n de utilidades para archivos binarios y estan compuestas por:
\begin{itemize}
\item \textbf{addr2line} Convierte direcciones de un programa en nombres de archivos y n<>meros de l<>nea. Dada una direcci<63>n y un ejecutable, usa la informaci<63>n de depuraci<63>n en el ejecutabe para determinar que nombre de atchivo y n<>mero de lpinea est<73> asociado con la direcci<63>n dada.
\item \textbf{ar} Esta utilidad crea, modifica y extrae desde ficheros. Un fichero es una colecci<63>n de otros archivos en una estructura que hace posible obtener los archivos individuales miembros del archivo.
\item \textbf{as} Utilidad que compila la salida del compilador de C (GCC).
\item \textbf{c++filt} Este program realiza un mapeo inverso: Decodifica nombres de bajo-nivel en nombres a nivel de usuario, de tal forma que el linker pueda mantener estas funciones sobrecargadas (overloaded) ``from clashing''.
\item \textbf{gasp} GNU Assembler Macro Preprocessor
\item \textbf{ld} El \textit{linker} GNU combina un n<>mero de objetos y ficheros, re-localiza sus datos y los relaciona con referencias. Normalmente el <20>ltimo paso en la construcci<63>n de un nuevo programa compilado es el llamado a ld.
\item \textbf{nm} Realiza un listado de s<>mbolos de archivos tipo objeto.
\item \textbf{objcopy} Copia los contenidos de un archivo tipo objeto a otro. \textit{objcopy} utiliza la librer<65>a GNU BFD para leer y escribir el archivo tipo objeto. Permite esccribibr el archivo destino en un formato diferente al del archivo fuente.
\item \textbf{objdump} Despliega informaci<63>n sobre archivos tipo objeto.
\item \textbf{ranlib} Genera un <20>ndice de contenidos de un fichero, y lo almacena en <20>l.
\item \textbf{readelf} Interpreta encabezados de un archivo ELF.
\item \textbf{size} Lista el tama<6D>o de las secciones y el tama<6D>o total de un archivo tipo objeto.
\item \textbf{strings} Imprime las secuencias de caracteres imprimibles de almenos 4 caracteres de longitud.
\item \textbf{strip} Elimina todos los s<>mbolos de un archivo tipo objeto.
\end{itemize}
\subsection{GNU Compiler Collection\cite{Wik}}
El \textit{GNU Compiler Collection} normalmente llamado GCC, es un grupo de compiladores de lenguajes de programaci<63>n producido por el proyecto GNU. Es el compilador standard para el software libre de los sistemas operativos basados en Unix y algunos propietarios como Mac OS de Apple.
\subsubsection{Lenguajes}
GCC soporta los siguientes lenguajes:
\begin{itemize}
\item \textbf{ADA}
\item \textbf{C}
\item \textbf{C++}
\item \textbf{Fortran}
\item \textbf{Java}
\item \textbf{Objective-C}
\item \textbf{Objective-C++}
\end{itemize}
\subsubsection{Arquitecturas}
\begin{itemize}
\item \textbf{Alpha}
\item \textbf{ARM}
\item \textbf{Atmel AVR}
\item \textbf{Blackfin}
\item \textbf{H8/300}
\item \textbf{System/370, System/390}
\item \textbf{IA-32 (x86) and x86-64}
\item \textbf{IA-64 i.e. the "Itanium"}
\item \textbf{Motorola 68000}
\item \textbf{Motorola 88000}
\item \textbf{MIPS}
\item \textbf{PA-RISC}
\item \textbf{PDP-11}
\item \textbf{PowerPC}
\item \textbf{SuperH}
\item \textbf{SPARC}
\item \textbf{VAX}
\item \textbf{Renesas R8C/M16C/M32C}
\item \textbf{MorphoSys}
\end{itemize}
Como puede verse GCC soporta una gran cantidad de lenguajes de programaci<63>n, sin embargo, en el presente estudio solo lo utilizaremos como herramienta de compilaci<63>n para C y C++. Una caracter<65>stica de resaltar de GCC es la gran cantidad de plataformas que soporta, esto lo hace una herramienta Universal para el desarrollo de sistemas embebidos, el c<>digo escrito en una plataforma (en un lenguaje de alto nivel) puede ser implementado en otra sin mayores cambios, esto elimina la dependencia entre el c<>digo fuente y el HW\footnote{Esto recibe el nombre de re-utilizaci<63>n de c<>digo}, lo cual no ocurre al utilizar lenguaje ensamblador.
Por otro lado, el tiempo requerido para realizar aplicaciones utilizando C o C++ disminuye, ya que no es necesario aprender las instrucciones en assembler de una plataforma determinada; adem<65>s, la disponibilidad de librer<65>as de m<>ltiples prop<6F>sitos reduce a<>n m<>s los tiempos de desarrollo, permitiendo de esta forma tener bajos tiempos \textit{time to market} y reducir de forma considerable el costo del desarrollo. Una consecuencia de esto se refleja en el n<>mero de desarrolladores en un grupo de trabajo, en la actualidad casi el 60\% de las empresas desarrolladoras de dispositivos embebidos tiene grupos con menos de 10 desarrolladores \ref{group}.
\begin{figure}[h]
\begin{center} \includegraphics[scale=.2]{./images/vdc_embedded_dev_company_size} \end{center}
\caption{N<EFBFBD>mero promedio de desarrolladores por compa<70><61>a. Fuente Venture Development Corp}\label{group}
\end{figure}
\subsection{GNU Debugger\cite{Wik}}
El depurador oficial de GNU (GDB), es un depurador que al igual que GCC tiene soporte para m<>ltiples lenguajes y plataformas. GDB permite al usuario monitorear y modificar las variables internas del programa y hacer llamado a funciones de forma independiente a la ejecuci<63>n normal del mismo. Adem<65>s, permite establecer sesiones remotas utilizando el puerto serie o TCP/IP. Aunque GDB no posee una interfaz gr<67>fica, se han desarrollado varios front-ends como DDD o GDB/Insight. A continuaci<63>n se muestra un ejemplo de una sesi<73>n con gdb.
\footnotesize
\begin{lstlisting}[firstnumber=40]
GNU gdb Red Hat Linux (6.3.0.0-1.21rh)
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "i386-redhat-linux-gnu"...Using host libthread_db
library "/lib/libthread_db.so.1".
(gdb) run
Starting program: /home/sam/programming/crash
Reading symbols from shared object read from target memory...done.
Loaded system supplied DSO at 0xc11000
This program will demonstrate gdb
Program received signal SIGSEGV, Segmentation fault.
0x08048428 in function_2 (x=24) at crash.c:22
22 return *y;
(gdb) edit
(gdb) shell gcc crash.c -o crash -gstabs+
(gdb) run
The program being debugged has been started already.
Start it from the beginning? (y or n) y
warning: cannot close "shared object read from target memory": File in wrong format
`/home/sam/programming/crash' has changed; re-reading symbols.
Starting program: /home/sam/programming/crash
Reading symbols from shared object read from target memory...done.
Loaded system supplied DSO at 0xa3e000
This program will demonstrate gdb
24
Program exited normally.
(gdb) quit
\end{lstlisting}
\subsection{C Libraries}
Adicionalmente es necesario contar con una librer<65>a que proporcione las librer<65>as standard de C: stdio, stdlib, math; las m<>s utilizadas en sistemas embebidos son:
\begin{itemize}
\item \textbf{glibc\footnote{http://www.gnu.org/software/libc/}} Es la librer<65>a C oficial del proyecto GNU. Uno de los inconvenientes al trabajar con esta librer<65>a en sistemas embebidos es que genera ejecutables de mayor tama<6D>o que los generados a partir de otras librer<65>as, lo cual no la hace muy atractiva para este tipo de aplicaciones.
\item \textbf{uClibc\footnote{http://uclibc.org/}} Es una librer<65>a dise<73>ada especialmente para sistemas embebidos, es mucho m<>s peque<75>a que \textbf{glibc}.
\item \textbf{newlib\footnote{http://sources.redhat.com/newlib/}} Al igual que \textbf{uClibc}, est<73> dise<73>ada para sistemas embebidos. El t<>pico ``Hello, world!'' ocupa menos de 30k en un entorno basado en newlib, mientras que en uno basado en glibc, puede ocupar 380k \cite{BG}.
\item \textbf{diet libc\footnote{http://www.fefe.de/dietlibc/}} Es una versi<73>n de \textit{libc} optimizada en tama<6D>o, puede ser utilizada para crear ejecutables est<73>ticamente enlazados para linux en plataformas alpha, arm, hppa, ia64, i386, mips, s390, sparc, sparc64, ppc y x86\_64.
\end{itemize}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% SECCION Obtenci<63>n y utilizaci<63>n del GNU toolchain
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\section{Obtenci<EFBFBD>n y utilizaci<63>n del \textit{GNU toolchain}}
El primer paso en nuestro estudio consiste en tener una cadena de herramientas funcional que soporte la familia de procesadores a utilizar. La arquitectura sobre la cual realizaremos nuestra investigaci<63>n es la ARM (Advanced Risc Machines), ya que un la m<>s utilizada en la actualidad por los dise<73>adores de sistemas embebidos (ver figura \ref{arch}) y se encuentran disponibles una gran variedad de herramientas para esta arquitectura. Existen dos formas de obtener la cadena de herramientas GNU:
\begin{figure}[h]
\begin{center} \includegraphics[scale=.8]{./images/embedded-processor-trends-sm} \end{center}
\caption{Tendencia del mercado de procesadores para sistemas embebidos. Fuente:\cite{Lin05} }\label{arch}
\end{figure}
\begin{enumerate}
\item Utilizar una distribuci<63>n precompilada: Esta es la via m<>s r<>pida, sin embargo, hay que tener cuidado al momento de instalarlas, ya que debe hacerse en un directorio con el mismo \textit{path} con el que fueron creadas. por ejemplo \textit{/usr/local/gnutools}; si esto no se cumple, las herramientas no funcionar<61>n de forma adecuada.
\item Utilizar un script de compilaci<63>n: Existen disponibles en la red una serie de \textit{scripts} que permiten descargar, configurar, compilar e instalar la cadena de herramientas, la ventaja de utilizar este m<>todo es que es posible elegir las versiones de las herramientas instaladas, al igual que el directorio de instalaci<63>n. En este estudio utilizaremos los \textit{scripts} creados por Dan Kegel \cite{DK06}.
\end{enumerate}
\subsection{Conceptos Previos}
Antes de hablar sobre el uso de las herramientas GNU hablaremos sobre varios conceptos que deben quedar claros; estos son: El flujo de dise<73>o software, y el formato ELF.
\subsubsection{El formato \textbf{ELF}}
El formato ELF (\textit{Executable and Linkable Format}) Es un st<73>ndard para objetos, librer<65>as y ejecutables. Como puede verse en la figura \ref{elf1} el formato ELF est<73> compuesto por varias secciones (\textit{link view}) o segmentos (\textit{execution view}). Si un programador est<73> interesado en obtener informaci<63>n de secciones sobre tablas de s<>mbolos, c<>digo ejecutable espec<65>fico o informaci<63>n de enlazado din<69>mico debe utilizar \textit{link view}. Pero si busca informaci<63>n sobre segmentos, como por ejemplo, la localizaci<63>n de los segmentos \textit{text} o \textit{data} debe utilizar \textit{execution view}. El encabezado describe el layout del archivo, proporcionando informaci<63>n de la forma de acceder a las secciones \cite{MLH98}.
\begin{figure}[h]
\begin{center} \includegraphics[scale=.4]{./images/ELF_Link_exec1} \end{center}
\caption{Tendencia del mercado de procesadores para sistemas embebidos. Fuente:\cite{Lin05} }\label{elf1}
\end{figure}
Las secciones pueden almacenar c<>digo ejecutable, datos, informaci<63>n de enlazado din<69>mico, datos de depuraci<63>n, tablas de s<>mbolos,comentarios, tablas de strings, y notas. Las secciones m<>s importantes son las siguientes:
\begin{itemize}
\item \textbf{.bss} Datos no inicializados. (RAM)
\item \textbf{.comment} Informaci<63>n de la versi<73>n.
\item \textbf{.data y .data1} Datos inicializados. (RAM)
\item \textbf{.debug} Informaci<63>n para depuraci<63>n simb<6D>lica.
\item \textbf{.dynamic} Informaci<63>n sobre enlace din<69>mico
\item \textbf{.dynstr} Strings necesarios para el enlacedin<69>mico
\item \textbf{.dynsym} Tabla de s<>mbolos utilizada para enlace din<69>mico.
\item \textbf{.fini} C<>digo de terminaci<63>n de proceso.
\item \textbf{.init} C<>digo de inicializaci<63>n de proceso.
\item \textbf{.line} Informaci<63>n de n<>mero de l<>nea para depuraci<63>n simb<6D>lica.
\item \textbf{.rodata y .rodta1} Datos de solo-lectura (ROM)
\item \textbf{.shstrtab} Nombres de secciones.
\item \textbf{.symtab} Tabla de s<>mbolos.
\item \textbf{.text} Instrucciones ejecutables (ROM)
\end{itemize}
Para aclarar un poco este concepto consideremos el siguiente c<>digo:
\begin{lstlisting}
#include <stdio.h>
int main(void)
{
int i; // Variable no inicializada
int j = 2; // Variable inicializada
for(i=0; i<10; i++){
printf("Printing %d\n", i*j); // Caracteres constantes
j = j + 1;
}
return 0;
}
\end{lstlisting}
En el ejemplo observamos que tenemos dos variables, una sin inicializar (\textit{i}) y otra inicializada (\textit{j}); estas variables estar<61>n en las secciones \textit{.bss} y \textit{.data} respectivamente, as<61> mismo los caracteres ``Printing `` Estar<61>n incluidos en la secci<63>n \textit{.rodata} ya que son datos que no cambian a lo largo de la ejecuci<63>n del programa. Las instrucciones que forman el programa residen en la secci<63>n \textit{.text}. A continuaci<63>n se muestra la informaci<63>n de este archivo una vez compilado, utilizando la herramienta \textit{objdump} de los utilitarios binarios \textit{binutils} y m<>s espec<65>ficamente el comando:
\textit{objdump -h hello}
\begin{lstlisting}
hello: file format elf32-littlearm
Sections:
Idx Name Size VMA LMA File off Algn
0 .interp 00000014 000080f4 000080f4 000000f4 2**0
CONTENTS, ALLOC, LOAD, READONLY, DATA
1 .hash 00000050 00008108 00008108 00000108 2**2
CONTENTS, ALLOC, LOAD, READONLY, DATA
2 .dynsym 000000f0 00008158 00008158 00000158 2**2
CONTENTS, ALLOC, LOAD, READONLY, DATA
3 .dynstr 0000008a 00008248 00008248 00000248 2**0
CONTENTS, ALLOC, LOAD, READONLY, DATA
5 .init 00000010 000082f4 000082f4 000002f4 2**2
CONTENTS, ALLOC, LOAD, READONLY, CODE
7 .text 0000017c 00008348 00008348 00000348 2**2
CONTENTS, ALLOC, LOAD, READONLY, CODE
8 .fini 0000000c 000084c4 000084c4 000004c4 2**2
CONTENTS, ALLOC, LOAD, READONLY, CODE
9 .rodata 00000010 000084d0 000084d0 000004d0 2**2
CONTENTS, ALLOC, LOAD, READONLY, DATA
10 .eh_frame 00000004 000084e0 000084e0 000004e0 2**2
CONTENTS, ALLOC, LOAD, READONLY, DATA
16 .data 0000000c 000105ac 000105ac 000005ac 2**2
CONTENTS, ALLOC, LOAD, DATA
17 .bss 00000004 000105b8 000105b8 000005b8 2**0
ALLOC
18 .comment 00000094 00000000 00000000 000005b8 2**0
CONTENTS, READONLY
\end{lstlisting}
En el item 9, se observa la informaci<63>n correspondiente a la secci<63>n \textit{.rodata}, la primera columna corresponde al tama<6D>o de la secci<63>n, en este caso 16 bytes, las columnas 2 y 3 corresponden a la direcci<63>n de ejecuci<63>n (VMA) y a la direcci<63>n de carga (LMA) respectivamente. La columna 4 indica la direcci<63>n dentro del ejecutable donde se encuentra almacenada esta informaci<63>n, en este caso la \textit{0x000004d0}, utilizando la herramienta \textit{hexdump} podemos ver el contenido de esa direcci<63>n en el archivo ejecutable:
\textit{hexdump -C hello | grep -i 000004d0}
\begin{lstlisting}
000004d0 50 72 69 6e 74 69 6e 67 20 25 64 0a 00 00 00 00 |Printing %d.....|
\end{lstlisting}
\subsection{Flujo de dise<73>o software}
En la figura \ref{toolchain_flow} se ilustra la secuencia de pasos que se realizan desde la creaci<63>n de un archivo de texto que posee el c<>digo fuente de una aplicaci<63>n hasta su implementaci<63>n en la tarjeta de desarrollo.
\begin{figure}[h]
\begin{center} \includegraphics[scale=.6]{./images/SW_design_flow} \end{center}
\caption{Tendencia del mercado de procesadores para sistemas embebidos. Fuente:\cite{Lin05} }\label{toolchain_flow}
\end{figure}
A continuaci<63>n se realiza una breve descripci<63>n de los pasos necesarios para generar un ejecutable para un sistema embebido:
\begin{enumerate}
\item \textbf{Escritura del c<>digo fuente:} Creaci<63>n del c<>digo fuente en cualquier editor de archivos de texto.
\item \textbf{Compilaci<EFBFBD>n:} Utilizando el compilador gcc se compila el c<>digo fuente; vala la pena mencionar que en este punto el compilador solo busca en los encabezados (\textit{headers}) de las librer<65>as la definici<63>n de una determinada funci<63>n, como por ejemplo el \textit{printf} en el archivo \textit{stdio.h}. Como resultado de este paso se obtiene un archivo tipo objeto.
\item \textbf{Enlazado:} En esta etapa se realizan dos tareas:
\begin{enumerate}
\item Se enlazan los archivos tipo objeto del proyecto, junto con las librer<65>as, si una determinada funci<63>n no es edfinida por ninguna de las librer<65>as pasadas como par<61>metro al linker, este generar<61> un error y no se generar<61> el ejecutable.
\item Se define la posici<63>nes f<>sicas de las secciones del ejecutable tipo ELF, esto se realiza a trav<61>s de un link de enlazado el cual define de forma expl<70>cita su localizaci<63>n.
\end{enumerate}
\item \textbf{Extracci<EFBFBD>n del archivo de programaci<63>n} En algunas aplicaciones es necesario extraer <20>nicamente las secciones que residen en los medios de almacenamiento no vol<6F>til y eliminar las dem<65>s secciones del ejecutable. Esto se realiza con la herramiento \textit{objcopy}, la cual, permite generar archivos en la mayor<6F>a de los formatos soportados por los programadores de memorias y procesadores, como por ejemplo S19 e Intel Hex.
\item \textbf{Descarga del programa a la plataforma}. Dependiendo de la plataforma existen varios m<>todos para descargar el archivo de programaci<63>n a la memoria de la plataforma de desarrollo:
\begin{enumerate}
\item Utilizando un \textit{loader}: El \textit{loader} es una aplicaci<63>n que reside en un medio de almacenamiento no vol<6F>til y permite la descarga de archivos utilizando el puerto serie o una interfaz de red.
\item Utilizando el puerto JTAG: El puerto JTAG (Joint Test Action Group) proporciona una interfaz capaz de controlar los registros internos del procesador, y de esta forma, acceder a las memorias de la plataforma y ejecutar un programa residente en una determinada posici<63>n de memoria.
\end{enumerate}
\item \textbf{Depuraci<EFBFBD>n} Una vez se descarga la aplicaci<63>n a la plataforma es necesario someterla a una serie de pruebas con el f<>n de probar su correcto funcionamiento. Esto se puede realizar con el depurador GNU (GDB) y una interfaz de comunicaci<63>n que puede ser un puerto serie o un adaptador de red.
\end{enumerate}
\section{Makefile}
Como pudo verse en la secci<63>n es necesario realizar una serie de pasos para poder descargar una aplicaci<63>n a una plataforma embebida. Debido a que las herramientas GNU solo poseen entrada por consola de comandos, es necesario esribir una serie de comandos cada vez que se realiza un cambio en el c<>digo fuente, lo cual resulta poco pr<70>ctico. Para realizar este proceso de forma autom<6F>tica se cre<72> la herramienta make, la cual recibe como entrada un archivo que normalmente recibe el nombre de \textit{Makefile} o \textit{makefile}. Un ejemplo de este tipo de archivo se muestra a continuaci<63>n:
\begin{lstlisting}[numbers=left]
SHELL = /bin/sh
basetoolsdir = /home/at91/gcc-3.4.5-glibc-2.3.6/arm-softfloat-linux-gnu
bindir = ${basetoolsdir}/bin
libdir = ${basetoolsdir}/lib/gcc/arm-softfloat-linux-gnu/3.4.5
CC = arm-softfloat-linux-gnu-gcc
AS = arm-softfloat-linux-gnu-as
LD = arm-softfloat-linux-gnu-ld
OBJCOPY = arm-softfloat-linux-gnu-objcopy
CFLAGS =-mcpu=arm920t -I. -Wall
LDFLAGS =-L${libdir} -l gcc
OBJS = \
main.o \
debug_io.o \
at91rm9200_lowlevel.o \
p_string.o
ASFILES = arm_init.o
LIBS=${libdir}/
all: hello_world
hello_world: ${OBJS} ${ASFILES} ${LIBS}
${LD} -e 0 -o hello_world.elf -T linker.cfg ${ASFILES} ${OBJS} ${LDFLAGS}
${OBJCOPY} -O binary hello_world.elf hello_world.bin
clean:
rm -f *.o *~ hello_world.*
PREPROCESS.c = $(CC) $(CPPFLAGS) $(TARGET_ARCH) -E -Wp,-C,-dD,-dI
%.pp : %.c FORCE
$(PREPROCESS.c) $< > $@
\end{lstlisting}
En las l<>neas 3-5 se definen algunas variables globales que ser<65>n utilizadas a lo largo del archivo; en las l<>neas 7 - 10 se definen las herramientas de compilaci<63>n a utilizar, espec<65>ficamente los compiladores de C (CC), de assembler (AS), el linker (LD) y la utilidad objcopy. A partir de la l<>nea 15 se definen los objetos que forman parte del proyecto, en este caso: \textit{main.o, debug\_io.o, at91rm9200\_lowlevel.o y p\_string.o}; en la l<>nea 21 se definen los archivos en assembler que contiene el proyecto, para este caso \textit{arm\_init.o}. Las l<>neas 12 y 13 definen dos variables especiales que se pasan directamente al copm<70>lador de C (CFLAGS) y al liniker (LDFLAGS)
En las l<>neas 25, 27 y 31 aparecen unas etiquetas de la forma: \textit{nombre:} estos labels permiten ejecutar de forma independiente el conjunto de instrucciones asociadas a ellas, por ejemplo, si se ejecuta el comando:
\\ \bigskip
\textit{make clean}\\ \bigskip
make ejecutar<61> el comando:\\ \bigskip
\textit{rm -f *.o *~ hello\_world.*}
Observemos los comandos asociados a la etiqueta \textit{hello\_world:} En la misma l<>nea aparecen \textit{\${OBJS} \${ASFILES} \${LIBS}} esto le indica a la herramienta \textit{make} que antes de ejecutar los comandos asociados a este label, debe realizar las acciones necesarias para generar \textit{\${OBJS} \${ASFILES} \${LIBS}} o lo que es lo mmismo: \textit{main.o, debug\_io.o, at91rm9200\_lowlevel.o, p\_string.o, arm\_init.o y libgcc.a}. \textit{make} tiene predefinidas una serie de reglas para compilar los archivos .c la regla es de la forma:
\begin{lstlisting}
.c.o:
$(CC) $(CFLAGS) -c $<
.c:
$(CC) $(CFLAGS) $@.c $(LDFLAGS) -o $@
\end{lstlisting}
Lo cual le indica a la herramienta make que para generar un archivo \textit{.o} a partir de uno \textit{.c} es necesario ejecutar \textit{\$(CC) \$(CFLAGS) -c \$<}; de aqui la importancia de definir bien la variable de entorno \textit{CC} cuando trabajamos con compiladores cruzados\footnote{Un compilador cruzado genera c<>digo para una plataforma diferente en la que se est<73> ejecutando, por ejemplo, genera ejecutables para ARM pero se ejecuta en un x86}. Hasta este punto al ejecutar el comando: \textit{make hello\_world}, \textit{make} realizar<61>a las siguientes operaciones: \\
\begin{lstlisting}
arm-softfloat-linux-gnu-gcc -mcpu=arm920t -I. -Wall -c -o main.o main.c
arm-softfloat-linux-gnu-gcc -mcpu=arm920t -I. -Wall -c -o debug_io.o debug_io.c
arm-softfloat-linux-gnu-gcc -mcpu=arm920t -I. -Wall -c -o at91rm9200_lowlevel.o at91rm9200_lowlevel.c
arm-softfloat-linux-gnu-gcc -mcpu=arm920t -I. -Wall -c -o p_string.o p_string.c
arm-softfloat-linux-gnu-as -o arm_init.o arm_init.s
\end{lstlisting}
En las l<>neas 28 se realiza el proceso de enlazado; al \textit{linker} se le pasan los par<61>metros:
\begin{itemize}
\item \textbf{-e 0}: Punto de entrada , utilice 0 como s<>mbolo para el inicio de ejecuci<63>n.
\item \textbf{-o hello\_world.elf}: Nombre del archivo de salida \textit{hello\_world}
\item \textbf{-T linker.cfg}: Utilice el archivo de enlace \textit{linker.cfg}
\item \textbf{\${ASFILES} \${OBJS} \${LDFLAGS}}: Lista de objetos y librer<65>as para crear el ejecutable.
\end{itemize}
En la l<>nea 29 se utiliza la herramienta \textit{objcopy} para generar un archivo binario (\textit{-O binary}) con la informaci<63>n necesaria para cargar en una memoria no vol<6F>til.

24
course/.docs/cambio_categoria/chapter2.tex Normal file
View File

@@ -0,0 +1,24 @@
\chapter{Sistema en un Chip (SoC)}
En esta secci<63>n estudiaremos la arquitectura b<>sica de un SoC moderno, componentes, funcionamiento, programaci<63>n y operaci<63>n. Como se mencion<6F> anteriormente, la tendencia actual de la industria de los semiconductores es integrar en un solo dispositivo las funcionalidades necesarias para la implementaci<63>n de dispositivos digitales modernos. Esto es posibe gracias a los grandes avances en las t<>cnicas de fabricaci<63>n de circuitos integrados y a la demanda de nuevas caracter<65>sticas exigidas por los fabricantes de dispositivos digitales de consumo masivo como tel<65>fonos celulares, PDAs, consolas de juegos y reproductores multimedia. Para utilizar estos avances tecnol<6F>gicos es necesario conocer su arquitectura, principio de funcionamiento, programaci<63>n e implementaci<63>n, para esto, se estudiar<61>n dos proyectos abiertos que implementan un SoC en un PLD utilizando lenguaje de descripci<63>n de hardware y herramientas GNU; proporcionan el c<>digo fuente, lo que permite un estudio profundo de su arquitectura. El proyecto \textit{Plasma} \cite{SR08} y el proyecto Mico32\cite{LSC08}.
\section{Arquitectura}
Un SoC, integra un conjunto de perif<69>ricos, memorias y una o varias unidades de procesamiento (CPUs) en un solo chip, lo cual facilita el desarrollo de aplicaciones. Comercialmente encontramos una gran variedad de configuraciones CPU - perif<69>ricos, dependiendo de la aplicaci<63>n; dentro de los m<>s comunes se encuentran: controladores de memorias externas (NOR, NAND, SDRAM, DDR), puertos de comunicaci<63>n (I2C, SPI), puerto de depuraci<63>n (UART), timers, reloj de tiempo real, codecs de audio, controladores de LCD, controladores de red, controlador de puerto USB host, controlador para sensores de im<69>genes, etc. La figura \ref{min_soc_arch} muestra una arquitectura de un SoC sencillo con los componentes necesarios para implementar tareas simples.
\begin{figure}
\begin{center} \includegraphics[scale=.6]{./images/Computer-simple} \end{center}
\caption{Arquitectura m<>nima de un SoC}\label{min_soc_arch}
\end{figure}
\subsubsection{Unidad de Procesamiento Central (CPU)}
La unidad de procesamiento central (CPU), como su nombre lo indica, est<73> encargada de centralizar las tareas del sistema coordinando las acciones de los perif<69>ricos. Puede ser vista como una m<>quina de estados programable que controla un camino de datos compuesto por bloques aritm<74>ticos, l<>gicos y un banco de registros. Cada CPU es capaz de realizar una serie de operaciones sobre variables almacenadas en el banco de registros, estas operaciones reciben el nombre de \textit{conjunto de instrucciones}. El programador utiliza estas instrucciones para hacer que la CPU realice una funci<63>n espec<65>fica, indicandole paso a paso donde debe leer la informaci<63>n, como procesarla y como entregar el resultado. A Esta funci<63>n se le conoce con el nombre de programa o tarea Software.
\subsubsection{Perif<EFBFBD>ricos}
Los perif<69>ricos proporcionan la comunicaci<63>n con el exterior, permiten el ingreso, almacenamiento y procesamiento de la informaci<63>n

16
course/.docs/cambio_categoria/chapter2.tex.backup Normal file
View File

@@ -0,0 +1,16 @@
\chapter{Sistema en un Chip (SoC)}
En esta secci<63>n estudiaremos la arquitectura b<>sica de un SoC moderno, componentes, funcionamiento, programaci<63>n y operaci<63>n. Como se mencion<6F> anteriormente la tendencia actual de la industria de los semiconductores es integrar en un solo dispositivo las funcionalidades necesarias para la implementaci<63>n de dispositivos digitales modernos. Esto es posibe gracias a los grandes avances en las t<>cnicas de fabricaci<63>n de circuitos integrados y a la demanda de nuevas caracter<65>sticas exigidas por los fabricantes de dispositivos digitales de consumo masivo como tel<65>fonos celuulares, PDAs, consolas de juegos y reproductores multimedia. Para utilizar estos avances tecnol<6F>gicos es necesario conocer su principio de funcionamiento, por este motivo, estudiaremos dos proyectos abiertos que implementan un SoC en una FPGA y proporcionan el c<>digo fuente, lo que permite estudiar y comprender su funcionamiento y de ser necesario hacer modificaciones. El proyecto \textit{Plasma} \cite{SR08} y el proyecto Mico32\cite{LSC08} ser<65>n utilizados como base de nuestro estudio.
\section{Arquitectura}
Un SoC, integra un conjunto de perif<69>ricos, memorias y una o varias unidades de procesamiento (CPUs) en un solo chip, lo cual facilita el desarrollo, los perif<69>ricos var<61>an dependiendo de la aplicaci<63>n, dentro de los m<>s comunes se encuentran: controladores de memorias externas (NOR, NAND, SDRAM, DDR), puertos de comunicaci<63>n (I2C, SPI), puerto de depuraci<63>n (UART), timers, reloj de tiempo real. Seg<65>n la aplicaci<63>n es com<6F>n encontrar: codecs de audio, controladores de LCD, controladores de red, controlador de puerto USB host, controlador para sensores de im<69>genes, etc.
La figura \ref{min_soc_arch} muestra una arquitectura m<>nima de un SoC, donde se muestra una interfaz sencilla entre la CPU y los perif<69>ricos (la cual var<61>a entre fabricantes).
\begin{figure}
\begin{center} \includegraphics[scale=.6]{./images/Computer-simple} \end{center}
\caption{Arquitectura m<>nima de un SoC}\label{min_soc_arch}
\end{figure}

2245
course/.docs/cambio_categoria/chaptera.tex Normal file
View File

File diff suppressed because it is too large Load Diff

159
course/.docs/cambio_categoria/embedded.kilepr Normal file
View File

@@ -0,0 +1,159 @@
[General]
def_graphic_ext=eps
img_extIsRegExp=false
img_extensions=.eps .jpg .jpeg .png .pdf .ps .fig .gif
kileprversion=2
kileversion=2.0.85
lastDocument=chapter2.tex
masterDocument=
name=embedded
pkg_extIsRegExp=false
pkg_extensions=.cls .sty .bbx .cbx .lbx
src_extIsRegExp=false
src_extensions=.tex .ltx .latex .dtx .ins
[Tools]
MakeIndex=
QuickBuild=
[document-settings,item:chapter1.tex]
Bookmarks=
Encoding=ISO-8859-3
Highlighting=LaTeX
Indentation Mode=
Mode=LaTeX
ReadWrite=true
[document-settings,item:chapter2.tex]
Bookmarks=
Encoding=ISO-8859-3
Highlighting=LaTeX
Indentation Mode=
Mode=LaTeX
ReadWrite=true
[document-settings,item:embedded.tex]
Bookmarks=
Encoding=ISO-8859-3
Highlighting=LaTeX
Indentation Mode=
Mode=LaTeX
ReadWrite=true
[document-settings,item:embedded_book.tex]
Bookmarks=
Encoding=ISO-8859-3
Highlighting=LaTeX
Indentation Mode=
Mode=LaTeX
ReadWrite=true
[document-settings,item:introduction.tex]
Bookmarks=
Encoding=ISO-8859-3
Highlighting=LaTeX
Indentation Mode=
Mode=LaTeX
ReadWrite=true
[document-settings,item:title.tex]
Bookmarks=
Encoding=ISO-8859-3
Highlighting=LaTeX
Indentation Mode=
Mode=LaTeX
ReadWrite=true
[item:chapter1.tex]
archive=true
column=0
encoding=ISO-8859-3
highlight=LaTeX
line=665
mode=LaTeX
open=true
order=3
[item:chapter2.tex]
archive=true
column=9
encoding=ISO-8859-3
highlight=LaTeX
line=5
mode=LaTeX
open=true
order=5
[item:embedded.kilepr]
archive=true
column=1
encoding=
highlight=
line=0
mode=
open=false
order=-1
[item:embedded.tex]
archive=true
column=7
encoding=ISO-8859-3
highlight=LaTeX
line=29
mode=LaTeX
open=true
order=0
[item:embedded_book.tex]
archive=true
column=21
encoding=ISO-8859-3
highlight=LaTeX
line=50
mode=LaTeX
open=true
order=1
[item:introduction.tex]
archive=true
column=89
encoding=ISO-8859-3
highlight=LaTeX
line=20
mode=LaTeX
open=true
order=2
[item:title.tex]
archive=true
column=29
encoding=ISO-8859-3
highlight=LaTeX
line=18
mode=LaTeX
open=true
order=4
[view-settings,view=0,item:chapter1.tex]
CursorColumn=0
CursorLine=665
[view-settings,view=0,item:chapter2.tex]
CursorColumn=9
CursorLine=5
[view-settings,view=0,item:embedded.tex]
CursorColumn=7
CursorLine=29
[view-settings,view=0,item:embedded_book.tex]
CursorColumn=21
CursorLine=50
[view-settings,view=0,item:introduction.tex]
CursorColumn=89
CursorLine=20
[view-settings,view=0,item:title.tex]
CursorColumn=29
CursorLine=18

647
course/.docs/cambio_categoria/embedded.tex Normal file
View File

@@ -0,0 +1,647 @@
\chapter{Sistemas Embebidos}
\label{ch:embedded}
\section{Introducci<EFBFBD>n}
Uno de los objetivos de este trabajo, es la creaci<63>n de una plataforma Embebida que permita la apropiaci<63>n de nuevas herramientas y metodolog<6F>as de dise<73>o.
El mercado de los sistemas embebidos contin<69>a en aumento y su campo de acci<63>n se ha extendido en casi todas las actividades humanas.
Seg<EFBFBD>n BBC, inc. \footnote{http://www.bccresearch.com/} el mercado para el software embebido puede crecer de \$1.6 billones a \$3.5 billones en 2009,
con una tasa de crecimiemto anual (AAGR) del 16\%, mientras la tasa de crecimiento para las tarjetas embebidas es del 10\%. (Favor ver Figura \ref{GESM}).
\begin{figure}[H]
\begin{center} \includegraphics[scale=.6]{./images/embedded_system_market} \end{center}
% \includegraphics[scale=.6]{./images/glob-emb-software-rev-regio} \end{center}
\caption{Mercado Global de Sistemas Embebidos 2003-2009. Fuente: BCC Inc.} \label{GESM}
\end{figure}
Esto unido a: el gran nivel de integraci<63>n obtenido por la industria de los semiconductores en los \textit{SOC}, la disponibilidad de herramientas software
de desarrollo gratuitas (compiladores, simuladores, librer<65>as, Sistemas Operativos) abre grandes posibilidades comerciales para paises en v<>a de
desarrollo ya que no son necesarias grandes inversiones de capital para la implementaci<63>n de estos sistemas.
M<EFBFBD>s de un bill<6C>n de dispositivos embebidos fueron vendidos en el 2004, seg<65>n \textit{Venture Development Corporation (VDC)}. De acuerdo con VDC
el porcentaje de dispositivos basados en Sistemas Operativos comerciales tiende a disminuir callendo del 43.1\% en 2001 a 37.1\% en 2004, esta tendencia
se debe al aumento de complejidad de los dispositivos y a las necesidades de conexi<78>n (tales como Ethernet, bluetooth, WiFi, etc); adem<65>s, la
caida de precios del hardware, elimina la necesidad de eficiencia en el manejo de recursos proporcionada por muchos productos comerciales. Otro factor
es el deseo de utilizar el mismo Sistema Operativo para varios proyectos.
Recientes investigaciones de VDC sugieren que entre el 13 y el 15\% de los desarrolladores utilizan linux como su sistema operativo principal, y se espera
que esta cifra aumente al madurar la tecnolog<6F>a y el soporte de los recursos de la comunidad aumenten. La figura \ref{os_trends} muestra una encuenta
realizada a 932 desarrolladores de todo el mundo por \textit{linuxdevices} \footnote{http://www.linuxdevices.com}
\begin{figure}[H]
\begin{center} \includegraphics[scale=.6]{./images/embedded_OS_sourcing_trends} \end{center}
\caption{Preferencia de Sistema Operativo para Sistemas Embebidos 2003-2007. Fuente: linuxdevices.} \label{os_trends}
\end{figure}
La elecci<63>n de Linux como herramienta de desarrollo esta fuertemente influenciada por su caracter libre, la gran disponibilidad de herramientas de
desarrollo, aplicaciones, librer<65>as y la posibilidad de modificar o adaptar c<>digo ya existente.
El coraz<61>n de todo sistema embebido es su procesador, en la actualidad existen diversos fabricantes que ponen a disposici<63>n de los desarrolladores
\textit{System On Chip} (SOC) que incluyen una gran variedad de perif<69>ricos que incluyen dispositivos de comunicaci<63>n (UARTs, USB, Ethernet),
interface con el humano (Controladores de: LCD, tarjetas de sonido, dispositivos touch screen), almacenamiento (memorias: RAM, SDRAM, SD, MMC).
Al incluir la mayor<6F>a de los perif<69>ricos en el mismo Chip se reduce el espacio de la placa de circuito impreso (PCB) y se reduce la posibilidad de
errores debido a interconexi<78>n y contrario a lo que se podr<64>a esperar, el costo de este SOC es muy bajo (en comparaci<63>n con el costo de cada perif<69>rico
por separado). La figura \ref{cpu_trends} muestra la preferencia de los desarrolladores encuestados por \textit{linuxdevices}.
\begin{figure}[H]
\begin{center} \includegraphics[scale=.6]{./images/embedded_processor_preference_history} \end{center}
\caption{Preferencia de CPU para Sistemas Embebidos 2004-2007. Fuente: linuxdevices.} \label{cpu_trends}
\end{figure}
Como puede verse en la Figura \ref{cpu_trends} existe una clara preferencia entre los procesadores x86 y los procesadores ARM, siendo estos <20>ltimos
los m<>s populares en dispositivos de consumo como PDAs, Routers, tel<65>fonos celulares, consolas de juego port<72>tiles.\ref{cpu_trends}
\section{Definici<EFBFBD>n}
Un Sistema Embebido es un sistema de prop<6F>sito espec<65>fico en el cual, el computador es encapsulado completamente por el dispositivo que el controla.
A diferencia de los computadores de prop<6F>sito general, un Sistema Embebido realiza tareas pre-definidas, lo cual permite su optimizaci<63>n, reduciendo
el tama<6D>o y costo del producto \cite{Wik}
\subsection{Caracter<EFBFBD>sticas}
\begin{itemize}
\item Los sistemas embebidos son dise<73>ados para una aplicaci<63>n
espec\'{\i}fica, es decir, estos sistemas realizan un grupo de funciones
previamente definidasm y una vez el sistema es dise<73>ado, no se puede cambiar
su funcionalidad. Por ejemplo, el control de un asensor siempre realizar\'a
las mismas acciones durante su vida \'util.
\item Debido a su interacci<63>n con el entorno los ES deben cumplir
esctr<74>ctamente restricciones temporales. El t\'ermino {\textit{Sistemas
de Tiempo Real}} es utilizado para enfatizar este aspecto.
\item Los Sistemas Embebidos son heterog\'eneos, es decir, est\'an
compuestos por componentes Hardware y Software. Los componentes Hardware,
como ASICs y Dispositivos L\'ogicos Programables (PLD) proporcionan la
velocidad de ejecuci\'on y el cosumo de potencia necesarios en algunas
aplicaciones.
\item Los Sitemas Embebidos tienen grandes requerimientos en t\'erminos de
confiabilidad. Errores en aplicaciones como la aviaci\'on y el
automovilismo, pueden tener consecuencias desastrosas.
\end{itemize}
\subsection{Arquitectura}
En la Figura \ref{es_arch} se muestra la arquitectura t<>pica de un Sistema Embebido. La cual integra un componente hardware, implementado ya sea
en un PLD (CPLD, FPGA) o en un ASIC, conocido con el nombre de perif<69>ricos y un componente software (procesador o DSP) cap<61>z de ejecutar software,
la parte del procesador est<73> dividida en la CPU (En algunos casos posee una cach<63>) y las unidades de Memoria.
\begin{figure}
\begin{center} \includegraphics[scale=.6]{./images/ES_Architecture} \end{center}
\caption{Arquitectura de un Sistema Embebido}\label{es_arch}
\end{figure}
Al momento de dise<73>ar un Sistema Embebido encontramos las siguientes opciones:
\begin{itemize}
\item Componente HW y SW Integrado en un dispositivo semiconductor (SoC): En la actualidad existen muchas compa<70><61>as que fabrican procesadores de 32 bits
integrados a una gran variedad de perif<69>ricos, lo cual simplifica el dise<73>o y reduce costos. \footnote{http://www.sharpsma.com, http://www.atmel.com,
http://www.cirrus.com, http://www.samsung.com, http://www.freescale.com, etc}. Este tipo de implementaci<63>n es muy popular en los dispositivos de consumo
masivo (Reproductores de MP3, consolas de juego, etc), debido a los grandes niveles de producci<63>n (del orden de millones de unidades) resulta m<>s econ<6F>mico
contar con un dispositivo que integre el mayor n<>mero de funcionalidades, esto disminuye el costo de componentes y reduce el <20>rea de circuito impreso.
\item Componente SW en un SoC y componente HW en una FPGA: Cuando no existen en el mercado un SoC con la cantidad de perif<69>ricos requerida para una
determinada aplicaci<63>n, o con una funcionalidad espec<65>fica, es necesario recurrir a la utilizaci<63>n de dispositivos comerciales que implementen dicha
operaci<EFBFBD>n, en algunas ocaciones el perif<69>rico puede relizar funciones poco com<6F>nes y no se proporciona comercialmente, la soluci<63>n es entonces, implementar estas funcionalidades en una FPGA; tambi<62>n se recomienda la utilizaci<63>n de FPGAs en sistemas que requieren la utilizaci<63>n de la misma funcionalidad un gran n<>mero de veces (Puertos seriales, Pines de Entrada/Salida). Esta decisi<73>n esta atada al nivel de producci<63>n, ya que al incluir una FPGA aumenta el costo global del proyecto.
\item Componente SW y HW en una FPGA: Esta es tal vez la opci<63>n m<>s flexible, pero la de menor desempe<70>o, ya que al utilizar los recursos l<>gicos de la FPGA para la implementaci<63>n del procesador (softcore) la longitud de los caminos de interconexi<78>n entre los bloques l<>gicos aumentan el retardo de las se<73>ales, lo cual disminuye la m<>xima velocidad de funcionamiento. Los procesadores \textit{softcore} m<>s populares en la actualidad son:
\begin{itemize}
\item Microblaze y Picoblaze de Xilinx\footnote{http://www.xilinx.com}
\item Leon de Gaisler Research \footnote{http://www.gaisler.com/}
\item LatticeMico32 de Lattice Semiconductors\footnote{http://www.latticesemi.com}
\item OpenRisc \footnote{http://www.opencores.com}
\end{itemize}
\end{itemize}
\section{Metodolog<EFBFBD>a de Dise<73>o}
El proceso de dise<73>o de un Sistema Embebido comienza con la {\textit{especificaci\'on del sistema}}, (ver Figura \ref{des_flow}), en este
punto se describe la funcionalidad y se definen las restricciones
f\'{\i}sicas, el\'ectricas y econ\'omicas. Esta especificaci\'on debe ser muy
general y no deben existir dependencias (tecnol\'ogicas, metodol\'ogicas) de
ning\'un tipo, se suele utilizar lenguajes de alto nivel, como UML, C++. La
especificaci\'on puede ser verificada a trav\'es de una serie de pasos de
an\'alisis cuyo objetivo es determinar la validez de los algor\'{\i}tmos
seleccionados, por ejemplo, determinar si el algoritmo siempre termina, los
resultados satisfacen las especificaciones. Desde el punto de vista de la
re-utilizaci\'on, algunas partes del funcionamiento global deben tomarse de
una librer\'{\i}a de algor\'{\i}tmos existentes.
\begin{figure}
\begin{center} \includegraphics[scale=.55]{./images/design_flow} \end{center}
\caption{Flujo de Dise<73>o de un Sistema Embebido \cite{Cor05}}\label{des_flow}
\end{figure}
Una vez definidas las especificaciones del sistema se debe realizar un
modelamiento que permita extraer de estas la funcionalidad. El modelamiento es
crucial en el dise<73>o ya que de \'el depende el paso existoso de la
especificaci\'on a la implementaci\'on. Es importante definir que modelo
matem\'atico debe soportar el entorno de dise<73>o. Los modelos m\'as utilizados
son: M\'aquinas de estados finitos, diagramas de flujos de datos, Sistemad de
Eventos Discretos y Redes de Petri. Cada modelo posee propiedades
matem\'aticas que pueden explotarse de forma eficiente para responder
preguntas sobre la funcionalidad del sistema sin llevar a cabo dispendiosas
tareas de verificaci\'on. \ Todo modelo obtenido debe ser verificado para
comprobar que cumple con las restricciones del sistema.
Una vez se ha obtenido el modelo del sistema se procede a determinar su
{\textit{arquitectura}}, esto es, el n\'umero y tipo de componentes y su
inter-conexi\'on. Este paso no es m\'as que una exploraci\'on del espacio de
dise<EFBFBD>o en b\'usqueda de soluciones que permitan la implementaci\'on de una
funcionalidad dada, y puede realizarse con varios criterios en mente: Costos,
confiabilidad, viabilidad comercial.
Utilizando como base la arquitectura obtenida en el paso anterior las tareas
del modelo del sistemas son mapeadas dentro de los componentes. Esto es,
asignaci\'on de funciones a los componentes de la arquitectura. Existen dos
opciones a la hora de implementar las tareas o procesos:
\begin{enumerate}
\item Implementaci\'on Software: La tarea se va a ejecutar en un procesador.
\item Implementaci\'on Hardware: La tarea se va a ejecutar en un sistema
digital dedicado.
\end{enumerate}
Para cumplir las especificaciones del sistema algunas tareas deben ser
implementadas en Hardware, esto con el f\'{\i}n de no ocupar al procesador en
tareas c\'{\i}clicas, un ejemplo t\'{\i}pico de estas tareas es la
generaci\'on de bases de tiempos. La decisi\'on de que tareas se implementan
en SW y que tareas se implementan en HW recibe el nombre de
{\textit{particionamiento}}, esta selecci\'on es fuertemente dependiente de
restricciones econ\'omicas y temporales.
Las tareas Software deben compartir los recursos que existan en el sistema
(procesador y memoria), por lo tanto se deben hacer decisiones sobre el orden
de ejecuci\'on y la prioridad de estas. Este proceso recibe el nombre de
{\textit{planificaci\'on}}. En este punto del dise<73>o el modelo debe incluir
informaci\'on sobre el mapeo, el particionamiento y la planificaci\'on del
sistema.
Las siguientes fases corresponden a la implementaci\'on del modelo, para esto
las tareas hardware deben ser llevadas al dispositivo elegido (ASIC o FPGA) y
se debe obtener el $''$ejecutable$''$ de las tareas software, este proceso
recibe el nombre de {\textit{s\'{\i}ntesis}} HW y SW respectivamente, as\'{\i}
mismo se deben sintetizar los mecanismos de comunicaci\'on.
El proceso de prototipado consiste en la realizaci\'on f\'{\i}sica del
sistema, finalmente el sistema f\'{\i}sico debe someterse a pruebas para
verificar que se cumplen con las especificaciones iniciales.
Como puede verse en el flujo de dise<73>o existen realimentaciones, estas
realimentaciones permiten depurar el resultado de pasos anteriores en el caso
de no cumplirse con las especificaciones iniciales.
\section{Herramientas Software de libre distribuci<63>n \textit{GNU toolchain}}
En el mercado existe una gran variedad de herramientas de desarrollo para Sistemas Embebidos,
sin embargo, en este estudio nos centraremos en el uso de las herramientas de libre distribuci<63>n;
esta elecci<63>n se debe a que la mayor<6F>a de los productos comerciales utilizan el toolchain de GNU\footnote{http://www.gnu.org} internamente y proporcionan un entorno gr<67>fico para su f<>cil manejo. Otro factor considerado a la hora de realizar nuestra elecci<63>n es el econ<6F>mico, ya que la mayor<6F>a de los productos comerciales son costosos y poseen soporte limitado. Por otro lado, el toolchain de GNU es utilizado ampliamente en el medio de los dise<73>adores de sistemas embebidos y se encuentra un gran soporte en m<>ltiples foros de discusi<73>n (ver Figura \ref{tools}).
\begin{figure}[h]
\begin{center} \includegraphics[scale=.7]{./images/embedded-linux-tool-trends-sm} \end{center}
\caption{Tendencia de utilizaci<63>n de herramientas de desarrollo}\label{tools}
\end{figure}
\subsubsection{GNU binutils\cite{A1}}
Son una colecci<63>n de utilidades para archivos binarios y estan compuestas por:
\begin{itemize}
\item \textbf{addr2line} Convierte direcciones de un programa en nombres de archivos y n<>meros de l<>nea. Dada una direcci<63>n y un ejecutable, usa la informaci<63>n de depuraci<63>n en el ejecutabe para determinar que nombre de atchivo y n<>mero de lpinea est<73> asociado con la direcci<63>n dada.
\item \textbf{ar} Esta utilidad crea, modifica y extrae desde ficheros. Un fichero es una colecci<63>n de otros archivos en una estructura que hace posible obtener los archivos individuales miembros del archivo.
\item \textbf{as} Utilidad que compila la salida del compilador de C (GCC).
\item \textbf{c++filt} Este program realiza un mapeo inverso: Decodifica nombres de bajo-nivel en nombres a nivel de usuario, de tal forma que el linker pueda mantener estas funciones sobrecargadas (overloaded) ``from clashing''.
\item \textbf{gasp} GNU Assembler Macro Preprocessor
\item \textbf{ld} El \textit{linker} GNU combina un n<>mero de objetos y ficheros, re-localiza sus datos y los relaciona con referencias. Normalmente el <20>ltimo paso en la construcci<63>n de un nuevo programa compilado es el llamado a ld.
\item \textbf{nm} Realiza un listado de s<>mbolos de archivos tipo objeto.
\item \textbf{objcopy} Copia los contenidos de un archivo tipo objeto a otro. \textit{objcopy} utiliza la librer<65>a GNU BFD para leer y escribir el archivo tipo objeto. Permite esccribibr el archivo destino en un formato diferente al del archivo fuente.
\item \textbf{objdump} Despliega informaci<63>n sobre archivos tipo objeto.
\item \textbf{ranlib} Genera un <20>ndice de contenidos de un fichero, y lo almacena en <20>l.
\item \textbf{readelf} Interpreta encabezados de un archivo ELF.
\item \textbf{size} Lista el tama<6D>o de las secciones y el tama<6D>o total de un archivo tipo objeto.
\item \textbf{strings} Imprime las secuencias de caracteres imprimibles de almenos 4 caracteres de longitud.
\item \textbf{strip} Elimina todos los s<>mbolos de un archivo tipo objeto.
\end{itemize}
\subsubsection{GNU Compiler Collection}
El \textit{GNU Compiler Collection} normalmente llamado GCC, es un grupo de compiladores de lenguajes de programaci<63>n producido por el proyecto GNU. Es el compilador standard para el software libre de los sistemas operativos basados en Unix y algunos propietarios como Mac OS de Apple. Soporta los siguientes lenguajes: ADA, C, C++, Fortran, Java, Objective-C, Objective-C++ para las arquitecturas: Alpha, ARM, Atmel AVR, Blackfin, H8/300, System/370, System/390, IA-32 (x86) and x86-64, IA-64 i.e. the "Itanium", Motorola 68000, Motorola 88000, MIPS, PA-RISC, PDP-11, PowerPC, SuperH, SPARC, VAX, Renesas R8C/M16C/M32C, MorphoSys.
Como puede verse GCC soporta una gran cantidad de lenguajes de programaci<63>n, sin embargo, en el presente estudio solo lo utilizaremos como herramienta de compilaci<63>n para C y C++. Una caracter<65>stica de resaltar de GCC es la gran cantidad de plataformas que soporta, esto lo hace una herramienta Universal para el desarrollo de sistemas embebidos, el c<>digo escrito en una plataforma (en un lenguaje de alto nivel) puede ser implementado en otra sin mayores cambios, esto elimina la dependencia entre el c<>digo fuente y el HW\footnote{Esto recibe el nombre de re-utilizaci<63>n de c<>digo}, lo cual no ocurre al utilizar lenguaje ensamblador.
Por otro lado, el tiempo requerido para realizar aplicaciones utilizando C o C++ disminuye, ya que no es necesario aprender las instrucciones en assembler de una plataforma determinada; adem<65>s, la disponibilidad de librer<65>as de m<>ltiples prop<6F>sitos reduce a<>n m<>s los tiempos de desarrollo, permitiendo de esta forma tener bajos tiempos \textit{time to market} y reducir de forma considerable el costo del desarrollo.
\subsubsection{GNU Debugger}
El depurador oficial de GNU (GDB), es un depurador que al igual que GCC tiene soporte para m<>ltiples lenguajes y plataformas. GDB permite al usuario monitorear y modificar las variables internas del programa y hacer llamado a funciones de forma independiente a la ejecuci<63>n normal del mismo. Adem<65>s, permite establecer sesiones remotas utilizando el puerto serie o TCP/IP. Aunque GDB no posee una interfaz gr<67>fica, se han desarrollado varios front-ends como DDD o GDB/Insight.
\subsubsection{Librer<EFBFBD>as C}
Adicionalmente es necesario contar con una librer<65>a que proporcione las librer<65>as standard de C: stdio, stdlib, math; las m<>s utilizadas en sistemas embebidos son:
\begin{itemize}
\item \textbf{glibc\footnote{http://www.gnu.org/software/libc/}} Es la librer<65>a C oficial del proyecto GNU. Uno de los inconvenientes al trabajar con esta librer<65>a en sistemas embebidos es que genera ejecutables de mayor tama<6D>o que los generados a partir de otras librer<65>as, lo cual no la hace muy atractiva para este tipo de aplicaciones.
\item \textbf{uClibc\footnote{http://uclibc.org/}} Es una librer<65>a dise<73>ada especialmente para sistemas embebidos, es mucho m<>s peque<75>a que \textbf{glibc}.
\item \textbf{newlib\footnote{http://sources.redhat.com/newlib/}} Al igual que \textbf{uClibc}, est<73> dise<73>ada para sistemas embebidos. El t<>pico ``Hello, world!'' ocupa menos de 30k en un entorno basado en newlib, mientras que en uno basado en glibc, puede ocupar 380k \cite{BG}.
\item \textbf{diet libc\footnote{http://www.fefe.de/dietlibc/}} Es una versi<73>n de \textit{libc} optimizada en tama<6D>o, puede ser utilizada para crear ejecutables est<73>ticamente enlazados para linux en plataformas alpha, arm, hppa, ia64, i386, mips, s390, sparc, sparc64, ppc y x86\_64.
\end{itemize}
\subsection{Flujo de dise<73>o software}
En la figura \ref{toolchain_flow} se ilustra la secuencia de pasos que se realizan desde la creaci<63>n de un archivo de texto que posee el c<>digo fuente de una aplicaci<63>n hasta su implementaci<63>n en la tarjeta de desarrollo.
\begin{figure}[h]
\begin{center} \includegraphics[scale=.6]{./images/SW_design_flow} \end{center}
\caption{Flujo de dise<73>o SW utilizando la cadena de herramientas GNU}\label{toolchain_flow}
\end{figure}
A continuaci<63>n se realiza una breve descripci<63>n de los pasos necesarios para generar un ejecutable para un sistema embebido:
\begin{enumerate}
\item \textbf{Escritura del c<>digo fuente:} Creaci<63>n del c<>digo fuente en cualquier editor de archivos de texto.
\item \textbf{Compilaci<EFBFBD>n:} Utilizando el compilador gcc se compila el c<>digo fuente; vala la pena mencionar que en este punto el compilador solo busca en los encabezados (\textit{headers}) de las librer<65>as la definici<63>n de una determinada funci<63>n, como por ejemplo el \textit{printf} en el archivo \textit{stdio.h}. Como resultado de este paso se obtiene un archivo tipo objeto.
\item \textbf{Enlazado:} En esta etapa se realizan dos tareas:
\begin{enumerate}
\item Se enlazan los archivos tipo objeto del proyecto, junto con las librer<65>as, si una determinada funci<63>n no es edfinida por ninguna de las librer<65>as pasadas como par<61>metro al linker, este generar<61> un error y no se generar<61> el ejecutable.
\item Se define la posici<63>nes f<>sicas de las secciones del ejecutable tipo ELF, esto se realiza a trav<61>s de un link de enlazado el cual define de forma expl<70>cita su localizaci<63>n.
\end{enumerate}
\item \textbf{Extracci<EFBFBD>n del archivo de programaci<63>n} En algunas aplicaciones es necesario extraer <20>nicamente las secciones que residen en los medios de almacenamiento no vol<6F>til y eliminar las dem<65>s secciones del ejecutable. Esto se realiza con la herramiento \textit{objcopy}, la cual, permite generar archivos en la mayor<6F>a de los formatos soportados por los programadores de memorias y procesadores, como por ejemplo S19 e Intel Hex.
\item \textbf{Descarga del programa a la plataforma}. Dependiendo de la plataforma existen varios m<>todos para descargar el archivo de programaci<63>n a la memoria de la plataforma de desarrollo:
\begin{enumerate}
\item Utilizando un \textit{loader}: El \textit{loader} es una aplicaci<63>n que reside en un medio de almacenamiento no vol<6F>til y permite la descarga de archivos utilizando el puerto serie o una interfaz de red.
\item Utilizando el puerto JTAG: El puerto JTAG (Joint Test Action Group) proporciona una interfaz capaz de controlar los registros internos del procesador, y de esta forma, acceder a las memorias de la plataforma y ejecutar un programa residente en una determinada posici<63>n de memoria.
\end{enumerate}
\item \textbf{Depuraci<EFBFBD>n} Una vez se descarga la aplicaci<63>n a la plataforma es necesario someterla a una serie de pruebas con el f<>n de probar su correcto funcionamiento. Esto se puede realizar con el depurador GNU (GDB) y una interfaz de comunicaci<63>n que puede ser un puerto serie o un adaptador de red.
\end{enumerate}
\subsubsection{Make}
Como vimoas anteriormente es necesario realizar una serie de pasos para poder descargar una aplicaci<63>n a una plataforma embebida. Debido a que las herramientas GNU solo poseen entrada por consola de comandos, es necesario escribir una serie de comandos cada vez que se realiza un cambio en el c<>digo fuente, lo cual resulta poco pr<70>ctico durante la etapa de desarrollo. Para realizar este proceso de forma autom<6F>tica, se cre<72> la herramienta make, la cual recibe como entrada un archivo que normalmente recibe el nombre de \textit{Makefile} o \textit{makefile}. La herramienta make ejecuta los comandos necesarios para realizar la compilaci<63>n, depuraci<63>n, o programaci<63>n, indicados en el archivo \textit{Makefile} o \textit{makefile}. Un ejemplo de este tipo de archivo se muestra a continuaci<63>n:
\begin{lstlisting}[numbers=left]
SHELL = /bin/sh
basetoolsdir = /home/at91/gcc-3.4.5-glibc-2.3.6/arm-softfloat-linux-gnu
bindir = ${basetoolsdir}/bin
libdir = ${basetoolsdir}/lib/gcc/arm-softfloat-linux-gnu/3.4.5
CC = arm-softfloat-linux-gnu-gcc
AS = arm-softfloat-linux-gnu-as
LD = arm-softfloat-linux-gnu-ld
OBJCOPY = arm-softfloat-linux-gnu-objcopy
CFLAGS =-mcpu=arm920t -I. -Wall
LDFLAGS =-L${libdir} -l gcc
OBJS = \
main.o \
debug_io.o \
at91rm9200_lowlevel.o \
p_string.o
ASFILES = arm_init.o
LIBS=${libdir}/
all: hello_world
hello_world: ${OBJS} ${ASFILES} ${LIBS}
${LD} -e 0 -o hello_world.elf -T linker.cfg ${ASFILES} ${OBJS} ${LDFLAGS}
${OBJCOPY} -O binary hello_world.elf hello_world.bin
clean:
rm -f *.o *~ hello_world.*
PREPROCESS.c = $(CC) $(CPPFLAGS) $(TARGET_ARCH) -E -Wp,-C,-dD,-dI
%.pp : %.c FORCE
$(PREPROCESS.c) $< > $@
\end{lstlisting}
En las l<>neas 3-5 se definen algunas variables globales que ser<65>n utilizadas a lo largo del archivo; en las l<>neas 7 - 10 se definen las herramientas de compilaci<63>n a utilizar, espec<65>ficamente los compiladores de C (CC), de assembler (AS), el linker (LD) y la utilidad objcopy. A partir de la l<>nea 15 se definen los objetos que forman parte del proyecto, en este caso: \textit{main.o, debug\_io.o, at91rm9200\_lowlevel.o y p\_string.o}; en la l<>nea 21 se definen los archivos en assembler que contiene el proyecto, para este caso \textit{arm\_init.o}. Las l<>neas 12 y 13 definen dos variables especiales que se pasan directamente al compilador de C (CFLAGS) y al liniker (LDFLAGS)
En las l<>neas 25, 27 y 31 aparecen unas etiquetas de la forma: \textit{nombre:} esta es la forma de definir reglas y permiten ejecutar de forma independiente el conjunto de instrucciones asociadas a ellas, por ejemplo, si se ejecuta el comando:
\\ \bigskip
\textit{make clean}\\ \bigskip
make ejecutar<61>:\\ \bigskip
\textit{rm -f *.o *~ hello\_world.*}
Observemos los comandos asociados a la etiqueta \textit{hello\_world:} En la misma l<>nea aparecen \textit{\${OBJS} \${ASFILES} \${LIBS}}, estos reciben el nombre de dependencias y le indican a la herramienta \textit{make} que antes de ejecutar los comandos asociados a este label, debe realizar las acciones necesarias para generar \textit{\${OBJS} \${ASFILES} \${LIBS}}, esto es: \textit{main.o, debug\_io.o, at91rm9200\_lowlevel.o, p\_string.o, arm\_init.o y libgcc.a}. \textit{make} tiene predefinidas una serie de reglas para compilar los archivos .c la regla es de la forma:
\begin{lstlisting}
.c.o:
$(CC) $(CFLAGS) -c $<
.c:
$(CC) $(CFLAGS) $@.c $(LDFLAGS) -o $@
\end{lstlisting}
Lo cual le indica a la herramienta make que para generar un archivo \textit{.o} a partir de uno \textit{.c} es necesario ejecutar \textit{\$(CC) \$(CFLAGS) -c \$<}; de aqui la importancia de definir bien la variable de entorno \textit{CC} cuando trabajamos con compiladores cruzados\footnote{Un compilador cruzado genera c<>digo para una plataforma diferente en la que se est<73> ejecutando, por ejemplo, genera ejecutables para ARM pero se ejecuta en un x86}. Hasta este punto al ejecutar el comando: \textit{make hello\_world}, \textit{make} realizar<61>a las siguientes operaciones: \\
\begin{lstlisting}
arm-softfloat-linux-gnu-gcc -mcpu=arm920t -I. -Wall -c -o main.o main.c
arm-softfloat-linux-gnu-gcc -mcpu=arm920t -I. -Wall -c -o debug_io.o debug_io.c
arm-softfloat-linux-gnu-gcc -mcpu=arm920t -I. -Wall -c -o at91rm9200_lowlevel.o
at91rm9200_lowlevel.c
arm-softfloat-linux-gnu-gcc -mcpu=arm920t -I. -Wall -c -o p_string.o p_string.c
arm-softfloat-linux-gnu-as -o arm_init.o arm_init.s
\end{lstlisting}
En las l<>neas 28 se realiza el proceso de enlazado; al \textit{linker} se le pasan los par<61>metros:
\begin{itemize}
\item \textbf{-e 0}: Punto de entrada , utilice 0 como s<>mbolo para el inicio de ejecuci<63>n.
\item \textbf{-o hello\_world.elf}: Nombre del archivo de salida \textit{hello\_world}
\item \textbf{-T linker.cfg}: Utilice el archivo de enlace \textit{linker.cfg}
\item \textbf{\${ASFILES} \${OBJS} \${LDFLAGS}}: Lista de objetos y librer<65>as para crear el ejecutable.
\end{itemize}
En la l<>nea 29 se utiliza la herramienta \textit{objcopy} para generar un archivo binario (\textit{-O binary}) con la informaci<63>n necesaria para cargar en una memoria no vol<6F>til. Esto se explicar<61> con mayor detalle m<>s adelante.
\subsubsection{El formato \textbf{ELF}}
El formato ELF (\textit{Executable and Linkable Format}) Es un st<73>ndard para objetos, librer<65>as y ejecutables y es el formato que genera las herramientas GNU. Como puede verse en la figura \ref{elf1} est<73> compuesto por varias secciones (\textit{link view}) o segmentos (\textit{execution view}). Si un programador est<73> interesado en obtener informaci<63>n de secciones sobre tablas de s<>mbolos, c<>digo ejecutable espec<65>fico o informaci<63>n de enlazado din<69>mico debe utilizar \textit{link view}. Pero si busca informaci<63>n sobre segmentos, como por ejemplo, la localizaci<63>n de los segmentos \textit{text} o \textit{data} debe utilizar \textit{execution view}. El encabezado describe el layout del archivo, proporcionando informaci<63>n de la forma de acceder a las secciones \cite{MLH98}.
\begin{figure}[h]
\begin{center} \includegraphics[scale=.4]{./images/ELF_Link_exec1} \end{center}
\caption{Formato ELF}\label{elf1}
\end{figure}
Las secciones pueden almacenar c<>digo ejecutable, datos, informaci<63>n de enlazado din<69>mico, datos de depuraci<63>n, tablas de s<>mbolos,comentarios, tablas de strings, y notas. Las secciones m<>s importantes son las siguientes:
\begin{itemize}
\item \textbf{.bss} Datos no inicializados. (RAM)
\item \textbf{.comment} Informaci<63>n de la versi<73>n.
\item \textbf{.data y .data1} Datos inicializados. (RAM)
\item \textbf{.debug} Informaci<63>n para depuraci<63>n simb<6D>lica.
\item \textbf{.dynamic} Informaci<63>n sobre enlace din<69>mico
\item \textbf{.dynstr} Strings necesarios para el enlacedin<69>mico
\item \textbf{.dynsym} Tabla de s<>mbolos utilizada para enlace din<69>mico.
\item \textbf{.fini} C<>digo de terminaci<63>n de proceso.
\item \textbf{.init} C<>digo de inicializaci<63>n de proceso.
\item \textbf{.line} Informaci<63>n de n<>mero de l<>nea para depuraci<63>n simb<6D>lica.
\item \textbf{.rodata y .rodta1} Datos de solo-lectura (ROM)
\item \textbf{.shstrtab} Nombres de secciones.
\item \textbf{.symtab} Tabla de s<>mbolos.
\item \textbf{.text} Instrucciones ejecutables (ROM)
\end{itemize}
Para aclarar un poco este concepto, escribamos una aplicaci<63>n sencilla:
\begin{lstlisting}
#include <stdio.h>
int global;
int global_1 = 1;
int main(void)
{
int i; // Variable no inicializada
int j = 2; // Variable inicializada
for(i=0; i<10; i++){
printf("Printing %d\n", i*j); // Caracteres constantes
j = j + 1;
global = i;
global_1 = i+j;
}
return 0;
}
\end{lstlisting}
Generemos el objeto compil<69>ndolo con el siguiente comando:
\textit{arm-none-eabi-gcc -c hello.c}
Examinemos que tipo de secciones tiene este ejecutable
\textit{arm-none-eabi-readelf -S hello.o}
\begin{lstlisting}
Section Headers:
[Nr] Name Type Addr Off Size ES Flg Lk Inf Al
[ 0] NULL 00000000 000000 000000 00 0 0 0
[ 1] .text PROGBITS 00000000 000034 00009c 00 AX 0 0 4
[ 2] .rel.text REL 00000000 000484 000020 08 9 1 4
[ 3] .data PROGBITS 00000000 0000d0 000004 00 WA 0 0 4
[ 4] .bss NOBITS 00000000 0000d4 000000 00 WA 0 0 1
[ 5] .rodata PROGBITS 00000000 0000d4 000010 00 A 0 0 4
[ 6] .comment PROGBITS 00000000 0000e4 00004d 00 0 0 1
[ 7] .ARM.attributes ARM_ATTRIBUTES 00000000 000131 00002e 00 0 0 1
[ 8] .shstrtab STRTAB 00000000 00015f 000051 00 0 0 1
[ 9] .symtab SYMTAB 00000000 000368 0000f0 10 10 11 4
[10] .strtab STRTAB 00000000 000458 00002b 00 0 0 1
Key to Flags:
W (write), A (alloc), X (execute), M (merge), S (strings)
I (info), L (link order), G (group), x (unknown)
O (extra OS processing required) o (OS specific), p (processor specific)
\end{lstlisting}
La secci<63>n \textit{.text}, como se dijo anteriormente contiene las instrucciones ejecutables, por esta raz<61>n se marca como ejecutable \textit{``X''} en la columna \textit{Flg}. Es posible ver las instrucciones que se ejecutan en esta secci<63>n:
\textit{arm-none-eabi-objdump -d -j .text hello.o}
\begin{lstlisting}
00000000 <main>:
0: e92d4800 stmdb sp!, {fp, lr}
4: e28db004 add fp, sp, #4 ; 0x4
8: e24dd008 sub sp, sp, #8 ; 0x8
c: e3a03002 mov r3, #2 ; 0x2
10: e50b3008 str r3, [fp, #-8]
14: e3a03000 mov r3, #0 ; 0x0
18: e50b300c str r3, [fp, #-12]
1c: ea000013 b 70 <main+0x70>
20: e51b200c ldr r2, [fp, #-12]
24: e51b3008 ldr r3, [fp, #-8]
28: e0030392 mul r3, r2, r3
2c: e59f005c ldr r0, [pc, #92] ; 90 <.text+0x90>
30: e1a01003 mov r1, r3
34: ebfffffe bl 0 <printf>
38: e51b3008 ldr r3, [fp, #-8]
3c: e2833001 add r3, r3, #1 ; 0x1
40: e50b3008 str r3, [fp, #-8]
44: e59f2048 ldr r2, [pc, #72] ; 94 <.text+0x94>
48: e51b300c ldr r3, [fp, #-12]
4c: e5823000 str r3, [r2]
50: e51b200c ldr r2, [fp, #-12]
54: e51b3008 ldr r3, [fp, #-8]
58: e0822003 add r2, r2, r3
5c: e59f3034 ldr r3, [pc, #52] ; 98 <.text+0x98>
60: e5832000 str r2, [r3]
64: e51b300c ldr r3, [fp, #-12]
68: e2833001 add r3, r3, #1 ; 0x1
6c: e50b300c str r3, [fp, #-12]
70: e51b300c ldr r3, [fp, #-12]
74: e3530009 cmp r3, #9 ; 0x9
78: daffffe8 ble 20 <main+0x20>
7c: e3a03000 mov r3, #0 ; 0x0
80: e1a00003 mov r0, r3
84: e24bd004 sub sp, fp, #4 ; 0x4
88: e8bd4800 ldmia sp!, {fp, lr}
8c: e12fff1e bx lr
\end{lstlisting}
La secci<63>n \textit{.data} mantiene las variables inicializadas, y contiene:
\textit{arm-none-eabi-objdump -d -j .data hello.o}
\begin{lstlisting}
00000000 <global_1>:
0: 01 00 00 00
\end{lstlisting}
Como vemos, la secci<63>n \textit{.data} contiene \'unicamente el valor de inicializaci\'on de la variable \textit{global\_1} (1) y no muestra informaci<63>\'on acerca de la variable \textit{j}, esto se debe a que la informaci\'on est\'a en el \textit{stack} del proceso. Si observamos el contenido de la secci<63>n \textit{.text} observamos que esta variable es asignada en tiempo de ejecuci<63>n, en la l<>nea \textit{0c:}
\begin{lstlisting}
0c: e3a03002 mov r3, #2 ; 0x2
10: e50b3008 str r3, [fp, #-8]
\end{lstlisting}
se ve la asignaci<63>n de esta variable.
La secci<63>n \textit{.bss} mantiene la informaci\'on de las variables no incializadas:
\textit{arm-none-eabi-objdump -d -j .bss hello}
\begin{lstlisting}
000145c4 <global>:
145c4: 00000000
\end{lstlisting}
En Linux todas las variables no inicializadas, se inicializadan en cero.
La secci<63>n \textit{.rodata} mantiene los datos que no cambian durante la ejecuci<63>n del programa, es decir, de solo lectura, si examinamos esta secci<63>n obtenemos:
\textit{hexdump -C hello.o | grep -i 000000d0} (la secci<63>n \textit{.rodata} comienza en la posici<63>n de memoria 0xd4)
\begin{lstlisting}
000000d0 01 00 00 00 50 72 69 6e 74 69 6e 67 20 25 64 0a |....Printing %d.|
000000e0 00 00 00 00 00 47 43 43 3a 20 28 43 6f 64 65 53 |.....GCC: (CodeS|
\end{lstlisting}
Observamos que en el archivo se almacena la cadena de caracteres \textit{Printing \%d\\n} la cual no se modifica durante la ejecuci<63>n del programa.
\subsubsection{Linker Script}
Como vimos anteriormente, el \textit{linker} es el encargado de agrupar todos los archivos objeto \textit{.o}, y las librer<65>as necesarias para crear el ejecutable, este \textit{linker} permite definir donde ser<65>n ubicados los diferentes segmentos del archivo ELF, por medio de un archivo de enlace \textit{linker script}. De esta forma podemos ajustar el ejecutable a plataformas con diferentes configuraciones de memoria.Esto brinda un grado mayor de flexibilidaad de la cadena de herramientas GNU. Cuando se dispone de un sistema operativo como Linux no es necesario definir este archivo, ya que el sistema operativo se encarga de guardar las secciones en el lugar indicado, sin embargo, es necesario tenerlo presente ya que como veremos m<>s adelante existe un momento en el que el sistema operativo no ha sido cargado en la plataforma y las aplicaciones que se ejecuten deben proporcionar esta informaci<63>n. A continuaci<63>n se muestra un ejemplo de este archivo:
\begin{lstlisting}
/* identify the Entry Point (_vec_reset is defined in file crt.s) */
ENTRY(_vec_reset)
/* specify the memory areas */
MEMORY
{
flash : ORIGIN = 0, LENGTH = 256K /* FLASH EPROM */
ram : ORIGIN = 0x00200000, LENGTH = 64K /* static RAM area */
}
/* define a global symbol _stack_end */
_stack_end = 0x20FFFC;
/* now define the output sections */
SECTIONS
{
. = 0; /* set location counter to address zero */
.text : /* collect all sections that should go into FLASH after startup */
{
*(.text) /* all .text sections (code) */
*(.rodata) /* all .rodata sections (constants, strings, etc.) */
*(.rodata*) /* all .rodata* sections (constants, strings, etc.) */
*(.glue_7) /* all .glue_7 sections (no idea what these are) */
*(.glue_7t) /* all .glue_7t sections (no idea what these are) */
_etext = .; /* define a global symbol _etext just after the last code byte */
} >flash /* put all the above into FLASH */
.data : /* collect all initialized .data sections that go into RAM */
{
_data = .; /* create a global symbol marking the start of the .data section */
*(.data) /* all .data sections */
_edata = .; /* define a global symbol marking the end of the .data section */
} >ram AT >flash /* put all the above into RAM (but load the LMA initializer copy into FLASH) */
.bss : /* collect all uninitialized .bss sections that go into RAM */
{
_bss_start = .; /* define a global symbol marking the start of the .bss section */
*(.bss) /* all .bss sections */
} >ram /* put all the above in RAM (it will be cleared in the startup code */
. = ALIGN(4); /* advance location counter to the next 32-bit boundary */
_bss_end = . ; /* define a global symbol marking the end of the .bss section */
}
_end = .; /* define a global symbol marking the end of application RAM */
\end{lstlisting}
En las primeras l<>neas del archivo aparece la declaraci<63>n de las memorias de la plataforma, en este ejemplo tenemos una memoria RAM de 64kB que comienza en la posici<63>n de memoria 0x00200000 y una memoria flash de 256k que comienza en la posici<63>n 0x0. A continuacion se definen las secciones y el lugar donde ser<65>n almacenadas; En este caso, las secciones \textit{.text} (c<>digo ejecutable) y \textit{.rodata} (datos de solo lectura) se almacenan en una memoria no vol<6F>til la flash. Cuando el sistema sea energizado el procesador ejecutar<61> el c<>digo almacenado en su memoria no vol<6F>til. Las secciones \textit{.data} (variables inicializadas) y \textit{.bss} (variables no inicializadas) se almacenar<61>n en la memoria vol<6F>til RAM, ya que el acceso a las memorias no vol<6F>tiles son m<>s lentas y tienen ciclos de lectura/escritura finitos.
En algunos SoCs no se dispone de una memoria no vol<6F>til, por lo que es necesario que la aplicaci<63>n sea cargada por completo en la RAM. Algunos desarrolladores prefieren almacenar y ejecutar sus aplicaciones en las memorias vol<6F>tiles durante la etapa de desarrollo, debido a que la programaci<63>n de las memorias no vol<6F>tiles toman mucho m<>s tiempo. Obviamente una vez finalizada la etapa de desarrollo las aplicaciones deben ser almacenadas en memorias no vol<6F>tiles.
\section{Herramientas hardware}
En esta subsecci<63>n se realizar<61> una breve descripci<63>n de los dispositivos semiconductores m<>s utilizados para la implementaci<63>n de dispositivos digitales.
\subsubsection{SoC}
La Figura \ref{at91rm} muestra la arquitectura de un SoC actual, espec<65>ficamente del AT91RM920 de Atmel. En este diagrama podemos observar el n<>cleo central un procesador ARM920T de 180MHz y los perif<69>ricos asociados a <20>l. En la actualidad podemos encontrar una gran variedad de SoC dise<73>ados para diferentes aplicaciones: Multimedia, Comunicaciones, Asistentes Digitales; los perif<69>ricos incluidos en cada SoC buscan minimizar el n<>mero de componentes externos, y de esta forma reducir los costos. Este SoC en particular fu<66> uno de los primeros que dise<73>o ATMEL y est<73> enfocado a tareas en las que se requiere una conexi<78>n de red. Dentro de los perif<69>ricos encontramos:
\begin{itemize}
\item Controlador para memorias: NAND flash, DataFlash, SDRAM, SD/MMC
\item Puerto USB 2.0 host.
\item Puerto I2C
\item Interfaz Ethernet 10/100.
\item Interfaz high speed USB 2.0
\item 4 Puertos SPI.
\item 2 puertos seriales (RS232).
\item Soporte JTAG.
\item Interf<72>z de Bus externo (EBI).
\end{itemize}
\begin{figure}[H]
\begin{center} \includegraphics[scale=.7]{./images/at91rm9200} \end{center}
\caption{SoC AT91RM9200 fuente: Hoja de Especificaciones AT91RM9200, ATMEL} \label{at91rm}
\end{figure}
Existen una serie de perif<69>ricos que son indispensables en todo Sistema Embebido, los cuales facilitan la programaci<63>n de aplicaciones y la depuraci<63>n de las mismas. A continuaci<63>n se realizar<61> una descripci<63>n de los diferentes perif<69>ricos que se encuentran disponibles en este SoC, indicando los que fueron utilizados en la plataforma de desarrollo.
\subsubsection{Memorias Vol<6F>tiles}
Como se estudi<64> anteriormente existen secciones del ejecutable que deben ser almacenadas en memorias vol<6F>tiles o en memorias no vol<6F>tiles. Debido a esto la mayor<6F>a de los SoC incluyen perif<69>ricos dedicados a controlar diferentes tipos de memoria, las memorias vol<6F>tiles son utilizadas como memoria de acceso aleatorio (RAM) gracias a su bajo tiempo de accesso y al ilimitado n<>mero de ciclos de lectura/escritura.
El tipo de memoria m<>s utilizado en los sistemas embebidos actuales es la memoria SDRAM; la cual est<73> organizada como una matriz de celdas, con un n<>mero de bits dedicados al direccionamiento de las filas y un n<>mero dedicado a direccionar columnas (ver Figura \ref{sdram_basics}).
\begin{figure}[H]
\begin{center} \includegraphics[scale=.6]{./images/sdram_basics} \end{center}
\caption{Diagrama de Bloques de una memoria SDRAM fuente: Hoja de Especificaciones MT48LC16M16, Micron Technology} \label{sdram_basics}
\end{figure}
Un ejemplo simplificado de una operaci<63>n de lectura es el siguiente: Una posici<63>n de memoria se determina colocando la direcci<63>n de la fila y la de la columna en las l<>neas de direcci<63>n de fila y columna respectivamente, un tiempo despu<70>s el dato almacenado aparecer<65> en el bus de datos. El procesador coloca la direcci<63>n de la fila en el bus de direcciones y despu<70>s activa la se<73>al \textit{RAS} (Row Access Strobe). Despu<70>s de un retardo de tiempo predeterminado para permitir que el circuito de la SDRAM capture la direcci<63>n de la fila, el procesador coloca la direcci<63>n de la columna en el bus de direcciones y activa la se<73>al \textit{CAS} (Column Access Strobe). Una celda de memoria SDRAM esta compuesta por un transistor y un condensador; el transistor suministra la carga y el condensador almacena el estado de cada celda, esta carga en el condensador desaparece con el tiempo, raz<61>n por la cual es necesario recargar estos condensadores peri<72>dicamente, este proceso recibe el nombre de \textit{Refresco}. Un ciclo de refresco es un ciclo especial en el que no se escribe ni se lee informaci<63>n, solo se recargan los condensadores para mantener la informaci<63>n. El perif<69>rico que controla la SDRAM est<73> encargado de garantizar los ciclos de refresco de acuerdo con los requerimientos de la SDRAM \cite{CH06}.
\subsubsection{Memorias No Vol<6F>tiles}
La memorias no vol<6F>tiles almacenan por largos per<65>odos de tiempo informaci<63>n necesaria para la operaci<63>n de un Sistema Embebido, pueden ser vistos como discos duros de estado s<>lido; existen dos tipos de memoria las memorias NOR y las NAND; las dos poseen la capacidad de ser escritas y borradas utilizando control de software, con lo que no es necesario utilizar programadores externos y puedens er modificadas una vez instaladas en el circuito integrado. Una desventaja de estas memorias es que los tiempos de escritura y borrado son muy largos en comparaci<63>n con los requeridos por las memorias RAM.
Las memorias NOR poseen buses de datos y direcci<63>n, con lo que es posible acceder de forma f<>cil a cada byte almacenado en ella. Los bits datos pueden ser cambiados de 0 a 1 utilizando el control de software un byte a la vez, sin embargo, para cambiar un bit de 1 a 0 es necesario borrar una serie de unidades de borrado que reciben el nombre de bloques, lo que permite reducir el tiempo de borrado de la memoria. Debido a que el borrado y escritura de una memoria ROM se puede realizar utilizando el control software (ver Figura \ref{nor_prog}) no es necesario contar con un perif<69>rico especializado para su manejo.
\begin{figure}[H]
\begin{center} \includegraphics[scale=.6]{./images/nor_prog} \end{center}
\caption{Ciclos de escritura y borrado de una memoria flash NOR} \label{nor_prog}
\end{figure}
Las memorias NOR son utilizadas en aplicaciones donde se necesiten altas velocidades de lectura y baja densidad, debido a que los tiempos de escritura y lectura son muy grandes se utilizan como memorias ROM. Las memorias NAND disminuyen los tiempos de escritura y aumentan la capacidad de almacenamiento, ideales para aplicaciones donde se requiera almacenamiento de informaci<63>n. Adicionalmente las memorias NAND consumen menos potencia que las memorias NAND, por esta raz<61>n este tipo de memorias son utilizadas en casi todos los dispositivos de almacenamiento modernos como las memorias SD y las memorias USB, los cuales integran una memoria NAND con un circuito encargado de controlarlas e implementar el protocolo de comunicaci<63>n. A diferencia de las flash tipo NOR, los dispositivos NAND se acceden de forma serial utilizando interfaces complejas; su operaci<63>n se asemeja a un disco duro tradicional. Se accede a la informaci<63>n utilizando bloques (m<>s peque<75>os que los bloques NOR). Los ciclos de escritura de las flash NAND son mayores en un orden de magnitud que los de las memorias NOR.
Un problema al momento de trabajar con las memorias tipo NAND es que requieren el uso de un \textit{manejo de bloques defectuosos}, esto es necesario ya que las celdas de memoria pueden da<64>arse de forma espont<6E>nea durante la operaci<63>n normal. Debido a esto se debe tener un determinado n<>mero de bloques que se encargen de almacenar tablas de mapeo para manejar los bloques defectuosos; o puede hacerse un chequeo en cada inicializaci<63>n del sistema de toda la RAM para actualizar esta lista de sectores defectuosos. El algoritmo de ECC (Error-Correcting Code) debe ser cap<61>z de corregir errores tan peque<75>os como un bit de cada 2048 bits, hasta 22 bits de cada 2048. Este algor<6F>tmo es capaz de detectar bloques defectuosos en la fase de programac<61><63>n comparando la informaci<63>n almacenada con la que debe ser almacenada (verificaci<63>n), si encuentra un error marca el bloque como defectuoso y utiliza un bloque sin defactos para almacenar la informaci<63>n.
La tabla \ref{flash_comp} resume las principales caracter<65>sticas de los diferentes tipos de memoria flash.
\begin{center}
\begin{table}[ht]
\begin{tabular}{|l|c|c|c|}
\hline
& \textbf{SLC NAND} & \textbf{MLC NAND} & MLC NOR \\ \hline
Densidad & 512Mbits - 4GBits & 1Gbits - 16GBits & 16MBits - 1GBit \\ \hline
Velocidad de Lectura & 24MB/s & 18.6MB/s & 103MB/s \\ \hline
Velocidad de escritura& 8 MB/s & 2.4MB/s & 0,47MB/s \\ \hline
Tiempo de borrado & 2ms & 2ms & 900ms \\ \hline
Interfaz & Acceso Indirecto & Acceso Indirecto & Acceso Aleatorio\\ \hline
Aplicaci<63>n & Almacenamiento & Almacenamiento & Solo lectura \\ \hline
\end{tabular}
\caption{Cuadro de comparaci<63>n de las memorias flash NAND y NOR} \label{flash_comp}
\end{table}
\end{center}
Adicionalmente, se encuentran dispoibles las memorias DATAFLASH, estos dispositivos son b<>sicamente una memoria flash tipo NOR con una interfaz SPI, permite una velocidad de lectura de hasta 66MHz utilizando solamente 4 pines para la comunicaci<63>n con el procesador.

21
course/.docs/cambio_categoria/embedded_book.aux Normal file
View File

@@ -0,0 +1,21 @@
\relax
\catcode`"\active
\catcode`<\active
\catcode`>\active
\@nameuse{es@quoting}
\bibstyle{unsrt}
\select@language{spanish}
\@writefile{toc}{\select@language{spanish}}
\@writefile{lof}{\select@language{spanish}}
\@writefile{lot}{\select@language{spanish}}
\citation{SR08}
\citation{LSC08}
\bibdata{biblio_EL}
\@writefile{toc}{\contentsline {chapter}{\numberline {1}Sistema en un Chip (SoC)}{3}}
\@writefile{lof}{\addvspace {10\p@ }}
\@writefile{lot}{\addvspace {10\p@ }}
\@writefile{toc}{\contentsline {section}{\numberline {1.1}Arquitectura}{3}}
\@writefile{lof}{\contentsline {figure}{\numberline {1.1}{\ignorespaces Arquitectura m\IeC {\'\i }nima de un SoC}}{4}}
\newlabel{min_soc_arch}{{1.1}{4}}
\bibcite{SR08}{1}
\bibcite{LSC08}{2}

15
course/.docs/cambio_categoria/embedded_book.bbl Normal file
View File

@@ -0,0 +1,15 @@
\begin{thebibliography}{1}
\bibitem{SR08}
{S. Rhoads}.
\newblock Plasma - most {MIPS} {I}({TM}) opcodes.
\newblock URL: http://opencores.org/project,plasma, 2008.
\bibitem{LSC08}
{Lattice Semiconductor Corporation}.
\newblock Lattice{M}ico32 {O}pen, {F}ree 32-{B}it {S}oft {P}rocessor.
\newblock URL:
http://www.latticesemi.com/products/intellectualproperty/ipcores/mico32/inde%
x.cfm, 2008.
\end{thebibliography}

45
course/.docs/cambio_categoria/embedded_book.blg Normal file
View File

@@ -0,0 +1,45 @@
This is BibTeX, Version 0.99c (TeX Live 2009/Debian)
The top-level auxiliary file: embedded_book.aux
The style file: unsrt.bst
Database file #1: biblio_EL.bib
You've used 2 entries,
1791 wiz_defined-function locations,
456 strings with 3823 characters,
and the built_in function-call counts, 278 in all, are:
= -- 22
> -- 8
< -- 0
+ -- 4
- -- 2
* -- 4
:= -- 49
add.period$ -- 6
call.type$ -- 2
change.case$ -- 2
chr.to.int$ -- 0
cite$ -- 2
duplicate$ -- 10
empty$ -- 37
format.name$ -- 2
if$ -- 63
int.to.chr$ -- 0
int.to.str$ -- 2
missing$ -- 0
newline$ -- 13
num.names$ -- 2
pop$ -- 12
preamble$ -- 1
purify$ -- 0
quote$ -- 0
skip$ -- 6
stack$ -- 0
substring$ -- 0
swap$ -- 2
text.length$ -- 0
text.prefix$ -- 0
top$ -- 0
type$ -- 0
warning$ -- 0
while$ -- 2
width$ -- 3
write$ -- 22

BIN
course/.docs/cambio_categoria/embedded_book.dvi Normal file
View File

Binary file not shown.

380
course/.docs/cambio_categoria/embedded_book.log Normal file
View File

@@ -0,0 +1,380 @@
This is pdfTeX, Version 3.1415926-1.40.10 (TeX Live 2009/Debian) (format=pdflatex 2010.5.7) 11 SEP 2010 21:52
entering extended mode
restricted \write18 enabled.
%&-line parsing enabled.
**embedded_book.tex
(./embedded_book.tex
LaTeX2e <2009/09/24>
Babel <v3.8l> and hyphenation patterns for english, usenglishmax, dumylang, noh
yphenation, loaded.
(/usr/share/texmf-texlive/tex/latex/base/report.cls
Document Class: report 2007/10/19 v1.4h Standard LaTeX document class
(/usr/share/texmf-texlive/tex/latex/base/size10.clo
File: size10.clo 2007/10/19 v1.4h Standard LaTeX file (size option)
)
\c@part=\count79
\c@chapter=\count80
\c@section=\count81
\c@subsection=\count82
\c@subsubsection=\count83
\c@paragraph=\count84
\c@subparagraph=\count85
\c@figure=\count86
\c@table=\count87
\abovecaptionskip=\skip41
\belowcaptionskip=\skip42
\bibindent=\dimen102
)
(/usr/share/texmf-texlive/tex/latex/base/fontenc.sty
Package: fontenc 2005/09/27 v1.99g Standard LaTeX package
)
(/usr/share/texmf-texlive/tex/latex/base/inputenc.sty
Package: inputenc 2008/03/30 v1.1d Input encoding file
\inpenc@prehook=\toks14
\inpenc@posthook=\toks15
(/usr/share/texmf-texlive/tex/latex/base/latin1.def
File: latin1.def 2008/03/30 v1.1d Input encoding file
))
(/usr/share/texmf-texlive/tex/generic/babel/babel.sty
Package: babel 2008/07/06 v3.8l The Babel package
(/usr/share/texmf-texlive/tex/generic/babel/spanish.ldf
Language: spanish.ldf 2009/01/02 v5.0h Spanish support from the babel system
(/usr/share/texmf-texlive/tex/generic/babel/babel.def
File: babel.def 2008/07/06 v3.8l Babel common definitions
\babel@savecnt=\count88
\U@D=\dimen103
)
Package babel Warning: No hyphenation patterns were loaded for
(babel) the language `Spanish'
(babel) I will use the patterns loaded for \language=0 instead.
\l@spanish = a dialect from \language0
\es@datefmt=\count89
\es@quottoks=\toks16
\es@quotdepth=\count90
Package babel Info: Making " an active character on input line 492.
Package babel Info: Making . an active character on input line 585.
Package babel Info: Making < an active character on input line 630.
Package babel Info: Making > an active character on input line 630.
)) (/usr/share/texmf-texlive/tex/latex/graphics/graphicx.sty
Package: graphicx 1999/02/16 v1.0f Enhanced LaTeX Graphics (DPC,SPQR)
(/usr/share/texmf-texlive/tex/latex/graphics/keyval.sty
Package: keyval 1999/03/16 v1.13 key=value parser (DPC)
\KV@toks@=\toks17
)
(/usr/share/texmf-texlive/tex/latex/graphics/graphics.sty
Package: graphics 2009/02/05 v1.0o Standard LaTeX Graphics (DPC,SPQR)
(/usr/share/texmf-texlive/tex/latex/graphics/trig.sty
Package: trig 1999/03/16 v1.09 sin cos tan (DPC)
)
(/etc/texmf/tex/latex/config/graphics.cfg
File: graphics.cfg 2009/08/28 v1.8 graphics configuration of TeX Live
)
Package graphics Info: Driver file: pdftex.def on input line 91.
(/usr/share/texmf-texlive/tex/latex/pdftex-def/pdftex.def
File: pdftex.def 2009/08/25 v0.04m Graphics/color for pdfTeX
\Gread@gobject=\count91
))
\Gin@req@height=\dimen104
\Gin@req@width=\dimen105
)
(/usr/share/texmf-texlive/tex/latex/psnfss/times.sty
Package: times 2005/04/12 PSNFSS-v9.2a (SPQR)
)
(/usr/share/texmf-texlive/tex/latex/colortbl/colortbl.sty
Package: colortbl 2001/02/13 v0.1j Color table columns (DPC)
(/usr/share/texmf-texlive/tex/latex/tools/array.sty
Package: array 2008/09/09 v2.4c Tabular extension package (FMi)
\col@sep=\dimen106
\extrarowheight=\dimen107
\NC@list=\toks18
\extratabsurround=\skip43
\backup@length=\skip44
)
(/usr/share/texmf-texlive/tex/latex/graphics/color.sty
Package: color 2005/11/14 v1.0j Standard LaTeX Color (DPC)
(/etc/texmf/tex/latex/config/color.cfg
File: color.cfg 2007/01/18 v1.5 color configuration of teTeX/TeXLive
)
Package color Info: Driver file: pdftex.def on input line 130.
)
\everycr=\toks19
\minrowclearance=\skip45
)
(/usr/share/texmf-texlive/tex/latex/tools/multicol.sty
Package: multicol 2008/12/05 v1.6h multicolumn formatting (FMi)
\c@tracingmulticols=\count92
\mult@box=\box26
\multicol@leftmargin=\dimen108
\c@unbalance=\count93
\c@collectmore=\count94
\doublecol@number=\count95
\multicoltolerance=\count96
\multicolpretolerance=\count97
\full@width=\dimen109
\page@free=\dimen110
\premulticols=\dimen111
\postmulticols=\dimen112
\multicolsep=\skip46
\multicolbaselineskip=\skip47
\partial@page=\box27
\last@line=\box28
\mult@rightbox=\box29
\mult@grightbox=\box30
\mult@gfirstbox=\box31
\mult@firstbox=\box32
\@tempa=\box33
\@tempa=\box34
\@tempa=\box35
\@tempa=\box36
\@tempa=\box37
\@tempa=\box38
\@tempa=\box39
\@tempa=\box40
\@tempa=\box41
\@tempa=\box42
\@tempa=\box43
\@tempa=\box44
\@tempa=\box45
\@tempa=\box46
\@tempa=\box47
\@tempa=\box48
\@tempa=\box49
\c@columnbadness=\count98
\c@finalcolumnbadness=\count99
\last@try=\dimen113
\multicolovershoot=\dimen114
\multicolundershoot=\dimen115
\mult@nat@firstbox=\box50
\colbreak@box=\box51
)
(/usr/share/texmf-texlive/tex/latex/multirow/multirow.sty
\bigstrutjot=\dimen116
)
(/usr/share/texmf-texlive/tex/latex/pdfpages/pdfpages.sty
Package: pdfpages 2009/02/07 v0.4g Insert pages of external PDF documents (AM)
(/usr/share/texmf-texlive/tex/latex/base/ifthen.sty
Package: ifthen 2001/05/26 v1.1c Standard LaTeX ifthen package (DPC)
)
(/usr/share/texmf-texlive/tex/latex/tools/calc.sty
Package: calc 2007/08/22 v4.3 Infix arithmetic (KKT,FJ)
\calc@Acount=\count100
\calc@Bcount=\count101
\calc@Adimen=\dimen117
\calc@Bdimen=\dimen118
\calc@Askip=\skip48
\calc@Bskip=\skip49
LaTeX Info: Redefining \setlength on input line 76.
LaTeX Info: Redefining \addtolength on input line 77.
\calc@Ccount=\count102
\calc@Cskip=\skip50
)
(/usr/share/texmf-texlive/tex/latex/eso-pic/eso-pic.sty
Package: eso-pic 2006/07/14 v1.1d eso-pic (RN)
(/usr/share/texmf-texlive/tex/latex/ms/everyshi.sty
Package: everyshi 2001/05/15 v3.00 EveryShipout Package (MS)
))
(/usr/share/texmf-texlive/tex/latex/pdfpages/pppdftex.def
File: pppdftex.def 2009/02/07 v0.4g Pdfpages driver for pdfTeX (AM)
)
\AM@pagebox=\box52
\AM@toc@title=\toks20
\c@AM@survey=\count103
\AM@templatesizebox=\box53
)
(/usr/share/texmf-texlive/tex/latex/graphics/lscape.sty
Package: lscape 2000/10/22 v3.01 Landscape Pages (DPC)
)
(/usr/share/texmf-texlive/tex/latex/listings/listings.sty
\lst@mode=\count104
\lst@gtempboxa=\box54
\lst@token=\toks21
\lst@length=\count105
\lst@currlwidth=\dimen119
\lst@column=\count106
\lst@pos=\count107
\lst@lostspace=\dimen120
\lst@width=\dimen121
\lst@newlines=\count108
\lst@lineno=\count109
\lst@maxwidth=\dimen122
(/usr/share/texmf-texlive/tex/latex/listings/lstmisc.sty
File: lstmisc.sty 2007/02/22 1.4 (Carsten Heinz)
\c@lstnumber=\count110
\lst@skipnumbers=\count111
\lst@framebox=\box55
)
(/usr/share/texmf-texlive/tex/latex/listings/listings.cfg
File: listings.cfg 2007/02/22 1.4 listings configuration
))
Package: listings 2007/02/22 1.4 (Carsten Heinz)
(/usr/share/texmf-texlive/tex/latex/listings/lstlang1.sty
File: lstlang1.sty 2004/09/05 1.3 listings language file
)
(/usr/share/texmf-texlive/tex/latex/listings/lstmisc.sty
File: lstmisc.sty 2007/02/22 1.4 (Carsten Heinz)
)
(/usr/share/texmf-texlive/tex/latex/tools/longtable.sty
Package: longtable 2004/02/01 v4.11 Multi-page Table package (DPC)
\LTleft=\skip51
\LTright=\skip52
\LTpre=\skip53
\LTpost=\skip54
\LTchunksize=\count112
\LTcapwidth=\dimen123
\LT@head=\box56
\LT@firsthead=\box57
\LT@foot=\box58
\LT@lastfoot=\box59
\LT@cols=\count113
\LT@rows=\count114
\c@LT@tables=\count115
\c@LT@chunks=\count116
\LT@p@ftn=\toks22
) (./embedded_book.aux)
\openout1 = `embedded_book.aux'.
LaTeX Font Info: Checking defaults for OML/cmm/m/it on input line 44.
LaTeX Font Info: ... okay on input line 44.
LaTeX Font Info: Checking defaults for T1/cmr/m/n on input line 44.
LaTeX Font Info: ... okay on input line 44.
LaTeX Font Info: Checking defaults for OT1/cmr/m/n on input line 44.
LaTeX Font Info: ... okay on input line 44.
LaTeX Font Info: Checking defaults for OMS/cmsy/m/n on input line 44.
LaTeX Font Info: ... okay on input line 44.
LaTeX Font Info: Checking defaults for OMX/cmex/m/n on input line 44.
LaTeX Font Info: ... okay on input line 44.
LaTeX Font Info: Checking defaults for U/cmr/m/n on input line 44.
LaTeX Font Info: ... okay on input line 44.
LaTeX Font Info: Try loading font information for OT1+ptm on input line 44.
(/usr/share/texmf-texlive/tex/latex/psnfss/ot1ptm.fd
File: ot1ptm.fd 2001/06/04 font definitions for OT1/ptm.
)
(/usr/share/texmf/tex/context/base/supp-pdf.mkii
[Loading MPS to PDF converter (version 2006.09.02).]
\scratchcounter=\count117
\scratchdimen=\dimen124
\scratchbox=\box60
\nofMPsegments=\count118
\nofMParguments=\count119
\everyMPshowfont=\toks23
\MPscratchCnt=\count120
\MPscratchDim=\dimen125
\MPnumerator=\count121
\everyMPtoPDFconversion=\toks24
) ABD: EveryShipout initializing macros
\c@lstlisting=\count122
(./title.tex
LaTeX Font Info: External font `cmex10' loaded for size
(Font) <12> on input line 11.
LaTeX Font Info: External font `cmex10' loaded for size
(Font) <8> on input line 11.
LaTeX Font Info: External font `cmex10' loaded for size
(Font) <6> on input line 11.
[1
{/var/lib/texmf/fonts/map/pdftex/updmap/pdftex.map}]
Underfull \hbox (badness 10000) in paragraph at lines 16--20
[]
LaTeX Font Info: Try loading font information for OMS+ptm on input line 23.
(/usr/share/texmf-texlive/tex/latex/psnfss/omsptm.fd
File: omsptm.fd
)
LaTeX Font Info: Font shape `OMS/ptm/m/n' in size <10> not available
(Font) Font shape `OMS/cmsy/m/n' tried instead on input line 23.
LaTeX Font Info: Try loading font information for OT1+pcr on input line 24.
(/usr/share/texmf-texlive/tex/latex/psnfss/ot1pcr.fd
File: ot1pcr.fd 2001/06/04 font definitions for OT1/pcr.
)
Underfull \hbox (badness 10000) in paragraph at lines 23--25
[]
Underfull \hbox (badness 10000) in paragraph at lines 26--30
[]
Underfull \hbox (badness 10000) in paragraph at lines 31--34
[]
Underfull \hbox (badness 10000) in paragraph at lines 35--36
[]
[1])
LaTeX Font Info: Font shape `OT1/ptm/bx/n' in size <24.88> not available
(Font) Font shape `OT1/ptm/b/n' tried instead on input line 47.
(./embedded_book.toc
LaTeX Font Info: Font shape `OT1/ptm/bx/n' in size <10> not available
(Font) Font shape `OT1/ptm/b/n' tried instead on input line 2.
LaTeX Font Info: External font `cmex10' loaded for size
(Font) <7> on input line 3.
LaTeX Font Info: External font `cmex10' loaded for size
(Font) <5> on input line 3.
)
\tf@toc=\write3
\openout3 = `embedded_book.toc'.
(./chapter2.tex [2
]
Cap\'{\i }tulo 1.
LaTeX Font Info: Font shape `OT1/ptm/bx/n' in size <20.74> not available
(Font) Font shape `OT1/ptm/b/n' tried instead on input line 1.
Overfull \hbox (2.1569pt too wide) in paragraph at lines 3--4
[]\OT1/ptm/m/n/10 En es-ta sec-ci[]on es-tu-di-are-mos la ar-qui-tec-tura b[]as
ica de un SoC mod-er-no, com-po-nentes, fun-cionamien-
[]
LaTeX Font Info: Font shape `OT1/ptm/bx/n' in size <14.4> not available
(Font) Font shape `OT1/ptm/b/n' tried instead on input line 6.
<./images/Computer-simple.png, id=15, 488.57532pt x 328.22626pt>
File: ./images/Computer-simple.png Graphic file (type png)
<use ./images/Computer-simple.png>) (./embedded_book.bbl [3
] [4 <./images/Computer-simple.png (PNG copy)>]) [5
] (./embedded_book.aux) )
Here is how much of TeX's memory you used:
4384 strings out of 495061
58680 string characters out of 1182622
142655 words of memory out of 3000000
7487 multiletter control sequences out of 15000+50000
24721 words of font info for 48 fonts, out of 3000000 for 9000
28 hyphenation exceptions out of 8191
34i,8n,49p,1030b,263s stack positions out of 5000i,500n,10000p,200000b,50000s
{/usr/share/texmf-texlive/fonts/enc/dvips/base/8r.enc}
</usr/share/texmf-texlive/fonts/type1/public/amsfonts/cm/cmsy10.pfb></usr/share
/texmf-texlive/fonts/type1/urw/courier/ucrr8a.pfb></usr/share/texmf-texlive/fon
ts/type1/urw/times/utmb8a.pfb></usr/share/texmf-texlive/fonts/type1/urw/times/u
tmr8a.pfb></usr/share/texmf-texlive/fonts/type1/urw/times/utmr8a.pfb></usr/shar
e/texmf-texlive/fonts/type1/urw/times/utmri8a.pfb>
Output written on embedded_book.pdf (6 pages, 104382 bytes).
PDF statistics:
47 PDF objects out of 1000 (max. 8388607)
0 named destinations out of 1000 (max. 500000)
6 words of extra memory for PDF output out of 10000 (max. 10000000)

BIN
course/.docs/cambio_categoria/embedded_book.pdf Normal file
View File

Binary file not shown.

61
course/.docs/cambio_categoria/embedded_book.tex Normal file
View File

@@ -0,0 +1,61 @@
\documentclass[]{report}
\usepackage{fontenc}
\usepackage[latin1]{inputenc}
\usepackage[spanish]{babel}
% \usepackage{pgf}
\usepackage{graphicx}
\usepackage{times}
\usepackage{colortbl}
\usepackage{multicol}
\usepackage{multirow}
\usepackage{pdfpages}
\usepackage{lscape}
\usepackage{graphicx, color}
\usepackage{listings}
\lstset{language=C}
% \lstset{ basicstyle=\small, keywordstyle=\color{blue}\bfseries, identifierstyle=, commentstyle=\color{gray}, showstringspaces=false, keywordstyle=\color{blue}, morekeywords={one,three,five}}
\lstset{backgroundcolor=\color{gray},frame=single,emph={EMPTY},emphstyle=\color{white}, showstringspaces=false,commentstyle=\itshape, morekeywords={printf}, tabsize=2, fontadjust=true, basicstyle=\scriptsize}
%\lstset{framexleftmargin=5mm, frame=shadowbox, rulesepcolor=\color{black}, backgroundcolor=\color[gray]{.9}}
\lstset{backgroundcolor=\color[gray]{.8}}
\pagestyle{myheadings}
\markboth{Codise<EFBFBD>o y Sistemas Embebidos}{Universidad Nacional de Colombia}
\usepackage{longtable}
\parindent 1cm
\parskip 0.2cm
\topmargin 0.2cm
\oddsidemargin 1cm
\evensidemargin 0.5cm
\textwidth 15cm
\textheight 21cm
\begin{document}
\bibliographystyle{unsrt}
\input title
\tableofcontents
\parindent=1cm
% \input introduction
2010/8/12 Oscar Javier Fajardo Ruiz <ojfajardor@unal.edu.co>
Nuestra idea es el ecualizador
% % \input chapter1
\input chapter2
\bibliography{biblio_EL}
\end{document}

57
course/.docs/cambio_categoria/embedded_book.tex.backup Normal file
View File

@@ -0,0 +1,57 @@
\documentclass[]{report}
\usepackage{fontenc}
\usepackage[latin1]{inputenc}
\usepackage[spanish]{babel}
% \usepackage{pgf}
\usepackage{graphicx}
\usepackage{times}
\usepackage{colortbl}
\usepackage{multicol}
\usepackage{multirow}
\usepackage{pdfpages}
\usepackage{lscape}
\usepackage{graphicx, color}
\usepackage{listings}
\lstset{language=C}
% \lstset{ basicstyle=\small, keywordstyle=\color{blue}\bfseries, identifierstyle=, commentstyle=\color{gray}, showstringspaces=false, keywordstyle=\color{blue}, morekeywords={one,three,five}}
\lstset{backgroundcolor=\color{gray},frame=single,emph={EMPTY},emphstyle=\color{white}, showstringspaces=false,commentstyle=\itshape, morekeywords={printf}, tabsize=2, fontadjust=true, basicstyle=\scriptsize}
%\lstset{framexleftmargin=5mm, frame=shadowbox, rulesepcolor=\color{black}, backgroundcolor=\color[gray]{.9}}
\lstset{backgroundcolor=\color[gray]{.8}}
\pagestyle{myheadings}
\markboth{Codise<73>o y Sistemas Embebidos}{Universidad Nacional de Colombia}
\usepackage{longtable}
\parindent 1cm
\parskip 0.2cm
\topmargin 0.2cm
\oddsidemargin 1cm
\evensidemargin 0.5cm
\textwidth 15cm
\textheight 21cm
\begin{document}
\bibliographystyle{unsrt}
\input title
\tableofcontents
\parindent=1cm
% \input introduction
% \input chapter1
\input chapter2
\bibliography{biblio_EL}
\end{document}

3
course/.docs/cambio_categoria/embedded_book.toc Normal file
View File

@@ -0,0 +1,3 @@
\select@language {spanish}
\contentsline {chapter}{\numberline {1}Sistema en un Chip (SoC)}{3}
\contentsline {section}{\numberline {1.1}Arquitectura}{3}

47
course/.docs/cambio_categoria/introduction.tex Normal file
View File

@@ -0,0 +1,47 @@
\chapter{Introducci<EFBFBD>n}
La industria de los semiconductores ha crecido velozmente durante los <20>ltimos a<>os, su campo de acci<63>n se ha extendido a casi todas las actividades del ser humano (Entretenimiento, salud, seguridad, transporte, educaci<63>n, etc); los tiempos de los procesos de dise<73>o son cada vez mas cortos, lo cual require herramientas Hardware, Software y metodolog<6F>as de dise<73>o que ayuden a cumplir con las exigencias impuestas al sistema.
Esta \textit{invasi<EFBFBD>n} digital ha sido posible gracias a la industria de los semiconductores y a las empresas desarrolladoras de software, las primeras haciendo uso de un alt<6C>simo grado de integraci<63>n ponen a disposici<63>n de los dise<73>adores \textit{Systems On Chip} (SoC) en los cuales se integran procesadores de 32 bits con una gran variedad de perif<69>ricos tales como: Controladores de dispositivos de red (cableada e inal<61>mbricos), controladores de video, procesadores aritm<74>ticos, controladores de memorias (Flash, SDRAM, DDR, USB, SD), codecs de audio, controladores de touch screen, etc; lo cual permite la implementaci<63>n de aplicaciones completas dentro de uno de estos SoCs.
Por otro lado, las empresas desarrolladoras de SW crean herramientas de programaci<63>n que permiten manejar toda la capacidad de estos SoCs. colocando a disposici<63>n de los dise<73>adores: compiladores, simuladores, emuladores, librer<65>as, Sistemas Operativos y drivers. Lo cual permite realizar desarrollos complejos en tiempos cortos.
En la actualidad existe un gran n<>mero de sistemas operativos (OS) disponibles tanto comerciales como \textit{open source}. La figura \ref{os} muestra la utilizaci<63>n actual de OS comerciales en aplicaciones embebidas; si sumamos los sistemas operativos basados en linux se obtiene un valor del 19.3 \% lo cual hace ganador al sistema operativo de libre distribuci<63>n \cite{CLSB05}. La figura \ref{os2} muestra un cuadro comparativo de la utilizaci<63>n de herramientas comerciales y linux; de nuevo se observa que linux es el preferido por los dise<73>adores. Este resultado es interesante ya que uno de los supuestos puntos d<>biles del software de libre distribuci<63>n es el soporte, lo cual no lo hace tan agradable a la hora de realizar aplicaciones comerciales, sin embargo, esto es solo un mito, ya que gracias a que el c<>digo fuente est<73> disponible, es posible comprender perfectamente su funcionamiento, lo cual no sucede con el software comercial; adem<65>s, existen muchos foros de dise<73>adores y desarrolladores que se encargan de responder las inquietudes, estos foros almacenan todos los mensajes recibidos e incluyen herramientas de b<>squeda para poder consultarlos, por regla general de estos foros, se debe buscar primero en estos archivos hist<73>ricos, muy seguramente alguien m<>s pregunt<6E> lo mismo antes que nosotros.
El caracter gratutito de las herramientas de libre distribuci<63>n no significa, ni mucho menos, mala calidad, todo lo contrario, existen muchas personas que escudri<72>an su c<>digo fuente en b<>squeda de posibles errores, y realizan cambios con el f<>n de eliminarlo; por lo tanto, se cuenta con miles de personas que est<73>n constantemente depurando y perfeccionando una determinada aplicaci<63>n; esto no ocurre con el software comercial, normalmente el soporte hay que pagarlo y las perosnas involucradas en el desarrollo no son tantas como las que tienen acceso al c<>digo fuente del software libre. Por esta raz<61>n empresas como PALM, han dejado de lado productos propietarios como el PALM OS para utilizar linux, SUN Microsystems, liber<65> el c<>digo fuente de su sistema operativo Solaris, ya que no era comparable con linux y est<73> en el proceso de liberar uno de sus procesadores.
\begin{figure}
\begin{center} \includegraphics[scale=.45, angle=90]{./images/Current_OS} \end{center}
\caption{Utilizaci<EFBFBD>n actual de OS para aplicaciones embebidas: Fuente \cite{JT04}.}\label{os}
\end{figure}
\begin{figure}
\begin{center} \includegraphics[scale=1]{./images/OS_embedded} \end{center}
\caption{Utilizaci<EFBFBD>n actual de OS para aplicaciones embebidas: Fuente http://www.linuxdevices.com/articles/AT7070519787.html.}\label{os2}
\end{figure}
De lo anterior se deduce que el mundo de los sistemas digitales ha cambiado en forma considerable, y que en la actualidad existen grandes facilidades para el desarrollo de productos de forma r<>pida y econ<6F>mica \footnote{En la actualidad cerca del 60\% de los ingenieros trabajan en compa<70><61>as con menos de 10 desarrolladores de SW \cite{VDC06}}. Desafortunadamente estas tendencias no se han aplicado a<>n en Colombia; existen varias razones para esto:
\begin{enumerate}
\item Desactualizaci<63>n de los programas aced<65>micos: En muchas de las Universidades de Colombia se utilizan tecnolog<6F>as obsoletas que impiden la aplicaci<63>n de metodolog<6F>as de dise<73>o modernas adem<65>s de impedir el desarrollo de aplicaciones comerciales, un ejemplo de este tipo de tecnolog<6F>as es la l<>gica TTL (74XX) y sus equivalentes en CMOS. Aunque vale la pena aclarar que este tipo de tecnolog<6F>a es <20>til a la hora de ense<73>ar conceptos b<>sicos, no puede ser utilizada como <20>nica herramienta de implementaci<63>n. Un ejemplo de desactualizaci<63>n de metodolog<6F>as de dise<73>o lo encontramos en las herramientas de programaci<63>n para microcontroladores, una gran cantidad de Universidades utilizan lenguaje ensamblador, lo cual impide la re-utilizaci<63>n de c<>digo y crea dependencias con el HW utilizado.
\item Falta de inter<65>s de la Industria: Un gran porcentaje de la industria Colombiana es consumidora de tecnolog<6F>a, es decir, no generan sus propias soluciones, no cuentan con departamentos de Investigaci<63>n y Desarrollo; esto se debe a la falta de confianza en los productos nacionales y en algunos casos a la inexistencia de producci<63>n nacional. Por otro lado, la cooperaci<63>n entre la Universidad y la industria es muy reducida, debido a falta de pol<6F>ticas en las Universidades que regulen esta actividad y a la poca inversi<73>n por parte de las empresas.
\item Pol<6F>ticas del Estado: Casi la totalidad de estos nuevos dispositivos semiconductores deben ser importados, ya que en Colombia no existen distribuidores, por lo tanto, es necesario pagar una serie de impuestos que no desalientan su utilizaci<63>n, estos impuestos est<73>n por el orden del 26\% del valor del producto. Por otro lado la apertura econ<6F>mica permite que ingresen productos a bajo precio, con los que no pueden competir los pocos productos desarrollados en el pais, eso sumado a la falta de protecci<63>n por parte de las pol<6F>ticas estatales condena a los desarrolladores de estos sistemas a la quiebra econ<6F>mica.
\end{enumerate}
Este proyecto resume el trabajo realizado durante los <20>ltimos cuatro a<>os en el <20>rea de la electr<74>nica digital y m<>s exactamente en el estudio de las metodolog<6F>as de dise<73>o modernas con aplicaciones comerciales y es presentado para cumplir parcialmente los requisitos de cambio de categor<6F>a de profesor asistente a asociado. El presente informe est<73> dividido de la siguiente forma:
\begin{itemize}
\item En el cap<61>tulo 1 se realiza una breve descripci<63>n de los sistemas embebidos, se enumeran sus caracter<65>sticas, aplicaciones y se hace una descripci<63>n de las herramientas HW y SW necesarias para el dise<73>o de los mismos. En los cap<61>tulos siguientes se desarrollan casos de estudio encaminados a la comprensi<73>n de estos sistemas:
\item En el cap<61>tulo dos se trabaja con una plataforma comercial de bajo costo: El GameBoy de Nintendo, (gracias a los elevados vol<6F>menes de producci<63>n el costo de este dispositivo es bajo alrededor de 40 USD) esta plataforma nos permite desarrollar conceptos b<>sicos como la compilaci<63>n cruzada, la interfaz HW-SW y los sistemas operativos.
\item En el cap<61>tulo tres se muestra la implementaci<63>n de la primera plataforma de desarrollo para sistemas embebidos dise<73>ada en la Universidad Nacional, a pesar de ser muy sencilla permite dar un gran paso en el proceso de fabricaci<63>n de este tipo de dispositivos.
\item En el cap<61>tulo cuatro se realiza la implementci<63>n de una plataforma de desarrollo que utiliza el sistema operativo linux sobre un arreglo de compuertas programable en campo (FPGA) y se muestran los resultados de una aplicaci<63>n en el <20>rea del Hardware Reconfigurable.
\item El cap<61>tulo cinco es una gu<67>a de adaptaci<63>n del sistema operativo linux para una arquitectura ARM.
\end{itemize}
Por <20>ltimo se muestra como algunos de los resultados de este estudio han sido introducidos a los cursos del <20>rea de los sistemas digitales en la Universidad Nacional de Colombia y como se ha realizado su difusi<73>n en otras Universidades de Colombia.

47
course/.docs/cambio_categoria/introduction.tex.backup Normal file
View File

@@ -0,0 +1,47 @@
\chapter{Introducci<63>n}
La industria de los semiconductores ha crecido velozmente durante los <20>ltimos a<>os, su campo de acci<63>n se ha extendido a casi todas las actividades del ser humano (Entretenimiento, salud, seguridad, transporte, educaci<63>n, etc); los tiempos de los procesos de dise<73>o son cada vez mas cortos, lo cual require herramientas Hardware, Software y metodolog<6F>as de dise<73>o que ayuden a cumplir con las exigencias impuestas al sistema.
Esta \textit{invasi<73>n} digital ha sido posible gracias a la industria de los semiconductores y a las empresas desarrolladoras de software, las primeras haciendo uso de un alt<6C>simo grado de integraci<63>n ponen a disposici<63>n de los dise<73>adores \textit{Systems On Chip} (SoC) en los cuales se integran procesadores de 32 bits con una gran variedad de perif<69>ricos tales como: Controladores de dispositivos de red (cableada e inal<61>mbricos), controladores de video, procesadores aritm<74>ticos, controladores de memorias (Flash, SDRAM, DDR, USB, SD), codecs de audio, controladores de touch screen, etc; lo cual permite la implementaci<63>n de aplicaciones completas dentro de uno de estos SoCs.
Por otro lado, las empresas desarrolladoras de SW crean herramientas de programaci<63>n que permiten manejar toda la capacidad de estos SoCs. colocando a disposici<63>n de los dise<73>adores: compiladores, simuladores, emuladores, librer<65>as, Sistemas Operativos y drivers. Lo cual permite realizar desarrollos complejos en tiempos cortos.
En la actualidad existe un gran n<>mero de sistemas operativos (OS) disponibles tanto comerciales como \textit{open source}. La figura \ref{os} muestra la utilizaci<63>n actual de OS comerciales en aplicaciones embebidas; si sumamos los sistemas operativos basados en linux se obtiene un valor del 19.3 \% lo cual hace ganador al sistema operativo de libre distribuci<63>n \cite{CLSB05}. La figura \ref{os2} muestra un cuadro comparativo de la utilizaci<63>n de herramientas comerciales y linux; de nuevo se observa que linux es el preferido por los dise<73>adores. Este resultado es interesante ya que uno de los supuestos puntos d<>biles del software de libre distribuci<63>n es el soporte, lo cual no lo hace tan agradable a la hora de realizar aplicaciones comerciales, sin embargo, esto es solo un mito, ya que gracias a que el c<>digo fuente est<73> disponible, es posible comprender perfectamente su funcionamiento, lo cual no sucede con el software comercial; adem<65>s, existen muchos foros de dise<73>adores y desarrolladores que se encargan de responder las inquietudes, estos foros almacenan todos los mensajes recibidos e incluyen herramientas de b<>squeda para poder consultarlos, por regla general de estos foros, se debe buscar primero en estos archivos hist<73>ricos, muy seguramente alguien m<>s pregunt<6E> lo mismo antes que nosotros.
El caracter gratutito de las herramientas de libre distribuci<63>n no significa, ni mucho menos, mala calidad, todo lo contrario, existen muchas personas que escudri<72>an su c<>digo fuente en b<>squeda de posibles errores, y realizan cambios con el f<>n de eliminarlo; por lo tanto, se cuenta con miles de personas que est<73>n constantemente depurando y perfeccionando una determinada aplicaci<63>n; esto no ocurre con el software comercial, normalmente el soporte hay que pagarlo y las perosnas involucradas en el desarrollo no son tantas como las que tienen acceso al c<>digo fuente del software libre. Por esta raz<61>n empresas como PALM, han dejado de lado productos propietarios como el PALM OS para utilizar linux, SUN Microsystems, liber<65> el c<>digo fuente de su sistema operativo Solaris, ya que no era comparable con linux y est<73> en el proceso de liberar uno de sus procesadores.
\begin{figure}[h]
\begin{center} \includegraphics[scale=.45, angle=90]{./images/Current_OS} \end{center}
\caption{Utilizaci<63>n actual de OS para aplicaciones embebidas: Fuente \cite{JT04}.}\label{os}
\end{figure}
\begin{figure}
\begin{center} \includegraphics[scale=1]{./images/OS_embedded} \end{center}
\caption{Utilizaci<63>n actual de OS para aplicaciones embebidas: Fuente http://www.linuxdevices.com/articles/AT7070519787.html.}\label{os2}
\end{figure}
De lo anterior se deduce que el mundo de los sistemas digitales ha cambiado en forma considerable, y que en la actualidad existen grandes facilidades para el desarrollo de productos de forma r<>pida y econ<6F>mica \footnote{En la actualidad cerca del 60\% de los ingenieros trabajan en compa<70><61>as con menos de 10 desarrolladores de SW \cite{VDC06}}. Desafortunadamente estas tendencias no se han aplicado a<>n en Colombia; existen varias razones para esto:
\begin{enumerate}
\item Desactualizaci<63>n de los programas aced<65>micos: En muchas de las Universidades de Colombia se utilizan tecnolog<6F>as obsoletas que impiden la aplicaci<63>n de metodolog<6F>as de dise<73>o modernas adem<65>s de impedir el desarrollo de aplicaciones comerciales, un ejemplo de este tipo de tecnolog<6F>as es la l<>gica TTL (74XX) y sus equivalentes en CMOS. Aunque vale la pena aclarar que este tipo de tecnolog<6F>a es <20>til a la hora de ense<73>ar conceptos b<>sicos, no puede ser utilizada como <20>nica herramienta de implementaci<63>n. Un ejemplo de desactualizaci<63>n de metodolog<6F>as de dise<73>o lo encontramos en las herramientas de programaci<63>n para microcontroladores, una gran cantidad de Universidades utilizan lenguaje ensamblador, lo cual impide la re-utilizaci<63>n de c<>digo y crea dependencias con el HW utilizado.
\item Falta de inter<65>s de la Industria: Un gran porcentaje de la industria Colombiana es consumidora de tecnolog<6F>a, es decir, no generan sus propias soluciones, no cuentan con departamentos de Investigaci<63>n y Desarrollo; esto se debe a la falta de confianza en los productos nacionales y en algunos casos a la inexistencia de producci<63>n nacional. Por otro lado, la cooperaci<63>n entre la Universidad y la industria es muy reducida, debido a falta de pol<6F>ticas en las Universidades que regulen esta actividad y a la poca inversi<73>n por parte de las empresas.
\item Pol<6F>ticas del Estado: Casi la totalidad de estos nuevos dispositivos semiconductores deben ser importados, ya que en Colombia no existen distribuidores, por lo tanto, es necesario pagar una serie de impuestos que no desalientan su utilizaci<63>n, estos impuestos est<73>n por el orden del 26\% del valor del producto. Por otro lado la apertura econ<6F>mica permite que ingresen productos a bajo precio, con los que no pueden competir los pocos productos desarrollados en el pais, eso sumado a la falta de protecci<63>n por parte de las pol<6F>ticas estatales condena a los desarrolladores de estos sistemas a la quiebra econ<6F>mica.
\end{enumerate}
Este proyecto resume el trabajo realizado durante los <20>ltimos cuatro a<>os en el <20>rea de la electr<74>nica digital y m<>s exactamente en el estudio de las metodolog<6F>as de dise<73>o modernas con aplicaciones comerciales y es presentado para cumplir parcialmente los requisitos de cambio de categor<6F>a de profesor asistente a asociado. El presente informe est<73> dividido de la siguiente forma:
\begin{itemize}
\item En el cap<61>tulo 1 se realiza una breve descripci<63>n de los sistemas embebidos, se enumeran sus caracter<65>sticas, aplicaciones y se hace una descripci<63>n de las herramientas HW y SW necesarias para el dise<73>o de los mismos. En los cap<61>tulos siguientes se desarrollan casos de estudio encaminados a la comprensi<73>n de estos sistemas:
\item En el cap<61>tulo dos se trabaja con una plataforma comercial de bajo costo: El GameBoy de Nintendo, (gracias a los elevados vol<6F>menes de producci<63>n el costo de este dispositivo es bajo alrededor de 40 USD) esta plataforma nos permite desarrollar conceptos b<>sicos como la compilaci<63>n cruzada, la interfaz HW-SW y los sistemas operativos.
\item En el cap<61>tulo tres se muestra la implementaci<63>n de la primera plataforma de desarrollo para sistemas embebidos dise<73>ada en la Universidad Nacional, a pesar de ser muy sencilla permite dar un gran paso en el proceso de fabricaci<63>n de este tipo de dispositivos.
\item En el cap<61>tulo cuatro se realiza la implementci<63>n de una plataforma de desarrollo que utiliza el sistema operativo linux sobre un arreglo de compuertas programable en campo (FPGA) y se muestran los resultados de una aplicaci<63>n en el <20>rea del Hardware Reconfigurable.
\item El cap<61>tulo cinco es una gu<67>a de adaptaci<63>n del sistema operativo linux para una arquitectura ARM.
\end{itemize}
Por <20>ltimo se muestra como algunos de los resultados de este estudio han sido introducidos a los cursos del <20>rea de los sistemas digitales en la Universidad Nacional de Colombia y como se ha realizado su difusi<73>n en otras Universidades de Colombia.

47
course/.docs/cambio_categoria/introduction.tex~ Normal file
View File

@@ -0,0 +1,47 @@
\chapter{Introducci<EFBFBD>n}
La industria de los semiconductores ha crecido velozmente durante los <20>ltimos a<>os, su campo de acci<63>n se ha extendido a casi todas las actividades del ser humano (Entretenimiento, salud, seguridad, transporte, educaci<63>n, etc); los tiempos de los procesos de dise<73>o son cada vez mas cortos, lo cual require herramientas Hardware, Software y metodolog<6F>as de dise<73>o que ayuden a cumplir con las exigencias impuestas al sistema.
Esta \textit{invasi<EFBFBD>n} digital ha sido posible gracias a la industria de los semiconductores y a las empresas desarrolladoras de software, las primeras haciendo uso de un alt<6C>simo grado de integraci<63>n ponen a disposici<63>n de los dise<73>adores \textit{Systems On Chip} (SoC) en los cuales se integran procesadores de 32 bits con una gran variedad de perif<69>ricos tales como: Controladores de dispositivos de red (cableada e inal<61>mbricos), controladores de video, procesadores aritm<74>ticos, controladores de memorias (Flash, SDRAM, DDR, USB, SD), codecs de audio, controladores de touch screen, etc; lo cual permite la implementaci<63>n de aplicaciones completas dentro de uno de estos SoCs.
Por otro lado, las empresas desarrolladoras de SW crean herramientas de programaci<63>n que permiten manejar toda la capacidad de estos SoCs. colocando a disposici<63>n de los dise<73>adores: compiladores, simuladores, emuladores, librer<65>as, Sistemas Operativos y drivers. Lo cual permite realizar desarrollos complejos en tiempos cortos.
En la actualidad existe un gran n<>mero de sistemas operativos (OS) disponibles tanto comerciales como \textit{open source}. La figura \ref{os} muestra la utilizaci<63>n actual de OS comerciales en aplicaciones embebidas; si sumamos los sistemas operativos basados en linux se obtiene un valor del 19.3 \% lo cual hace ganador al sistema operativo de libre distribuci<63>n \cite{CLSB05}. La figura \ref{os2} muestra un cuadro comparativo de la utilizaci<63>n de herramientas comerciales y linux; de nuevo se observa que linux es el preferido por los dise<73>adores. Este resultado es interesante ya que uno de los supuestos puntos d<>biles del software de libre distribuci<63>n es el soporte, lo cual no lo hace tan agradable a la hora de realizar aplicaciones comerciales, sin embargo, esto es solo un mito, ya que gracias a que el c<>digo fuente est<73> disponible, es posible comprender perfectamente su funcionamiento, lo cual no sucede con el software comercial; adem<65>s, existen muchos foros de dise<73>adores y desarrolladores que se encargan de responder las inquietudes, estos foros almacenan todos los mensajes recibidos e incluyen herramientas de b<>squeda para poder consultarlos, por regla general de estos foros, se debe buscar primero en estos archivos hist<73>ricos, muy seguramente alguien m<>s pregunt<6E> lo mismo antes que nosotros.
El caracter gratutito de las herramientas de libre distribuci<63>n no significa, ni mucho menos, mala calidad, todo lo contrario, existen muchas personas que escudri<72>an su c<>digo fuente en b<>squeda de posibles errores, y realizan cambios con el f<>n de eliminarlo; por lo tanto, se cuenta con miles de personas que est<73>n constantemente depurando y perfeccionando una determinada aplicaci<63>n; esto no ocurre con el software comercial, normalmente el soporte hay que pagarlo y las perosnas involucradas en el desarrollo no son tantas como las que tienen acceso al c<>digo fuente del software libre. Por esta raz<61>n empresas como PALM, han dejado de lado productos propietarios como el PALM OS para utilizar linux, SUN Microsystems, liber<65> el c<>digo fuente de su sistema operativo Solaris, ya que no era comparable con linux y est<73> en el proceso de liberar uno de sus procesadores.
\begin{figure}[h]
\begin{center} \includegraphics[scale=.45, angle=90]{./images/Current_OS} \end{center}
\caption{Utilizaci<EFBFBD>n actual de OS para aplicaciones embebidas: Fuente \cite{JT04}.}\label{os}
\end{figure}
\begin{figure}
\begin{center} \includegraphics[scale=1]{./images/OS_embedded} \end{center}
\caption{Utilizaci<EFBFBD>n actual de OS para aplicaciones embebidas: Fuente http://www.linuxdevices.com/articles/AT7070519787.html.}\label{os2}
\end{figure}
De lo anterior se deduce que el mundo de los sistemas digitales ha cambiado en forma considerable, y que en la actualidad existen grandes facilidades para el desarrollo de productos de forma r<>pida y econ<6F>mica \footnote{En la actualidad cerca del 60\% de los ingenieros trabajan en compa<70><61>as con menos de 10 desarrolladores de SW \cite{VDC06}}. Desafortunadamente estas tendencias no se han aplicado a<>n en Colombia; existen varias razones para esto:
\begin{enumerate}
\item Desactualizaci<63>n de los programas aced<65>micos: En muchas de las Universidades de Colombia se utilizan tecnolog<6F>as obsoletas que impiden la aplicaci<63>n de metodolog<6F>as de dise<73>o modernas adem<65>s de impedir el desarrollo de aplicaciones comerciales, un ejemplo de este tipo de tecnolog<6F>as es la l<>gica TTL (74XX) y sus equivalentes en CMOS. Aunque vale la pena aclarar que este tipo de tecnolog<6F>a es <20>til a la hora de ense<73>ar conceptos b<>sicos, no puede ser utilizada como <20>nica herramienta de implementaci<63>n. Un ejemplo de desactualizaci<63>n de metodolog<6F>as de dise<73>o lo encontramos en las herramientas de programaci<63>n para microcontroladores, una gran cantidad de Universidades utilizan lenguaje ensamblador, lo cual impide la re-utilizaci<63>n de c<>digo y crea dependencias con el HW utilizado.
\item Falta de inter<65>s de la Industria: Un gran porcentaje de la industria Colombiana es consumidora de tecnolog<6F>a, es decir, no generan sus propias soluciones, no cuentan con departamentos de Investigaci<63>n y Desarrollo; esto se debe a la falta de confianza en los productos nacionales y en algunos casos a la inexistencia de producci<63>n nacional. Por otro lado, la cooperaci<63>n entre la Universidad y la industria es muy reducida, debido a falta de pol<6F>ticas en las Universidades que regulen esta actividad y a la poca inversi<73>n por parte de las empresas.
\item Pol<6F>ticas del Estado: Casi la totalidad de estos nuevos dispositivos semiconductores deben ser importados, ya que en Colombia no existen distribuidores, por lo tanto, es necesario pagar una serie de impuestos que no desalientan su utilizaci<63>n, estos impuestos est<73>n por el orden del 26\% del valor del producto. Por otro lado la apertura econ<6F>mica permite que ingresen productos a bajo precio, con los que no pueden competir los pocos productos desarrollados en el pais, eso sumado a la falta de protecci<63>n por parte de las pol<6F>ticas estatales condena a los desarrolladores de estos sistemas a la quiebra econ<6F>mica.
\end{enumerate}
Este proyecto resume el trabajo realizado durante los <20>ltimos cuatro a<>os en el <20>rea de la electr<74>nica digital y m<>s exactamente en el estudio de las metodolog<6F>as de dise<73>o modernas con aplicaciones comerciales y es presentado para cumplir parcialmente los requisitos de cambio de categor<6F>a de profesor asistente a asociado. El presente informe est<73> dividido de la siguiente forma:
\begin{itemize}
\item En el cap<61>tulo 1 se realiza una breve descripci<63>n de los sistemas embebidos, se enumeran sus caracter<65>sticas, aplicaciones y se hace una descripci<63>n de las herramientas HW y SW necesarias para el dise<73>o de los mismos. En los cap<61>tulos siguientes se desarrollan casos de estudio encaminados a la comprensi<73>n de estos sistemas:
\item En el cap<61>tulo dos se trabaja con una plataforma comercial de bajo costo: El GameBoy de Nintendo, (gracias a los elevados vol<6F>menes de producci<63>n el costo de este dispositivo es bajo alrededor de 40 USD) esta plataforma nos permite desarrollar conceptos b<>sicos como la compilaci<63>n cruzada, la interfaz HW-SW y los sistemas operativos.
\item En el cap<61>tulo tres se muestra la implementaci<63>n de la primera plataforma de desarrollo para sistemas embebidos dise<73>ada en la Universidad Nacional, a pesar de ser muy sencilla permite dar un gran paso en el proceso de fabricaci<63>n de este tipo de dispositivos.
\item En el cap<61>tulo cuatro se realiza la implementci<63>n de una plataforma de desarrollo que utiliza el sistema operativo linux sobre un arreglo de compuertas programable en campo (FPGA) y se muestran los resultados de una aplicaci<63>n en el <20>rea del Hardware Reconfigurable.
\item El cap<61>tulo cinco es una gu<67>a de adaptaci<63>n del sistema operativo linux para una arquitectura ARM.
\end{itemize}
Por <20>ltimo se muestra como algunos de los resultados de este estudio han sido introducidos a los cursos del <20>rea de los sistemas digitales en la Universidad Nacional de Colombia y como se ha realizado su difusi<73>n en otras Universidades de Colombia.

79
course/.docs/cambio_categoria/main.aux Normal file
View File

@@ -0,0 +1,79 @@
\relax
\catcode`.\active
\catcode`\.=12
\catcode`"\active
\catcode`<\active
\catcode`>\active
\es@quoting
\bibstyle{unsrt}
\select@language{spanish}
\@writefile{toc}{\select@language{spanish}}
\@writefile{lof}{\select@language{spanish}}
\@writefile{lot}{\select@language{spanish}}
\citation{A1}
\citation{Wik}
\citation{Wik}
\citation{CLSB05}
\@writefile{toc}{\contentsline {chapter}{\numberline {1}Introducci\'on}{3}}
\@writefile{lof}{\addvspace {10\p@ }}
\@writefile{lot}{\addvspace {10\p@ }}
\citation{JT04}
\citation{VDC06}
\@writefile{lof}{\contentsline {figure}{\numberline {1.1}{\ignorespaces Utilizaci\'on actual de OS para aplicaciones embebidas: Fuente \cite {JT04}.}}{4}}
\newlabel{os}{{1.1}{4}}
\@writefile{lof}{\contentsline {figure}{\numberline {1.2}{\ignorespaces Utilizaci\'on actual de OS para aplicaciones embebidas: Fuente http://www.linuxdevices.com/articles/AT7070519787.html.}}{5}}
\newlabel{os2}{{1.2}{5}}
\citation{Wik}
\@writefile{toc}{\contentsline {chapter}{\numberline {2}Conceptos B\'asicos de los Sistemas Embebidos}{7}}
\@writefile{lof}{\addvspace {10\p@ }}
\@writefile{lot}{\addvspace {10\p@ }}
\@writefile{toc}{\contentsline {section}{\numberline {2.1}Definici\'on}{7}}
\@writefile{toc}{\contentsline {section}{\numberline {2.2}Caracter\IeC {\'\i }sticas}{7}}
\@writefile{toc}{\contentsline {section}{\numberline {2.3}Arquitectura}{7}}
\@writefile{lof}{\contentsline {figure}{\numberline {2.1}{\ignorespaces Arquitectura de un Sistema Embebido}}{8}}
\newlabel{es_arch}{{2.1}{8}}
\citation{Cor05}
\@writefile{toc}{\contentsline {section}{\numberline {2.4}Metodolog\IeC {\'\i }a de Dise\~no}{9}}
\@writefile{lof}{\contentsline {figure}{\numberline {2.2}{\ignorespaces Flujo de Dise\~no de un Sistema Embebido}}{10}}
\newlabel{des_flow}{{2.2}{10}}
\citation{A1}
\@writefile{toc}{\contentsline {subsection}{\numberline {2.4.1}Herramientas Software de libre distribuci\'on \textit {GNU toolchain}}{11}}
\@writefile{lof}{\contentsline {figure}{\numberline {2.3}{\ignorespaces Tendencia de utilizaci\'on de herramientas de desarrollo}}{11}}
\newlabel{tools}{{2.3}{11}}
\@writefile{toc}{\contentsline {subsection}{\numberline {2.4.2}Componentes del \textit {GNU toolchain} }{11}}
\@writefile{toc}{\contentsline {subsection}{\numberline {2.4.3}GNU binutils\cite {A1}}{11}}
\citation{Wik}
\@writefile{toc}{\contentsline {subsection}{\numberline {2.4.4}GNU Compiler Collection\cite {Wik}}{12}}
\@writefile{toc}{\contentsline {subsubsection}{Lenguajes}{12}}
\@writefile{toc}{\contentsline {subsubsection}{Arquitecturas}{13}}
\@writefile{lof}{\contentsline {figure}{\numberline {2.4}{\ignorespaces N\'umero promedio de desarrolladores por compa\~n\IeC {\'\i }a. Fuente Venture Development Corp}}{14}}
\newlabel{group}{{2.4}{14}}
\@writefile{toc}{\contentsline {subsection}{\numberline {2.4.5}GNU Debugger}{14}}
\citation{BG}
\citation{Lin05}
\citation{DK06}
\citation{MLH98}
\@writefile{toc}{\contentsline {subsection}{\numberline {2.4.6}C Libraries}{15}}
\@writefile{toc}{\contentsline {section}{\numberline {2.5}Obtenci\'on y utilizaci\'on del \textit {GNU toolchain}}{15}}
\@writefile{toc}{\contentsline {subsection}{\numberline {2.5.1}Conceptos Previos}{15}}
\citation{Lin05}
\@writefile{lof}{\contentsline {figure}{\numberline {2.5}{\ignorespaces Tendencia del mercado de procesadores para sistemas embebidos. Fuente:\cite {Lin05} }}{16}}
\newlabel{arch}{{2.5}{16}}
\@writefile{toc}{\contentsline {subsubsection}{El formato \textbf {ELF}}{16}}
\@writefile{lof}{\contentsline {figure}{\numberline {2.6}{\ignorespaces Tendencia del mercado de procesadores para sistemas embebidos. Fuente:\cite {Lin05} }}{16}}
\newlabel{elf1}{{2.6}{16}}
\citation{Lin05}
\@writefile{toc}{\contentsline {subsection}{\numberline {2.5.2}Flujo de dise\~no software}{18}}
\@writefile{lof}{\contentsline {figure}{\numberline {2.7}{\ignorespaces Tendencia del mercado de procesadores para sistemas embebidos. Fuente:\cite {Lin05} }}{18}}
\newlabel{toolchain_flow}{{2.7}{18}}
\@writefile{toc}{\contentsline {section}{\numberline {2.6}Makefile}{19}}
\bibdata{biblio_EL}
\bibcite{A1}{1}
\bibcite{Wik}{2}
\bibcite{CLSB05}{3}
\bibcite{JT04}{4}
\bibcite{VDC06}{5}
\bibcite{BG}{6}
\bibcite{Lin05}{7}
\bibcite{DK06}{8}
\bibcite{MLH98}{9}

51
course/.docs/cambio_categoria/main.bbl Normal file
View File

@@ -0,0 +1,51 @@
\begin{thebibliography}{1}
\bibitem{A1}
{Aleph 1}.
\newblock Building the {T}oolchain.
\newblock http://www.aleph1.co.uk/node/279.
\bibitem{Wik}
Wikipedia.
\newblock Wikipedia, the free encyclopedia.
\newblock http://en.wikipedia.org/.
\bibitem{CLSB05}
{C. Lanfear}, {S. Balacco}, and {M. Volckmann}.
\newblock The 2005 {E}mbedded {S}oftware {S}trategic {M}arket {I}ntelligence
{P}rogram.
\newblock {\em Venture Development Corporation http://www.vdc-corp.com}, August
2005.
\bibitem{JT04}
{J. Turley}.
\newblock Embedded systems survey: {O}perating systems up for grabs.
\newblock {\em Embedded Systems Programming}, May 2004.
\bibitem{VDC06}
{Venture Development Corp.}
\newblock Small teams dominate embedded software development.
\newblock http://www.linuxdevices.com/articles/AT7019328497.html, 1 June 2006.
\bibitem{BG}
{Bill Gatliff}.
\newblock Porting and {U}sing {N}ewlib in {E}mbedded {S}ystems.
\newblock http://venus.billgatliff.com/node/3.
\bibitem{Lin05}
Linuxdevices.
\newblock Embedded {L}inux market snapshot, 2005.
\newblock {\em http://www.linuxdevices.com}, 4 May 2005.
\bibitem{DK06}
{Dan Kegel}.
\newblock Building and {T}esting gcc/glibc cross toolchains.
\newblock http://www.kegel.com/crosstool/, 20 February 2006.
\bibitem{MLH98}
{Michael L. Haungs}.
\newblock The {E}xecutable and {L}inking {F}ormat ({ELF}).
\newblock http://www.cs.ucdavis.edu/~haungs/paper/node1.html, 21 September
1998.
\end{thebibliography}

47
course/.docs/cambio_categoria/main.blg Normal file
View File

@@ -0,0 +1,47 @@
This is BibTeX, Version 0.99c (Web2C 7.5.4)
The top-level auxiliary file: main.aux
The style file: unsrt.bst
Database file #1: biblio_EL.bib
Warning--I didn't find a database entry for "Cor05"
You've used 9 entries,
1791 wiz_defined-function locations,
500 strings with 4568 characters,
and the built_in function-call counts, 1212 in all, are:
= -- 97
> -- 43
< -- 0
+ -- 20
- -- 11
* -- 31
:= -- 204
add.period$ -- 27
call.type$ -- 9
change.case$ -- 9
chr.to.int$ -- 0
cite$ -- 9
duplicate$ -- 54
empty$ -- 151
format.name$ -- 11
if$ -- 274
int.to.chr$ -- 0
int.to.str$ -- 9
missing$ -- 3
newline$ -- 48
num.names$ -- 9
pop$ -- 42
preamble$ -- 1
purify$ -- 0
quote$ -- 0
skip$ -- 33
stack$ -- 0
substring$ -- 0
swap$ -- 9
text.length$ -- 0
text.prefix$ -- 0
top$ -- 0
type$ -- 0
warning$ -- 0
while$ -- 9
width$ -- 10
write$ -- 89
(There was 1 warning)

475
course/.docs/cambio_categoria/main.log Normal file
View File

@@ -0,0 +1,475 @@
This is pdfTeXk, Version 3.141592-1.40.3 (Web2C 7.5.6) (format=pdflatex 2009.4.27) 16 JUL 2009 14:24
entering extended mode
Source specials enabled.
%&-line parsing enabled.
**main.tex
(./main.tex
LaTeX2e <2005/12/01>
Babel <v3.8h> and hyphenation patterns for english, usenglishmax, dumylang, noh
yphenation, ukrainian, russian, bulgarian, loaded.
(/usr/share/texmf-texlive/tex/latex/base/report.cls
Document Class: report 2005/09/16 v1.4f Standard LaTeX document class
(/usr/share/texmf-texlive/tex/latex/base/size10.clo
File: size10.clo 2005/09/16 v1.4f Standard LaTeX file (size option)
)
\c@part=\count79
\c@chapter=\count80
\c@section=\count81
\c@subsection=\count82
\c@subsubsection=\count83
\c@paragraph=\count84
\c@subparagraph=\count85
\c@figure=\count86
\c@table=\count87
\abovecaptionskip=\skip41
\belowcaptionskip=\skip42
\bibindent=\dimen102
)
(/usr/share/texmf-texlive/tex/latex/base/fontenc.sty
Package: fontenc 2005/09/27 v1.99g Standard LaTeX package
)
(/usr/share/texmf-texlive/tex/latex/base/inputenc.sty
Package: inputenc 2006/05/05 v1.1b Input encoding file
\inpenc@prehook=\toks14
\inpenc@posthook=\toks15
(/usr/share/texmf-texlive/tex/latex/base/latin1.def
File: latin1.def 2006/05/05 v1.1b Input encoding file
))
(/usr/share/texmf-texlive/tex/generic/babel/babel.sty
Package: babel 2005/11/23 v3.8h The Babel package
(/usr/share/texmf-texlive/tex/generic/babel/spanish.ldf
Language: spanish.ldf 2005/03/31 v4.2b Spanish support from the babel system
(/usr/share/texmf-texlive/tex/generic/babel/babel.def
File: babel.def 2005/11/23 v3.8h Babel common definitions
\babel@savecnt=\count88
\U@D=\dimen103
)
Package babel Warning: No hyphenation patterns were loaded for
(babel) the language `Spanish'
(babel) I will use the patterns loaded for \language=0 instead.
\l@spanish = a dialect from \language0
\es@quottoks=\toks16
\es@quotdepth=\count89
Package babel Info: Making . an active character on input line 509.
Package babel Info: Making " an active character on input line 540.
Package babel Info: Making < an active character on input line 641.
Package babel Info: Making > an active character on input line 642.
)) (/usr/share/texmf-texlive/tex/latex/graphics/graphicx.sty
Package: graphicx 1999/02/16 v1.0f Enhanced LaTeX Graphics (DPC,SPQR)
(/usr/share/texmf-texlive/tex/latex/graphics/keyval.sty
Package: keyval 1999/03/16 v1.13 key=value parser (DPC)
\KV@toks@=\toks17
)
(/usr/share/texmf-texlive/tex/latex/graphics/graphics.sty
Package: graphics 2006/02/20 v1.0o Standard LaTeX Graphics (DPC,SPQR)
(/usr/share/texmf-texlive/tex/latex/graphics/trig.sty
Package: trig 1999/03/16 v1.09 sin cos tan (DPC)
)
(/etc/texmf/tex/latex/config/graphics.cfg
File: graphics.cfg 2007/01/18 v1.5 graphics configuration of teTeX/TeXLive
)
Package graphics Info: Driver file: pdftex.def on input line 90.
(/usr/share/texmf-texlive/tex/latex/pdftex-def/pdftex.def
File: pdftex.def 2007/01/08 v0.04d Graphics/color for pdfTeX
\Gread@gobject=\count90
))
\Gin@req@height=\dimen104
\Gin@req@width=\dimen105
)
(/usr/share/texmf-texlive/tex/latex/psnfss/times.sty
Package: times 2005/04/12 PSNFSS-v9.2a (SPQR)
)
(/usr/share/texmf-texlive/tex/latex/colortbl/colortbl.sty
Package: colortbl 2001/02/13 v0.1j Color table columns (DPC)
(/usr/share/texmf-texlive/tex/latex/tools/array.sty
Package: array 2005/08/23 v2.4b Tabular extension package (FMi)
\col@sep=\dimen106
\extrarowheight=\dimen107
\NC@list=\toks18
\extratabsurround=\skip43
\backup@length=\skip44
)
(/usr/share/texmf-texlive/tex/latex/graphics/color.sty
Package: color 2005/11/14 v1.0j Standard LaTeX Color (DPC)
(/etc/texmf/tex/latex/config/color.cfg
File: color.cfg 2007/01/18 v1.5 color configuration of teTeX/TeXLive
)
Package color Info: Driver file: pdftex.def on input line 130.
)
\everycr=\toks19
\minrowclearance=\skip45
)
(/usr/share/texmf-texlive/tex/latex/tools/multicol.sty
Package: multicol 2006/05/18 v1.6g multicolumn formatting (FMi)
\c@tracingmulticols=\count91
\mult@box=\box26
\multicol@leftmargin=\dimen108
\c@unbalance=\count92
\c@collectmore=\count93
\doublecol@number=\count94
\multicoltolerance=\count95
\multicolpretolerance=\count96
\full@width=\dimen109
\page@free=\dimen110
\premulticols=\dimen111
\postmulticols=\dimen112
\multicolsep=\skip46
\multicolbaselineskip=\skip47
\partial@page=\box27
\last@line=\box28
\mult@rightbox=\box29
\mult@grightbox=\box30
\mult@gfirstbox=\box31
\mult@firstbox=\box32
\@tempa=\box33
\@tempa=\box34
\@tempa=\box35
\@tempa=\box36
\@tempa=\box37
\@tempa=\box38
\@tempa=\box39
\@tempa=\box40
\@tempa=\box41
\@tempa=\box42
\@tempa=\box43
\@tempa=\box44
\@tempa=\box45
\@tempa=\box46
\@tempa=\box47
\@tempa=\box48
\@tempa=\box49
\c@columnbadness=\count97
\c@finalcolumnbadness=\count98
\last@try=\dimen113
\multicolovershoot=\dimen114
\multicolundershoot=\dimen115
\mult@nat@firstbox=\box50
\colbreak@box=\box51
)
(/usr/share/texmf-texlive/tex/latex/multirow/multirow.sty
\bigstrutjot=\dimen116
)
(/usr/share/texmf-texlive/tex/latex/pdfpages/pdfpages.sty
Package: pdfpages 2006/08/12 v0.4a Insert pages of external PDF documents (AM)
(/usr/share/texmf-texlive/tex/latex/base/ifthen.sty
Package: ifthen 2001/05/26 v1.1c Standard LaTeX ifthen package (DPC)
)
(/usr/share/texmf-texlive/tex/latex/tools/calc.sty
Package: calc 2005/08/06 v4.2 Infix arithmetic (KKT,FJ)
\calc@Acount=\count99
\calc@Bcount=\count100
\calc@Adimen=\dimen117
\calc@Bdimen=\dimen118
\calc@Askip=\skip48
\calc@Bskip=\skip49
LaTeX Info: Redefining \setlength on input line 75.
LaTeX Info: Redefining \addtolength on input line 76.
\calc@Ccount=\count101
\calc@Cskip=\skip50
)
(/usr/share/texmf-texlive/tex/latex/eso-pic/eso-pic.sty
Package: eso-pic 2006/07/14 v1.1d eso-pic (RN)
(/usr/share/texmf-texlive/tex/latex/everyshi/everyshi.sty
Package: everyshi 2001/05/15 v3.00 EveryShipout Package (MS)
))
(/usr/share/texmf-texlive/tex/latex/pdfpages/pppdftex.def
File: pppdftex.def 2006/08/12 v0.4a Pdfpages driver for pdfTeX (AM)
)
\AM@pagebox=\box52
\AM@toc@title=\toks20
\c@AM@survey=\count102
)
(/usr/share/texmf-texlive/tex/latex/graphics/lscape.sty
Package: lscape 2000/10/22 v3.01 Landscape Pages (DPC)
)
(/usr/share/texmf-texlive/tex/latex/listings/listings.sty
\lst@mode=\count103
\lst@gtempboxa=\box53
\lst@token=\toks21
\lst@length=\count104
\lst@currlwidth=\dimen119
\lst@column=\count105
\lst@pos=\count106
\lst@lostspace=\dimen120
\lst@width=\dimen121
\lst@newlines=\count107
\lst@lineno=\count108
\c@lstlisting=\count109
\lst@maxwidth=\dimen122
(/usr/share/texmf-texlive/tex/latex/listings/lstpatch.sty
File: lstpatch.sty 2004/10/17 1.3b (Carsten Heinz)
)
(/usr/share/texmf-texlive/tex/latex/listings/lstmisc.sty
File: lstmisc.sty 2004/09/07 1.3 (Carsten Heinz)
\c@lstnumber=\count110
\lst@skipnumbers=\count111
\lst@framebox=\box54
)
(/usr/share/texmf-texlive/tex/latex/listings/listings.cfg
File: listings.cfg 2004/09/05 1.3 listings configuration
))
Package: listings 2004/10/17 1.3b (Carsten Heinz)
(/usr/share/texmf-texlive/tex/latex/listings/lstlang1.sty
File: lstlang1.sty 2004/09/05 1.3 listings language file
)
(/usr/share/texmf-texlive/tex/latex/listings/lstmisc.sty
File: lstmisc.sty 2004/09/07 1.3 (Carsten Heinz)
)
(/usr/share/texmf-texlive/tex/latex/tools/longtable.sty
Package: longtable 2004/02/01 v4.11 Multi-page Table package (DPC)
\LTleft=\skip51
\LTright=\skip52
\LTpre=\skip53
\LTpost=\skip54
\LTchunksize=\count112
\LTcapwidth=\dimen123
\LT@head=\box55
\LT@firsthead=\box56
\LT@foot=\box57
\LT@lastfoot=\box58
\LT@cols=\count113
\LT@rows=\count114
\c@LT@tables=\count115
\c@LT@chunks=\count116
\LT@p@ftn=\toks22
) (./main.aux)
\openout1 = `main.aux'.
LaTeX Font Info: Checking defaults for OML/cmm/m/it on input line 43.
LaTeX Font Info: ... okay on input line 43.
LaTeX Font Info: Checking defaults for T1/cmr/m/n on input line 43.
LaTeX Font Info: ... okay on input line 43.
LaTeX Font Info: Checking defaults for OT1/cmr/m/n on input line 43.
LaTeX Font Info: ... okay on input line 43.
LaTeX Font Info: Checking defaults for OMS/cmsy/m/n on input line 43.
LaTeX Font Info: ... okay on input line 43.
LaTeX Font Info: Checking defaults for OMX/cmex/m/n on input line 43.
LaTeX Font Info: ... okay on input line 43.
LaTeX Font Info: Checking defaults for U/cmr/m/n on input line 43.
LaTeX Font Info: ... okay on input line 43.
LaTeX Font Info: Try loading font information for OT1+ptm on input line 43.
(/usr/share/texmf-texlive/tex/latex/psnfss/ot1ptm.fd
File: ot1ptm.fd 2001/06/04 font definitions for OT1/ptm.
)
(/usr/share/texmf/tex/context/base/supp-pdf.tex
[Loading MPS to PDF converter (version 2006.09.02).]
\scratchcounter=\count117
\scratchdimen=\dimen124
\scratchbox=\box59
\nofMPsegments=\count118
\nofMParguments=\count119
\everyMPshowfont=\toks23
\MPscratchCnt=\count120
\MPscratchDim=\dimen125
\MPnumerator=\count121
\everyMPtoPDFconversion=\toks24
) ABD: EveryShipout initializing macros (./title.tex
LaTeX Font Info: External font `cmex10' loaded for size
(Font) <12> on input line 11.
LaTeX Font Info: External font `cmex10' loaded for size
(Font) <8> on input line 11.
LaTeX Font Info: External font `cmex10' loaded for size
(Font) <6> on input line 11.
[1
{/var/lib/texmf/fonts/map/pdftex/updmap/pdftex.map}]
Underfull \hbox (badness 10000) in paragraph at lines 16--20
[]
LaTeX Font Info: Try loading font information for OMS+ptm on input line 23.
(/usr/share/texmf-texlive/tex/latex/psnfss/omsptm.fd
File: omsptm.fd
)
LaTeX Font Info: Font shape `OMS/ptm/m/n' in size <10> not available
(Font) Font shape `OMS/cmsy/m/n' tried instead on input line 23.
LaTeX Font Info: Try loading font information for OT1+pcr on input line 24.
(/usr/share/texmf-texlive/tex/latex/psnfss/ot1pcr.fd
File: ot1pcr.fd 2001/06/04 font definitions for OT1/pcr.
)
Underfull \hbox (badness 10000) in paragraph at lines 23--25
[]
Underfull \hbox (badness 10000) in paragraph at lines 26--30
[]
Underfull \hbox (badness 10000) in paragraph at lines 31--34
[]
Underfull \hbox (badness 10000) in paragraph at lines 35--36
[]
[1])
LaTeX Font Info: Font shape `OT1/ptm/bx/n' in size <24.88> not available
(Font) Font shape `OT1/ptm/b/n' tried instead on input line 46.
(./main.toc
LaTeX Font Info: Font shape `OT1/ptm/bx/n' in size <10> not available
(Font) Font shape `OT1/ptm/b/n' tried instead on input line 2.
LaTeX Font Info: External font `cmex10' loaded for size
(Font) <7> on input line 4.
LaTeX Font Info: External font `cmex10' loaded for size
(Font) <5> on input line 4.
)
\tf@toc=\write3
\openout3 = `main.toc'.
(./introduction.tex [2
]
Cap\'{\i }tulo 1.
LaTeX Font Info: Font shape `OT1/ptm/bx/n' in size <20.74> not available
(Font) Font shape `OT1/ptm/b/n' tried instead on input line 1.
[3
] <./images/Current_OS.jpg, id=19, 401.5pt x 460.72125pt>
File: ./images/Current_OS.jpg Graphic file (type jpg)
<use ./images/Current_OS.jpg>
<./images/OS_embedded.jpg, id=20, 301.125pt x 232.79893pt>
File: ./images/OS_embedded.jpg Graphic file (type jpg)
<use ./images/OS_embedded.jpg>
Underfull \hbox (badness 10000) in paragraph at lines 21--21
[][]\OT1/ptm/m/n/10 Figura 1.2: Uti-lizaci[]on ac-tu-al de OS para apli-ca-cion
es em-be-bidas: Fuente
[]
[4 <./images/Current_OS.jpg>] [5 <./images/OS_embedded.jpg>]) (./chapter1.tex
[6]
Cap\'{\i }tulo 2.
LaTeX Font Info: Font shape `OT1/ptm/bx/n' in size <14.4> not available
(Font) Font shape `OT1/ptm/b/n' tried instead on input line 3.
<./images/ES_Architecture.png, id=32, 488.82625pt x 407.5225pt>
File: ./images/ES_Architecture.png Graphic file (type png)
<use ./images/ES_Architecture.png> [7
] [8 <./images/ES_Architecture.png (PNG copy)>]
LaTeX Warning: Citation `Cor05' on page 9 undefined on input line 62.
<./images/design_flow.jpg, id=39, 675.52374pt x 1068.99374pt>
File: ./images/design_flow.jpg Graphic file (type jpg)
<use ./images/design_flow.jpg>
LaTeX Warning: Float too large for page by 24.60542pt on input line 67.
[9] [10 <./images/design_flow.jpg>]
LaTeX Font Info: Font shape `OT1/ptm/bx/n' in size <12> not available
(Font) Font shape `OT1/ptm/b/n' tried instead on input line 149.
LaTeX Font Info: Font shape `OT1/ptm/bx/it' in size <12> not available
(Font) Font shape `OT1/ptm/b/it' tried instead on input line 149.
<./images/embedded-linux-tool-trends-sm.jpg, id=46, 301.125pt x 227.04292pt>
File: ./images/embedded-linux-tool-trends-sm.jpg Graphic file (type jpg)
<use ./images/embedded-linux-tool-trends-sm.jpg> [11 <./images/embedded-linux-t
ool-trends-sm.jpg>] [12] [13]
<./images/vdc_embedded_dev_company_size.jpg, id=59, 1806.75pt x 843.15pt>
File: ./images/vdc_embedded_dev_company_size.jpg Graphic file (type jpg)
<use ./images/vdc_embedded_dev_company_size.jpg>
LaTeX Font Info: Font shape `OT1/ptm/bx/n' in size <8> not available
(Font) Font shape `OT1/ptm/b/n' tried instead on input line 241.
LaTeX Font Info: Font shape `OMS/ptm/m/n' in size <8> not available
(Font) Font shape `OMS/cmsy/m/n' tried instead on input line 253.
[14 <./images/vdc_embedded_dev_company_size.jpg>]
LaTeX Font Info: Font shape `OT1/ptm/bx/it' in size <14.4> not available
(Font) Font shape `OT1/ptm/b/it' tried instead on input line 287.
<./images/embedded-processor-trends-sm.jpg, id=64, 301.125pt x 223.84514pt>
File: ./images/embedded-processor-trends-sm.jpg Graphic file (type jpg)
<use ./images/embedded-processor-trends-sm.jpg>
LaTeX Warning: `h' float specifier changed to `ht'.
[15] <./images/ELF_Link_exec1.png, id=68, 509.905pt x 312.16624pt>
File: ./images/ELF_Link_exec1.png Graphic file (type png)
<use ./images/ELF_Link_exec1.png> [16 <./images/embedded-processor-trends-sm.jp
g> <./images/ELF_Link_exec1.png (PNG copy)>]
LaTeX Font Info: Try loading font information for OML+ptm on input line 337.
(/usr/share/texmf-texlive/tex/latex/psnfss/omlptm.fd
File: omlptm.fd
)
LaTeX Font Info: Font shape `OML/ptm/m/n' in size <8> not available
(Font) Font shape `OML/cmm/m/it' tried instead on input line 337.
[17]
<./images/SW_design_flow.png, id=76, 564.1075pt x 438.63875pt>
File: ./images/SW_design_flow.png Graphic file (type png)
<use ./images/SW_design_flow.png> [18 <./images/SW_design_flow.png (PNG copy)>]
[19]
Underfull \hbox (badness 10000) in paragraph at lines 491--492
[]
Overfull \hbox (72.41374pt too wide) in paragraph at lines 496--497
[][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][
][]
[]
) (./main.bbl [20]
Underfull \hbox (badness 10000) in paragraph at lines 26--29
[][]\OT1/ptm/m/n/8 Venture De-vel-op-ment Corp. Small teams dom-i-nate em-bed-
ded soft-ware de-vel-op-ment.
[]
) [21
] (./main.aux)
LaTeX Warning: There were undefined references.
)
Here is how much of TeX's memory you used:
5331 strings out of 94834
67806 string characters out of 1179181
152743 words of memory out of 1500000
8415 multiletter control sequences out of 10000+50000
38234 words of font info for 65 fonts, out of 1200000 for 2000
212 hyphenation exceptions out of 8191
34i,9n,49p,1368b,1776s stack positions out of 5000i,500n,6000p,200000b,5000s
{/usr/share/texmf-texlive/fonts/enc/dvips/base/8r.enc}</usr/share/texmf-texli
ve/fonts/type1/bluesky/cm/cmmi8.pfb></usr/share/texmf-texlive/fonts/type1/blues
ky/cm/cmsy10.pfb></usr/share/texmf-texlive/fonts/type1/bluesky/cm/cmsy7.pfb></u
sr/share/texmf-texlive/fonts/type1/bluesky/cm/cmsy8.pfb></usr/share/texmf-texli
ve/fonts/type1/urw/courier/ucrr8a.pfb></usr/share/texmf-texlive/fonts/type1/urw
/times/utmb8a.pfb></usr/share/texmf-texlive/fonts/type1/urw/times/utmbi8a.pfb><
/usr/share/texmf-texlive/fonts/type1/urw/times/utmr8a.pfb></usr/share/texmf-tex
live/fonts/type1/urw/times/utmr8a.pfb></usr/share/texmf-texlive/fonts/type1/urw
/times/utmri8a.pfb>
Output written on main.pdf (22 pages, 648643 bytes).
PDF statistics:
123 PDF objects out of 1000 (max. 8388607)
0 named destinations out of 1000 (max. 131072)
46 words of extra memory for PDF output out of 10000 (max. 10000000)

BIN
course/.docs/cambio_categoria/main.pdf Normal file
View File

Binary file not shown.

56
course/.docs/cambio_categoria/main.tex.backup Normal file
View File

@@ -0,0 +1,56 @@
\documentclass[]{report}
\usepackage{fontenc}
\usepackage[latin1]{inputenc}
\usepackage[spanish]{babel}
% \usepackage{pgf}
\usepackage{graphicx}
\usepackage{times}
\usepackage{colortbl}
\usepackage{multicol}
\usepackage{multirow}
\usepackage{pdfpages}
\usepackage{lscape}
\usepackage{graphicx, color}
\usepackage{listings}
\lstset{language=C}
% \lstset{ basicstyle=\small, keywordstyle=\color{blue}\bfseries, identifierstyle=, commentstyle=\color{gray}, showstringspaces=false, keywordstyle=\color{blue}, morekeywords={one,three,five}}
\lstset{backgroundcolor=\color{gray},frame=single,emph={EMPTY},emphstyle=\color{white}, showstringspaces=false,commentstyle=\itshape, morekeywords={printf} }
%\lstset{framexleftmargin=5mm, frame=shadowbox, rulesepcolor=\color{black}, backgroundcolor=\color[gray]{.9}}
\lstset{backgroundcolor=\color[gray]{.9}}
\pagestyle{myheadings}
\markboth{Codise<73>o y Sistemas Embebidos}{emQbit LTDA}
\usepackage{longtable}
\parindent 1cm
\parskip 0.2cm
\topmargin 0.2cm
\oddsidemargin 1cm
\evensidemargin 0.5cm
\textwidth 15cm
\textheight 21cm
\begin{document}
\bibliographystyle{unsrt}
\input title
\tableofcontents
\parindent=1cm %Sangr<67>a de 1.5 cm al comienzo de cada p<>rrafo
\input introduction
\input chapter1
% \input information}
\bibliography{biblio_EL}
\end{document}

56
course/.docs/cambio_categoria/main.tex~ Normal file
View File

@@ -0,0 +1,56 @@
\documentclass[]{report}
\usepackage{fontenc}
\usepackage[latin1]{inputenc}
\usepackage[spanish]{babel}
% \usepackage{pgf}
\usepackage{graphicx}
\usepackage{times}
\usepackage{colortbl}
\usepackage{multicol}
\usepackage{multirow}
\usepackage{pdfpages}
\usepackage{lscape}
\usepackage{graphicx, color}
\usepackage{listings}
\lstset{language=C}
% \lstset{ basicstyle=\small, keywordstyle=\color{blue}\bfseries, identifierstyle=, commentstyle=\color{gray}, showstringspaces=false, keywordstyle=\color{blue}, morekeywords={one,three,five}}
\lstset{backgroundcolor=\color{gray},frame=single,emph={EMPTY},emphstyle=\color{white}, showstringspaces=false,commentstyle=\itshape, morekeywords={printf} }
%\lstset{framexleftmargin=5mm, frame=shadowbox, rulesepcolor=\color{black}, backgroundcolor=\color[gray]{.9}}
\lstset{backgroundcolor=\color[gray]{.8}}
\pagestyle{myheadings}
\markboth{Codise<EFBFBD>o y Sistemas Embebidos}{Universidad Nacional de Colombia}
\usepackage{longtable}
\parindent 1cm
\parskip 0.2cm
\topmargin 0.2cm
\oddsidemargin 1cm
\evensidemargin 0.5cm
\textwidth 15cm
\textheight 21cm
\begin{document}
\bibliographystyle{unsrt}
\input title
\tableofcontents
\parindent=1cm %Sangr<67>a de 1.5 cm al comienzo de cada p<>rrafo
\input introduction
\input chapter1
% \input information}
\bibliography{biblio_EL}
\end{document}

20
course/.docs/cambio_categoria/main.toc Normal file
View File

@@ -0,0 +1,20 @@
\select@language {spanish}
\contentsline {chapter}{\numberline {1}Introducci\'on}{3}
\contentsline {chapter}{\numberline {2}Conceptos B\'asicos de los Sistemas Embebidos}{7}
\contentsline {section}{\numberline {2.1}Definici\'on}{7}
\contentsline {section}{\numberline {2.2}Caracter\IeC {\'\i }sticas}{7}
\contentsline {section}{\numberline {2.3}Arquitectura}{7}
\contentsline {section}{\numberline {2.4}Metodolog\IeC {\'\i }a de Dise\~no}{9}
\contentsline {subsection}{\numberline {2.4.1}Herramientas Software de libre distribuci\'on \textit {GNU toolchain}}{11}
\contentsline {subsection}{\numberline {2.4.2}Componentes del \textit {GNU toolchain} }{11}
\contentsline {subsection}{\numberline {2.4.3}GNU binutils\cite {A1}}{11}
\contentsline {subsection}{\numberline {2.4.4}GNU Compiler Collection\cite {Wik}}{12}
\contentsline {subsubsection}{Lenguajes}{12}
\contentsline {subsubsection}{Arquitecturas}{13}
\contentsline {subsection}{\numberline {2.4.5}GNU Debugger}{14}
\contentsline {subsection}{\numberline {2.4.6}C Libraries}{15}
\contentsline {section}{\numberline {2.5}Obtenci\'on y utilizaci\'on del \textit {GNU toolchain}}{15}
\contentsline {subsection}{\numberline {2.5.1}Conceptos Previos}{15}
\contentsline {subsubsection}{El formato \textbf {ELF}}{16}
\contentsline {subsection}{\numberline {2.5.2}Flujo de dise\~no software}{18}
\contentsline {section}{\numberline {2.6}Makefile}{19}

BIN
course/.docs/cambio_categoria/src/hello Executable file
View File

Binary file not shown.

17
course/.docs/cambio_categoria/src/hello.c Normal file
View File

@@ -0,0 +1,17 @@
#include <stdio.h>
int global;
int global_1 =7;
int main(void)
{
int local_i; // Variable no inicializada
int local_j = 8; // Variable inicializada
for(local_i=0; local_i<10; local_i++){
printf("Printing %d\n", local_i*local_j); // Caracteres constantes
local_j = local_j + 1;
global = local_i;
global_1 = local_i+local_j;
}
return 0;
}

BIN
course/.docs/cambio_categoria/src/hello.o Normal file
View File

Binary file not shown.

BIN
course/.docs/cambio_categoria/src/test Executable file
View File

Binary file not shown.

41
course/.docs/cambio_categoria/title.tex Normal file
View File

@@ -0,0 +1,41 @@
% Title Page
\title{Sistemas Embebidos: Teor<6F>a, Implementaci<63>n y Metodolog<6F>as de Dise<73>o \\
\bigskip \bigskip \bigskip
\bigskip \bigskip \bigskip
UNIVERSIDAD NACIONAL DE COLOMBIA\\
\bigskip \bigskip \bigskip
\bigskip \bigskip \bigskip
}
\author{Carlos Iv<49>n Camargo Bare<72>o}
\maketitle
\newpage
\thispagestyle{empty}
\parindent0pt
{\scshape Informe Final}\\
Sistemas Embebidos: Teor<6F>a, Implementaci<63>n y Metodolog<6F>as de Dise<73>o\\
\textsc{Author:} C.~Camargo\\
\textsc{e-mail:} cicamargoba@unal.edu.co\\
\vfill
Copyright \copyright 2004, 2005\ Universidad Nacional de Colombia\\
\texttt{http://www.unal.edu.co}\\
Permission is granted to copy, distribute and/or modify this document
under the terms of the \textsc{gnu} Free Documentation License, version
1.2, with no invariant sections, no front-cover texts, and no back-cover
texts. A copy of the license is included in the end.\\
This document is distributed in the hope that it will be useful, but
without any warranty; without even the implied warranty of merchantability
or fitness for a particular purpose.\\
Published by the Universidad Nacional de Colombia\\
\newpage
\normalsize
\thispagestyle{empty}

41
course/.docs/cambio_categoria/title.tex.backup Normal file
View File

@@ -0,0 +1,41 @@
% Title Page
\title{UNIVERSIDAD NACIONAL DE COLOMBIA\\
\bigskip \bigskip \bigskip
\bigskip \bigskip \bigskip
Proyecto de Investigaci<63>n:\\
\bigskip \bigskip \bigskip
\bigskip \bigskip \bigskip
Sistemas Embebidos: Teor<6F>a, Implementaci<63>n y Metodolog<6F>as de Dise<73>o}
\author{Carlos Iv<49>n Camargo Bare<72>o}
\maketitle
\newpage
\thispagestyle{empty}
\parindent0pt
{\scshape Informe Final}\\
Sistemas Embebidos: Teor<6F>a, Implementaci<63>n y Metodolog<6F>as de Dise<73>o\\
\textsc{Author:} C.~Camargo\\
\textsc{e-mail:} cicamargoba@unal.edu.co\\
\vfill
Copyright \copyright 2004, 2005\ Universidad Nacional de Colombia\\
\texttt{http://www.unal.edu.co}\\
Permission is granted to copy, distribute and/or modify this document
under the terms of the \textsc{gnu} Free Documentation License, version
1.2, with no invariant sections, no front-cover texts, and no back-cover
texts. A copy of the license is included in the end.\\
This document is distributed in the hope that it will be useful, but
without any warranty; without even the implied warranty of merchantability
or fitness for a particular purpose.\\
Published by the Universidad Nacional de Colombia\\
\newpage
\normalsize
\thispagestyle{empty}

41
course/.docs/cambio_categoria/title.tex~ Normal file
View File

@@ -0,0 +1,41 @@
% Title Page
\title{UNIVERSIDAD NACIONAL DE COLOMBIA\\
\bigskip \bigskip \bigskip
\bigskip \bigskip \bigskip
Proyecto de Investigaci<63>n:\\
\bigskip \bigskip \bigskip
\bigskip \bigskip \bigskip
Sistemas Embebidos: Teor<6F>a, Implementaci<63>n y Metodolog<6F>as de Dise<73>o}
\author{Carlos Iv<49>n Camargo Bare<72>o}
\maketitle
\newpage
\thispagestyle{empty}
\parindent0pt
{\scshape Informe Final}\\
Sistemas Embebidos: Teor<6F>a, Implementaci<63>n y Metodolog<6F>as de Dise<73>o\\
\textsc{Author:} C.~Camargo\\
\textsc{e-mail:} cicamargoba@unal.edu.co\\
\vfill
Copyright \copyright 2004, 2005\ Universidad Nacional de Colombia\\
\texttt{http://www.unal.edu.co}\\
Permission is granted to copy, distribute and/or modify this document
under the terms of the \textsc{gnu} Free Documentation License, version
1.2, with no invariant sections, no front-cover texts, and no back-cover
texts. A copy of the license is included in the end.\\
This document is distributed in the hope that it will be useful, but
without any warranty; without even the implied warranty of merchantability
or fitness for a particular purpose.\\
Published by the Universidad Nacional de Colombia\\
\newpage
\normalsize
\thispagestyle{empty}