1
0
mirror of git://projects.qi-hardware.com/nn-usb-fpga.git synced 2025-04-21 12:27:27 +03:00
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

View File

@@ -102,7 +102,7 @@ static int __init blink_init(void)
{
printk(KERN_INFO "BLINK module is Up.\n");
Major = register_chrdev(252, DEVICE_NAME, &fops);
Major = register_chrdev(0, DEVICE_NAME, &fops);
if (Major < 0) {
printk(KERN_ALERT "Registering char device failed with %d\n", Major);

View File

@@ -34,6 +34,7 @@ main ()
JZ_PIO *pio;
int *virt_addr;
// Set GPIOB26 as part of External Memory Controller
pio = jz_gpio_map (CS2_PORT);
jz_gpio_as_func (pio, CS2_PIN, 0);
@@ -51,9 +52,10 @@ main ()
printf ("Writing Memory..\n");
srand48(0x3c);
// srand48(0x3c);
for (i = 0; i < FPGA_SIZE/4; i++)
// virt_addr[i] = (lrand48() & 0x00ff);
virt_addr[i] = (lrand48() & 0x00ff);
printf ("Reading Memory..\n");

2131
course/.docs/book/biblio.bib Normal file

File diff suppressed because it is too large Load Diff

File diff suppressed because it is too large Load Diff

View File

@@ -0,0 +1,367 @@
\chapter{Copyleft HW/SW y el Conocimiento Como Bien Com<6F>n}
\label{ch:common}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%% El conocimiento como bien com<6F>n %%%%%%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\section{Introducci<EFBFBD>n}
Es indudable que el desarrollo tecnol<6F>gico de un pa<70>s se encuentra ligado al mejoramiento de la calidad de vida de sus habitantes, y que para que un pa<70>s en v<>a de desarrollo se realice una transferencia tecnol<6F>gica (y de conocimientos asociados a la tecnolog<6F>a que se transfiere) exitosa que permita desarrollar productos similares, pero ajustados al contexto socio-econ<6F>mico local, es necesario que el pa<70>s cuente con la capacidad de absorber las habilidades, t<>cnicas, informaci<63>n y organizaci<63>n asociadas a dicha tecnolog<6F>a. Esta absorci<63>n de conocimientos debe ser realizada por un gran n<>mero de personas para que la transferencia tenga un impacto significativo en la sociedad, este conocimiento debe ser considerado como un bien p<>blico, y como tal, el acceso a <20>l, debe ser un derecho y por lo tanto, la sociedad debe garantizar los mecanismos de difusi<73>n para que llegue a los sectores de la sociedad interesados en <20>l. De igual forma, es un deber, de los sectores que utilizan este bien com<6F>n contribuir a su difusi<73>n, actualizaci<63>n, mejoramiento, y crecimiento.
Un bien com<6F>n es un recurso compartido que es vulnerable a dilemas sociales, es el resultado de interacciones entre personas y recursos, las cuales pueden ser positivas o negativas. El concepto de bien com<6F>n esta asociado a la \textit{libertad de expresi<73>n}, \textit{libre acceso} y \textit{autogobierno}
El conocimiento en este trabajo se refiere a las ideas intangibles, informaci<63>n y datos de todo tipo en que el conocimiento es expresado u obtenido, como todo tipo de entendimiento adquirido a trav<61>s de la experiencia o estudio ya sea propio, cient<6E>fico, acad<61>mico o no acad<61>mico. El conocimiento puede ser visto como una mercanc<6E>a y como una fuerza constitutiva de la sociedad lo que evidencia la naturaleza compleja de este recurso, adicionalmente, la adqusici<63>n y descubrimiento de conocimiento es un proceso social y personal. \textit{El descubrimiento de conocimiento es un bien com<6F>n y un tesoro que dejamoa a futuras generaciones y el reto de nuestra generaci<63>n es en mantener los caminos del descubrimiento abiertos}.
El acceso al conocimiento debe garantizarse sin restricci<63>n alguna a las personas interesadas, al considerar el conocimiento como un producto comercial se limita su difusi<73>n favoreciendo a un grupo de la poblaci<63>n, lo cual es inaceptable, ya que representa una forma de discriminaci<63>n. En nuestro pais, el acceso a la informaci<63>n ha ido aumentando gracias a la aparici<63>n de Internet y a la gran cantidad de proyectos existentes que buscan difundir todo tipo de conocimientos. Sin embargo, para poder asimilar este conocimiento se requieren ciertas habilidades que se adquieren despu<70>s de un procesos de ense<73>anza formal. En Colombia el acceso a la educaci<63>n superior de calidad es limitado, la cobertura de las Universidades p<>blicas est<73> limitada por la inversi<73>n del estado, y como pudimos ver anteriormente, en nuestro pa<70>s la preocupaci<63>n actual es la seguridad y no la educaci<63>n. Por lo tanto, hacer del conocimiento un bien com<6F>n requiere la intervenci<63>n de diferentes sectores que garanticen y regulen el acceso, generen, clasifiquen y administren la forma en la que se expresa el conocimiento.
La diferencia entre esta propuesta y las existentes promovidas por los organismos gubernamentales, es el <20>nfasis en la transferencia y difusi<73>n del conocimiento, del \textit{saber hacer}, muchas pol<6F>ticas existentes se enfocan en la compra de equipo, lo que, como se vi<76> antes no es el canal m<>s eficiente para la transferencia tecnol<6F>gica. Nuestros esfuerzos est<73>n enfocados a crear un conocimiento b<>sico en la Concepci<63>n, Dise<73>o, Implementaci<63>n y Dise<73>o de Sistemas Embebidos. Este conocimiento es el resultado de a<>os de experimentaci<63>n e investigaci<63>n en el <20>rea, al ser colocado a disposici<63>n de usuarios interesados, se aumentan las posibilidades de difusi<73>n, ya que ya se realiz<69> un trabajo previo de "adaptaci<63>n" a las condiciones de la plataforma tecnol<6F>gica local y al contexto econ<6F>mico y social. En la actualidad existen instituciones educativas que proporcionan conocimientos similares pero no tienen la profundidad del presente estudio y limitan el acceso a esta informaci<63>n cobrando altos precios para acceder a ella.
En este cap<61>tulo estudiaremos las licencias \textit{Creative Commons} una nueva forma de licenciamiento que permite asignar diferentes "permisos" de utilizaci<63>n a un determinado trabajo y puede ser utilizadas tanto en Software como en Hardware. Exploraremos el movimiento de Software Libre y C<>digo Abierto (FOSS) y como este contribuye a la transferencia tecnol<6F>gica y como millones de usuarios a lo largo y ancho del mundo trabajan de forma conjunta para difundir, actualizar, mejorar, y aumentar las aplicaciones disponibles. Adicionalmente se presenta una propuesta a la creaci<63>n de un movimiento que funcione con pol<6F>ticas similares pero centrado en el Desarrollo Hardware.
\section{El Conocimiento Como Bien Com<6F>n}
El an<61>lisis del conocimiento como bien com<6F>n tiene sus bases en el estudio de recursos naturales compartidos (agua, bosques, fauna, flora). El recurso puede ser peque<75>o y ser utilizado por un grupo reducido (El televisor familiar), puede ser de nivel comunitario (campos de juego, bibliotecas, paruqes etc) o pueden tener naturaleza internacional y mundial (oceanos, atm<74>sfera, internet, conocimiento cient<6E>fico, etc), puden ser delimitados (la librer<65>a comunitaria), transfronterizos (El rio Amazonas, Internet, vida salvaje migratoria, etc) o sin l<>mites claros (el conocimiento, la capa de ozono, etc). Adicionalmnete, existe una diferencia entre el bien com<6F>n como un recurso o sistema de recursos y el bien com<6F>n como un r<>gimen de derechos de propiedad\cite{EO90}. El conocimiento posee caracter<65>sticas que lo diferencian de los recursos naturales, mientras muchos bienes comunes ven comprometido su sostenimiento a medida que aumenta el n<>mero de usuarios, el objetivo de utilizar el conocimiento como bien com<6F>n es lograr su m<>xima difusi<73>n. El beneficio asociado al acceso a la informaci<63>n depende de la calidad de esta, a mayor calidad mayor el beneficio.
El conocimiento, al igual que otros bienes comunes es utilizado de forma conjunta y es manejado por grupos de diversos intereses y tama<6D>os. Para que este recurso sea <20>til se requiere una infra-estructura que permita su difusi<73>n, actualizaci<63>n, mejoramiento, realimentaci<63>n y crecimiento. Pero como administrar un recurso intangible y distribuido como el conocimiento? Como coordinar acciones de miembros que se encuentran localizados en diferentes puntos geogr<67>ficos?
Como coordinar acciones de miles de usuarios para garantizar un recurso <20>til y sostenible? Como convertir este conocimiento en motor de Desarrollo y crecimiento empresarial? Estas preguntas ser<65>n respondidas a lo largo de este cap<61>tulo.
\subsection{Auto-Gobierno}
Ostrom \cite{Ost00} argumenta que la forma m<>s eficiente de administrar un bien com<6F>n es el auto-gobierno ejercido por beneficiarios de dicho recurso. Si estos beneficiarios son conscientes de la importancia de un uso eficiente y racionado que garantice la existencia de este bien y toda acci<63>n o decisi<73>n que se haga es formulada pensando en el beneficio com<6F>n se crear<61>n normas que garantizan el beneficio de todos los usuarios y la sostenibilidad del recurso. El auto-gobierno requiere acciones colectivas que "emergen cuando se requiere el esfuerzo de dos o m<>s individuos para cumplir con una meta" \cite{ST92}. Otro aspecto importante de las acciones colectivas es que son voluntarias por parte de los individuos \cite{MMDG04}. El autogobierno requiere de la acci<63>n combinada de conociminto y voluntad unido a normas institucionales consistentes.
Ostrom \cite{EO92} y Baland and Platteau \cite{J.B96}, consideran que los atributos necesarios para que un recurso tenga una probabilidad alta de crear asociaciones de autogobierno son:
\begin{itemize}
\item Posibilidad de mejoramiento: El recurso no se encuentra en un punto tal que sea in<69>til crear una organizaci<63>n alrededor de <20>l.
\item Indicadores: Disponibilidad de indicadores confiables y v<>lidos sobre la condici<63>n del recurso.
\item Predictibilidad: El flujo de unidades de recurso es relativamente predecible.
\item El recurso es lo suficientemente peque<75>o, teniendo en cuenta las tecnolog<6F>as de comunicaci<63>n utilizadas, para que los usuarios pueden tener un conocimiento preciso de los l<>mites externos y de los micro-ambientes internos.
\end{itemize}
Y los atributos de los usuarios del recurso son:
\begin{itemize}
\item Prominencia: Los usuarios dependen del recurso para una parte importante de su sostenimiento.
\item Entendimiento com<6F>n: Conocimiento sobre el funcionamiento del sistema y como acciones individuales afectan a los dem<65>s y al sistema.
\item Baja Tasa de Descuento: Para obtener un mayor beneficio a futuro se deben mantener tasas bajas de descuento del recurso.
\item Confianza y Reciprocidad: Los usuarios del recurso conf<6E>an en que los dem<65>s mantendr<64>n las promesas y se relacionar<61>n entre ellos con reciprocidad.
\item Autonom<6F>a: Los usuarios pueden determinar reglas sin la intervenci<63>n de autoridades externas
\item Experiencia Previa en Organizaci<63>n y Liderazgo Local: Los usuarios poseen habilidades m<>nimas de organizaci<63>n y liderazgo a trav<61>s de la participaci<63>n en otras asociaciones locales o eprendiendo de organizaciones en grupos cercanos.
\end{itemize}
De los anteriores atributos podemos deducir que para que pueda emerger un auto-gobierno asociado a un recurso debe existir un excelente canal de comunicaci<63>n entre los usuarios de dicho recurso y que todos ellos deben conocer y aceptar una serie de normas (creadas por ellos mismos) que fueron formuladas pensando en el beneficio com<6F>n, un grupo de estas normas debe establecer mecanismos de resoluci<63>n de conflictos, esto es vital ya que toda la organizaci<63>n se basa en la confianza mutua y no puede permitirse que las relaciones entre los usuarios se deteriore. Adicionalmente se requiere de miembros que tengan claro que el <20>xito de sus acciones y el sostenimiento del recurso depende de sus acciones, las cuales deben realizarse teniendo en cuenta el beneficio com<6F>n. El conocimiento no se ve afectado por la sustracci<63>n (uso) del mismo, todo lo contrario, el objetivo es obtener el m<>ximo n<>mero de usuasrios, sin embargo, este conocimiento puede llegar a ser obsoleto r<>pidamente, (en especial en el <20>rea de la Electr<74>nica digital) y por lo tanto inservible, para que esto no suceda se requiere de la actualizaci<63>n de este conocimiento para que refleje el estado actual en un <20>rea determinada.
\subsubsection{Ecuaci<EFBFBD>n Costo Beneficio de Ostrom}
La pregunta que trata de responder Ostrom en su estudio es como emerge el auto-gobierno? \cite{Ost00} Para contestar esto formula una ecuaci<63>n que describe el an<61>lisis costo-beneficio que un individuo realiza para participar en un gobierno comunal:
\begin{lstlisting}[]
D < C (C1 + C2 + C3)
\end{lstlisting}
Donde ($D$) es el incentivo al cambio y compara los beneficios de utilizar las reglas tradicionales (BO) frente a los beneficios de utilizar un nuevo grupo de reglas basadas en un gobierno comunal (BN)
\begin{lstlisting}
D = BN - BO
\end{lstlisting}
C1 costo anticipado asociado a la transici<63>n.
C2 el costo de corto plazo para adoptar y apropiar las nuevas estrategias.
C3 Costos de largo plazo: mantenimiento, monitoreo y auto-gobierno.
Para que se realice el cambio el incentivo al cambio debe ser mayor que los costos asociados a el.
\begin{lstlisting}
BN - BO > C
BN > BO + C
\end{lstlisting}
Complejidades adicionales resultan de la interacci<63>n entre sub-grupos de usuarios, esta ecuaci<63>n puede ser diferente para cada participante, por lo que es normal encontrar coaliciones y acciones.
En la actualidad obervamos que grandes multinacionales como Nokia, Motorola o Google, est<73>n participando y promoviendo el desarrollo de productos y aplicaciones \cite{Mot} \cite{And} \cite{Mae} con la participaci<63>n de la comunidad, lo que representa un giro de 180 grados en la pol<6F>ticas lideradas por multinacionales como Microsoft y Aple en las que todas sus creaciones est<73>n protegidas por licencias, acuerdos comerciales y contratos de exclusividad que restringen la participaci<63>n en su desarrollo y aseguran el monopolio de los resultados de sus investigaciones. El movimiento de Software Libre \cite{FSF} hizo posible este cambio, proporcionando herramientas de desarrollo y facilidades para que cualquier persona alrededor del mundo pudiera realizar sus propias aplicaciones, gracias a esto se han creado aplicaciones como el servidor Web Apache, el explorador Mozilla el sistema operativo Linux, aplicaciones como gimp, openoffice, librer<65>as como ncurses, Qt y entornos de trabajo como xfce, gnome y KDE. El trabajo realizado por miles de programadores para llegar a este estado ha sido enorme, y por esta raz<61>n los grandes multinacionales est<73>n poniendo sus ojos en estas iniciativas ya que les representa un gran ahorro de dinero, es decir, el costo de participar en estas iniciativas es mucho menor que el beneficio obtenido por participar en ellas.
\subsubsection{Principios de Dise<73>o}
El primer paso para gobernar un bien com<6F>n es la identificaci<63>n de los principios de dise<73>o de un recurso com<6F>n robusto de larga duraci<63>n. Ostrom \cite{EO90} despu<70>s de dirigir un gran n<>mero de estudios emp<6D>ricos sobre gobernancia de recursos de bienes com<6F>nes. Encontr<74> una serir de principios de dise<73>o que hacen que el recurso sea sostenible a lo largo del tiempo. Los principales son:
\begin{itemize}
\item Fronteras claramente definidas
\item Las reglas deben reflajar necesidades y condiciones locales.
\item Los individuos sujetos a estas reglas pueden modificar y participar en la elaboraci<63>n de estas reglas.
\item Las autoridades externas deben respetar el derecho de los miembros de la comunidad a cear sus propias reglas.
\item Debe establecerse un sistema de seguimiento propio.
\item Disponibilidad de un sistema gradual de sanciones.
\item Acceso por parte de miembros de la comunidad a mecanismos de resoluci<63>n de conflictos de bajo costo.
\item Las actividades de apropiaci<63>n, suministro, monitoreo y sanci<63>n deben ser organizadas en estructuras anidadas con m<>ltiples capas de actividades
\end{itemize}
Es importante mencionar que no existe una combinaci<63>n de principios que garantice el <20>xito, es necesario probar con este set para identificar los principios generales que deben incluir los sistemas robustos. Estos ocho factores fueron encontrados en la mayor<6F>a de las instituciones analizadas en cientos de estudios y constituyen un buen punto de partida para comenzar esta investigaci<63>n. Estos ocho puntos se encuentran fuertemente relacionados con los atributos que requiere un recurso y un usario de este recurso para que pueda emerger un auto-gobierno y buscan que todos los participantes tengan pleno conocimiento de las reglas que monitorean, regulan, fijan y controlan las actividades de los miembros.
\subsubsection{Movimiento FOSS}
Es interesante consoiderar como este pensamiento aplica a proyectos de C<>digo Abierto. El Software no es un recurso t<>pico, porque no es sustraible, no existe un costo si un usuario decide usarlo o no. Sin embargo, es un bien com<6F>n, ya que es un recurso comunal que prospera o decae gracias a la contribuci<63>n de sus miembros. Los participantes de este tipo de recurso es el grupo de contribuidores potenciales, en lugar del grupo de posibles propietarios. Un aporte de un usuario a mejorar el proyecto se traduce en un beneficio colectivo. Los contribuyentes pueden ser empresas que pagan a una persona para que adicione una nueva caracter<65>stica, sin embargo, ellos pueden decidir no compartir estos cambios para tener una ventaja competitiva. En la actualidad observamos las tendeencias de multinacionales como Nokia o Motorola a participar, crear y promover proyectos de Software Libre, desde el punto de vista comercial resulta mpas rentable utilizar harramientas que han sido desarrolladas, probadas, y depuradas por miles de usuarios calificados que pagar a un grupo de decenas de desarrolladores para trabajar en sistemos propietarios.
En los proyectos de C<>digo Abierto puede utilizarse una variaci<63>n modificada de la ecuaci<63>n de Ostrom \cite{AC09}:
\begin{lstlisting}
BC > BN + C
\end{lstlisting}
Donde $BC$ es el beneficio a contribuir, y debe superar el costo de contribuir $C$ m<>s el beneficio de no contribuir $BN$. La comunidad del Software Libre ha creado un grupo de normas e instituciones muy sofisticadas alrededor de esta ecuaci<63>n dando como resultado uno de los estructuras auto-gobernadas m<>s exitosas. Los trabajos de la comunidad de Software Libre hacen que $C$ sea cada vez m<>s peque<75>o, proporcionando:
\begin{itemize}
\item Herramientas de programaci<63>n, depuraci<63>n y librer<65>as que facilitan el desarrollo de nuevas aplicaciones o mejoras a las ya existentes.
\item Listas de discusi<73>n en donde los creadores de estas herramientas responden preguntas, y buscan en conjunto soluciones a problemas espec<65>ficos
\item Sistemas de control de versiones y protocolos de comunicaci<63>n.
\item Bases de datos de soluci<63>n de problemas asociadas a las listas de discusi<73>n.
\item Tutoriales, documentaci<63>n, libros disponibles on-line.
\end{itemize}
Para contribuyentes no comerciales el costo de no contribuir es cero, pero, para contribuyentes comerciales $BN$ puede resultar muy grande, ya que pagar una n<>mina de programadores para que dise<73>en un sistema propio desde cero es mucho m<>s costoso (en tiempo y en dinero) que pagar a pocos programadores pra utilizar y modificar proyectos ya existentes. La licencia m<>s utilizada en los proyectos de Software Libre es la GPL, la cual, aunque no cubre todos los posibles tipos de uso, impone fuertes sanciones (escarnio p<>blico y consecuencias legales) cuando se utiliza y mejora un proyecto, pero no se comparten estos cambios con la comunidad. M<>s adelante estudiaremos el movimiento FOSS del cual se puede aprender mucho para crear nuestra versi<73>n de \textit{Hadrware Copyleft}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%% FOSS %%%%%%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\section{FOSS}
Como se mencion<6F> anteriormente, el movimiento FOSS es la estructura auto-gobernada m<>s exitosa y ser<65> tomada como referencia en el desarrollo de nuestra iniciativa de Hardware Copyleft. Su principal innovaci<63>n radica en un nuevo esquema de licencias unido a herramientas de colaboraci<63>n basadas en Internet, lo que se cnvirti<74> en una nueva forma de bien com<6F>n, donde los miembros de forma colectiva generan un buen com<6F>n el \textit{software}. El desaf<61>o de FOSS es realizar \textit{acciones colectivas para crear y mantener este bien p<>blico}. A diferencia de la creencia popular, en este movimiento existen derechos de autor (\textit{copyright}) y propiedad, sin embargo, algunos individuos involucrados en el proyecto, poseen derechos legales sobre el c<>dico (recurso), tienen control sobre las nuevas versiones del software y pueden excluir a otros que aportan c<>digo a las nuevas distribuciones.
Los miembros del movimiento FOSS usualmente son programadores (y usuarios finales de software) que contribuyen (ya sea voluntariamente, o que se les pague para hacerlo) para producir un software bajo la licencia FOSS. La "situaci<63>n de acci<63>n" que estos programadores encaran es, si en alg<6C>n momento, vale la pena contribuir al desarrollo de este software. La interaci<63>n de programadores trabajando de forma conjunta en Internet puede ser visto como un resultado que puede cambiar en el tiempo. Schweik y Semenov \cite{SAS03} identificaron tres estados de este tipo de bien com<6F>n, una fase inicial, seguida por un estado de apertura y un estado m<>s maduro de gran crecimiento (en t<>rminos de usuarios y participaci<63>n), estabilizaci<63>n donde el n<>mero de participantes (normalmente peque<75>o) no var<61>a, o el protecto se estanca y muere (sin participantes). Para que un proyecto sea exitoso, no es necesaria la participaci<63>n de un gran n<>mero de programadores, es frecuente encontrar grupos peque<75>os de programadores con un gran n<>mero de usuarios. La clave del <20>xito est<73> en la disponibilidad de un programador para contribuir al esfuerzo colectivo de por lo menos un peque<75>o grupo de actores que producen y mantienen el software.
En la Figura \ref{framework_foss} se ilustra el marco definido por Ostrom y Hess \cite{CHEO06} para analizar el conocimiento como bien com<6F>n, aplicado al movimiento FOSS. Como se mencion<6F> anteriormente, el razgo que diferencia este movimiento es la utilizaci<63>n de una forma de licenciamiento especial. Richard Stallman \cite{Wikb}, a mediados de los 80 inici<63> un proyecto para desarrollar un sistema operativo abierto/libre basado en \textit{unix} llamado \textit{GNU} (GNU is Not unix).
\subsubsection{Reglas En Uso}
Stallman \cite{Sta99} sostiene que las propiedades digitales del software hacen posible considerarlo como un bien p<>blico, proporcionando a sus usuarios \textit{la libertad} de utilizarlo, distribuirlo y modificarlo. Esta filosf<73>a se basa en cuatro libertades que encarnan el principio \textit{copyleft}:
\begin{itemize}
\item Libertad de ejecutar el software para cualquier prop<6F>sito.
\item Libertad de estudiar como funciona el programa, y cambiarlo para hacer lo que se desee. El acceso al c<>digo fuente es una condici<63>n para esto.
\item Libertad para re-distribuir copias.
\item Libertad para distribuir copias de versiones modificadas. Lo que permite que la comunidad se beneficie de estos cambios. El acceso al c<>digo fuente es una condici<63>n para esto.
\end{itemize}
Esta filosof<6F>a permite que los conocimientos y habilidades que el programador posee puedan ser transferidas a programadores, empresas, instituciones acad<61>micas y sociedades, ya sea en forma de producto o como herramienta de ense<73>anza. Esta actividad representa un proceso de Transferencia Tecnol<6F>gica, en la que el que suministra la tecnolog<6F>a proporciona todos los medios para que el receptor pueda abosrverla y transformarla para satisfacer necesidades en su entorno social. Adicionalmente, Stallman ide<64> una forma de trabajar con las leyes de derechos de autor que proporciona una alternativa al licenciamiento tradicional. Las grandes multinacionales como Microsoft o Apple limitan el n<>mero de usuarios por licencia y hacen distribuciones de archivos binarios compilados en forma de ejecutables. El software con licencia \textit{copyleft} estipula que cualquier modificaci<63>n que se le realice adquiere los principios de licenciamiento del software original. La licencia \textit{GPL}\footnote{http://www.gnu.org/licenses/licenses.html} (GNU General Public License) fue creada para implementar estos principios.
\begin{figure}[H]
\begin{center} \includegraphics[scale=.6]{./images/framework_foss.png} \end{center}
\caption{Marco para analizar el conocimiento como bien com<6F>n aplicado al movimiento FOSS: Modificaci<63>n de: \cite{CHEO06} p<>g 46} \label{framework_foss}
\end{figure}
El proyecto de \textit{c<EFBFBD>digo abierto} liderado por Bruce Perens y Eric Raymond, utiliza las propiedades de la licencia GPL adicionando un grupo de \textit{derechos morales} dirigidos a conservar el trabajo del autor en su forma original, con el f<>n de conservar su autor<6F>a. Existe un gran n<>mero de variaciones de licenciamiento \footnote{http://www.opensource.org/licenses/alphabetical} para proyectos de Software Libre, lo que indica que al momento de licenciar un software el autor debe determinar que derechos retener y cuales regalar \cite{CMS06}. Las innovaciones del licenciamiento \textit{copyleft} constituyen las \textit{reglas en uso} que motivan a los programadores a participar en el movimiento FOSS, y establecen las bases de un r<>gimen de propiedad com<6F>n.
La clave para mantener un bien com<6F>n es la estructura de gobernanza de dicho recurso, el movimiento FOSS es un experimento en marcha, en dondes se prueba una mezcla imperfecta de liderazgo, mecanismos informales de coordinaci<63>n, normas impl<70>citas y expl<70>citas junto con estructuras de gobernanza formal que evolucionan de tal forma que han logrado mantener unido este sistema tan camplejo \cite{Web04}. Aunque no existe literatura que estudie las estructuras de gobernanza en el movimiento FOSS, algunas observaciones a los proyectos existentes en la actualidad indican que estas estructuras podr<64>an incluir:
\begin{itemize}
\item Priorizaci<63>n de caracter<65>sticas a incluir en nuevas versiones del software.
\item Definici<63>n de Reglas y procedimientos para evaluar y escoger nuevos aportes para que hagan parte de las nuevas versiones.
\item Definici<63>n de Reglas y procedimientos para detectar y corregir errores en el software.
\item Asignaci<63>n y administraci<63>n de tareas.
\item Asistencia en la resoluci<63>n de disputas entre miembros del equipo.
\end{itemize}
Estas reglas var<61>an dependiendo del estado del proyecto, ya que, las actividades que se deben realizar en cada etapa son diferentes, en la etapa inicial, se establece la comunidad de programadores que definen las especificaciones del software, por lo que las tarea m<>s importante son el reclutamiento de programadores y la definci<63>n de una estructura flexible para el software. Cuando el proyecto alcanza una determinada madurez, lo importante es a<>adir funcionalidades y corregir errores.
\subsubsection{Atributos de la Comunidad}
La comunidad FOSS esta compuesta por usuarios y programadores voluntarios motivados por intereses tecnol<6F>gicos, sociopol<6F>ticos, econ<6F>micos y acad<61>micos. Desde el punto de vista tecnol<6F>gico, resulta m<>s efectivo en tiempo y en dinero, participar en un proyecto conjunto para la realizaci<63>n de una aplicaci<63>n que satisface una determinada necesidad. La principal motivaci<63>n sociopol<6F>tica es la creencia por parte del programador en la filosof<6F>a del movimiento, en lalucha contra el monopolio del software, adicionalmente, para que el proyecto permenezca durante mucho tiempo, es necesario que sea atractivo para vincular el mayor n<>mero de participantes y de esta forma sobrevivir en el futuro. Las motivaciones econ<6F>micas y acad<61>micas pueden ser consideradas en forma conjunta ya que al participar en estos proyectos, los miembros adquieren o mejoran sus habilidades de programaci<63>n ya sea revisando, leyendo y entendiendo el c<>digo existente o sometiendo a la revisi<73>n de los dem<65>s miembros sus contribuciones. Por otro lado, esta participaci<63>n puede verse como una vitrina en donde el programador muestra sus capacidades y puede ser contactado por empresas para establecer relaciones comerciales. En los dos casos la participaci<63>n es una forma de inversi<73>n y una forma de ganar experiencia y reputaci<63>n \cite{VWJ+03}.
En proyectos con un gran n<>mero de personas asociadas, solo un peque<75>o porcentaje de ellos realizan la mayor parte del trabajo. En la actualidad muchas empresas est<73>n participando de forma activa en estos proyectos, aportando programadores pagados para que contribuyan con el desarrollo y mejoramiento del softeare. Un estudio realizado a 25 firmas participantes en el proyecto FOSS \textit{Linux Operating System} \cite{GGR02} indica que la tercera parte de los programadores encuestados son pagados por sus empleadores para participar, y que su motivaci<63>n a participar es el interes propio en estandarizaci<63>n, disminuci<63>n de costos, estrategias para debilitar a la competencia y esfuerzos para hacer sus productos compatibles con los productos derivados del movimiento FOSS.
\subsubsection{Atributos F<>sicos}
Existen tres categor<6F>as \cite{CMS06} en FOSS que pueden ser consideradas como atributos f<>sicos:
\begin{enumerate}
\item La utilidad del Software: Como vimos anteriormente, para que una persona participe en una actividad relacionada con el bien com<6F>n, el costo por no hacerlo debe ser mayor que el beneficio por participar, es decir, el software debe representar una utilidad grande para que valga la pena participar en el proyecto.
\item El dise<73>o o la estructura del software. Un c<>digo limpio (optimizado, documentado y <20>ptimo) y modularizado permite el trabajo en paralelo, lo que reduce el tiempo de depuraci<63>n y el requerido para implementar nuevas caracter<65>sticas.
\item La infraestructura que hace posible coordinar y administrar la colaboraci<63>n y la producci<63>n: El uso de Internet para soportar herramientas de control de versiones (como \textit{svn}, \textit{cvs} y \textit{git}) y la comunicaci<63>n v<>a listas de discusi<73>n hace posible coordinar de forma eficiente los esfuerzos de cooperaci<63>n. Permitiendo:
\begin{itemize}
\item Almacenar versiones de software.
\item La descarga de m<>dulos.
\item La adici<63>n de Nuevas contribuciones y la protecci<63>n del c<>digo existente.
\item Generar un historial donde se documentan los cambios realizados a lo largo del tiempo.
\item Analizar funciones para identificar diferencias entre versiones.
\item Informar a los miembros del equipo cambios en los m<>dulos del proyecto.
\end{itemize}
\end{enumerate}
Esta infraestructura trabaja junto con las reglas-en-uso establecidas para proporcionar procesos que direccionen nuevos trabajos, un sistema para recibir y revisar contribuciones de nuevos m<>dulos que pueden ser incluidos en futuras versiones.
En conclusi<73>n, los proyectos FOSS evolucionan en el tiempo como resultado de la configuraci<63>n de sus reglas-en-uso, atributos de la comunidad y atributos f<>sicos relacionados con la estructura del software para hacer f<>cil la colaboraci<63>n y herramientas efectivas para coordinaci<63>n de equipos y manejo de contenido.
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%% Copy Left %%%%%%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\section{Propiedad Intelectual y Licencias}
Para utilizar el paradigma colaborativo del movimiento FOSS para adaptarlo a cualquier forma de propiedad intelectual (incluyendo la creaci<63>n de hardware) es necesario ampliar el t<>rmino \textit{copyleft} de Stallman. El primer en esta direcci<63>n fu<66> dado por el mismo Stallman al desarrollar la licencia GFDL (GNU Free Documentation License) aplicable a todo tipo de documentaci<63>n t<>cnica, guias de usuario, tutoriales, etc. Esta licencia gobierna el uso, modificaci<63>n y distribuci<63>n de la documentaci<63>n del software GNU, especificando las secciones del documento que no puden ser modificadas (tales como autor, aviso de derechos de autor), los t<>rminos de distribuci<63>n.
\subsection{Licencias Creative Commons}
Creative Commons \footnote{http://creativecommons.org/} organizaci<63>n no gubernamental sin <20>nimo de lucro ha desarrollado una serie de licencias basadas en principios similares a los de Stallman y que puden ser aplicadas a trabajos realizados en m<>sica, arte, video, texto y notas de clase. Estas licencias permiten que el autor de un trabajo conserve la propiedad intelectual (los derechos asociados a esta) pero posibilitando su copia y distribuci<63>n, con la <20>nica condici<63>n de dar cr<63>ditos al autor \cite{CCb}. Se puede elegir diferentes permisos dependiendo de los deseos del autor, para definir dichos permisos CreativeCommons proporciona una serie de preguntas que buscan determinar los derechos que se desean conservar y los que desean liberar. Las preguntas claves son: 1) Los lectores pueden copiar y distribuir su trabajo libremente? 2) Es permitido a los usuarios crear trabajos derivados del contenido digital? Si es permitido, estas modificaciones deben tener la misma licencia que el trabajo original (esquema de licencia viral), o deben ser distribuidos bajo un esquema de licencias diferente? 3) Es necesario atribuir el trabajo al autor original?. Estas preguntas son la base para definir un esquema de licencias modular.
Existen cuatro bloques constructivos para las licencias Creative Commons estos son:
\begin{itemize}
\item \textit{Atribuci<EFBFBD>n} (\textbf{BY}): Se permite la distribuci<63>n pero se debe dar cr<63>dito al autor.
\item \textit{No comercial} (\textbf{NC}): Se permite la distribuci<63>n del trabajo sin fines comerciales, si se desea utilizar este trabajo para obtener dinero es necesaria una autorizaci<63>n del autor
\item \textit{No a trabajos derivados} (\textbf{ND}): Permite la copia y la distribuci<63>n del trabajo original sin modificaciones.
\item \textit{Compartir de la misma forma} (\textbf{SA}): Exige que todo trabajo derivado del uso de proyectos que con este esquema de licencias deben tener la misma licencia de los trabajos originales.
\end{itemize}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%% COPY LEFT HW %%%%%%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\section{Hardware Copyleft}
En esta secci<63>n se relizar<61> la definici<63>n del t<>rmino \textit{hardware copyleft} como una extensi<73>n del proyecto \textit{FOSS}. Una de las hip<69>tesis manejadas durante el desarrollo de este trabajo es que el conocimiento debe ser considerado como un bien com<6F>n y que los usuarios de este recurso deben utilizarlo de tal forma que se beneficie la comunidad asociada a dicho recurso. Como estrategia para obtener una transferencia tecnol<6F>gica y de conocimientos exitosa a la academia y a la industria electr<74>nica nacional (en el <20>rea de sistemas digitales) se utilizar<61> el principio del conocimiento como bien com<6F>n para crear una comunidad que utilice como recurso inicial el trabajo generado en este proyecto.
Los dispositivos digitales modernos poseen dos grandes componentes, el hardware que proporciona recursos como capacidad de c<>mputo, capacidad de almacenamiento, medios de comunicaci<63>n e interfaz con otros dispositivos y con el mundo real; y el software implementa una determinada funcionalidad utilizando los recursos hardware. Normalmente estos dispositivos est<73>n dise<73>ados para ejecutar una funci<63>n <20>nica, por lo que el componente hardware se encuentra optimizado (funcionalidad, tama<6D>o, consumo de potencia, costos) para la ejecuci<63>n de dicha tarea. Como se mencion<6F> anteriormente existe un movimiento muy fuerte (FOSS) que proporciona una gran variedad de herramientas para la implementaci<63>n del componente software. Sin embargo, hasta el momento no existe un movimiento similar dirigido al desarrollo del componente hardware. Mi hip<69>tesis es que un movimiento de hardware abierto permitir<69> el desarrollo de la industria electr<74>nica local permitiendo la transferencia exitosa de tecnolog<6F>a y conocimientos en el <20>rea de dise<73>o de sistemas embebidos.
Haciendo una analog<6F>a con el movimiento FOSS, la iniciativa \textit{hardware copyleft} permitir<69>a el uso, distribuci<63>n, y modificaci<63>n de proyectos hardware existentes. La acci<63>n de modificaci<63>n se origina por una necesidad que se debe satisfacer, implica un entendimiento del principio de funcionamiento y del proceso de fabricaci<63>n asociados al proyecto original. Lo anterior cumple con la definici<63>n de transferencia tecnol<6F>gica exitosa: ``\cite{Mo94} El problema de transfencia de conocimiento (o know-how) sobre un n<>mero de aspectos (que incluyen el conocimiento) sobre como funciona un determinado sistema, como operarlo y desarrollar sus aplicaciones, como mantenerlo y si es necesario, como producir sus componentes y montar un sistema similar. La transferencia tecnol<6F>gica se considera exitosa cuando los receptores de la tecnolog<6F>a asimilan los conceptos anteriores para suplir sus necesidades locales''.
El reto en la definici<63>n del concepto de \textit{hardware copyleft} radica en la naturaleza del componente hardware, a diferencia del software donde solo es necesario descargar el c<>digo fuente y las herramientas de compilaci<63>n para modificar un proyecto existente ; los proyectos hardware involucran procesos de fabricaci<63>n, montaje y pruebas que tienen asociados unos costos que var<61>an dependiendo de la tecnolog<6F>a utilizada (ASIC, PCB). Este costo representa un factor que afecta a los potenciales miembros de la comunidad, en el peor de los casos predefiniendo sus perfiles o limitando el acceso. Por este motivo, se debe considerar el impacto del factor econ<6F>mico en la formaci<63>n de la comunidad, definiendo las caracter<65>sticas que deben poseer estos proyectos para minimizar el costo asociado.
\subsection{Atributos de la Comunidad}
El <20>xito de la iniciativa \textit{FOSS} se debe en parte a la gran comunidad que comparte la ideolog<6F>a del software libre \cite{RS07},sus miembros buscan: satisfacer necesidades propias \cite{JK00}, aprendizaje \cite{HIH02}, reputaci<63>n dentro y fuera de la comunidad, asociaci<63>n e identidad \cite{GH03}, diversi<73>n y creatividad \cite{RAG+02}. Para que la propuesta \textit{hardware copyleft} sea una realidad, es importante identificar los motivos por los cuales estos individuos se unen a este tipo de comunidades y como las diferentes formas de gobierno afectan su participaci<63>n, y como esta experiencia exitos puede ser utilizada en nuestro movimiento.
Un estudio reciente, realizado sobre diferentes comunidades software \cite{SS06} \cite{KBCR10} revela que la raz<61>n inicial para la participaci<63>n es la necesidad de cambios, alteraciones o asistencia a proyectos existentes, su resultado se resumen en la tabla \ref{participation}. A pesar de que los costos de contribuci<63>n son relativamente altos en t<>rminos de tiempo y esfuerzo, muchos programadores se unen a esta comunidad buscando:
\begin{itemize}
\item \textit{Reciprocidad.} Una gran cantidad de los participantes en los proyectos software que fueron consultados en este estudio expresaban la necesidad de que la reciprocidad sea parte de las normas de la comunidad. Una gran parte de proyectos son liberados con el prop<6F>sito de suplir una necesidad, ya sea por la inexistencia de una herramienta que realice ciertas funciones o para reemplazar una comercial, sus autores buscan con esto que otras personas liberen sus trabajos para que puedan ser utilizados por la comunidad.
\item \textit{Mejoras.} Someter el c<>digo a la inspecci<63>n de miles de programadores ayuda a depurar y limpiar el c<>digo, adicionalmente se logra aumentar su funcionalidad y se aumenta el n<>mero de usuarios. Sin el apoyo de la comunidad estas mejoras tomar<61>an mucho tiempo o en algunos casos nunca se realizar<61>an.
\item \textit{Contribuci<EFBFBD>n con la escritura de c<>digo fuente.} Algunos de los miembros de estas comunidades son empleados de compa<70><61>as que utilizan resultados de estos proyectos en sus productos comerciales, y dentro de sus intereses est<73> incluir en las distribuciones oficiales funcionalidades creadas por ellos.
\item \textit{Motivos profesionales.} Razones como reputaci<63>n, desarrollo de habilidades tienen una importancia relativamente baja en la creaci<63>n y contribuci<63>n de c<>digo. La mayor<6F>a expresa que su participaci<63>n busca conocimiento espec<65>fico del proyecto y no para adquirir habilidades espec<65>ficas; al trabajar con programadores m<>s experimentados se agudizan o expanden ciertas habilidades.
\item \textit{Disfrute y Entretenimiento} Un gran porcentaje de los participantes con mayor tiempo de permanencia manifiestan que esta actividad les proporciona un pasatiempo desafiante; curiosamente este tipo de participantes superan en n<>mero a los que se participan para suplir necesidades.
\end{itemize}
\begin{center}
\begin{table}[H]
\begin{tabular}{|m{1.8cm}|p{3cm}|p{3cm}|p{2.5cm}|p{2.5cm}|} \hline
\textbf{Motivo para crear} & \textbf{Motivo para contribuir} & \textbf{Nivel de participaci<63>n} & \textbf{No. relativo de participantes} & \textbf{Conocimiento del c<>digo y estructura} \\ \hline
\multirow{5}{*}[-2cm]{\textbf{\textit{Necesidad}}}
& Reciprocidad; normas & Bajo & Alto & Limitado al <20>rea del problema inicial \\\cline{2-5}
& Mejoras futuras & Variable, depende de la necesidad & Moderada & En el <20>rea del problema \\\cline{2-5}
& Deseo de integrar
c<>digo propio en el
c<>digo fuente & Moderado a alto & Bajo & Variable \\\cline{2-5}
& Motivos profesionales & Bajo & Muy bajo & variable \\\cline{2-5}
& No contribuye & Muy bajo & NA & Limitado al <20>rea del problema inicial \\ \hline
\textbf{\textit{Diversi<EFBFBD>n y disfrute}}
& Realimentaci<63>n & Alto & Bajo & Comienza en un <20>rea determinada, y se expande \\ \hline
\end{tabular}
\caption{Motivaci<EFBFBD>n de la participaci<63>n de desarrolladores en proyectos de softawre libre. Fuente \cite{SS06} } \label{compet_4}
\end{table}
\end{center}
Este estudio concluye que muchos miembros de estas comunidades ingresan para suplir necesidades, pero muchos de ellos continuan creando c<>digo porque disfrutan programar. Estos \textit{aficionados} realizan un papel muy importante dentro de la comunidad encarg<72>ndose de tareas como mejora de la plataforma tecnol<6F>gica, re-escribiendo secciones de c<>digo, documentandolo, respondiendo preguntas, preservar o mejorar la arquitectura. Otros consideran que la reciprocidad es vital para la contribuci<63>n de c<>digo a la comunidad y que la forma de gobierno afecta dram<61>ticamente la participaci<63>n de programadores voluntarios.
\begin{center}
\begin{table}[H]
\begin{tabular}{|m{2.8cm}|c|} \hline
\textbf{Mecanismos de Gobierno} & \textbf{Motivo para contribuir} \\\hline
\multicolumn{2}{|c|} {Toma de decisiones} \\\hline
\multirow{3}{*}[-2cm]{\textit{Control del C<>digo}
& Limita las \\\hline
\end{tabular}
\end{table}
\end{center}
\subsection{Atributos F<>sicos}
\subsection{ECB\_AT91, ECBOT, ECB\_BFIN} Plataformas realizadas para adquirir experiencia en el dise<73>o de sistemas embebidos
detectar las habilidades que se necesitan para realizar el proceso
\subsection{Proyecto Qi-Hardware}
% whatever form or technol-
% ogy the land-use model utilizes (e.g., a computer program, a statistical
% script, and so on), it should be placed under some license that allows the
% free copying of the model, requires the model ?source? to be readable,
% and permits the development of new derivative components of the model
% or other products related to the model. In some instances, the
% model developers might decide to make all related products (e.g., the
% model modules, their documentation, data, and even theoretical papers)
% fall under these conditions. However, there will be situations where more
% restrictive licensing is warranted. For instance, empirical papers describ-
% ing a particular application of a model would probably be licensed with
% a ?no derivative work? component, because these types of papers report
% findings from a particular study at a particular time.
%
% INTERNET INTERNET
% Clearly, the Internet, as a technological advance, is as important a
% ?structural change? to the way scientific advances are communicated and
% collaborated on as was the printing press. Digital storage has become so
% cheap that many treat the saving of a file on a hard disk as nearly cost-
% less. Advances like the web and e-mail software have greatly reduced the
% costs or skills required to access information on the Internet. Over the
% last five to ten years, the Internet has moved from a domain utilized pri-
% marily by high-skilled computer scientists, engineers, or others in the
% high-tech industries, to a system utilized by scientists and scholars in all
% disciplines. We are now in a shake-up period where traditional organi-
% zations chartered with the management of scientific information (e.g.,
% libraries, publishers) are developing new organizational models and mis-
% sions built around computer database and connectivity issues (see, for
% example, chapters 4 and 11 in this book). This environment, where
% digital files can be copied and transferred globally in an instant and at
% very little cost, makes it much easier to treat information or knowledge
% as a global public good. But as other contributors to this book describe,
% these advances in technology are directly at odds with other societal
% trends and developments in intellectual copyright law that are pushing
% to treat information and other digital products as private goods for mon-
% etary gain (see chapters 5 and 7).
%
% To promote the argument made in the opening paragraph of this
% chapter?that the collaborative ideals and principles applied in FOSS
% projects are potentially applicable to any collaboration built around
% intellectual property?I first provide an overview and summary of the
% FOSS software ?movement? and describe some critical project compo-
% nents. I use the Institutional Analysis and Development Framework
% described in chapter 3 to help guide the description of these projects.
% Next, I provide more detail on the argument that the FOSS collabora-
% tive principles and approaches can extend more broadly to scientific
% research in general. At this juncture, I introduce the more recent inno-
% vation of ?open-content? licensing. Using a short example in the scien-
% tific field of land-use change modeling, I then provide a discussion of
% some critical issues that will need to be addressed in order to transfer
% the collaborative principles of FOSS software commons to scientific-
% commons endeavors.

View File

@@ -0,0 +1,367 @@
\chapter{Copyleft HW/SW y el Conocimiento Como Bien Com<6F>n}
\label{ch:common}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%% El conocimiento como bien com<6F>n %%%%%%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\section{Introducci<63>n}
Es indudable que el desarrollo tecnol<6F>gico de un pa<70>s se encuentra ligado al mejoramiento de la calidad de vida de sus habitantes, y que para que un pa<70>s en v<>a de desarrollo se realice una transferencia tecnol<6F>gica (y de conocimientos asociados a la tecnolog<6F>a que se transfiere) exitosa que permita desarrollar productos similares, pero ajustados al contexto socio-econ<6F>mico local, es necesario que el pa<70>s cuente con la capacidad de absorber las habilidades, t<>cnicas, informaci<63>n y organizaci<63>n asociadas a dicha tecnolog<6F>a. Esta absorci<63>n de conocimientos debe ser realizada por un gran n<>mero de personas para que la transferencia tenga un impacto significativo en la sociedad, este conocimiento debe ser considerado como un bien p<>blico, y como tal, el acceso a <20>l, debe ser un derecho y por lo tanto, la sociedad debe garantizar los mecanismos de difusi<73>n para que llegue a los sectores de la sociedad interesados en <20>l. De igual forma, es un deber, de los sectores que utilizan este bien com<6F>n contribuir a su difusi<73>n, actualizaci<63>n, mejoramiento, y crecimiento.
Un bien com<6F>n es un recurso compartido que es vulnerable a dilemas sociales, es el resultado de interacciones entre personas y recursos, las cuales pueden ser positivas o negativas. El concepto de bien com<6F>n esta asociado a la \textit{libertad de expresi<73>n}, \textit{libre acceso} y \textit{autogobierno}
El conocimiento en este trabajo se refiere a las ideas intangibles, informaci<63>n y datos de todo tipo en que el conocimiento es expresado u obtenido, como todo tipo de entendimiento adquirido a trav<61>s de la experiencia o estudio ya sea propio, cient<6E>fico, acad<61>mico o no acad<61>mico. El conocimiento puede ser visto como una mercanc<6E>a y como una fuerza constitutiva de la sociedad lo que evidencia la naturaleza compleja de este recurso, adicionalmente, la adqusici<63>n y descubrimiento de conocimiento es un proceso social y personal. \textit{El descubrimiento de conocimiento es un bien com<6F>n y un tesoro que dejamoa a futuras generaciones y el reto de nuestra generaci<63>n es en mantener los caminos del descubrimiento abiertos}.
El acceso al conocimiento debe garantizarse sin restricci<63>n alguna a las personas interesadas, al considerar el conocimiento como un producto comercial se limita su difusi<73>n favoreciendo a un grupo de la poblaci<63>n, lo cual es inaceptable, ya que representa una forma de discriminaci<63>n. En nuestro pais, el acceso a la informaci<63>n ha ido aumentando gracias a la aparici<63>n de Internet y a la gran cantidad de proyectos existentes que buscan difundir todo tipo de conocimientos. Sin embargo, para poder asimilar este conocimiento se requieren ciertas habilidades que se adquieren despu<70>s de un procesos de ense<73>anza formal. En Colombia el acceso a la educaci<63>n superior de calidad es limitado, la cobertura de las Universidades p<>blicas est<73> limitada por la inversi<73>n del estado, y como pudimos ver anteriormente, en nuestro pa<70>s la preocupaci<63>n actual es la seguridad y no la educaci<63>n. Por lo tanto, hacer del conocimiento un bien com<6F>n requiere la intervenci<63>n de diferentes sectores que garanticen y regulen el acceso, generen, clasifiquen y administren la forma en la que se expresa el conocimiento.
La diferencia entre esta propuesta y las existentes promovidas por los organismos gubernamentales, es el <20>nfasis en la transferencia y difusi<73>n del conocimiento, del \textit{saber hacer}, muchas pol<6F>ticas existentes se enfocan en la compra de equipo, lo que, como se vi<76> antes no es el canal m<>s eficiente para la transferencia tecnol<6F>gica. Nuestros esfuerzos est<73>n enfocados a crear un conocimiento b<>sico en la Concepci<63>n, Dise<73>o, Implementaci<63>n y Dise<73>o de Sistemas Embebidos. Este conocimiento es el resultado de a<>os de experimentaci<63>n e investigaci<63>n en el <20>rea, al ser colocado a disposici<63>n de usuarios interesados, se aumentan las posibilidades de difusi<73>n, ya que ya se realiz<69> un trabajo previo de "adaptaci<63>n" a las condiciones de la plataforma tecnol<6F>gica local y al contexto econ<6F>mico y social. En la actualidad existen instituciones educativas que proporcionan conocimientos similares pero no tienen la profundidad del presente estudio y limitan el acceso a esta informaci<63>n cobrando altos precios para acceder a ella.
En este cap<61>tulo estudiaremos las licencias \textit{Creative Commons} una nueva forma de licenciamiento que permite asignar diferentes "permisos" de utilizaci<63>n a un determinado trabajo y puede ser utilizadas tanto en Software como en Hardware. Exploraremos el movimiento de Software Libre y C<>digo Abierto (FOSS) y como este contribuye a la transferencia tecnol<6F>gica y como millones de usuarios a lo largo y ancho del mundo trabajan de forma conjunta para difundir, actualizar, mejorar, y aumentar las aplicaciones disponibles. Adicionalmente se presenta una propuesta a la creaci<63>n de un movimiento que funcione con pol<6F>ticas similares pero centrado en el Desarrollo Hardware.
\section{El Conocimiento Como Bien Com<6F>n}
El an<61>lisis del conocimiento como bien com<6F>n tiene sus bases en el estudio de recursos naturales compartidos (agua, bosques, fauna, flora). El recurso puede ser peque<75>o y ser utilizado por un grupo reducido (El televisor familiar), puede ser de nivel comunitario (campos de juego, bibliotecas, paruqes etc) o pueden tener naturaleza internacional y mundial (oceanos, atm<74>sfera, internet, conocimiento cient<6E>fico, etc), puden ser delimitados (la librer<65>a comunitaria), transfronterizos (El rio Amazonas, Internet, vida salvaje migratoria, etc) o sin l<>mites claros (el conocimiento, la capa de ozono, etc). Adicionalmnete, existe una diferencia entre el bien com<6F>n como un recurso o sistema de recursos y el bien com<6F>n como un r<>gimen de derechos de propiedad\cite{EO90}. El conocimiento posee caracter<65>sticas que lo diferencian de los recursos naturales, mientras muchos bienes comunes ven comprometido su sostenimiento a medida que aumenta el n<>mero de usuarios, el objetivo de utilizar el conocimiento como bien com<6F>n es lograr su m<>xima difusi<73>n. El beneficio asociado al acceso a la informaci<63>n depende de la calidad de esta, a mayor calidad mayor el beneficio.
El conocimiento, al igual que otros bienes comunes es utilizado de forma conjunta y es manejado por grupos de diversos intereses y tama<6D>os. Para que este recurso sea <20>til se requiere una infra-estructura que permita su difusi<73>n, actualizaci<63>n, mejoramiento, realimentaci<63>n y crecimiento. Pero como administrar un recurso intangible y distribuido como el conocimiento? Como coordinar acciones de miembros que se encuentran localizados en diferentes puntos geogr<67>ficos?
Como coordinar acciones de miles de usuarios para garantizar un recurso <20>til y sostenible? Como convertir este conocimiento en motor de Desarrollo y crecimiento empresarial? Estas preguntas ser<65>n respondidas a lo largo de este cap<61>tulo.
\subsection{Auto-Gobierno}
Ostrom \cite{Ost00} argumenta que la forma m<>s eficiente de administrar un bien com<6F>n es el auto-gobierno ejercido por beneficiarios de dicho recurso. Si estos beneficiarios son conscientes de la importancia de un uso eficiente y racionado que garantice la existencia de este bien y toda acci<63>n o decisi<73>n que se haga es formulada pensando en el beneficio com<6F>n se crear<61>n normas que garantizan el beneficio de todos los usuarios y la sostenibilidad del recurso. El auto-gobierno requiere acciones colectivas que "emergen cuando se requiere el esfuerzo de dos o m<>s individuos para cumplir con una meta" \cite{ST92}. Otro aspecto importante de las acciones colectivas es que son voluntarias por parte de los individuos \cite{MMDG04}. El autogobierno requiere de la acci<63>n combinada de conociminto y voluntad unido a normas institucionales consistentes.
Ostrom \cite{EO92} y Baland and Platteau \cite{J.B96}, consideran que los atributos necesarios para que un recurso tenga una probabilidad alta de crear asociaciones de autogobierno son:
\begin{itemize}
\item Posibilidad de mejoramiento: El recurso no se encuentra en un punto tal que sea in<69>til crear una organizaci<63>n alrededor de <20>l.
\item Indicadores: Disponibilidad de indicadores confiables y v<>lidos sobre la condici<63>n del recurso.
\item Predictibilidad: El flujo de unidades de recurso es relativamente predecible.
\item El recurso es lo suficientemente peque<75>o, teniendo en cuenta las tecnolog<6F>as de comunicaci<63>n utilizadas, para que los usuarios pueden tener un conocimiento preciso de los l<>mites externos y de los micro-ambientes internos.
\end{itemize}
Y los atributos de los usuarios del recurso son:
\begin{itemize}
\item Prominencia: Los usuarios dependen del recurso para una parte importante de su sostenimiento.
\item Entendimiento com<6F>n: Conocimiento sobre el funcionamiento del sistema y como acciones individuales afectan a los dem<65>s y al sistema.
\item Baja Tasa de Descuento: Para obtener un mayor beneficio a futuro se deben mantener tasas bajas de descuento del recurso.
\item Confianza y Reciprocidad: Los usuarios del recurso conf<6E>an en que los dem<65>s mantendr<64>n las promesas y se relacionar<61>n entre ellos con reciprocidad.
\item Autonom<6F>a: Los usuarios pueden determinar reglas sin la intervenci<63>n de autoridades externas
\item Experiencia Previa en Organizaci<63>n y Liderazgo Local: Los usuarios poseen habilidades m<>nimas de organizaci<63>n y liderazgo a trav<61>s de la participaci<63>n en otras asociaciones locales o eprendiendo de organizaciones en grupos cercanos.
\end{itemize}
De los anteriores atributos podemos deducir que para que pueda emerger un auto-gobierno asociado a un recurso debe existir un excelente canal de comunicaci<63>n entre los usuarios de dicho recurso y que todos ellos deben conocer y aceptar una serie de normas (creadas por ellos mismos) que fueron formuladas pensando en el beneficio com<6F>n, un grupo de estas normas debe establecer mecanismos de resoluci<63>n de conflictos, esto es vital ya que toda la organizaci<63>n se basa en la confianza mutua y no puede permitirse que las relaciones entre los usuarios se deteriore. Adicionalmente se requiere de miembros que tengan claro que el <20>xito de sus acciones y el sostenimiento del recurso depende de sus acciones, las cuales deben realizarse teniendo en cuenta el beneficio com<6F>n. El conocimiento no se ve afectado por la sustracci<63>n (uso) del mismo, todo lo contrario, el objetivo es obtener el m<>ximo n<>mero de usuasrios, sin embargo, este conocimiento puede llegar a ser obsoleto r<>pidamente, (en especial en el <20>rea de la Electr<74>nica digital) y por lo tanto inservible, para que esto no suceda se requiere de la actualizaci<63>n de este conocimiento para que refleje el estado actual en un <20>rea determinada.
\subsubsection{Ecuaci<63>n Costo Beneficio de Ostrom}
La pregunta que trata de responder Ostrom en su estudio es como emerge el auto-gobierno? \cite{Ost00} Para contestar esto formula una ecuaci<63>n que describe el an<61>lisis costo-beneficio que un individuo realiza para participar en un gobierno comunal:
\begin{lstlisting}[]
D < C (C1 + C2 + C3)
\end{lstlisting}
Donde ($D$) es el incentivo al cambio y compara los beneficios de utilizar las reglas tradicionales (BO) frente a los beneficios de utilizar un nuevo grupo de reglas basadas en un gobierno comunal (BN)
\begin{lstlisting}
D = BN - BO
\end{lstlisting}
C1 costo anticipado asociado a la transici<63>n.
C2 el costo de corto plazo para adoptar y apropiar las nuevas estrategias.
C3 Costos de largo plazo: mantenimiento, monitoreo y auto-gobierno.
Para que se realice el cambio el incentivo al cambio debe ser mayor que los costos asociados a el.
\begin{lstlisting}
BN - BO > C
BN > BO + C
\end{lstlisting}
Complejidades adicionales resultan de la interacci<63>n entre sub-grupos de usuarios, esta ecuaci<63>n puede ser diferente para cada participante, por lo que es normal encontrar coaliciones y acciones.
En la actualidad obervamos que grandes multinacionales como Nokia, Motorola o Google, est<73>n participando y promoviendo el desarrollo de productos y aplicaciones \cite{Mot} \cite{And} \cite{Mae} con la participaci<63>n de la comunidad, lo que representa un giro de 180 grados en la pol<6F>ticas lideradas por multinacionales como Microsoft y Aple en las que todas sus creaciones est<73>n protegidas por licencias, acuerdos comerciales y contratos de exclusividad que restringen la participaci<63>n en su desarrollo y aseguran el monopolio de los resultados de sus investigaciones. El movimiento de Software Libre \cite{FSF} hizo posible este cambio, proporcionando herramientas de desarrollo y facilidades para que cualquier persona alrededor del mundo pudiera realizar sus propias aplicaciones, gracias a esto se han creado aplicaciones como el servidor Web Apache, el explorador Mozilla el sistema operativo Linux, aplicaciones como gimp, openoffice, librer<65>as como ncurses, Qt y entornos de trabajo como xfce, gnome y KDE. El trabajo realizado por miles de programadores para llegar a este estado ha sido enorme, y por esta raz<61>n los grandes multinacionales est<73>n poniendo sus ojos en estas iniciativas ya que les representa un gran ahorro de dinero, es decir, el costo de participar en estas iniciativas es mucho menor que el beneficio obtenido por participar en ellas.
\subsubsection{Principios de Dise<73>o}
El primer paso para gobernar un bien com<6F>n es la identificaci<63>n de los principios de dise<73>o de un recurso com<6F>n robusto de larga duraci<63>n. Ostrom \cite{EO90} despu<70>s de dirigir un gran n<>mero de estudios emp<6D>ricos sobre gobernancia de recursos de bienes com<6F>nes. Encontr<74> una serir de principios de dise<73>o que hacen que el recurso sea sostenible a lo largo del tiempo. Los principales son:
\begin{itemize}
\item Fronteras claramente definidas
\item Las reglas deben reflajar necesidades y condiciones locales.
\item Los individuos sujetos a estas reglas pueden modificar y participar en la elaboraci<63>n de estas reglas.
\item Las autoridades externas deben respetar el derecho de los miembros de la comunidad a cear sus propias reglas.
\item Debe establecerse un sistema de seguimiento propio.
\item Disponibilidad de un sistema gradual de sanciones.
\item Acceso por parte de miembros de la comunidad a mecanismos de resoluci<63>n de conflictos de bajo costo.
\item Las actividades de apropiaci<63>n, suministro, monitoreo y sanci<63>n deben ser organizadas en estructuras anidadas con m<>ltiples capas de actividades
\end{itemize}
Es importante mencionar que no existe una combinaci<63>n de principios que garantice el <20>xito, es necesario probar con este set para identificar los principios generales que deben incluir los sistemas robustos. Estos ocho factores fueron encontrados en la mayor<6F>a de las instituciones analizadas en cientos de estudios y constituyen un buen punto de partida para comenzar esta investigaci<63>n. Estos ocho puntos se encuentran fuertemente relacionados con los atributos que requiere un recurso y un usario de este recurso para que pueda emerger un auto-gobierno y buscan que todos los participantes tengan pleno conocimiento de las reglas que monitorean, regulan, fijan y controlan las actividades de los miembros.
\subsubsection{Movimiento FOSS}
Es interesante consoiderar como este pensamiento aplica a proyectos de C<>digo Abierto. El Software no es un recurso t<>pico, porque no es sustraible, no existe un costo si un usuario decide usarlo o no. Sin embargo, es un bien com<6F>n, ya que es un recurso comunal que prospera o decae gracias a la contribuci<63>n de sus miembros. Los participantes de este tipo de recurso es el grupo de contribuidores potenciales, en lugar del grupo de posibles propietarios. Un aporte de un usuario a mejorar el proyecto se traduce en un beneficio colectivo. Los contribuyentes pueden ser empresas que pagan a una persona para que adicione una nueva caracter<65>stica, sin embargo, ellos pueden decidir no compartir estos cambios para tener una ventaja competitiva. En la actualidad observamos las tendeencias de multinacionales como Nokia o Motorola a participar, crear y promover proyectos de Software Libre, desde el punto de vista comercial resulta mpas rentable utilizar harramientas que han sido desarrolladas, probadas, y depuradas por miles de usuarios calificados que pagar a un grupo de decenas de desarrolladores para trabajar en sistemos propietarios.
En los proyectos de C<>digo Abierto puede utilizarse una variaci<63>n modificada de la ecuaci<63>n de Ostrom \cite{AC09}:
\begin{lstlisting}
BC > BN + C
\end{lstlisting}
Donde $BC$ es el beneficio a contribuir, y debe superar el costo de contribuir $C$ m<>s el beneficio de no contribuir $BN$. La comunidad del Software Libre ha creado un grupo de normas e instituciones muy sofisticadas alrededor de esta ecuaci<63>n dando como resultado uno de los estructuras auto-gobernadas m<>s exitosas. Los trabajos de la comunidad de Software Libre hacen que $C$ sea cada vez m<>s peque<75>o, proporcionando:
\begin{itemize}
\item Herramientas de programaci<63>n, depuraci<63>n y librer<65>as que facilitan el desarrollo de nuevas aplicaciones o mejoras a las ya existentes.
\item Listas de discusi<73>n en donde los creadores de estas herramientas responden preguntas, y buscan en conjunto soluciones a problemas espec<65>ficos
\item Sistemas de control de versiones y protocolos de comunicaci<63>n.
\item Bases de datos de soluci<63>n de problemas asociadas a las listas de discusi<73>n.
\item Tutoriales, documentaci<63>n, libros disponibles on-line.
\end{itemize}
Para contribuyentes no comerciales el costo de no contribuir es cero, pero, para contribuyentes comerciales $BN$ puede resultar muy grande, ya que pagar una n<>mina de programadores para que dise<73>en un sistema propio desde cero es mucho m<>s costoso (en tiempo y en dinero) que pagar a pocos programadores pra utilizar y modificar proyectos ya existentes. La licencia m<>s utilizada en los proyectos de Software Libre es la GPL, la cual, aunque no cubre todos los posibles tipos de uso, impone fuertes sanciones (escarnio p<>blico y consecuencias legales) cuando se utiliza y mejora un proyecto, pero no se comparten estos cambios con la comunidad. M<>s adelante estudiaremos el movimiento FOSS del cual se puede aprender mucho para crear nuestra versi<73>n de \textit{Hadrware Copyleft}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%% FOSS %%%%%%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\section{FOSS}
Como se mencion<6F> anteriormente, el movimiento FOSS es la estructura auto-gobernada m<>s exitosa y ser<65> tomada como referencia en el desarrollo de nuestra iniciativa de Hardware Copyleft. Su principal innovaci<63>n radica en un nuevo esquema de licencias unido a herramientas de colaboraci<63>n basadas en Internet, lo que se cnvirti<74> en una nueva forma de bien com<6F>n, donde los miembros de forma colectiva generan un buen com<6F>n el \textit{software}. El desaf<61>o de FOSS es realizar \textit{acciones colectivas para crear y mantener este bien p<>blico}. A diferencia de la creencia popular, en este movimiento existen derechos de autor (\textit{copyright}) y propiedad, sin embargo, algunos individuos involucrados en el proyecto, poseen derechos legales sobre el c<>dico (recurso), tienen control sobre las nuevas versiones del software y pueden excluir a otros que aportan c<>digo a las nuevas distribuciones.
Los miembros del movimiento FOSS usualmente son programadores (y usuarios finales de software) que contribuyen (ya sea voluntariamente, o que se les pague para hacerlo) para producir un software bajo la licencia FOSS. La "situaci<63>n de acci<63>n" que estos programadores encaran es, si en alg<6C>n momento, vale la pena contribuir al desarrollo de este software. La interaci<63>n de programadores trabajando de forma conjunta en Internet puede ser visto como un resultado que puede cambiar en el tiempo. Schweik y Semenov \cite{SAS03} identificaron tres estados de este tipo de bien com<6F>n, una fase inicial, seguida por un estado de apertura y un estado m<>s maduro de gran crecimiento (en t<>rminos de usuarios y participaci<63>n), estabilizaci<63>n donde el n<>mero de participantes (normalmente peque<75>o) no var<61>a, o el protecto se estanca y muere (sin participantes). Para que un proyecto sea exitoso, no es necesaria la participaci<63>n de un gran n<>mero de programadores, es frecuente encontrar grupos peque<75>os de programadores con un gran n<>mero de usuarios. La clave del <20>xito est<73> en la disponibilidad de un programador para contribuir al esfuerzo colectivo de por lo menos un peque<75>o grupo de actores que producen y mantienen el software.
En la Figura \ref{framework_foss} se ilustra el marco definido por Ostrom y Hess \cite{CHEO06} para analizar el conocimiento como bien com<6F>n, aplicado al movimiento FOSS. Como se mencion<6F> anteriormente, el razgo que diferencia este movimiento es la utilizaci<63>n de una forma de licenciamiento especial. Richard Stallman \cite{Wikb}, a mediados de los 80 inici<63> un proyecto para desarrollar un sistema operativo abierto/libre basado en \textit{unix} llamado \textit{GNU} (GNU is Not unix).
\subsubsection{Reglas En Uso}
Stallman \cite{Sta99} sostiene que las propiedades digitales del software hacen posible considerarlo como un bien p<>blico, proporcionando a sus usuarios \textit{la libertad} de utilizarlo, distribuirlo y modificarlo. Esta filosf<73>a se basa en cuatro libertades que encarnan el principio \textit{copyleft}:
\begin{itemize}
\item Libertad de ejecutar el software para cualquier prop<6F>sito.
\item Libertad de estudiar como funciona el programa, y cambiarlo para hacer lo que se desee. El acceso al c<>digo fuente es una condici<63>n para esto.
\item Libertad para re-distribuir copias.
\item Libertad para distribuir copias de versiones modificadas. Lo que permite que la comunidad se beneficie de estos cambios. El acceso al c<>digo fuente es una condici<63>n para esto.
\end{itemize}
Esta filosof<6F>a permite que los conocimientos y habilidades que el programador posee puedan ser transferidas a programadores, empresas, instituciones acad<61>micas y sociedades, ya sea en forma de producto o como herramienta de ense<73>anza. Esta actividad representa un proceso de Transferencia Tecnol<6F>gica, en la que el que suministra la tecnolog<6F>a proporciona todos los medios para que el receptor pueda abosrverla y transformarla para satisfacer necesidades en su entorno social. Adicionalmente, Stallman ide<64> una forma de trabajar con las leyes de derechos de autor que proporciona una alternativa al licenciamiento tradicional. Las grandes multinacionales como Microsoft o Apple limitan el n<>mero de usuarios por licencia y hacen distribuciones de archivos binarios compilados en forma de ejecutables. El software con licencia \textit{copyleft} estipula que cualquier modificaci<63>n que se le realice adquiere los principios de licenciamiento del software original. La licencia \textit{GPL}\footnote{http://www.gnu.org/licenses/licenses.html} (GNU General Public License) fue creada para implementar estos principios.
\begin{figure}[H]
\begin{center} \includegraphics[scale=.6]{./images/framework_foss.png} \end{center}
\caption{Marco para analizar el conocimiento como bien com<6F>n aplicado al movimiento FOSS: Modificaci<63>n de: \cite{CHEO06} p<>g 46} \label{framework_foss}
\end{figure}
El proyecto de \textit{c<>digo abierto} liderado por Bruce Perens y Eric Raymond, utiliza las propiedades de la licencia GPL adicionando un grupo de \textit{derechos morales} dirigidos a conservar el trabajo del autor en su forma original, con el f<>n de conservar su autor<6F>a. Existe un gran n<>mero de variaciones de licenciamiento \footnote{http://www.opensource.org/licenses/alphabetical} para proyectos de Software Libre, lo que indica que al momento de licenciar un software el autor debe determinar que derechos retener y cuales regalar \cite{CMS06}. Las innovaciones del licenciamiento \textit{copyleft} constituyen las \textit{reglas en uso} que motivan a los programadores a participar en el movimiento FOSS, y establecen las bases de un r<>gimen de propiedad com<6F>n.
La clave para mantener un bien com<6F>n es la estructura de gobernanza de dicho recurso, el movimiento FOSS es un experimento en marcha, en dondes se prueba una mezcla imperfecta de liderazgo, mecanismos informales de coordinaci<63>n, normas impl<70>citas y expl<70>citas junto con estructuras de gobernanza formal que evolucionan de tal forma que han logrado mantener unido este sistema tan camplejo \cite{Web04}. Aunque no existe literatura que estudie las estructuras de gobernanza en el movimiento FOSS, algunas observaciones a los proyectos existentes en la actualidad indican que estas estructuras podr<64>an incluir:
\begin{itemize}
\item Priorizaci<63>n de caracter<65>sticas a incluir en nuevas versiones del software.
\item Definici<63>n de Reglas y procedimientos para evaluar y escoger nuevos aportes para que hagan parte de las nuevas versiones.
\item Definici<63>n de Reglas y procedimientos para detectar y corregir errores en el software.
\item Asignaci<63>n y administraci<63>n de tareas.
\item Asistencia en la resoluci<63>n de disputas entre miembros del equipo.
\end{itemize}
Estas reglas var<61>an dependiendo del estado del proyecto, ya que, las actividades que se deben realizar en cada etapa son diferentes, en la etapa inicial, se establece la comunidad de programadores que definen las especificaciones del software, por lo que las tarea m<>s importante son el reclutamiento de programadores y la definci<63>n de una estructura flexible para el software. Cuando el proyecto alcanza una determinada madurez, lo importante es a<>adir funcionalidades y corregir errores.
\subsubsection{Atributos de la Comunidad}
La comunidad FOSS esta compuesta por usuarios y programadores voluntarios motivados por intereses tecnol<6F>gicos, sociopol<6F>ticos, econ<6F>micos y acad<61>micos. Desde el punto de vista tecnol<6F>gico, resulta m<>s efectivo en tiempo y en dinero, participar en un proyecto conjunto para la realizaci<63>n de una aplicaci<63>n que satisface una determinada necesidad. La principal motivaci<63>n sociopol<6F>tica es la creencia por parte del programador en la filosof<6F>a del movimiento, en lalucha contra el monopolio del software, adicionalmente, para que el proyecto permenezca durante mucho tiempo, es necesario que sea atractivo para vincular el mayor n<>mero de participantes y de esta forma sobrevivir en el futuro. Las motivaciones econ<6F>micas y acad<61>micas pueden ser consideradas en forma conjunta ya que al participar en estos proyectos, los miembros adquieren o mejoran sus habilidades de programaci<63>n ya sea revisando, leyendo y entendiendo el c<>digo existente o sometiendo a la revisi<73>n de los dem<65>s miembros sus contribuciones. Por otro lado, esta participaci<63>n puede verse como una vitrina en donde el programador muestra sus capacidades y puede ser contactado por empresas para establecer relaciones comerciales. En los dos casos la participaci<63>n es una forma de inversi<73>n y una forma de ganar experiencia y reputaci<63>n \cite{VWJ+03}.
En proyectos con un gran n<>mero de personas asociadas, solo un peque<75>o porcentaje de ellos realizan la mayor parte del trabajo. En la actualidad muchas empresas est<73>n participando de forma activa en estos proyectos, aportando programadores pagados para que contribuyan con el desarrollo y mejoramiento del softeare. Un estudio realizado a 25 firmas participantes en el proyecto FOSS \textit{Linux Operating System} \cite{GGR02} indica que la tercera parte de los programadores encuestados son pagados por sus empleadores para participar, y que su motivaci<63>n a participar es el interes propio en estandarizaci<63>n, disminuci<63>n de costos, estrategias para debilitar a la competencia y esfuerzos para hacer sus productos compatibles con los productos derivados del movimiento FOSS.
\subsubsection{Atributos F<>sicos}
Existen tres categor<6F>as \cite{CMS06} en FOSS que pueden ser consideradas como atributos f<>sicos:
\begin{enumerate}
\item La utilidad del Software: Como vimos anteriormente, para que una persona participe en una actividad relacionada con el bien com<6F>n, el costo por no hacerlo debe ser mayor que el beneficio por participar, es decir, el software debe representar una utilidad grande para que valga la pena participar en el proyecto.
\item El dise<73>o o la estructura del software. Un c<>digo limpio (optimizado, documentado y <20>ptimo) y modularizado permite el trabajo en paralelo, lo que reduce el tiempo de depuraci<63>n y el requerido para implementar nuevas caracter<65>sticas.
\item La infraestructura que hace posible coordinar y administrar la colaboraci<63>n y la producci<63>n: El uso de Internet para soportar herramientas de control de versiones (como \textit{svn}, \textit{cvs} y \textit{git}) y la comunicaci<63>n v<>a listas de discusi<73>n hace posible coordinar de forma eficiente los esfuerzos de cooperaci<63>n. Permitiendo:
\begin{itemize}
\item Almacenar versiones de software.
\item La descarga de m<>dulos.
\item La adici<63>n de Nuevas contribuciones y la protecci<63>n del c<>digo existente.
\item Generar un historial donde se documentan los cambios realizados a lo largo del tiempo.
\item Analizar funciones para identificar diferencias entre versiones.
\item Informar a los miembros del equipo cambios en los m<>dulos del proyecto.
\end{itemize}
\end{enumerate}
Esta infraestructura trabaja junto con las reglas-en-uso establecidas para proporcionar procesos que direccionen nuevos trabajos, un sistema para recibir y revisar contribuciones de nuevos m<>dulos que pueden ser incluidos en futuras versiones.
En conclusi<73>n, los proyectos FOSS evolucionan en el tiempo como resultado de la configuraci<63>n de sus reglas-en-uso, atributos de la comunidad y atributos f<>sicos relacionados con la estructura del software para hacer f<>cil la colaboraci<63>n y herramientas efectivas para coordinaci<63>n de equipos y manejo de contenido.
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%% Copy Left %%%%%%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\section{Propiedad Intelectual y Licencias}
Para utilizar el paradigma colaborativo del movimiento FOSS para adaptarlo a cualquier forma de propiedad intelectual (incluyendo la creaci<63>n de hardware) es necesario ampliar el t<>rmino \textit{copyleft} de Stallman. El primer en esta direcci<63>n fu<66> dado por el mismo Stallman al desarrollar la licencia GFDL (GNU Free Documentation License) aplicable a todo tipo de documentaci<63>n t<>cnica, guias de usuario, tutoriales, etc. Esta licencia gobierna el uso, modificaci<63>n y distribuci<63>n de la documentaci<63>n del software GNU, especificando las secciones del documento que no puden ser modificadas (tales como autor, aviso de derechos de autor), los t<>rminos de distribuci<63>n.
\subsection{Licencias Creative Commons}
Creative Commons \footnote{http://creativecommons.org/} organizaci<63>n no gubernamental sin <20>nimo de lucro ha desarrollado una serie de licencias basadas en principios similares a los de Stallman y que puden ser aplicadas a trabajos realizados en m<>sica, arte, video, texto y notas de clase. Estas licencias permiten que el autor de un trabajo conserve la propiedad intelectual (los derechos asociados a esta) pero posibilitando su copia y distribuci<63>n, con la <20>nica condici<63>n de dar cr<63>ditos al autor \cite{CCb}. Se puede elegir diferentes permisos dependiendo de los deseos del autor, para definir dichos permisos CreativeCommons proporciona una serie de preguntas que buscan determinar los derechos que se desean conservar y los que desean liberar. Las preguntas claves son: 1) Los lectores pueden copiar y distribuir su trabajo libremente? 2) Es permitido a los usuarios crear trabajos derivados del contenido digital? Si es permitido, estas modificaciones deben tener la misma licencia que el trabajo original (esquema de licencia viral), o deben ser distribuidos bajo un esquema de licencias diferente? 3) Es necesario atribuir el trabajo al autor original?. Estas preguntas son la base para definir un esquema de licencias modular.
Existen cuatro bloques constructivos para las licencias Creative Commons estos son:
\begin{itemize}
\item \textit{Atribuci<63>n} (\textbf{BY}): Se permite la distribuci<63>n pero se debe dar cr<63>dito al autor.
\item \textit{No comercial} (\textbf{NC}): Se permite la distribuci<63>n del trabajo sin fines comerciales, si se desea utilizar este trabajo para obtener dinero es necesaria una autorizaci<63>n del autor
\item \textit{No a trabajos derivados} (\textbf{ND}): Permite la copia y la distribuci<63>n del trabajo original sin modificaciones.
\item \textit{Compartir de la misma forma} (\textbf{SA}): Exige que todo trabajo derivado del uso de proyectos que con este esquema de licencias deben tener la misma licencia de los trabajos originales.
\end{itemize}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%% COPY LEFT HW %%%%%%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\section{Hardware Copyleft}
En esta secci<63>n se relizar<61> la definici<63>n del t<>rmino \textit{hardware copyleft} como una extensi<73>n del proyecto \textit{FOSS}. Una de las hip<69>tesis manejadas durante el desarrollo de este trabajo es que el conocimiento debe ser considerado como un bien com<6F>n y que los usuarios de este recurso deben utilizarlo de tal forma que se beneficie la comunidad asociada a dicho recurso. Como estrategia para obtener una transferencia tecnol<6F>gica y de conocimientos exitosa a la academia y a la industria electr<74>nica nacional (en el <20>rea de sistemas digitales) se utilizar<61> el principio del conocimiento como bien com<6F>n para crear una comunidad que utilice como recurso inicial el trabajo generado en este proyecto.
Los dispositivos digitales modernos poseen dos grandes componentes, el hardware que proporciona recursos como capacidad de c<>mputo, capacidad de almacenamiento, medios de comunicaci<63>n e interfaz con otros dispositivos y con el mundo real; y el software implementa una determinada funcionalidad utilizando los recursos hardware. Normalmente estos dispositivos est<73>n dise<73>ados para ejecutar una funci<63>n <20>nica, por lo que el componente hardware se encuentra optimizado (funcionalidad, tama<6D>o, consumo de potencia, costos) para la ejecuci<63>n de dicha tarea. Como se mencion<6F> anteriormente existe un movimiento muy fuerte (FOSS) que proporciona una gran variedad de herramientas para la implementaci<63>n del componente software. Sin embargo, hasta el momento no existe un movimiento similar dirigido al desarrollo del componente hardware. Mi hip<69>tesis es que un movimiento de hardware abierto permitir<69> el desarrollo de la industria electr<74>nica local permitiendo la transferencia exitosa de tecnolog<6F>a y conocimientos en el <20>rea de dise<73>o de sistemas embebidos.
Haciendo una analog<6F>a con el movimiento FOSS, la iniciativa \textit{hardware copyleft} permitir<69>a el uso, distribuci<63>n, y modificaci<63>n de proyectos hardware existentes. La acci<63>n de modificaci<63>n se origina por una necesidad que se debe satisfacer, implica un entendimiento del principio de funcionamiento y del proceso de fabricaci<63>n asociados al proyecto original. Lo anterior cumple con la definici<63>n de transferencia tecnol<6F>gica exitosa: ``\cite{Mo94} El problema de transfencia de conocimiento (o know-how) sobre un n<>mero de aspectos (que incluyen el conocimiento) sobre como funciona un determinado sistema, como operarlo y desarrollar sus aplicaciones, como mantenerlo y si es necesario, como producir sus componentes y montar un sistema similar. La transferencia tecnol<6F>gica se considera exitosa cuando los receptores de la tecnolog<6F>a asimilan los conceptos anteriores para suplir sus necesidades locales''.
El reto en la definici<63>n del concepto de \textit{hardware copyleft} radica en la naturaleza del componente hardware, a diferencia del software donde solo es necesario descargar el c<>digo fuente y las herramientas de compilaci<63>n para modificar un proyecto existente ; los proyectos hardware involucran procesos de fabricaci<63>n, montaje y pruebas que tienen asociados unos costos que var<61>an dependiendo de la tecnolog<6F>a utilizada (ASIC, PCB). Este costo representa un factor que afecta a los potenciales miembros de la comunidad, en el peor de los casos predefiniendo sus perfiles o limitando el acceso. Por este motivo, se debe considerar el impacto del factor econ<6F>mico en la formaci<63>n de la comunidad, definiendo las caracter<65>sticas que deben poseer estos proyectos para minimizar el costo asociado.
\subsection{Atributos de la Comunidad}
El <20>xito de la iniciativa \textit{FOSS} se debe en parte a la gran comunidad que comparte la ideolog<6F>a del software libre \cite{RS07},sus miembros buscan: satisfacer necesidades propias \cite{JK00}, aprendizaje \cite{HIH02}, reputaci<63>n dentro y fuera de la comunidad, asociaci<63>n e identidad \cite{GH03}, diversi<73>n y creatividad \cite{RAG+02}. Para que la propuesta \textit{hardware copyleft} sea una realidad, es importante identificar los motivos por los cuales estos individuos se unen a este tipo de comunidades y como las diferentes formas de gobierno afectan su participaci<63>n, y como esta experiencia exitos puede ser utilizada en nuestro movimiento.
Un estudio reciente, realizado sobre diferentes comunidades software \cite{SS06} \cite{KBCR10} revela que la raz<61>n inicial para la participaci<63>n es la necesidad de cambios, alteraciones o asistencia a proyectos existentes, su resultado se resumen en la tabla \ref{participation}. A pesar de que los costos de contribuci<63>n son relativamente altos en t<>rminos de tiempo y esfuerzo, muchos programadores se unen a esta comunidad buscando:
\begin{itemize}
\item \textit{Reciprocidad.} Una gran cantidad de los participantes en los proyectos software que fueron consultados en este estudio expresaban la necesidad de que la reciprocidad sea parte de las normas de la comunidad. Una gran parte de proyectos son liberados con el prop<6F>sito de suplir una necesidad, ya sea por la inexistencia de una herramienta que realice ciertas funciones o para reemplazar una comercial, sus autores buscan con esto que otras personas liberen sus trabajos para que puedan ser utilizados por la comunidad.
\item \textit{Mejoras.} Someter el c<>digo a la inspecci<63>n de miles de programadores ayuda a depurar y limpiar el c<>digo, adicionalmente se logra aumentar su funcionalidad y se aumenta el n<>mero de usuarios. Sin el apoyo de la comunidad estas mejoras tomar<61>an mucho tiempo o en algunos casos nunca se realizar<61>an.
\item \textit{Contribuci<63>n con la escritura de c<>digo fuente.} Algunos de los miembros de estas comunidades son empleados de compa<70><61>as que utilizan resultados de estos proyectos en sus productos comerciales, y dentro de sus intereses est<73> incluir en las distribuciones oficiales funcionalidades creadas por ellos.
\item \textit{Motivos profesionales.} Razones como reputaci<63>n, desarrollo de habilidades tienen una importancia relativamente baja en la creaci<63>n y contribuci<63>n de c<>digo. La mayor<6F>a expresa que su participaci<63>n busca conocimiento espec<65>fico del proyecto y no para adquirir habilidades espec<65>ficas; al trabajar con programadores m<>s experimentados se agudizan o expanden ciertas habilidades.
\item \textit{Disfrute y Entretenimiento} Un gran porcentaje de los participantes con mayor tiempo de permanencia manifiestan que esta actividad les proporciona un pasatiempo desafiante; curiosamente este tipo de participantes superan en n<>mero a los que se participan para suplir necesidades.
\end{itemize}
\begin{center}
\begin{table}[H]
\begin{tabular}{|m{1.8cm}|p{3cm}|p{3cm}|p{2.5cm}|p{2.5cm}|} \hline
\textbf{Motivo para crear} & \textbf{Motivo para contribuir} & \textbf{Nivel de participaci<63>n} & \textbf{No. relativo de participantes} & \textbf{Conocimiento del c<>digo y estructura} \\ \hline
\multirow{5}{*}[-2cm]{\textbf{\textit{Necesidad}}}
& Reciprocidad; normas & Bajo & Alto & Limitado al <20>rea del problema inicial \\\cline{2-5}
& Mejoras futuras & Variable, depende de la necesidad & Moderada & En el <20>rea del problema \\\cline{2-5}
& Deseo de integrar
c<>digo propio en el
c<>digo fuente & Moderado a alto & Bajo & Variable \\\cline{2-5}
& Motivos profesionales & Bajo & Muy bajo & variable \\\cline{2-5}
& No contribuye & Muy bajo & NA & Limitado al <20>rea del problema inicial \\ \hline
\textbf{\textit{Diversi<73>n y disfrute}}
& Realimentaci<63>n & Alto & Bajo & Comienza en un <20>rea determinada, y se expande \\ \hline
\end{tabular}
\caption{Motivaci<63>n de la participaci<63>n de desarrolladores en proyectos de softawre libre. Fuente \cite{SS06} } \label{compet_4}
\end{table}
\end{center}
Este estudio concluye que muchos miembros de estas comunidades ingresan para suplir necesidades, pero muchos de ellos continuan creando c<>digo porque disfrutan programar. Estos \textit{aficionados} realizan un papel muy importante dentro de la comunidad encarg<72>ndose de tareas como mejora de la plataforma tecnol<6F>gica, re-escribiendo secciones de c<>digo, documentandolo, respondiendo preguntas, preservar o mejorar la arquitectura. Otros consideran que la reciprocidad es vital para la contribuci<63>n de c<>digo a la comunidad y que la forma de gobierno afecta dram<61>ticamente la participaci<63>n de programadores voluntarios.
\begin{center}
\begin{table}[H]
\begin{tabular}{|m{2.8cm}|c|} \hline
\textbf{Mecanismos de Gobierno} & \textbf{Motivo para contribuir} \\\hline
\multicolumn{2}{|c|} {Toma de decisiones} \\\hline
\multirow{3}{*}[-2cm]{\textit{Control del C<>digo}
& Disminuye la \\\hline
\end{tabular}
\end{table}
\end{center}
\subsection{Atributos F<>sicos}
\subsection{ECB\_AT91, ECBOT, ECB\_BFIN} Plataformas realizadas para adquirir experiencia en el dise<73>o de sistemas embebidos
detectar las habilidades que se necesitan para realizar el proceso
\subsection{Proyecto Qi-Hardware}
% whatever form or technol-
% ogy the land-use model utilizes (e.g., a computer program, a statistical
% script, and so on), it should be placed under some license that allows the
% free copying of the model, requires the model ?source? to be readable,
% and permits the development of new derivative components of the model
% or other products related to the model. In some instances, the
% model developers might decide to make all related products (e.g., the
% model modules, their documentation, data, and even theoretical papers)
% fall under these conditions. However, there will be situations where more
% restrictive licensing is warranted. For instance, empirical papers describ-
% ing a particular application of a model would probably be licensed with
% a ?no derivative work? component, because these types of papers report
% findings from a particular study at a particular time.
%
% INTERNET INTERNET
% Clearly, the Internet, as a technological advance, is as important a
% ?structural change? to the way scientific advances are communicated and
% collaborated on as was the printing press. Digital storage has become so
% cheap that many treat the saving of a file on a hard disk as nearly cost-
% less. Advances like the web and e-mail software have greatly reduced the
% costs or skills required to access information on the Internet. Over the
% last five to ten years, the Internet has moved from a domain utilized pri-
% marily by high-skilled computer scientists, engineers, or others in the
% high-tech industries, to a system utilized by scientists and scholars in all
% disciplines. We are now in a shake-up period where traditional organi-
% zations chartered with the management of scientific information (e.g.,
% libraries, publishers) are developing new organizational models and mis-
% sions built around computer database and connectivity issues (see, for
% example, chapters 4 and 11 in this book). This environment, where
% digital files can be copied and transferred globally in an instant and at
% very little cost, makes it much easier to treat information or knowledge
% as a global public good. But as other contributors to this book describe,
% these advances in technology are directly at odds with other societal
% trends and developments in intellectual copyright law that are pushing
% to treat information and other digital products as private goods for mon-
% etary gain (see chapters 5 and 7).
%
% To promote the argument made in the opening paragraph of this
% chapter?that the collaborative ideals and principles applied in FOSS
% projects are potentially applicable to any collaboration built around
% intellectual property?I first provide an overview and summary of the
% FOSS software ?movement? and describe some critical project compo-
% nents. I use the Institutional Analysis and Development Framework
% described in chapter 3 to help guide the description of these projects.
% Next, I provide more detail on the argument that the FOSS collabora-
% tive principles and approaches can extend more broadly to scientific
% research in general. At this juncture, I introduce the more recent inno-
% vation of ?open-content? licensing. Using a short example in the scien-
% tific field of land-use change modeling, I then provide a discussion of
% some critical issues that will need to be addressed in order to transfer
% the collaborative principles of FOSS software commons to scientific-
% commons endeavors.

View File

@@ -0,0 +1,809 @@
\chapter{Habilidades CDIO}
\label{ch:education}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%% INTRODUCCION %%%%%%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\section{Introducci<EFBFBD>n}
La iniciativa CDIO \footnote{http://www.cdio.org} ha sido desarrollada con ayuda de academicos, industriales, ingenieros y estudiantes\cite {WCI}. Es posible adaptar esta iniciativa a cualquier centro educativo en Ingenier<65>a, y ha sido adoptada por un creciente n<>mero de instiruciones acad<61>micas a lo largo del mundo.
La educaci<63>n de la ingenier<65>a y las demandas del mundo real est<73>n tomando caminos separados, la Iniciativa CDIO es un proyecto mundial que busca desarrollar una nueva visi<73>n de la educaci<63>n en ingenier<65>a. Hacer parte de este esfuerzo mundial nos ayuda a mantener nuestros planes acad<61>micos actualizados con los cambios que se realizan en pa<70>ses m<>s industrializados. En este cap<61>tulo mostraremos como esta iniciativa se adapta perfectamemente a los cambios que se han inroducido en el <20>rea de la electr<74>nica digital en la universidad Nacional de Colombia.
La Iniciativa CDIO se basa en la suposici<63>n que los egresados de los centros de formaci<63>n en ingenier<65>a deben ser capaces de: Concebir, Dise<73>ar, Implementar y Operar sistemas complejos en un entorno basado en equipos para crear sistemas y productos. En Colombia, la mayor<6F>a de los centros de formaci<63>n solo tienen en cuenta la Concepci<63>n y el Dise<73>o, descuidando por completo la Implementaci<63>n y la Operaci<63>n de sistemas, esto, impide que se tenga una estrecha relaci<63>n con la industria, la cual, requiere productos que pueda comercializar o soluciones a sus necesidades.
\subsection{Objetivos de la Iniciativa CDIO}
La Iniciativa CDIO se enfoca en preparar a los estudiantes con los conocimientos habilidades y aptitudes para ser ingenieros l<>der. Y sus principales objetivos son: \cite {WCI}:
\begin{itemize}
\item Educar a los estudiantes para dominar un conocimiento m<>s profundo de los fundamentos t<>cnicos.
\item Educar a los ingenieros para liderar la creaci<63>n y operaci<63>n de nuevos productos y sistemas.
\item Educar futuros investigadores para entender la importancia estrat<61>gica y el valor de su trabajo.
\end{itemize}
El Departamento de Ingenier<65>a El<45>ctrica y Electr<74>nica de la Universidad Nacional de Colombia est<73> realizando el trabajo de adaptar la Iniciativa CDIO a su programa acad<61>mico, esta iniciativa coincidi<64> con el desarrollo de esta investigaci<63>n. Los objetivos de esta iniciativa se adaptan a los requerimientos que se exige a la plataforma tecnol<6F>gica de un pa<70>s para que pueda realizar una adecuada absorci<63>n del conocimiento transferido y posteriormente transformar ese conocimiento en nuevos productos adaptados a las necesidades del pa<70>s.
Las premisas que capturan la visi<73>n, objetivos y fundamentos pedag<61>gicos de la Iniciativa CDIO son:
\begin{itemize}
\item Es posible cumplir las necesidades propias de la profesi<73>n mientras al mismo tiempo se realiza el proceso de Concebir, dise<73>ar, implementar y operar sistemas en el contexto de los sistemas de Ingenier<65>a.
\item Los resultados de la formaci<63>n deben ser fijados por los sectores interesados (Academia, Industria, Gobierno) y deben formar una secuencia de experiencias de aprendizaje, algunas de las cuales son experimentales, es decir, deben enfrentar a los estudiantes a situaciones que encontrar<61>n en el ejercicio de su profesi<73>n.
\item La adecuada construcci<63>n de esta cadena de actividades tendr<64>n un doble impacto en la formaci<63>n de los estudiantes, por un lado facilitar<61> el aprendizaje de habilidades cr<63>ticas e inter-personales y fortalecer<65> las habilidades de construcci<63>n de sistemas, productos y procesos, mientras se mejora el aprendizaje de los conceptos fundamentales.
\end{itemize}
\subsubsection{liderazgo}
La situaci<63>n actual por la que atraviesa la Industria electr<74>nica nacional, requiere que los profesionales en el <20>rea tengan las capacidades de emprendimiento y liderazgo necesarias para la creaci<63>n de nuevas empresas o para la creaci<63>n de nuevos productos, la Figura \ref{cdio_emp_lid} muestra la relaci<63>n entre emprendimiento, liderazgo y las habilidades CDIO.
\begin{figure}[H]
\begin{center} \includegraphics[scale=.6]{./images/CDIO_emp_lid.png} \end{center}
\caption{} fuente:\cite{ECJM+09} \label{cdio_emp_lid}
\end{figure}
Las habilidades principales que deben poseer un lider seg<65>n la \textit{Sloan School of Management at MIT} son \cite{AD}:
\begin{itemize}
\item \textit{Interpretar} Interpretar el contexto de los cambios mundiales incluyendo el uso de peque<75>os experimentos para obtener informaci<63>n.
\item \textit{Relacionarse} Desrrollar relaciones confiables con diferentes tipos de personas, utilizando las preguntas para saber como comunicarse de forma efectiva.
\item \textit{Visi<EFBFBD>n} Crear una visi<73>n para uno mismo y transmitir esta visi<73>n a los dem<65>s.
\item \textit{Realizaci<EFBFBD>n de la Visi<73>n}
\end{itemize}
\subsubsection{Emprendimiento}
El concepto cl<63>sico de emprendimiento involucra el re-direccionamiento y movilizaci<63>n de capital y recursos humanos para crear una nueva actividad econ<6F>mica. Actualmente, el emprendimiento esta asociado a la creaci<63>n de une nueva empresa con una nueva l<>nea de negocios. En algunas ocasiones las innovaciones tecnol<6F>gicas no requieren cambios en el mercado. Cuando la ingenier<65>a es el componente principal del producto, se debe enfatizar en el proceso de dise<73>o y los ingenieros deben entender la relaci<63>n entre la primicia y el tiempo de salida al mercado, m<>rgenes de producto, la tasa de rendimiento m<>nima para justificar la inversi<73>n en la compa<70>ia y otras consideraciones de negocios que influyen en el dise<73>o y las estrategias de implementaci<63>n.
\subsection{Estructura del Plan de Estudios CDIO}
La figura \ref{cdio_blocks} muestra los bloques constructores del plan de estudios CDIO, en el primer nivel podemos observar que todo individuo interesado en obtener habilidades t<>cnicas posee \textit{Habilidades Personales y Profesionales}, las cuales son fundamentales para la pr<70>ctica. Con el f<>n de desarrollar sistemas de ingenier<65>a complejos, los estudiantes deben dominar los fundamentos del \textit{Razonamiento y Conocimiento T<>cnico}. Para trabajar en un entorno moderno basado en equipos los estudiantes deben desarrollar \textit{Habilidades Interpersonales} de comunicaci<63>n y trabajo en equipo. Finalmente con el fin de ser capaz de crear y operar productos y sistemas un estudiante debe entender el concepto de \textit{Concebir, Dise<73>ar, Implementar y Operar Sistemas en el Contexto Social y Empresarial}\cite{EFC01}
\begin{figure}[H]
\begin{center} \includegraphics[scale=.8]{./images/CDIO.png} \end{center}
\caption{Bloques Constructores de conocimiento, habilidades y actitudes necesarias para Concebir, Dise<73>ar, Implementar y Operar sistemas en el contexto social y empresarial} fuente:\cite{EFC01} \label{cdio_blocks}
\end{figure}
\subsubsection{Nivel 1: Razonamiento y Conocimiento T<>cnico}
Los componentes del primer nivel \textit{Razonamiento y Conocimiento T<>cnico} son com<6F>nes a los planes de estudio de las ingenier<65>as modernas y son:
\begin{enumerate}
\item Fundamentos Avanzados de Igenier<65>a.
\item Fundamentos del n<>cleo de Ingenier<65>a.
\item Conocimiento cient<6E>fico.
\end{enumerate}
La raz<61>n de colocar este bloque constructor en el primer nivel es solo para recordar que el objetivo primordial de cualquier programa de pregrado es el desarrollo de un profundo conocimiento de fundamentos t<>cnicos. En este trabajo no se cambiar<61> este componente ya que para hacerlo es necesario un consenso con las dem<65>s carreras de la facultad de Ingenier<65>a, labor que puede tomar varios a<>os.
\subsubsection{Habilidades Personales, Profesionales e Interpersonales}
Los niveles 2 y 3 se centran en las habilidades personales que debe poseer un individo para que pueda cumplir con el objetivo de la Iniciativa CDIO. El nivel 2 esta compuesto por:
\begin{enumerate}
\item Las habilidades profesionales que representan las tres formas de pensar m<>s practicadas por los ingenieros: Resoluci<63>n de problemas, Descubrimiento de conocimiento y Pensamiento sist<73>mico.
\item Actitudes que incluyen integridad y comportamiento profesional as<61> como las necesarias para planear la profesi<73>n.
\end{enumerate}
Las habilidades que no hacen parte del contexto profesional ni del inter-personal son llamadas \textit{Habilidades y Actitudes Personales}, incluyen el car<61>cter, iniciativa, perseverancia, formas de pensar m<>s gen<65>ricas como pensamiento cr<63>tico, creativo y habilidades propias como curiosidad, aprendizaje continuo y manejo del tiempo.
Las habilidades inter-personales, son un subconjunto de las habilidades personales y se dividen en dos grupos que se traslapan llamados: Equipo de Trabajo y Comunicaciones. El grupo de trabajo se refiere a las habilidades necesarias para formar, operar, fortalecer y liderar un equipo con habilidades espec<65>ficas de un equipo de trabajo t<>cnico. La comunicaci<63>n se compone de habilidades para idear estrategias de comunicaci<63>n y aquellas para utilizar los medios orales, escritos, electr<74>nicos y gr<67>ficos y en el caso Colombiano el uso del idioma Ingl<67>s. La Figura \ref{cdio_2_3} muestra la relaci<63>n entre las habilidades de nivel 2 (Personales y Profesionales) y nivel 3 (Interpersonales).
\begin{figure}
\begin{center} \includegraphics[scale=.8]{./images/CDIO_2_3.png} \end{center}
\caption{Relaci<EFBFBD>n entre las Habilidades Personales, Profesionales e Interpersonales} fuente:\cite{EFC01} \label{cdio_2_3}
\end{figure}
\subsubsection{Habiidades CDIO}
Habilidades necesarias parea Concebir, Dise<73>ar, Implementar y Operar Systemas en el Contexto Social y empresarial. Estos cuatro componentes son necesarios para que los egresados de las carreras de Ingnier<65>a El<45>ctrica y Electr<74>nica sean capaces de absorver los conocimientos que las nuevas tecnolog<6F>as proporcionan, adaptarlos a la situaci<63>n tecnol<6F>gica y al contexto social del pa<70>s para generar productos que resuelvan necesidades locales. Para satisfacer una necesidad de la sociedad es necesario conocer la din<69>mica empresarial, los principios que la rigen y como se debe actuar en una empresa de cualquier tipo y tama<6D>o.
\subsection{Implementaci<EFBFBD>n del Plan de Estudios CDIO}
La Figura \ref{impl_CDIO} muestra los componentes que deben ser especificados para implementar el plan de estudios CDIO al curr<72>culo de las asignaturas del <20>rea de electr<74>nica digital. En primer lugar se encuentran los resultados esperados del proceso de aprendizaje, esto es, Qu<51> deben saber y que deben ser capaces de hacer los estudiantes al final del curso? Para contestar a esta pregunta es necesario definir las \textbf{habilidades} que ser<65>n reforzadas o desarrolladas y los \textit{objetivos} de cada asignatura.
\begin{figure}[H]
\begin{center} \includegraphics[scale=.6]{./images/CDIO_metodologia.png} \end{center}
\caption{Objetivos, Actividades, y Evaluaci<63>n: } \label{impl_CDIO}
\end{figure}
Para alcanzar los objetivos definidos en el primer paso, es necesario generar una serie de \textbf{actividades} que le permitan al estudiante: retener nuevos conocimientos y habilidades y desarrollar las competencias deseadas, el n<>mero de actividades debe ser tal que cubran todas las habilidades que se quieran desarrollar o reforzar.
Finalmente, se deben desarrollar m<>todos de evaluaci<63>n que permitan conocer el nivel de competencia de los estudiantes, y de esta forma ajustar las actividades para obtener los resultados esperados.
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%% IDENTIFICACION DE HABILIDADES CDIO %%%%%%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\section{Definici<EFBFBD>n e Identificaci<63>n de las Habilidades CDIO}
El primer paso en la implementaci<63>n del plan de estudios CDIO es definir e identificar las habilidades requeridas en una determinada <20>rea del plan de estudios, este estudio se centrar<61> en las asignaturas del <20>rea de electr<74>nica digital. En la Universidad Nacional de Colombia el <20>rea de Electr<74>nica Digital esta compuesta por tres asignaturas para la carrera de Ingenier<65>a Electr<74>nica: Electr<74>nica Digital 1, Electr<74>nica Digital 2 y Sistemas Embebidos. Para la carrera de Ingenier<65>a El<45>ctrica est<73> compuesta por Electr<74>nica Digital 1 (la misma en las dos carreras) <20>nicamente.
\subsection{Introducir, Ense<73>ar y Usar}
Para transladar esta lista de habilidades a objetivos de aprendizaje es necesario determinar el grado de competencia que se espera que el profesional adquiera en cada una de las asignaturas. Por supuesto, algunas de estas habilidades no pueden obtenerse en una asignatura, es necesario que todo el plan acad<61>mico contribuya a generar una determinada habilidad, lo que requiere un consenso del personal acad<61>mico. En el Departamento de Ingenier<65>a El<45>ctrica y Electr<74>nica de la Universidad Nacional de Colombia se est<73> realizando esta tarea y los resultados presentados en este estudio hacen parte de esta iniciativa.
Los niveles de competencia seleccionados para indicar el nivel en que debe ser apropiada una determinada habilidad son:
\begin{enumerate}
\item Introducir: Introduce pero no eval<61>a.
\item Ense<73>ar: Ense<73>a y eval<61>a.
\item Utilizar: Utiliza, puede ser evaluado o no.
\end{enumerate}
\subsection{Habilidades CDIO}
A continuaci<63>n se listan las habilidades CDIO que deben desarrollarse o reforzarse en el <20>rea de Electr<74>nica Digital, algunas de las habilidades como la comunicaci<63>n oral y escrita en Ingl<67>s es com<6F>n a la mayor<6F>a de las asignaturas, mientras que otras como la Integraci<63>n Software - Hardware es exclusiva,
%Redefine the first level
\renewcommand{\theenumi}{\arabic{enumi}}
\renewcommand{\labelenumi}{\theenumi}
%Redefine the second level
\renewcommand{\theenumii}{\arabic{enumii}}
\renewcommand{\labelenumii}{\theenumii}
\begin{enumerate}
\setcounter{enumi}{1}
% CDIO NIVEL 2
\item \textbf{Aptitudes personales y profesionales}
\begin{enumerate}
\item Razonamiento ana;<3B>tico y Resoluci<63>n de problemas
\begin{enumerate}
\item Identificaci<63>n y Formulaci<63>n del problema
\item Modelamiento
\item Soluci<63>n y recomendaci<63>n
\end{enumerate}
\item Experimentaci<63>n Investigaci<63>n y Descubrimiento de Conocimiento
\begin{enumerate}
\item Formulaci<63>n de hip<69>tesis
\item Investigaci<63>n experimental
\end{enumerate}
\item Pensamiento Sistem<65>tico
\begin{enumerate}
\item Pensamiento Global
\item Surgimiento e interacciones
\end{enumerate}
\item Pensamiento Cr<43>tico y Creativo y Habilidades y actitudes personales
\begin{enumerate}
\item Pensamiento creativo
\item Pensamiento cr<63>tico
\item Toma de conciencia de conocimientos propios y metaconocimiento.
\item Aprendizaje permanente y Educar a otros.
\end{enumerate}
\item <20>tica, Responsabilidad Profesional, Equidad y Otros Valores Personales.
\begin{enumerate}
\item <20>tica, integridad y responsabilidad social
\item Comportamiento profesional y responsabilidad
\item Confianza y lealtad
\end{enumerate}
\end{enumerate}
% CDIO NIVEL 3
\item \textbf{Habilidades interpersonales, trabajo en equipo y comunicaci<63>n}
\begin{enumerate}
\item Equipo de Trabajo
\begin{enumerate}
\item Formar grupos efectivos
\item Equipo de liderazgo
\item Equipo T<>cnico y multi-disciplinario.
\end{enumerate}
\item Comunicaciones estructuradas
\begin{enumerate}
\item Estrategia de comunicaci<63>n
\item Estructura de la comunicaci<63>n
\item Comunicaci<63>n Escrita
\item Comunicaci<63>n Electr<74>nica
\item Presentaci<63>n Oral
\end{enumerate}
\item Comunicaci<63>n en Idioma Extranjero
\begin{enumerate}
\item Ingl<67>s
\end{enumerate}
\item Comunicaciones Informales: Relacionarse con los dem<65>s
\begin{enumerate}
\item Preguntar, Escuchar y Dialogar
\item Negociaci<63>n, compromiso y resoluci<63>n de conflictos.
\item Establecimiento de conexiones
\end{enumerate}
\end{enumerate}
% CDIO NIVEL 4
\item \textbf{Concebir, Dise<73>ar, Implementar y Operar Sistemas en el Contexto Social y Empresarial}
\begin{enumerate}
\item Contexto Externo, Social, Econ<6F>mico y Ambiental
\begin{enumerate}
\item Rol y responsabilidad de los Ingenieros
\item Impacto sobre la sociedad y el medio ambiente
\item Cuestiones y valores actuales
\item Sostenibilidad y necesidad de un desarrollo sostenible.
\end{enumerate}
\item Empresa y contexto empresarial
\begin{enumerate}
\item Interesados en la empresa, metas y objetivos
\item Esp<73>ritu Empresarial T<>cnico
\item Trabajo en organizaciones
\item Finanzas y Econom<6F>s de los Proyectos de Ingenier<65>a
\end{enumerate}
\item Concepci<63>n y Administraci<63>n de Sistemas en Ingenier<65>a.
\begin{enumerate}
\item Entender las necesidades y establecer las metas
\item Definir la funci<63>n, concepto y arquitectura
\end{enumerate}
\item Dise<73>o
\begin{enumerate}
\item Proceso de Dise<73>o
\item Fases del proceso de Dise<73>o y enfoques
\item Utilizaci<63>n de conocimiento cient<6E>fico en el dise<73>o
\item Dise<73>o espec<65>fico
\item Dise<73>o multi-disciplinario
\end{enumerate}
\item Implementaci<63>n
\begin{enumerate}
\item Proceso de fabricaci<63>n Hardware
\item Proceso de Implementaci<63>n de Software
\item Integraci<63>n Software - Hardware
\item Pruebas, verificaci<63>n, validaci<63>n y certificaci<63>n
\end{enumerate}
\item Liderar Esfuerzos en ingenier<65>a
\begin{enumerate}
\item Pensar creativamente e Imaginar posibilidades
\item Definir la soluci<63>n
\item Crear nuevas formas de soluci<63>n
\item Construir y liderar una organizaci<63>n y una organizaci<63>n extendida.
\item Planear y administrar un prpyecto hasta su finalizaci<63>n.
\item Innovar - la concepci<63>n, dise<73>o e introducci<63>n de nuevos bienes y servicios.
\item Innovar - el desarrollo de nuevos dispositivos, materiales o procesos que permitan nuevos bienes y servicios.
\end{enumerate}
\item Emprendimiento en ingenier<65>a
\begin{enumerate}
\item Creaci<63>n, Formulaci<63>n y organizaci<63>n de una empresa.
\item Desarrollo del plan de negocios.
\item Finanzas y capitalizaci<63>n.
\item Mercadeo de productos innovadores
\item Cencepci<63>n de productos y servicios alrededor de nuevas tecnolog<6F>as.
\item Sistema de innovaci<63>n, redes, infraestructura y servicios.
\item Construyendo el equipo e iniciando el proceso de ingenier<65>a.
\item Manejo de la propiedad intelectual.
\end{enumerate}
\end{enumerate}
\end{enumerate}
\subsection{Competencias de las Habilidades CDIO 2 y 3}
La tabla \ref{compet_2_3} muestra las competencias IEU para las \textit{Aptitudes Personales y Profesionales} de las tres asignaturas del <20>rea de Electr<74>nica Digital.
\begin{center}
\begin{table}[H]
\begin{tabular}{|l|c|c|c|} \hline
\multicolumn{4}{|c|}{\textbf{Competencias de las Habilidades CDIO Nivel 2 y 3}} \\ \hline
\multirow{2}{*}{\textbf{APTITUDES PERSONALES Y PROFESIONALES}} & \multicolumn{3}{c|} {Nivel 1} \\
& E. Digital1 & E. Digital1 & Sist. Emb. \\ \hline
\textbf{\textit{Planteamiento y Resoluci<63>n de problemas de Ingenier<65>a}} & \multicolumn{3}{c|} {EU} \\ \hline
1 Identificaci<63>n y Formulaci<63>n del problema & \multicolumn{3}{c|} {EU} \\ \hline
2 Modelamiento & \multicolumn{3}{c|} {EU} \\ \hline
3 Soluci<63>n y recomendaci<63>n & \multicolumn{3}{c|} {EU} \\ \hline
\textbf{\textit{Experimentaci<EFBFBD>n y Descubrimiento de Conocimiento}} & \multicolumn{3}{c|} {U} \\ \hline
4 Formulaci<63>n de hip<69>tesis & \multicolumn{3}{c|} {U} \\ \hline
5 Investigaci<63>n experimental & \multicolumn{3}{c|} {U} \\ \hline
\textbf{\textit{Pensamiento Sistem<65>tico}} & \multicolumn{3}{c|} {EU} \\ \hline
6 Pensamiento Global & \multicolumn{3}{c|} {U} \\ \hline
7 Surgimiento e interacciones & \multicolumn{3}{c|} {U} \\ \hline
\textbf{\textit{Habilidades y actitudes personales}} & \multicolumn{3}{c|} {U} \\ \hline
8 Pensamiento creativo & \multicolumn{3}{c|} {IEU} \\ \hline
9 Pensamiento cr<63>tico & \multicolumn{3}{c|} {IEU} \\ \hline
10 Toma de conciencia de conocimientos propios & \multicolumn{3}{c|} {IEU} \\ \hline
11 Curiosidad y aprendizaje permanente
\textbf{\textit{Habilidades y actitudes profesionales}} & \multicolumn{3}{c|} {U} \\ \hline% \begin{enumerate}
12 <20>tica profesional, integridad, responsabilidad & \multicolumn{3}{c|} {U} \\ \hline
13 Comportamiento profesional & \multicolumn{3}{c|} {U} \\ \hline
39 Confianza y Lealtad & \multicolumn{3}{c|} {IEU} \\ \hline
\multirow{2}{*}{\textbf{HABILIDADES INTERPERSONALES}} & \multicolumn{3}{c|} {Nivel 1} \\
& E. Digital1 & E. Digital1 & Sist. Emb. \\ \hline
\textbf{\textit{Equipo de Trabajo}} & \multicolumn{3}{c|} {EU} \\ \hline
14 Formar grupos efectivos & EU & U & U \\ \hline
15 Equipo de Liderazgo & EU & U & U \\ \hline
40 Equipo T<>cnico y Multi-disciplinario & EU & U & U \\ \hline
\textbf{\textit{Comunicaciones estructuradas}} & \multicolumn{3}{c|} {EU} \\ \hline
16 Estrategia de comunicaci<63>n & EU & U & U \\ \hline
17 Estructura de la comunicaci<63>n & EU & U & U \\ \hline
18 Comunicaci<63>n Escrita & EU & U & U \\ \hline
19 Comunicaci<63>n Electr<74>nica & EU & U & U \\ \hline
20 Presentaci<63>n Oral & EU & U & U \\ \hline
\textbf{\textit{Comunicaci<EFBFBD>n en Idioma Extranjero}} & \multicolumn{3}{c|} {U} \\ \hline
21 Ingl<67>s & \multicolumn{3}{c|} {U} \\ \hline
\textbf{\textit{Comunicaciones Informales: Relacionarse con los dem<65>s}} & \multicolumn{3}{c|} {U} \\ \hline
41 Preguntar, Escuchar y Dialogar & EU & U & U \\ \hline
42 Negociaci<63>n, compromiso y resoluci<63>n de conflictos & EU & U & U \\ \hline
43 Establecimiento de conexiones & IEU& U & U \\ \hline
\end{tabular}
\caption{Competencias para los niveles 2 y 3 CDIO} \label{compet_2_3}
\end{table}
\end{center}
\subsection{Competencias de las Habilidades C.D.I.O. Sistemas en el contexto Empresarial, Social y Ambiental - Innovaci<63>n}
La tabla \ref{compet_4} muestra las competencias IEU para las \textit{C.D.I.O. Sistemas en el contexto Empresarial, Social y Ambiental - Innovaci<63>n} de las tres asignaturas del <20>rea de Electr<74>nica Digital.
\begin{center}
\begin{table}[H]
\begin{tabular}{|l|c|c|c|} \hline
\multirow{2}{*}{\textbf{HABILIDADES CDIO}} & \multicolumn{3}{c|} {Nivel 1} \\
& E. Digital1 & E. Digital1 & Sist. Emb. \\ \hline
\textbf{\textit{Contexto Externo, Social, Econ<6F>mico y Ambiental}} & \multicolumn{3}{c|} {IEU} \\ \hline
22 Rol y responsabilidad de los Ingenieros & \multicolumn{3}{c|} {IEU} \\ \hline
23 Impacto sobre la sociedad y el medio ambiente & \multicolumn{3}{c|} {IEU} \\ \hline
24 Cuestiones y valores actuales & \multicolumn{3}{c|} {IEU} \\ \hline
44 Sostenibilidad y necesidad de un desarrollo sostenible& IE & IE & IE \\ \hline
\textbf{\textit{Empresa y contexto empresarial}} & \multicolumn{3}{c|} {EU} \\ \hline
25 Interesados en la empresa, metas y objetivos & \multicolumn{3}{c|} {I} \\ \hline
26 Esp<73>ritu Empresarial T<>cnico & \multicolumn{3}{c|} {I} \\ \hline
27 Trabajo exitoso en organizaciones & \multicolumn{3}{c|} {I} \\ \hline
45 Finanzas y Econom<6F>a de los Proyectos de Ingenier<65>a & IE & IE & IE \\ \hline
\textbf{\textit{Concepci<EFBFBD>n y Administraci<63>n de Sistemas en Ingenier<65>a.}} & \multicolumn{3}{c|} {IEU} \\ \hline
28 Entender las necesidades y establecer las metas & IEU & EU & U \\ \hline
29 Definir la funci<63>n, concepto y arquitectura & IEU & EU & U \\ \hline
\textbf{\textit{Dise<EFBFBD>o}} & \multicolumn{3}{c|} {IEU} \\ \hline
30 Proceso de Dise<73>o & IEU & EU & U \\ \hline
31 Fases del proceso de Dise<73>o y enfoques & IEU & EU & U \\ \hline
32 Utilizaci<63>n de conocimiento cient<6E>fico en el dise<73>o & IEU & EU & U \\ \hline
33 Dise<73>o espec<65>fico & IEU & EU & U \\ \hline
34 Dise<73>o multi-disciplinario & I & E & U \\ \hline
\textbf{\textit{Implementaci<EFBFBD>n}} & \multicolumn{3}{c|} {EU} \\ \hline
35 Proceso de fabricaci<63>n Hardware & IE & EU & U \\ \hline
36 Proceso de Implementaci<63>n de Software & I & EU & U \\ \hline
37 Integraci<63>n Software - Hardware & I & EU & U \\ \hline
38 Pruebas, verificaci<63>n, validaci<63>n y certificaci<63>n & IE & EU & U \\ \hline
\end{tabular}
\caption{Competencias para CDIO} \label{compet_4}
\end{table}
\end{center}
\section{Integraci<EFBFBD>n de las Habilidades CDIO al Plan de Estudios}
\subsection{Objetivo General}
Generar en el estudiante las habilidades necesarias para Concebir, Dise<73>ar, Implementar y Operar Sistemas Digitales complejos que satisfagan necesidades de la sociedad y proporcionar un canal para la transferencia de Tecnolog<6F>a y conocimiento a la Industria Colombiana. La Figura \ref{design_method} muestra la metodolog<6F>a de dise<73>o para las diferentes asignaturas del <20>rea.
\begin{figure}[H]
\begin{center} \includegraphics[scale=.8]{./images/habilidades_digitales.png} \end{center}
\caption{Metodolog<EFBFBD>a de Dise<73>o para el <20>rea de Sistemas Digitales} \label{design_method}
\end{figure}
\subsubsection{Electr<EFBFBD>nica Digital 1}
Concebir y definir las especificaciones y requerimientos de un Sistema Digital, modelar su funcionamiento, y realizar la implementaci<63>n siguiendo la metodolog<6F>a de dise<73>o de Sistemas Embebidos utilizando <20>nicamente tareas Hardware.
\subsubsection{Electr<EFBFBD>nica Digital 2}
Concebir, definir las especificaciones, modelar, dise<73>ar un Sistema Digital siguiendo la metodolog<6F>a de dise<73>o de Sistemas Embebidos y realizar su implementaci<63>n <20>ptima utilizando tareas Hardware (que se ejecutan en un PLD) y tareas Software (que se ejecutan en un procesador).
\subsubsection{Sistemas Embebidos}
Concebir, dise<73>ar, e Implementar un sistema digital complejo utilizando la metodolog<6F>a de dise<73>o de sistemas Embebidos y un Sistema Operativo para su Implementaci<63>n.
\subsection{Objetivos Espec<65>ficos}
\subsection {Ojbetivos com<6F>nes}
\begin{itemize}
\item Identificar las especificaciones funcionales del sistema, su arquitectura de alto nivel y definir su descomposici<63>n en elementos
\item Explicar las actividades en las etapas del proceso de dise<73>o,
\item Desarrollar el pensamiento sist<73>mico.
\item Modelar funcionalmente Sistemas Digitales.
\item Dise<73>ar pruebas para comprobar el correcto funcionamiento de los sistemas implementados.
\item Leer y entender material t<>cnico escrito en ingl<67>s.
\item Implementar un Sistemas Embebido (Hardware o Hardware/Software) para cumplir una tarea determinada que cumpla con una necesidad real (Obtener e interpretar las necesidades del consumidor) utilizando t<>cnicas, herramientas y procesos adecuados.
\item Estudiar y aplicar el concepto de la re-utilizaci<63>n de c<>digo.
\item Desarrollar trabajo en equipo incluyendo presentaciones, describiendo los diversos roles y responsabilidades.
\item Documentar los dise<73>os realizados para crear una base de datos que contribuya a la difusi<73>n del conocimiento adquirido.
\end{itemize}
\subsubsection{Electr<EFBFBD>nica Digital 1}
\begin{itemize}
\item Estudiar las fases de la metodolog<6F>a de dise<73>o para Sistemas Embebidos.
\item Estudiar los dominios de dise<73>o Estructural, Funcional y F<>sico.
\item Estudiar los Lenguajes de Descripci<63>n de Hardware.
\item Estudiar los componentes b<>sicos de la l<>gica combinatoria y secuencial.
\end{itemize}
\subsubsection{Electr<EFBFBD>nica Digital 2}
\begin{itemize}
\item Estudiar los requisitos para un particionamiento Hardware / Software <20>ptimo.
\item Estudiar la arquitectura de un procesador, micro-arquitectura, set de instrucciones, interrupciones, direccionamiento.
\item Estudiar el proceso de implementaci<63>n de tareas software.
\item Estudiar la integraci<63>n Software-Hardware.
\item Dise<73>ar pruebas para comprobar el correcto funcionamiento de los sistemas implementados.
\end{itemize}
\subsubsection{Sistemas Embebidos}
\begin{itemize}
\item Realizar aplicaciones que requieran dise<73>o multi-disciplinario.
\item Estudiar y realizar el proceso de Fabricaci<63>n Hardware.
\item Estudiar el principio b<>sico de los sistemas operativos.
\item Describir la integraci<63>n de software en hardware electr<74>nico
\item Entender diagramas de circuitos electr<74>nicos de sistemas digitales, identifcar sus componentes y su funci<63>n.
\item Estudiar dise<73>os software y hardware existentes para entender su funcionamiento, arquitectura y adquirir experiencia en el dise<73>o.
\item Hacer parte de listas de discusi<73>n de temas t<>cnicos que usen el ingl<67>s como lenguaje.
\end{itemize}
\subsection{Contenido}
\subsubsection{Electr<EFBFBD>nica Digital 1}
\begin{itemize}
\item \textbf{Flujo de Dise<73>o de Sistemas Embebidos}
\begin{itemize}
\item Sistemas Digitales: Panorama Y Perspectiva
\item Metodolog<6F>a de Dise<73>o
\item Representaciones de Dise<73>o y Niveles de Abstracci<63>n
\end{itemize}
\item \textbf{Sistemas Num<75>ricos y Operaciones Aritm<74>ticas}
\begin{itemize}
\item Representaci<63>n de Datos
\item Sistemas num<75>ricos: Binario, Octal Hexadecimal
\item Representaci<63>n de n<>meros negativos
\item Algoritmos para la implementaci<63>n de operaciones aritm<74>ticas
\begin{itemize}
\item Camino de Datos
\item Control
\end{itemize}
\end{itemize}
\item \textbf{L<EFBFBD>gica Combinatoria}
\begin{itemize}
\item Definici<63>n.
\item Ecuaciones Booleanas, Formas can<61>nicas.
\item M<>dulos B<>sicos: Multiplexores, codificadores, sumadores, restadores comparadores.
\end{itemize}
\item \textbf{L<EFBFBD>gica Secuencial}
\begin{itemize}
\item Definici<63>n
\item Elementos de memoria:
\begin{itemize}
\item Latch
\item Flip-Flop
\end{itemize}
\item Bloques b<>sicos
\begin{itemize}
\item Registros
\item Acumuladores
\item Contadores
\end{itemize}
\item M<>quina de Estados Finitos (FSM)
\begin{itemize}
\item Arquitectura
\item Tipos: Mealy, Moore
\item Diagramas de Estado
\item S<>ntesis de M<>quinas de Estado
\end{itemize}
\item M<>quinas de Estado Algor<6F>tmicas (ASM)
\begin{itemize}
\item Tareas Hardware
\item Componentes: Camino de Datos y M<>quina de Control
\item Implementaci<63>n de operaciones aritm<74>ticas utilizando ASM
\item Identificaci<63>n, funcionamiento e interfaz de bloques constructores.
\item Interacci<63>n entre el Camino de Datos y la M<>quina de Control
\item Lenguajes de Descripci<63>n de Hardware
\end{itemize}
\end{itemize}
\item \textbf{Tecnolog<EFBFBD>as de Implementaci<63>n}
\begin{itemize}
\item Familia L<>gica CMOS
\begin{itemize}
\item Principio de funcionamiento, consumo de potencia
\item Niveles L<>gicos y m<>rgenes de ruido
\item Retardos, Manejo de Corriente
\item Compuertas tri-estado y Open-Drain
\end{itemize}
\item Dispositivos L<>gicos Programables
\begin{itemize}
\item Arreglos L<>gicos Programables (PALs)
\item Dispositivos L<>gicos Programables (PLDs, CPLDs)
\item Arreglo de Compuertas Programable en Campo (FPGA)
\item Flujo de Dise<73>o - Programaci<63>n en Sistema
\end{itemize}
\end{itemize}
\item \textbf{Introducci<EFBFBD>n a los procesadores}
\begin{itemize}
\item M<>quina de Estados Algor<6F>tmica Programable
\end{itemize}
\end{itemize}
\subsubsection{Electr<EFBFBD>nica Digital 2}
\begin{itemize}
\item \textbf{Codise<EFBFBD>o Hardware-Software}
\begin{itemize}
\item Flujo de Dise<73>o y Particionamiento HW/SW.
\item Comunicaci<63>n SW -> HW (Direccionamiento)
\item Comunicaci<63>n HW -> SW (Interrupciones)
\item Componentes de un Sistema etherog<6F>neo.
\begin{itemize}
\item Procesador
\item Buses
\item Perif<69>ricos
\item Memorias
\end{itemize}
\end{itemize}
\item \textbf{Arquitectura de Procesadores}
\begin{itemize}
\item Micro-Arquitectura
\item Set de Instrucciones
\item Modos de direccionamiento
\item Interrupciones
\item Pipeline
\end{itemize}
\item \textbf{Implementacion de Tareas Hardware}
\begin{itemize}
\item Arquitectura de computadores
\begin{itemize}
\item CPU
\item Memorias
\item Perif<69>ricos
\item Mapa de Memoria
\item Controlador de Interrupciones Programable
\end{itemize}
\item Definici<63>n de la Interfaz HS <-> SW
\item Implementaci<63>n de Tareas Hardware en Perif<69>ricos.
\end{itemize}
\item \textbf{Flujo de Dise<73>o Software}
\begin{itemize}
\item Cadena de Herramientas:
\begin{itemize}
\item Compilador
\item Librer<65>as standard
\item Depurador
\item Utilidades binarias
\item C<>digo de Inicio C RunTime crt0
\item Herramienta \textit{make}
\end{itemize}
\item Integraci<63>n del Software sobre hardware Electr<74>nico.
\begin{itemize}
\item Ejecuci<63>n en Memoria Interna
\item Ejecuci<63>n en Memoria Externa: Bootloaders
\end{itemize}
\item Implementaci<63>n de tareas software y comunicaci<63>n con tareas Hardware.
\end{itemize}
\item \textbf{Sistemas Sobre Silicio}
\begin{itemize}
\item Arquitectura
\end{itemize}
\end{itemize}
\subsubsection{Sistemas Embebidos}
\begin{itemize}
\item \textbf{Sistemas Embebidos}
\begin{itemize}
\item Definici<63>n,aplicaciones
\item Metodolog<6F>a de Dise<73>o
\item Arquitectura
\begin{itemize}
\item Sistema Sobre Silicio
\item Circuitos de Referencia
\end{itemize}
\end{itemize}
\item Iniclializaci<63>n
\begin{itemize}
\item M<>todos de arranque
\item Bootloaders
\end{itemize}
\item \textbf{Sistema Operativo Linux}
\begin{itemize}
\item Arquitectura
\item Sincronizaci<63>n entre procesos
\item Estructura del Kernel y Organizaci<63>n del c<>digo fuente
\item Drivers de Dispositivos y m<>dulos del kernel
\item Im<49>gen del kernel
\item Inicializaci<63>n del Kernel
\end{itemize}
\item \textbf{Sistema de Archivos del root}
\begin{itemize}
\item Tipos de Sistema de Archivos
\item Estructura del Sistema de Archivos del root
\item Archivos de configuraci<63>n y niveles de ejecuci<63>n.
\item Montaje del sistema de archvios del root
\end{itemize}
\item \textbf{Interfaz con dispositivos externos al SoC}
\begin{itemize}
\item Control utilizando se<73>ales de Entrada/Salida de prop<6F>sito general (GPIOs)
\item Utilizando puertos de comunicaciones UART, I2C, SPI, USB.
\item Utilizando el controlador de memorias externas del SoC
\end{itemize}
\item \textbf{Interfaz con Perif<69>ricos Dedicados Implementados en PLDs}
\begin{itemize}
\item Configuraci<63>n del PLD utilizando GPIOs del SoC
\item Definici<63>n de la Interfaz HW y SW
\item Comunicaci<63>n con perif<69>ricos dedicados
\end{itemize}
\end{itemize}
\subsection{Metodolog<EFBFBD>a}
Todas las actividades que se realizar<61>n en estos cursos est<73>n encamindas a generar habilidades necesarias para Concebir, Dise<73>ar, e Implementar Sistemas Digitales Complejos, y est<73>n articuladas alrededor de una <20>nica metodolog<6F>a de dise<73>o (la aceptada internacionalmente para el dise<73>o de sistemas embebidos). Los tres cursos se diferencian en el medio donde se realiza la implementaci<63>n de las tareas y el tipo de las mismas, en el primer curso todas las tareas son Hardware y se implementar<61>n en un PLD, en el segundo las tareas son de tipo hardware y software y ser<65>n implementadas en un PLD. El tercer curso tambi<62>n implementa tareas hardware y software pero utiliza componentes utilizados en dispositivos comerciales, esto es, SoCs para implementar las tareas Software y PLDs para las tareas hardware. El conocimiento adquirido en cada asignatura ser<65> la base del siguiente curso.
Los tres cursos tienen un car<61>cter te<74>rico-pr<70>ctico, el componente te<74>rico tratar<61> los diferentes temas de forma general, con el f<>n de no crear dependencia con las herramientas utilizadas (lo que permitir<69> realizar actualizaci<63>nes de forma f<>cil). En el componente pr<70>ctico se tratar<61>n temas espec<65>ficos de manejo de las herramientas (Lenguajes de Descripci<63>n de Hardware, lenguajes de programaci<63>n, manejo de plataformas de desarrollo) y como estas se relacionan con la metodolog<6F>a de dise<73>o utilizada.
El estudiante debe estudiar, profundizar y comprobar algunos temas tratados en clase y debe leer previamente la documentaci<63>n que se encuentra disponible en el sitio web de los cursos. Adicionalmente, debe formar grupos de trabajo para realizar actividades a lo largo del semestre.
Durante el semestre se trabajar<61> para definir las especificaciones, dise<73>ar e implementar un dispositivo que resuelva una determinada necesidad (con la complejidad adecuada para cada curso), en la sesi<73>n te<74>rica se tratar<61>n aspectos relacionados con la concepci<63>n, dise<73>o, Identificaci<63>n y definici<63>n de las funciones de los componentes del sistma, mientras que en los relacionados con la implementaci<63>n de dichos componentes sobre PLDs o SoC. Se deben realizar presentaciones del avance, indicando las razones que se tuvieron en cuenta en cada decisi<73>n y somo se resolvieron los problemas encontrados, todo este proceso debe documentarse en el sitio web del curso.
El laboratorio est<73> relacionado con la pr<70>ctica y proporciona el conocimiento y habilidades para manejar y entender las herramientas Hardware y Software utilizadas en la implementaci<63>n. Las actividades programadas, deben ser entregadas con un informe donde se evidencie el uso de la metodolog<6F>a de dise<73>o utilizada, adicionalmente el estudiante debe defender y explicar su dise<73>o.
Se utilizar<61>n los siguientes m<>todos de calificaci<63>n:
\begin{itemize}
\item Pruebas escritas donde se verificar<61> la asimiliaci<63>n de conocimiento.
\item Sustentaci<63>n oral de procesos de dise<73>o e Implementaci<63>n.
\item Evaluaci<63>n del avance del proceso de Concepci<63>n, Dise<73>o e Implementaci<63>n del Proyecto Final.
\end{itemize}
\subsection{Actividades}
\subsubsection{Lectura de material del curso 10, 11}
Con la lectura previa de los temas, el estudiante adquiere la capacidad de absorver conocimiento (11), identificar sus preferenicas, deficiencias y buscar ayuda para suplirlas (10), lo cual ayuda al mejoramiento de las habilidades para el auto-aprendizaje, uno de los problemas detectados en los estudiantes es la necesidad de una autoridad que le proporcione la informaci<63>n que necesita para resolver un problema o tomar una decisi<73>n.
\subsubsection{Lectura de material T<>cnico en Ingl<67>s 10, 11, 6, 30, 33, 21}
La mayor parte de la documentaci<63>n de los componentes electr<74>nicos esta escrita en ingl<67>s t<>cnico, es necesario que el estudiante aprenda a entender este tipo de escritura y se familiarice con su estructura. Esto le permite identificar el funcionamiento de un componente del sistema (6,30), determinar que componente se adapta mejor a sus necesidades (33) y mejorar sus habilidades para comunicarse en ingl<67>s 21.
\subsubsection{Utilizaci<EFBFBD>n de Metodolog<6F>as de Dise<73>o 1, 2, 3, 6, 7, 9, 28, 29, 30, 31, 32, 33, 34, 35, 36, 37, 38}
La metodolog<6F>a de dise<73>o(30,31,) de sistemas embebidos requiere identificar un problema(1, 28), plantear una soluci<63>n(3,29,32) l<>gica (9) de alto nivel (9), modelarla (2) a nivel de sistema(6), verificar el cumplimiento de los requerimientos(33,38). Proporciona m<>todos para determinar su arquitectura <20>ptima (particionamiento HW/SW) y definir la funci<63>n e interacci<63>n(37,7) de sus componentes software (36) y hardware (35).
\subsubsection{Implementaci<EFBFBD>n de Sistemas Digitales Sencillos 3, 14, 29, 30, 35, 36, 17, 18, 19}
La realizaci<63>n de pr<70>cticas de laboratorio en las que grupos de trabajo (14) implementan dise<73>os de baja o media complejidad le permite al estudiante: Formular recomendaciones (3) para que no se repitan errores en experiencias futuras. Utilizar sistemas de desarrollo (30) para la implementaci<63>n de tareas HW y SW a bajo nivel (36). Con el fin de mejorar la capacidad de comunicaci<63>n escrita (18, 19) se deben presentar informes que refuercen las habilidades generadas en la utilizaci<63>n de la metodolog<6F>a de dise<73>o, por lo que se deben tener la siguiente estructura(17):
\begin{itemize}
\item Un diagrama de caja negra que indique las entradas y salidas del sistema.
\item Una descripci<63>n de alto nivel del algoritmo que implementa la soluci<63>n (29).
\item Un diagrama de bloques que indique el particionamiento y la interconexi<78>n entre sus componentes (30).
\item Descripciones de alto nivel de cada uno de los componentes (31).
\item La implementaci<63>n y simulaci<63>n de cada componente y del sistema completo (35), donde se muestre que el sistema cumple con las especificaciones funcionales(38)
\end{itemize}
\subsubsection{Proyecto Final 1,2,3, 14, 15, 30, 31, 32, 33, 34, 35, 22, 23, 24, 25, 27}
Durante el semestre se trabajar<61> para definir las especificaciones(1,2,3), dise<73>ar(30,31,32,33,34) e implementar un dispositivo que resuelva una hipot<6F>tica necesidad de la sociedad (22) (con la complejidad adecuada para cada curso), en la sesi<73>n te<74>rica se tratar<61>n aspectos relacionados con la concepci<63>n, dise<73>o, Identificaci<63>n y definici<63>n de las funciones de los componentes del sistema, mientras que en el componente pr<70>ctico, los relacionados con la implementaci<63>n de dichos componentes sobre PLDs o SoC.
A los estudiantes se les hace una descripci<63>n funcional de alto nivel del sistema, ellos deben organizarse en grupos de trabajo (14,15), definir la funci<63>n de cada uno de estos grupos (27,14,31), establecer estrategias de comunicaci<63>n (16,31), realizar y/o cumplir un cronograma de actividades (25,31) que permitan resolver la necesidad en el tiempo especificado (22). Una de las estrategias de comunicaci<63>n es la realizaci<63>n de presentaciones orales (20), en las que cada equipo de trabajo expondr<64> el estado de su sub-proyecto, indicando las razones que se tuvieron en cuenta en cada decisi<73>n y como se resolvieron los problemas encontrados (24). Adicionalmente todo este proceso debe documentarse en el sitio web del curso (wiki) con el objetivo de crear una base de proyectos que permitan a futuros estudiantes utilizar la experiencia obtenida (23) y en un determinado caso dar continuidad al proyecto.
El estudiante debe dise<73>ar y construir placas de circuito impreso con los circuitos necesarios para su aplicaci<63>n (35) siguiendo las normas de dise<73>o establecidas por el fabricante (resoluci<63>n, n<>mero de capas, costo) y las restricciones del circuito (Capacidad de corriente, niveles de ruido, compatibilidad electromagn<67>tica, etc).
Vale la pena aclarar que durante el primer curso los estudiantes no poseen la experiencia necesaria para realizar (sin asistencia) labores como la divisi<73>n de tareas, generaci<63>n de un cronograma de actividades y fijar la estrategia de comunicaci<63>n, raz<61>n por la cual el docente debe acompa<70>ar este proceso.
\subsubsection{Participaci<EFBFBD>n en listas de discuci<63>n 21}
Con el objeto de aumentar las capacidades en la comunicaci<63>n en idioma extranjero, se alentar<61> a los estudiantes a que hagan parte de listas de discusi<73>n en diferentes temas t<>cnicos, algunos problemas que encontrar<61>n en la realizaci<63>n de las diferentes pr<70>cticas deben ser consultados en estas listas para encontrar una forma de soluci<63>n
\subsection{Plataforma de Desarrollo SAKC}
La plataforma SAKC fu<66> dise<73>ada para ser utilizada como herramienta de implementaci<63>n para los tres cursos de esta <20>rea. Est<73> compuesta (ver Figura \ref{sakc_block}) por una FPGA y un Procesador, lo que permite la implementaci<63>n de tareas Hardware y Software utilizando <20>nicamente la FPGA o el procesador y la FPGA.
\begin{figure}[h]
\begin{center} \includegraphics[scale=.8]{./images/SAKC_block_diagram.png} \end{center}
\caption{Diagrama de Bloques de la Plataforma de Desarrollo SAKC}\label{sakc_block}
\end{figure}
Durante el primer curso, el procesador de la plataforma se utilizar<61> para configurar a la FPGA con las tareas hardware sitetizadas por los estudiantes. esta plataforma carece (intencionalmente) de elementos comunmente utilizados en las plataformas de desarrollo para PLDs como Pulsadores, Leds, Displays o conectores espaciales, lo que obliga a los estudiantes a investigar la forma de conexi<78>n de estos y a construir circuitos que permitan la conexi<78>n de la plataforma con estos elementos de interfaz con el usuario o con otros sistemas.
\begin{figure}[h]
\centering
\mbox{
\subfigure[Big]{\includegraphics[scale=.5]{./images/SAKC.png}}
\subfigure[Small]{\includegraphics[scale=.5]{./images/SAKC_LCD.png}}
}
\caption{Plataforma de Desarrollo SAKC}
\label{sakc}
\end{figure}
La capacidad de la FPGA de SAKC permite la implementaci<63>n de procesadores soft-core (como plasma y microblaze), posibilitando la implementaci<63>n de tareas Hadware y software en ella. El procesador ser<65> utilizado al finalizar el curso para comparar el desempe<70>o (velocidad, consumo de potencia, costo) entre un procesador soft-core y un procesador comercial.
El ultimo curso utilizar<61> el procesador para la ejecuci<63>n de tareas software y la FPGA para ejecutar las tareas Software, se har<61> uso de herramientas utilizadas actualmente en el dise<73>o de Aplicaciones comerciales de multinacionales como Nokia (QT), Motorola (Linux).
\subsubsection{Hardware y Software Copy-Left}
El conocimiento debe ser considerado un bien com<6F>n y se debe garantizar el acceso a todo el mundo. Por esta raz<61>n SAKC proporciona la documentaci<63>n necesaria para:
\begin{itemize}
\item Estudiar. entender, y reproducir o modificar su Arquitectura.
\item Conocer su proceso de fabricaci<63>n.
\item Entender su funcionamiento global y la interacci<63>n de sus componentes.
\item Estudiar tutoriales que explican su programaci<63>n.
\item Descargar, estudiar y modificar el c<>digo fuente de todas las aplicaciones existentes actualmente.
\item Realizar consultas con los creadores de las aplicaciones y de las plataforma de desarrollo.
\item Contribuir a mejorar la calidad de la documentaci<63>n y crear nueva informaci<63>n.
\end{itemize}
SAKC esta distribuido bajo la licencia Creative Commons \textit{(CC) BY - SA}, la que permite la distribuci<63>n y modificaci<63>n del dise<73>o (incluso para aplicaciones comerciales), con el <20>nico requisito de que los productos derivadas deben tener la misma licencia.
\section{Desarrollo de M<>todos de Evaluaci<63>n}
% 6. Evaluation is the making of judgments about the value, for some purpose, of ideas, works, solutions,
% methods, material, etc. It involves the use of criteria and standards for appraising the extent to which
% particulars are accurate, effective, or satisfying. It may be quantitative or qualitative.
% Verb examples that represent intellectual activity on this level include: assess, defend, evaluate.
% Examples from the Syllabus:
% Assess one?s skills, interests, strengths and weaknesses
% Evaluate supporting evidence
% A way in which to view the structure of the Bloom verbs is shown in Table B1, which gives the six
% levels, and identifies three to five key verbs within each level. Some common synonyms for those key
% verbs are also listed. Verbs in Italics of Table B1 are commonly used Bloom verbs, and those in regular
% font were added to better fit with technically oriented topics of the Syllabus. The verbs in the column
% to the far right of Table B1 are commonly used Bloom verbs that we recommend not be used with the
% Syllabus. This is because the verbs either appear at two levels, and therefore are ambiguous, or
% because they have a technical connotation apart from their common meaning, which causes them to be
% misplaced in terms of level. Entries in bold will be used in the Bloom verb patterns discussed below.
% B-3
% B.2 The Affective Domain
% The affective domain relates to the emotional component of learning. It emphasizes a feeling, tone, an
% emotion, or a degree of acceptance or rejection. Affect encompasses a range from simple attention to
% organization and characterization of complex, but internally consistent, qualities of character and
% conscience. Krathwohl, Bloom and Masia (1964) developed five levels in the affective domain.
% 1. Receiving (attending): Receiving speaks to an awareness that a learner is conscious of something,
% that he/she take into account a situation, phenomenon or state of affairs. It also addresses the
% learner's willingness to receive information. In other words the climate must be set so that students
% attention is grabbed and directed in a particular manner.
% Verb examples which represent intellectual activity on this level include: a s k , accept, hold.
% Examples from the Syllabus:
% Accepts the need for a commitment to service
% Accepts the goals and roles of the engineering profession
% 2. Responding: At the responding level, students are sufficiently motivated that they are not just
% willing to attend, but are actively attending. It involves a continuum from acquiescence in responding,
% to willingness to respond, to satisfaction in response. In other words, it is active participation by the
% students in their own learning.
% Verb examples that represent intellectual activity on this level include: answer, assist, discuss.
% Examples from the Syllabus:
% Discuss the motivation for continued self-education
% Discuss the importance of both a depth and breadth of knowledge
% 3. Valuing: Simply put, something has value or worth. At this level, behavior is sufficiently
% consistent and stable as to be characterized as a belief or attitude. The student is perceived as holding
% a value. This level ranges from acceptance of a value, to preference, to commitment to a value.
% Verb examples that represent intellectual activity on this level include: demonstrate a belief in,
% embrace, follow, join, share, value.
% Examples from the Syllabus:
% Embrace one?s responsibility for self improvement
% Value a willingness to work independently
% 4. Organization refers to the process learners go through after they internalize values and are faced
% with situations for which more than one value is relevant. This necessitates the organization of values
% into a system, determining the relationship among them, and establishing dominant and pervasive
% values. The emphasis is on comparing, relating, and synthesizing values.
% Verb examples that represent intellectual activity on this level include: alter, combine, complete,
% integrate, order, organize, relate, synthesize .
% B-4
% Example from the Syllabus:
% Integrate the potential benefits and risks of an action
% 5. Characterization by a value or value complex: At this level the individual acts consistently in
% accordance with the values he/she has internalized. A behavior is pervasive, consistent, predictable,
% and characteristic of the student. Student beliefs, ideas, and attitudes are integrated into a total
% philosophy or view of the world.
% Verb examples that represent intellectual activity on this level include: discriminate, display,
% influence, presuppose, qualify, resolve, solve, verify.
% Example from the Syllabus:
% Resolves conflicting issues in the balance between personal and professional life
% B.3 The Psychomotor Domain
% The psychomotor domain emphasizes physical skills. It involves muscular or motor skill, some
% manipulation of materials and objects, or some act which requires a neuromuscular coordination. It
% captures the complexity of grace, strength, and speed that is often involved in physical activity or
% skill acquisition.
% While there are a few examples in the CDIO Syllabus that touch on the psychomotor domain, these
% topics all have an important cognitive component as well. Therefore the cognitive verbs are
% consistently used for these topics, and the psychomotor categories are not used in the Syllabus.
% For completeness, it is worth outlining the breakdown of this domain by Simpson (1972) into seven
% levels.
% 1. Perception is defined as the ability to use sensory cues to guide motor activity.
% 2. Set refers to the readiness to take a particular course of action. This includes physical and
% emotional set as well as mental.
% 3. Guided Response: refers to imitation and trial and error in which the adequacy of the performance
% is judged by the instructor or by a defined set of criteria.
% 4. Mechanism: describe learned responses that have become habitual, movements can be performed
% with some confidence and proficiency.
% 5. Complex Overt Responses: is the skillful performance of motor acts that involve complex movement
% patterns. Proficiency is indicated by a quick, accurate, and highly coordinated performance, requiring
% a minimum of energy. In this category, responses are automatic.
% 6. Adaptation: is the level at which skills are so well developed that the individual can modify
% movement patterns to fit special requirements or to meet a problem situation.
% 7. Origination is the creation of new movement patterns to fit a particular situation or specific
% problem. Outcomes at this level emphasize creativity based upon highly developed skills.

View File

@@ -0,0 +1,815 @@
\chapter{Habilidades CDIO}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%% INTRODUCCION %%%%%%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\section{Introducci<63>n}
La iniciativa CDIO \footnote{http://www.cdio.org} ha sido desarrollada con ayuda de academicos, industriales, ingenieros y estudiantes\cite {WCI}. Es posible adaptar esta iniciativa a cualquier centro educativo en Ingenier<65>a, y ha sido adoptada por un creciente n<>mero de instiruciones acad<61>micas a lo largo del mundo.
La educaci<63>n de la ingenier<65>a y las demandas del mundo real est<73>n tomando caminos separados, la Iniciativa CDIO es un proyecto mundial que busca desarrollar una nueva visi<73>n de la educaci<63>n en ingenier<65>a. Hacer parte de este esfuerzo mundial nos ayuda a mantener nuestros planes acad<61>micos actualizados con los cambios que se realizan en pa<70>ses m<>s industrializados. En este cap<61>tulo mostraremos como esta iniciativa se adapta perfectamemente a los cambios que se han inroducido en el <20>rea de la electr<74>nica digital en la universidad Nacional de Colombia.
La Iniciativa CDIO se basa en la suposici<63>n que los egresados de los centros de formaci<63>n en ingenier<65>a deben ser capaces de: Concebir, Dise<73>ar, Implementar y Operar sistemas complejos en un entorno basado en equipos para crear sistemas y productos. En Colombia, la mayor<6F>a de los centros de formaci<63>n solo tienen en cuenta la Concepci<63>n y el Dise<73>o, descuidando por completo la Implementaci<63>n y la Operaci<63>n de sistemas, esto, impide que se tenga una estrecha relaci<63>n con la industria, la cual, requiere productos que pueda comercializar o soluciones a sus necesidades.
\subsection{Objetivos de la Iniciativa CDIO}
La Iniciativa CDIO se enfoca en preparar a los estudiantes con los conocimientos habilidades y aptitudes para ser ingenieros l<>der. Y sus principales objetivos son: \cite {WCI}:
\begin{itemize}
\item Educar a los estudiantes para dominar un conocimiento m<>s profundo de los fundamentos t<>cnicos.
\item Educar a los ingenieros para liderar la creaci<63>n y operaci<63>n de nuevos productos y sistemas.
\item Educar futuros investigadores para entender la importancia estrat<61>gica y el valor de su trabajo.
\end{itemize}
El Departamento de Ingenier<65>a El<45>ctrica y Electr<74>nica de la Universidad Nacional de Colombia est<73> realizando el trabajo de adaptar la Iniciativa CDIO a su programa acad<61>mico, esta iniciativa coincidi<64> con el desarrollo de esta investigaci<63>n. Los objetivos de esta iniciativa se adaptan a los requerimientos que se exige a la plataforma tecnol<6F>gica de un pa<70>s para que pueda realizar una adecuada absorci<63>n del conocimiento transferido y posteriormente transformar ese conocimiento en nuevos productos adaptados a las necesidades del pa<70>s.
Las premisas que capturan la visi<73>n, objetivos y fundamentos pedag<61>gicos de la Iniciativa CDIO son:
\begin{itemize}
\item Es posible cumplir las necesidades propias de la profesi<73>n mientras al mismo tiempo se realiza el proceso de Concebir, dise<73>ar, implementar y operar sistemas en el contexto de los sistemas de Ingenier<65>a.
\item Los resultados de la formaci<63>n deben ser fijados por los sectores interesados (Academia, Industria, Gobierno) y deben formar una secuencia de experiencias de aprendizaje, algunas de las cuales son experimentales, es decir, deben enfrentar a los estudiantes a situaciones que encontrar<61>n en el ejercicio de su profesi<73>n.
\item La adecuada construcci<63>n de esta cadena de actividades tendr<64>n un doble impacto en la formaci<63>n de los estudiantes, por un lado facilitar<61> el aprendizaje de habilidades cr<63>ticas e inter-personales y fortalecer<65> las habilidades de construcci<63>n de sistemas, productos y procesos, mientras se mejora el aprendizaje de los conceptos fundamentales.
\end{itemize}
\subsubsection{liderazgo}
La situaci<63>n actual por la que atraviesa la Industria electr<74>nica nacional, requiere que los profesionales en el <20>rea tengan las capacidades de emprendimiento y liderazgo necesarias para la creaci<63>n de nuevas empresas o para la creaci<63>n de nuevos productos, la Figura \ref{cdio_emp_lid} muestra la relaci<63>n entre emprendimiento, liderazgo y las habilidades CDIO.
\begin{figure}[H]
\begin{center} \includegraphics[scale=.6]{./images/CDIO_emp_lid.png} \end{center}
\caption{} fuente:\cite{ECJM+09} \label{cdio_emp_lid}
\end{figure}
Las habilidades principales que deben poseer un lider seg<65>n la \textit{Sloan School of Management at MIT} son \cite{AD}:
\begin{itemize}
\item \textit{Interpretar} Interpretar el contexto de los cambios mundiales incluyendo el uso de peque<75>os experimentos para obtener informaci<63>n.
\item \textit{Relacionarse} Desrrollar relaciones confiables con diferentes tipos de personas, utilizando las preguntas para saber como comunicarse de forma efectiva.
\item \textit{Visi<73>n} Crear una visi<73>n para uno mismo y transmitir esta visi<73>n a los dem<65>s.
\item \textit{Realizaci<63>n de la Visi<73>n}
\end{itemize}
\subsubsection{Emprendimiento}
El concepto cl<63>sico de emprendimiento involucra el re-direccionamiento y movilizaci<63>n de capital y recursos humanos para crear una nueva actividad econ<6F>mica. Actualmente, el emprendimiento esta asociado a la creaci<63>n de une nueva empresa con una nueva l<>nea de negocios. En algunas ocasiones las innovaciones tecnol<6F>gicas no requieren cambios en el mercado. Cuando la ingenier<65>a es el componente principal del producto, se debe enfatizar en el proceso de dise<73>o y los ingenieros deben entender la relaci<63>n entre la primicia y el tiempo de salida al mercado, m<>rgenes de producto, la tasa de rendimiento m<>nima para justificar la inversi<73>n en la compa<70>ia y otras consideraciones de negocios que influyen en el dise<73>o y las estrategias de implementaci<63>n.
\subsection{Estructura del Plan de Estudios CDIO}
La figura \ref{cdio_blocks} muestra los bloques constructores del plan de estudios CDIO, en el primer nivel podemos observar que todo individuo interesado en obtener habilidades t<>cnicas posee \textit{Habilidades Personales y Profesionales}, las cuales son fundamentales para la pr<70>ctica. Con el f<>n de desarrollar sistemas de ingenier<65>a complejos, los estudiantes deben dominar los fundamentos del \textit{Razonamiento y Conocimiento T<>cnico}. Para trabajar en un entorno moderno basado en equipos los estudiantes deben desarrollar \textit{Habilidades Interpersonales} de comunicaci<63>n y trabajo en equipo. Finalmente con el fin de ser capaz de crear y operar productos y sistemas un estudiante debe entender el concepto de \textit{Concebir, Dise<73>ar, Implementar y Operar Sistemas en el Contexto Social y Empresarial}\cite{EFC01}
\begin{figure}[H]
\begin{center} \includegraphics[scale=.8]{./images/CDIO.png} \end{center}
\caption{Bloques Constructores de conocimiento, habilidades y actitudes necesarias para Concebir, Dise<73>ar, Implementar y Operar sistemas en el contexto social y empresarial} fuente:\cite{EFC01} \label{cdio_blocks}
\end{figure}
\subsubsection{Nivel 1: Razonamiento y Conocimiento T<>cnico}
Los componentes del primer nivel \textit{Razonamiento y Conocimiento T<>cnico} son com<6F>nes a los planes de estudio de las ingenier<65>as modernas y son:
\begin{enumerate}
\item Fundamentos Avanzados de Igenier<65>a.
\item Fundamentos del n<>cleo de Ingenier<65>a.
\item Conocimiento cient<6E>fico.
\end{enumerate}
La raz<61>n de colocar este bloque constructor en el primer nivel es solo para recordar que el objetivo primordial de cualquier programa de pregrado es el desarrollo de un profundo conocimiento de fundamentos t<>cnicos. En este trabajo no se cambiar<61> este componente ya que para hacerlo es necesario un consenso con las dem<65>s carreras de la facultad de Ingenier<65>a, labor que puede tomar varios a<>os.
\subsubsection{Habilidades Personales, Profesionales e Interpersonales}
Los niveles 2 y 3 se centran en las habilidades personales que debe poseer un individo para que pueda cumplir con el objetivo de la Iniciativa CDIO. El nivel 2 esta compuesto por:
\begin{enumerate}
\item Las habilidades profesionales que representan las tres formas de pensar m<>s practicadas por los ingenieros: Resoluci<63>n de problemas, Descubrimiento de conocimiento y Pensamiento sist<73>mico.
\item Actitudes que incluyen integridad y comportamiento profesional as<61> como las necesarias para planear la profesi<73>n.
\end{enumerate}
Las habilidades que no hacen parte del contexto profesional ni del inter-personal son llamadas \textit{Habilidades y Actitudes Personales}, incluyen el car<61>cter, iniciativa, perseverancia, formas de pensar m<>s gen<65>ricas como pensamiento cr<63>tico, creativo y habilidades propias como curiosidad, aprendizaje continuo y manejo del tiempo.
Las habilidades inter-personales, son un subconjunto de las habilidades personales y se dividen en dos grupos que se traslapan llamados: Equipo de Trabajo y Comunicaciones. El grupo de trabajo se refiere a las habilidades necesarias para formar, operar, fortalecer y liderar un equipo con habilidades espec<65>ficas de un equipo de trabajo t<>cnico. La comunicaci<63>n se compone de habilidades para idear estrategias de comunicaci<63>n y aquellas para utilizar los medios orales, escritos, electr<74>nicos y gr<67>ficos y en el caso Colombiano el uso del idioma Ingl<67>s. La Figura \ref{cdio_2_3} muestra la relaci<63>n entre las habilidades de nivel 2 (Personales y Profesionales) y nivel 3 (Interpersonales).
\begin{figure}
\begin{center} \includegraphics[scale=.8]{./images/CDIO_2_3.png} \end{center}
\caption{Relaci<63>n entre las Habilidades Personales, Profesionales e Interpersonales} fuente:\cite{EFC01} \label{cdio_2_3}
\end{figure}
\subsubsection{Habiidades CDIO}
Habilidades necesarias parea Concebir, Dise<73>ar, Implementar y Operar Systemas en el Contexto Social y empresarial. Estos cuatro componentes son necesarios para que los egresados de las carreras de Ingnier<65>a El<45>ctrica y Electr<74>nica sean capaces de absorver los conocimientos que las nuevas tecnolog<6F>as proporcionan, adaptarlos a la situaci<63>n tecnol<6F>gica y al contexto social del pa<70>s para generar productos que resuelvan necesidades locales. Para satisfacer una necesidad de la sociedad es necesario conocer la din<69>mica empresarial, los principios que la rigen y como se debe actuar en una empresa de cualquier tipo y tama<6D>o.
\subsection{Implementaci<63>n del Plan de Estudios CDIO}
La Figura \ref{impl_CDIO} muestra los componentes que deben ser especificados para implementar el plan de estudios CDIO al curr<72>culo de las asignaturas del <20>rea de electr<74>nica digital. En primer lugar se encuentran los resultados esperados del proceso de aprendizaje, esto es, Qu<51> deben saber y que deben ser capaces de hacer los estudiantes al final del curso? Para contestar a esta pregunta es necesario definir las \textbf{habilidades} que ser<65>n reforzadas o desarrolladas y los \textit{objetivos} de cada asignatura.
\begin{figure}[ht]
\begin{center} \includegraphics[scale=.8]{./images/habilidades_digitales.png} \end{center}
\caption{Objetivos, Actividades, y Evaluaci<63>n: } \label{impl_CDIO}
\end{figure}
Para alcanzar los objetivos definidos en el primer paso, es necesario generar una serie de \textbf{actividades} que le permitan al estudiante: retener nuevos conocimientos y habilidades y desarrollar las competencias deseadas, el n<>mero de actividades debe ser tal que cubran todas las habilidades que se quieran desarrollar o reforzar.
Finalmente, se deben desarrollar m<>todos de evaluaci<63>n que permitan conocer el nivel de competencia de los estudiantes, y de esta forma ajustar las actividades para obtener los resultados esperados.
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%% IDENTIFICACION DE HABILIDADES CDIO %%%%%%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\section{Definici<63>n e Identificaci<63>n de las Habilidades CDIO}
El primer paso en la implementaci<63>n del plan de estudios CDIO es definir e identificar las habilidades requeridas en una determinada <20>rea del plan de estudios, este estudio se centrar<61> en las asignaturas del <20>rea de electr<74>nica digital. En la Universidad Nacional de Colombia el <20>rea de Electr<74>nica Digital esta compuesta por tres asignaturas para la carrera de Ingenier<65>a Electr<74>nica: Electr<74>nica Digital 1, Electr<74>nica Digital 2 y Sistemas Embebidos. Para la carrera de Ingenier<65>a El<45>ctrica est<73> compuesta por Electr<74>nica Digital 1 (la misma en las dos carreras) <20>nicamente.
\subsection{Introducir, Ense<73>ar y Usar}
Para transladar esta lista de habilidades a objetivos de aprendizaje es necesario determinar el grado de competencia que se espera que el profesional adquiera en cada una de las asignaturas. Por supuesto, algunas de estas habilidades no pueden obtenerse en una asignatura, es necesario que todo el plan acad<61>mico contribuya a generar una determinada habilidad, lo que requiere un consenso del personal acad<61>mico. En el Departamento de Ingenier<65>a El<45>ctrica y Electr<74>nica de la Universidad Nacional de Colombia se est<73> realizando esta tarea y los resultados presentados en este estudio hacen parte de esta iniciativa.
Los niveles de competencia seleccionados para indicar el nivel en que debe ser apropiada una determinada habilidad son:
\begin{enumerate}
\item Introducir: Introduce pero no eval<61>a.
\item Ense<73>ar: Ense<73>a y eval<61>a.
\item Utilizar: Utiliza, puede ser evaluado o no.
\end{enumerate}
\subsection{Habilidades CDIO}
A continuaci<63>n se listan las habilidades CDIO que deben desarrollarse o reforzarse en el <20>rea de Electr<74>nica Digital, algunas de las habilidades como la comunicaci<63>n oral y escrita en Ingl<67>s es com<6F>n a la mayor<6F>a de las asignaturas, mientras que otras como la Integraci<63>n Software - Hardware es exclusiva,
%Redefine the first level
\renewcommand{\theenumi}{\arabic{enumi}}
\renewcommand{\labelenumi}{\theenumi}
%Redefine the second level
\renewcommand{\theenumii}{\arabic{enumii}}
\renewcommand{\labelenumii}{\theenumii}
\begin{enumerate}
\setcounter{enumi}{1}
% CDIO NIVEL 2
\item \textbf{Aptitudes personales y profesionales}
\begin{enumerate}
\item Razonamiento ana;<3B>tico y Resoluci<63>n de problemas
\begin{enumerate}
\item Identificaci<63>n y Formulaci<63>n del problema
\item Modelamiento
\item Soluci<63>n y recomendaci<63>n
\end{enumerate}
\item Experimentaci<63>n Investigaci<63>n y Descubrimiento de Conocimiento
\begin{enumerate}
\item Formulaci<63>n de hip<69>tesis
\item Investigaci<63>n experimental
\end{enumerate}
\item Pensamiento Sistem<65>tico
\begin{enumerate}
\item Pensamiento Global
\item Surgimiento e interacciones
\end{enumerate}
\item Pensamiento Cr<43>tico y Creativo y Habilidades y actitudes personales
\begin{enumerate}
\item Pensamiento creativo
\item Pensamiento cr<63>tico
\item Toma de conciencia de conocimientos propios y metaconocimiento.
\item Aprendizaje permanente y Educar a otros.
\end{enumerate}
\item <20>tica, Responsabilidad Profesional, Equidad y Otros Valores Personales.
\begin{enumerate}
\item <20>tica, integridad y responsabilidad social
\item Comportamiento profesional y responsabilidad
\item Confianza y lealtad
\end{enumerate}
\end{enumerate}
% CDIO NIVEL 3
\item \textbf{Habilidades interpersonales, trabajo en equipo y comunicaci<63>n}
\begin{enumerate}
\item Equipo de Trabajo
\begin{enumerate}
\item Formar grupos efectivos
\item Equipo de liderazgo
\item Equipo T<>cnico y multi-disciplinario.
\end{enumerate}
\item Comunicaciones estructuradas
\begin{enumerate}
\item Estrategia de comunicaci<63>n
\item Estructura de la comunicaci<63>n
\item Comunicaci<63>n Escrita
\item Comunicaci<63>n Electr<74>nica
\item Presentaci<63>n Oral
\end{enumerate}
\item Comunicaci<63>n en Idioma Extranjero
\begin{enumerate}
\item Ingl<67>s
\end{enumerate}
\item Comunicaciones Informales: Relacionarse con los dem<65>s
\begin{enumerate}
\item Preguntar, Escuchar y Dialogar
\item Negociaci<63>n, compromiso y resoluci<63>n de conflictos.
\item Establecimiento de conexiones
\end{enumerate}
\end{enumerate}
% CDIO NIVEL 4
\item \textbf{Concebir, Dise<73>ar, Implementar y Operar Sistemas en el Contexto Social y Empresarial}
\begin{enumerate}
\item Contexto Externo, Social, Econ<6F>mico y Ambiental
\begin{enumerate}
\item Rol y responsabilidad de los Ingenieros
\item Impacto sobre la sociedad y el medio ambiente
\item Cuestiones y valores actuales
\item Sostenibilidad y necesidad de un desarrollo sostenible.
\end{enumerate}
\item Empresa y contexto empresarial
\begin{enumerate}
\item Interesados en la empresa, metas y objetivos
\item Esp<73>ritu Empresarial T<>cnico
\item Trabajo en organizaciones
\item Finanzas y Econom<6F>s de los Proyectos de Ingenier<65>a
\end{enumerate}
\item Concepci<63>n y Administraci<63>n de Sistemas en Ingenier<65>a.
\begin{enumerate}
\item Entender las necesidades y establecer las metas
\item Definir la funci<63>n, concepto y arquitectura
\end{enumerate}
\item Dise<73>o
\begin{enumerate}
\item Proceso de Dise<73>o
\item Fases del proceso de Dise<73>o y enfoques
\item Utilizaci<63>n de conocimiento cient<6E>fico en el dise<73>o
\item Dise<73>o espec<65>fico
\item Dise<73>o multi-disciplinario
\end{enumerate}
\item Implementaci<63>n
\begin{enumerate}
\item Proceso de fabricaci<63>n Hardware
\item Proceso de Implementaci<63>n de Software
\item Integraci<63>n Software - Hardware
\item Pruebas, verificaci<63>n, validaci<63>n y certificaci<63>n
\end{enumerate}
\item Liderar Esfuerzos en ingenier<65>a
\begin{enumerate}
\item Pensar creativamente e Imaginar posibilidades
\item Definir la soluci<63>n
\item Crear nuevas formas de soluci<63>n
\item Construir y liderar una organizaci<63>n y una organizaci<63>n extendida.
\item Planear y administrar un prpyecto hasta su finalizaci<63>n.
\item Innovar - la concepci<63>n, dise<73>o e introducci<63>n de nuevos bienes y servicios.
\item Innovar - el desarrollo de nuevos dispositivos, materiales o procesos que permitan nuevos bienes y servicios.
\end{enumerate}
\item Emprendimiento en ingenier<65>a
\begin{enumerate}
\item Creaci<63>n, Formulaci<63>n y organizaci<63>n de una empresa.
\item Desarrollo del plan de negocios.
\item Finanzas y capitalizaci<63>n.
\item Mercadeo de productos innovadores
\item Cencepci<63>n de productos y servicios alrededor de nuevas tecnolog<6F>as.
\item Sistema de innovaci<63>n, redes, infraestructura y servicios.
\item Construyendo el equipo e iniciando el proceso de ingenier<65>a.
\item Manejo de la propiedad intelectual.
\end{enumerate}
\end{enumerate}
\end{enumerate}
\subsection{Competencias de las Habilidades CDIO 2 y 3}
La tabla \ref{compet_2_3} muestra las competencias IEU para los niveles CDIO 2 y 3 para las asignaturas Electr<74>nica Digital 1, Electr<74>nica Digital 2 y Sistemas Embebidos.
\begin{center}
\begin{table}[ht]
\begin{tabular}{|l|c|c|c|} \hline
\multicolumn{4}{|c|}{\textbf{Competencias de las Habilidades CDIO Nivel 2 y 3}} \\ \hline
\multirow{2}{*}{\textbf{APTITUDES PERSONALES Y PROFESIONALES}} & \multicolumn{3}{c|} {Nivel 1} \\
& E. Digital1 & E. Digital1 & Sist. Emb. \\ \hline
\textbf{\textit{Planteamiento y Resoluci<63>n de problemas de Ingenier<65>a}} & \multicolumn{3}{c|} {EU} \\ \hline
1 Identificaci<63>n y Formulaci<63>n del problema & \multicolumn{3}{c|} {EU} \\ \hline
2 Modelamiento & \multicolumn{3}{c|} {EU} \\ \hline
3 Soluci<63>n y recomendaci<63>n & \multicolumn{3}{c|} {EU} \\ \hline
\textbf{\textit{Experimentaci<63>n y Descubrimiento de Conocimiento}} & \multicolumn{3}{c|} {U} \\ \hline
4 Formulaci<63>n de hip<69>tesis & \multicolumn{3}{c|} {U} \\ \hline
5 Investigaci<63>n experimental & \multicolumn{3}{c|} {U} \\ \hline
\textbf{\textit{Pensamiento Sistem<65>tico}} & \multicolumn{3}{c|} {EU} \\ \hline
6 Pensamiento Global & \multicolumn{3}{c|} {U} \\ \hline
7 Surgimiento e interacciones & \multicolumn{3}{c|} {U} \\ \hline
\textbf{\textit{Habilidades y actitudes personales}} & \multicolumn{3}{c|} {U} \\ \hline
8 Pensamiento creativo & \multicolumn{3}{c|} {IEU} \\ \hline
9 Pensamiento cr<63>tico & \multicolumn{3}{c|} {IEU} \\ \hline
10 Toma de conciencia de conocimientos propios & \multicolumn{3}{c|} {IEU} \\ \hline
11 Curiosidad y aprendizaje permanente
\textbf{\textit{Habilidades y actitudes profesionales}} & \multicolumn{3}{c|} {U} \\ \hline% \begin{enumerate}
12 <20>tica profesional, integridad, responsabilidad & \multicolumn{3}{c|} {U} \\ \hline
13 Comportamiento profesional & \multicolumn{3}{c|} {U} \\ \hline
39 Confianza y Lealtad & \multicolumn{3}{c|} {IEU} \\ \hline
\multirow{2}{*}{\textbf{HABILIDADES INTERPERSONALES}} & \multicolumn{3}{c|} {Nivel 1} \\
& E. Digital1 & E. Digital1 & Sist. Emb. \\ \hline
\textbf{\textit{Equipo de Trabajo}} & \multicolumn{3}{c|} {EU} \\ \hline
14 Formar grupos efectivos & EU & U & U \\ \hline
15 Equipo de Liderazgo & EU & U & U \\ \hline
40 Equipo T<>cnico y Multi-disciplinario & EU & U & U \\ \hline
\textbf{\textit{Comunicaciones estructuradas}} & \multicolumn{3}{c|} {EU} \\ \hline
16 Estrategia de comunicaci<63>n & EU & U & U \\ \hline
17 Estructura de la comunicaci<63>n & EU & U & U \\ \hline
18 Comunicaci<63>n Escrita & EU & U & U \\ \hline
19 Comunicaci<63>n Electr<74>nica & EU & U & U \\ \hline
20 Presentaci<63>n Oral & EU & U & U \\ \hline
\textbf{\textit{Comunicaci<63>n en Idioma Extranjero}} & \multicolumn{3}{c|} {U} \\ \hline
21 Ingl<67>s & \multicolumn{3}{c|} {U} \\ \hline
\textbf{\textit{Comunicaciones Informales: Relacionarse con los dem<65>s}} & \multicolumn{3}{c|} {U} \\ \hline
41 Preguntar, Escuchar y Dialogar & EU & U & U \\ \hline
42 Negociaci<63>n, compromiso y resoluci<63>n de conflictos & EU & U & U \\ \hline
43 Establecimiento de conexiones & IEU& U & U \\ \hline
\end{tabular}
\caption{Competencias para los niveles 2 y 3 CDIO} \label{compet_2_3}
\end{table}
\end{center}
\subsection{Competencias de las Habilidades C.D.I.O. Sistemas en el contexto Empresarial, Social y Ambiental - Innovaci<63>n}
\begin{center}
\begin{table}[ht]
\begin{tabular}{|l|c|c|c|} \hline
\multirow{2}{*}{\textbf{HABILIDADES CDIO}} & \multicolumn{3}{c|} {Nivel 1} \\
& E. Digital1 & E. Digital1 & Sist. Emb. \\ \hline
\textbf{\textit{Contexto Externo, Social, Econ<6F>mico y Ambiental}} & \multicolumn{3}{c|} {IEU} \\ \hline
22 Rol y responsabilidad de los Ingenieros & \multicolumn{3}{c|} {IEU} \\ \hline
23 Impacto sobre la sociedad y el medio ambiente & \multicolumn{3}{c|} {IEU} \\ \hline
24 Cuestiones y valores actuales & \multicolumn{3}{c|} {IEU} \\ \hline
44 Sostenibilidad y necesidad de un desarrollo sostenible& IE & IE & IE \\ \hline
\textbf{\textit{Empresa y contexto empresarial}} & \multicolumn{3}{c|} {EU} \\ \hline
25 Interesados en la empresa, metas y objetivos & \multicolumn{3}{c|} {I} \\ \hline
26 Esp<73>ritu Empresarial T<>cnico & \multicolumn{3}{c|} {I} \\ \hline
27 Trabajo exitoso en organizaciones & \multicolumn{3}{c|} {I} \\ \hline
45 Finanzas y Econom<6F>a de los Proyectos de Ingenier<65>a & IE & IE & IE \\ \hline
\textbf{\textit{Concepci<63>n y Administraci<63>n de Sistemas en Ingenier<65>a.}} & \multicolumn{3}{c|} {IEU} \\ \hline
28 Entender las necesidades y establecer las metas & IEU & EU & U \\ \hline
29 Definir la funci<63>n, concepto y arquitectura & IEU & EU & U \\ \hline
\textbf{\textit{Dise<73>o}} & \multicolumn{3}{c|} {IEU} \\ \hline
30 Proceso de Dise<73>o & IEU & EU & U \\ \hline
31 Fases del proceso de Dise<73>o y enfoques & IEU & EU & U \\ \hline
32 Utilizaci<63>n de conocimiento cient<6E>fico en el dise<73>o & IEU & EU & U \\ \hline
33 Dise<73>o espec<65>fico & IEU & EU & U \\ \hline
34 Dise<73>o multi-disciplinario & I & E & U \\ \hline
\textbf{\textit{Implementaci<63>n}} & \multicolumn{3}{c|} {EU} \\ \hline
35 Proceso de fabricaci<63>n Hardware & IE & EU & U \\ \hline
36 Proceso de Implementaci<63>n de Software & I & EU & U \\ \hline
37 Integraci<63>n Software - Hardware & I & EU & U \\ \hline
38 Pruebas, verificaci<63>n, validaci<63>n y certificaci<63>n & IE & EU & U \\ \hline
\end{tabular}
\caption{Competencias para el niveles 4 CDIO} \label{compet_2_3}
\end{table}
\end{center}
\section{Integraci<63>n de las Habilidades CDIO al Plan de Estudios}
\subsection{Objetivo General}
Generar en el estudiante las habilidades necesarias para Concebir, Dise<73>ar, Implementar y Operar Sistemas Digitales complejos que satisfagan necesidades de la sociedad y proporcionar un canal para la transferencia de Tecnolog<6F>a y conocimiento a la Industria Colombiana. La Figura \ref{design_method} muestra la metodolog<6F>a de dise<73>o para las diferentes asignaturas del <20>rea.
\begin{figure}[ht]
\begin{center} \includegraphics[scale=.8]{./images/habilidades_digitales.png} \end{center}
\caption{Metodolog<6F>a de Dise<73>o para el <20>rea de Sistemas Digitales} \label{design_method}
\end{figure}
\subsubsection{Electr<74>nica Digital 1}
Concebir y definir las especificaciones y requerimientos de un Sistema Digital, modelar su funcionamiento, y realizar la implementaci<63>n siguiendo la metodolog<6F>a de dise<73>o de Sistemas Embebidos utilizando <20>nicamente tareas Hardware.
\subsubsection{Electr<74>nica Digital 2}
Concebir, definir las especificaciones, modelar, dise<73>ar un Sistema Digital siguiendo la metodolog<6F>a de dise<73>o de Sistemas Embebidos y realizar su implementaci<63>n <20>ptima utilizando tareas Hardware (que se ejecutan en un PLD) y tareas Software (que se ejecutan en un procesador).
\subsubsection{Sistemas Embebidos}
Concebir, dise<73>ar, e Implementar un sistema digital complejo utilizando la metodolog<6F>a de dise<73>o de sistemas Embebidos y un Sistema Operativo para su Implementaci<63>n.
\subsection{Objetivos Espec<65>ficos}
\subsection {Ojbetivos com<6F>nes}
\begin{itemize}
\item Identificar las especificaciones funcionales del sistema, su arquitectura de alto nivel y definir su descomposici<63>n en elementos
\item Explicar las actividades en las etapas del proceso de dise<73>o,
\item Desarrollar el pensamiento sist<73>mico.
\item Modelar funcionalmente Sistemas Digitales.
\item Dise<73>ar pruebas para comprobar el correcto funcionamiento de los sistemas implementados.
\item Leer y entender material t<>cnico escrito en ingl<67>s.
\item Implementar un Sistemas Embebido (Hardware o Hardware/Software) para cumplir una tarea determinada que cumpla con una necesidad real (Obtener e interpretar las necesidades del consumidor) utilizando t<>cnicas, herramientas y procesos adecuados.
\item Estudiar y aplicar el concepto de la re-utilizaci<63>n de c<>digo.
\item Desarrollar trabajo en equipo incluyendo presentaciones, describiendo los diversos roles y responsabilidades.
\item Documentar los dise<73>os realizados para crear una base de datos que contribuya a la difusi<73>n del conocimiento adquirido.
\end{itemize}
\subsubsection{Electr<74>nica Digital 1}
\begin{itemize}
\item Estudiar las fases de la metodolog<6F>a de dise<73>o para Sistemas Embebidos.
\item Estudiar los dominios de dise<73>o Estructural, Funcional y F<>sico.
\item Estudiar los Lenguajes de Descripci<63>n de Hardware.
\item Estudiar los componentes b<>sicos de la l<>gica combinatoria y secuencial.
\end{itemize}
\subsubsection{Electr<74>nica Digital 2}
\begin{itemize}
\item Estudiar los requisitos para un particionamiento Hardware / Software <20>ptimo.
\item Estudiar la arquitectura de un procesador, micro-arquitectura, set de instrucciones, interrupciones, direccionamiento.
\item Estudiar el proceso de implementaci<63>n de tareas software.
\item Estudiar la integraci<63>n Software-Hardware.
\item Dise<73>ar pruebas para comprobar el correcto funcionamiento de los sistemas implementados.
\end{itemize}
\subsubsection{Sistemas Embebidos}
\begin{itemize}
\item Realizar aplicaciones que requieran dise<73>o multi-disciplinario.
\item Estudiar y realizar el proceso de Fabricaci<63>n Hardware.
\item Estudiar el principio b<>sico de los sistemas operativos.
\item Describir la integraci<63>n de software en hardware electr<74>nico
\item Entender diagramas de circuitos electr<74>nicos de sistemas digitales, identifcar sus componentes y su funci<63>n.
\item Estudiar dise<73>os software y hardware existentes para entender su funcionamiento, arquitectura y adquirir experiencia en el dise<73>o.
\item Hacer parte de listas de discusi<73>n de temas t<>cnicos que usen el ingl<67>s como lenguaje.
\end{itemize}
\subsection{Contenido}
\subsubsection{Electr<74>nica Digital 1}
\begin{itemize}
\item \textbf{Flujo de Dise<73>o de Sistemas Embebidos}
\begin{itemize}
\item Sistemas Digitales: Panorama Y Perspectiva
\item Metodolog<6F>a de Dise<73>o
\item Representaciones de Dise<73>o y Niveles de Abstracci<63>n
\end{itemize}
\item \textbf{Sistemas Num<75>ricos y Operaciones Aritm<74>ticas}
\begin{itemize}
\item Representaci<63>n de Datos
\item Sistemas num<75>ricos: Binario, Octal Hexadecimal
\item Representaci<63>n de n<>meros negativos
\item Algoritmos para la implementaci<63>n de operaciones aritm<74>ticas
\begin{itemize}
\item Camino de Datos
\item Control
\end{itemize}
\end{itemize}
\item \textbf{L<>gica Combinatoria}
\begin{itemize}
\item Definici<63>n.
\item Ecuaciones Booleanas, Formas can<61>nicas.
\item M<>dulos B<>sicos: Multiplexores, codificadores, sumadores, restadores comparadores.
\end{itemize}
\item \textbf{L<>gica Secuencial}
\begin{itemize}
\item Definici<63>n
\item Elementos de memoria:
\begin{itemize}
\item Latch
\item Flip-Flop
\end{itemize}
\item Bloques b<>sicos
\begin{itemize}
\item Registros
\item Acumuladores
\item Contadores
\end{itemize}
\item M<>quina de Estados Finitos (FSM)
\begin{itemize}
\item Arquitectura
\item Tipos: Mealy, Moore
\item Diagramas de Estado
\item S<>ntesis de M<>quinas de Estado
\end{itemize}
\item M<>quinas de Estado Algor<6F>tmicas (ASM)
\begin{itemize}
\item Tareas Hardware
\item Componentes: Camino de Datos y M<>quina de Control
\item Implementaci<63>n de operaciones aritm<74>ticas utilizando ASM
\item Identificaci<63>n, funcionamiento e interfaz de bloques constructores.
\item Interacci<63>n entre el Camino de Datos y la M<>quina de Control
\item Lenguajes de Descripci<63>n de Hardware
\end{itemize}
\end{itemize}
\item \textbf{Tecnolog<6F>as de Implementaci<63>n}
\begin{itemize}
\item Familia L<>gica CMOS
\begin{itemize}
\item Principio de funcionamiento, consumo de potencia
\item Niveles L<>gicos y m<>rgenes de ruido
\item Retardos, Manejo de Corriente
\item Compuertas tri-estado y Open-Drain
\end{itemize}
\item Dispositivos L<>gicos Programables
\begin{itemize}
\item Arreglos L<>gicos Programables (PALs)
\item Dispositivos L<>gicos Programables (PLDs, CPLDs)
\item Arreglo de Compuertas Programable en Campo (FPGA)
\item Flujo de Dise<73>o - Programaci<63>n en Sistema
\end{itemize}
\end{itemize}
\item \textbf{Introducci<63>n a los procesadores}
\begin{itemize}
\item M<>quina de Estados Algor<6F>tmica Programable
\end{itemize}
\end{itemize}
\subsubsection{Electr<74>nica Digital 2}
\begin{itemize}
\item \textbf{Codise<73>o Hardware-Software}
\begin{itemize}
\item Flujo de Dise<73>o y Particionamiento HW/SW.
\item Comunicaci<63>n SW -> HW (Direccionamiento)
\item Comunicaci<63>n HW -> SW (Interrupciones)
\item Componentes de un Sistema etherog<6F>neo.
\begin{itemize}
\item Procesador
\item Buses
\item Perif<69>ricos
\item Memorias
\end{itemize}
\end{itemize}
\item \textbf{Arquitectura de Procesadores}
\begin{itemize}
\item Micro-Arquitectura
\item Set de Instrucciones
\item Modos de direccionamiento
\item Interrupciones
\item Pipeline
\end{itemize}
\item \textbf{Implementacion de Tareas Hardware}
\begin{itemize}
\item Arquitectura de computadores
\begin{itemize}
\item CPU
\item Memorias
\item Perif<69>ricos
\item Mapa de Memoria
\item Controlador de Interrupciones Programable
\end{itemize}
\item Definici<63>n de la Interfaz HS <-> SW
\item Implementaci<63>n de Tareas Hardware en Perif<69>ricos.
\end{itemize}
\item \textbf{Flujo de Dise<73>o Software}
\begin{itemize}
\item Cadena de Herramientas:
\begin{itemize}
\item Compilador
\item Librer<65>as standard
\item Depurador
\item Utilidades binarias
\item C<>digo de Inicio C RunTime crt0
\item Herramienta \textit{make}
\end{itemize}
\item Integraci<63>n del Software sobre hardware Electr<74>nico.
\begin{itemize}
\item Ejecuci<63>n en Memoria Interna
\item Ejecuci<63>n en Memoria Externa: Bootloaders
\end{itemize}
\item Implementaci<63>n de tareas software y comunicaci<63>n con tareas Hardware.
\end{itemize}
\item \textbf{Sistemas Sobre Silicio}
\begin{itemize}
\item Arquitectura
\end{itemize}
\end{itemize}
\subsubsection{Sistemas Embebidos}
\begin{itemize}
\item \textbf{Sistemas Embebidos}
\begin{itemize}
\item Definici<63>n,aplicaciones
\item Metodolog<6F>a de Dise<73>o
\item Arquitectura
\begin{itemize}
\item Sistema Sobre Silicio
\item Circuitos de Referencia
\end{itemize}
\end{itemize}
\item Iniclializaci<63>n
\begin{itemize}
\item M<>todos de arranque
\item Bootloaders
\end{itemize}
\item \textbf{Sistema Operativo Linux}
\begin{itemize}
\item Arquitectura
\item Sincronizaci<63>n entre procesos
\item Estructura del Kernel y Organizaci<63>n del c<>digo fuente
\item Drivers de Dispositivos y m<>dulos del kernel
\item Im<49>gen del kernel
\item Inicializaci<63>n del Kernel
\end{itemize}
\item \textbf{Sistema de Archivos del root}
\begin{itemize}
\item Tipos de Sistema de Archivos
\item Estructura del Sistema de Archivos del root
\item Archivos de configuraci<63>n y niveles de ejecuci<63>n.
\item Montaje del sistema de archvios del root
\end{itemize}
\item \textbf{Interfaz con dispositivos externos al SoC}
\begin{itemize}
\item Control utilizando se<73>ales de Entrada/Salida de prop<6F>sito general (GPIOs)
\item Utilizando puertos de comunicaciones UART, I2C, SPI, USB.
\item Utilizando el controlador de memorias externas del SoC
\end{itemize}
\item \textbf{Interfaz con Perif<69>ricos Dedicados Implementados en PLDs}
\begin{itemize}
\item Configuraci<63>n del PLD utilizando GPIOs del SoC
\item Definici<63>n de la Interfaz HW y SW
\item Comunicaci<63>n con perif<69>ricos dedicados
\end{itemize}
\end{itemize}
\subsection{Metodolog<6F>a}
Todas las actividades que se realizar<61>n en estos cursos est<73>n encamindas a generar habilidades necesarias para Concebir, Dise<73>ar, e Implementar Sistemas Digitales Complejos, y est<73>n articuladas alrededor de una <20>nica metodolog<6F>a de dise<73>o (la aceptada internacionalmente para el dise<73>o de sistemas embebidos). Los tres cursos se diferencian en el medio donde se realiza la implementaci<63>n de las tareas y el tipo de las mismas, en el primer curso todas las tareas son Hardware y se implementar<61>n en un PLD, en el segundo las tareas son de tipo hardware y software y ser<65>n implementadas en un PLD. El tercer curso tambi<62>n implementa tareas hardware y software pero utiliza componentes utilizados en dispositivos comerciales, esto es, SoCs para implementar las tareas Software y PLDs para las tareas hardware. El conocimiento adquirido en cada asignatura ser<65> la base del siguiente curso.
Los tres cursos tienen un car<61>cter te<74>rico-pr<70>ctico, el componente te<74>rico tratar<61> los diferentes temas de forma general, con el f<>n de no crear dependencia con las herramientas utilizadas (lo que permitir<69> realizar actualizaci<63>nes de forma f<>cil). En el componente pr<70>ctico se tratar<61>n temas espec<65>ficos de manejo de las herramientas (Lenguajes de Descripci<63>n de Hardware, lenguajes de programaci<63>n, manejo de plataformas de desarrollo) y como estas se relacionan con la metodolog<6F>a de dise<73>o utilizada.
El estudiante debe estudiar, profundizar y comprobar algunos temas tratados en clase y debe leer previamente la documentaci<63>n que se encuentra disponible en el sitio web de los cursos. Adicionalmente, debe formar grupos de trabajo para realizar actividades a lo largo del semestre.
Durante el semestre se trabajar<61> para definir las especificaciones, dise<73>ar e implementar un dispositivo que resuelva una determinada necesidad (con la complejidad adecuada para cada curso), en la sesi<73>n te<74>rica se tratar<61>n aspectos relacionados con la concepci<63>n, dise<73>o, Identificaci<63>n y definici<63>n de las funciones de los componentes del sistma, mientras que en los relacionados con la implementaci<63>n de dichos componentes sobre PLDs o SoC. Se deben realizar presentaciones del avance, indicando las razones que se tuvieron en cuenta en cada decisi<73>n y somo se resolvieron los problemas encontrados, todo este proceso debe documentarse en el sitio web del curso.
El laboratorio est<73> relacionado con la pr<70>ctica y proporciona el conocimiento y habilidades para manejar y entender las herramientas Hardware y Software utilizadas en la implementaci<63>n. Las actividades programadas, deben ser entregadas con un informe donde se evidencie el uso de la metodolog<6F>a de dise<73>o utilizada, adicionalmente el estudiante debe defender y explicar su dise<73>o.
Se utilizar<61>n los siguientes m<>todos de calificaci<63>n:
\begin{itemize}
\item Pruebas escritas donde se verificar<61> la asimiliaci<63>n de conocimiento.
\item Sustentaci<63>n oral de procesos de dise<73>o e Implementaci<63>n.
\item Evaluaci<63>n del avance del proceso de Concepci<63>n, Dise<73>o e Implementaci<63>n del Proyecto Final.
\end{itemize}
\subsection{Actividades}
\subsubsection{Lectura de material del curso 10, 11}
Con la lectura previa de los temas, el estudiante adquiere la capacidad de absorver conocimiento (11), identificar sus preferenicas, deficiencias y buscar ayuda para suplirlas (10), lo cual ayuda al mejoramiento de las habilidades para el auto-aprendizaje, uno de los problemas detectados en los estudiantes es la necesidad de una autoridad que le proporcione la informaci<63>n que necesita para resolver un problema o tomar una decisi<73>n.
\subsubsection{Lectura de material T<>cnico en Ingl<67>s 10, 11, 6, 30, 33, 21}
La mayor parte de la documentaci<63>n de los componentes electr<74>nicos esta escrita en ingl<67>s t<>cnico, es necesario que el estudiante aprenda a entender este tipo de escritura y se familiarice con su estructura. Esto le permite identificar el funcionamiento de un componente del sistema (6,30), determinar que componente se adapta mejor a sus necesidades (33) y mejorar sus habilidades para comunicarse en ingl<67>s 21.
\subsubsection{Utilizaci<63>n de Metodolog<6F>as de Dise<73>o 1, 2, 3, 6, 7, 9, 28, 29, 30, 31, 32, 33, 34, 35, 36, 37, 38}
La metodolog<6F>a de dise<73>o(30,31,) de sistemas embebidos requiere identificar un problema(1, 28), plantear una soluci<63>n(3,29,32) l<>gica (9) de alto nivel (9), modelarla (2) a nivel de sistema(6), verificar el cumplimiento de los requerimientos(33,38). Proporciona m<>todos para determinar su arquitectura <20>ptima (particionamiento HW/SW) y definir la funci<63>n e interacci<63>n(37,7) de sus componentes software (36) y hardware (35).
\subsubsection{Implementaci<63>n de Sistemas Digitales Sencillos 3, 14, 29, 30, 35, 36, 17, 18, 19}
La realizaci<63>n de pr<70>cticas de laboratorio en las que grupos de trabajo (14) implementan dise<73>os de baja o media complejidad le permite al estudiante: Formular recomendaciones (3) para que no se repitan errores en experiencias futuras. Utilizar sistemas de desarrollo (30) para la implementaci<63>n de tareas HW y SW a bajo nivel (36). Con el fin de mejorar la capacidad de comunicaci<63>n escrita (18, 19) se deben presentar informes que refuercen las habilidades generadas en la utilizaci<63>n de la metodolog<6F>a de dise<73>o, por lo que se deben tener la siguiente estructura(17):
\begin{itemize}
\item Un diagrama de caja negra que indique las entradas y salidas del sistema.
\item Una descripci<63>n de alto nivel del algoritmo que implementa la soluci<63>n (29).
\item Un diagrama de bloques que indique el particionamiento y la interconexi<78>n entre sus componentes (30).
\item Descripciones de alto nivel de cada uno de los componentes (31).
\item La implementaci<63>n y simulaci<63>n de cada componente y del sistema completo (35), donde se muestre que el sistema cumple con las especificaciones funcionales(38)
\end{itemize}
\subsubsection{Proyecto Final 1,2,3, 14, 15, 30, 31, 32, 33, 34, 35, 22, 23, 24, 25, 27}
Durante el semestre se trabajar<61> para definir las especificaciones(1,2,3), dise<73>ar(30,31,32,33,34) e implementar un dispositivo que resuelva una hipot<6F>tica necesidad de la sociedad (22) (con la complejidad adecuada para cada curso), en la sesi<73>n te<74>rica se tratar<61>n aspectos relacionados con la concepci<63>n, dise<73>o, Identificaci<63>n y definici<63>n de las funciones de los componentes del sistema, mientras que en el componente pr<70>ctico, los relacionados con la implementaci<63>n de dichos componentes sobre PLDs o SoC.
A los estudiantes se les hace una descripci<63>n funcional de alto nivel del sistema, ellos deben organizarse en grupos de trabajo (14,15), definir la funci<63>n de cada uno de estos grupos (27,14,31), establecer estrategias de comunicaci<63>n (16,31), realizar y/o cumplir un cronograma de actividades (25,31) que permitan resolver la necesidad en el tiempo especificado (22). Una de las estrategias de comunicaci<63>n es la realizaci<63>n de presentaciones orales (20), en las que cada equipo de trabajo expondr<64> el estado de su sub-proyecto, indicando las razones que se tuvieron en cuenta en cada decisi<73>n y como se resolvieron los problemas encontrados (24). Adicionalmente todo este proceso debe documentarse en el sitio web del curso (wiki) con el objetivo de crear una base de proyectos que permitan a futuros estudiantes utilizar la experiencia obtenida (23) y en un determinado caso dar continuidad al proyecto.
El estudiante debe dise<73>ar y construir placas de circuito impreso con los circuitos necesarios para su aplicaci<63>n (35) siguiendo las normas de dise<73>o establecidas por el fabricante (resoluci<63>n, n<>mero de capas, costo) y las restricciones del circuito (Capacidad de corriente, niveles de ruido, compatibilidad electromagn<67>tica, etc).
Vale la pena aclarar que durante el primer curso los estudiantes no poseen la experiencia necesaria para realizar (sin asistencia) labores como la divisi<73>n de tareas, generaci<63>n de un cronograma de actividades y fijar la estrategia de comunicaci<63>n, raz<61>n por la cual el docente debe acompa<70>ar este proceso.
\subsubsection{Participaci<63>n en listas de discuci<63>n 21}
Con el objeto de aumentar las capacidades en la comunicaci<63>n en idioma extranjero, se alentar<61> a los estudiantes a que hagan parte de listas de discusi<73>n en diferentes temas t<>cnicos, algunos problemas que encontrar<61>n en la realizaci<63>n de las diferentes pr<70>cticas deben ser consultados en estas listas para encontrar una forma de soluci<63>n
\subsection{Plataforma de Desarrollo SAKC}
La plataforma SAKC fu<66> dise<73>ada para ser utilizada como herramienta de implementaci<63>n para los tres cursos de esta <20>rea. Est<73> compuesta (ver Figura \ref{sakc_block}) por una FPGA y un Procesador, lo que permite la implementaci<63>n de tareas Hardware y Software utilizando <20>nicamente la FPGA o el procesador y la FPGA.
\begin{figure}[h]
\begin{center} \includegraphics[scale=.8]{./images/SAKC_block_diagram.png} \end{center}
\caption{Diagrama de Bloques de la Plataforma de Desarrollo SAKC}\label{sakc_block}
\end{figure}
Durante el primer curso, el procesador de la plataforma se utilizar<61> para configurar a la FPGA con las tareas hardware sitetizadas por los estudiantes. esta plataforma carece (intencionalmente) de elementos comunmente utilizados en las plataformas de desarrollo para PLDs como Pulsadores, Leds, Displays o conectores espaciales, lo que obliga a los estudiantes a investigar la forma de conexi<78>n de estos y a construir circuitos que permitan la conexi<78>n de la plataforma con estos elementos de interfaz con el usuario o con otros sistemas.
\begin{figure}[h]
\centering
\mbox{\subfigure[Big]{\epsfig{figure=matlab.eps,width=3in}}\quad
\subfigure[Small]{\epsfig{figure=matlab.eps,width=2in}}}
\caption{Fuel Metabolism}
\label{fig:SubF}
\end{figure}
\begin{figure}[h]
\begin{center}
\mbox{
}
\includegraphics[scale=.6]{./images/SAKC.png} \includegraphics[scale=.6]{./images/SAKC_LCD.png}
\end{center}
\caption{Plataforma de Desarrollo SAKC} \label{sakc}
\end{figure}
La capacidad de la FPGA de SAKC permite la implementaci<63>n de procesadores soft-core (como plasma y microblaze), posibilitando la implementaci<63>n de tareas Hadware y software en ella. El procesador ser<65> utilizado al finalizar el curso para comparar el desempe<70>o (velocidad, consumo de potencia, costo) entre un procesador soft-core y un procesador comercial.
El ultimo curso utilizar<61> el procesador para la ejecuci<63>n de tareas software y la FPGA para ejecutar las tareas Software, se har<61> uso de herramientas utilizadas actualmente en el dise<73>o de Aplicaciones comerciales de multinacionales como Nokia (QT), Motorola (Linux).
\subsubsection{Hardware y Software Copy-Left}
El conocimiento debe ser considerado un bien com<6F>n y se debe garantizar el acceso a todo el mundo. Por esta raz<61>n SAKC proporciona la documentaci<63>n necesaria para:
\begin{itemize}
\item Estudiar. entender, y reproducir o modificar su Arquitectura.
\item Conocer su proceso de fabricaci<63>n.
\item Entender su funcionamiento global y la interacci<63>n de sus componentes.
\item Estudiar tutoriales que explican su programaci<63>n.
\item Descargar, estudiar y modificar el c<>digo fuente de todas las aplicaciones existentes actualmente.
\item Realizar consultas con los creadores de las aplicaciones y de las plataforma de desarrollo.
\item Contribuir a mejorar la calidad de la documentaci<63>n y crear nueva informaci<63>n.
\end{itemize}
SAKC esta distribuido bajo la licencia Creative Commons \textit{(CC) BY - SA}, la que permite la distribuci<63>n y modificaci<63>n del dise<73>o (incluso para aplicaciones comerciales), con el <20>nico requisito de que los productos derivadas deben tener la misma licencia.
\section{Desarrollo de M<>todos de Evaluaci<63>n}
% 6. Evaluation is the making of judgments about the value, for some purpose, of ideas, works, solutions,
% methods, material, etc. It involves the use of criteria and standards for appraising the extent to which
% particulars are accurate, effective, or satisfying. It may be quantitative or qualitative.
% Verb examples that represent intellectual activity on this level include: assess, defend, evaluate.
% Examples from the Syllabus:
% Assess one?s skills, interests, strengths and weaknesses
% Evaluate supporting evidence
% A way in which to view the structure of the Bloom verbs is shown in Table B1, which gives the six
% levels, and identifies three to five key verbs within each level. Some common synonyms for those key
% verbs are also listed. Verbs in Italics of Table B1 are commonly used Bloom verbs, and those in regular
% font were added to better fit with technically oriented topics of the Syllabus. The verbs in the column
% to the far right of Table B1 are commonly used Bloom verbs that we recommend not be used with the
% Syllabus. This is because the verbs either appear at two levels, and therefore are ambiguous, or
% because they have a technical connotation apart from their common meaning, which causes them to be
% misplaced in terms of level. Entries in bold will be used in the Bloom verb patterns discussed below.
% B-3
% B.2 The Affective Domain
% The affective domain relates to the emotional component of learning. It emphasizes a feeling, tone, an
% emotion, or a degree of acceptance or rejection. Affect encompasses a range from simple attention to
% organization and characterization of complex, but internally consistent, qualities of character and
% conscience. Krathwohl, Bloom and Masia (1964) developed five levels in the affective domain.
% 1. Receiving (attending): Receiving speaks to an awareness that a learner is conscious of something,
% that he/she take into account a situation, phenomenon or state of affairs. It also addresses the
% learner's willingness to receive information. In other words the climate must be set so that students
% attention is grabbed and directed in a particular manner.
% Verb examples which represent intellectual activity on this level include: a s k , accept, hold.
% Examples from the Syllabus:
% Accepts the need for a commitment to service
% Accepts the goals and roles of the engineering profession
% 2. Responding: At the responding level, students are sufficiently motivated that they are not just
% willing to attend, but are actively attending. It involves a continuum from acquiescence in responding,
% to willingness to respond, to satisfaction in response. In other words, it is active participation by the
% students in their own learning.
% Verb examples that represent intellectual activity on this level include: answer, assist, discuss.
% Examples from the Syllabus:
% Discuss the motivation for continued self-education
% Discuss the importance of both a depth and breadth of knowledge
% 3. Valuing: Simply put, something has value or worth. At this level, behavior is sufficiently
% consistent and stable as to be characterized as a belief or attitude. The student is perceived as holding
% a value. This level ranges from acceptance of a value, to preference, to commitment to a value.
% Verb examples that represent intellectual activity on this level include: demonstrate a belief in,
% embrace, follow, join, share, value.
% Examples from the Syllabus:
% Embrace one?s responsibility for self improvement
% Value a willingness to work independently
% 4. Organization refers to the process learners go through after they internalize values and are faced
% with situations for which more than one value is relevant. This necessitates the organization of values
% into a system, determining the relationship among them, and establishing dominant and pervasive
% values. The emphasis is on comparing, relating, and synthesizing values.
% Verb examples that represent intellectual activity on this level include: alter, combine, complete,
% integrate, order, organize, relate, synthesize .
% B-4
% Example from the Syllabus:
% Integrate the potential benefits and risks of an action
% 5. Characterization by a value or value complex: At this level the individual acts consistently in
% accordance with the values he/she has internalized. A behavior is pervasive, consistent, predictable,
% and characteristic of the student. Student beliefs, ideas, and attitudes are integrated into a total
% philosophy or view of the world.
% Verb examples that represent intellectual activity on this level include: discriminate, display,
% influence, presuppose, qualify, resolve, solve, verify.
% Example from the Syllabus:
% Resolves conflicting issues in the balance between personal and professional life
% B.3 The Psychomotor Domain
% The psychomotor domain emphasizes physical skills. It involves muscular or motor skill, some
% manipulation of materials and objects, or some act which requires a neuromuscular coordination. It
% captures the complexity of grace, strength, and speed that is often involved in physical activity or
% skill acquisition.
% While there are a few examples in the CDIO Syllabus that touch on the psychomotor domain, these
% topics all have an important cognitive component as well. Therefore the cognitive verbs are
% consistently used for these topics, and the psychomotor categories are not used in the Syllabus.
% For completeness, it is worth outlining the breakdown of this domain by Simpson (1972) into seven
% levels.
% 1. Perception is defined as the ability to use sensory cues to guide motor activity.
% 2. Set refers to the readiness to take a particular course of action. This includes physical and
% emotional set as well as mental.
% 3. Guided Response: refers to imitation and trial and error in which the adequacy of the performance
% is judged by the instructor or by a defined set of criteria.
% 4. Mechanism: describe learned responses that have become habitual, movements can be performed
% with some confidence and proficiency.
% 5. Complex Overt Responses: is the skillful performance of motor acts that involve complex movement
% patterns. Proficiency is indicated by a quick, accurate, and highly coordinated performance, requiring
% a minimum of energy. In this category, responses are automatic.
% 6. Adaptation: is the level at which skills are so well developed that the individual can modify
% movement patterns to fit special requirements or to meet a problem situation.
% 7. Origination is the creation of new movement patterns to fit a particular situation or specific
% problem. Outcomes at this level emphasize creativity based upon highly developed skills.

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.

View File

@@ -0,0 +1,645 @@
\chapter{Sistemas Embebidos}
\section{Introducci<63>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<63>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<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}
\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}
\subsection{Metodolog<6F>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.
\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}
\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<65>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}
\subsubsection{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<63>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<63>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<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 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.
\subsection{Herramientas hardware}
Como se mencion<6F> anteriormente existen varias alternativas al momento de implementar un Sistema Embebido (ver Figura \ref{es_arch}). En este trabajo se utiliza una arquitectura compuesta por el SoC de Atmel el AT91RM9200 y una FPGA, teniendo en cuenta que esta pataforma tiene fines acad<61>micos es muy importante tener la posibilidad de crear tareas HW en un Dispositivo L<>gico Programable (PLD).
\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.

471
course/.docs/book/intro.tex Normal file
View File

@@ -0,0 +1,471 @@
\chapter{Introduci<EFBFBD>n}
\section{Visi<EFBFBD>n, Paradigmas, y Dificultades}
El gran avance de las t<>cnicas de fabricaci<63>n de Circuitos Integrados ha
permitido que los sistemas digitales sean partes fundamentales de nuestra
vida, a<>n sin darnos cuenta, diariamente interactuamos con ellos,
facilitando las tareas cotidianas. Los niveles de integraci<63>n actuales
permiten construir sistemas cada vez m<>s peque<75>os, veloces y de menor
consumo de potencia, lo cual ha favorecido su difusi<73>n. El uso de los sistemas
digitales en \'<EFBFBD>reas como la aviaci<63>n, la industria automovil\'{\i}stica, la
bioingenier\'{\i}a, etc. demanda de estos un alto desempe<70>o y un
funcionamiento continuo, el no cumplimiento de estas exigencias traer\'{\i}a
consecuencias desastrosas.
Una de las t\'ecnicas utilizadas actualmente para aumentar la confiabilidad
de un sistema es la redundancia hardware, esta redundancia se logra
adicionando unidades funcionales de reserva, que entrar\'an en operaci\'on
cuando la unidad operativa en un determinado momento falle. Otra t\'ecnica
utilizada es la distribuci\'on de tareas en varias unidades de procesamiento.
Con esto no se depende de la confiabilidad de un sistema complejo y costoso
sino que se dispone de muchas unidades de c\'omputo simples y econ\'omicas;
pero que en conjunto son m\'as robustas que el sistema centralizado. Sin
embargo, contar con varias unidades de procesamiento genera nuevos retos como
la divisi\'on y coordinaci\'on de tareas; la forma de realizar estas funciones
de forma \'optima ha sido el objetivo de muchos estudios, los cuales
contin\'uan hasta hoy.
La tecnolog\'{\i}a de los semiconductores adelanta a la capacidad de
utilizaci\'on por parte de los dise<73>adores, lo cual crea una brecha en la
productividad: cada a<>o, el n\'umero de transistores disponibles aumenta en un
58\% mientras las utilizaci\'on por parte de los dise<73>adores lo hace en un
21\% {\cite{KAK01}}. A medida que aumenta el campo de aplicaci\'on de los
sistemas digitales, lo hacen las exigencias de funcionamiento a ellos
impuestas, nuevos retos en el dise<73>o se presentan a medida que los sistemas
embebidos se integran a nuestra vida diaria, se hace necesario dise<73>ar nuevas
t\'ecnicas que permitan eliminar la brecha en la productividad.
\subsection{Futuro de los Sistemas Computacionales}
\begin{quote}
"The best way to predict the future is to invent it."
Alan Kay
\end{quote}
\subsubsection{Computador Ubicuo}
Observando la tendencia actual de los sistemas electr\'onicos, se puede
especular que el computador tal como lo conocemos actualmente desaparecer\'a
{\cite{WM91}}, ya que estar\'a en todas partes, ubicuo, interactuando con los
seres humanos para realzar el mundo que ellos viven. Se pasar\'a de un esquema
en el que existe un computador para uno o varios usuarios (PC, mainframe) a
uno en el que existan muchos computadores para un usuario. Estos computadores
disponen de grandes capacidades de c\'alculo y de comunicaci\'on, pero a la
vez, poseen un grado de integraci\'on tal que ser\'an invisibles; para aclarar
como se puede lograr esta invisibilidad, imag\'{\i}nense que existen sistemas
embebidos construidos con t\'ecnicas de microfabricaci\'on y que son capaces
de tomar su energ\'{\i}a de fuentes alternas como la temperatura, la
radiaci\'on solar, o a partir de fen\'omenos qu\'{\i}micos, debido a su
reducido tama<6D>o, estos sistemas pueden integrarse a objetos o pintarse sobre
ellos, de tal forma que no sean visibles ante los ojos humanos. Esta
desaparici\'on no solo ser\'a una consecuencia de la tecnolog\'{\i}a, sino de
la sicolog\'{\i}a humana; cuando las personas asimilan perfectamente algo y se
convierte en parte de la vida diaria no se es consciente de su utilizaci\'on.
Por ejemplo, cuando observamos una se<73>al de tr\'ansito capturamos la
informaci\'on sin ser conscientes de la realizaci\'on del acto de la lectura.
\begin{figure}[h]
\begin{center} \includegraphics[scale=.6]{./images/Ubiquitous.jpg} \end{center}
\caption{Concepto de Computador Ubiquo.}
\end{figure}
Hasta el momento el dise<73>o de sistemas tanto software como hardware se ha
centrado en las m\'aquinas, las personas se encargan de crear condiciones
adecuadas de trabajo para ellas. Nos vemos obligados a interactuar con estas
utilizando su propio lenguaje, lo cual dificulta su manejo. En el futuro la
computaci\'on tendr\'a como centro al ser humano, estar\'a en todas partes
dispuesta a ayudarle en sus tareas diarias. No tendr\'an que llevar
computadoras con ellos, se podr\'a interactuar con ellas en cualquier parte a
trav\'es de dispositivos como HandHelds, tel\'efonos celulares, etc no tendremos que
preocuparnos por nuestra privacidad ya que ellas se encargar\'an de eso {\cite{Oxygen}}.
Un nuevo t\'ermino aparece en el escenario del dise<73>o de Sistemas Digitales:
Los \textit{ambientes Inteligentes}, este t\'ermino se utiliza para describir
entornos electr\'onicos sensibles a la presencia de personas, en estos
entornos los usuarios interact\'uan de forma natural con recursos
computacionales que les ayudan a la realizaci\'on de tareas. Es una nueva
\'area de desarrollo que involucra a profesionales en las \'areas de:
Ingenier\'{\i}a Electr\'onica, Ingenier\'{\i}a Mec\'anica, Ciencias de la
computaci\'on, redes y comunicaciones, ciencias sociales y humanistas.
En las siguientes secciones se estudiar\'a el impacto de la computaci\'on
ubicua en el dise<73>o de los sistemas digitales siguiendo los lineamientos de
Marc Weiss {\cite{WM91}} y David Servat {\cite{DS02}}.
\subsubsection{Ambientes Inteligentes.}
En la actualidad, cada vez con m\'as frecuencia, se notan signos de la
invasi\'on digital, por ejemplo, en el aumento de chips embebidos en los
dispositivos que utilizamos a diario. Se ha demostrado {\cite{MW93}} que una
persona que vive en un pa\'{\i}s industrializado se ve confrontada con un
promedio de 40 chips al d\'{\i}a, de los cuales 5 son capaces de comunicarse
en redes. Se estima que dentro de 10 a<>os estaremos en contacto con cientos de
estos chips, la mayor\'{\i}a de los cuales acceden a densas redes de
informaci\'on {\cite{DS02}}, muchos de estos artefactos toman la apariencia de
objetos que utilizamos en nuestra vida diaria (herramientas, vestuario,
electrodom\'esticos, etc) pero son mejorados con sensores, actuadores,
procesadores y software embebido. Una de las razones de la aparici\'on de
estos sistemas es econ\'omica. Las industrias han visto como se muestran
signos de recesi\'on en los mercados tradicionales. Por lo tanto, buscan
nuevos productos en los que pueden ser embebidos chips y software. El
an\'alisis de los procesos de adopci\'on de los dispositivos tecnol\'ogicos de
hoy muestra que la introducci\'on en el mercado de nuevos dispositivos genera
la alteraci\'on o la creaci\'on de nuevos h\'abitos {\cite{DS02}}. Esta
invasi\'on electr\'onica trae consigo una serie de efectos que resultan poco
pr\'acticos e inc\'omodos para sus usuarios humanos:
\begin{itemize}
\item La interacci\'on se realiza utilizando el lenguaje del dispositivo,
este lenguaje no es \'unico, por lo tanto debemos aprender un tipo de
lenguaje para un tipo de aplicaci\'on determinda.
\item Estos dispositivos no pueden comunicarse entre s\'{\i}, por lo que nos
vemos obligados a buscar \textit{traductores} que sirvan de puente
entre ellos.
\item Est\'an construidos para operar en un ambiente determinado, lo cual
nos obliga a movilizarnos con el f\'{\i}n de utilizarlos.
\item No realizan distinci\'on entre usuarios, cada vez que un usuario
diferente los use debe configurar sus preferencias.
\end{itemize}
Los ambientes inteligentes son entornos electr\'onicos que son sensibles y
responden a la presencia de personas {\cite{EA01}}. Est\'an compuestos por
muchos dispositivos distribuidos que interact\'uan con el usuario de forma
natural. El concepto fue construido con base en las ideas de Marc Weiser
{\cite{WM91}}, en {\cite{NRC01}} se puede encontrar un resumen de los
desarrollos y retos recientes en este campo de investigaci\'on. En un ambiente
inteligente, las personas est\'an rodeadas por redes de dispositivos
inteligentes embebidos que proporcionan informaci\'on ubicua, comunicaci\'on,
servicios y entretenimiento {\cite{APaET03}}. Adem\'as, estos dispositivos se
adaptan por si mismos a los usuarios, y anticipan sus necesidades. La
electr\'onica puede integrarse en el vestuario, los muebles, autom\'oviles,
casas, oficinas y sitios p\'ublicos, introduciendo el problema del desarrollo
de nuevos conceptos de interfaz de usuario que permitan la interacci\'on
natural con estos entornos. Las funciones b\'asicas que deben realizar los
ambientes inteligentes son:
\begin{itemize}
\item Conocimiento del entorno.
\item Sistemas inal\'ambricos Distribuidos.
\item Interacci\'on natural con los usuarios.
\end{itemize}
La visi\'on de los ambientes inteligentes es que las aplicaciones ser\'an cada
vez m\'as y m\'as distribuidas y ser\'an ejecutadas en plataformas que
proporcionan recursos de forma din\'amica. Estas aplicaciones deben cumplir
con las funciones mencionadas anteriormente. Los nuevos retos que generan los
ambientes inteligentes al dise<73>o de Sistemas embebidos se pueden dividir en
interacci\'on y adaptaci\'on:
\begin{itemize}
\item Interacci\'on con:
\begin{itemize}
\item las aplicaciones,
\item la plataforma Hardware,
\item otros dispositivos,
\item el usuario.
\end{itemize}
\item Adaptaci\'on:
\begin{itemize}
\item al cambio de aplicaciones y necesidades del usuario,
\item a la cantidad de recursos Hardware,
\item a cambios en el entorno.
\end{itemize}
\end{itemize}
\subsubsection{Consecuencias de la aparici\'on de los sistemas de computaci\'on
ubicua.}
La aparici\'on de la computaci\'on ubicua no es una revoluci\'on, por el
contrario es una consecuencia l\'ogica de la evoluci\'on de las relaciones
entre los usuarios y los sistemas de computadores, los cuales se han
caracterizado por una democratizaci\'on de acceso a los equipos y una
descentralizaci\'on de la infraestructura subyacente. En el primer
per\'{\i}odo (1950-1970) se compart\'{\i}an recursos a trav\'es de terminales,
es decir, se contaba con un computador para muchos usuarios. En los 80s, la
aparici\'on de los computadores personales impulsa la relaci\'on personal
entre los computadores y usuarios. El los 90s la aparici\'on de Internet
permiti\'o compartir recursos a trav\'es de un computador personal. Internet
no es m\'as que un paso adelante hacia la llegada de los sistemas de
computaci\'on ubicua. La misma filosof\'{\i}a de simplificaci\'on y
descentralizaci\'on prevalece hasta hoy y nos conducir\'a a una situaci\'on
donde miles de dispositivos computacionales estar\'an disponibles para
realizar nuestras tareas y se compartir\'an recursos a trav\'es de redes m\'as
intrincadas que Internet. En conclusi\'on se pasar\'a de un esquema en el que
se ten\'{\i}a un computador para muchos usuarios a uno en el que se tienen
muchos (tal vez miles o millares) elementos computacionales para servir a un
usuario.
Estos sistemas ser\'an componentes de una infraestructura computacional que
difiere radicalmente de las que conocemos hoy, y deben poseer las siguientes
caracter\'{\i}sticas:
\begin{itemize}
\item Descentralizados: la centralizaci\'on adem\'as de impr\'actica no
permite que diferentes usuarios puedan controlar sus componentes.
\item Manejar la variaci\'on de su configuraci\'on: debido a la adici\'on o
substracci\'on de sus componentes, o por la forma en que los usuarios los
usan.
\item Estar inmersos en las comunidades humanas con varios tama<6D>os y
necesidades, y operar con informaci\'on incompleta sobre su entorno.
\item Unir combinaciones altamente heterog\'eneas de software y hardware,
las cuales pueden diferir por su funci\'on o por su procesamiento,
comunicaci\'on o capacidades de acci\'on.
\item Ser el resultado de combinaciones de componentes, que pudieron no ser
vistos en tiempo de dise<73>o, sin embargo, producen comportamientos emergentes
interesantes.
\item Adaptarse de forma cont\'{\i}nua a su entorno con el f\'{\i}n de
mejorar su desempe<70>o.
\end{itemize}
El dise<73>o de estos sistemas requiere nuevas fuentes de inspiraci\'on; una
direcci\'on promisoria es verlos y dise<73>arlos como \textit{ecosistemas de agentes f<>sicos} organizados seg\'un principios
biol\'ogicos, qu\'{\i}micos o f\'{\i}sicos {\cite{DS02}}.
\section{Estado del Dise<73>o Electr<74>nico en Colombia}
En la actualidad Colombia atraviesa por una $''$\textit{\textit{crisis}}$''$ a
nivel de dise<73>o de sistemas digitales, existe un atraso muy grande en esta
\'area; a nuestro modo de ver existen dos grandes responsables de esta situaci\'on.
Por un lado, las pol\'{\i}ticas de la mayor\'{\i}a de las industrias al no
realizar inversi\'on de capital en sus departamentos de I+D; algunas de ellas
ni siquiera cuentan con este departamento. Por otro lado, las Universidades no
cuentan con programas actualizados que permitan explotar los avances
realizados en las industrias electr\'onica y de semiconductores; en un gran
n\'umero de Universidades Colombianas a\'un se trabaja con dispositivos de
funci\'on fija como las familias 74 y 40. Los lenguajes de descripci\'on de
hardware han sido adoptados recientemente en la mayor\'{\i}a de programas de
ingenier\'{\i}a electr\'onica, pero en algunos casos no existe una base
metodol\'ogica que soporte su adecuada utilizaci\'on. La disponibilidad de
dispositivos l\'ogicos programables (FPGAs, CPLDs) es limitada debido a la
inexistencia de un proveedor local. Se dedican cursos completos para
$''$ense<EFBFBD>ar$''$ a programar microprocesadores de 8 bits en lenguaje
ensamblador y muchos educadores a\'un miran con desconfianza a los lenguajes
de alto nivel como el C, C++. En muy pocos programas de Ingenier\'{\i}a
Electr\'onica no se cuenta con una asignatura dedicada a sistemas operativos y
en muchos de ellos no se le da la importancia que tiene la ense<73>anza de
lenguajes estructurados.
La situaci\'on se agrava a\'un m\'as al ver el estado de la relaci\'on entre
la universidad y la industria, la cual no existe en algunos casos. Desde el
punto de vista industrial los resultados obtenidos en la academia parten de
entornos ideales y no se tienen en cuenta las caracter\'{\i}sticas de los
entornos industriales, lo cual da como resultado sistemas poco robustos y con
problemas funcionales. Por otro lado, los tiempos de desarrollos son muy
largos ya que la mayor\'{\i}a de las universidades Colombianas no cuenta
con grupos de investigaci\'on que tengan miembros dedicados de forma
exclusiva al desarrollo de este tipo de proyectos, la mayor\'{\i}a \ de los
miembros de estos grupos son temporales (estudiantes de pregrado) y sin paga,
lo cual no garantiza el cumplimiento ni la continuidad de las investigaciones.
\subsection{Apropiaci<EFBFBD>n de Conocimiento}
Para que Colombia deje de ser un pa<70>s que consume tecnolog<6F>a y llegue en alg<6C>n momento a ser generador de productos tecnol<6F>gicos, es necesario que se genere un conocimiento que permita esta transici<63>n. ``Para que el conocimiento sea motor de desarrollo es necesario el traspaso desde sus creadores a la sociedad, mediante la conversi<73>n a tecnolog<6F>as que produzcan cambios radicales que incrementen la producci<63>n. Esa transmisi<73>n de tecnolog<6F>a generadora de crecimiento econ<6F>mico esta influenciada por diversos factores: medio geogr<67>fico, leyes de propiedad industrial, costos laborales, nivel de ciencia y tecnolog<6F>a, religi<67>n, tipos de instituciones, resistencia a innovar, pol<6F>ticas de estado, guerras, factores demogr<67>ficos, entre otros'' \cite{Mok90}
Pero como apropiar este conocimiento? Arrow \cite{Arr62} afirma que la apropicaci<63>n de conocimiento puede efectuarse de varias formas: ``aprender haciendo'', ``aprender usando'', ``aprender leyendo''. Cuando una empresa decide transmitir su conocimiento disponible, lo hace en procesos de investigaciones conjuntas, en actividades de producci<63>n, y distribuci<63>n, mercadeo, servicio y soporte operativo o riesgo compartido. Tambi<62>n se presentan alianzas entre firmas como: contratos de I+D, acuerdos de licencias, licencias cruzadas. La conformaci<63>n de estas asociaciones permite crear redes tecnol<6F>gicas dominadas por pa<70>ses industrializados con sus respectivas empresas multinacionales monopolizando conocimiento \cite{Mar04}
Para Colombia, el problema radica en que las empresas de capital nacional no est<73>n adquiriendo el conocimiento necesario para lograr innovaciones al interior de las mismas. De forma que puedan ser competitivas y logren acceder a mercados internacionales ofreciendo productos innovadores, de calidad y a precios competitivos. Con efectos directos como: generaci<63>n de empleos especializados, desarrollo tecnol<6F>gico e industrial sostenido, ampliaci<63>n del acervo de conocimiento nacional y disminuci<63>n de la salida de divisas (al mejorar los procesos de negociaci<63>n) y creaci<63>n de externalidades positivas \cite{Mar04}.
Ligado al problema de la senda tecnol<6F>gica est<73> el del grado de lo t<>cito del conocimiento cient<6E>fico. Teece \cite{Tee81} se<73>ala que al existir conocimiento t<>cito toda la tecnolog<6F>a disponible no se transfiere de los productores a los receptores o compradores de la misma. Por tanto, los pa<70>ses seguidores siempre van a estar a la zaga tecnol<6F>gica. Forbes y Wield \cite{FW00} se<73>alan que los esfuerzos adaptativos son mayores porque deben acomodar las ``innovaciones'' a los materiales locales, fuerza laboral nativa, mercados internos y medio ambiente local. Entonces, el problema no se limita a c<>mo transferir conocimiento, c<>mo develar su parte t<>cita y c<>mo extraerlo de las multinacionales, sino que radica en el bajo poder de negociaci<63>n y adquisici<63>n de tecnolog<6F>a por firmas peque<75>as y medianas, las cuales carecen de recursos y tienen procesos deficientes de contrataci<63>n.
En este orden de ideas, si el pa<70>s no es un innovador neto <20>no deber<65>a m<>s bien mostrar una tendencia a importar conocimiento? Y las firmas nacionales <20>no deber<65>an ser las que m<>s efectuaran este tipo de contratos, para as<61> acceder al conocimiento de la tecnolog<6F>a adquirida? En resumen, conociendo mejor qu<71> tecnolog<6F>a se importa y qu<71> tipos de contratos se utilizan, es posible crear marcos de referencia para empresas nacionales que est<73>n interesadas en adquirir tecnolog<6F>a. Esto producir<69>a externalidades positivas en empresas importadoras de conocimiento y, a su vez, en la econom<6F>a del pa<70>s. Con una adecuada importaci<63>n de conocimientos tecnol<6F>gicos se crear<61>a una ventaja competitiva de car<61>cter estructural, basada en un acervo de conocimiento tecnol<6F>gico que permita incrementar la productividad en todos los sectores econ<6F>micos de manera permanente \cite{Mar04}.
Seg<EFBFBD>n los estudios realizados por Mart<72>nez, con base en registros del Decreto 259/92, del Incomex. La importaci<63>n de conocimiento no est<73> siendo empleada con el prop<6F>sito de utilizar tecnolog<6F>as de punta que permitan efectuar innovaciones al interior de las empresas y de los sectores. Las empresas nacionales se limitan a comprar un determinado dispositivo, sin tener el conocimiento para operarlo, hacerle mantenimiento ni mucho menos mejorarlo, por lo que se ven obligadas a contratar con el vendedor contratos para dicho f<>n. Esto indica que la adquisici<63>n de tecnolog<6F>a no se realiza con base en programa desarrollado de antemano, sino son una respuesta a cambios en el mercado, lo cual evidencia la inexistencia de programas de innovaci<63>n encaminados a la disminuci<63>n de la brecha tecnol<6F>gica.
\subsection{Situaci<EFBFBD>n de la Industria Electr<74>nica en Colombia}
La industria electr<74>nica nacional no es ajena a las pol<6F>ticas que siguen las empresas nacionales en cuanto a la apropiaci<63>n de tecnolog<6F>a; Colombia depende totalmente de econom<6F>as m<>s desarrolladas para el suministro de dispositivos electr<74>nicos en diversas areas (comunicaciones, entretenimiento, industria, medicina, etc). Mientras en otros sectores de la econom<6F>a han pasado de ser consumidores a exportadores, y adquieren nuevas tecnolog<6F>as para ser m<>s competitivos, el sector electr<74>nico del pa<70>s ha reducido sus actividades de Investigaci<63>n y Desarrollo hasta el punto de depender totalmente de productos externos, de los cuales, algunos son de baja calidad y no suplen los requerimientos del mercado local, pero son utilizados porque son muy econ<6F>micos.
En la actualidad la industria electr<74>nica presenta una gran din<69>mica a nivel mundial, el uso de los sistemas electr<74>nicos se extiende a todas las actividades humanas; La demanda mundial de este tipo de sistemas aumentar<61> de forma dram<61>tica en los pr<70>ximos a<>os, especialmente en los sectores de tecnolog<6F>a m<>dica, movilidad, seguridad, comunicaciones y consumo \cite{ETPoSSI(09}. El mercado de los sistemas embebidos es una industria que movi<76> alrededor de 25 billones de d<>lares en el 2008 seg<65>n Venture Development Corporation \cite{Vc08}. Por otro lado, la inversi<73>n de capital necesaria para el dise<73>o de Sistemas Embebidos es relativamente baja, gracias a la gran demanda originada, los insumos y los servicios de fabricaci<63>n son muy econ<6F>micos, las herramientas de desarrollo necesarias para la programaci<63>n y depuraci<63>n de este tipo de sistemas son de libre distribuci<63>n.
Desafortunadamente en Colombia la industria electr<74>nica se encuentra muy rezagada en relaci<63>n a las de los pa<70>ses industrializados, y las ventajas y oportunidades de negocios mencionadas anteriormente no son aprovechadas en la actualidad.
Seg<EFBFBD>n ASESEL \footnote{Asociaci<EFBFBD>n de entidades del Sector Electr<74>nico} en el 2001 exist<73>an 154 empresas productoras de componentes y equipos de la cadena electr<74>nica. Dentro de los productos que la industria electr<74>nica exporta se encuentran registrados: Circuitos integrados, circuitos impresos, microestructuras, instrumentos para medida y control, Instrumentos y aparatos el<65>ctricos o electr<74>nicos. Es importante decir que la industria colombiana, en la actualidad no fabrica circuitos integrados, ni microestructuras, por lo que estas son ventas de productos comprados en pa<70>ses desarrollados. Seg<65>n Proexport el 91\% de las exportaciones son realizadas por Bogot<6F> y los destinos se encuentran en pa<70>ses cercanos como Venezuela, Per<65>, Ecuador y USA.
La electr<74>nica en Colombia y en el mundo hace parte de esas industrias que se mueven velozmente en un
camino desconocido, como consecuencia se hace necesario tener una actualizaci<63>n constante de los
avances tecnol<6F>gicos y las proyecciones futuras del sector. Debido a la importancia del sector tecnol<6F>gico es primordial que en Colombia se est<73> consciente del estado actual y que se puede hacer en t<>rminos de
Investigaci<EFBFBD>n Cient<6E>fica y Desarrollo Tecnol<6F>gico (I+D) en Ingenier<65>a Electr<74>nica.
Un estudio realizado en la Universidad Nacional de Colombia \cite{MTRR07} identific<69> los siguientes obst<73>culos para el desarrollo de la industria electr<74>nica en Colombia: Deficientes relaciones Universidad Empresa, Pobre enfoque acad<61>mico hacia la industria, baja calidad de los productos nacionales, pol<6F>ticas gubernamentales, falta de cultura de Investigaci<63>n y Reducida apropiaci<63>n tecnol<6F>gica, competencia de pa<70>ses asi<73>ticos, atraso tecnol<6F>gico, limitado recurso humano con formaci<63>n avanzada.
De los problemas expuestos anteriormente podemos identificar cuales son los que m<>s afectan el desarrollo de la industria electr<74>nica en Colombia, el que m<>s perjudica sin lugar a dudas es el atraso tecnol<6F>gico, no es posible ser competitivo en el mercado electr<74>nico mundial con tecnolog<6F>as y metodolog<6F>as de dise<73>o obsoletas. \footnote{En Colombia trabajamos a<>n con circuitos integrados que se crearon en la decada de los 80 del siglo pasado y utilizamos lenguajes de programaci<63>n como el \textit{assembler}, para el cual el tiempo de aprendizaje, desarrollo y de depuraci<63>n es muy largo} La culpa de este atraso tecnol<6F>gico no es exclusiva de la industria, aunque, como vimos anteriormente muchas industrial Colombianas se resisten al cambio y prefieren comprar equipos en el exterior a buscarlos localmente, la falta de confiabilidad en los productos Colombianos agrava este problema, esta falta de confianza en la industria local no es infundada, la mayor<6F>a de los productos Colombianos no cumplen con las normas m<>nimas de calidad y utilizan productos de bajo costo obtenidos en remates de componetes.
Otro actor que contribuye al retraso tecnol<6F>gico es el sector acad<61>mico; Seg<65>n el Sistema Nacional de Informaci<63>n Superior, durante los <20>ltimos 10 a<>os se han abierto 230 programas relacionados con la industria electr<74>nica, estos programas est<73>n repartidos entre programas de formaci<63>n Universitaria, tecnol<6F>gica terminal y de t<>cnica profesional, la mayor<6F>a de estos centros de formaci<63>n se encuentran ubicados en 3 Departamentos: Bogot<6F>, Antioquia y Valle \cite{DZSC+07}. El n<>mero de Ingenieros graduados en un a<>o es entre 2 y 8 veces mayor que en los pa<70>ses en v<>a de desarrollo y doce veces mayor que los que se grad<61>an en los pa<70>ses desarrollados. En Colombia, este aumento es aportado por instituciones de poca consolidaci<63>n; adem<65>s, las preferencias en la educaci<63>n superior son Formaci<63>n t<>cnica / form. tecnol<6F>gica / form. profesional que es justamente lo opuesto a la de los pa<70>ses desarrollados \cite{MDAG99}.
Por otro lado, el contenido de las asignaturas relacionadas directamente con la industria electr<74>nica se encuentran muy desactualizados, y fuera del contexto mundial, se utilizan metodolog<6F>as de dise<73>o antiguas en las que primaba la experiencia del dise<73>ador, se realizan tareas manuales, repetitivas que pueden ser realizadas por herramientas de dise<73>o moderno, los curr<72>culos son conservadores hay poca experimentaci<63>n y su estructuraci<63>n y metodolog<6F>as son muy cl<63>sicas. Adicionalmente, muchos investigadores dedican sus estudios en proyectos que no aportan al desarrollo del pa<70>s <20>nicamente porque est<73>n de moda. Otro problema adicional radica en la falta de experiencia en el sector productivo por parte del personal acad<61>mico, un componente importante de los profesores nunca han sido parte de un proceso productivo o de un proceso de desarrollo que tenga como f<>n la creaci<63>n de un producto comercial, raz<61>n por la cual se evita la experimentaci<63>n y se da m<>s <20>nfasis al an<61>lisis y solo se llega a una simulaci<63>n.
De lo anterior podemos concluir que en Colombia se presenta una sobre-oferta de profesionales en el <20>rea electr<74>nica, muchos de los cuales provienen de instituciones educativas con poca consolidaci<63>n, y que han sido formados con programas desactualizados que no tienen en cuenta los avances tecnol<6F>gicos y metodol<6F>gicos, lo cual explica la pobreza de ingenieros con altos niveles de formaci<63>n. Por esta raz<61>n no es de extra<72>ar la poca confianza que tienen los industriales en los productos nacionales.
Lo anterior unido a la falta de pol<6F>ticas de estado que: tracen normas encaminadas a incentivar la inversi<73>n en investigaci<63>n y desarrollo, defina l<>neas y campos de investigaci<63>n, regule la oferta laboral y los programas acad<61>micos, generan el clima perfecto para que el atraso tecnol<6F>gico se mantenga durante mucho tiempo y Colombia no deje de ser un consumidor de tecnolog<6F>a. Seg<65>n John Kao, uno de los grandes expertos del mundo en innovaci<63>n, los pa<70>ses desarrollados no invierten en Ciencia Tecnolog<6F>a e Innovaci<63>n (CTI) porque son ricos, sino que son ricos porque invierten en CTI.
\subsubsection{Tecnolog<EFBFBD>as de Informaci<63>n y Comunicaci<63>n}
En la actualidad existe un especial inter<65>s por parte del gobierno \footnote{ La Agenda de Conectividad es el programa del Ministerio de Comunicaciones, encargado de impulsar el uso y masificaci<63>n de las Tecnolog<6F>as de Informaci<63>n y Comunicaci<63>n -TIC- como herramienta dinamizadora del desarrollo social y econ<6F>mico del pa<70>s ()} en impulsar las Tecnolog<6F>as de la Informaci<63>n y la Comunicaci<63>n (TIC). Este programa no debe centrarse en solo difundir el uso de internet y aumentar el n<>mero de personas que tienen acceso a un computador. ``La tecnolog<6F>a es simplemente la infraestructura, si la infraestructura no est<73> acompa<70>ada por la creaci<63>n de habilidades y conocimiento la adopci<63>n de TICs no ayudar<61> a obtener los beneficios que esperamos, sin embargo, ayudar<61>n con los intereses de los m<>s poderosos y de las naciones m<>s ricas.'' \footnote{Brito Lidia, ``Enabling Environment, ICT for Development and the Millennium Development Goals'',p<>gina 20, 2005}. Las TICs deben utilizar la educaci<63>n como pricipal herramienta para reducir la \textit{brecha tecnol<6F>gica} que existe entre las diferentes regiones de nuestro pa<70>s y de nuestro pa<70>s con los paises desarrollados.
Hearn, Simpson, Lennie y Kimber \cite{HSL+04} \cite{MJF05} nombran las siguientes caracter<65>sticas para que las TICs contribuyan con el desarrollo regional.
\begin{enumerate}
\item Conseguir claridad en especificar objetivos sostenibles, las regiones no se
pueden dar el lujo de esperar a que todo les sea entregado y listo, ponerlo a
funcionar, debe existir un plan para evitar que la tecnolog<6F>a se vuelva
obsoleta y se acabe el proyecto por esta causa.
\item Apalancar el desarrollo de la empresa peque<75>a ayudado por personal y
financiaci<63>n del gobierno y utilizando las fortalezas de las industrias locales.
\item Construir basado en las industrias fuertes locales; Aprender de las
experiencias globales mientras que se construye en acciones locales
\item Encontrar innovadores modelos de negocios para aprovecharlos en nuevas
oportunidades de contenidos y aplicaciones.
\item Asegurar el envolvimiento de la comunidad en la decisi<73>n, planeaci<63>n y
evaluaci<63>n de proyectos. Hemos visto que para que un proyecto de
tecnolog<6F>a tenga <20>xito se debe involucrar a la sociedad civil, a ellos deben ir
dirigidos los principales beneficios, deben ser ellos quienes se capaciten y
de esta forma el proyecto va a funcionar.
\item Adoptar una metodolog<6F>a de aprendizaje a trav<61>s de ciclos de evaluaci<63>n
basados en una acci<63>n investigativa.
\end{enumerate}
Adicionalmente es necesario buscar el bien com<6F>n por encima del individual, raz<61>n por la cual debemos preguntarnos quienes son los favorecidos por la difusi<73>n de estas tecnolog<6F>as, no tiene sentido invertir grandes sumas de dinero para llevar estas tecnolog<6F>a a lugares donde no saben como utilizarlas y m<>s a<>n, en lugares donde las necesidades b<>sicas no han sido resueltas. Es importante pensar en las personas a las que se va a beneficiar y preparar el camino para que el impacto sea mayor, sin educaci<63>n y sin entrenamiento no se le puede sacar provecho a estas tecnolog<6F>as. Debemos crear herramientas que integren a nuestros pueblos y que permitan colaborar entre ellas.
En la actualidad esta pol<6F>tica gubernamental se limita a comprar software propietario normalmente el sistema operativo MicroSoft Windows y aplicaciones del mismo fabricante como su suite Office y MSN. Esto no aporta absolutamente nada al desarrollo tecnol<6F>gico del pa<70>s ya que al ser un sistema operativo cerrado no es posible modificarlo o aprender sobre su funcionamiento, el usuario debe limitarse a aceptar lo que el fabricante le entrega y si quiere desarrollar apliaciones propias debe pagar por las herramientas de desarrollo y por la documentaci<63>n. Microsoft utiliza una pol<6F>tica de reducci<63>n de precios para los centros educativos y algunos centros gubernamentales, esta ``donaci<63>n'' solo crea dependencia tecnol<6F>gica y en la mayor<6F>a de los casos promueve acciones ilegales ya que (el costo de estos productos son los mismos en todo el mundo y en muchas ocasiones cuestan m<>s que el computador sobre el que se ejecuta) los usuarios obtienen software ilegal, pr<70>ctica que se generaliza a todo el software no solo al de Microsoft lo que hace que las empresas medianas y peque<75>as locales sean forzadas a cerrar sus negocios. Por otro lado, al permitir que solo una empresa extranjera sea la que decide sobre el futuro del software utilizado en la mayor<6F>a de los computadores de una naci<63>n se est<73> cediendo la soberan<61>a para el beneficio de un particular for<6F>neo.
Lo mismo sucede con los equipos que se utilizan para acceder a estas tecnolog<6F>as, en la mayor<6F>a de los casos son fabricados en paises con diferentes culturas y diferentes necesidades. Es obvio que el pa<70>s no puede fabricar ciertos equipos que se requieren para poder llevar estas tecnolog<6F>as a las diferentes regiones, sin embargo, este trabajo proporciona una base s<>lida sobre la cual se puede desarrollar un producto similar al propuesto por el proyecto del MIT OLPC (One Laptop For Child), el cual busca construir un dispositivo de muy bajo costo (200 USD) que permita a los estudiantes y a la comunidad en general, aprender los conceptos b<>sicos para poder utilizar estas tecnolog<6F>as. De esta forma impulsamos la industra electr<74>nica produciendo de forma masiva un dispositivo electr<74>nico en el pais, dise<73>ado para suplir necesidades de la regi<67>n. Esta plataforma no solo poroporcionar<61> la base para el desarrollo de las TICs, sino la base tecnol<6F>gica sobre la cual se pueden desarrollar muchas soluciones a problemas de la industria local.
Es posible incluir el presente estudio en dicho programa de tal forma que el objetivo final de este programa no sea aumentar la venta de licencias de un determinado sistema Operativo o el n<>mero de computadores con acceso a internet, sino desarrollar en el pais la tecnolog<6F>a necesaria para que las universidades y empresas locales sean capaces de desarrollar dispositivos que permitan el acceso a estas tecnolog<6F>as.
\subsection{Estado de la Electr<74>nica Digital en la Universidad Nacional de Colombia}
Hasta hace un a<>o en las asignaturas del <20>rea de electr<74>nica digital de la Universidad Nacional de Colombia (La Universidad p<>blica m<>s grande e importante del pais), se trabajaba con dispositivos que fueron sacados al mercado en 1966 y 1968, las familia l<>gica TTL 7400 y CMOS 4000. El problema principal al utilizar esta tecnolog<6F>a no es su a<>o de creaci<63>n, ni siquiera que en la actualidad se consideren obsoletas para el dise<73>o de un sistema digital completo. \footnote{En la actualidad estas compuertas se utilizan para la implementaci<63>n de peque<75>as operaciones l<>gicas} El problema detr<74>s del uso de esta tecnolog<6F>a se encuentra en la ausencia total de metodolog<6F>as de dise<73>o (en el caso Colombiano). Y el desconocimiento en herramientas tipo CAD. El proceso de dise<73>o que realizaban los estudiantes era:
\begin{enumerate}
\item Especificaciones del sistema.
\item Generaci<63>n manual de ecuaciones boolenas.
\item Minimizaci<63>n manual utilizando mapas de Karnaugh.
\item Implementaci<63>n de las ecuaciones minimizadas utilizando las familias l<>gicas 7400 y 4000, sobre placas de pruebas (protoboards, breadboards)
\item Pruebas del sistema.
\end{enumerate}
A manera de ejercicio acad<61>mico se justifica el uso de las familias 7400 y 4000, sin embargo, el quedarse ahi no es bueno para una industria electr<74>nica desactualizada, debido a que este tipo de implementaciones no pueden generar productos competitivos a nivel mundial. La raz<61>n de esto es que existen muchas fuentes de error en el proceso, generados por la ausencia de herramientas CAD que realicen las operaciones tediosas como las minimizaci<63>n de ecuaciones booleanas, las cuales est<73>n sujetas a errores humanos originados por cansancio, falta de concentraci<63>n, etc. Otro aspecto que vale la pena resaltar es la falta de una simulaci<63>n funcional, la mayor<6F>a de los estudiantes consultados no realizaban simulaciones funcionales y prefer<65>an probar el dise<73>o una vez implementado f<>sicamente, esto unido a la dificultad de depuraci<63>n innata a este tipo de implementaciones, aumentaba considerablemente el tiempo requerido para realizar la implementaci<63>n y pruebas del sistema.
En el segundo curso del <20>rea de electr<74>nica digital, se introduce al estudiante al uso de los dispositivos l<>gicos programables (PLD) y los lenguajes de descripci<63>n de hardware (HDL) como herramientas para el dise<73>o de sistemas digitales, al comienzo, el contenido de estos cursos se limitaba al uso de una herramienta de dise<73>o y la ense<73>anza de nociones b<>sicas del lenguaje VHDL, se daba m<>s importancia al uso de la herramienta y no a la metodolog<6F>a de dise<73>o, de nuevo el estudiante ataca los problemas sin una metodolog<6F>a de dise<73>o clara. Vale la pena indicar que este curso fue dictado por profesores ocasionales durante los <20>ltimos cuatro a<>os, cada profesor utilizaba contenidos y niveles de exigencia diferentes.
En la tercera parte del curso se trabaja con sistemas microcontrolados, se utilizan microcontroladores de 8 bits de diferentes familias y se utiliza el lenguaje ensamblador como herramienta de desarrollo. Una de las principales desventajas que presenta este curso (y de la l<>nea en general) es la falta de continuidad en los contenidos y en la metodolog<6F>a utilizada, ya que el contenido de este curso se encuentra totalmente desligado al de los dos anteriores. Sin embargo, durante este curso se proporciona una metodolog<6F>a de dise<73>o en la que los estudiantes emulan el comportamiento del microcontrolador antes de ser programado, sin embargo, esta pr<70>ctica no es seguida por la mayor<6F>a de los estudiantes, una posible causa de este comportamiento puede ser la falta de metodolog<6F>as de dise<73>o en los cursos anteriores.
La sensaci<63>n que queda al terminar el <20>rea de electr<74>nica digital es que lo <20>nico que importa son los microcontroladores y que lo visto en los primeros cursos no es muy <20>til. La siguiente tabla muestra los problemas encontrados en el <20>rea de electr<74>nica digital de las carreras de Ingenier<65>a El<45>ctrica y Electr<74>nica de la Universidad Nacional de Colombia:
\begin{enumerate}
\item Falta de una metodolog<6F>a de dise<73>o.
\item Utilizaci<63>n de herramientas obsoletas: Familias L<>gicas, lenguajes de programaci<63>n.
\item Poco uso de las herramientas CAD.
\item Falta de continuidad en las asignaturas.
\item Falta de docentes.
\item No se suministra una formaci<63>n adecuada que ayude a la industria electronica a salir del retraso tecnol<6F>gico.
\end{enumerate}
\section{Descripci<EFBFBD>n de la T<>sis}
\subsection{Objetivos e Hip<69>tesis}
\subsubsection{Ojetivo Principal}
Desarrollar una metodolog<6F>a para la transferencia tecnol<6F>gica y de conocimientos en el <20>rea de Sistemas Embebidos.
El objetivo de este trabajo es contribuir a dar soluci<63>n al problema del atraso tecnol<6F>gico en Colombia, puntualmente en los siguientes puntos:
\subsubsection{Objetivos Secundarios}
\begin{itemize}
\item Formulaci<63>n de una metodolog<6F>a para la transferencia tecnol<6F>gica y de conocimientos en el <20>rea de Sistemas Embebidos en Colombia.
\item Formulaci<63>n de una metodolog<6F>a de Dise<73>o y producci<63>n para Sistemas Embebidos aplicable en el entorno local.
\item Identificaci<63>n de las habilidades requeridas para los profesionales y t<>cnicos en la Industria Electr<74>nica para estar acorde con la tendencia de la industria electr<74>nica mundial y formulaci<63>n de recomenadaciones para la industria y los organismos gubernamentales encaminadas a mejora la productividad de la industria electr<74>nica del pa<70>s.
\item Desarrollo de Plataformas Hardware que utilicen tecnolog<6F>a de punta.
\item Dise<73>o de los programas de las asignaturas del <20>rea de electr<74>nica digital en programas de pregrado para incorporar las nuevas metodolog<6F>as modernas de dise<73>o y producci<63>n.
\end{itemize}
\subsubsection{Hip<EFBFBD>tesis}
Las recomendaciones dadas por los estudios sobre como solucionar el problema del desarrollo tecnol<6F>gico, hablan de como se debe trabajar de forma local, teniendo en cuenta la experiencia generada globalmente, Por lo que partiemos de la hip<69>tesis que es posible utilizar t<>cnicas de auto-organizaci<63>n para que diferentes centros de formaci<63>n y producci<63>n distribuidos a lo largo del pa<70>s encuentren la forma de distribuir de forma eficiente los recursos (Informaci<63>n, conocimiento, recursos econ<6F>micos) comunes para alcanzar en forma conjunta el objetivo principal: Encontrar pol<6F>ticas de auto-gobierno que permitan el beneficio de la comunidad.
\subsection{Aproximaciones}
El problema del atraso tecnol<6F>gico en Colombia debe ser atacado desde varios flancos para que pueda ser resuelto de forma efectiva. Como se indic<69> anteriormente solo con el trabajo conjunto de la industria, la academia y las politicas gubernamentales podremos avanzar en la soluci<63>n del problema. El trabajo realizado ac<61> solo puede contribuir a la soluci<63>n del problema con soluciones encaminadas a la industria y la academia.
Porqu<EFBFBD> se eligi<67> el <20>rea de dise<73>o de sistemas digitales para atacar el problema del atraso tecnol<6F>gico? B<>sicamente porque este sector es el que presenta un mayor retraso en el pais, adicionalmente, muchas <20>reas del conocimiento (como control, instrumentaci<63>n, medici<63>n, comunicaciones, rob<6F>tica, etc) se apoyan en dispositivos digitales como herramientas para implementar aplicaciones. Por otro lado, existe una gran demanda de productos especializados con capacidades de comunicaci<63>n especiales y de procesamiento, tanto en el mercado de productos de consumo (Entretenimiento, electrodim<69>sticos, etc), como en el mercado de productos espscializados (Sistemas de control, sistemas de medici<63>n, etc).
Para que el estudio realizado tenga un mayor impacto se deben evitar temas en los que se requieran grandes inversiones en infra-estructuras como por ejemplo dise<73>o y fabricaci<63>n de Circuitos Integrados o aplicaciones en nanotecnolog<6F>a, ya que los laboratorios necesarios son muy costosos y en el pa<70>s no existe a<>n la demanda suficiente que sostenga los costos de funcionamiento de este tipo de procesos. Teniendo en cuenta esto, existen varias alternativas en las que el pa<70>s podr<64>a llegar a ser competitivo a corto plazo y generar productos que compitan con los ofrecidos por industrias de pa<70>ses desarrollados, estas son:
\begin{itemize}
\item Desarrollo de n<>cleos de Propiedad Intelectual (IPs)
\item Desarrollo de dispositivos dedicados a resolver problemas espec<65>ficos utilizando dispositivos semiconductores ya existentes.
\begin{itemize}
\item Dise<73>o de plataformas de Desarrollo Hardware robustas.
\item Creaci<63>n de plataformas de desarrollo software estables.
\item Desarrollo de aplicaciones basadas en las plataformas de desarrollo ya creadas.
\end{itemize}
\item Desarrollo de aplicaciones HW/SW para que sean fabricadas en otros pa<70>ses con mayor oferta en servicios de manufactura.
\end{itemize}
Los sistemas embebidos proporcionan una visi<73>n completa del proceso de producci<63>n de nuevos dispositivos: Concepci<63>n, Dise<73>o, Implementaci<63>n y Operaci<63>n, adicionalmente es un mercado que mueve miles de millones de D<>lares al a<>o y su campo de acci<63>n abarca casi todas las actividades humanas (Educaci<63>n, entrtenimiento, transporte, salud, productividad), existe una infinidad de herramientas Hardware (Procesadores, SoCs, FPGAs, dise<73>os de referencia, herramientas CAD) y Software (Compiladores, depuradores, librer<65>as, Sistemas Operativos, Aplicaciones) y una gran din<69>mica en la industria que proporciona servicios de manufactura (suministro de componentes, fabricaci<63>n, pruebas, distribuci<63>n). Lo que permite ingresar a este mercado con bajas inversiones de dinero, lo que es ideal para la situaci<63>n actual del pa<70>s (baja inversi<73>n en I+D), y es perfecta para que reci<63>n egresados puedan crear nuevos productos y servicios utilizando sistemas embebidos.
Para asegurar que existan profesionales capaces de utilizar los nuevos conocimientos es necesario crear cursos de actualizaci<63>n a diferentes niveles: Cursos de capacitaci<63>n, Diplomados, L<>neas de profundizaci<63>n en pregrado y posgrado; Modificar el contenido de las asignaturas de las materias relacionadas con la electr<74>nica digital para actualizar sus contenidos y las metodolog<6F>as de dise<73>o adecuadas, tambien es necesario un cambio en el enfoque, debemos pasar de un perfil anal<61>tico a un perfil de dise<73>ador-investigador, en el que todo dise<73>o debe culminar en un producto funcional, y no quedarse solo en las simulaciones. Adicionalmente, es necesario contar con una buena documentaci<63>n que facilite el proceso de adopci<63>n de estos nuevos conocimientos.
Las actividades anteriores pueden garantizar que a corto plazo el pais forme profesionales capaces de realizar dise<73>o de sistemas digitales utilizando metodolog<6F>as de dise<73>o adecuadas y herramientas de dise<73>o moderno, pero para que estos cambios sean adoptados por las industrias debe crearse un v<>nculo con las Universidades para que estas <20>ltimas proporcionen profesionales con las competencias requeridas en el medio. Tambi<62>n es necesario que existan pol<6F>ticas gubernamentales que estimulen el consumo de los productos locales y protejan las industrias que realicen actividades encaminadas al desarrollo tecnol<6F>gico del pais. Adicionalmente es necesario capacitar a las empresas en el uso de nuevas tecnolog<6F>as y en el proceso de producci<63>n masivo, si se desea competir con los productos provenientes del exterior es prioritario que nuestras industrias conozcan estos procesos y donde pueden realizarse.
Como parte del trabajo de esta investigaci<63>n se tom<6F> una empresa reci<63>n formada, con poco capital de inversi<73>n, dedicada al dise<73>o de sistemas digitales y se trabaj<61> con ella en la realizaci<63>n de productos con tecnolog<6F>a de punta,
Por otro lado, aprovechando que la realizaci<63>n de este trabajo coincidi<64> con la re-estructuraci<63>n de todos los programas acad<61>micos de la Universidad Nacional de Colombia, se pudo realizar un cambio total en el contenido de las asignaturas pertenecientes al <20>rea de la electr<74>nica digital, estos cambios est<73>n encaminados a suplir las necesidades de la industria local y los habilidades necesarias para que nuestros profesionales pasen de ser empleados que comercializan productos for<6F>neos a creadores de empresas que desarrollan sus propios productos.
Por <20>ltimo y no menos importante, todo este proceso se realiz<69> utilizando herramientas de libre distribuci<63>n y utilizando una filosof<6F>a adoptada de los movimientos de Software Libre \footnote{http://www.fsf.org/} y hardware abierto\footnote{http://en.wikipedia.org/wiki/Open\_source\_hardware}, en las cuales, en palabras de sus fundadores ``el usuario tiene libertad de ejecutar, copiar, distribuir, estudiar, cambiar y mejorar el software''. En el caso del hardware se suministra informaci<63>n sobre los archivos de dise<73>o: Esquem<65>ticos, lista de materiales, archivos gerber para la fabricaci<63>n de los PCBs y software de configuraci<63>n utilizando herramientas libres. Si queremos que nuestro pais salga del atraso tecnol<6F>gico en el que se encuentra no podemos trabajar en comunidades aisladas dentro de nuestro pais, ni aislados del entorno mundial, es necesario crear una comunidad que aporte conocimientos que sean utilizados por todos. De aqu<71> la importancia de los conceptos de los movimientos de HW y SW libre.
El movimiento de SW libre demostr<74> que es posible generar una cultura en la que los aportes de la comunidadad pueden generar productos de gran calidad, y el secreto de su r<>pido crecimiento es justamente lo que lo diferencia de productos similares: La apertura del c<>digo fuente y la posibilidad de hacer modificaciones. Esta idea revolucionaria, permite que miles de personas alrededor del mundo utilicen el conocimiento requerido para escribir esta aplicaci<63>n de forma directa, y adicionalmente, permite que este conocimiento sea transmitido ya que es posible realizar preguntas a las personas que desarrollaron el producto. Este modelo puede ser utilizado como pol<6F>tica del entorno acad<61>mico e industrial Colombiano para aprovechar de una forma m<>s eficiente, los pocos recursos que suministra el estado para el desarrollo tecnol<6F>gico.
Aprovechando lo posici<63>n provilegiada que tiene la Universidad Nacional de Colombia como el centro de formaci<63>n superior m<>s importante de Colombia, as<61> como el respeto y la credibilidad que tiene el entorno productivo nacional, es posible hacer cambios que tengan un impacto profundo sobre la industria electr<74>nica a corto plazo. Para avanzar en este sentido, el presente trabajo suminstrar<61> la base para generar los cambios en el <20>rea de electr<74>nica digital, estas modificaciones est<73>n encaminadas a crear en nuestros profesionales las habilidades necesarias para la creaci<63>n de empresas con productos que suplen las demandas de la industria local. Adicionalmente, se pone a disposici<63>n de la comunidad interesada, la informaci<63>n necesaria para construir, programar y modificar una plataforma de desarrollo que puede ser utilizada como base para la soluci<63>n de problemas locales, siguiendo la filosof<6F>a del Software y Hardware libre, esta informaci<63>n se encuentra disponible para todo el mundo, y es el punto de partida para la formaci<63>n de una comunidad que coopera para avanzar en el cumplimiento de un objetivo com<6F>n. Sin embargo, estos pasos no son suficientes para que un producto pueda ser comercializado en cantidades relativamente grandes, por lo que es necesario mostrar los pasos que se deben seguir para esto y donde se puede realizar el montaje, en este punto se debe crear una base de datos de fabricantes y de distribuidores de componentes y se deben definir las normas nacionales e internacionales que deben cumplirse para que el producto sea distribuido.
% \subsection{Contribuciones}
% Las contribuciones de este trabajo se resumen a continuaci<63>n:
%
% \begin{itemize}
%
% \item Adopci<63>n y transferencia tecnologica: Con el f<>n de lograr un estado en el que el pa<70>s sea soberano en cuanto a la tecnolog<6F>a que utiliza se estudi<64> profundamente el dise<73>o de Sistemas Embebidos, se implementaron plataformas de desarrollo para las arquitecturas m<>s utilizadas en esta <20>rea, utilizando el sistema operativo GNU-Linux como herramienta de desarrollo.
%
% \item Las plataformas de desarrollo ECB\_AT91 y ECBOT, primeras computadoras en una sola placa (SBC -Single Board Computer) abiertas dise<73>adas en Colombia. La informaci<63>n necesaria para su fabricaci<63>n y utilizaci<63>n hacen parte de este documento. Estas plataformas pueden ser utilizadas como base de aplicaciones comerciales, o como plataforma educativa para la ense<73>anza de Sistemas Embebidos.
%
% \item Una metodolog<6F>a de trabajo que permite compartir el trabajo realizado por diferentes grupos de investigaci<63>n o departamentos de I+D para generar conocimiento que permita que Colombia desarrolle tecnolog<6F>a propia, espec<65>ficamente en el <20>rea de los Sistemas Embebidos. Esta informaci<63>n es el recurso com<6F>n con el que cuentan los miembros de esta ``red'' \footnote{En los movimientos de Hardware y Software libre estas asociaciones reciben el nombre de \textit{comunidades}} y los trabajos de la misma deben estar encaminados a aumentar dichos recursos, por lo que las actividades relizadas deben buscar el bien com<6F>n y no el individual.
%
% \item Se realiz<69> un cambio total en las asignaturas que hacen parte del <20>rea de Electr<74>nica Digital en la universidad m<>s importante del pa<70>s, los contenidos fueron actualizados para que reflejaran el estado de la industria a nivel mundial; Adicionalmente, se cambi<62> el enfoque para que los ingenieros adquieran capacidades que les permitan dar soluciones a problemas reales.
%
% \end{itemize}
% \subsection{Organizaci<63>n}

View File

@@ -0,0 +1,472 @@
\chapter{Introduci<63>n}
\section{Visi<73>n, Paradigmas, y Dificultades}
El gran avance de las t<>cnicas de fabricaci<63>n de Circuitos Integrados ha
permitido que los sistemas digitales sean partes fundamentales de nuestra
vida, a<>n sin darnos cuenta, diariamente interactuamos con ellos,
facilitando las tareas cotidianas. Los niveles de integraci<63>n actuales
permiten construir sistemas cada vez m<>s peque<75>os, veloces y de menor
consumo de potencia, lo cual ha favorecido su difusi<73>n. El uso de los sistemas
digitales en \'<27>reas como la aviaci<63>n, la industria automovil\'{\i}stica, la
bioingenier\'{\i}a, etc. demanda de estos un alto desempe<70>o y un
funcionamiento continuo, el no cumplimiento de estas exigencias traer\'{\i}a
consecuencias desastrosas.
Una de las t\'ecnicas utilizadas actualmente para aumentar la confiabilidad
de un sistema es la redundancia hardware, esta redundancia se logra
adicionando unidades funcionales de reserva, que entrar\'an en operaci\'on
cuando la unidad operativa en un determinado momento falle. Otra t\'ecnica
utilizada es la distribuci\'on de tareas en varias unidades de procesamiento.
Con esto no se depende de la confiabilidad de un sistema complejo y costoso
sino que se dispone de muchas unidades de c\'omputo simples y econ\'omicas;
pero que en conjunto son m\'as robustas que el sistema centralizado. Sin
embargo, contar con varias unidades de procesamiento genera nuevos retos como
la divisi\'on y coordinaci\'on de tareas; la forma de realizar estas funciones
de forma \'optima ha sido el objetivo de muchos estudios, los cuales
contin\'uan hasta hoy.
La tecnolog\'{\i}a de los semiconductores adelanta a la capacidad de
utilizaci\'on por parte de los dise<73>adores, lo cual crea una brecha en la
productividad: cada a<>o, el n\'umero de transistores disponibles aumenta en un
58\% mientras las utilizaci\'on por parte de los dise<73>adores lo hace en un
21\% {\cite{KAK01}}. A medida que aumenta el campo de aplicaci\'on de los
sistemas digitales, lo hacen las exigencias de funcionamiento a ellos
impuestas, nuevos retos en el dise<73>o se presentan a medida que los sistemas
embebidos se integran a nuestra vida diaria, se hace necesario dise<73>ar nuevas
t\'ecnicas que permitan eliminar la brecha en la productividad.
\subsection{Futuro de los Sistemas Computacionales}
\begin{quote}
"The best way to predict the future is to invent it."
Alan Kay
\end{quote}
\subsubsection{Computador Ubicuo}
Observando la tendencia actual de los sistemas electr\'onicos, se puede
especular que el computador tal como lo conocemos actualmente desaparecer\'a
{\cite{WM91}}, ya que estar\'a en todas partes, ubicuo, interactuando con los
seres humanos para realzar el mundo que ellos viven. Se pasar\'a de un esquema
en el que existe un computador para uno o varios usuarios (PC, mainframe) a
uno en el que existan muchos computadores para un usuario. Estos computadores
disponen de grandes capacidades de c\'alculo y de comunicaci\'on, pero a la
vez, poseen un grado de integraci\'on tal que ser\'an invisibles; para aclarar
como se puede lograr esta invisibilidad, imag\'{\i}nense que existen sistemas
embebidos construidos con t\'ecnicas de microfabricaci\'on y que son capaces
de tomar su energ\'{\i}a de fuentes alternas como la temperatura, la
radiaci\'on solar, o a partir de fen\'omenos qu\'{\i}micos, debido a su
reducido tama<6D>o, estos sistemas pueden integrarse a objetos o pintarse sobre
ellos, de tal forma que no sean visibles ante los ojos humanos. Esta
desaparici\'on no solo ser\'a una consecuencia de la tecnolog\'{\i}a, sino de
la sicolog\'{\i}a humana; cuando las personas asimilan perfectamente algo y se
convierte en parte de la vida diaria no se es consciente de su utilizaci\'on.
Por ejemplo, cuando observamos una se<73>al de tr\'ansito capturamos la
informaci\'on sin ser conscientes de la realizaci\'on del acto de la lectura.
\begin{figure}[h]
\begin{center} \includegraphics[scale=.6]{./images/Ubiquitous.jpg} \end{center}
\caption{Concepto de Computador Ubiquo.}
\end{figure}
Hasta el momento el dise<73>o de sistemas tanto software como hardware se ha
centrado en las m\'aquinas, las personas se encargan de crear condiciones
adecuadas de trabajo para ellas. Nos vemos obligados a interactuar con estas
utilizando su propio lenguaje, lo cual dificulta su manejo. En el futuro la
computaci\'on tendr\'a como centro al ser humano, estar\'a en todas partes
dispuesta a ayudarle en sus tareas diarias. No tendr\'an que llevar
computadoras con ellos, se podr\'a interactuar con ellas en cualquier parte a
trav\'es de dispositivos como HandHelds, tel\'efonos celulares, etc no tendremos que
preocuparnos por nuestra privacidad ya que ellas se encargar\'an de eso {\cite{Oxygen}}.
Un nuevo t\'ermino aparece en el escenario del dise<73>o de Sistemas Digitales:
Los \textit{ambientes Inteligentes}, este t\'ermino se utiliza para describir
entornos electr\'onicos sensibles a la presencia de personas, en estos
entornos los usuarios interact\'uan de forma natural con recursos
computacionales que les ayudan a la realizaci\'on de tareas. Es una nueva
\'area de desarrollo que involucra a profesionales en las \'areas de:
Ingenier\'{\i}a Electr\'onica, Ingenier\'{\i}a Mec\'anica, Ciencias de la
computaci\'on, redes y comunicaciones, ciencias sociales y humanistas.
En las siguientes secciones se estudiar\'a el impacto de la computaci\'on
ubicua en el dise<73>o de los sistemas digitales siguiendo los lineamientos de
Marc Weiss {\cite{WM91}} y David Servat {\cite{DS02}}.
\subsubsection{Ambientes Inteligentes.}
En la actualidad, cada vez con m\'as frecuencia, se notan signos de la
invasi\'on digital, por ejemplo, en el aumento de chips embebidos en los
dispositivos que utilizamos a diario. Se ha demostrado {\cite{MW93}} que una
persona que vive en un pa\'{\i}s industrializado se ve confrontada con un
promedio de 40 chips al d\'{\i}a, de los cuales 5 son capaces de comunicarse
en redes. Se estima que dentro de 10 a<>os estaremos en contacto con cientos de
estos chips, la mayor\'{\i}a de los cuales acceden a densas redes de
informaci\'on {\cite{DS02}}, muchos de estos artefactos toman la apariencia de
objetos que utilizamos en nuestra vida diaria (herramientas, vestuario,
electrodom\'esticos, etc) pero son mejorados con sensores, actuadores,
procesadores y software embebido. Una de las razones de la aparici\'on de
estos sistemas es econ\'omica. Las industrias han visto como se muestran
signos de recesi\'on en los mercados tradicionales. Por lo tanto, buscan
nuevos productos en los que pueden ser embebidos chips y software. El
an\'alisis de los procesos de adopci\'on de los dispositivos tecnol\'ogicos de
hoy muestra que la introducci\'on en el mercado de nuevos dispositivos genera
la alteraci\'on o la creaci\'on de nuevos h\'abitos {\cite{DS02}}. Esta
invasi\'on electr\'onica trae consigo una serie de efectos que resultan poco
pr\'acticos e inc\'omodos para sus usuarios humanos:
\begin{itemize}
\item La interacci\'on se realiza utilizando el lenguaje del dispositivo,
este lenguaje no es \'unico, por lo tanto debemos aprender un tipo de
lenguaje para un tipo de aplicaci\'on determinda.
\item Estos dispositivos no pueden comunicarse entre s\'{\i}, por lo que nos
vemos obligados a buscar \textit{traductores} que sirvan de puente
entre ellos.
\item Est\'an construidos para operar en un ambiente determinado, lo cual
nos obliga a movilizarnos con el f\'{\i}n de utilizarlos.
\item No realizan distinci\'on entre usuarios, cada vez que un usuario
diferente los use debe configurar sus preferencias.
\end{itemize}
Los ambientes inteligentes son entornos electr\'onicos que son sensibles y
responden a la presencia de personas {\cite{EA01}}. Est\'an compuestos por
muchos dispositivos distribuidos que interact\'uan con el usuario de forma
natural. El concepto fue construido con base en las ideas de Marc Weiser
{\cite{WM91}}, en {\cite{NRC01}} se puede encontrar un resumen de los
desarrollos y retos recientes en este campo de investigaci\'on. En un ambiente
inteligente, las personas est\'an rodeadas por redes de dispositivos
inteligentes embebidos que proporcionan informaci\'on ubicua, comunicaci\'on,
servicios y entretenimiento {\cite{APaET03}}. Adem\'as, estos dispositivos se
adaptan por si mismos a los usuarios, y anticipan sus necesidades. La
electr\'onica puede integrarse en el vestuario, los muebles, autom\'oviles,
casas, oficinas y sitios p\'ublicos, introduciendo el problema del desarrollo
de nuevos conceptos de interfaz de usuario que permitan la interacci\'on
natural con estos entornos. Las funciones b\'asicas que deben realizar los
ambientes inteligentes son:
\begin{itemize}
\item Conocimiento del entorno.
\item Sistemas inal\'ambricos Distribuidos.
\item Interacci\'on natural con los usuarios.
\end{itemize}
La visi\'on de los ambientes inteligentes es que las aplicaciones ser\'an cada
vez m\'as y m\'as distribuidas y ser\'an ejecutadas en plataformas que
proporcionan recursos de forma din\'amica. Estas aplicaciones deben cumplir
con las funciones mencionadas anteriormente. Los nuevos retos que generan los
ambientes inteligentes al dise<73>o de Sistemas embebidos se pueden dividir en
interacci\'on y adaptaci\'on:
\begin{itemize}
\item Interacci\'on con:
\begin{itemize}
\item las aplicaciones,
\item la plataforma Hardware,
\item otros dispositivos,
\item el usuario.
\end{itemize}
\item Adaptaci\'on:
\begin{itemize}
\item al cambio de aplicaciones y necesidades del usuario,
\item a la cantidad de recursos Hardware,
\item a cambios en el entorno.
\end{itemize}
\end{itemize}
\subsubsection{Consecuencias de la aparici\'on de los sistemas de computaci\'on
ubicua.}
La aparici\'on de la computaci\'on ubicua no es una revoluci\'on, por el
contrario es una consecuencia l\'ogica de la evoluci\'on de las relaciones
entre los usuarios y los sistemas de computadores, los cuales se han
caracterizado por una democratizaci\'on de acceso a los equipos y una
descentralizaci\'on de la infraestructura subyacente. En el primer
per\'{\i}odo (1950-1970) se compart\'{\i}an recursos a trav\'es de terminales,
es decir, se contaba con un computador para muchos usuarios. En los 80s, la
aparici\'on de los computadores personales impulsa la relaci\'on personal
entre los computadores y usuarios. El los 90s la aparici\'on de Internet
permiti\'o compartir recursos a trav\'es de un computador personal. Internet
no es m\'as que un paso adelante hacia la llegada de los sistemas de
computaci\'on ubicua. La misma filosof\'{\i}a de simplificaci\'on y
descentralizaci\'on prevalece hasta hoy y nos conducir\'a a una situaci\'on
donde miles de dispositivos computacionales estar\'an disponibles para
realizar nuestras tareas y se compartir\'an recursos a trav\'es de redes m\'as
intrincadas que Internet. En conclusi\'on se pasar\'a de un esquema en el que
se ten\'{\i}a un computador para muchos usuarios a uno en el que se tienen
muchos (tal vez miles o millares) elementos computacionales para servir a un
usuario.
Estos sistemas ser\'an componentes de una infraestructura computacional que
difiere radicalmente de las que conocemos hoy, y deben poseer las siguientes
caracter\'{\i}sticas:
\begin{itemize}
\item Descentralizados: la centralizaci\'on adem\'as de impr\'actica no
permite que diferentes usuarios puedan controlar sus componentes.
\item Manejar la variaci\'on de su configuraci\'on: debido a la adici\'on o
substracci\'on de sus componentes, o por la forma en que los usuarios los
usan.
\item Estar inmersos en las comunidades humanas con varios tama<6D>os y
necesidades, y operar con informaci\'on incompleta sobre su entorno.
\item Unir combinaciones altamente heterog\'eneas de software y hardware,
las cuales pueden diferir por su funci\'on o por su procesamiento,
comunicaci\'on o capacidades de acci\'on.
\item Ser el resultado de combinaciones de componentes, que pudieron no ser
vistos en tiempo de dise<73>o, sin embargo, producen comportamientos emergentes
interesantes.
\item Adaptarse de forma cont\'{\i}nua a su entorno con el f\'{\i}n de
mejorar su desempe<70>o.
\end{itemize}
El dise<73>o de estos sistemas requiere nuevas fuentes de inspiraci\'on; una
direcci\'on promisoria es verlos y dise<73>arlos como \textit{ecosistemas de agentes f<>sicos} organizados seg\'un principios
biol\'ogicos, qu\'{\i}micos o f\'{\i}sicos {\cite{DS02}}.
\section{Estado del Dise<73>o Electr<74>nico en Colombia}
En la actualidad Colombia atraviesa por una $''$\textit{\textit{crisis}}$''$ a
nivel de dise<73>o de sistemas digitales, existe un atraso muy grande en esta
\'area; a nuestro modo de ver existen dos grandes responsables de esta situaci\'on.
Por un lado, las pol\'{\i}ticas de la mayor\'{\i}a de las industrias al no
realizar inversi\'on de capital en sus departamentos de I+D; algunas de ellas
ni siquiera cuentan con este departamento. Por otro lado, las Universidades no
cuentan con programas actualizados que permitan explotar los avances
realizados en las industrias electr\'onica y de semiconductores; en un gran
n\'umero de Universidades Colombianas a\'un se trabaja con dispositivos de
funci\'on fija como las familias 74 y 40. Los lenguajes de descripci\'on de
hardware han sido adoptados recientemente en la mayor\'{\i}a de programas de
ingenier\'{\i}a electr\'onica, pero en algunos casos no existe una base
metodol\'ogica que soporte su adecuada utilizaci\'on. La disponibilidad de
dispositivos l\'ogicos programables (FPGAs, CPLDs) es limitada debido a la
inexistencia de un proveedor local. Se dedican cursos completos para
$''$ense<73>ar$''$ a programar microprocesadores de 8 bits en lenguaje
ensamblador y muchos educadores a\'un miran con desconfianza a los lenguajes
de alto nivel como el C, C++. En muy pocos programas de Ingenier\'{\i}a
Electr\'onica no se cuenta con una asignatura dedicada a sistemas operativos y
en muchos de ellos no se le da la importancia que tiene la ense<73>anza de
lenguajes estructurados.
La situaci\'on se agrava a\'un m\'as al ver el estado de la relaci\'on entre
la universidad y la industria, la cual no existe en algunos casos. Desde el
punto de vista industrial los resultados obtenidos en la academia parten de
entornos ideales y no se tienen en cuenta las caracter\'{\i}sticas de los
entornos industriales, lo cual da como resultado sistemas poco robustos y con
problemas funcionales. Por otro lado, los tiempos de desarrollos son muy
largos ya que la mayor\'{\i}a de las universidades Colombianas no cuenta
con grupos de investigaci\'on que tengan miembros dedicados de forma
exclusiva al desarrollo de este tipo de proyectos, la mayor\'{\i}a \ de los
miembros de estos grupos son temporales (estudiantes de pregrado) y sin paga,
lo cual no garantiza el cumplimiento ni la continuidad de las investigaciones.
\subsection{Apropiaci<63>n de Conocimiento}
Para que Colombia deje de ser un pa<70>s que consume tecnolog<6F>a y llegue en alg<6C>n momento a ser generador de productos tecnol<6F>gicos, es necesario que se genere un conocimiento que permita esta transici<63>n. ``Para que el conocimiento sea motor de desarrollo es necesario el traspaso desde sus creadores a la sociedad, mediante la conversi<73>n a tecnolog<6F>as que produzcan cambios radicales que incrementen la producci<63>n. Esa transmisi<73>n de tecnolog<6F>a generadora de crecimiento econ<6F>mico esta influenciada por diversos factores: medio geogr<67>fico, leyes de propiedad industrial, costos laborales, nivel de ciencia y tecnolog<6F>a, religi<67>n, tipos de instituciones, resistencia a innovar, pol<6F>ticas de estado, guerras, factores demogr<67>ficos, entre otros'' \cite{Mok90}
Pero como apropiar este conocimiento? Arrow \cite{Arr62} afirma que la apropicaci<63>n de conocimiento puede efectuarse de varias formas: ``aprender haciendo'', ``aprender usando'', ``aprender leyendo''. Cuando una empresa decide transmitir su conocimiento disponible, lo hace en procesos de investigaciones conjuntas, en actividades de producci<63>n, y distribuci<63>n, mercadeo, servicio y soporte operativo o riesgo compartido. Tambi<62>n se presentan alianzas entre firmas como: contratos de I+D, acuerdos de licencias, licencias cruzadas. La conformaci<63>n de estas asociaciones permite crear redes tecnol<6F>gicas dominadas por pa<70>ses industrializados con sus respectivas empresas multinacionales monopolizando conocimiento \cite{Mar04}
Para Colombia, el problema radica en que las empresas de capital nacional no est<73>n adquiriendo el conocimiento necesario para lograr innovaciones al interior de las mismas. De forma que puedan ser competitivas y logren acceder a mercados internacionales ofreciendo productos innovadores, de calidad y a precios competitivos. Con efectos directos como: generaci<63>n de empleos especializados, desarrollo tecnol<6F>gico e industrial sostenido, ampliaci<63>n del acervo de conocimiento nacional y disminuci<63>n de la salida de divisas (al mejorar los procesos de negociaci<63>n) y creaci<63>n de externalidades positivas \cite{Mar04}.
Ligado al problema de la senda tecnol<6F>gica est<73> el del grado de lo t<>cito del conocimiento cient<6E>fico. Teece \cite{Tee81} se<73>ala que al existir conocimiento t<>cito toda la tecnolog<6F>a disponible no se transfiere de los productores a los receptores o compradores de la misma. Por tanto, los pa<70>ses seguidores siempre van a estar a la zaga tecnol<6F>gica. Forbes y Wield \cite{FW00} se<73>alan que los esfuerzos adaptativos son mayores porque deben acomodar las ``innovaciones'' a los materiales locales, fuerza laboral nativa, mercados internos y medio ambiente local. Entonces, el problema no se limita a c<>mo transferir conocimiento, c<>mo develar su parte t<>cita y c<>mo extraerlo de las multinacionales, sino que radica en el bajo poder de negociaci<63>n y adquisici<63>n de tecnolog<6F>a por firmas peque<75>as y medianas, las cuales carecen de recursos y tienen procesos deficientes de contrataci<63>n.
En este orden de ideas, si el pa<70>s no es un innovador neto <20>no deber<65>a m<>s bien mostrar una tendencia a importar conocimiento? Y las firmas nacionales <20>no deber<65>an ser las que m<>s efectuaran este tipo de contratos, para as<61> acceder al conocimiento de la tecnolog<6F>a adquirida? En resumen, conociendo mejor qu<71> tecnolog<6F>a se importa y qu<71> tipos de contratos se utilizan, es posible crear marcos de referencia para empresas nacionales que est<73>n interesadas en adquirir tecnolog<6F>a. Esto producir<69>a externalidades positivas en empresas importadoras de conocimiento y, a su vez, en la econom<6F>a del pa<70>s. Con una adecuada importaci<63>n de conocimientos tecnol<6F>gicos se crear<61>a una ventaja competitiva de car<61>cter estructural, basada en un acervo de conocimiento tecnol<6F>gico que permita incrementar la productividad en todos los sectores econ<6F>micos de manera permanente \cite{Mar04}.
Seg<EFBFBD>n los estudios realizados por Mart<72>nez, con base en registros del Decreto 259/92, del Incomex. La importaci<63>n de conocimiento no est<73> siendo empleada con el prop<6F>sito de utilizar tecnolog<6F>as de punta que permitan efectuar innovaciones al interior de las empresas y de los sectores. Las empresas nacionales se limitan a comprar un determinado dispositivo, sin tener el conocimiento para operarlo, hacerle mantenimiento ni mucho menos mejorarlo, por lo que se ven obligadas a contratar con el vendedor contratos para dicho f<>n. Esto indica que la adquisici<63>n de tecnolog<6F>a no se realiza con base en programa desarrollado de antemano, sino son una respuesta a cambios en el mercado, lo cual evidencia la inexistencia de programas de innovaci<63>n encaminados a la disminuci<63>n de la brecha tecnol<6F>gica.
\subsection{Situaci<63>n de la Industria Electr<74>nica en Colombia}
La industria electr<74>nica nacional no es ajena a las pol<6F>ticas que siguen las empresas nacionales en cuanto a la apropiaci<63>n de tecnolog<6F>a; Colombia depende totalmente de econom<6F>as m<>s desarrolladas para el suministro de dispositivos electr<74>nicos en diversas areas (comunicaciones, entretenimiento, industria, medicina, etc). Mientras en otros sectores de la econom<6F>a han pasado de ser consumidores a exportadores, y adquieren nuevas tecnolog<6F>as para ser m<>s competitivos, el sector electr<74>nico del pa<70>s ha reducido sus actividades de Investigaci<63>n y Desarrollo hasta el punto de depender totalmente de productos externos, de los cuales, algunos son de baja calidad y no suplen los requerimientos del mercado local, pero son utilizados porque son muy econ<6F>micos.
En la actualidad la industria electr<74>nica presenta una gran din<69>mica a nivel mundial, el uso de los sistemas electr<74>nicos se extiende a todas las actividades humanas; La demanda mundial de este tipo de sistemas aumentar<61> de forma dram<61>tica en los pr<70>ximos a<>os, especialmente en los sectores de tecnolog<6F>a m<>dica, movilidad, seguridad, comunicaciones y consumo \cite{ETPoSSI(09}. El mercado de los sistemas embebidos es una industria que movi<76> alrededor de 25 billones de d<>lares en el 2008 seg<65>n Venture Development Corporation \cite{Vc08}. Por otro lado, la inversi<73>n de capital necesaria para el dise<73>o de Sistemas Embebidos es relativamente baja, gracias a la gran demanda originada, los insumos y los servicios de fabricaci<63>n son muy econ<6F>micos, las herramientas de desarrollo necesarias para la programaci<63>n y depuraci<63>n de este tipo de sistemas son de libre distribuci<63>n.
Desafortunadamente en Colombia la industria electr<74>nica se encuentra muy rezagada en relaci<63>n a las de los pa<70>ses industrializados, y las ventajas y oportunidades de negocios mencionadas anteriormente no son aprovechadas en la actualidad.
Seg<EFBFBD>n ASESEL \footnote{Asociaci<63>n de entidades del Sector Electr<74>nico} en el 2001 exist<73>an 154 empresas productoras de componentes y equipos de la cadena electr<74>nica. Dentro de los productos que la industria electr<74>nica exporta se encuentran registrados: Circuitos integrados, circuitos impresos, microestructuras, instrumentos para medida y control, Instrumentos y aparatos el<65>ctricos o electr<74>nicos. Es importante decir que la industria colombiana, en la actualidad no fabrica circuitos integrados, ni microestructuras, por lo que estas son ventas de productos comprados en pa<70>ses desarrollados. Seg<65>n Proexport el 91\% de las exportaciones son realizadas por Bogot<6F> y los destinos se encuentran en pa<70>ses cercanos como Venezuela, Per<65>, Ecuador y USA.
La electr<74>nica en Colombia y en el mundo hace parte de esas industrias que se mueven velozmente en un
camino desconocido, como consecuencia se hace necesario tener una actualizaci<63>n constante de los
avances tecnol<6F>gicos y las proyecciones futuras del sector. Debido a la importancia del sector tecnol<6F>gico es primordial que en Colombia se est<73> consciente del estado actual y que se puede hacer en t<>rminos de
Investigaci<EFBFBD>n Cient<6E>fica y Desarrollo Tecnol<6F>gico (I+D) en Ingenier<65>a Electr<74>nica.
Un estudio realizado en la Universidad Nacional de Colombia \cite{MTRR07} identific<69> los siguientes obst<73>culos para el desarrollo de la industria electr<74>nica en Colombia: Deficientes relaciones Universidad Empresa, Pobre enfoque acad<61>mico hacia la industria, baja calidad de los productos nacionales, pol<6F>ticas gubernamentales, falta de cultura de Investigaci<63>n y Reducida apropiaci<63>n tecnol<6F>gica, competencia de pa<70>ses asi<73>ticos, atraso tecnol<6F>gico, limitado recurso humano con formaci<63>n avanzada.
De los problemas expuestos anteriormente podemos identificar cuales son los que m<>s afectan el desarrollo de la industria electr<74>nica en Colombia, el que m<>s perjudica sin lugar a dudas es el atraso tecnol<6F>gico, no es posible ser competitivo en el mercado electr<74>nico mundial con tecnolog<6F>as y metodolog<6F>as de dise<73>o obsoletas. \footnote{En Colombia trabajamos a<>n con circuitos integrados que se crearon en la decada de los 80 del siglo pasado y utilizamos lenguajes de programaci<63>n como el \textit{assembler}, para el cual el tiempo de aprendizaje, desarrollo y de depuraci<63>n es muy largo} La culpa de este atraso tecnol<6F>gico no es exclusiva de la industria, aunque, como vimos anteriormente muchas industrial Colombianas se resisten al cambio y prefieren comprar equipos en el exterior a buscarlos localmente, la falta de confiabilidad en los productos Colombianos agrava este problema, esta falta de confianza en la industria local no es infundada, la mayor<6F>a de los productos Colombianos no cumplen con las normas m<>nimas de calidad y utilizan productos de bajo costo obtenidos en remates de componetes.
Otro actor que contribuye al retraso tecnol<6F>gico es el sector acad<61>mico; Seg<65>n el Sistema Nacional de Informaci<63>n Superior, durante los <20>ltimos 10 a<>os se han abierto 230 programas relacionados con la industria electr<74>nica, estos programas est<73>n repartidos entre programas de formaci<63>n Universitaria, tecnol<6F>gica terminal y de t<>cnica profesional, la mayor<6F>a de estos centros de formaci<63>n se encuentran ubicados en 3 Departamentos: Bogot<6F>, Antioquia y Valle \cite{DZSC+07}. El n<>mero de Ingenieros graduados en un a<>o es entre 2 y 8 veces mayor que en los pa<70>ses en v<>a de desarrollo y doce veces mayor que los que se grad<61>an en los pa<70>ses desarrollados. En Colombia, este aumento es aportado por instituciones de poca consolidaci<63>n; adem<65>s, las preferencias en la educaci<63>n superior son Formaci<63>n t<>cnica / form. tecnol<6F>gica / form. profesional que es justamente lo opuesto a la de los pa<70>ses desarrollados \cite{MDAG99}.
Por otro lado, el contenido de las asignaturas relacionadas directamente con la industria electr<74>nica se encuentran muy desactualizados, y fuera del contexto mundial, se utilizan metodolog<6F>as de dise<73>o antiguas en las que primaba la experiencia del dise<73>ador, se realizan tareas manuales, repetitivas que pueden ser realizadas por herramientas de dise<73>o moderno, los curr<72>culos son conservadores hay poca experimentaci<63>n y su estructuraci<63>n y metodolog<6F>as son muy cl<63>sicas. Adicionalmente, muchos investigadores dedican sus estudios en proyectos que no aportan al desarrollo del pa<70>s <20>nicamente porque est<73>n de moda. Otro problema adicional radica en la falta de experiencia en el sector productivo por parte del personal acad<61>mico, un componente importante de los profesores nunca han sido parte de un proceso productivo o de un proceso de desarrollo que tenga como f<>n la creaci<63>n de un producto comercial, raz<61>n por la cual se evita la experimentaci<63>n y se da m<>s <20>nfasis al an<61>lisis y solo se llega a una simulaci<63>n.
De lo anterior podemos concluir que en Colombia se presenta una sobre-oferta de profesionales en el <20>rea electr<74>nica, muchos de los cuales provienen de instituciones educativas con poca consolidaci<63>n, y que han sido formados con programas desactualizados que no tienen en cuenta los avances tecnol<6F>gicos y metodol<6F>gicos, lo cual explica la pobreza de ingenieros con altos niveles de formaci<63>n. Por esta raz<61>n no es de extra<72>ar la poca confianza que tienen los industriales en los productos nacionales.
Lo anterior unido a la falta de pol<6F>ticas de estado que: tracen normas encaminadas a incentivar la inversi<73>n en investigaci<63>n y desarrollo, defina l<>neas y campos de investigaci<63>n, regule la oferta laboral y los programas acad<61>micos, generan el clima perfecto para que el atraso tecnol<6F>gico se mantenga durante mucho tiempo y Colombia no deje de ser un consumidor de tecnolog<6F>a. Seg<65>n John Kao, uno de los grandes expertos del mundo en innovaci<63>n, los pa<70>ses desarrollados no invierten en Ciencia Tecnolog<6F>a e Innovaci<63>n (CTI) porque son ricos, sino que son ricos porque invierten en CTI.
\subsubsection{Tecnolog<6F>as de Informaci<63>n y Comunicaci<63>n}
En la actualidad existe un especial inter<65>s por parte del gobierno \footnote{ La Agenda de Conectividad es el programa del Ministerio de Comunicaciones, encargado de impulsar el uso y masificaci<63>n de las Tecnolog<6F>as de Informaci<63>n y Comunicaci<63>n -TIC- como herramienta dinamizadora del desarrollo social y econ<6F>mico del pa<70>s ()} en impulsar las Tecnolog<6F>as de la Informaci<63>n y la Comunicaci<63>n (TIC). Este programa no debe centrarse en solo difundir el uso de internet y aumentar el n<>mero de personas que tienen acceso a un computador. ``La tecnolog<6F>a es simplemente la infraestructura, si la infraestructura no est<73> acompa<70>ada por la creaci<63>n de habilidades y conocimiento la adopci<63>n de TICs no ayudar<61> a obtener los beneficios que esperamos, sin embargo, ayudar<61>n con los intereses de los m<>s poderosos y de las naciones m<>s ricas.'' \footnote{Brito Lidia, ``Enabling Environment, ICT for Development and the Millennium Development Goals'',p<>gina 20, 2005}. Las TICs deben utilizar la educaci<63>n como pricipal herramienta para reducir la \textit{brecha tecnol<6F>gica} que existe entre las diferentes regiones de nuestro pa<70>s y de nuestro pa<70>s con los paises desarrollados.
Hearn, Simpson, Lennie y Kimber \cite{HSL+04} \cite{MJF05} nombran las siguientes caracter<65>sticas para que las TICs contribuyan con el desarrollo regional.
\begin{enumerate}
\item Conseguir claridad en especificar objetivos sostenibles, las regiones no se
pueden dar el lujo de esperar a que todo les sea entregado y listo, ponerlo a
funcionar, debe existir un plan para evitar que la tecnolog<6F>a se vuelva
obsoleta y se acabe el proyecto por esta causa.
\item Apalancar el desarrollo de la empresa peque<75>a ayudado por personal y
financiaci<63>n del gobierno y utilizando las fortalezas de las industrias locales.
\item Construir basado en las industrias fuertes locales; Aprender de las
experiencias globales mientras que se construye en acciones locales
\item Encontrar innovadores modelos de negocios para aprovecharlos en nuevas
oportunidades de contenidos y aplicaciones.
\item Asegurar el envolvimiento de la comunidad en la decisi<73>n, planeaci<63>n y
evaluaci<63>n de proyectos. Hemos visto que para que un proyecto de
tecnolog<6F>a tenga <20>xito se debe involucrar a la sociedad civil, a ellos deben ir
dirigidos los principales beneficios, deben ser ellos quienes se capaciten y
de esta forma el proyecto va a funcionar.
\item Adoptar una metodolog<6F>a de aprendizaje a trav<61>s de ciclos de evaluaci<63>n
basados en una acci<63>n investigativa.
\end{enumerate}
Adicionalmente es necesario buscar el bien com<6F>n por encima del individual, raz<61>n por la cual debemos preguntarnos quienes son los favorecidos por la difusi<73>n de estas tecnolog<6F>as, no tiene sentido invertir grandes sumas de dinero para llevar estas tecnolog<6F>a a lugares donde no saben como utilizarlas y m<>s a<>n, en lugares donde las necesidades b<>sicas no han sido resueltas. Es importante pensar en las personas a las que se va a beneficiar y preparar el camino para que el impacto sea mayor, sin educaci<63>n y sin entrenamiento no se le puede sacar provecho a estas tecnolog<6F>as. Debemos crear herramientas que integren a nuestros pueblos y que permitan colaborar entre ellas.
En la actualidad esta pol<6F>tica gubernamental se limita a comprar software propietario normalmente el sistema operativo MicroSoft Windows y aplicaciones del mismo fabricante como su suite Office y MSN. Esto no aporta absolutamente nada al desarrollo tecnol<6F>gico del pa<70>s ya que al ser un sistema operativo cerrado no es posible modificarlo o aprender sobre su funcionamiento, el usuario debe limitarse a aceptar lo que el fabricante le entrega y si quiere desarrollar apliaciones propias debe pagar por las herramientas de desarrollo y por la documentaci<63>n. Microsoft utiliza una pol<6F>tica de reducci<63>n de precios para los centros educativos y algunos centros gubernamentales, esta ``donaci<63>n'' solo crea dependencia tecnol<6F>gica y en la mayor<6F>a de los casos promueve acciones ilegales ya que (el costo de estos productos son los mismos en todo el mundo y en muchas ocasiones cuestan m<>s que el computador sobre el que se ejecuta) los usuarios obtienen software ilegal, pr<70>ctica que se generaliza a todo el software no solo al de Microsoft lo que hace que las empresas medianas y peque<75>as locales sean forzadas a cerrar sus negocios. Por otro lado, al permitir que solo una empresa extranjera sea la que decide sobre el futuro del software utilizado en la mayor<6F>a de los computadores de una naci<63>n se est<73> cediendo la soberan<61>a para el beneficio de un particular for<6F>neo.
Lo mismo sucede con los equipos que se utilizan para acceder a estas tecnolog<6F>as, en la mayor<6F>a de los casos son fabricados en paises con diferentes culturas y diferentes necesidades. Es obvio que el pa<70>s no puede fabricar ciertos equipos que se requieren para poder llevar estas tecnolog<6F>as a las diferentes regiones, sin embargo, este trabajo proporciona una base s<>lida sobre la cual se puede desarrollar un producto similar al propuesto por el proyecto del MIT OLPC (One Laptop For Child), el cual busca construir un dispositivo de muy bajo costo (200 USD) que permita a los estudiantes y a la comunidad en general, aprender los conceptos b<>sicos para poder utilizar estas tecnolog<6F>as. De esta forma impulsamos la industra electr<74>nica produciendo de forma masiva un dispositivo electr<74>nico en el pais, dise<73>ado para suplir necesidades de la regi<67>n. Esta plataforma no solo poroporcionar<61> la base para el desarrollo de las TICs, sino la base tecnol<6F>gica sobre la cual se pueden desarrollar muchas soluciones a problemas de la industria local.
Es posible incluir el presente estudio en dicho programa de tal forma que el objetivo final de este programa no sea aumentar la venta de licencias de un determinado sistema Operativo o el n<>mero de computadores con acceso a internet, sino desarrollar en el pais la tecnolog<6F>a necesaria para que las universidades y empresas locales sean capaces de desarrollar dispositivos que permitan el acceso a estas tecnolog<6F>as.
\subsection{Estado de la Electr<74>nica Digital en la Universidad Nacional de Colombia}
Hasta hace un a<>o en las asignaturas del <20>rea de electr<74>nica digital de la Universidad Nacional de Colombia (La Universidad p<>blica m<>s grande e importante del pais), se trabajaba con dispositivos que fueron sacados al mercado en 1966 y 1968, las familia l<>gica TTL 7400 y CMOS 4000. El problema principal al utilizar esta tecnolog<6F>a no es su a<>o de creaci<63>n, ni siquiera que en la actualidad se consideren obsoletas para el dise<73>o de un sistema digital completo. \footnote{En la actualidad estas compuertas se utilizan para la implementaci<63>n de peque<75>as operaciones l<>gicas} El problema detr<74>s del uso de esta tecnolog<6F>a se encuentra en la ausencia total de metodolog<6F>as de dise<73>o (en el caso Colombiano). Y el desconocimiento en herramientas tipo CAD. El proceso de dise<73>o que realizaban los estudiantes era:
\begin{enumerate}
\item Especificaciones del sistema.
\item Generaci<63>n manual de ecuaciones boolenas.
\item Minimizaci<63>n manual utilizando mapas de Karnaugh.
\item Implementaci<63>n de las ecuaciones minimizadas utilizando las familias l<>gicas 7400 y 4000, sobre placas de pruebas (protoboards, breadboards)
\item Pruebas del sistema.
\end{enumerate}
A manera de ejercicio acad<61>mico se justifica el uso de las familias 7400 y 4000, sin embargo, el quedarse ahi no es bueno para una industria electr<74>nica desactualizada, debido a que este tipo de implementaciones no pueden generar productos competitivos a nivel mundial. La raz<61>n de esto es que existen muchas fuentes de error en el proceso, generados por la ausencia de herramientas CAD que realicen las operaciones tediosas como las minimizaci<63>n de ecuaciones booleanas, las cuales est<73>n sujetas a errores humanos originados por cansancio, falta de concentraci<63>n, etc. Otro aspecto que vale la pena resaltar es la falta de una simulaci<63>n funcional, la mayor<6F>a de los estudiantes consultados no realizaban simulaciones funcionales y prefer<65>an probar el dise<73>o una vez implementado f<>sicamente, esto unido a la dificultad de depuraci<63>n innata a este tipo de implementaciones, aumentaba considerablemente el tiempo requerido para realizar la implementaci<63>n y pruebas del sistema.
En el segundo curso del <20>rea de electr<74>nica digital, se introduce al estudiante al uso de los dispositivos l<>gicos programables (PLD) y los lenguajes de descripci<63>n de hardware (HDL) como herramientas para el dise<73>o de sistemas digitales, al comienzo, el contenido de estos cursos se limitaba al uso de una herramienta de dise<73>o y la ense<73>anza de nociones b<>sicas del lenguaje VHDL, se daba m<>s importancia al uso de la herramienta y no a la metodolog<6F>a de dise<73>o, de nuevo el estudiante ataca los problemas sin una metodolog<6F>a de dise<73>o clara. Vale la pena indicar que este curso fue dictado por profesores ocasionales durante los <20>ltimos cuatro a<>os, cada profesor utilizaba contenidos y niveles de exigencia diferentes.
En la tercera parte del curso se trabaja con sistemas microcontrolados, se utilizan microcontroladores de 8 bits de diferentes familias y se utiliza el lenguaje ensamblador como herramienta de desarrollo. Una de las principales desventajas que presenta este curso (y de la l<>nea en general) es la falta de continuidad en los contenidos y en la metodolog<6F>a utilizada, ya que el contenido de este curso se encuentra totalmente desligado al de los dos anteriores. Sin embargo, durante este curso se proporciona una metodolog<6F>a de dise<73>o en la que los estudiantes emulan el comportamiento del microcontrolador antes de ser programado, sin embargo, esta pr<70>ctica no es seguida por la mayor<6F>a de los estudiantes, una posible causa de este comportamiento puede ser la falta de metodolog<6F>as de dise<73>o en los cursos anteriores.
La sensaci<63>n que queda al terminar el <20>rea de electr<74>nica digital es que lo <20>nico que importa son los microcontroladores y que lo visto en los primeros cursos no es muy <20>til. La siguiente tabla muestra los problemas encontrados en el <20>rea de electr<74>nica digital de las carreras de Ingenier<65>a El<45>ctrica y Electr<74>nica de la Universidad Nacional de Colombia:
\begin{enumerate}
\item Falta de una metodolog<6F>a de dise<73>o.
\item Utilizaci<63>n de herramientas obsoletas: Familias L<>gicas, lenguajes de programaci<63>n.
\item Poco uso de las herramientas CAD.
\item Falta de continuidad en las asignaturas.
\item Falta de docentes.
\item No se suministra una formaci<63>n adecuada que ayude a la industria electronica a salir del retraso tecnol<6F>gico.
\end{enumerate}
\section{Descripci<63>n de la T<>sis}
\subsection{Objetivos e Hip<69>tesis}
\subsubsection{Ojetivo Principal}
Desarrollar una metodolog<6F>a para la transferencia tecnol<6F>gica y de conocimientos en el <20>rea de Sistemas Embebidos.
El objetivo de este trabajo es contribuir a dar soluci<63>n al problema del atraso tecnol<6F>gico en Colombia, puntualmente en los siguientes puntos:
\subsubsection{Objetivos Secundarios}
\begin{itemize}
\item Formulaci<63>n de una metodolog<6F>a para la transferencia tecnol<6F>gica y de conocimientos en el <20>rea de Sistemas Embebidos en Colombia.
\item Formulaci<63>n de una metodolog<6F>a de Dise<73>o y producci<63>n para Sistemas Embebidos aplicable en el entorno local.
\item Identificaci<63>n de las habilidades requeridas para los profesionales y t<>cnicos en la Industria Electr<74>nica para estar acorde con la tendencia de la industria electr<74>nica mundial y formulaci<63>n de recomenadaciones para la industria y los organismos gubernamentales encaminadas a mejora la productividad de la industria electr<74>nica del pa<70>s.
\item Desarrollo de Plataformas Hardware que utilicen tecnolog<6F>a de punta.
\item Dise<73>o de los programas de las asignaturas del <20>rea de electr<74>nica digital en programas de pregrado para incorporar las nuevas metodolog<6F>as modernas de dise<73>o y producci<63>n.
\end{itemize}
\subsubsection{Hip<69>tesis}
Las recomendaciones dadas por los estudios sobre como solucionar el problema del desarrollo tecnol<6F>gico, hablan de como se debe trabajar de forma local, teniendo en cuenta la experiencia generada globalmente, Por lo que partiemos de la hip<69>tesis que es posible utilizar t<>cnicas de auto-organizaci<63>n para que diferentes centros de formaci<63>n y producci<63>n distribuidos a lo largo del pa<70>s encuentren la forma de distribuir de forma eficiente los recursos (Informaci<63>n, conocimiento, recursos econ<6F>micos) comunes para alcanzar en forma conjunta el objetivo principal: Encontrar pol<6F>ticas de auto-gobierno que permitan el beneficio de la comunidad.
\subsection{Aproximaciones}
El problema del atraso tecnol<6F>gico en Colombia debe ser atacado desde varios flancos para que pueda ser resuelto de forma efectiva. Como se indic<69> anteriormente solo con el trabajo conjunto de la industria, la academia y las politicas gubernamentales podremos avanzar en la soluci<63>n del problema. El trabajo realizado ac<61> solo puede contribuir a la soluci<63>n del problema con soluciones encaminadas a la industria y la academia.
Porqu<EFBFBD> se eligi<67> el <20>rea de dise<73>o de sistemas digitales para atacar el problema del atraso tecnol<6F>gico? B<>sicamente porque este sector es el que presenta un mayor retraso en el pais, adicionalmente, muchas <20>reas del conocimiento (como control, instrumentaci<63>n, medici<63>n, comunicaciones, rob<6F>tica, etc) se apoyan en dispositivos digitales como herramientas para implementar aplicaciones. Por otro lado, existe una gran demanda de productos especializados con capacidades de comunicaci<63>n especiales y de procesamiento, tanto en el mercado de productos de consumo (Entretenimiento, electrodim<69>sticos, etc), como en el mercado de productos espscializados (Sistemas de control, sistemas de medici<63>n, etc).
Para que el estudio realizado tenga un mayor impacto se deben evitar temas en los que se requieran grandes inversiones en infra-estructuras como por ejemplo dise<73>o y fabricaci<63>n de Circuitos Integrados o aplicaciones en nanotecnolog<6F>a, ya que los laboratorios necesarios son muy costosos y en el pa<70>s no existe a<>n la demanda suficiente que sostenga los costos de funcionamiento de este tipo de procesos. Teniendo en cuenta esto, existen varias alternativas en las que el pa<70>s podr<64>a llegar a ser competitivo a corto plazo y generar productos que compitan con los ofrecidos por industrias de pa<70>ses desarrollados, estas son:
\begin{itemize}
\item Desarrollo de n<>cleos de Propiedad Intelectual (IPs)
\item Desarrollo de dispositivos dedicados a resolver problemas espec<65>ficos utilizando dispositivos semiconductores ya existentes.
\begin{itemize}
\item Dise<73>o de plataformas de Desarrollo Hardware robustas.
\item Creaci<63>n de plataformas de desarrollo software estables.
\item Desarrollo de aplicaciones basadas en las plataformas de desarrollo ya creadas.
\end{itemize}
\item Desarrollo de aplicaciones HW/SW para que sean fabricadas en otros pa<70>ses con mayor oferta en servicios de manufactura.
\end{itemize}
Los sistemas embebidos proporcionan una visi<73>n completa del proceso de producci<63>n de nuevos dispositivos: Concepci<63>n, Dise<73>o, Implementaci<63>n y Operaci<63>n, adicionalmente es un mercado que mueve miles de millones de D<>lares al a<>o y su campo de acci<63>n abarca casi todas las actividades humanas (Educaci<63>n, entrtenimiento, transporte, salud, productividad), existe una infinidad de herramientas Hardware (Procesadores, SoCs, FPGAs, dise<73>os de referencia, herramientas CAD) y Software (Compiladores, depuradores, librer<65>as, Sistemas Operativos, Aplicaciones) y una gran din<69>mica en la industria que proporciona servicios de manufactura (suministro de componentes, fabricaci<63>n, pruebas, distribuci<63>n). Lo que permite ingresar a este mercado con bajas inversiones de dinero, lo que es ideal para la situaci<63>n actual del pa<70>s (baja inversi<73>n en I+D), y es perfecta para que reci<63>n egresados puedan crear nuevos productos y servicios utilizando sistemas embebidos.
Para asegurar que existan profesionales capaces de utilizar los nuevos conocimientos es necesario crear cursos de actualizaci<63>n a diferentes niveles: Cursos de capacitaci<63>n, Diplomados, L<>neas de profundizaci<63>n en pregrado y posgrado; Modificar el contenido de las asignaturas de las materias relacionadas con la electr<74>nica digital para actualizar sus contenidos y las metodolog<6F>as de dise<73>o adecuadas, tambien es necesario un cambio en el enfoque, debemos pasar de un perfil anal<61>tico a un perfil de dise<73>ador-investigador, en el que todo dise<73>o debe culminar en un producto funcional, y no quedarse solo en las simulaciones. Adicionalmente, es necesario contar con una buena documentaci<63>n que facilite el proceso de adopci<63>n de estos nuevos conocimientos.
Las actividades anteriores pueden garantizar que a corto plazo el pais forme profesionales capaces de realizar dise<73>o de sistemas digitales utilizando metodolog<6F>as de dise<73>o adecuadas y herramientas de dise<73>o moderno, pero para que estos cambios sean adoptados por las industrias debe crearse un v<>nculo con las Universidades para que estas <20>ltimas proporcionen profesionales con las competencias requeridas en el medio. Tambi<62>n es necesario que existan pol<6F>ticas gubernamentales que estimulen el consumo de los productos locales y protejan las industrias que realicen actividades encaminadas al desarrollo tecnol<6F>gico del pais. Adicionalmente es necesario capacitar a las empresas en el uso de nuevas tecnolog<6F>as y en el proceso de producci<63>n masivo, si se desea competir con los productos provenientes del exterior es prioritario que nuestras industrias conozcan estos procesos y donde pueden realizarse.
Como parte del trabajo de esta investigaci<63>n se tom<6F> una empresa reci<63>n formada, con poco capital de inversi<73>n, dedicada al dise<73>o de sistemas digitales y se trabaj<61> con ella en la realizaci<63>n de productos con tecnolog<6F>a de punta,
Por otro lado, aprovechando que la realizaci<63>n de este trabajo coincidi<64> con la re-estructuraci<63>n de todos los programas acad<61>micos de la Universidad Nacional de Colombia, se pudo realizar un cambio total en el contenido de las asignaturas pertenecientes al <20>rea de la electr<74>nica digital, estos cambios est<73>n encaminados a suplir las necesidades de la industria local y los habilidades necesarias para que nuestros profesionales pasen de ser empleados que comercializan productos for<6F>neos a creadores de empresas que desarrollan sus propios productos.
Por <20>ltimo y no menos importante, todo este proceso se realiz<69> utilizando herramientas de libre distribuci<63>n y utilizando una filosof<6F>a adoptada de los movimientos de Software Libre \footnote{http://www.fsf.org/} y hardware abierto\footnote{http://en.wikipedia.org/wiki/Open\_source\_hardware}, en las cuales, en palabras de sus fundadores ``el usuario tiene libertad de ejecutar, copiar, distribuir, estudiar, cambiar y mejorar el software''. En el caso del hardware se suministra informaci<63>n sobre los archivos de dise<73>o: Esquem<65>ticos, lista de materiales, archivos gerber para la fabricaci<63>n de los PCBs y software de configuraci<63>n utilizando herramientas libres. Si queremos que nuestro pais salga del atraso tecnol<6F>gico en el que se encuentra no podemos trabajar en comunidades aisladas dentro de nuestro pais, ni aislados del entorno mundial, es necesario crear una comunidad que aporte conocimientos que sean utilizados por todos. De aqu<71> la importancia de los conceptos de los movimientos de HW y SW libre.
El movimiento de SW libre demostr<74> que es posible generar una cultura en la que los aportes de la comunidadad pueden generar productos de gran calidad, y el secreto de su r<>pido crecimiento es justamente lo que lo diferencia de productos similares: La apertura del c<>digo fuente y la posibilidad de hacer modificaciones. Esta idea revolucionaria, permite que miles de personas alrededor del mundo utilicen el conocimiento requerido para escribir esta aplicaci<63>n de forma directa, y adicionalmente, permite que este conocimiento sea transmitido ya que es posible realizar preguntas a las personas que desarrollaron el producto. Este modelo puede ser utilizado como pol<6F>tica del entorno acad<61>mico e industrial Colombiano para aprovechar de una forma m<>s eficiente, los pocos recursos que suministra el estado para el desarrollo tecnol<6F>gico.
Aprovechando lo posici<63>n provilegiada que tiene la Universidad Nacional de Colombia como el centro de formaci<63>n superior m<>s importante de Colombia, as<61> como el respeto y la credibilidad que tiene el entorno productivo nacional, es posible hacer cambios que tengan un impacto profundo sobre la industria electr<74>nica a corto plazo. Para avanzar en este sentido, el presente trabajo suminstrar<61> la base para generar los cambios en el <20>rea de electr<74>nica digital, estas modificaciones est<73>n encaminadas a crear en nuestros profesionales las habilidades necesarias para la creaci<63>n de empresas con productos que suplen las demandas de la industria local. Adicionalmente, se pone a disposici<63>n de la comunidad interesada, la informaci<63>n necesaria para construir, programar y modificar una plataforma de desarrollo que puede ser utilizada como base para la soluci<63>n de problemas locales, siguiendo la filosof<6F>a del Software y Hardware libre, esta informaci<63>n se encuentra disponible para todo el mundo, y es el punto de partida para la formaci<63>n de una comunidad que coopera para avanzar en el cumplimiento de un objetivo com<6F>n. Sin embargo, estos pasos no son suficientes para que un producto pueda ser comercializado en cantidades relativamente grandes, por lo que es necesario mostrar los pasos que se deben seguir para esto y donde se puede realizar el montaje, en este punto se debe crear una base de datos de fabricantes y de distribuidores de componentes y se deben definir las normas nacionales e internacionales que deben cumplirse para que el producto sea distribuido.
% \subsection{Contribuciones}
% Las contribuciones de este trabajo se resumen a continuaci<63>n:
%
% \begin{itemize}
%
% \item Adopci<63>n y transferencia tecnologica: Con el f<>n de lograr un estado en el que el pa<70>s sea soberano en cuanto a la tecnolog<6F>a que utiliza se estudi<64> profundamente el dise<73>o de Sistemas Embebidos, se implementaron plataformas de desarrollo para las arquitecturas m<>s utilizadas en esta <20>rea, utilizando el sistema operativo GNU-Linux como herramienta de desarrollo.
%
% \item Las plataformas de desarrollo ECB\_AT91 y ECBOT, primeras computadoras en una sola placa (SBC -Single Board Computer) abiertas dise<73>adas en Colombia. La informaci<63>n necesaria para su fabricaci<63>n y utilizaci<63>n hacen parte de este documento. Estas plataformas pueden ser utilizadas como base de aplicaciones comerciales, o como plataforma educativa para la ense<73>anza de Sistemas Embebidos.
%
% \item Una metodolog<6F>a de trabajo que permite compartir el trabajo realizado por diferentes grupos de investigaci<63>n o departamentos de I+D para generar conocimiento que permita que Colombia desarrolle tecnolog<6F>a propia, espec<65>ficamente en el <20>rea de los Sistemas Embebidos. Esta informaci<63>n es el recurso com<6F>n con el que cuentan los miembros de esta ``red'' \footnote{En los movimientos de Hardware y Software libre estas asociaciones reciben el nombre de \textit{comunidades}} y los trabajos de la misma deben estar encaminados a aumentar dichos recursos, por lo que las actividades relizadas deben buscar el bien com<6F>n y no el individual.
%
% \item Se realiz<69> un cambio total en las asignaturas que hacen parte del <20>rea de Electr<74>nica Digital en la universidad m<>s importante del pa<70>s, los contenidos fueron actualizados para que reflejaran el estado de la industria a nivel mundial; Adicionalmente, se cambi<62> el enfoque para que los ingenieros adquieran capacidades que les permitan dar soluciones a problemas reales.
%
% \end{itemize}
% \subsection{Organizaci<63>n}

View File

@@ -0,0 +1,349 @@
Es necesario transferir todos los componentes de la tecnolog<6F>a para una efectiva transferenica.
En conclusi<73>n con la venta de equipos se transmite <20>nicamente el conocimiento para operar, programar o mantener, sin embargo,
este conocimiento sobre el sistema puede ayudar a concientizarse sobre la tecnolog<6F>a e impulsar la formaci<63>n de capital humano.
La transferencia tecnol<6F>gica incluye la difusi<73>n de conocimiento cient<6E>fico y la preocupaci<63>n por la transformaci<63>n del conocimiento en
innovaciones <20>tiles
La transferencia tecnol<6F>gica no ocurre cuando estudiantes formados en el exterior no pueden aplicar sus conocimientos en su pa<70>s de origen,
por lo que es necesario crear pol<6F>ticas que definan que <20>reas de estudio son prioritarias para el pa<70>s. Adicionalmente, existen centros privados
de capacitaci<63>n que ofrecen cursos para el manejo de paquetes y lenguajes de
programaci<EFBFBD>n, estos centros aprovechan la falta de centros de ense<73>anza tecnol<6F>gica y personal calificado para cobrar altas sumas de dinero,
lo cual limita el acceso
no es bueno confiar a consultores externos la responsabilidad
de construir habilidades locales, ya que reduce el desarrollo de estas habilidades, especialmente, la del personal encargado de manejar proyectos
El licenciamiento es un canal que se utiliza para transferencia de know-how sobre productos o procesos, es aplicado de forma individual o en
combinaci<EFBFBD>n con otros instrumentos como investigaci<63>n extranjera, importaci<63>n de maquinaria o de t<>cnicos. Sin embargo, no es efectivo si no
se acompa<70>a de habilidades administrativas y de producci<63>n. Adicionalmente, es necesario contar con una infraestructura tecnol<6F>gica adecuada,
capacidades locales de fabricaci<63>n de hardware y software y pol<6F>ticas de gobierno adecuadas.
Toda pol<6F>tica debe contar con formas de medir la transferencia exitosa. Uno de los indicadores de <20>xito es la transferencia de habilidades.
Muchos pa<70>ses en v<>a de desarrollo tienen dificultades al momento de dise<73>ar estrategias efectivas para su transformaci<63>n tecnol<6F>gica y para una r<>pida
industrializaci<EFBFBD>n y desarrollo tecnol<6F>gico.
Problemas:
Identificar que tecnolog<6F>a es adecuada, como adoptarla y adaptarla
Como se escoge la tecnolog<6F>a a importar y como se definen los canales de transferencia
Como utilizar los escasos recursos de forma eficiente con el fin de promover sus capacidades tecnol<6F>gicas
Los PVD prefieren adoptar y asimilar nuevas tecnolog<6F>as en lugar de tratar de crear y generarlas, ya que se requiere un nivel menor de R\&D pero se sigue necesitando un nivel alto de habilidades t<>cnicas.
Las pol<6F>ticas de transferencia tecnol<6F>gica deben ser parte de las metas generales de la naci<63>n para sus planes de desarrollo econ<6F>mico, industrial y social. Las pol<6F>ticas de transferencia de tecnolog<6F>a deben centrarse en encontrar los m<>todos apropiados para utilizar la tecnolog<6F>a con el fin de lograr un r<>pido progreso econ<6F>mico e industrial. De esta forma los PVD reducen su dependencia de los pa<70>ses desarrollados.
La transferencia vertical establece varios pasos en la transferencia, que pueden ser aplicados en diferentes niveles: Entre centros acad<61>micos, transferencia entre la academia y la empresa para generar aplicaciones, prototipos y producci<63>n en masa. La desconcexi<78>n entre la Universidad y la empresa en Colombia y en la mayor<6F>a de los pa<70>ses en desarrollo hace que los objetivos que persigue la Academia no est<73>n sintonizados con las necesidades de la industria y en muchas ocasiones los productos generados en la Academia nunca llegan a las industrias locales, ya sea porque no tienen la infraestructura tecnol<6F>gica para hacerlo o porque la Universidad no proporciona el soporte necesario para que ese producto pueda ser utilizado en la pr<70>ctica.
Las actividades realizadas durante este estudio est<73>n enmarcadas dentro del concepto: \textit{El conocimiento es un Bien Com<6F>n}, toda la documentaci<63>n necesaria para reproducir, entrenar, entender y modificar los productos generados se encuentran disponibles en servidores p<>blicos \cite{WSCC} \cite{CC} y se proporciona soporte a trav<61>s de listas de discusi<73>n, adicionalmente se proporciona soporte comercial para permitir la producci<63>n de estas modificaciones.
la investigaci<63>n cient<6E>fica se origina y justifica cada vez m<>s en el contexto de aplicaci<63>n del conocimiento,
es decir, en la posibilidad de su utilizaci<63>n. Por lo que los temas de investigaci<63>n no son fijados por los cient<6E>ficos sino por redes formadas
por empresarios, ingenieros de planta e inversionistas
el esfuerzo de los pa<70>ses de la regi<67>n en ciencia y tecnolog<6F>a es inferior al que les corresponder<65>a realizar tomando en cuenta el valor del producto regional en Colombia el gasto es del 0.18\% lo que contrasta fuertemente con el gasto militar de 3.4\%.
Como se relacionan las habilidades CDIO con la transferencia tecnol<6F>gica?
2. Aptitudes personales y profesionales
2.1 Planteamiento y resoluci<63>n de problemas de Ing.
2.1.1 Identificaci<63>n y Formulaci<63>n del problema:
Evaluar s<>ntomas y datos.
Formular un plan de ataque.
2.1.2 Modelamiento
Aplicar modelos y simulaciones
2.1.3 Soluci<63>n y recomendaci<63>n
Analizar resultados de simulaciones y de soluciones
Analizar las diferencias en los resultados.
Formular recomendaciones.
2.2 Experimentaci<63>n y Descubrimiento de Conocimiento
2.2.1 Formulaci<63>n de hip<69>tesis
Formular hip<69>tesis para ser probadas
2.2.2 Investigaci<63>n experimental
Formular el concepto y la estrategia del experimento
Comparar datos experimentales y simulaciones
2.3 Pensamiento Sistem<65>tico
2.3.1 Pensamiento Global:
Identificar y definir un sistema, su funcionamiento y sus elementos
Utilizar un enfoque multi-disciplinario para el entendimiento global del sistema.
Identificar el contexto social y t<>cnico del sistema.
2.3.2 Surgimiento e interacciones
Identificar y definir un sistema, su funcionamiento y sus elementos
Utilizar un enfoque multi-disciplinario para el entendimiento global del sistema.
Identificar el contexto social y t<>cnico del sistema.
Discutir las abstracciones necesarias para definir y modelar un sistema
Identificar el comportamiento y las propiedades funcionales que emergen del sistema
Identificar las interfaces entre los elementos.
2.4 Habilidades y actitudes personales
2.4.1 Pensamiento creativo
Demostrar conceptualizaci<63>n y abstracci<63>n
Ejecutar el proceso de invenci<63>n.
2.4.2 Pensamiento cr<63>tico:
Analizar el planteamiento del problema.
Elegir soluciones l<>gicas.
2.4.3 Toma de conciencia de conocimientos propios
Identificar los intereses debilidades y fortalezas.
2.4.4 Curiosidad y aprendizaje permanente
Adquirir habilidades para auto-aprendizaje
2.5 Habilidades y actitudes profesionales
2.5.1 <20>tica profesional, integridad, responsabilidad.
Manifestar normas y principios <20>ticos.
Dar cr<63>dito a los colaboradores.
2.5.2 Comportamiento profesional.
Identificar normas internacionales de contacto inter-personal
3. Habilidades interpersonales, trabajo en equipo y comunicaci<63>n.
3.1 Equipo de Trabajo
3.1.1 Formar grupos efectivos
Identificar las etapas de la formaci<63>n del grupo y el ciclo de vida.
Identificar roles y responsabilidades
3.1.2 Liderazgo
Entrenamiento en procesos de administraci<63>n del equipo
Representaci<63>n del equipo ante otros.
3.2 Comunicaciones
3.2.1 Estrategia de comunicaci<63>n
Analizar la situaci<63>n
Elegir una estrategia de comunicaci<63>n
3.2.2 Estructura de la comunicaci<63>n
Construir una estructura apropiada y relaci<63>n entre las ideas.
3.2.3 Comunicaci<63>n Escrita
Escritura de documentos t<>cnicos.
3.2.4 Comunicaci<63>n Electr<74>nica
Utilizar varios estilos electr<74>nicos ()
3.2.5 Presentaci<63>n Oral y Comunicaci<63>n Inter-Personal
Preparaci<63>n de presentaciones
3.3 Comunicaci<63>n en Idioma Extranjero
3.3.1 Ingl<67>s
Leer y entender informaci<63>n t<>cnica.
Participar en listas de discusi<73>n.
4. Concebir, Dise<73>ar, Implementar y Operar Sistemas en el Contexto Social y Empresarial
4.1 Contexto externo y Social
4.1.1 Rol y responsabilidad de los Ingenieros
Aceptar las metas y funciones de la profesi<73>n
Aceptar las responsabilidades ante la sociedad
4.1.2 Impacto sobre la sociedad.
Impacto sobre el entorno sistemas sociales, conocimiento y econ<6F>mico en la cultura moderna.
4.1.3 Cuestiones y valores actuales
Define el proceso por el que se fijan los valores en la actualidad, y su rol en estos procesos.
Determina los mecanismos para expansi<73>n y difusi<73>n de conocimiento.
4.2 Empresa y contexto empresarial
4.2.1 Estrategias de empresa, metas y planificaci<63>n
Reconocer los procesos de investigaci<63>n y tecnolog<6F>a
Reconocer las alianzas estrat<61>gicas y las relaciones con los proveedores.
4.3.2 Esp<73>ritu Empresarial T<>cnico
Reconocer nuevas tecnolog<6F>as que puedan generar nuevos productos y sistemas
4.3.3 Trabajo exitoso en organizaciones
Describir los diversos roles y responsabilidades en una organizaci<63>n
4.3 Concepci<63>n de Sistemas
4.3.1 Establecer los objetivos del sistema y requerimientos
Identificar las necesidades y oportunidades del mercado
Obtener e interpretar las necesidades del consumidor
Identificar oportunidades que se derivan de las nuevas tecnolog<6F>as o necesidades
4.3.2 Definir la funci<63>n, concepto y arquitectura
Identificar las especificaciones funcionales del sistema
Identificar la arquitectura de alto nivel.
Definir la descomposici<63>n en elementos, su funci<63>n y su interfaz.
4.4 Dise<73>o
4.4.1 Proceso de Dise<73>o
Definir las especificaciones de cada componente derivado del sistema global
Analizar alternativas de dise<73>o
Utilizar prototipos en el proceso de desarrollo
Sintetizar el proyecto final
Demostrar capacidad de adaptaci<63>n ante cambio en las especificaciones.
4.4.2 Fases del proceso de Dise<73>o y enfoques
Explicar las actividades en las etapas del proceso de dise<73>o
Discutir modelos de proceso apropiados para el desarrollo de un proyecto en particular
Discutir el proceso para una plataforma sencilla y productos derivados.
4.4.3 Utilizaci<63>n de conocimiento cient<6E>fico en el dise<73>o
Utilizar conocimiento t<>cnico y cient<6E>fico
Practicar pensamiento cr<63>tico y creativo y soluci<63>n de problemas
4.4.4 Dise<73>o espec<65>fico
Elecci<63>n de t<>cnicas herramientas y procesos adecuados
Pr<50>ctica de modelamiento, simulaci<63>n y pruebas
Discutir el refinamiento anal<61>tico del dise<73>o
4.4.5 Dise<73>o multi-disciplinario
Identificar las interacciones entre disciplinas
4.5 Implementaci<63>n
4.5.2 Proceso de fabricaci<63>n Hardware
Describir la fabricaci<63>n de partes.
Describir el ensamble de partes a gran escala
4.5.3 Proceso de Implementaci<63>n de Software
Explicar el proceso de descomposici<63>n de componentes de alto nivel en m<>dulos (incluyendo algoritmos y estructuras de datos)
Realizar dise<73>o de bajo nivel
Describir el sistema de desarrollo
4.5.4 Integraci<63>n Software - Hardware
Describir la integraci<63>n de software en hardware electr<74>nico (Tama<6D>o del procesador, comunicaciones, memorias, per<65>f<EFBFBD>ricos)
Describir la funci<63>n y la seguridad del HW/SW
4.5.5 Pruebas, verificaci<63>n, validaci<63>n y certificaci<63>n
Discutir procedimientos de an<61>lisis y pruebas
Discutir la verificaci<63>n de desempe<70>o de los requerimientos del sistema.
Discutir la validaci<63>n del desempe<70>o que el usuario necesita
Explicar la certificaci<63>n de normas.
4.6 OPERATING (2.2) [c]
4.6.1 Designing and Optimizing Operations (2.6/3)
Interpret the goals and metrics for operational performance, cost, and value {b-S2}
Explain operations process architecture and development {a-S2}
Explain operations (and mission) analysis and modeling {CP}
4.6.2 Training and Operations (2.2/2)
Describe training for professional operations: {CP}
Simulation
Instruction and programs
Procedures
Recognize education for consumer operation {a-S3}
Describe operations processes {a-S3}
Recognize operations process interactions {c-E1}
4.6.3 Supporting the System Lifecycle (2.4/2)
Explain maintenance and logistics {a-S5}
Describe lifecycle performance and reliability {a-E1}
Describe lifecycle value and costs {a-E1}
Explain feedback to facilitate system improvement {CP}
4.6.4 System Improvement and Evolution (2.4/2)
Define pre-planned product improvement {a-S5}
Recognize improvements based on needs observed in operation {c-S5}
Recognize evolutionary system upgrades {c-S5}
Recognize contingency improvements/solutions resulting from operational necessity {c-S4}
4.6.5 Disposal and Life-End Issues (1.5/2)
Define the end of life issues {b-E1}
List disposal options {c-S5}
Define residual value at life-end {b-E1}
List environmental considerations for disposal {c-E2}
4.6.6 Operations Management (2.3/2)
Describe the organization and structure for operations {a-S2}
Recognize partnerships and alliances {c-S2}
Recognize control of operations cost, performance and scheduling {c-S3}
Describe quality and safety assurance {b-S4}
Define life cycle management {a-S3}
Recognize possible operations process improvements {a-S2}
\subsubsection{Sistemas Embebidos}
\begin{itemize}
\item Realizar aplicaciones que requieran dise<73>o multi-disciplinario.
\item Estudiar y realizar el proceso de Fabricaci<63>n Hardware.
\item Estudiar el principio b<>sico de los sistemas operativos.
\item Describir la integraci<63>n de software en hardware electr<74>nico
\item Entender diagramas de circuitos electr<74>nicos de sistemas digitales, identifcar sus componentes y su funci<63>n.
\item Estudiar dise<73>os software y hardware existentes para entender su funcionamiento, arquitectura y adquirir experiencia en el dise<73>o.
\item Hacer parte de listas de discusi<73>n de temas t<>cnicos que usen el ingl<67>s como lenguaje.
\end{itemize}
\subsection{Recomendaciones para los generadores de pol<6F>ticas}
\begin{itemize}
\item{Fomentar la Generaci<63>n de Empresas Locales de Base Tecnol<6F>gica}
\item{Promover la Importancia de la Transferencia Tecnol<6F>gica como Motor de Desarrollo Econ<6F>mico}
\item{Promover el Mejoramiento de la Plataforma Tecnol<6F>gica}
\end{itemize}
\subsection{Recomendaciones para la academia}
\begin{itemize}
\item{Alianza con la industria}
\item{Actualizaci<EFBFBD>n Curricular}
\item{Promover y Soportar la Transferencia Tecnol<6F>gica}
\item{B<EFBFBD>squeda de financiaci<63>n para I+D}
\end{itemize}
\subsection{Recomendaciones para el Gobierno}
\begin{itemize}
\item{Promover la Relaci<63>n Universidad-Empresa}
\item{Promover la Excelencia Acad<61>mica y la Investigaci<63>n}
\item{Formular pol<6F>ticas Para Incentivar Actividades de Transferencia Tecnol<6F>gica}
\end{itemize}
I believe in free knowledge, that means everybody should have the CHANCE to grow
but but no means do I think that will mean everybody will actually use that chance
n hardware in particular, it's all about capital invested, effective managment, standardization, drive prices down
so I think that needs to go along with free knowledge, but I don't think free knowledge means that we will all bake our phones in our ovens
El auto-gobierno esta basado en al confianza que existe entre sus miembros y el conocimiento que todos tienen del funcionamiento del sistema.
El beneficio asociado al acceso a la informaci<63>n depende de la calidad de esta, a mayor calidad de informaci<63>n, mayor el beneficio.

View File

@@ -0,0 +1,351 @@
Es necesario transferir todos los componentes de la tecnolog<6F>a para una efectiva transferenica.
En conclusi<73>n con la venta de equipos se transmite <20>nicamente el conocimiento para operar, programar o mantener, sin embargo,
este conocimiento sobre el sistema puede ayudar a concientizarse sobre la tecnolog<6F>a e impulsar la formaci<63>n de capital humano.
La transferencia tecnol<6F>gica incluye la difusi<73>n de conocimiento cient<6E>fico y la preocupaci<63>n por la transformaci<63>n del conocimiento en
innovaciones <20>tiles
La transferencia tecnol<6F>gica no ocurre cuando estudiantes formados en el exterior no pueden aplicar sus conocimientos en su pa<70>s de origen,
por lo que es necesario crear pol<6F>ticas que definan que <20>reas de estudio son prioritarias para el pa<70>s. Adicionalmente, existen centros privados
de capacitaci<63>n que ofrecen cursos para el manejo de paquetes y lenguajes de
programaci<EFBFBD>n, estos centros aprovechan la falta de centros de ense<73>anza tecnol<6F>gica y personal calificado para cobrar altas sumas de dinero,
lo cual limita el acceso
no es bueno confiar a consultores externos la responsabilidad
de construir habilidades locales, ya que reduce el desarrollo de estas habilidades, especialmente, la del personal encargado de manejar proyectos
El licenciamiento es un canal que se utiliza para transferencia de know-how sobre productos o procesos, es aplicado de forma individual o en
combinaci<EFBFBD>n con otros instrumentos como investigaci<63>n extranjera, importaci<63>n de maquinaria o de t<>cnicos. Sin embargo, no es efectivo si no
se acompa<70>a de habilidades administrativas y de producci<63>n. Adicionalmente, es necesario contar con una infraestructura tecnol<6F>gica adecuada,
capacidades locales de fabricaci<63>n de hardware y software y pol<6F>ticas de gobierno adecuadas.
Toda pol<6F>tica debe contar con formas de medir la transferencia exitosa. Uno de los indicadores de <20>xito es la transferencia de habilidades.
Muchos pa<70>ses en v<>a de desarrollo tienen dificultades al momento de dise<73>ar estrategias efectivas para su transformaci<63>n tecnol<6F>gica y para una r<>pida
industrializaci<EFBFBD>n y desarrollo tecnol<6F>gico.
Problemas:
Identificar que tecnolog<6F>a es adecuada, como adoptarla y adaptarla
Como se escoge la tecnolog<6F>a a importar y como se definen los canales de transferencia
Como utilizar los escasos recursos de forma eficiente con el fin de promover sus capacidades tecnol<6F>gicas
Los PVD prefieren adoptar y asimilar nuevas tecnolog<6F>as en lugar de tratar de crear y generarlas, ya que se requiere un nivel menor de R\&D pero se sigue necesitando un nivel alto de habilidades t<>cnicas.
Las pol<6F>ticas de transferencia tecnol<6F>gica deben ser parte de las metas generales de la naci<63>n para sus planes de desarrollo econ<6F>mico, industrial y social. Las pol<6F>ticas de transferencia de tecnolog<6F>a deben centrarse en encontrar los m<>todos apropiados para utilizar la tecnolog<6F>a con el fin de lograr un r<>pido progreso econ<6F>mico e industrial. De esta forma los PVD reducen su dependencia de los pa<70>ses desarrollados.
La transferencia vertical establece varios pasos en la transferencia, que pueden ser aplicados en diferentes niveles: Entre centros acad<61>micos, transferencia entre la academia y la empresa para generar aplicaciones, prototipos y producci<63>n en masa. La desconcexi<78>n entre la Universidad y la empresa en Colombia y en la mayor<6F>a de los pa<70>ses en desarrollo hace que los objetivos que persigue la Academia no est<73>n sintonizados con las necesidades de la industria y en muchas ocasiones los productos generados en la Academia nunca llegan a las industrias locales, ya sea porque no tienen la infraestructura tecnol<6F>gica para hacerlo o porque la Universidad no proporciona el soporte necesario para que ese producto pueda ser utilizado en la pr<70>ctica.
Las actividades realizadas durante este estudio est<73>n enmarcadas dentro del concepto: \textit{El conocimiento es un Bien Com<6F>n}, toda la documentaci<63>n necesaria para reproducir, entrenar, entender y modificar los productos generados se encuentran disponibles en servidores p<>blicos \cite{WSCC} \cite{CC} y se proporciona soporte a trav<61>s de listas de discusi<73>n, adicionalmente se proporciona soporte comercial para permitir la producci<63>n de estas modificaciones.
la investigaci<63>n cient<6E>fica se origina y justifica cada vez m<>s en el contexto de aplicaci<63>n del conocimiento,
es decir, en la posibilidad de su utilizaci<63>n. Por lo que los temas de investigaci<63>n no son fijados por los cient<6E>ficos sino por redes formadas
por empresarios, ingenieros de planta e inversionistas
el esfuerzo de los pa<70>ses de la regi<67>n en ciencia y tecnolog<6F>a es inferior al que les corresponder<65>a realizar tomando en cuenta el valor del producto regional en Colombia el gasto es del 0.18\% lo que contrasta fuertemente con el gasto militar de 3.4\%.
Como se relacionan las habilidades CDIO con la transferencia tecnol<6F>gica?
2. Aptitudes personales y profesionales
2.1 Planteamiento y resoluci<63>n de problemas de Ing.
2.1.1 Identificaci<63>n y Formulaci<63>n del problema:
Evaluar s<>ntomas y datos.
Formular un plan de ataque.
2.1.2 Modelamiento
Aplicar modelos y simulaciones
2.1.3 Soluci<63>n y recomendaci<63>n
Analizar resultados de simulaciones y de soluciones
Analizar las diferencias en los resultados.
Formular recomendaciones.
2.2 Experimentaci<63>n y Descubrimiento de Conocimiento
2.2.1 Formulaci<63>n de hip<69>tesis
Formular hip<69>tesis para ser probadas
2.2.2 Investigaci<63>n experimental
Formular el concepto y la estrategia del experimento
Comparar datos experimentales y simulaciones
2.3 Pensamiento Sistem<65>tico
2.3.1 Pensamiento Global:
Identificar y definir un sistema, su funcionamiento y sus elementos
Utilizar un enfoque multi-disciplinario para el entendimiento global del sistema.
Identificar el contexto social y t<>cnico del sistema.
2.3.2 Surgimiento e interacciones
Identificar y definir un sistema, su funcionamiento y sus elementos
Utilizar un enfoque multi-disciplinario para el entendimiento global del sistema.
Identificar el contexto social y t<>cnico del sistema.
Discutir las abstracciones necesarias para definir y modelar un sistema
Identificar el comportamiento y las propiedades funcionales que emergen del sistema
Identificar las interfaces entre los elementos.
2.4 Habilidades y actitudes personales
2.4.1 Pensamiento creativo
Demostrar conceptualizaci<63>n y abstracci<63>n
Ejecutar el proceso de invenci<63>n.
2.4.2 Pensamiento cr<63>tico:
Analizar el planteamiento del problema.
Elegir soluciones l<>gicas.
2.4.3 Toma de conciencia de conocimientos propios
Identificar los intereses debilidades y fortalezas.
2.4.4 Curiosidad y aprendizaje permanente
Adquirir habilidades para auto-aprendizaje
2.5 Habilidades y actitudes profesionales
2.5.1 <20>tica profesional, integridad, responsabilidad.
Manifestar normas y principios <20>ticos.
Dar cr<63>dito a los colaboradores.
2.5.2 Comportamiento profesional.
Identificar normas internacionales de contacto inter-personal
3. Habilidades interpersonales, trabajo en equipo y comunicaci<63>n.
3.1 Equipo de Trabajo
3.1.1 Formar grupos efectivos
Identificar las etapas de la formaci<63>n del grupo y el ciclo de vida.
Identificar roles y responsabilidades
3.1.2 Liderazgo
Entrenamiento en procesos de administraci<63>n del equipo
Representaci<63>n del equipo ante otros.
3.2 Comunicaciones
3.2.1 Estrategia de comunicaci<63>n
Analizar la situaci<63>n
Elegir una estrategia de comunicaci<63>n
3.2.2 Estructura de la comunicaci<63>n
Construir una estructura apropiada y relaci<63>n entre las ideas.
3.2.3 Comunicaci<63>n Escrita
Escritura de documentos t<>cnicos.
3.2.4 Comunicaci<63>n Electr<74>nica
Utilizar varios estilos electr<74>nicos ()
3.2.5 Presentaci<63>n Oral y Comunicaci<63>n Inter-Personal
Preparaci<63>n de presentaciones
3.3 Comunicaci<63>n en Idioma Extranjero
3.3.1 Ingl<67>s
Leer y entender informaci<63>n t<>cnica.
Participar en listas de discusi<73>n.
4. Concebir, Dise<73>ar, Implementar y Operar Sistemas en el Contexto Social y Empresarial
4.1 Contexto externo y Social
4.1.1 Rol y responsabilidad de los Ingenieros
Aceptar las metas y funciones de la profesi<73>n
Aceptar las responsabilidades ante la sociedad
4.1.2 Impacto sobre la sociedad.
Impacto sobre el entorno sistemas sociales, conocimiento y econ<6F>mico en la cultura moderna.
4.1.3 Cuestiones y valores actuales
Define el proceso por el que se fijan los valores en la actualidad, y su rol en estos procesos.
Determina los mecanismos para expansi<73>n y difusi<73>n de conocimiento.
4.2 Empresa y contexto empresarial
4.2.1 Estrategias de empresa, metas y planificaci<63>n
Reconocer los procesos de investigaci<63>n y tecnolog<6F>a
Reconocer las alianzas estrat<61>gicas y las relaciones con los proveedores.
4.3.2 Esp<73>ritu Empresarial T<>cnico
Reconocer nuevas tecnolog<6F>as que puedan generar nuevos productos y sistemas
4.3.3 Trabajo exitoso en organizaciones
Describir los diversos roles y responsabilidades en una organizaci<63>n
4.3 Concepci<63>n de Sistemas
4.3.1 Establecer los objetivos del sistema y requerimientos
Identificar las necesidades y oportunidades del mercado
Obtener e interpretar las necesidades del consumidor
Identificar oportunidades que se derivan de las nuevas tecnolog<6F>as o necesidades
4.3.2 Definir la funci<63>n, concepto y arquitectura
Identificar las especificaciones funcionales del sistema
Identificar la arquitectura de alto nivel.
Definir la descomposici<63>n en elementos, su funci<63>n y su interfaz.
4.4 Dise<73>o
4.4.1 Proceso de Dise<73>o
Definir las especificaciones de cada componente derivado del sistema global
Analizar alternativas de dise<73>o
Utilizar prototipos en el proceso de desarrollo
Sintetizar el proyecto final
Demostrar capacidad de adaptaci<63>n ante cambio en las especificaciones.
4.4.2 Fases del proceso de Dise<73>o y enfoques
Explicar las actividades en las etapas del proceso de dise<73>o
Discutir modelos de proceso apropiados para el desarrollo de un proyecto en particular
Discutir el proceso para una plataforma sencilla y productos derivados.
4.4.3 Utilizaci<63>n de conocimiento cient<6E>fico en el dise<73>o
Utilizar conocimiento t<>cnico y cient<6E>fico
Practicar pensamiento cr<63>tico y creativo y soluci<63>n de problemas
4.4.4 Dise<73>o espec<65>fico
Elecci<63>n de t<>cnicas herramientas y procesos adecuados
Pr<50>ctica de modelamiento, simulaci<63>n y pruebas
Discutir el refinamiento anal<61>tico del dise<73>o
4.4.5 Dise<73>o multi-disciplinario
Identificar las interacciones entre disciplinas
4.5 Implementaci<63>n
4.5.2 Proceso de fabricaci<63>n Hardware
Describir la fabricaci<63>n de partes.
Describir el ensamble de partes a gran escala
4.5.3 Proceso de Implementaci<63>n de Software
Explicar el proceso de descomposici<63>n de componentes de alto nivel en m<>dulos (incluyendo algoritmos y estructuras de datos)
Realizar dise<73>o de bajo nivel
Describir el sistema de desarrollo
4.5.4 Integraci<63>n Software - Hardware
Describir la integraci<63>n de software en hardware electr<74>nico (Tama<6D>o del procesador, comunicaciones, memorias, per<65>f<EFBFBD>ricos)
Describir la funci<63>n y la seguridad del HW/SW
4.5.5 Pruebas, verificaci<63>n, validaci<63>n y certificaci<63>n
Discutir procedimientos de an<61>lisis y pruebas
Discutir la verificaci<63>n de desempe<70>o de los requerimientos del sistema.
Discutir la validaci<63>n del desempe<70>o que el usuario necesita
Explicar la certificaci<63>n de normas.
4.6 OPERATING (2.2) [c]
4.6.1 Designing and Optimizing Operations (2.6/3)
Interpret the goals and metrics for operational performance, cost, and value {b-S2}
Explain operations process architecture and development {a-S2}
Explain operations (and mission) analysis and modeling {CP}
4.6.2 Training and Operations (2.2/2)
Describe training for professional operations: {CP}
Simulation
Instruction and programs
Procedures
Recognize education for consumer operation {a-S3}
Describe operations processes {a-S3}
Recognize operations process interactions {c-E1}
4.6.3 Supporting the System Lifecycle (2.4/2)
Explain maintenance and logistics {a-S5}
Describe lifecycle performance and reliability {a-E1}
Describe lifecycle value and costs {a-E1}
Explain feedback to facilitate system improvement {CP}
4.6.4 System Improvement and Evolution (2.4/2)
Define pre-planned product improvement {a-S5}
Recognize improvements based on needs observed in operation {c-S5}
Recognize evolutionary system upgrades {c-S5}
Recognize contingency improvements/solutions resulting from operational necessity {c-S4}
4.6.5 Disposal and Life-End Issues (1.5/2)
Define the end of life issues {b-E1}
List disposal options {c-S5}
Define residual value at life-end {b-E1}
List environmental considerations for disposal {c-E2}
4.6.6 Operations Management (2.3/2)
Describe the organization and structure for operations {a-S2}
Recognize partnerships and alliances {c-S2}
Recognize control of operations cost, performance and scheduling {c-S3}
Describe quality and safety assurance {b-S4}
Define life cycle management {a-S3}
Recognize possible operations process improvements {a-S2}
\subsubsection{Sistemas Embebidos}
\begin{itemize}
\item Realizar aplicaciones que requieran dise<73>o multi-disciplinario.
\item Estudiar y realizar el proceso de Fabricaci<63>n Hardware.
\item Estudiar el principio b<>sico de los sistemas operativos.
\item Describir la integraci<63>n de software en hardware electr<74>nico
\item Entender diagramas de circuitos electr<74>nicos de sistemas digitales, identifcar sus componentes y su funci<63>n.
\item Estudiar dise<73>os software y hardware existentes para entender su funcionamiento, arquitectura y adquirir experiencia en el dise<73>o.
\item Hacer parte de listas de discusi<73>n de temas t<>cnicos que usen el ingl<67>s como lenguaje.
\end{itemize}
\subsection{Recomendaciones para los generadores de pol<6F>ticas}
\begin{itemize}
\item{Fomentar la Generaci<63>n de Empresas Locales de Base Tecnol<6F>gica}
\item{Promover la Importancia de la Transferencia Tecnol<6F>gica como Motor de Desarrollo Econ<6F>mico}
\item{Promover el Mejoramiento de la Plataforma Tecnol<6F>gica}
\end{itemize}
\subsection{Recomendaciones para la academia}
\begin{itemize}
\item{Alianza con la industria}
\item{Actualizaci<63>n Curricular}
\item{Promover y Soportar la Transferencia Tecnol<6F>gica}
\item{B<>squeda de financiaci<63>n para I+D}
\end{itemize}
\subsection{Recomendaciones para el Gobierno}
\begin{itemize}
\item{Promover la Relaci<63>n Universidad-Empresa}
\item{Promover la Excelencia Acad<61>mica y la Investigaci<63>n}
\item{Formular pol<6F>ticas Para Incentivar Actividades de Transferencia Tecnol<6F>gica}
\end{itemize}
I believe in free knowledge, that means everybody should have the CHANCE to grow
but but no means do I think that will mean everybody will actually use that chance
n hardware in particular, it's all about capital invested, effective managment, standardization, drive prices down
so I think that needs to go along with free knowledge, but I don't think free knowledge means that we will all bake our phones in our ovens
El auto-gobierno esta basado en al confianza que existe entre sus miembros y el conocimiento que todos tienen del funcionamiento del sistema.
El beneficio asociado al acceso a la informaci<63>n depende de la calidad de esta, a mayor calidad de informaci<63>n, mayor el beneficio.

File diff suppressed because it is too large Load Diff

File diff suppressed because it is too large Load Diff

View File

@@ -0,0 +1,516 @@
\section{Definici\'on del problema }
\section{Introducci<EFBFBD>n}
Uno de los objetivos principales del presente trabajo es la realizaci<63>n de actividades que ayude al pa<70>s en su desarrollo tecnol<6F>gico; en la actualidad Colombia es un consumidor de tecnolog<6F>a, es decir, busca en el exterior soluciones a sus problemas, en la mayor<6F>a de las ocasiones, estas soluciones no se ajustan a los requerimientos, ya que no tienen en cuenta la situaci<63>n pol<6F>tica, cultural y social del pa<70>s. En la mayor<6F>a de los casos, no se aumenta el conocimiento tecnol<6F>gicos del pa<70>s, y reduce las opciones de negocios para las empresas locales a representantes de ventas o suministro de sevicios de mantenimiento.
Este esquema es nocivo para la industria Colombiana, ya que no existen mecanismos que permita su desarrollo, protegi<67>ndola de alguna forma frente a los productos for<6F>neos. Esto unido a las politicas de estado encaminadas a la apertura comercial, en donde los productos nacionales compiten con productos de paises con mayor desarrollo tecnol<6F>gico nos llevar<61> a la eliminaci<63>n total de la industrias Colombianas. A continuaci<63>n se presenta un res<65>men del estudio realizado por Hector Mart<72>nez sobre la Apropiaci<63>n del conocimiento en Colombia \cite{Mar04} durante los a<>os 1991 a 2000.
En la actualidad Colombia atraviesa por una $''$\textit{\textit{crisis}}$''$ a
nivel de dise<73>o de sistemas digitales, existe un atraso muy grande en esta
\'area; a mi modo de ver existen dos grandes responsables de esta situaci\'on.
Por un lado, las pol\'{\i}ticas de la mayor\'{\i}a de las industrias al no
realizar inversi\'on de capital en sus departamentos de I+D; algunas de ellas
ni siquiera cuentan con este departamento. Por otro lado, las Universidades no
cuentan con programas actualizados que permitan explotar los avances
realizados en las industrias electr\'onica y de semiconductores; en un gran
n\'umero de Universidades Colombianas a\'un se trabaja con dispositivos de
funci\'on fija como las familias 74 y 40. Los lenguajes de descripci\'on de
hardware han sido adoptados recientemente en la mayor\'{\i}a de programas de
ingenier\'{\i}a electr\'onica, pero en algunos casos no existe una base
metodol\'ogica que soporte su adecuada utilizaci\'on. La disponibilidad de
dispositivos l\'ogicos programables (FPGAs, CPLDs) es limitada debido a la
inexistencia de un proveedor local. Se dedican cursos completos para
$''$ense<EFBFBD>ar$''$ a programar microprocesadores de 8 bits en lenguaje
ensamblador y muchos educadores a\'un miran con desconfianza a los lenguajes
de alto nivel como el C, C++ o UML. En muy pocos programas de Ingenier\'{\i}a
Electr\'onica no se cuenta con una asignatura dedicada a sistemas operativos y
en muchos de ellos no se le da la importancia que tiene la ense<73>anza de
lenguajes estructurados.
La situaci\'on se agrava a\'un m\'as al ver el estado de la relaci\'on entre
la universidad y la industria, la cual no existe en algunos casos. Desde el
punto de vista industrial los resultados obtenidos en la academia parten de
entornos ideales y no se tienen en cuenta las caracter\'{\i}sticas de los
entornos industriales, lo cual da como resultado sistemas poco robustos y con
problemas funcionales. Por otro lado, los tiempos de desarrollos son muy
largos ya que la mayor\'{\i}a de las universidades Colombianas no se cuenta
con grupos de investigaci\'on cuyos miembros se encuentren dedicados de forma
exclusiva al desarrollo de este tipo de proyectos, la mayor\'{\i}a \ de los
miembros de estos grupos son temporales (estudiantes de pregrado) y sin paga,
lo cual no garantiza el cumplimiento ni la continuidad de las investigaciones.
\subsection{Apropiaci<EFBFBD>n de Conocimiento}
Para que Colombia deje de ser un pa<70>s que consume tecnolog<6F>a y llegue en alg<6C>n momento a ser generador de productos tecnol<6F>gicos, es necesario que se genere un conocimiento que permita esta transici<63>n. ``Para que el conocimiento sea motor de desarrollo es necesario el traspaso desde sus creadores a la sociedad, mediante la conversi<73>n a tecnolog<6F>as que produzcan cambios radicales que incrementen la producci<63>n. Esa transmisi<73>n de tecnolog<6F>a generadora de crecimiento econ<6F>mico esta influenciada por diversos factores: medio geogr<67>fico, leyes de propiedad industrial, costos laborales, nivel de ciencia y tecnolog<6F>a, religi<67>n, tipos de instituciones, resistencia a innovar, pol<6F>ticas de estado, guerras, factores demogr<67>ficos, entre otros'' \cite{Mok90}
Pero como apropiar este conocimiento? Arrow \cite{Arr62} afirma que la apropicaci<63>n de conocimiento puede efectuarse de varias formas: ``aprender haciendo'', ``aprender usando'', ``aprender leyendo''. Cuando una empresa decide transmitir su conocimiento disponible, lo hace en procesos de investigaciones conjuntas, en actividades de producci<63>n, y distribuci<63>n, mercadeo, servicio y soporte operativo o riesgo compartido. Tambi<62>n se presentan alianzas entre firmas como: contratos de I+D, acuerdos de licencias, licencias cruzadas. La conformaci<63>n de estas asociaciones permite crear redes tecnol<6F>gicas dominadas por pa<70>ses industrializados con sus respectivas empresas multinacionales monopolizando conocimiento \cite{Mar04}
Para Colombia, el problema radica en que mediante contratos de importaci<63>n de tecnolog<6F>a, las empresas de capital nacional no est<73>n adquiriendo el conocimiento necesario para lograr innovaciones al interior de las mismas. De forma que puedan ser competitivas y logren acceder a mercados internacionales ofreciendo productos innovadores, de calidad y a precios competitivos. Con efectos directos como: generaci<63>n de empleos especializados, desarrollo tecnol<6F>gico e industrial sostenido, ampliaci<63>n del acervo de conocimiento nacional y disminuci<63>n de la salida de divisas (al mejorar los procesos de negociaci<63>n) y creaci<63>n de externalidades positivas \cite{Mar04}.
Ligado al problema de la senda tecnol<6F>gica est<73> el del grado de lo t<>cito del conocimiento cient<6E>fico. Teece \cite{Tee81} se<73>ala que al existir conocimiento t<>cito toda la tecnolog<6F>a disponible no se transfiere de los productores a los receptores o compradores de la misma. Por tanto, los pa<70>ses seguidores siempre van a estar a la zaga tecnol<6F>gica. Forbes y Wield \cite{FW00} se<73>alan que los esfuerzos adaptativos son mayores porque deben acomodar las ``innovaciones'' a los materiales locales, fuerza laboral nativa, mercados internos y medio ambiente local. Entonces, el problema no se limita a c<>mo transferir conocimiento, c<>mo develar su parte t<>cita y c<>mo extraerlo de las multinacionales, sino que radica en el bajo poder de negociaci<63>n y adquisici<63>n de tecnolog<6F>a por firmas peque<75>as y medianas, las cuales carecen de recursos y tienen procesos deficientes de contrataci<63>n.
En este orden de ideas, si el pa<70>s no es un innovador neto <20>no deber<65>a m<>s bien mostrar una tendencia a importar conocimiento? Y las firmas nacionales <20>no deber<65>an ser las que m<>s efectuaran este tipo de contratos, para as<61> acceder al conocimiento de la tecnolog<6F>a adquirida? En resumen, conociendo mejor qu<71> tecnolog<6F>a se importa y qu<71> tipos de contratos se utilizan, es posible crear marcos de referencia para empresas nacionales que est<73>n interesadas en adquirir tecnolog<6F>a. Esto producir<69>a externalidades positivas en empresas importadoras de conocimiento y, a su vez, en la econom<6F>a del pa<70>s. Con una adecuada importaci<63>n de conocimientos tecnol<6F>gicos se crear<61>a una ventaja competitiva de car<61>cter estructural, basada en un acervo de conocimiento tecnol<6F>gico que permita incrementar la productividad en todos los sectores econ<6F>micos de manera permanente \cite{Mar04}.
Seg<EFBFBD>n los estudios realizados por Mart<72>nez, con base en registros del Decreto 259/92, del Incomex. La importaci<63>n de conocimiento no est<73> siendo empleada con el prop<6F>sito de utilizar tecnolog<6F>as de punta que permitan efectuar innovaciones al interior de las empresas y de los sectores. Las empresas nacionales se limitan a comprar un determinado dispositivo, sin tener el conocimiento para operarlo, hacerle mantenimiento ni mucho menos mejorarlo, por lo que se ven obligadas a contratar con el vendedor contratos para dicho f<>n. Esto indica que la adquisici<63>n de tecnolog<6F>a no se realiza con base en programa desarrollado de antemano, sino son una respuesta a cambios en el mercado, lo cual evidencia la inexistencia de programas de innovaci<63>n encaminados a la disminuci<63>n de la brecha tecnol<6F>gica.
\subsubsection{Situaci<EFBFBD>n de la Industria Electr<74>nica en Colombia}
La industria electr<74>nica nacional no es ajena a las pol<6F>ticas que siguen las empresas nacionales en cuanto a la apropiaci<63>n de tecnolog<6F>a; Colombia depende totalmente de econom<6F>as m<>s desarrolladas para el suministro de dispositivos electr<74>nicos en diversas areas (comunicaciones, entretenimiento, industria, medicina, etc). Mientras en otros sectores de la econom<6F>a han pasado de ser consumidores a exportadores, y adquieren nuevas tecnolog<6F>as para ser m<>s competitivos, el sector electr<74>nico del pa<70>s ha reducido sus actividades de Investigaci<63>n y Desarrollo hasta el punto de depender totalmente de productos externos unos de baja calidad y que no suplen los requerimientos del mercado local, pero que son muy econ<6F>micos.
En la actualidad la industria electr<74>nica presenta una gran din<69>mica a nivel mundial, el uso de los sistemas electr<74>nicos se extiende a todas las actividades humanas; La demanda mundial de este tipo de sistemas aumentar<61> de forma dram<61>tica en los pr<70>ximos a<>os, especialmente en los sectores de tecnolog<6F>a m<>dica, movilidad, seguridad, comunicaciones y consumo \cite{ETPoSSI(09}. El mercado de los sistemas embebidos es una industria que movi<76> alrededor de 25 billones de d<>lares en el 2008 seg<65>n Venture Development Corporation \cite{Vc08}. Por otro lado, la inversi<73>n de capital necesaria para el dise<73>o de Sistemas Embebidos es relativamente baja, gracias a la gran demanda originada, los insumos y los servicios de fabricaci<63>n son muy econ<6F>micos, por otro lado, las herramientas de desarrollo necesarias para la programaci<63>n y depuraci<63>n de este tipo de sistemas son de libre distribuci<63>n.
Desafortunadamente en Colombia la industria electr<74>nica se encuentra muy rezagada en relaci<63>n a las de los pa<70>ses industrializados, y las ventajas y oportunidades de negocios mencionadas anteriormente no son aprovechadas en la actualidad.
Seg<EFBFBD>n ASESEL \footnote{Asociaci<EFBFBD>n de entidades del Sector Electr<74>nico} en el 2001 exist<73>an 154 empresas productoras de componentes y equipos de la cadena electr<74>nica. Dentro de los productos que la industria electr<74>nica exporta se encuentran registrados: Circuitos integrados, circuitos impresos, microestructuras, instrumentos para medida y control, Instrumentos y aparatos el<65>ctricos o electr<74>nicos. Es importante decir que la industria colombiana, en la actualidad no fabrica circuitos integrados, ni microestructuras, por lo que estas son ventas de productos comprados en pa<70>ses desarrollados. Seg<65>n Proexport el 91\% de las exportaciones son realizadas por Bogot<6F> y los destinos se encuentran en pa<70>ses cercanos como Venezuela, Per<65>, Ecuador y USA.
La electr<74>nica en Colombia y en el mundo hace parte de esas industrias que se mueven velozmente en un
camino desconocido, como consecuencia se hace necesario tener una actualizaci<63>n constante de los
avances tecnol<6F>gicos y las proyecciones futuras del sector. Debido a la importancia del sector tecnol<6F>gico es primordial que en Colombia se est<73> consciente del estado actual y que se puede hacer en t<>rminos de
Investigaci<EFBFBD>n Cient<6E>fica y Desarrollo Tecnol<6F>gico (I+D) en Ingenier<65>a Electr<74>nica.
Un estudio realizado en la Universidad Nacional de Colombia \cite{MTRR07} identific<69> los siguientes obst<73>culos para el desarrollo de la industria electr<74>nica en Colombia: Deficientes relaciones Universidad Empresa, Pobre enfoque acad<61>mico hacia la industria, Calidad de los productos nacionales, pol<6F>ticas gubernamentales, falta de cultura de Investigaci<63>n y Reducida apropiaci<63>n tecnol<6F>gica, competencia de pa<70>ses asi<73>ticos, atraso tecnol<6F>gico, limitado recurso humano con formaci<63>n avanzada.
De los problemas expuestos anteriormente podemos identificar cuales son los que m<>s afectan el desarrollo de la industria electr<74>nica en Colombia, el que m<>s perjudica sin lugar a dudas es el atraso tecnol<6F>gico, no es posible ser competitivo en el mercado electr<74>nico mundial con tecnolog<6F>as y metodolog<6F>as de dise<73>o obsoletas, en Colombia trabajamos a<>n con circuitos integrados que se crearon en la decada de los 80 del siglo pasado y utilizamos lenguajes de programaci<63>n como el assembler, para el cual el tiempo de aprendizaje, desarrollo y de depuraci<63>n es muy largo. La culpa de este atraso tecnol<6F>gico no es exclusiva de la induatria, aunque, como vimos anteriormente muchas industrial Colombianas se resisten al cambio y prefieren comprar equipos en el exterior a buscarlos localmente, la falta de confiabilidad en los productos Colombianos agrava este problema, esta falta de confianza en la industria local no es infundada, la mayor<6F>a de los productos Colombianos no cumplen con las normas m<>nimas de calidad y utilizan productos de bajo costo obtenidos en remates de componetes.
Otro actor que contribuye al retraso tecnol<6F>gico es el sector acad<61>mico; seg<65>n el Sistema Nacional de Informaci<63>n Superior, durante los <20>ltimos 10 a<>os se han abierto 230 programas relacionados con la industria electr<74>nica, estos programas est<73>n repartidos entre programas de formaci<63>n Universitaria, tecnol<6F>gica terminal y de t<>cnica profesional, la mayor<6F>a de estos centros de formaci<63>n se encuentran ubicados en 3 Departamentos: Bogot<6F>, Antioquia y Valle \cite{DZSC+07}. El n<>mero de Ingenieros graduados en un a<>o es entre 2 y 8 veces mayor que en los pa<70>ses en v<>a de desarrollo y doce veces mayor que los que se grad<61>an en los pa<70>ses desarrollados, en Colombia, este aumento es aportado por instituciones de poca consolidaci<63>n. Adem<65>s las preferencias en la educaci<63>n superior son Formaci<63>n t<>cnica / form. tecnol<6F>gica / form. profesional que es justamente lo opuesto a la de los pa<70>ses desarrollados \cite{MDAG99}.
Por otro lado, el contenido de las asignaturas relacionadas directamente con la industria electr<74>nica se encuentran muy desactualizados, y fuera del contexto mundial, se utilizan metodolog<6F>as de dise<73>o antiguas en las que primaba la experiencia del dise<73>ador, se realizan tareas manuales, repetitivas que pueden ser realizadas por herramientas de dise<73>o moderno, los curr<72>culos son conservadores hay poca experimentaci<63>n y su estructuraci<63>n y metodolog<6F>as son muy cl<63>sicas. Otro problema adicional radica en la falta de experiencia en el sector productivo por parte del personal acad<61>mico, un componente importante de los profesores nunca han sido parte de un proceso productivo o de un proceso de desarrollo que tenga como f<>n la creaci<63>n de un producto comercial, raz<61>n por la cual se evita la experimentaci<63>n y se da m<>s <20>nfasis al an<61>lisis y solo se llega a una simulaci<63>n.
De lo anterior podemos concluir que en Colombia se presenta una sobre-oferta de profesionales en el <20>rea electr<74>nica, muchos de los cuales provienen de instituciones educativas con poca consolidaci<63>n, y que han sido formados con programas desactualizados que no tienen en cuenta los avances tecnol<6F>gicos y metodol<6F>gicos, lo cual explica la pobreza de ingenieros con altos niveles de formaci<63>n. Por esta raz<61>n no es de extra<72>ar la poca confianza que tienen los industriales en los productos nacionales.
Lo anterior unido a la falta de pol<6F>ticas de estado que: tracen normas encaminadas a incentivar la inversi<73>n en investigaci<63>n y desarrollo, defina l<>neas y campos de investigaci<63>n, regulaci<63>n de la oferta laboral, regulaci<63>n de los programas acad<61>micos, generan el clima perfecto para que el atraso tecnol<6F>gico se mantenga durante mucho tiempo y Colombia no deje de ser un consumidor de tecnolog<6F>a.
\subsubsection{Pasos a seguir para iniciar la soluci<63>n al problema de atraso tecnol<6F>gico}
Estudios consultados \cite{MDAG99} \cite{DZSC+07} \cite{MTRR07} \cite{Mar04}, coinciden en que para dar soluci<63>n a los problemas expuestos anteriormente se deben seguir las siguientes recomendaciones:
Al gobierno:
\begin{itemize}
\item Fomento gubernamental de centros de investigaci<63>n y productividad para fortalecer la relaciones universidad empresa.
\item Fomentar cooperaci<63>n internacional e inversi<73>n extranjera con transferencia de tecnolog<6F>a. a nivel gubernamental, Apoyo del gobierno a personas que tienen un alto potencial de crear y desarrollar tecnolog<6F>a.
\item Definir agendas de investigaci<63>n acordes con las tendencias mundiales y desarrollar capacidades en el pa<70>s.
\end{itemize}
A los centros de Ense<73>anza:
\begin{itemize}
\item Creaci<63>n de portafolio de servicios.
\item Realizar seminarios y l<>neas de profundizaci<63>n de temas afines a la administraci<63>n y la gerencia en empresas de base tecnol<6F>gica.
\item Montar laboratorios de pruebas e incentivar los productores nacionales para que logren una calidad que cumpla con los est<73>ndares internacionales.
\item Infraestructura institucional que impulse la actualizaci<63>n tecnol<6F>gica en el sector mediante desarrollo de proyectos de tecnolog<6F>a de punta con una posible transferencia de tecnolog<6F>a.
\item Incentivar la formaci<63>n de maestr<74>as y doctorados nacionales acorde con una agenda de investigaci<63>n.
\item Realizaci<63>n de proyectos de aplicaci<63>n.
\item El contacto con las empresas no debe ser encargada <20>nicamente a los estudiantes, la Universidad debe desarrollar las competencias que la empresa requiere.
\item Interacci<63>n entre Universidades, Conviene que buena parte de los trabajos realizados en doctorado sean de investigaci<63>n aplicada, orientadas a mejorar la productividad del sector empresarial
\item Innovaci<63>n curricular, actualizaci<63>n continua de profesionales.
\item Las facultades de Ingenier<65>a deben acompa<70>ar las demandas que surgen del sector productivo.
\item Necesidad de mejorar las competencias y habilidades generales de los ingenieros, (continuo aprendizaje) habilidad para innovar, investigar, desarrollar nueva tecnolog<6F>a.
\end{itemize}
\subsubsection{Estado de la Electr<74>nica Digital en la Universidad Nacional de Colombia}
Hasta hace un a<>o en las asignaturas del <20>rea de electr<74>nica digital de la Universidad Nacional de Colombia (La Universidad m<>s grande e importante del pais), se trabajaba con dispositivos que fueron sacados al mercado en 1966 y 1968, las familia l<>gica TTL 7400 y CMOS 4000. El problema principal al utilizar esta tecnolog<6F>a no es su a<>o de creaci<63>n, ni siquiera que en la actualidad se consideren obsoletas para el dise<73>o de un sistema digital completo. \footnote{En la actualidad estas compuertas se utilizan para la implementaci<63>n de peque<75>as operaciones l<>gicas} El problema detr<74>s del uso de esta tecnolog<6F>a se encuentra en la ausencia total de metodolog<6F>as de dise<73>o (en el caso Colombiano). Y el desconocimiento en herramientas tipo CAD. El proceso de dise<73>o que realizaban los estudiantes era:
\begin{enumerate}
\item Especificaciones del sistema.
\item Generaci<63>n manual de ecuaciones boolenas.
\item Minimizaci<63>n manual utilizando mapas de Karnaugh.
\item Implementaci<63>n de las ecuaciones minimizadas utilizando las familias l<>gicas 7400 y 4000, sobre placas de pruebas (protoboards, breadboards)
\item Pruebas del sistema.
\end{enumerate}
A manera de ejercicio acad<61>mico se justifica el uso de las familias 7400 y 4000, sin embargo, el quedarse ahi no es bueno para una industria electr<74>nica desactualizada, debido a que este tipo de implementaciones no pueden generar productos competitivos a nivel mundial. La raz<61>n de esto es que existen muchas fuentes de error en el proceso, generados por la ausencia de herramientas CAD que realizan las operaciones tediosas como las minimizaci<63>n de ecuaciones booleanas, las cuales est<73>n sujetas a errores humanos originados por cansancio, falta de concentraci<63>n, etc. Otro aspecto que vale la pena resaltar es la falta de ua simulaci<63>n funcional, la mayor<6F>a de los estudiantes consultados no realizaban simulaciones funcionales y prefer<65>an probar el dise<73>o una vez implementado f<>sicamente, esto unido a la dificultad de depuraci<63>n innata a este tipo de implementaciones, aumentaba considerablemente el tiempo requerido para realizar las pruebas al sistema.
A los problemas mencionados anteriormente se suma la gran cantidad de circuitos integrados necesarios para implementar un sistema sencillo, se observaron hasta 8 placas de pruebas con cerca de 50 circuitos integrados interconectados entre s<>, lo cual aumenta las posibles causas de error y aumenta el tiempo de desarrollo en forma considerable.
En el segundo curso del <20>rea de electr<74>nica digital, se introduce al estudiante al uso de los dispositivos l<>gicos programables (PLD) y los lenguajes de descripci<63>n de hardware (HDL) como herramientas para el dise<73>o de sistemas digitales, al comienzo, el contenido de estos cursos se limitaba al uso de una herramienta de dise<73>o y la ense<73>anza de nociones b<>sicas del lenguaje VHDL, se daba m<>s importancia al uso de la herramienta y no a la metodolog<6F>a de dise<73>o, de nuevo el estudiante ataca los problemas sin una metodolog<6F>a de dise<73>o clara. Vale la pena indicar que este curso fue dictado por profesores ocasionales durante los <20>ltimos cuatro a<>os, cada profesor utilizaba contenidos y niveles de exigencia diferentes.
En la tercera parte del curso se trabaja con sistemas microcontrolados, se utilizan microcontroladores de 8 bits de diferentes familias y se utiliza el lenguaje ensamblador como herramienta de desarrollo. Una de las principales desventajas que presenta este curso (y de la l<>nea en general) es la falta de continuidad en los contenidos y en la metodolog<6F>a utilizada, ya que el contenido de este curso se encuentra totalmente desligado al de los dos anteriores. Sin embargo, durante este curso se proporciona una metodolog<6F>a de dise<73>o en la que los estudiantes emulan el comportamiento del microcontrolador antes de ser programado, sin embargo, esta pr<70>ctica no es seguida por la mayor<6F>a de los estudiantes, una posible causa de este comportamiento puede ser la falta de metodolog<6F>as de dise<73>o en los cursos anteriores.
La sensaci<63>n que queda al terminar el <20>rea de electr<74>nica digital es que lo <20>nico que importa son los microcontroladores y que lo visto en los primeros cursos no es muy <20>til. La siguiente tabla muestra los problemas encontrados en el <20>rea de electr<74>nica digital de las carreras de Ingenier<65>a El<45>ctrica y Electr<74>nica de la Universidad Nacional de Colombia:
\begin{enumerate}
\item Falta de una metodolog<6F>a de dise<73>o.
\item Utilizaci<63>n de herramientas obsoletas: Familias L<>gicas, lenguajes de programaci<63>n.
\item Poco uso de las herramientas CAD.
\item Falta de continuidad en las asignaturas.
\item Falta de docentes.
\item No se suministra una formaci<63>n adecuada que ayude a la industria electronica a salir del retraso tecnol<6F>gico.
\end{enumerate}
\begin{enumerate}
\item Estudio de sistemas y algoritmos bio-inspirados: Algoritmos
Gen\'eticos (GA), Sistema Inmune Artificial (AIS), Hardware Evolutivo (EHW),
Chips de ADN, Aut\'omatas Celulares (CA), entre otros. el cu\'al ha
producido las siguientes publicaciones \cite{JSCC04c},\cite{JSCC04},\cite{JSCC03},\cite{JSCC04b}:
\begin{itemize}
\item J. Sep\'ulveda and C. Camargo. Implementaci\'on de un
Sistema InmuneArtificial sobre un FPGA para Reconocimiento de Patrones.
\textit{Memorias del X WorkShop de Iberchip}, 2004.
\item J. Sep\'ulveda, C. Camargo, and A. Delgado. El Problema
SAT: Enfoque Comparativo con ADN y FPGA. \textit{Memorias del
IX Workshop de Iberchip}, 2003.
\item J. Sep\'ulveda, C. Camargo, and A. Delgado.
Implementaci\'on de Chip de ADN en FPGA. \textit{Memorias del X Workshop de Iberchip}, 2004.
\item J. Sep\'ulveda, C. Camargo, and S. Bolivar.
Metodolog\'{\i}a de Implementaci\'on de Aut\'omatas Celulares
en FPGA. \textit{Memorias del X Workshop de Iberchip}, 2004.
\end{itemize}
\item Estudio del proyecto Embrionics, implementaci\'on de un arreglo de
c\'elulas en una FPGA; como resultado se obtuvo el siguiente art\'{\i}culo
{\cite{JEFS05}}:
\begin{itemize}
\item J. Espinosa, C. Camargo, and F. Segura. Evoluci\'on de un
Arreglo de C\'elulas Utilizando Algoritmos Gen\'eticos.
\textit{Memorias del XI Workshop de Iberchip}, 2005.
\end{itemize}
\item Estudio del proyecto Amorphous Computing.
\item Investigaci\'on en nuevas tecnolog\'{\i}as y en metodolog\'{\i}as de
dise<73>o de sistemas digitales:
\begin{enumerate}
\item Implementaci\'on de aplicaciones de Sistemas Embebidos utilizando
herramientas GNU y el sistema operativo de libre distribuci\'on
eCos{\footnote{http://sources.redhat.com/ecos}}, sobre un procesador ARM
(AT91 de Atmel y GameBoy Advance de Nintendo); como parte de este estudio
se publicaron los art\'{\i}culos {\cite{CC05}}, {\cite{FPFS+05}}:
\begin{itemize}
\item C. Camargo. Implementaci\'on de Sistemas Digitales
Complejos Utilizando Sistemas Embebidos. \textit{Memorias
del XI Workshop de Iberchip}, 2005.
\item F. Pedraza, C. Camargo, F. Segura, and A. Gauthier.
Control Adaptativo Embebido. \textit{Memorias
del XI workshop de Iberchip}, 2005.
\end{itemize}
\item Implementaci\'on de aplicaciones linux sobre una FPGA Spartan 3 de
Xilinx, utilizando el procesador microblaze de Xilinx.
\item Implementaci\'on de aplicaciones Java sobre una JVM implementada en
hardware{\footnote{http://www.jopdesign.com}} sobre una FPGA Spartan 3 de
Xilinx.
\item Desarrollo de aplicaciones sobre el sistema operativo linux
utilizando el SoC de Sharp LH79520.
\item Desarrollo de plataformas de desarrollo para FPGAs, SoC y
Procesadores ARM.
\end{enumerate}
\item Construcci\'on de la plataforma rob\'otica y desarrollo de Software y
Hardware para su funcionamiento:
\begin{itemize}
\item C. Camargo ECBOT: Arquitectura Abierta para Robots M\'obiles.
\textit{IEEE CWCAS'07 Noviembre Bogot\'a - Colombia.}
\end{itemize}
\end{enumerate}
\chapter{Paradigmas para la inteligencia Ubicua}
\section{Trabajo Previo}
En esta secci<63>n realizaremos una revisi<73>n de los trabajos realizados en las <20>reas relacionadas con auto-organizaci<63>n con implementaciones Hardware.....
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% AUTO - ORGANIZACION
\subsection{Auto-Organizaci<63>n}
Trabajos en Auto-Organizaci<63>n han sido desarrollados en muchos campos, Por ejemplo, en \cite{SOQX04} utilizan un protocolo de auto-organizaci<63>n para optimizar la energ<72>a de una red de sensores inal<61>mbricos, proporcionar adaptabilidad (en tama<6D>o, topolog<6F>a y densidad) a la infraestructura de comunicaciones y permite comunicaciones multi-hop
Las t<>cnicas para modelamiento de sistemas complejos se pueden dividir en aproximaciones \cite{JLXJ}:
\begin{itemize}
\item Top-Down: Comienza con una descripci<63>n de alto nivel del sistema y utiliza herramientas como ecuaciones diferenciales. Trata cada parte del sistema complejo de forma gen<65>rica y es efectivo modelando casos promedio, donde la diferencia de comportamiento de los individuos puede ser ignorada. Sin embargo, esta aproximaci<63>n no puede ser utilizada en todos los casos. Por ejemplo, las ecuaciones diferenciales no pueden modelar de forma precisa, la din<69>mica y el comportamiento emergente de algunos de los sistemas biol<6F>gicos (la distribuci<63>n de anticuerpos en el sistema inmunol<6F>gico humano tiende a ser heterog<6F>neo)
\item Bottom-Up: Comienza con una descripci<63>n de la entidad m<>s peque<75>a del sistema complejo y modela su funcionamiento de la siguiente forma:
\begin{itemize}
\item Aut<75>nomo: Los elementos del sistema son individuos racionales que act<63>an de forma independiente.
\item Emergente: Exhiben comportamientos complejos que no estan presentes o son predefinidos en el funcionamiento de las unidades aut<75>nomas.
\item Adaptativo: Modifican su comportamiento ante cambios en el entorno donde estan localizados.
\item Auto-Organizado: Son capaces de organizar los elementos para alcanzar los funcionamientos anteriormente mencionados.
\end{itemize}
\end{itemize}
Autonomy-Oriented Computing (AOC) \cite{JLXJ} es una aproximaci<63>n bottom-up que intenta resolver problemas computacionales de alto grado de dificultad o caracterizar el funcionamiento de sistemas complejos basado en la observaci<63>n de la naturaleza, los pasos para construir un modelo AOC son:
\begin{enumerate}
\item Observar el comportamiento macrosc<73>pico del sistema natural
\item Dise<73>ar las entidades funcionamiento deseado asi como el entorno donde residen dichas entidades.
\item Observar el comportamiento macrosc<73>pico del sistema artificial.
\item Validar el comporatmiento del sistema artificial con su contraparte natural.
\item Modificar el dise<73>o obtenido en 2) de acuerdo a los resultados obtenidos en 4)
\item Repetir 3) y 5) hasta encontrar el comportamiento deseado.
\item Encontrar un modelo de 1) en t<>rminos de 2).
\end{enumerate}
\subsection{Auto-Organizaci<63>n de sensores}
\cite{KPJZ}
El CEBOT \cite{TUTF} esta conformado por un gran n<>mero de unidades rob<6F>ticas aut<75>nomas, llamadas cel<65>las, cada una con capaz de realizar una funci<63>n simple. CEBOT permite configurar de forma din<69>mica la estructura del SW y HW con el f<>n de realizar una determminada funci<63>n o ante cambios en el entorno, esta reconfiguraci<63>n se logra modificando la interacci<63>n entre las c<>lulas. En este trabajo el comportamiento cooperativo se define como un comportamiento de la c<>lula para generar la configuraci<63>n estructural.
\section{Coordinaci<EFBFBD>n basada en el comportamiento de un sistema multi-robot\cite{JaMJM05}}
\subsection{Arquitecturas de control de robots}
\subsubsection{Control de un robot}
Aca se define el control de un robot como el proceso de mapear la informaci<63>n obtenida por los sensores del mismo en acciones en el mundo real. las aproximaciones para controlar un robot pueden describirse como un espectro que va desde el control deliberativo al reactivo.
La aproximaci<63>n deliberativa es computacionalmente intensiva, ya que utiliza razonamiento o planeaci<63>n expl<70>cita utilizando una representaci<63>n simb<6D>lica y modelos del mundo \cite{RK95}. Para que el proceso de razonamiento sea efectivo, se requiere que los modelos del mundo sean completos y precisos. En dominios donde dicho modelo es difi<66>cil de obtener, por ejemplo, en entornos din<69>micos y de r<>pido cambio o en situaciones donde exista una gran incertidumbre sobre los sensores y acciones de los robots, puede ser imposible para un robot actuar de forma adecuada utilizando este tipo de control.
En contraste al control deliberativo, el reactivo se caracteriza por tener un fuerte acople entre el sensado y la acci<63>n, donde t<>picamente no existe ning<6E>n tipo de razonamiento\cite{BC86}\cite{Bro91}. El control reactivo no requiere la creaci<63>n o el mantenimiento de modelos del mundo, ya que no se basa en procesos de razonamientos complejos utilizados en el control deliberativo. En lugar de esto, utilizan m<>todos que involucran una cantidad mpinima de computaci<63>n, representaci<63>n interna o cinicimiento del mundo. Esto hace al control reactivo adecuado para entornos din<69>micos, donde tener un modelo del mismo no es muy realista. A<>n mejor, la baja necesidad computacional permite a los sistemas reactivos responder de forma adecuada a din<69>micas de cambios r<>pidos.
El control h<>brido se encuentra localizado entre el control deliberativo y reactivo, en el cual un controlador posee componentes reactivos y deliberativos. EL control reactivo maneja tareas de control a bajo nivel que requieren una respuesta r<>pida, tal como evaci<63>n local de obst<73>culos. La parte deliberativa del control maneja tareas de alto nivel saobre una mayor escala de tiempo, tales como planeaci<63>n de camino (path planning). Adicionalmente el control hibrido debe tener una tercera capa que realice la interfaz entre el componente reactivo y el deliberativo. Esta arquitectura de tres capas pretende extraer lo mejor del control reactivo en t<>rminos de control din<69>mico y tiempo de respuesta y lo mejor lo mejor de los controladores deliberativos en la forma de acciones globales eficientes sobre una gran escala de tiempo. Sin embargo existen asuntos complejos que involucrados en la interfaz de estos dos componentes fundamentalmente distintos y la forma en la cual su funcionalidad puede ser particionada no es muy clara a<>n.
\subsection{Control Basado en el Comportamiento (BB)}
La aproximaci<63>n BB para el control de robots no puede ser clasificada como reactiva o deliberativa, ya que puede ser, y en mucho casos son, las dos. Sin embargo, el control BB se identifica m<>s con el control reactivo del espectro de control, porque se presta una gran atenci<63>n en mantener una estrecha realaci<63>n entre sensado y acci<63>n. \cite{Con92} \cite{Gat98}
Fundamentalmente un Controlador Basado en el Comportamiento esta compuesto por un grupo de componentes modulares,llamados \textit{funcionamientos}, los cuales, son ejecutados en paralelo. Un \textit{funcionamiento} es una ley de control que agrupa una serie de restricciones con el f<>n de alcanzar y mantener una meta.\cite{Mat97}\cite{Ark88}
Cada funcionamiento recibe entradas desde los sensores y/o otros funcionamientos y proporciona salidas los actudores del robot o a otros funcionamientos.
Los actuadores pueden compartir entradas de sensores y enviar comandos de salida a los mismos actuadores. El escoger una determinada acci<63>n ante m<>ltiples entradas de sensores y funcionamientos secibe el nombre de \textit{Selecci<EFBFBD>n de acci<63>n}\cite{Pir00}. Uno de los mecanimos mejor conocidos para selecci<63>n de acci<63>n es el uso de una jerarqu<71>a de funcionamiento predefinida, como la \textit{Subsumption Architecture \cite{Bro86}}, en la cual, los comandos de los funcionamientos activos de mayor-rango son enviados al actuador y los otros son ignorados.
Los sistemas BB son variados, pero existem dos principios fundamentales a los que todos los sistemas BB se adhieren inherentemente: 1) En robot posee un cuerpo f<>sico y su funcionamiento est<73> limitado por realidades fisicas, incertidumbres y consecuencias de sus acciones, todas ellas dif<69>ciles de predecir y 2) El robot est<73> imerso en un mundo real y act<63>a directamente en base a la informaci<63>n de sus sensores, no sobre una representaci<63>n abstracta o procesada del mismo.
\subsection{Desde el control de un robot a control de m<>ltiples robots}
Los Sistemas distribuidos Multi-Robot contrastan con los sistemas centralizados Multi-Robot, en los cuales, todas las acciones de un robot no son determinadas localmente, ellas deben ser determinadas por una entidad externa, tal como otro robot o por cualquier tipo de comando externo. En los sistemas multi-Robot distribuidos, cada robot debe tomar sus propias decisiones de control, bas<61>ndose <20>nicamente en la informaci<63>n de sus sensores, la cual es limitada, local y con presencia de ruido.
\subsubsection{Ventajas y Retos en los sistemas Multi-Robot}
Las potenciales ventajas de los Sistemas Multi-Robot sobre los SRS (Simple Robot System) incluyen una reducci<63>n del costo total del sistema, al utilizar robots simples y econ<6F>micos en lugar de un robot complejo y costoso. Adem<65>s, una arquitectura Multi-Robot puede aumentar la flexibilidad y robustez del sistema tomando ventaja del paralelismo y la redundancia. Asimismo, la complejidad inherente de algunos entornos de trabajo requiere el uso de una arquitectura Multi-Robot, cuando las capacidades o los requerimientos de recursos necesarios son muy grandes para ser alcanzados por un solo robot.
Sin embargo, la utilizaci<63>n de Sistemas Multi-Robot (MRS) presenta desventajas potenciales y retos adicionales que deben ser tratados para que presenten una alternativa efectiva y viable a los SRS. Un sistema MRS dise<73>ado pobremente, con robots individuales trabajando en oposici<63>n, puede ser menos efectivo que un sistema SRS dise<73>ado cuidadosamente. El reto m<>s grande en el dise<73>o de sistemas MRS efectivos es el manejo de la complejidad introducida por la interacci<63>n entre los robots.
\subsubsection{Necesidad de Coordinaci<63>n en Sistemas Multi-Robot}
Con el f<>n de maximizar la efectividad de un MRS, las acciones de los robots deben ser espacio-temporalmente coordinadas y dirigirlas hacia el logro de una determinada tarea o un determinado objetivo a nivel de sistema. El solo hecho de tener robots interactuando entre si, no es suficiente para producir un comportamiento a nivel de sistema coordinado, interesante o pr<70>ctico. Para que la interacci<63>n de los robots produzcan funcionamientos coherentes, debe existir algun mecanismo de coordinaci<63>n que organice espacio-temporalmente las interacciones de forma apropiada para la tarea.
\subsection{Coordinaci<EFBFBD>n global a partir de interacciones locales}
Existen muchos mecanismos por los cuales se pueden organizar las interacciones. Nosotros los clasificaremos en tres clases: Interacci<63>n a trav<61>s del entorno, interacci<63>n a trav<61>s de sensores, e interacci<63>n a trav<61>s de comunicacion. Estas clases no son mutuamente excluyentes ya que los MRS pueden y en algunos casos utilizan mecanismos simult<6C>neos de cualquiera o de las tres clases para alcanzar un funcionamieno coordinado a nivel de sistema.
\subsubsection{Interacci<EFBFBD>n por medio del entorno}
El primer mecanismo de interacci<63>n es atrav<61>s del entorno compartido de los robots. Esta forma de interacci<63>n es indirecta, ya que no existe comunicaci<63>n expl<70>cita o f<>sica entre los robots. En lugar de esto, el mismo entorno se utiliza como medio de la comunicaci<63>n indirecta.
Con el cuidadoso dise<73>o de los sensores, actuadores y las cualidades del control, es posible utilizar el concepto de
\textit{stigmergy \cite{HM99}\footnote{\textit{Stigmergy} es un m<>todo de comunicaci<63>n indirecta en un sistema de auto-organizaci<63>n emergente, donde sus partes individuales se comunican con las otras modificando su entorno local.}} en MRS. Este poderoso mecanismo de coordinaci<63>n es muy atractivo ya que t<>picamente requiere capacidades m<>nimas de los robots individuales. Los robots no requieren comunicaci<63>n directa, solo reconocer a los otros robots o distinguirlos entre diferentes objetos en el entorno, tampoco requieren realizar razonmientos computacionales intensivos de razonamiento y planeaci<63>n.
Las acciones de construcci<63>n de un robot alteran el entorno, y por lo tanto la informaci<63>n de los sensores disponible para los otros robots. Esta nueva informaci<63>n activa acciones de construcci<63>n posteriores.
\subsubsection{Iteracci<EFBFBD>n atrav<61>s de sensores}
El segundo mecanismo para la interacci<63>n entre robots es atrav<61>s de sensores. Como se describe en \cite{CFK97}, la interacci<63>n utilizando sensores se refiere a interacciones locales que pueden ocurrir entre robots como resultado de el sensado de otro robot., pero sin comunicaci<63>n expl<70>cita. Al igual que la interacci<63>n por medio del entorno, la interacci<63>n utilizando sensores es tambi<62>n indirecta ya que no existe comunicaci<63>n expl<70>cita entre los robots; sin embargo, requiere que cada robot sea capaz de distinguir otros robots entre diferentes objetos del entorno. En algunas circunstancias, cada robot puede ser requerido para identificar a todos los dem<65>s robots, o clases de los otros robots. En otros casos, puede ser necesario distingir robots de otros objetos del entorno.
La interaci<63>n por medio de sensores puede ser usada por un robot para modelar el comportamiento de otros robots o para determinar que est<73> haciendo otro robot con el f<>n de tomar decisiones y reponder de forma adecuada. Por ejemplo, las bandadas de aves utilizan sus sensores para monitorear las acciones de otras aves en su vecindad para hecer correcciones locales a su propio movimiento. Ha sido demostrado que los resultados efectivos del grupo a partir de relativamente simples reglas locales seguidas por cada ave respondiendo a la direcci<63>n y velocidad de los vecinos locales \cite{Rey87}.
Otros dominios en los cuales la interacci<63>n a trav<61>s de sensores han sido utilizada en MRS inclute \textit{flocking}\cite{Mat95}, en donde cada robot ajusta su movimiento de acuerdo al movimiento de los robots observados localmente. La interacci<63>n a trav<61>s de sensores tambi<62>n ha sido demostrada en el dominio de divisi<73>n adaptativa de tareas \cite{JM03}. En este dominio, cada robot cambia de forma din<69>mica las tarea que est<73> ejecutando bas<61>ndose en las acciones observadas de otros robots y la disponibilidad de tareas en el entorno.
\subsubsection{Caso de Estudio Interacci<63>n por medio de Sensores: Formaci<63>n de marcha}
La aproximaci<63>n a la formaci<63>n de marcha aca descrita fu<66> presentada en \cite{FM02}. La idea general de esta aproximaci<63>n es que cada robot en el MRS se posiciona el mismo relativamente a un robot vecino designado. Este robot vecino, a su vez, se posisiona el mismo de forma relativa a su propio robot vecino designado. Ya que todos los robots solo tienen en cuanta su posici<63>n relativa con respecto a su robot vecino, ning<6E>n robot esta, ni necesita estar pendiente de, la posici<63>n global de todos los robots en la formaci<63>n. Cada robot solo necesita ser capaz de determinar la distancia y direcci<63>n a su vecino. La geometr<74>a global de la formaci<63>n fue determinada a trav<61>s de la cadena de vecinos. La formaci<63>n puede ser cambiada de forma din<69>mica alterando la estructura de la relaci<63>n local del vecino.
\subsubsection{Interacci<EFBFBD>n por medio de comunicaci<63>n}
La comunicaci<63>n en los robots f<>sicos no es gratuita o confiable y puede ser restringida limitanfo el ancho de banda y el alcance, y la inpredecible interferencia. En los sistemas reales de robots, el rango y la confiabilidad de la comunicaci<63>n son factores de dise<73>o muy importantes \cite{GM(.I.W01}.
Existen muchos tipos de comunicaci<63>n. La comunicaci<63>n puede ser directa de un robot a otro, de un robot a una clase de robots, o difundir desde un robot a todos los dem<65>s robots. As<41> mismo, los protocolos pueden ir desde esquemas simples carentes de protocolo a esquemas complejos basados en negociaci<63>n y comunicaci<63>n intensiva. La informaci<63>n codificada en una comunicaci<63>n puede ser informaci<63>n de estado, un comando a uno o m<>s robots, una petici<63>n de informaci<63>n adicional por otros robots.
\subsubsection{Casi de estudio Interacci<63>n por medio de comunicaci<63>n: Seguimiento de m<>ltiples objetivos}
En \cite{Par97}, el objetivo es tener un grupo de robots con rangos de sensores limitados se posicionan y orientan ellos mismos de tal forma que son capaces de adquirir y seguir multiples objetos que se mueven a trav<61>s de su entorno. Las posiciones, trayectorias y numero de objetivos no se conocen a priori. Estas dificultades son compuestas en un MRS distribuido, donde el sistema debe determinar que robot(s) deben monitorear que objetivo(s). Cada robot tiene un rango limitado de sensores y comunicaci<63>n. La comunicaci<63>n fue utilizada por cada robot para transmitir la posici<63>n y velocidad de todos los objetivos dentro de su rango de sensado a los dem<65>s robots dentro de su rango de comunicaci<63>n.
Cada robot eval<61>a constantemente la importancia de su actual actividad de seguimiento y los posibles cambios de posici<63>n que podr<64>an aumentar la importancia de sus actividades de seguimiento. La comunicaci<63>n fue utilizada para permitir a cada robot mantener un mapa local de los movimientos de los objetivos dentro del rango de comunicaci<63>n pero fuera fuera de su rango de sensado. Como resultado, el grupo como un todo, pudo seguir un n<>mero m<>ximo de objetivos, con un m<>nimo n<>mero de robots.
\subsection{Dise<EFBFBD>o formal y an<61>lisis de un Sistema Multi-Robot}
El dise<73>o de los mecanismos de coordinaci<63>n para un sistema multi-robot (MRS) ha probado ser un problema dificil de resolver. En la <20>ltima d<>cada, el dise<73>o de una variedad de tales mecanismos sobre un amplio rango de dominios de aplicaci<63>n ha sido estudiado \cite{CFK97b} \cite{DJM+02}.
Las siguientes preguntas deben ser resueltas antes de poder producir r<>pida y eficientemente un MRS efectivo para una nuevo dominio:
\begin{itemize}
\item Que tan apropiado es un determinado mecanismo de coordinaci<63>n para un dominio en particular.
\item Que caracter<65>sticas de desempe<70>o se pueden esperar de el.
\item Como esta relacionado con otros mecanismos de coordinaci<63>n.
\item Como se puede modificar para aumentar el desempe<70>o del sistema.
\end{itemize}
El paradigma BB para control multi-robot es popular en MRS debido a su robustez a las interacciones din<69>micas inherentes a cualquier MRS. Un MRS representa un sistema de alta no linealidad en el cual las acciones de un robot son afectadas por las acciones de los dem<65>s rebots. Esto hace que cualquier esquema de control que se base en razonamiento o planeaci<63>n complejos no sean efectivos debido a que es muy dif<69>cil predecir de forma precisa futuros estados de un sistema MRS no trivial. Por esta raz<61>n, el control BB es utilizado frecuentemente en MRS. La simplicidad del robot individual tambien presenta una ventaja al permitir que sea posible el an<61>lisi externo para predecir el desempe<70>o del sistema.
\subsubsection{Analisis de Sistemas Multi-Robot Utilizando Modelos Macrosc<73>picos}
Los modelos macrosc<73>picos se enfocan en el funcionamiento a nivel de sistema del MRS sin considerar de forma expl<70>cita cada robot individualmente en el sistema.
Un modelo matem<65>tico macrosc<73>pico MRS ha sido demostrado en el dominio de tareas de recolecci<63>n de alimentos \cite{LG02}. El modelo fu<66> usado para estudiar los efectos de la interferencia entre robots, el resultado pudo ser utilizado para modificar el control individual de los robots o para determinar la densidad <20>ptima de robots con el f<>n de maximizar el desempe<70>o de la tarea. Un modelo anal<61>tico macrosc<73>pico ha sido aplicado para el estudio de la din<69>mica del comportamiento colectivo en un dominio colaborativo utilizando una serie de ecuaciones diferenciales \cite{LGM+01}.
Un modelo macrosc<73>pico general para el estudio de sistemas adaptativos multi-agente fu<66> presentado en \cite{LG03} y fu<66> aplicado al an<61>lisis en el dominio de localizaci<63>n de tareas que fu<66> realizado de forma experimental en \cite{JM03}. En este trabajo los robors que forman el MRS mantienen una cantidad limitada de estados internos persistentes para representar una historia corta de eventos pasados, pero no se comunican de forma expl<70>cita con otros robots.
\subsubsection{An<EFBFBD>lisi de Sistemas Multi-Robot Utilizando Modelos Microsc<73>picos}
El modelamiento microsc<73>pico considera directamente cada robot en el sistema y puede modelar de forma individual las interacciones de un robot con otros robots y con la tarea con un detalle arbitrario, incluyendo la simulaci<63>n exacta del funcionamiento de cada robot. Sin embargo, la mayor<6F>a de las aproximaciones microsc<73>picas modelan el funcionamienro de cada robot como una serie de eventos estoc<6F>sticos. T<>picamente, el controlador del robot individual es abstraido a alg<6C>n grado y las trayectorias e interacciones no son consideradas directamente.
Una metodolog<6F>a de modelamiento microsc<73>pico probabil<69>stico para el estudio de funcionamiento colectivo en en dominio de clustering fu<66> presentado en \cite{MIM99}. El modelo fu<66> validado a trav<61>s de un acuerdo cuantitativo entre la predicci<63>n de la evoluci<63>n del tama<6D>o del cluster, con la simulaci<63>n de experimentos y con experimentos sobre robots reales. La efectividad y precisi<73>n de las t<>cnicas de modelamiento macrosc<73>pico y microsc<73>pico comparadas con los experimentos con robots reales y simulaciones se discuten en \cite{ME02}.
Un paso hacia adelante en las metodolog<6F>as para el an<61>lisis formal de un determinado dise<73>o MRS se encuentra en las metodolog<6F>as formales para la s<>ntesis de controladores MRS. La s<>ntesis es el proceso de construcci<63>n de un controlador MRS que cumple con las restricciones del dise<73>o, tales como alcanzar el nivel de desempe<70>o deseado mientras cumple las restricciones impuestas por las limitadas capacidades del robot.
Ser capaz de definir un dominio de aplicaci<63>n y tener un m<>todo formal que dise<73>e el MRS para cumplir con la tarea mientras se alcanza el criterio de desempe<70>o especificado es uno de los objetivos de largo plazo en la comunidad MRS.
Una herramienta de trabajo importante en el dise<73>o formal de MRS coordinados fu<66> el desarrollo de \textit{information invariants}, la cual intenta definir los requerimientos de informaci<63>n de una tarea dada e indica cual de estos requerimientos pueden ser alcanzados en un contolador \cite{Don95}. El concepto de \textit{information invariants} fu<66> estudiado experimentalmente en el dominia de manipulaci<63>n distribuida de tareas \cite{DJR95} y fu<66> extendido a trav<61>s de la definici<63>n de equivalencia de clases entre definiciones de tareas y capacidades del robot para ayudar en la elecci<63>n de una clase de controlador apropiada en un dominio dado \cite{Par98}.
Otras aproximaciones alternativas a la s<>ntesis de controladores MRS pueden ser encontrados en m<>todos evolutivos \cite{Mat95} \cite{Par98b}. Tambi<62>n existen un n<>mero de entornos de dise<73>o de MRS, arquitecturas de control, y lenguajes de programaci<63>n, los cuales ayudan en el dise<73>o de MRS coordinados \cite{Mat95b} \cite{AB97} \cite{AGH+00}
%*******************************************************************************************************************
\subsection{Asignaci<EFBFBD>n d<>n<EFBFBD>mica de tareas \cite{KLCJ+0}}
En un MRS distibuido no existe un mecanismo de control centralizado, a cambio, cada robot opera de forma independiente bajo control y sensado local, con un comportamiento coordinado a nivel de sistema que resulta de las interacciones locales entre los robots y entre los robots y el entorno. El dise<73>o efectivo de un MRS coordinado est<73> restringido por la carencia de herramientas de dise<73>o y metodolog<6F>as formales. El dise<73>o de un SRS (Single Robot System) se ha visto beneficiado en gran medida por los formalismos proporcionados por la teor<6F>a de control -- el dise<73>o de MRS esta necesitando un formalismo an<61>logo.
Para que un grupo de robots realicen de forma efectiva una determinada tarea a nivel de sistema, el dise<73>ador debe hacerse la pregunta: <20>Qu<51> robot puede realizar que tarea y cuando?. La asignaci<63>n din<69>mica de tareas es una clase de asignaci<63>n de tareas en la cual, la asignaci<63>n de robots a las sub-tareas es un proceso din<69>mico y puede requerir un ajuste continuo en respuesta a cambios en el entorno de la tarea o al desempe<70>o del grupo. El problema de la asignaci<63>n de la asigaci<63>n de tareas en un MRS distribuido esta compuesto por el hecho que la asignaci<63>n debe ocurrir como resultado de un proceso distribuido ya que no existe un coordinador central para hacer estas asignaciones. Esto aumenta la complejidad del problema ya que debido al rango local de los sensores del robot, ning<6E>n robot posee una visi<73>n completa del estado del mundo. Con esta informaci<63>n incompleta y en algunos casos ruidosa, cada robot debe hacer decisiones locales de control sobre que acciones realizar y cuando, sin un conocimiento completo de que est<73>n haciendo otros robots que la hayan realizado en el pasado, o que har<61>an en el futuro \cite{KLCJ+}.
Existe un n<>mero de modelos y filosof<6F>as de asignaci<63>n de tareas. Hist<73>ricamente, la m<>s popular se basa en la coordinaci<63>n intencional para lograr la asignaci<63>n de tareas \cite{Par98b}. En esta, los robots coordinan sus respectivas acciones de forma expl<70>cita a trav<61>s de comunicaciones y negocioaciones deliberadas. Debido a problemas relacioados con la escala, dichas aproximaciones son utilizadas en MRS con un numero relativamente peque<75>o de robots (i.e. menor que 10). Este m<>todo es el preferido debido a que es el m<>s conocido, f<>cil de dise<73>ar e implementar, y m<>s adecuado para el an<61>lisis formal \cite{BPG}.
Al aumentar el tama<6D>o del MRS, la complejidad introducida al aumentar las interacciones de los robots, hace que estos sistemas sean m<>s dif<69>ciles de analizar y dise<73>ar. Esto lleva a la alternativa de coordinaci<63>n intencional, es decir, asignaci<63>n de tareas utilizando coordinaci<63>n emergente. En sistemas que utilizan la coordinaci<63>n emergente, los robots individuales coordinan sus acciones basad<61>ndose <20>nicamente en informaci<63>n local de sensores e interacciones locales. T<>picamente, existe muy poca o ninguna comunicaci<63>n directa o negociaciones expl<70>citas entre los robots. Ellos son, por lo tanto, m<>s escalables a grandes n<>meros de robots y son m<>s capaces de tomar ventaja de la robustez y paralelismo provisto por la agregaci<63>n de grandes n<>meros de robots coordinados.
\subsubsection{Trabajo relacionado}
Sugawara et al \cite{KSMS97} \cite{KSMS+} desarrollaron un modelo simple de recolecci<63>n de alimentos cooperativo en grupos de robots con y sin comunicaci<63>n. Kazadi et al. [11] \cite{SKAA02} estudi<64> la propiedad general de una agregaci<63>n multi-robot utilizando modelos mocrosc<73>picos fenomenol<6F>gicos. Agassounon y Martinoli \cite{WAAM02} presentan un modelo de agregaci<63>n en el cual el n<>mero de robots toman parte de en la tarea de clustering se basa en el mecanismo de divisi<73>n de labores de las antenas.
Estos modelos son ad-hoc y e dominio espec<65>fico, y los autores no dan explicaci<63>n de como aplicar estos modelos a otros dominios. En trabajos recientes hemos desarrollado un marco de trabajo general para crear modelos fenomenol<6F>gicos de funcionamiento colectivo en grupos de robots \cite{KLAG04} \cite{KLAM05}.
Muchas de las aproximaciones listadas arriba est<73>n de forma impl<70>cita o expl<70>cita basadas en la teor<6F>a de procesos estoc<6F>sticos. Otro ejemplo de una aproximaci<63>n estoc<6F>stica es el modelo probabil<69>stico desarrollado por Martinoli y sus colaboradores \cite{AMPt99} \cite{AMAJI99} \cite{AJI+01} para estudiar el funcionamiento colectivo de un grupo de robots.
Muy poco trabajo ha sido desarrollado sobre an<61>lisis de sistemas multirobot en entornos din<69>micos. En \cite{KLAG03} se extiende el marco de trabajo de los procesos estoc<6F>sticos desarrollado en trabajos recientes, a robots que cambian su comportamiento bas<61>ndose en la historia de observaciones locales del (probablemente cambiante) entorno \cite{LG03}.
En \cite{BAH88} Huberman y Hogg, realizaron un estudio matem<65>tico sobre funcionamiento colectivo de sistemas de agentes adaptativos utilizando la din<69>mica de juego como un mecanismo de adaptaci<63>n. En los sistemas de din<69>mica de juegos, las estrategias ganadoras son premiadas, y los agentes utilizan las mejores estrategias para decidir su pr<70>ximo movimiento.
\subsubsection{Mecanismos de asignaci<63>n de tareas}
El esenario de asignaci<63>n de tareas din<69>mico estudiado considera un mundo poblado con tareas de \textit{T} tipos diferentes y robots que son igualmente capaces de realizar cada tarea, pero solo se les puede asignar un tipo de tarea en un momento dado. El estado de un robot es un atajo para el tipo de tarea asignada al robot. Un robot puyede cambiar su estado de acuerdoa sus pol<6F>ticas de control cuando lo determine apropiado (evitando cambios de tarea no necesarios).
El prop<6F>sito de la asignaci<63>n de tareas es asignar robots a las tareas de una forma que aumente el desempe<70>o del sistema, lo que normalmente significa reducir el tiempo total de ejecuci<63>n. Esto es, si todas las tareas toman igual cantidad de tiempo en completarse, en la mejor asignaci<63>n, la fracci<63>n de robots en el estado \textit{i} ser<65> igual a la fracci<63>n de tareas de tipo \textit{i}. En general, sin embargo, la asignaci<63>n deseada puede tomar otras formas, -- por ejemplo, puede estar relacionada a la recompensa relativa o costo de realizaci<63>n total (completing) de cada tipo de tarea -- sin cambiar nuestra aproximaci<63>n. En el escenario de asignaci<63>n din<69>mica de tareas, el n<>mero de tareas y el n<>mero de robots disponibles pueden variar en el tiempo, por ejemplo, agragando nuevas tareas, desarrollando nuevos robots, o removiendo robots defectuosos.
El reto al que se enfrenta el dise<73>ador es divisar un mecanismoque permita una asignaci<63>n de tareas deseada en un MRS distribuido ante cambios en el entorno. Se asume que los robots son capaces de observar tareas y discriminar sus tipos. Ellos tambi<62>n son capaces de observar y discriminar los estados de las tareas de los otros robots.
Una forma de dar al robot la habilidad de responder a cambios en el entorno es dotarlo con un estado interno donde el puede almacenar su conocimiento del mundo capturado por sus observaciones \cite{CVJ03} \cite{KLAG03}. Las observaciones son almacenadas en una lista continua c<>clica de longitud finita, donde las nuevas observaciones reemplazan las anteriores. El robot consulta estas observaciones peri<72>dicamente y actualiza su estado de acuerdo a una funci<63>n de transici<63>n especificada por el dise<73>ador \cite{LG03} \cite{CVJ03}.
\subsection{Analisis de Asignci<63>n Autom<6F>tica de Tareas}
En esta secci<63>n asumiremos que existen dos tipos de tareas, -- denominadas de forma arbitraria \textit{red} y \textit{green}. Esta simplificaci<63>n se hace con fines pedag<61>gicos, el modelo puede expandirse. Durante un intervalo de tiempo suficientemente corto, puede considerarse que cada robot permanece en la tarea Red o Green, cada tarea esta compuesta por muchas acciones y funcionamientos del robot, por ejemplo, buscando nuevas tareas, detectando y ejecut<75>ndolas, evitando obst<73>culos, etc. Sin embargo, ya que lo que se desea es modelar como evoluciona en el tiempo la fracci<63>n de robots en cada tarea, es suficiente considerar solo estos dos estados. Si encontramos que se necesitan niveles de detalle adicionales para explicar el funcionamiento del sistema podemos elaborar el modelo descomponiendo los estados de alto nivel en sus componentes.
\subsubsection{Observaci<EFBFBD>n de tareas}
En esta secci<63>n estudiaremos en mecanismo en el cual los robots hacen decisiones paea cambiar de estado de tarea bas<61>ndose <20>nicamente en la observaci<63>n de las tareas disponibles. Sean $m_{r}$ y $m_{g}$ el n<>mero de tareas Red y Green observadas, en la memoria de un robot. El robot elige cambiar su estado o el tipo de tarea a la que esta asignado, con probabilidades dadas por las funciones de transici<63>n $f_{g \to r}(m_{r}, m_{g})$ (probabilidad de cambiar a Red desde Green) y $f_{r \to g}(m_{r}, m_{g})$ (probabilidad de cambiar a Green desde Red). Se desea definir reglas de transici<63>n de tal forma que la fracci<63>n de tiempo que el robot est<73> en el estado Red (Green) sea igual a la fracci<63>n de tareas Red (Green). Esto asegura que en promedio el n<>mero de robots Red y Green refleja la distribuci<63>n de tareas deseada. Si los robots tienen conocimiento global sobre el n<>mero de tareas Red Y Green $M_{r}$ y $M_{g}$, entonces cada robot podr<64>a elegir cada estado con probabilidades igual a la fracci<63>n de las tareas del tipo correspondiente. Dicho conocimiento no est<73> disponible; por eso, se desea investigar comoo el observamiento incompleto del entorno (a trav<61>s de observaciones locales) as<61> como de los cambios din<69>micos del mismo (por ejemplo, cambiando la relaci<63>n entre tareas Red y Green), afectan la asignaci<63>n de tareas.
\subsection{Recolecci<EFBFBD>n m<>ltiple con M<>ltiples Robots}
\subsubsection{Descripci<EFBFBD>n de la tarea}
La tarea tradicional de recolecci<63>n se define al tener un robot o grupo de robots recolectando un grupo de objetos del entorno, cada uno consume uno y regrese a un lugar com<6F>n \cite{DGMJM02}. La recolecci<63>n m<>liple, es una variaci<63>n de la recolecci<63>n tradicional, se define en \cite{TB99} y consiste en una arena poblada por objetos de varios tipos que deben ser recolectados de forma concurrente.
Existen dos tipos de objetos dispersados de forma aleatoria a lo largo de la arena: \textit{PuckRed} y \textit{PuckGreen}. Cada robot es capaz de recolectar ambos tipos de objetos, pero solo puede ser asignado a la recolecci<63>n de un tipo en un instante de tiempo dado. Adicionalmente, todos los robots est<73>n recolectando todo el tiempo, es decir, no existen robots en estado de ``inactividad''. Un robot puede cambiar el tipo de objeto que est<73> recolectando de acuerdo a su pol<6F>tica de control, cuando el determina que es apropiado hacerlo. Los robots se mueven en un espacio cerrado y recogen los objetos que van encontrando. Cuando un robot recoge un objeto, el objeto es consumido y el robot lo lleva al sitio de recolecci<63>n de los otros objetos. Una vez que se consume el objeto, se coloca otro del mismo tipo de forma inmediata en un lugar aleatorio. Esto se hace para mantener la densidad de objetos constante.
\textit{En algunas ocaciones, la densidad de objetos puede afectar la precisi<73>n o la velocidad de convergencia a la asignaci<63>n de tareas deseada. \textbf{Nos reservamos el estudio del impacto de la variaci<63>n de densidad para trabajos futuros}}
El papel de la asignaci<63>n din<69>mica de tareas en este dominio requiere que los robots dividan su n<>mero recolectando unos los objetos \textit{PuckRed} y otros los \textit{PuckGreen}. En este experimento, se desea que la asignaci<63>n de robots converja a una situaci<63>n en la que la proporci<63>n de robots recolectando objetos \textit{PuckRed} sea igual a la proporci<63>n de objetos \textit{PuckRed} presentes en la arena.
Se ha observado que las capacidades limitadas de sensado y la falta de comunicaci<63>n directa de los robots, les impide adquirir informaci<63>n global tal como el tama<6D>o y forma de la arena de recolecci<63>n, el n<>mero inicial o actual de objetos a ser recolectados (total o por tipo), o el n<>mero inicial o total de robots recolectores (total o por tipo).
\textit{Utilizar la red idiot<6F>pica para aumentar el conocimiento del robot sobre el entorno}
\subsubsection{Controlador del robot basado en funcionamiento}
Todos los robots tienen controladores id<69>nticos basados en el comportamiento, los cuales consisten en los siguientes comportamientos mutuamente excluyentes:
\begin{itemize}
\item El comportamiento \textit{ovoiding} provoca que el robot gire para evitar obst<73>culos en su camino.
\item El comportamiento \textit{wandering (caminar sin una direcci<63>n determinada)} provoca que el robot se mueva hacia adelante y, despu<70>s de un lapso de tiempo aleatorio, gire a la izquierda o a la derecha describiendo un arco aleatorio por un per<65>odo de tiempo aleatorio.
\item El comportamiento \textit{Puck Servoing} hace que el robot se mueva hacia un objeto (detectado) del tipo deseado.
\item El comportamiento \textit{Grasping} hace que el robot recoja y consuma un objeto.
\item El comportamiento \textit{Observing} hace que el robot tome la informaci<63>n de sus sensores y almacene los objetos y robots detectados en su respsctiva historia. El robot entonces actualiza su estado de recolecci<63>n basado en esas historias.
\end{itemize}
\begin{tabular}{|c|c|c|c|c|}
\hline
\multirow{2}{1.8cm}{Obst<EFBFBD>culo Detectado} & \multirow{2}{1.8cm}{Objeto Detectado} & \multirow{2}{2.7cm}{Gripper Break-Beam On} & \multirow{2}{2cm}{Se<EFBFBD>al de Observaci<63>n} & \multirow{2}{2.2cm}{Funcionamiento Activo} \\ \\ \hline
X & X & X & 1 & Observing \\ \hline
1 & X & X & X & Avoiding \\ \hline
0 & 1 & 0 & 0 & Puck Servoing \\ \hline
0 & X & 1 & 0 & Grasping \\ \hline
0 & X & X & X & Wandering \\ \hline
\end{tabular}
\tablename{Condiciones de activaci<63>n de los comportamientos}
Todos los robots mantienen tres tipos de informaci<63>n de estado: estado de recolecci<63>n, historia de objetos observados, e historia de robots observados. Cada robot es dotado con un indicador luminoso observable por los robots cercanos, el cual indica el estado actual del robot. Es decir, este indicador luminoso act<63>a como una comunicaci<63>n local, pasiva.
Todos los robots mantienen una historia limitada de tama<6D>o constante donde se almacena el estado de recolecci<63>n de los robots observados recientemente. Ninguna de estas historias contiene una identidad <20>nica o localizaci<63>n de los objetos o robots detectados.
Despu<EFBFBD>s que el robot hace una observaci<63>n, hace una re-evaluaci<63>n y cambia de forma probabil<69>stica su estado actual de recolecci<63>n dadas las nuvas historias de objetos y robots. La probabilidad con la cual el robot cambia su estado de recolecci<63>n se define con la funci<63>n de transici<63>n.

View File

@@ -0,0 +1,564 @@
\chapter{TRANSFERENCIA TECNOL<4F>GICA}
\begin{quote}
"Social development today is determined by the ability to stablish a synergistic interaction between technological innovation and human values"
Castells 1999
\end{quote}
La transferencia de tecnolog<6F>a seg<65>n Van Gigch involucra la adquisici<63>n de "actividad Inventiva" por parte de usuarios secundarios. Es decir, la
transferencia tecnol<6F>gica no involucra necesariamente maquinaria o dispositivos f<>sicos. El conocimiento puede ser transferido a trav<61>s de entrenamiento y
educaci<EFBFBD>n, y puede incluir temas como manejo efectivo de procesos y cambios tecnol<6F>gicos\cite{FBFP07} .
La transferencia tecnol<6F>gica es un proceso din<69>mico que debe ser re-evaluado peri<72>dicamente, requiere una infraestructura adecuada que involucra
instituciones, institutos de formaci<63>n vocacional, t<>cnica y administrativa, personal con diferentes especialidades y un entorno cultural adecuado.
Es dif<69>cil que la tecnolog<6F>a desarrollada en un entorno determinado pueda ser transferida sin realizar modificaciones en la escala de producci<63>n y
la adopci<63>n de productos al mercado local.
La transferencia de tecnolog<6F>a ha introducido t<>cnicas de alta productividad y en muchos casos cambios t<>cnicos en pa<70>ses menos desarrollados.
La adquisici<63>n de tecnolog<6F>a for<6F>nea contribuye a mejorar la competitividad en los mercados locales e internacionales en estos pa<70>ses, en los que debe
ser considerada como un proceso vital. Este proceso presenta problemas cuando se pierde capacidad de absorci<63>n por parte del pa<70>s receptor y la
renuencia del pa<70>s que transfiere a transferir tecnolog<6F>a real y el know-how. Por lo que es necesario que estos pa<70>ses promuevan sus capacidades
tecnol<EFBFBD>gicas locales con el fin de absorber las tecnolog<6F>as for<6F>neas de forma eficiente en funci<63>n de sus necesidades locales y de esta forma forma
generar un r<>pido proceso de industrializaci<63>n.
No debe confundirse la transferencia tecnol<6F>gica con la apropiaci<63>n de tecnolog<6F>a que se define como el proceso de interacci<63>n con la tecnolog<6F>a,
la modificaci<63>n de la forma como es usada y el marco social dentro del cual es usada. Un ejemplo de apropiaci<63>n de tecnolog<6F>a lo podemos encontrar
en la telefon<6F>a celular, nuestras sociedades han cambiado dr<64>sticamente su forma de comunicarse y han generado nuevas actividades alrededor de esta
tecnolog<EFBFBD>a, los usuarios pueden generar aplicaciones que adicionan funcionalidades y servicios.
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%% DEFINICION DE TRANSFERENICA TECNOLOG<4F>A %%%%%%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\section{Tecnolog<EFBFBD>a}
La tecnolog<6F>a es definida como el factor m<>s significativo para mejorar la productividad, calidad y competitividad \cite{GC04} y puede verse como
un proceso de transformaci<63>n de recursos que tiene como entrada recursos naturales, bienes, o preductos semi-manufacturados y como salida se obtienen
bienes consumibles de capital y semi-manufacturados. El \textit{Technology Atlas team} identifica cuatro componentes de la tecnolog<6F>a \cite{FBFP07}:
\begin{itemize}
\item Techno-ware Relacionado con objetos: Herramientas, equipos, m<>quinas, veh<65>culos, facilidades f<>sicas, instrumentos, dispositivos y f<>bricas
\item Human-ware Relacionado con personas: Habilidades en conocimiento experimental, sabidur<75>a y creatividad, experiencia, competencia, creatividad.
\item Info-ware Relacionado con la Informaci<63>n: Incluye todo tipo de documentaci<63>n y datos acumulados relacionados con especificaci<63>n de procesos,
procedimientos, dise<73>os, teor<6F>as, y observaciones
\item orga-ware Relacionado con la Organizaci<63>n: Acuerdos y Alianzas necesarias para facilitar la integraci<63>n de los componentes T<>cnico, Humano, y
de informaci<63>n. Involucra asignaci<63>n, sistematizaci<63>n, organizaci<63>n, redes de comunicaci<63>n.
\end{itemize}
El uso efectivo de estos cuatro componentes requiere el cumplimiento de ciertas condiciones. El componente t<>cnico requiere de personal con habilidades
espec<EFBFBD>ficas para poder ser utilizado. Para mejorar la eficiencia del sistema el componente humano necesita de adaptaci<63>n y motivaci<63>n. A medida que la
organizaci<EFBFBD>n cambia para adaptarse a nuevas condiciones o requerimientos se debe actualizar el sector de la informaci<63>n. \textbf{No es posible realizar
operaciones de transformaci<63>n ante la ausencia de uno de estos cuatro componentes}
La interacci<63>n de estos cuatro componentes puedes ser resumida de la siguiente forma:
\begin{itemize}
\item \textit{Tecnoware} constituye el n<>cleo de cualquier tecnolog<6F>a, es decir, una habilidad de transformaci<63>n, y es desarrollada, instalada y operada
por \textit{humanware}.
\item \textit{Humanware} o las habilidades individuales representan el elemento clave de cualquier operaci<63>n de transfomaci<63>n guiada por el \textit{infoware}
\item \textit{Infoware} almacena conocimiento acumulado para ahorrar tiempo en el aprendizaje individual. Es generado y utilizado por \textit{humanware}
para los procesos de toma de decisiones y operaciones.
\item \textit{Orgaware}, o el marco de trabajo administrativo, adquiere y administra el tecnoware, humanware e infoware con el fin de realizar la operaci<63>n.
Orgaware se compone de las actividades de planeaci<63>n, organizaci<63>n, activaci<63>n, motivaci<63>n y control de operaciones.
\end{itemize}
La tecnolog<6F>a no esta asociada a un sistema socio-econ<6F>mico abstracto. La tecnolog<6F>a se encuentra fuertemente relacionada con un espectro amplio de las
necesidades humanas, si se dictan por las condiciones f<>sicas existentes o por factores culturales derivados de las especificidades hist<73>ricas de
diferentes grupos sociales \cite{KGSB95}. En res<65>men, la tecnolog<6F>a esta compuesta de conocimiento, herramientas, t<>cnicas y actividades utilizadas
para transformar las entradas de la organizaci<63>n en salidas.
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%% DEFINICION DE TRANSFERENICA TECNOL<4F>GICA %%%%%%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\section{Definici<EFBFBD>n}
Odedra \cite{Mo94} define la transferencia tecnol<6F>gica como el problema de transfencia de conocimiento
(o know-how) sobre un n<>mero de aspectos (que incluyen el conocimiento) sobre como funciona
un determinado sistema, como operarlo y desarrollar sus aplicaciones, como mantenerlo y si
es necesario, como producir sus componentes y montar un sistema similar. La transferencia
tecnol<EFBFBD>gica se considera exitosa cuando los receptores de la tecnolog<6F>a asimilan los conceptos
anteriores para suplir sus necesidades locales.
Seg<EFBFBD>n Jolly \cite{Jol77} La innovaci<63>n tecnol<6F>gica es entendida como un nuevo m<>todo, medio o capacidad del individuo para realizar una determinada actividad. El resultado de la transferencia tecnol<6F>gica puede ser la aceptaci<63>n de una pr<70>ctica com<6F>n en otros lugares, o la aplicaci<63>n de una t<>cnica
dise<EFBFBD>ada para otro uso en la saluci<63>n de problemas locales, debe distinguirse del proceso general de difusi<73>n de tecnolog<6F>a: un movimiento no planeado de art<72>culos sociales y tecnol<6F>gicos de un lugar a otro sin ning<6E>n esfuerzo centrado en la transferencia. La transferencia tecnol<6F>gica incluye la difusi<73>n de conocimiento cient<6E>fico y la preocupaci<63>n por la transformaci<63>n del conocimiento en innovaciones <20>tiles. El conocimiento es lo que queda al final de un proceso documentado y difundido de forma apropiada. Para que la transferencia tecnol<6F>gica sea exitosa es necesario transferir los componentes de la tecnolog<6F>a, es decir: Los conocimientos t<>cnicos, las habilidades humanas, la informaci<63>n y la estructura de la organizaci<63>n.
\subsection{Tipos de Transferencia Tecnol<6F>gica}
Mansfield clasifica la transferencia tecnol<6F>gica en transferencia de material, dise<73>o y capacidades, la transferencia de material no constituye una transfencia tecnol<6F>gica real, ya que no genera el conocimiento necesario para transformarlos y generar nuevos productos que cumplan con las necesidades locales
\begin{itemize}
\item Transferencia material: Artefactos tecnol<6F>gicos: Materiales, productos finales, componentes, equipos
\item Transferenica de dise<73>o: Dise<73>os, proyectos, know-how para fabricar productos dise<73>ados previamente. Los productos son copiados para producirlos
localmente.
\item Transferencia de Capacidades: Proporciona know-how y software no solo para fabricar componentes existentes, sino, innovar y adaptar tecnolog<6F>as
existentes para producir nuevos productos.
\end{itemize}
La transferencia de dise<73>os permite adquirir mayor conocimiento sobre la tecnolog<6F>a transferida, sin embargo, es necesario que el pais receptor cuente con la plataforma tecnol<6F>gica adecuada para absorver estos conocimientos, de lo contario no se generar<61>n nuevos productos y las actividades se limitar<61>n al ensamblaje de productos pre-manufacturados. La transferencia de capacidades es ideal, ya que proporciona las herramientas necesarias para que la transferencia sea exitosa, est<73> asociada a una transferencia de conocimiento, lo cual es vital para entender plenamente la tecnolog<6F>a, mejorando las habilidades de los profesionales del receptor.
Otra clasificaci<63>n distingue entre Transferencia Vertical y Horizontal:
\begin{itemize}
\item Transferencia Vertical: Transferencia de informaci<63>n t<>cnica a diferentes niveles de un proceso innovativo determinado. Por ejemplo de
investigaci<EFBFBD>n b<>sica a investigaci<63>n aplicada, de investigaci<63>n aplicada a desarrollo y de desarrollo a producci<63>n. es decir, una progresi<73>n
tecnol<EFBFBD>gica desde la teor<6F>a al producto terminado.
\item Transferencia Horizontal: Cuando se utiliza en un lugar, organizaci<63>n o contexto y es transferida y utilizada en otro lugar.
\end{itemize}
La transferencia vertical establece varios pasos en la transferencia, que pueden ser aplicados en diferentes niveles: Entre centros acad<61>micos, transferencia entre la academia y la empresa para generar aplicaciones, prototipos y producci<63>n en masa. La desconcexi<78>n entre la Universidad y la empresa en Colombia y en la mayor<6F>a de los pa<70>ses en desarrollo hace que los objetivos que persigue la Academia no est<73>n sintonizados con las necesidades de la industria y en muchas ocasiones los productos generados en la Academia nunca llegan a las industrias locales, ya sea porque no tienen la infraestructura tecnol<6F>gica para hacerlo o porque la Universidad no proporciona el soporte necesario para que ese producto pueda ser utilizado en la pr<70>ctica.
\subsection{Canales Para la Transferencia de tecnolog<6F>a}
Erdilec and Rapoport [45] clasifican los mecanismos en Formales: Acuerdos de licenciamiento, Inversi<73>n extranjera, compa<70><61>as conjuntas, acuerdos de cooperaci<63>n en investigaci<63>n, arreglos de producci<63>n conjunta e Informales: No involucran acuerdos entre las partes y son dif<69>ciles de detectar y monitorear, por ejemplo, exportaci<63>n de productos tecnol<6F>gicos o bienes de capital, ingenier<65>a inversa, intercambio de personal t<>cnico y cient<6E>fico, conferencias de ciencia y tecnolog<6F>a, ferias y exposiciones, educaci<63>n y entrenamiento realizado por extranjeros, visitas comerciales, literatura abierta (art<72>culos, revistas, libros t<>cnicos), espionaje industrial. Adicionalmente, existe una divisi<73>n basada en la naturaleza de la instituci<63>n que proporciona los recursos para que se realice la transferencia, la instituci<63>n puede ser de car<61>cter:
\begin{itemize}
\item \textit{Abierta} en donde la tecnolog<6F>a y el conocimiento s<>n considerados bienes p<>blicos, no existen restricciones para acceder a la informaci<63>n necesaria para adquirir, usar y transformar estos conocimientos en productos comerciales, y su <20>xito radica en obtener la m<>xima difusi<73>n posible para que los usuarios de este conocimiento mejoren el material existente y contribuyan con experiencias personale,
\item \textit{Cerrada} La tecnolog<6F>a y el conocimiento se genera para fines privados, la utilizaci<63>n de este conocimiento esta sometida a acuerdos comerciales. No es posible entender las bases de la tecnolog<6F>a, por lo que no se pueden generar productos derivados.
\end{itemize}
Las actividades realizadas durante este estudio est<73>n enmarcadas dentro del concepto: \textit{El conocimiento es un Bien Com<6F>n}, toda la documentaci<63>n necesaria para reproducir, entrenar, entender y modificar los productos generados se encuentran disponibles en servidores p<>blicos \cite{WSCC} \cite{CC} y se proporciona soporte a trav<61>s de listas de discusi<73>n, adicionalmente se proporciona soporte comercial para permitir la producci<63>n de estas modificaciones. A continuaci<63>n se realiza una descripci<63>n de los canales m<>s utilizados para la transferencia de tecnolog<6F>a y conocimiento en pa<70>ses en v<>a de desarrollo (\cite{MO90} \cite{Mo94} \cite{MO91}) indicando en cada caso sus ventajes, limitaciones y desventajas.
\subsubsection{Adquisici<EFBFBD>n de IT}
La adquisici<63>n de equipo ha sido uno de los mecanismos de transferencia m<>s importantes para los pa<70>ses en desarrollo. Estos equipos
se entregan con el software requerido para su funcionamiento con lo que no es necesario que los usuarios generen aplicaciones, por lo que
solo adquieren el conocimiento necesario para utilizar estas m<>quinas, y por lo tanto no saben como funcionan.
Otra forma de transferencia se presenta cuando una empresa vende una soluci<63>n personalizada a las necesidades de los clientes. La
transferencia tecnol<6F>gica se presenta en el proceso de personalizaci<63>n, esto, unido a otras habilidades en programaci<63>n ayudan a elevar
el mercado de SW local. Sin embargo, en muchas ocasiones no se detect<63> ning<6E>n tipo de transferencia de knowhow en la adquisici<63>n de estas m<>quinas.
Las grandes multinacionales como IBM, Microsoft, NCR dominan el mercado de Software y Hardware y hacen que sea imposible el ingreso de
peque<EFBFBD>as compa<70><61>as locales, lo que se traduce en que el mantenimiento y servicios asociados al hardware, as<61> como los ajustes de Software
sean realizados por los proveedores de las multinacionales y en muy pocos casos los usuarios de esta tecnolog<6F>a adquieren habilidades
para sostener el equipo. La transferencia se realiza a subsidiarias de las multinacionales, con lo que la transferencia es m<>nima, esto se
hace para que la dependencia no se pierda.
En conclusi<73>n con la venta de equipos se transmite <20>nicamente el conocimiento para operar, programar o mantener, sin embargo,
este conocimiento sobre el sistema puede ayudar a concientizarse sobre la tecnolog<6F>a e impulsar la formaci<63>n de capital humano.
La experiencia de pa<70>ses que lograron un r<>pido desarrollo econ<6F>mico e industrial muestra que la adquisici<63>n de una gran cantidad de
tecnolog<EFBFBD>a for<6F>nea jug<75> un papel importante en este proceso. Colombia ha realizado un proceso de transformaci<63>n tecnol<6F>gica pero no ha
dise<EFBFBD>ado pol<6F>ticas efectivas y eficientes para la transferencia de tecnolog<6F>as de alto nivel
.
\subsubsection{Educaci<EFBFBD>n y Entrenamiento}
Educar a las personas a trav<61>s de cursos y entrenamiento en el pa<70>s y envi<76>ndolas al extranjero para otros estudios es una forma de adquirir
know-how sobre nuevas tecnolog<6F>as, o tecnolog<6F>as que no se utilizan en el pa<70>s de origen. Muchas instituciones ofrecen carreras en
Ingenier<EFBFBD>a Electr<74>nica, Ciencias de la computaci<63>n y afines, algunas de ellas utilizan modelos pedag<61>gicos utilizados en pa<70>ses desarrollados,
los que no han sido adaptados plenamente a la infraestructura tecnol<6F>gica local, y no es raro encontrar estudiantes que no est<73>n satisfechos
con su profesi<73>n al finalizar los cursos\cite{Mo94}.
En muchas Universidades temas como Nanotecnolog<6F>a, Dise<73>o de Circuitos integrados de muy alta integraci<63>n (VLSI) hacen parte importante de las
actividades de investigaci<63>n; la pertinencia de estos t<>picos avanzados ante la situaci<63>n tecnol<6F>gica del pa<70>s es discutible ya que muchos
estudiantes no aplicar<61>n nunca estos conocimientos en el entorno local, por lo que la ense<73>anza de estos t<>picos puede resultar una p<>rdida de
recursos. Es m<>s, con los r<>pidos cambios en la industria electr<74>nica estos conocimientos pueden resultar irrelevantes, a<>n si la
infraestructura del pa<70>s se mejora. Es decir, es importante no dejarse llevar por el momento, o por la "fama" de un t<>pico de investigaci<63>n
o de una tecnolog<6F>a novedosa, es necesario evaluar la pertinencia de los cursos que se dictan en el entorno tecnol<6F>gico local, por supuesto,
es necesario que la academia impulse cambios en el sector, pero estos cambios deben ser consecuentes con el nivel tecnol<6F>gico que posea el pa<70>s.
La transferencia tecnol<6F>gica no ocurre cuando estudiantes formados en el exterior no pueden aplicar sus conocimientos en su pa<70>s de origen,
por lo que es necesario crear pol<6F>ticas que definan que <20>reas de estudio son prioritarias para el pa<70>s.
Las multinacionales tambi<62>n ofrecen cursos de capacitaci<63>n, sin embargo, se limitan al uso de sus productos, creando dependencia hacia
sus herramientas. Adicionalmente, existen centros privados de capacitaci<63>n que ofrecen cursos para el manejo de paquetes y lenguajes de
programaci<EFBFBD>n, estos centros aprovechan la falta de centros de ense<73>anza tecnol<6F>gica y personal calificado para cobrar altas sumas de dinero,
lo cual limita el acceso. Programas acad<61>micos inapropiados, acceso limitado a libros y computadores, falta de facilidades para capacitaci<63>n, reduce la efectividad
de la educaci<63>n y capacitaci<63>n como canal para la transferencia tecnol<6F>gica.
\subsubsection{Asistencia T<>cnica}
La ventaja de contratar consultores externos radica en el ahorro de tiempo y dinero, ya que, utilizar personal local implicar<61>a un gran esfuerzo
y posiblemente se tendr<64>an que asumir errores costosos en el proceso. Sin embargo, no es bueno confiar a consultores externos la responsabilidad
de construir habilidades locales, ya que reduce el desarrollo de estas habilidades, especialmente, la del personal encargado de manejar proyectos.
En algunas ocasiones los consultores no est<73>n familiarizados con las condiciones y requerimientos locales, con lo que dise<73>an soluciones que no se
ajustan perfectamente a las necesidades, lo que significa que el sistema es sub-utilizado y la transferencia de tecnolog<6F>a es poca. La falta de
personal calificado hace que los consultores se encarguen de todas las tareas del proyecto, lo que aumenta su carga de trabajo y disminuye la
posibilidad de entrenamiento de personal local\cite{Mo94}.
En algunas ocaciones los consultores son representantes de grandes multimacionales y todas sus acciones est<73>n dirigidas a aumentar la dependencia
con los productos generados por dichas transnacionales y a ignorar de forma sistem<65>tica opciones que pueden ayudar a la transferencia de conocimiento,
llegando hasta el punto de influir en la formulaci<63>n de pol<6F>ticas para transferencia tecnol<6F>gica. Un ejemplo de este tipo de alianzas no convenientes
se presenta en la industria del Software dominada por Microsft. Microsoft firma acuerdos con centros educativos oficiales para la distribuci<63>n de
sus productos con licencias a muy bajo costo, el estudiante se acostumbra a utilizarlas y cuando sea un profesional debe adquirirlas a un precio
elevado para poder realizar su actividad profesional con la <20>nica herramienta que conoce.
\subsubsection{Licenciamiento}
El licenciamiento es un canal que se utiliza para transferencia de know-how sobre productos o procesos, es aplicado de forma individual o en
combinaci<EFBFBD>n con otros instrumentos como investigaci<63>n extranjera, importaci<63>n de maquinaria o de t<>cnicos. Sin embargo, no es efectivo si no
se acompa<70>a de habilidades administrativas y de producci<63>n. Adicionalmente, es necesario contar con una infraestructura tecnol<6F>gica adecuada,
capacidades locales de fabricaci<63>n de hardware y software y pol<6F>ticas de gobierno adecuadas \cite{Mo94}.
Un ejemplo de este tipo de pr<70>ctica se presenta en el ensamble de dispositivos electr<74>nicos, todos los componentes se importan completamente
terminados y el dispositivo final es ensamblado probado y se carga la configuraci<63>n inical, no se producen actividades de ingenier<65>a inversa con
lo que se transmite muy poco conocimiento.Odedra \cite{Mo94} define la transferencia tecnol<6F>gica como el problema de transfencia de conocimiento
(o know-how) sobre un n<>mero de aspectos (que incluyen el conocimiento) sobre como funciona un determinado sistema, como operarlo y desarrollar sus aplicaciones, como mantenerlo y si es necesario, como producir sus componentes y montar un sistema similar. La transferencia tecnol<6F>gica se considera exitosa cuando los receptores de la tecnolog<6F>a asimilan los conceptos anteriores para suplir sus necesidades locales.
Sin embargo, es necesario crear una confianza en los productos locales, el gobierno debe crear pol<6F>ticas de protecci<63>n de los productos generados
localmente, pa<70>ses de latinoamerica aplican este tipo de protecciones y solo permiten la importaci<63>n de productos que no se fabriquen en el pa<70>s.
Esto aumenta la confianza en los productos generados localmente e impulsa el desarrollo industrial y la generaci<63>n de empleo.
\subsubsection{Inversi<EFBFBD>n Extranjera Directa}
La inversi<73>n directa de multinacionales es una forma de obtener tecnolog<6F>a externa. Esto asegura una r<>pida transferencia de informaci<63>n
tecnol<EFBFBD>gica, pero no necesariamente del entendimiento o know-how. Lo que hace que la tecnolog<6F>a transferida a trav<61>s de este canal sea m<>nima.
Las grandes multinacionales pueden tener cierto control pol<6F>tico en los pa<70>ses en v<>a de desarrollo, hasta tal punto que son asesores de
instituciones encargadas de fijar pol<6F>ticas para la transferencia tecnol<6F>gica \cite{Mo94}.
El objetivo de la transferencia tecnol<6F>gica debe ser el aumento de la auto-suficiencia en el pais receptor, unido a un uso compartido de
recursos y experiencia entre los pa<70>ses desarrollados y en v<>a de desarrollo. La compra de equipo o de software transfiere muy poco conocimiento
sobre la tecnolog<6F>a, el servicio post-venta y el mantenimiento es realizado por el proveedor. Por otro lado, las facilidades en educaci<63>n y capacitaci<63>n
son limitadas lo cual obstaculiza la formaci<63>n de capital humano. La asistencia t<>cnica utilizada para suplir la falta de personal especializado y
ayudar con el proceso de transferencia no ha sido muy efectiva.
\subsection{Conclusi<EFBFBD>n}
La efectividad de cada canal depende de la naturaleza de la tecnolog<6F>a que se va a adquirir, el tipo de organizaci<63>n y de las capacidades de absorci<63>n del recipiente. La tecnolog<6F>a es efectiva <20>nicamente cuando la econom<6F>a del pa<70>s es capaz de utilizarla. Cuando se transfiere una tecnolog<6F>a se debe contar con el dinero para adquirirla y se deben generar las actividades necesarias para mejorar la plataforma tecnol<6F>gica, incluyendo la educaci<63>n y la capacitaci<63>n, de tal forma que el pa<70>s sea capaz de absorberla y generar nuevos productos que satisfagan necesidades locales.
El <20>xito de la transferencia tecnol<6F>gica no depende de un factor <20>nico, sino de la confluencia de multiples factores dentro y fuera de la instituci<63>n acad<61>mica. Las relaciones personales entre los agentes de transferencia tecnol<6F>gica y la facultad, licencias corporativas, y las comunidades de investigaci<63>n y de negocios son la clave de esfuerzos exitosos. En muchos casos, las Universidades han liderado el proceso de transferencia tecnol<6F>gica a trav<61>s de sus directivos, estos a trav<61>s de incentivos crean una cultura acad<61>mica que recompensa la transferencia tecnol<6F>gica y el emprendimiento.
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%% Modelo %%%%%%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\section{Modelo}
Un programa de transferencia tecnol<6F>gica bebe incluir mecanismos que unan de forma eficiente la fuente del conocimiento con la utilizaci<63>n del mismo.
Estos canales de comunicaci<63>n son mecanismos de recursos humanos que pueden ser incorporados tanto en la fuente como en el destino,
el proceso de una efectiva transferencia tecnol<6F>gica puede comenzar con potenciales usuarios en lugar de fuentes \cite{Jol77}
La figura \ref{tech_trans_model_global} muestra
\begin{figure}[ht]
\begin{center} \includegraphics[scale=.6]{./images/transfer_model_global.png} \end{center}
\caption{Modelo del proceso de Transferencia de Tecnolog<6F>a} \label{tech_trans_model_global}
\end{figure}
\subsection{Los factores formales}
\subsubsection{Documentaci<EFBFBD>n}
Es el formato, organizaci<63>n, o presentaci<63>n de la tecnolog<6F>a que ser<65> transferida. El formato y el lenguaje se relacionan directamente con el entendimiento del material por parte del receptor. La informaci<63>n que no se entiende no se utiliza. Los cient<6E>ficos e ingenieros ocupan hasta 4 horas diarias leyendo art<72>culos, hablando con sus pares o buscando informaci<63>n, mientras que los nuevos usuarios (por ejemplo, gobiernos locales, y grupos de ciudadanos) desean gastar menos tiempo en dar respuestas a sus preguntas.
\subsubsection{Distribuci<EFBFBD>n}
Constituye el canal f<>sico a trav<61>s del cual la tecnolog<6F>a fluye e involucra tanto el n<>mero de entradas y el f<>cil acceso al canal, as<61> como el plan de distribuci<63>n. knox 1973, dice: "Una medida de la efectividad del sistema de informaci<63>n tecnol<6F>gica es al capacidad de permitir el contacto entre personas con necesidades y con posibles soluciones. Ames 1965, Encontr<74> que los abstracts y los papers son la fuente de informaci<63>n m<>s importante, mientras que las reuniones y conferencias el mejor veh<65>culo para crear conciencia, la cual es indispensable para que el proceso de distribuci<63>n sea exitoso, por lo que, el intercambio personal debe ser considerado como parte del proceso de distribuci<63>n de tecnolog<6F>a. Este canal ayuda a eliminar retardos en la investigaci<63>n, ya que permite determinar el estado del arte de una determinada actividad o <20>rea de trabajo.
\subsubsection{Organizaci<EFBFBD>n}
La percepci<63>n del receptor de la organizaci<63>n. Schon 1967, caracteriza a una organizaci<63>n que es favorable a la transferencia tecnol<6F>gica y utilizaci<63>n de conocimiento como aquella que vive en un estado de urgencia, donde los conflictos son resueltos por mandato, donde los recursos son enviados sin vacilar, y donde la incertidumbre se convierte en un riesgo. Stephenson, Ganz y Erickson 1974, reportan un estudio realizado sobre 109 cient<6E>ficos e ingenieros donde algunos de ellos sienten que una organizaci<63>n ocasionalmente puede actuar como una barrera a las nuevas ideas.
\subsubsection{Selecci<EFBFBD>n de Proyectos}
Proceso de selecci<63>n para proyectos de investigaci<63>n y desarrollo realizado por el proveedor con ayuda del receptor. Es importante que la investigaci<63>n comience como respuesta a una necesidad del cliente.
La figura \ref{tech_trans_model} muestra
\begin{figure}[ht]
\begin{center} \includegraphics[scale=.6]{./images/transfer_model.png} \end{center}
\caption{Modelo del proceso de Transferencia de Tecnolog<6F>a Indicando La Composici<63>n de Los Canales Formales e Informales} \label{tech_trans_model}
\end{figure}
\subsection{Factores Informales}
Los factores informales son de naturaleza sociol<6F>gica y/o comportamental, y contribuyen fuertemente al <20>xito de la utilizaci<63>n del conocimiento por una determinada organizaci<63>n.
\subsubsection{Capacidad}
La capacidad del usuario para utilizar nuevas ideas que cubren un amplio espectro de rasgos que incluyen riesgo, riqueza, poder, educaci<63>n, experiencia, edad, confianza en s<> mismos.
Atributos como: Atrevimiento, status profesional y educativo, domino, sociabilidad, no son considerados tan importantes frente a la autosuficiencia que es el m<>s valorado.
\subsubsection{Enlace (contacto)}
Presencia y efectos de enlaces informales en la organizaci<63>n receptora. El enlace opera dentro de la organizaci<63>n receptora y exhibe caracter<65>sticas similares al supervisor, l<>der de opini<6E>n, innovador y previo conocedor de la innovaci<63>n.
\subsubsection{Credibilidad}
La credibilidad es una evaluaci<63>n por parte del usuario, de la confiabilidad de la informaci<63>n. Es evaluada analizando la fuente y el canal del mensaje. La opini<6E>n cambia dependiendo de la fuente de la informaci<63>n, es decir, la credibilidad es influenciada por su fuente.
\subsubsection{Recompensa}
Reconocimiento del sistema social del cual hace parte un individuo ante un comportamiento innovador.
\subsubsection{Disposici<EFBFBD>n}
La habilidad y/o deseo del individuo para aceptar un cambio en la organizaci<63>n de la cual es miembro. As<41> mismo es importante la capacidad de adopci<63>n de nuevas ideas, Gallup 1955 se<73>al<61> que aunque una idea halla sido aceptada intelectualmente, toma un per<65>odo de tiempo antes de ser incorporada en la forma de pensar. Ser consciente de la importancia de de una nueva idea no s suficiente para asegurar su uso; debe existir una disposici<63>n, un inter<65>s, una motivaci<63>n personal para utilizar un mejor m<>todo, proceso o concepto.
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%% Historia %%%%%%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\section{Transferenica Tecnol<6F>gica en Latinoam<61>rica \cite{UNE}}
\subsection{Trasfondo hist<73>rico}
Durante el per<65>odo que va de los a<>os 40 a la d<>cada de los 80, en Am<41>rica Latina y el Caribe se puso en pr<70>ctica una pol<6F>tica de
industrializaci<EFBFBD>n por sustituci<63>n de importaciones mediante modalidades de proteccionismo de la industria manufacturera local.
Con lo que se comenz<6E> a importar los bienes de capital necesarios para la fabricaci<63>n en el <20>mbito local, desarrollando
de esta forma a las industrias locales. Mientras tanto, en los pa<70>ses de donde proven<65>an estos bienes, se transformaba el conocimiento
adquirido de la investigaci<63>n, en nuevos productos, procesos y modelos de gesti<74>n m<>s competitivos. Es decir, se importaron los equipos
para realizar la transformaci<63>n industrial, pero no se generaron las bases cient<6E>fico-tecnol<6F>gicas que se encargaran de generar nuevos
productos asociados a las materias primas proporcionadas por los recursos naturales locales, se descuid<69> el capital humano capaz de entender,
adaptar y llevar estos inventos a la sociedad, salvo en algunas disciplinas agr<67>colas donde la especificidad local oblig<69> a la investigaci<63>n.
Adicionalmente, no se gener<65> demanda local que impulsara la producci<63>n de conocimiento, las nuevas empresas no contaban con departamentos de
Investigaci<EFBFBD>n y desarrollo (I+D) y los gobiernos no estimulaban la creaci<63>n de centros de investigaci<63>n asociados a este proceso de industrializaci<63>n.
Cuando los gobiernos de la regi<67>n se dieron cuenta de esta situaci<63>n crearon la Comisi<73>n para Am<41>rica Latina y el Caribe (CEPAL). A partir
de las d<>cadas de los cincuentas y setentas comenzaron a crear pol<6F>ticas en las <20>reas cient<6E>ficas y tecnol<6F>gicas, creando instituciones
destinadas al fomento de la ciencia y la tecnolog<6F>a. Muchos de estos esfuerzos fueron discontinuos y contradictorios, pero algunos siguieron
las pautas establecidas por la UNESCO y la OEA (basadas en "la idea de que la ciencia y la tecnolog<6F>a eran una usina de crecimiento, en un rico
suelo fertilizado por el deseo de la modernizaci<63>n y el desarrollo") exhibieron una continuidad notable. Esto unido al apoyo gubernamental y
el inter<65>s de las universidades fue clave para la formulaci<63>n de pol<6F>ticas de apoyo a la ciencia y la tecnolog<6F>a.
Gracias a estas pol<6F>ticas hubo un fuerte proceso de institucionalizaci<63>n de la investigaci<63>n cient<6E>fica y de los mecanismos de desarrollo:
Sistemas de promoci<63>n del I+D, legislaci<63>n en transferencia de tecnolog<6F>a, planificaci<63>n de la ciencia, m<>todos de diagn<67>stico de recursos,
sistemas de fijaci<63>n de prioridades tecnol<6F>gicas, etc. A finales de los 50s y dyrante los 60s y 70s, estas actividades eran soportadas casi de
forma exclusiva por el estado (incluyendo las universidades p<>blicas), estos esfuerzos no provocaron una din<69>mica sostenida de innovaci<63>n en el
conocimiento y en la econom<6F>a ya que en muchos sectores no se gener<65> un v<>nculo s<>lido entre la producci<63>n y la investigaci<63>n, esto debido a la
creaci<EFBFBD>n de dos modelos de investigaci<63>n en ciencia y tecnolog<6F>a:
\begin{itemize}
\item Ciencia Acad<61>mica: Basada en las universidades, es incorporada a la comunidad cient<6E>fica internacional, de quien recibe legitimidad, orientaci<63>n,
organizaci<EFBFBD>n.
\item Actividad Tecnol<6F>gica: Sustentada por organismos sectoriales, legitimada por instituciones estatales, su objetivo es dar soluci<63>n a problemas
pr<EFBFBD>cticos y a la transferencia de tecnolog<6F>a al sector productivo.
\end{itemize}
En los a<>os 80 disminuy<75> la confianza de poder encontrar un camino hacia un desarrollo end<6E>geno, lo que origin<69> un giro hacia pol<6F>ticas de ajuste,
estabilizaci<EFBFBD>n y apertura de la econom<6F>a que buscaban v<>as alternas para llegar a la globalizaci<63>n. La apertura de la econom<6F>a supon<6F>a un
abastecimiento de nuevos conocimientos por parte de las empresas locales para estar a tono con el estado internacional o la b<>squeda de nuevos
nichos de mercado; por otro lado, la apertura forzar<61>a una homogeneizaci<63>n tecnol<6F>gica, por lo que el aumento de la competitividad se lograr<61>a
a trav<61>s de la transferencia de productos externos y no la inventiva e innovaci<63>n local.
En los a<>os 90 los pa<70>ses de la regi<67>n realizan grandes compras a costa de su endeudamiento externo. La industria local se ve enfrentadas a
productos extranjeros baratos, lo que ocasiona el cierre de muchas industrias manufactureras y la transformaci<63>n de muchas en importadores;
esta pol<6F>tica desmantela el aparato productivo y no fomenta actividades de adaptaci<63>n, mejora y creaci<63>n de productos. La oferta tecnol<6F>gica
proviene del exterior, se diluye el sistema nacional de ciencia y tecnolog<6F>a basado en el aumento de la oferta interna de conocimiento.
Las pol<6F>ticas p<>blicas se reducen a la aceptaci<63>n de normas de la Organizaci<63>n Mundial de Comercio (OMC) basadas en presiones de Estados
Unidos y la Uni<6E>n Europea sobre patentes farmac<61>uticas, tecnolog<6F>as agr<67>colas y de otros tipos. No es que no existan esfuerzos e interacciones tecnol<6F>gicas entre la ciencia y la producci<63>n; el problema es que no constituyen un sistema autosostenido de relaciones din<69>micas que marquen un rumbo claro a la investigaci<63>n en ciencia y tecnolog<6F>a vinculado con las sociedades y las econom<6F>as donde se desenvuelven.
Seg<EFBFBD>n Gibbons y Schwartzman, la investigaci<63>n cient<6E>fica se origina y justifica cada vez m<>s en el contexto de aplicaci<63>n del conocimiento,
es decir, en la posibilidad de su utilizaci<63>n. Por lo que los temas de investigaci<63>n no son fijados por los cient<6E>ficos sino por redes formadas
por empresarios, ingenieros de planta e inversionistas. Lo que lleva a que las diferencias entre las dos formas de investigaci<63>n disminuyan.
En tal sentido, no es seguro que la inserci<63>n en el comercio internacional de Am<41>rica Latina favorezca su posici<63>n en la producci<63>n de
conocimientos en ciencia y tecnolog<6F>a.
La ciencia y la tecnolog<6F>a en la regi<67>n presenta dos grandes probleams: a) su escasa magnitud; b) su desvinculaci<63>n con la sociedad a
la que pertenece, con el agravante de la p<>rdida de legitimidad que se produjo en las <20>ltimas dos d<>cadas, sustentada por una parte en
el Estado, y en su integraci<63>n en una ciencia internacional fuertemente acad<61>mica, por la otra.
\subsection{Financiaci<EFBFBD>n}
Seg<EFBFBD>n la Red de Indicadores de Ciencia y Tecnolog<6F>a (RYCIT), el gasto en actividades de ciencia y tecnolog<6F>a en los pa<70>ses latinoamericanos alcanza poco menos de los 8.000 millones de d<>lares anuales, lo cual representa el 2,3\% del gasto mundial en el sector. Mientras el PBI de Estados Unidos cuadruplica al de Am<41>rica Latina y el Caribe, su inversi<73>n en I+D es m<>s de 20 veces mayor que la latinoamericana. Dicho de otro modo, el esfuerzo de los pa<70>ses de la regi<67>n en ciencia y tecnolog<6F>a es inferior al que les corresponder<65>a realizar tomando en cuenta el valor del producto regional.
Seg<EFBFBD>n la Organization for Economic Co-operation and Development (OCED) los pa<70>ses Latinoamericanos dedican en promedio algo m<>s del 0,6\% de su Producto Interno Bruto a I+D. Esta inversi<73>n se concentra en Brasil, M<>xico y Argentina, en Colombia el gasto es del 0.18\% lo que contrasta fuertemente con el gasto militar de 3.4\%. En la Uni<6E>n Europea, en cambio, el porcentaje alcanza el 1,7\% del PIB, en Estados Unidos alcanza el 2,8\%, Jap<61>n (3,13\%), Corea del Sur (2,52\%) y otros como China e India en los cuales, aunque la inversi<73>n es algo inferior, la tendencia de los <20>ltimos a<>os hace pensar en un aumento progresivo de sus inversiones en I+D. El gasto en ciencia y tecnolog<6F>a como el recurso promedio que tienen los investigadores para llevar a cabo su tarea, en EEUU asciende a 171.000 d<>lares por investigador, y en el conjunto de pa<70>ses latinoamericanos a 59.000.
Un rasgo caracter<65>stico de la investigaci<63>n cient<6E>fica en Am<41>rica Latina es su gran dependencia del Estado, seg<65>n un estudio de la OCED, en el plano estrictamente tecnol<6F>gico, las estad<61>sticas sobre patentes describen un panorama entre el norte y el sur similar a los datos del I+D: el n<>mero de solicitudes de patentes en EEUU es del orden de los 200.000 por a<>o, m<>s de 50.000 y de 40.000 en Espa<70>a y Canad<61>, respectivamente. En Am<41>rica Latina, s<>lo Brasil y M<>xico (pero ambos con marcados desniveles anuales) presentan cifras algo significativas: entre 6.000 y 10.000 patentes anuales. Aun as<61> son valores marcadamente inferiores.
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%% Obstaculo %%%%%%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\section{Obst<EFBFBD>culos para una Transferencia Exitosa}
La cantidad de conocimiento y tecnolog<6F>a transferida es afectada por pol<6F>ticas gubernamentales, la situaci<63>n econ<6F>mica, facilidades de educaci<63>n y capacitaci<63>n, personal calificado, aspectos organizacionales y sociales, proveedores de tecnolog<6F>a e infraestructura tecnol<6F>gica. El gobierno juega un papel importante en el proceso de transferencia tecnol<6F>gica ya que puede invertir en la infraestructura para impulsar una determinada tecnolog<6F>a o colocar restricciones para des-estimular su uso. Estas pol<6F>ticas son dependientes de la situaci<63>n econ<6F>mica del pa<70>s y del entendimiento de la importancia de la transferencia por parte de de sus dirigentes. La falta de facilidades en educaci<63>n y en capacitaci<63>n obstaculizan el proceso de transferencia, limitando el acceso. La falta de estas habilidades indica que los canales de transferencia no son eficientes porque la infraestructura del pa<70>s no lo permite. Las personas son las que finalmente absorben el know-how tecnol<6F>gico, si no existe el suficiente personal disponible y dispuesto, el proceso de transferencia se detendr<64>.
La administraci<63>n a nivel de organizaci<63>n juega el papel m<>s importante en el proceso de transferencia tecnol<6F>gica. La resistencia o el
desconocimiento a la tecnolog<6F>a, la adquisici<63>n de tecnolog<6F>a por motivos particulares no contemplan la implementaci<63>n y la capacitaci<63>n.
Por esta raz<61>n, es necesario que los encargados de tomar las decisiones y trazar pol<6F>ticas, conozcan la tecnolog<6F>a, o que est<73>n conscientes de
su importancia. La transferencia tecnol<6F>gica debe ser un proceso de dos v<>as, por lo que es indispensable tener habilidades adecuadas en
investigaci<EFBFBD>n, capacidades organizacionales y de ingenier<65>a para que estos conocimientos sean asimilados y utilizados en la soluci<63>n de
problemas locales. Es necesario que la adquisici<63>n de tecnolog<6F>a obedezca a un plan y que esta tecnolog<6F>a supla una necesidad real, de
lo contrario los equipos adquiridos y la capacitaci<63>n recibida no ser<65>n utilizados, por otro lado, la tecnolog<6F>a adquirida que no es
asimilada y transformada en herramienta para la soluci<63>n de problemas locales aumenta el grado de dependencia, lo que representa justamente
lo contrario a lo que se debe buscar en una actividad de transferencia tecnol<6F>gica.
Los procesos de transferencia tecnol<6F>gica son influenciados de forma directo o indirecta por las infraestructuras organizacionales y
tecnol<EFBFBD>gicas de los pa<70>ses, los cuales, deben exceder sus capacidades para absorber la tecnolog<6F>a transferida. Esta transferencia es efectiva solo
si la econom<6F>a en la cual es introducida es capaz de utilizarla. Si un pa<70>s cuenta con los recursos econ<6F>micos necesarios para adquirir la tecnolog<6F>a,
debe mejorar la infraestructura para soportarla, incluyendo la educaci<63>n y las facilidades de entrenamiento, as<61> como los enlaces de telecomunicaciones \cite{MO90}.
La falta de facilidades de educaci<63>n y capacitaci<63>n afecta la transferencia del knowhow, obstaculizando el desarrollo de habilidades a trav<61>s del proceso de aprendizaje. La carencia de estas facilidades limita la difusi<73>n del conocimiento; la p<>rdida de estas habilidades se pueden originar porque la transferencia no se realiz<69> o porque la infraestructura no lo permite.
Si no existen personas disponibles y dispuestas a absorber el knowhow el proceso de transferencia se detendr<64>. El proceso de transferencia
tecnol<EFBFBD>gico tambi<62>n es influenciado por la falta de pol<6F>ticas claras en la Tecnolog<6F>a de la Informaci<63>n, y los planes de negocios estrat<61>gicos,
los cuales pueden identificar las necesidades que traer<65>n beneficios a la naci<63>n o determinar lo que se puede lograr con los recursos disponibles.
Algunas pol<6F>ticas regulatorias sobre procesos de adquisici<63>n de hardware y software que existen en varios pa<70>ses obstaculizan los procesos de
transferencia de tecnolog<6F>a. Al hacer convenios con multinacionales para suministro de tecnolog<6F>a, a menudo estas multinacionales no est<73>n
interesadas en difundir el conocimiento necesario para reproducir sus productos y el soporte se limita a t<>picos relacionados con su manejo.
Ejemplos claros de esto se encuentran en el software propietario, los usuarios deben usar el programa como se les suministra y no tienen
acceso al c<>digo fuente, con lo que no pueden adquirir habilidades estudiando su estructura y no pueden hacer modificaciones para adaptarlo a
sus necesidades. Esto se traduce en una sub-utilizaci<63>n del producto y en el aumento de la dependencia del proveedor.
Las tecnolog<6F>as de la Informaci<63>n deben ser utilizadas como una facilidad en el proceso de educaci<63>n y capacitaci<63>n, es necesario tomar
conciencia de la importancia de la informaci<63>n a nivel organizacional y gubernamental.
La gran ausente en las pol<6F>ticas Tecnol<6F>gicas parece ser la sociedad. Nada permite suponer que el inter<65>s de los cultores del campo
se pretenda una democratizaci<63>n de la ciencia y la tecnolog<6F>a, una apropiaci<63>n de su din<69>mica y de sus resultados por parte de la sociedad
en su conjunto. Llama la atenci<63>n que, por una parte, no existan trabajos o programas que destaquen desde un punto de vista
cr<EFBFBD>tico los impactos tecnol<6F>gicos sobre la vida de la sociedad (calidad, tejido social, integraci<63>n social, distribuci<63>n de beneficios, etc.);
por otro lado, no se registran estudios o programas de formaci<63>n destinados a plantear la cuesti<74>n de la divulgaci<63>n cient<6E>fica y tecnol<6F>gica
como procesos de apropiaci<63>n simb<6D>lica por parte de los ciudadanos respecto de los contenidos de la ciencia y la tecnolog<6F>a.
\section{Recomendaciones Para una Transferencia Tecnol<6F>gica Exitosa}
Estudios consultados \cite{MO90} \cite{IAI} \cite{MDAG99} \cite{DZSC+07} \cite{MTRR07} \cite{Mar04}, coinciden en que para dar soluci<63>n a los problemas expuestos anteriormente se deben seguir las siguientes recomendaciones:
\subsection{Recomendaciones para los generadores de pol<6F>ticas}
\begin{itemize}
\item{Promover la Importancia de la Transferencia Tecnol<6F>gica como Motor de Desarrollo Econ<6F>mico}
\begin{itemize}
\item Proporcionar educaci<63>n en transferencia tecnol<6F>gica y comercializaci<63>n a las nuevas instituciones acad<61>micas.
\item Promover las asociaciones regionales de I+D.
\item Tomar conciencia que la innovaci<63>n involucra el desarrollo cient<6E>fico y tecnol<6F>gico a varios niveles, por diferentes medios y a trav<61>s de un amplio rango de instituciones acad<61>micas.
\item Promover las actividades de Transferencia tecnol<6F>gica que involucren transferencia de conocimiento que permita la creaci<63>n de nuevos productos y servicios. Del mismo modo, desalentar la compra de equipo y software propietario como pol<6F>tica para la transferencia tecnol<6F>gica.
\end{itemize}
\item{Fomentar la Generaci<63>n de Empresas Locales de Base Tecnol<6F>gica}
\begin{itemize}
\item Evaluar y abordar la transferencia de tecnolog<6F>a desde una perspectiva corporativa.
\item Revisi<73>n de la pol<6F>tica gubernamental de apoyo a las peque<75>as empresas.
\end{itemize}
\item{Promover el Mejoramiento de la Plataforma Tecnol<6F>gica}
\begin{itemize}
\item Desarrollar sistemas de medici<63>n para capturar de forma efectiva el valor de las actividades relacionadas con la innovaci<63>n.
\item Crear un centro de intercambio de informaci<63>n para transferencia tecnol<6F>gica y difundir la informaci<63>n de forma activa.
\end{itemize}
\end{itemize}
\subsection{Recomendaciones para la academia}
\begin{itemize}
\item{Actualizaci<EFBFBD>n Curricular}
\begin{itemize}
\item Innovaci<63>n
\item Crear planes de transferencia de tecnolog<6F>a flexibles
\item hacer compromisos con el desarrollo econ<6F>mico.
\item Necesidad de mejorar las competencias y habilidades generales de los ingenieros, (continuo aprendizaje) habilidad para innovar, investigar, desarrollar nueva tecnolog<6F>a.
\item Innovaci<63>n curricular, actualizaci<63>n continua de profesionales.
\item Incentivar la formaci<63>n de maestr<74>as y doctorados nacionales acorde con una agenda de investigaci<63>n.
\end{itemize}
\item{Alianza con la industria}
\begin{itemize}
\item La Universidad debe desarrollar las habilidades y competencias que la empresa requiere.
\item Buscar alianzas industriales para lograr beneficios a largo-plazo.
\item Vinculaci<63>n de miembros de la industria a centros de investigaci<63>n para formar relaciones formales e informales.
\item Buscar tener fortalezas en <20>reas dominadas por las industrias locales
\item Promover y soportar la Transferencia de Tecnolog<6F>a
\item Fortalecer el esp<73>ritu empresarial para apoyar la comercializaci<63>n
\item Montar laboratorios de pruebas e incentivar a los productores nacionales para que logren una calidad que cumpla con los est<73>ndares internacionales.
\end{itemize}
\item{Promover y Soportar la Transferencia Tecnol<6F>gica}
\begin{itemize}
\item Elevar la transferencia tecnol<6F>gica a un nivel superior y promover la excelencia.
\item Concientizar a los creadores de pol<6F>ticas gubernamentales sobre la importancia de la transferencia tecnol<6F>gica y las alianzas con la investigaci<63>n industrial.
\item Interacci<63>n entre Universidades, Conviene que buena parte de los trabajos realizados en doctorado sean de investigaci<63>n aplicada, orientadas a mejorar la productividad del sector empresarial
\item Infraestructura institucional que impulse la actualizaci<63>n tecnol<6F>gica en el sector mediante desarrollo de proyectos de tecnolog<6F>a de punta con una posible transferencia de tecnolog<6F>a.
\end{itemize}
\item{B<EFBFBD>squeda de Financiaci<63>n para Investigaci<63>n y Desarrollo}
\begin{itemize}
\item Buscar de forma agresiva fondos para la investigaci<63>n.
\item Crear recursos empresariales en las instituciones acad<61>micas, y enlazarlos con actividades de transferencia tecnol<6F>gica.
\item Aumentar las alianzas con fuentes de inversi<73>n de capital para nuevas empresas.
\item Creaci<63>n de empresas como parte del proceso de transferencia tecnol<6F>gica de la instituci<63>n y de los compromisos con el desarrollo econ<6F>mico
\item Realizar seminarios y l<>neas de profundizaci<63>n de temas afines a la administraci<63>n y la gerencia en empresas de base tecnol<6F>gica.
\end{itemize}
\end{itemize}
\subsection{Recomendaciones para el Gobierno}
\begin{itemize}
\item{Promover la Relaci<63>n Universidad-Empresa}
\begin{itemize}
\item Fomento a centros de investigaci<63>n y productividad para fortalecer la relaciones universidad empresa.
\item Fomentar la colaboraci<63>n Universidad-Empresa en I+D, mediante la financiaci<63>n de becas de cooperaci<63>n, centros de investigaci<63>n e incentivos fiscales.
\item Crear estrategias para mejorar la relaci<63>n Universidad - empresa, creando premios para casos exitosos de transferencia tecnol<6F>gica.
\item Educar a las instituciones acad<61>micas sobre los recursos empresariales locales.
\item Trabajar con corporaciones y fundaciones para el fomento de patrocinios y participaci<63>n en transferencia de tecnolog<6F>a, I+D y desarrollo empresarial.
\item Desarrollar o mejorar infraestructuras regionales para capturar y retener empresas creadas en las instituciones acad<61>micas.
\end{itemize}
\item{Formular pol<6F>ticas Para Incentivar Actividades de Transferencia Tecnol<6F>gica}
\begin{itemize}
\item Fomentar en l<>deres universitarios el compromiso con el desarrollo econ<6F>mico.
\item Definir agendas de investigaci<63>n acordes con las tendencias mundiales y desarrollar capacidades en el pa<70>s.
\item Fomentar cooperaci<63>n internacional e inversi<73>n extranjera con transferencia de tecnolog<6F>a. a nivel gubernamental, Apoyo del gobierno a personas que tienen un alto potencial de crear y desarrollar tecnolog<6F>a.
\item Mejorar la plataforma Tecnol<6F>gica.
\end{itemize}
\item{Promover la Excelencia Acad<61>mica y la Investigaci<63>n}
\begin{itemize}
\item Promoci<63>n de las instituciones acad<61>micas como bienes econ<6F>micos
\item Trabajar con las instituciones acad<61>micas para identificar sus competencias.
\item Proporcionar fondos para temas espec<65>ficos de investigaci<63>n en instituciones acad<61>micas.
\item Promover la Investigaci<63>n y Desarrollo y la transferencia tecnol<6F>gica
\item Promover la investigaci<63>n, la colaboraci<63>n, la transferencia tecnol<6F>gica y el desarrollo empresarial.
\item Ayudar a las instituciones acad<61>micas a evaluar su impacto sobre las econom<6F>as locales y difundir los resultados a las instituciones gubernamentales.
\end{itemize}
\end{itemize}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%% CONCLUSIONES %%%%%%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\section{Actividades Prioritarias Para Obtener Una Transferencia de Tecnolog<6F>a Exitosa}
Las Anteriores recomendaciones coinciden en que para que se presente una Transferencia Tecnol<6F>gica exitosa, es decir, para que los elementos t<>cnicos, habilidades humanas, la documentaci<63>n y la organizaci<63>n asociadas a una determinada tecnolog<6F>a, puedan ser asimilados por personal calificado (disponible y dispuesto) para posteriormente transformar estos conocimientos en la creaci<63>n de nuevos productos o servicios que suplan necesidades locales es necesario:
\textbf{Fomentar la Creaci<63>n de Empresas de Base Tecnol<6F>gica} El gobierno debe crear facilidades y cr<63>ditos para que empresas tecnol<6F>gicas con la capacidad de innovaci<63>n puedan realizar su actividad comercial (productos o servicios) y de esta forma crear nuevos empleos, aumentar la demanda de servicios tecnol<6F>gicos. As<41> mismo, las universidades deben crear empresas que comercialicen productos derivados de sus actividades de Investigaci<63>n.
\textbf{Promoci<EFBFBD>n de la Transferencia Tecnol<6F>gica} El gobierno y las Universidades deben centrar sus esfuerzos en identificar las necesidades de las empresas locales y cambiar sus prioridades para solucionarlas, las universidades deben realizar proyectos de aplicaci<63>n que puedan ser utilizados por el sector productivo a corto o mediano plazo. Las pol<6F>ticas de gobierno deben desalentar la compra de equipo que solo transfiera conocimiento sobre su operaci<63>n y no permita la creaci<63>n de nuevos conocimientos a partir de ellos, asi mismo, debe formular pol<6F>ticas que protejan las empresas locales de base tecnol<6F>gica impidiendo el ingreso de productos similares provenientes del mercado asi<73>tico premiando a las empresas locales que realicen productos innovadores ya sea con beneficios tributarios temporales o con la adjudiaci<63>n de cr<63>ditos condonables destinados al desarrollo de nuevos productos. Universidad, Gobierno e Industria deben trazar pol<6F>ticas que definan las <20>reas en las que se deben formar los profesionales en el exterior, las cuales deben estar en sinton<6F>a con el estado de la plataforma tecnol<6F>gica y el sector productivo, estas pol<6F>ticas deben cambiar a medida que se mejora la plataforma tecnol<6F>gica local y se presentan cambios en el entorno mundial. Se debe trabajar en la creaci<63>n de una cultura de la Transferencia Tecnol<6F>gica, resaltando su importancia para el desarrollo del pa<70>s.
\textbf{Promover la Excelencia Acad<61>mica} Debe exisitir una evaluaci<63>n continua de los planes acad<61>micos para que se adapten a las necesidades del sistema productivo local, proporcionando a sus profesionales las habilidades requeridas por la industria, en especial las requeridas para crear l<>deres emprendedores que puedan crear nuevas empresas y que sean conscientes de la importancia del aprendizaje continuo. Por otro lado, es necesaria la creaci<63>n de maestr<74>as y doctorados que sigan pol<6F>ticas nacionales encaminadas al desarrollo econ<6F>mico y crear mecanismos de medici<63>n que permitan comparar y clasificar las instituciones acad<61>micas seg<65>n las competencias de las habilidades (liderazgo y emprendimiento) de sus egresados y de esta forma determinar que instituciones son merecedoras de cr<63>ditos, becas, o financiaci<63>n para desarrollar actividades.
Los centro de educaci<63>n de diferentes niveles deben trabajar de forma conjunta para definir los objetivos y habilidades que requiere el sector productivo a nivel de formaci<63>n tecnol<6F>gica y profesional. Esto con el fin de delimitar sus funciones para que no interfieran en el mercado laboral. En la actualidad estos limites no est<73>n definidos, esto debido a la falta de producci<63>n tecnol<6F>gica del pais, somos un pa<70>s consumidor de tecnolog<6F>a y productos manufacturaodos, y las funciones de compra de productos pueden ser realizadas por t<>cnicos e ingenieros, adicionalmente la venta de estos productos tambien puede ser realizada por cualquier persona, raz<61>n por la cual lo ingenieros tienen problemas a la hora de conseguir empleo. Esta situaci<63>n se vuelve cr<63>tica debido a la gran cantidad de programas de Ingenier<65>a que se crearon en Colombia, solo en la Universidad Nacional de Colombia se grad<61>an cerca de 60 ingenieros electr<74>nicos al a<>o.
"Para hacer esto posible se requiere una comisi<73>n de regulaci<63>n de la educaci<63>n superior que vele, especialmente, por la calidad de los diferentes programas. <20>sta debe ser una comisi<73>n independiente y mixta con la participaci<63>n del sector privado. Por otra parte, es menester tener en cuenta que el programa planteado requerir<69> un incremento sustancial de inversi<73>n en la oferta docente, tecnol<6F>gica y de investigaci<63>n'" \footnote{Publicado en el Espectador: 16 de julio 1999 `\textit{Urge elevar la competitividad} Santiago Montenegro}
\textbf{Promover la Relaci<63>n Universidad Empresa} El sector productivo debe ser el principal inversionista para las actividades de Transferenica Tecnol<6F>gica e Investigaci<63>n y Desarrollo, ya que es el directamente beneficiado con ellas. El gobierno debe desalentar las pr<70>cticas comerciales que no generan actividades de I+D, en especial las que solo comercializan productos manufacturados en pa<70>ses asi<73>ticos ya que esto hace que la empresas no vean la necesidad de crear productos propios y por lo tanto no es necesario hacer inversi<73>n en Investigaci<63>n y Desarrollo. La academia debe proporcionar a la industria herramientas que le permitan competir con productos provenientes del mercado asi<73>tico, es una realidad que a corto plazo no podemos competir con la industra manufacturera asi<73>tica, pero si podemos utilizarla para producir productos dise<73>ados en el pa<70>s, por Colombianos, para satisfacer necesidades locales. Se debe crear consciencia en la industria de las ventajas de tener productos dise<73>ados localmente, resaltando los servicios adicionales que pieden generarse al personalisar estos productos y proporcionar servicios derivados de su uso. Adicionalmente, se deben crear espacios donde los empresarios participen en los procesos de toma de decisiones y creaci<63>n de pol<6F>ticas gubernamentales sobre educaci<63>n e Investigaci<63>n y Desarrollo, para esto es vital determinar que acividades econ<6F>micas contribuyen al desarrollo tecnol<6F>gico, cuales son generadoras de conocimientos y de esta forma incentivar su pr<70>ctica. Por otra parte, las Universidades deben continuar con sus labores de investigaci<63>n en temas de actualidad y aumentar la visibilidad de la academia colombiana en el entorno cent<6E>fico mundia, sin embargo, muchos de estos trabajo no se pueden aplicar a corto, mediano y algunos ni a muy largo plazo en Colombia debido al estado de la plataforma tecnol<6F>gica actual. Los centros acad<61>micos deben trabajar en problemas del entorno local, que aunque no tienen reconocimiento a nivel internacional si refleja un grado de compromiso con el entorno social en donde ellas operan.
\textbf{Alianzas Para Obtener y Compartir Recursos}
Como se mencion<6F> anteriormente Colombia es el pa<70>s de Sur-Am<41>rica que menos invierte en Investigaci<63>n y Desarrollo, por esta raz<61>n es necesario crear alianzas estrat<61>gicas para compartir los escasos recursos disponibles, en la actualidad no existe una red nacional de Universidades que trabajen conjuntamente en temas tecnol<6F>gicos, por eso vemos que muchas investigaciones se repiten y se compran costosos equipos que en muchos casos se sub-utilizan. En la actualidad el Servicio Nacional de Aprendizaje SENA posee una gran cantidad de recursos econ<6F>micos, de infraestructura y de equipos, adicionalmente tiene una muy buena relaci<63>n con peque<75>as empresas y conoce las necesidades de este sector, la funci<63>n del SENA es proporcionar formaci<63>n a nivel t<>cnico que soporte las actividades de las empresas Colombianas, sin embargo, los centros de educaci<63>n superior no utilizan esta coyuntura para acercarse a la empresa y de esta forma obtener recursos necesarios para sus actividades en investigaci<63>n.
\section{Actividades}
En la Figura \ref{thesis_flow} se hace un res<65>men de las recomendaciones formuladas anteriormente para lograr una transferencia tecnol<6F>gica exitosa y como estas est<73>n relacionadas con actividades requeridas para el mejoramiento de la plataforma tecnol<6F>gica y la creaci<63>n de una cultura de transferencia de tecnolog<6F>a en el <20>rea de Sistemas Embebidos. <20>rea en la que (como veremos m<>s adelante) el pa<70>s puede competir a corto plazo con productos provenientes de paises industrializados. Adicionalmente, los sistemas embebidos cubren un amplio campo de aplicaciones comerciales y requieren de conocimientos y habilidades especiales. Estas habilidades deben ser desarrolladas por los centros de formaci<63>n teniendo en mente la situaci<63>n actual del pa<70>s y la situaci<63>n a la que se quiere llegar.
\begin{sidewaysfigure}[ht]
\begin{center} \includegraphics[scale=.6]{./images/thesis_flow_diagram.png} \end{center}
\caption{esum<EFBFBD>n de las Actividades Realizadas Para Encontrar una Metodolog<6F>a para la Transferencia Tecnol<6F>gica en Sistemas Embebidos} \label{thesis_flow}
\end{sidewaysfigure}
Todas las actividades desarrolladas buscan la creaci<63>n de conocimiento alrededor del tema de Transferencia Tecnol<6F>gica en el <20>rea de Sistemas Embebidos (SE), se parte del concepto \textit{El Conocimiento como Bien Com<6F>n} \cite{Ost00} \cite{EO92} \cite{EO90} \cite{AC09}, y por lo tanto, se deben crear mecanismos que permitan su distribuci<63>n, organizaci<63>n, mejoramiento y actualizaci<63>n. Este trabajo representa la semilla de este recurso y es el fruto del trabajo de 5 a<>os de estudio de metodolog<6F>as de dise<73>o, fabricaci<63>n y producci<63>n, experimentaci<63>n, establecimiento de relaciones de todo tipo para entender la din<69>mica de la industria Colombiana y mundial. Todo esto para identificar las habilidades con las que debe contar un profesional para que lidere proyectos innovadores y emprendedores que permitan la creaci<63>n de empresas locales y de esta forma generar empleo y mejorar las condiciones de vida de la comunidad asociada a la Universidad Nacional de Colombia. Y adicionalmente, detectar las necesidades de la industria Colombiana y generar actividades para la transferencia de estos conocimientos. Las actividades se dividieron en los siguientes cuatro grupos:
\begin{itemize}
\item \textbf{Creaci<EFBFBD>n de Habilidades Necesarias Para una Transferenica Tecnol<6F>gica Exitosa}: Aplicaci<63>n del plan de estudios \textit{CDIO} \cite{WCI} a las asignaturas del <20>rea de Electr<74>nica Digital, utilizando las habilidades que requiere la industra electr<74>nica nacional. Para poder generar estas habilidades se requiere de una serie de conocimientos con los que no se contaba hasta el momento en la Concepci<63>n, Dise<73>o e Implementaci<63>n de Sistemas Embebidos, por lo que se realiz<69> un estudio sobre metodolog<6F>as de dise<73>o, implementaci<63>n y producci<63>n de sistemas digitales. El conocimiento y la experiencia adquirida se esta documentando en un servidor p<>blio y hace parte del proyecto QI-Hardware \cite{QH}, esta informaci<63>n le permitir<69> a cualquier personal entender, usar y modificar la gran variedad de plataformas de referencia ya sea para adquirir o mejorar habilidades en la Concepci<63>n, Dise<73>o e Implementaci<63>n de SE o para crear nuevos dispositivos que satisfagan una determinada necesidad. En el cap<61>tulo \ref{ch:embedded} se realizar<61> una descripci<63>n de las actividades realizadas y las plataformas dise<73>adas durante este estudio. En el cap<61>tulo \ref{ch:education} se hace una descripci<63>n del proceso que se llev<65> a cabo para la aplicaci<63>n del plan de estudios \textit{CDIO} a las asignaturas del <20>rea de Electr<74>nica Digital.
\item \textbf{Creaci<EFBFBD>n de Empresas de Base Tecnol<6F>gica}: La principal fuente de informaci<63>n sobre la din<69>mica de la industria electr<74>nica Colombiana y el estado de la industria Electr<74>nica mundial (la que se utiliz<69> para determinar las necesidades de las empresas locales, y las habilidades que los prefesionales en el <20>rea deben poseer para suplirlas) fu<66> la empresa Colombiana emQbit, esta empresa fue creada por un grupo de egresados de la Universidad Nacional de Colombia, los cuales con la asesor<6F>a del autor de este trabajo de investigaci<63>n incursionaron en la concepci<63>n, dise<73>o e Implementaci<63>n de Sistemas Digitales, concirti<74>ndose en la primera y <20>nica empresa en Colombia que realiza el proceso completo del proceso de dise<73>o de SE \cite{CC06}.\cite{emQ}. En el cap<61>tulo \ref{ch:embedded} se enumerar<61>n las actividades realizadas con esta empresa.
\item \textbf{Hardware Copyleft}: El movimiento de Software Libre y de C<>digo Abierto (FOSS) es hoy en d<>a la estructura auto-gobernada m<>s exitosa, millones de personas alrededor del mundo trabajan de forma conjunta y distribuida en busca de un bien com<6F>n: Generaci<63>n y distribuci<63>n de herramientas software, sistema operativo y todo tipo de aplicaciones incluyendo el c<>digo fuente bajo una licencia que permite su distribuci<63>n y modificaci<63>n. Este movimiento busca romper los grandes monopolios en la industria del Software, donde el usuario final no puede participar en el proceso de creaci<63>n del mismo y debe pagar por aplicaciones que no se ajustan a sus necesidades, que presentan errores en su funcionamiento, acaptar todos estos problemas y pagar por actualizaciones. Adicionalmente, buscan difundir los conocimientos que un determinado programador adquiri<72> para el desarrollo de una aplicaci<63>n permitiendo el estudio del c<>digo fuente, creando listas de discusi<73>n donde se resuelven todo tipo de dudas y se planifica de forma conjunta el desarrollo de estas aplicaciones, desarrollando tutoriales y libros disponibles en l<>nea.
Este movimiento ha creado toda una serie de herramientas que compiten con las suministradas por multinacionales como Microsoft y Apple, dentro de las m<>s destacables se encuentran: La \textit{cadena de herramientas de compilaci<63>n GNU}, librer<65>as, el sistema operativo \textit{Linux}, aplicaciones como el servidor web \textit{Apache}, el explorador \textit{Mozilla}, la suite ofim<69>tica \textit{OpenOffice} y distribuciones como \textit{Debian}, \textit{Ubuntu}, \textit{Suse}, \textit{Redhat}. Gracias a esto es, se dispone de una cantidad enorme de aplicaciones en diversos campos que pueden ser utilizadas para adquirir conocimientos y desarrollar aplicaciones en diferentes <20>reas.
El resultado m<>s notable, es la creaci<63>n de un recurso de bien com<6F>n: el conocimiento contenido en las herramientas y aplicaciones, la infra-estructura f<>sica y tecnol<6F>gica para su distribuci<63>n y difusi<73>n, y una comunidad que se encarga de contribuir, mejorar y administrar este recurso. Este recurso est<73> basado en principios de libertad y de confianza, esto es, cualquier persona puede ser parte de la comunidad y participar en los procesos de toma de decisiones y creaci<63>n de normas, y deben conocer de antemano las reglas de interacci<63>n entre los miembros y como sus acciones afectan a los otros miembros y al recurso. En el cap<61>tulo \ref{ch:common} estudiaremos con m<>s detalle este movimiento.
Este trabajo contribuye con la creaci<63>n de un movimiento inspirado en el movimiento FOSS, pero dirigido al desarrollo de aplicaciones Hardware, esto es, Circuitos Integrados, Placas de Circuito Impreso, Dispositivos comercializables, programaci<63>n y generaci<63>n de bienes y servicios asociados a estos productos. En la actualidad existen varios proyectos que proporcionan los archivos de dise<73>o para reproducir el componente hardware, sin embargo, no existe un consenso sobre las caracter<65>sticas que se deben cumplir para que sea considerado \textit{copyleft}, esta es una de los t<>picos que se abordar<61>n en el cap<61>tulo \ref{ch:common}
\end{itemize}

View File

@@ -0,0 +1,563 @@
\chapter{TRANSFERENCIA TECNOL<4F>GICA}
\begin{quote}
"Social development today is determined by the ability to stablish a synergistic interaction between technological innovation and human values"
Castells 1999
\end{quote}
La transferencia de tecnolog<6F>a seg<65>n Van Gigch involucra la adquisici<63>n de "actividad Inventiva" por parte de usuarios secundarios. Es decir, la
transferencia tecnol<6F>gica no involucra necesariamente maquinaria o dispositivos f<>sicos. El conocimiento puede ser transferido a trav<61>s de entrenamiento y
educaci<EFBFBD>n, y puede incluir temas como manejo efectivo de procesos y cambios tecnol<6F>gicos\cite{FBFP07} .
La transferencia tecnol<6F>gica es un proceso din<69>mico que debe ser re-evaluado peri<72>dicamente, requiere una infraestructura adecuada que involucra
instituciones, institutos de formaci<63>n vocacional, t<>cnica y administrativa, personal con diferentes especialidades y un entorno cultural adecuado.
Es dif<69>cil que la tecnolog<6F>a desarrollada en un entorno determinado pueda ser transferida sin realizar modificaciones en la escala de producci<63>n y
la adopci<63>n de productos al mercado local.
La transferencia de tecnolog<6F>a ha introducido t<>cnicas de alta productividad y en muchos casos cambios t<>cnicos en pa<70>ses menos desarrollados.
La adquisici<63>n de tecnolog<6F>a for<6F>nea contribuye a mejorar la competitividad en los mercados locales e internacionales en estos pa<70>ses, en los que debe
ser considerada como un proceso vital. Este proceso presenta problemas cuando se pierde capacidad de absorci<63>n por parte del pa<70>s receptor y la
renuencia del pa<70>s que transfiere a transferir tecnolog<6F>a real y el know-how. Por lo que es necesario que estos pa<70>ses promuevan sus capacidades
tecnol<EFBFBD>gicas locales con el fin de absorber las tecnolog<6F>as for<6F>neas de forma eficiente en funci<63>n de sus necesidades locales y de esta forma forma
generar un r<>pido proceso de industrializaci<63>n.
No debe confundirse la transferencia tecnol<6F>gica con la apropiaci<63>n de tecnolog<6F>a que se define como el proceso de interacci<63>n con la tecnolog<6F>a,
la modificaci<63>n de la forma como es usada y el marco social dentro del cual es usada. Un ejemplo de apropiaci<63>n de tecnolog<6F>a lo podemos encontrar
en la telefon<6F>a celular, nuestras sociedades han cambiado dr<64>sticamente su forma de comunicarse y han generado nuevas actividades alrededor de esta
tecnolog<EFBFBD>a, los usuarios pueden generar aplicaciones que adicionan funcionalidades y servicios.
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%% DEFINICION DE TRANSFERENICA TECNOLOG<4F>A %%%%%%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\section{Tecnolog<6F>a}
La tecnolog<6F>a es definida como el factor m<>s significativo para mejorar la productividad, calidad y competitividad \cite{GC04} y puede verse como
un proceso de transformaci<63>n de recursos que tiene como entrada recursos naturales, bienes, o preductos semi-manufacturados y como salida se obtienen
bienes consumibles de capital y semi-manufacturados. El \textit{Technology Atlas team} identifica cuatro componentes de la tecnolog<6F>a \cite{FBFP07}:
\begin{itemize}
\item Techno-ware Relacionado con objetos: Herramientas, equipos, m<>quinas, veh<65>culos, facilidades f<>sicas, instrumentos, dispositivos y f<>bricas
\item Human-ware Relacionado con personas: Habilidades en conocimiento experimental, sabidur<75>a y creatividad, experiencia, competencia, creatividad.
\item Info-ware Relacionado con la Informaci<63>n: Incluye todo tipo de documentaci<63>n y datos acumulados relacionados con especificaci<63>n de procesos,
procedimientos, dise<73>os, teor<6F>as, y observaciones
\item orga-ware Relacionado con la Organizaci<63>n: Acuerdos y Alianzas necesarias para facilitar la integraci<63>n de los componentes T<>cnico, Humano, y
de informaci<63>n. Involucra asignaci<63>n, sistematizaci<63>n, organizaci<63>n, redes de comunicaci<63>n.
\end{itemize}
El uso efectivo de estos cuatro componentes requiere el cumplimiento de ciertas condiciones. El componente t<>cnico requiere de personal con habilidades
espec<EFBFBD>ficas para poder ser utilizado. Para mejorar la eficiencia del sistema el componente humano necesita de adaptaci<63>n y motivaci<63>n. A medida que la
organizaci<EFBFBD>n cambia para adaptarse a nuevas condiciones o requerimientos se debe actualizar el sector de la informaci<63>n. \textbf{No es posible realizar
operaciones de transformaci<63>n ante la ausencia de uno de estos cuatro componentes}
La interacci<63>n de estos cuatro componentes puedes ser resumida de la siguiente forma:
\begin{itemize}
\item \textit{Tecnoware} constituye el n<>cleo de cualquier tecnolog<6F>a, es decir, una habilidad de transformaci<63>n, y es desarrollada, instalada y operada
por \textit{humanware}.
\item \textit{Humanware} o las habilidades individuales representan el elemento clave de cualquier operaci<63>n de transfomaci<63>n guiada por el \textit{infoware}
\item \textit{Infoware} almacena conocimiento acumulado para ahorrar tiempo en el aprendizaje individual. Es generado y utilizado por \textit{humanware}
para los procesos de toma de decisiones y operaciones.
\item \textit{Orgaware}, o el marco de trabajo administrativo, adquiere y administra el tecnoware, humanware e infoware con el fin de realizar la operaci<63>n.
Orgaware se compone de las actividades de planeaci<63>n, organizaci<63>n, activaci<63>n, motivaci<63>n y control de operaciones.
\end{itemize}
La tecnolog<6F>a no esta asociada a un sistema socio-econ<6F>mico abstracto. La tecnolog<6F>a se encuentra fuertemente relacionada con un espectro amplio de las
necesidades humanas, si se dictan por las condiciones f<>sicas existentes o por factores culturales derivados de las especificidades hist<73>ricas de
diferentes grupos sociales \cite{KGSB95}. En res<65>men, la tecnolog<6F>a esta compuesta de conocimiento, herramientas, t<>cnicas y actividades utilizadas
para transformar las entradas de la organizaci<63>n en salidas.
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%% DEFINICION DE TRANSFERENICA TECNOL<4F>GICA %%%%%%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\section{Definici<63>n}
Odedra \cite{Mo94} define la transferencia tecnol<6F>gica como el problema de transfencia de conocimiento
(o know-how) sobre un n<>mero de aspectos (que incluyen el conocimiento) sobre como funciona
un determinado sistema, como operarlo y desarrollar sus aplicaciones, como mantenerlo y si
es necesario, como producir sus componentes y montar un sistema similar. La transferencia
tecnol<EFBFBD>gica se considera exitosa cuando los receptores de la tecnolog<6F>a asimilan los conceptos
anteriores para suplir sus necesidades locales.
Seg<EFBFBD>n Jolly \cite{Jol77} La innovaci<63>n tecnol<6F>gica es entendida como un nuevo m<>todo, medio o capacidad del individuo para realizar una determinada actividad. El resultado de la transferencia tecnol<6F>gica puede ser la aceptaci<63>n de una pr<70>ctica com<6F>n en otros lugares, o la aplicaci<63>n de una t<>cnica
dise<EFBFBD>ada para otro uso en la saluci<63>n de problemas locales, debe distinguirse del proceso general de difusi<73>n de tecnolog<6F>a: un movimiento no planeado de art<72>culos sociales y tecnol<6F>gicos de un lugar a otro sin ning<6E>n esfuerzo centrado en la transferencia. La transferencia tecnol<6F>gica incluye la difusi<73>n de conocimiento cient<6E>fico y la preocupaci<63>n por la transformaci<63>n del conocimiento en innovaciones <20>tiles. El conocimiento es lo que queda al final de un proceso documentado y difundido de forma apropiada. Para que la transferencia tecnol<6F>gica sea exitosa es necesario transferir los componentes de la tecnolog<6F>a, es decir: Los conocimientos t<>cnicos, las habilidades humanas, la informaci<63>n y la estructura de la organizaci<63>n.
\subsection{Tipos de Transferencia Tecnol<6F>gica}
Mansfield clasifica la transferencia tecnol<6F>gica en transferencia de material, dise<73>o y capacidades, la transferencia de material no constituye una transfencia tecnol<6F>gica real, ya que no genera el conocimiento necesario para transformarlos y generar nuevos productos que cumplan con las necesidades locales
\begin{itemize}
\item Transferencia material: Artefactos tecnol<6F>gicos: Materiales, productos finales, componentes, equipos
\item Transferenica de dise<73>o: Dise<73>os, proyectos, know-how para fabricar productos dise<73>ados previamente. Los productos son copiados para producirlos
localmente.
\item Transferencia de Capacidades: Proporciona know-how y software no solo para fabricar componentes existentes, sino, innovar y adaptar tecnolog<6F>as
existentes para producir nuevos productos.
\end{itemize}
La transferencia de dise<73>os permite adquirir mayor conocimiento sobre la tecnolog<6F>a transferida, sin embargo, es necesario que el pais receptor cuente con la plataforma tecnol<6F>gica adecuada para absorver estos conocimientos, de lo contario no se generar<61>n nuevos productos y las actividades se limitar<61>n al ensamblaje de productos pre-manufacturados. La transferencia de capacidades es ideal, ya que proporciona las herramientas necesarias para que la transferencia sea exitosa, est<73> asociada a una transferencia de conocimiento, lo cual es vital para entender plenamente la tecnolog<6F>a, mejorando las habilidades de los profesionales del receptor.
Otra clasificaci<63>n distingue entre Transferencia Vertical y Horizontal:
\begin{itemize}
\item Transferencia Vertical: Transferencia de informaci<63>n t<>cnica a diferentes niveles de un proceso innovativo determinado. Por ejemplo de
investigaci<EFBFBD>n b<>sica a investigaci<63>n aplicada, de investigaci<63>n aplicada a desarrollo y de desarrollo a producci<63>n. es decir, una progresi<73>n
tecnol<EFBFBD>gica desde la teor<6F>a al producto terminado.
\item Transferencia Horizontal: Cuando se utiliza en un lugar, organizaci<63>n o contexto y es transferida y utilizada en otro lugar.
\end{itemize}
La transferencia vertical establece varios pasos en la transferencia, que pueden ser aplicados en diferentes niveles: Entre centros acad<61>micos, transferencia entre la academia y la empresa para generar aplicaciones, prototipos y producci<63>n en masa. La desconcexi<78>n entre la Universidad y la empresa en Colombia y en la mayor<6F>a de los pa<70>ses en desarrollo hace que los objetivos que persigue la Academia no est<73>n sintonizados con las necesidades de la industria y en muchas ocasiones los productos generados en la Academia nunca llegan a las industrias locales, ya sea porque no tienen la infraestructura tecnol<6F>gica para hacerlo o porque la Universidad no proporciona el soporte necesario para que ese producto pueda ser utilizado en la pr<70>ctica.
\subsection{Canales Para la Transferencia de tecnolog<6F>a}
Erdilec and Rapoport [45] clasifican los mecanismos en Formales: Acuerdos de licenciamiento, Inversi<73>n extranjera, compa<70><61>as conjuntas, acuerdos de cooperaci<63>n en investigaci<63>n, arreglos de producci<63>n conjunta e Informales: No involucran acuerdos entre las partes y son dif<69>ciles de detectar y monitorear, por ejemplo, exportaci<63>n de productos tecnol<6F>gicos o bienes de capital, ingenier<65>a inversa, intercambio de personal t<>cnico y cient<6E>fico, conferencias de ciencia y tecnolog<6F>a, ferias y exposiciones, educaci<63>n y entrenamiento realizado por extranjeros, visitas comerciales, literatura abierta (art<72>culos, revistas, libros t<>cnicos), espionaje industrial. Adicionalmente, existe una divisi<73>n basada en la naturaleza de la instituci<63>n que proporciona los recursos para que se realice la transferencia, la instituci<63>n puede ser de car<61>cter:
\begin{itemize}
\item \textit{Abierta} en donde la tecnolog<6F>a y el conocimiento s<>n considerados bienes p<>blicos, no existen restricciones para acceder a la informaci<63>n necesaria para adquirir, usar y transformar estos conocimientos en productos comerciales, y su <20>xito radica en obtener la m<>xima difusi<73>n posible para que los usuarios de este conocimiento mejoren el material existente y contribuyan con experiencias personale,
\item \textit{Cerrada} La tecnolog<6F>a y el conocimiento se genera para fines privados, la utilizaci<63>n de este conocimiento esta sometida a acuerdos comerciales. No es posible entender las bases de la tecnolog<6F>a, por lo que no se pueden generar productos derivados.
\end{itemize}
Las actividades realizadas durante este estudio est<73>n enmarcadas dentro del concepto: \textit{El conocimiento es un Bien Com<6F>n}, toda la documentaci<63>n necesaria para reproducir, entrenar, entender y modificar los productos generados se encuentran disponibles en servidores p<>blicos \cite{WSCC} \cite{CC} y se proporciona soporte a trav<61>s de listas de discusi<73>n, adicionalmente se proporciona soporte comercial para permitir la producci<63>n de estas modificaciones. A continuaci<63>n se realiza una descripci<63>n de los canales m<>s utilizados para la transferencia de tecnolog<6F>a y conocimiento en pa<70>ses en v<>a de desarrollo (\cite{MO90} \cite{Mo94} \cite{MO91}) indicando en cada caso sus ventajes, limitaciones y desventajas.
\subsubsection{Adquisici<63>n de IT}
La adquisici<63>n de equipo ha sido uno de los mecanismos de transferencia m<>s importantes para los pa<70>ses en desarrollo. Estos equipos
se entregan con el software requerido para su funcionamiento con lo que no es necesario que los usuarios generen aplicaciones, por lo que
solo adquieren el conocimiento necesario para utilizar estas m<>quinas, y por lo tanto no saben como funcionan.
Otra forma de transferencia se presenta cuando una empresa vende una soluci<63>n personalizada a las necesidades de los clientes. La
transferencia tecnol<6F>gica se presenta en el proceso de personalizaci<63>n, esto, unido a otras habilidades en programaci<63>n ayudan a elevar
el mercado de SW local. Sin embargo, en muchas ocasiones no se detect<63> ning<6E>n tipo de transferencia de knowhow en la adquisici<63>n de estas m<>quinas.
Las grandes multinacionales como IBM, Microsoft, NCR dominan el mercado de Software y Hardware y hacen que sea imposible el ingreso de
peque<EFBFBD>as compa<70><61>as locales, lo que se traduce en que el mantenimiento y servicios asociados al hardware, as<61> como los ajustes de Software
sean realizados por los proveedores de las multinacionales y en muy pocos casos los usuarios de esta tecnolog<6F>a adquieren habilidades
para sostener el equipo. La transferencia se realiza a subsidiarias de las multinacionales, con lo que la transferencia es m<>nima, esto se
hace para que la dependencia no se pierda.
En conclusi<73>n con la venta de equipos se transmite <20>nicamente el conocimiento para operar, programar o mantener, sin embargo,
este conocimiento sobre el sistema puede ayudar a concientizarse sobre la tecnolog<6F>a e impulsar la formaci<63>n de capital humano.
La experiencia de pa<70>ses que lograron un r<>pido desarrollo econ<6F>mico e industrial muestra que la adquisici<63>n de una gran cantidad de
tecnolog<EFBFBD>a for<6F>nea jug<75> un papel importante en este proceso. Colombia ha realizado un proceso de transformaci<63>n tecnol<6F>gica pero no ha
dise<EFBFBD>ado pol<6F>ticas efectivas y eficientes para la transferencia de tecnolog<6F>as de alto nivel
.
\subsubsection{Educaci<63>n y Entrenamiento}
Educar a las personas a trav<61>s de cursos y entrenamiento en el pa<70>s y envi<76>ndolas al extranjero para otros estudios es una forma de adquirir
know-how sobre nuevas tecnolog<6F>as, o tecnolog<6F>as que no se utilizan en el pa<70>s de origen. Muchas instituciones ofrecen carreras en
Ingenier<EFBFBD>a Electr<74>nica, Ciencias de la computaci<63>n y afines, algunas de ellas utilizan modelos pedag<61>gicos utilizados en pa<70>ses desarrollados,
los que no han sido adaptados plenamente a la infraestructura tecnol<6F>gica local, y no es raro encontrar estudiantes que no est<73>n satisfechos
con su profesi<73>n al finalizar los cursos\cite{Mo94}.
En muchas Universidades temas como Nanotecnolog<6F>a, Dise<73>o de Circuitos integrados de muy alta integraci<63>n (VLSI) hacen parte importante de las
actividades de investigaci<63>n; la pertinencia de estos t<>picos avanzados ante la situaci<63>n tecnol<6F>gica del pa<70>s es discutible ya que muchos
estudiantes no aplicar<61>n nunca estos conocimientos en el entorno local, por lo que la ense<73>anza de estos t<>picos puede resultar una p<>rdida de
recursos. Es m<>s, con los r<>pidos cambios en la industria electr<74>nica estos conocimientos pueden resultar irrelevantes, a<>n si la
infraestructura del pa<70>s se mejora. Es decir, es importante no dejarse llevar por el momento, o por la "fama" de un t<>pico de investigaci<63>n
o de una tecnolog<6F>a novedosa, es necesario evaluar la pertinencia de los cursos que se dictan en el entorno tecnol<6F>gico local, por supuesto,
es necesario que la academia impulse cambios en el sector, pero estos cambios deben ser consecuentes con el nivel tecnol<6F>gico que posea el pa<70>s.
La transferencia tecnol<6F>gica no ocurre cuando estudiantes formados en el exterior no pueden aplicar sus conocimientos en su pa<70>s de origen,
por lo que es necesario crear pol<6F>ticas que definan que <20>reas de estudio son prioritarias para el pa<70>s.
Las multinacionales tambi<62>n ofrecen cursos de capacitaci<63>n, sin embargo, se limitan al uso de sus productos, creando dependencia hacia
sus herramientas. Adicionalmente, existen centros privados de capacitaci<63>n que ofrecen cursos para el manejo de paquetes y lenguajes de
programaci<EFBFBD>n, estos centros aprovechan la falta de centros de ense<73>anza tecnol<6F>gica y personal calificado para cobrar altas sumas de dinero,
lo cual limita el acceso. Programas acad<61>micos inapropiados, acceso limitado a libros y computadores, falta de facilidades para capacitaci<63>n, reduce la efectividad
de la educaci<63>n y capacitaci<63>n como canal para la transferencia tecnol<6F>gica.
\subsubsection{Asistencia T<>cnica}
La ventaja de contratar consultores externos radica en el ahorro de tiempo y dinero, ya que, utilizar personal local implicar<61>a un gran esfuerzo
y posiblemente se tendr<64>an que asumir errores costosos en el proceso. Sin embargo, no es bueno confiar a consultores externos la responsabilidad
de construir habilidades locales, ya que reduce el desarrollo de estas habilidades, especialmente, la del personal encargado de manejar proyectos.
En algunas ocasiones los consultores no est<73>n familiarizados con las condiciones y requerimientos locales, con lo que dise<73>an soluciones que no se
ajustan perfectamente a las necesidades, lo que significa que el sistema es sub-utilizado y la transferencia de tecnolog<6F>a es poca. La falta de
personal calificado hace que los consultores se encarguen de todas las tareas del proyecto, lo que aumenta su carga de trabajo y disminuye la
posibilidad de entrenamiento de personal local\cite{Mo94}.
En algunas ocaciones los consultores son representantes de grandes multimacionales y todas sus acciones est<73>n dirigidas a aumentar la dependencia
con los productos generados por dichas transnacionales y a ignorar de forma sistem<65>tica opciones que pueden ayudar a la transferencia de conocimiento,
llegando hasta el punto de influir en la formulaci<63>n de pol<6F>ticas para transferencia tecnol<6F>gica. Un ejemplo de este tipo de alianzas no convenientes
se presenta en la industria del Software dominada por Microsft. Microsoft firma acuerdos con centros educativos oficiales para la distribuci<63>n de
sus productos con licencias a muy bajo costo, el estudiante se acostumbra a utilizarlas y cuando sea un profesional debe adquirirlas a un precio
elevado para poder realizar su actividad profesional con la <20>nica herramienta que conoce.
\subsubsection{Licenciamiento}
El licenciamiento es un canal que se utiliza para transferencia de know-how sobre productos o procesos, es aplicado de forma individual o en
combinaci<EFBFBD>n con otros instrumentos como investigaci<63>n extranjera, importaci<63>n de maquinaria o de t<>cnicos. Sin embargo, no es efectivo si no
se acompa<70>a de habilidades administrativas y de producci<63>n. Adicionalmente, es necesario contar con una infraestructura tecnol<6F>gica adecuada,
capacidades locales de fabricaci<63>n de hardware y software y pol<6F>ticas de gobierno adecuadas \cite{Mo94}.
Un ejemplo de este tipo de pr<70>ctica se presenta en el ensamble de dispositivos electr<74>nicos, todos los componentes se importan completamente
terminados y el dispositivo final es ensamblado probado y se carga la configuraci<63>n inical, no se producen actividades de ingenier<65>a inversa con
lo que se transmite muy poco conocimiento.
Sin embargo, es necesario crear una confianza en los productos locales, el gobierno debe crear pol<6F>ticas de protecci<63>n de los productos generados
localmente, pa<70>ses de latinoamerica aplican este tipo de protecciones y solo permiten la importaci<63>n de productos que no se fabriquen en el pa<70>s.
Esto aumenta la confianza en los productos generados localmente e impulsa el desarrollo industrial y la generaci<63>n de empleo.
\subsubsection{Inversi<73>n Extranjera Directa}
La inversi<73>n directa de multinacionales es una forma de obtener tecnolog<6F>a externa. Esto asegura una r<>pida transferencia de informaci<63>n
tecnol<EFBFBD>gica, pero no necesariamente del entendimiento o know-how. Lo que hace que la tecnolog<6F>a transferida a trav<61>s de este canal sea m<>nima.
Las grandes multinacionales pueden tener cierto control pol<6F>tico en los pa<70>ses en v<>a de desarrollo, hasta tal punto que son asesores de
instituciones encargadas de fijar pol<6F>ticas para la transferencia tecnol<6F>gica \cite{Mo94}.
El objetivo de la transferencia tecnol<6F>gica debe ser el aumento de la auto-suficiencia en el pais receptor, unido a un uso compartido de
recursos y experiencia entre los pa<70>ses desarrollados y en v<>a de desarrollo. La compra de equipo o de software transfiere muy poco conocimiento
sobre la tecnolog<6F>a, el servicio post-venta y el mantenimiento es realizado por el proveedor. Por otro lado, las facilidades en educaci<63>n y capacitaci<63>n
son limitadas lo cual obstaculiza la formaci<63>n de capital humano. La asistencia t<>cnica utilizada para suplir la falta de personal especializado y
ayudar con el proceso de transferencia no ha sido muy efectiva.
\subsection{Conclusi<73>n}
La efectividad de cada canal depende de la naturaleza de la tecnolog<6F>a que se va a adquirir, el tipo de organizaci<63>n y de las capacidades de absorci<63>n del recipiente. La tecnolog<6F>a es efectiva <20>nicamente cuando la econom<6F>a del pa<70>s es capaz de utilizarla. Cuando se transfiere una tecnolog<6F>a se debe contar con el dinero para adquirirla y se deben generar las actividades necesarias para mejorar la plataforma tecnol<6F>gica, incluyendo la educaci<63>n y la capacitaci<63>n, de tal forma que el pa<70>s sea capaz de absorberla y generar nuevos productos que satisfagan necesidades locales.
El <20>xito de la transferencia tecnol<6F>gica no depende de un factor <20>nico, sino de la confluencia de multiples factores dentro y fuera de la instituci<63>n acad<61>mica. Las relaciones personales entre los agentes de transferencia tecnol<6F>gica y la facultad, licencias corporativas, y las comunidades de investigaci<63>n y de negocios son la clave de esfuerzos exitosos. En muchos casos, las Universidades han liderado el proceso de transferencia tecnol<6F>gica a trav<61>s de sus directivos, estos a trav<61>s de incentivos crean una cultura acad<61>mica que recompensa la transferencia tecnol<6F>gica y el emprendimiento.
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%% Modelo %%%%%%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\section{Modelo}
Un programa de transferencia tecnol<6F>gica bebe incluir mecanismos que unan de forma eficiente la fuente del conocimiento con la utilizaci<63>n del mismo.
Estos canales de comunicaci<63>n son mecanismos de recursos humanos que pueden ser incorporados tanto en la fuente como en el destino,
el proceso de una efectiva transferencia tecnol<6F>gica puede comenzar con potenciales usuarios en lugar de fuentes \cite{Jol77}
La figura \ref{tech_trans_model_global} muestra
\begin{figure}[ht]
\begin{center} \includegraphics[scale=.6]{./images/transfer_model_global.png} \end{center}
\caption{Modelo del proceso de Transferencia de Tecnolog<6F>a} \label{tech_trans_model_global}
\end{figure}
\subsection{Los factores formales}
\subsubsection{Documentaci<63>n}
Es el formato, organizaci<63>n, o presentaci<63>n de la tecnolog<6F>a que ser<65> transferida. El formato y el lenguaje se relacionan directamente con el entendimiento del material por parte del receptor. La informaci<63>n que no se entiende no se utiliza. Los cient<6E>ficos e ingenieros ocupan hasta 4 horas diarias leyendo art<72>culos, hablando con sus pares o buscando informaci<63>n, mientras que los nuevos usuarios (por ejemplo, gobiernos locales, y grupos de ciudadanos) desean gastar menos tiempo en dar respuestas a sus preguntas.
\subsubsection{Distribuci<63>n}
Constituye el canal f<>sico a trav<61>s del cual la tecnolog<6F>a fluye e involucra tanto el n<>mero de entradas y el f<>cil acceso al canal, as<61> como el plan de distribuci<63>n. knox 1973, dice: "Una medida de la efectividad del sistema de informaci<63>n tecnol<6F>gica es al capacidad de permitir el contacto entre personas con necesidades y con posibles soluciones. Ames 1965, Encontr<74> que los abstracts y los papers son la fuente de informaci<63>n m<>s importante, mientras que las reuniones y conferencias el mejor veh<65>culo para crear conciencia, la cual es indispensable para que el proceso de distribuci<63>n sea exitoso, por lo que, el intercambio personal debe ser considerado como parte del proceso de distribuci<63>n de tecnolog<6F>a. Este canal ayuda a eliminar retardos en la investigaci<63>n, ya que permite determinar el estado del arte de una determinada actividad o <20>rea de trabajo.
\subsubsection{Organizaci<63>n}
La percepci<63>n del receptor de la organizaci<63>n. Schon 1967, caracteriza a una organizaci<63>n que es favorable a la transferencia tecnol<6F>gica y utilizaci<63>n de conocimiento como aquella que vive en un estado de urgencia, donde los conflictos son resueltos por mandato, donde los recursos son enviados sin vacilar, y donde la incertidumbre se convierte en un riesgo. Stephenson, Ganz y Erickson 1974, reportan un estudio realizado sobre 109 cient<6E>ficos e ingenieros donde algunos de ellos sienten que una organizaci<63>n ocasionalmente puede actuar como una barrera a las nuevas ideas.
\subsubsection{Selecci<63>n de Proyectos}
Proceso de selecci<63>n para proyectos de investigaci<63>n y desarrollo realizado por el proveedor con ayuda del receptor. Es importante que la investigaci<63>n comience como respuesta a una necesidad del cliente.
La figura \ref{tech_trans_model} muestra
\begin{figure}[ht]
\begin{center} \includegraphics[scale=.6]{./images/transfer_model.png} \end{center}
\caption{Modelo del proceso de Transferencia de Tecnolog<6F>a Indicando La Composici<63>n de Los Canales Formales e Informales} \label{tech_trans_model}
\end{figure}
\subsection{Factores Informales}
Los factores informales son de naturaleza sociol<6F>gica y/o comportamental, y contribuyen fuertemente al <20>xito de la utilizaci<63>n del conocimiento por una determinada organizaci<63>n.
\subsubsection{Capacidad}
La capacidad del usuario para utilizar nuevas ideas que cubren un amplio espectro de rasgos que incluyen riesgo, riqueza, poder, educaci<63>n, experiencia, edad, confianza en s<> mismos.
Atributos como: Atrevimiento, status profesional y educativo, domino, sociabilidad, no son considerados tan importantes frente a la autosuficiencia que es el m<>s valorado.
\subsubsection{Enlace (contacto)}
Presencia y efectos de enlaces informales en la organizaci<63>n receptora. El enlace opera dentro de la organizaci<63>n receptora y exhibe caracter<65>sticas similares al supervisor, l<>der de opini<6E>n, innovador y previo conocedor de la innovaci<63>n.
\subsubsection{Credibilidad}
La credibilidad es una evaluaci<63>n por parte del usuario, de la confiabilidad de la informaci<63>n. Es evaluada analizando la fuente y el canal del mensaje. La opini<6E>n cambia dependiendo de la fuente de la informaci<63>n, es decir, la credibilidad es influenciada por su fuente.
\subsubsection{Recompensa}
Reconocimiento del sistema social del cual hace parte un individuo ante un comportamiento innovador.
\subsubsection{Disposici<63>n}
La habilidad y/o deseo del individuo para aceptar un cambio en la organizaci<63>n de la cual es miembro. As<41> mismo es importante la capacidad de adopci<63>n de nuevas ideas, Gallup 1955 se<73>al<61> que aunque una idea halla sido aceptada intelectualmente, toma un per<65>odo de tiempo antes de ser incorporada en la forma de pensar. Ser consciente de la importancia de de una nueva idea no s suficiente para asegurar su uso; debe existir una disposici<63>n, un inter<65>s, una motivaci<63>n personal para utilizar un mejor m<>todo, proceso o concepto.
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%% Historia %%%%%%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\section{Transferenica Tecnol<6F>gica en Latinoam<61>rica \cite{UNE}}
\subsection{Trasfondo hist<73>rico}
Durante el per<65>odo que va de los a<>os 40 a la d<>cada de los 80, en Am<41>rica Latina y el Caribe se puso en pr<70>ctica una pol<6F>tica de
industrializaci<EFBFBD>n por sustituci<63>n de importaciones mediante modalidades de proteccionismo de la industria manufacturera local.
Con lo que se comenz<6E> a importar los bienes de capital necesarios para la fabricaci<63>n en el <20>mbito local, desarrollando
de esta forma a las industrias locales. Mientras tanto, en los pa<70>ses de donde proven<65>an estos bienes, se transformaba el conocimiento
adquirido de la investigaci<63>n, en nuevos productos, procesos y modelos de gesti<74>n m<>s competitivos. Es decir, se importaron los equipos
para realizar la transformaci<63>n industrial, pero no se generaron las bases cient<6E>fico-tecnol<6F>gicas que se encargaran de generar nuevos
productos asociados a las materias primas proporcionadas por los recursos naturales locales, se descuid<69> el capital humano capaz de entender,
adaptar y llevar estos inventos a la sociedad, salvo en algunas disciplinas agr<67>colas donde la especificidad local oblig<69> a la investigaci<63>n.
Adicionalmente, no se gener<65> demanda local que impulsara la producci<63>n de conocimiento, las nuevas empresas no contaban con departamentos de
Investigaci<EFBFBD>n y desarrollo (I+D) y los gobiernos no estimulaban la creaci<63>n de centros de investigaci<63>n asociados a este proceso de industrializaci<63>n.
Cuando los gobiernos de la regi<67>n se dieron cuenta de esta situaci<63>n crearon la Comisi<73>n para Am<41>rica Latina y el Caribe (CEPAL). A partir
de las d<>cadas de los cincuentas y setentas comenzaron a crear pol<6F>ticas en las <20>reas cient<6E>ficas y tecnol<6F>gicas, creando instituciones
destinadas al fomento de la ciencia y la tecnolog<6F>a. Muchos de estos esfuerzos fueron discontinuos y contradictorios, pero algunos siguieron
las pautas establecidas por la UNESCO y la OEA (basadas en "la idea de que la ciencia y la tecnolog<6F>a eran una usina de crecimiento, en un rico
suelo fertilizado por el deseo de la modernizaci<63>n y el desarrollo") exhibieron una continuidad notable. Esto unido al apoyo gubernamental y
el inter<65>s de las universidades fue clave para la formulaci<63>n de pol<6F>ticas de apoyo a la ciencia y la tecnolog<6F>a.
Gracias a estas pol<6F>ticas hubo un fuerte proceso de institucionalizaci<63>n de la investigaci<63>n cient<6E>fica y de los mecanismos de desarrollo:
Sistemas de promoci<63>n del I+D, legislaci<63>n en transferencia de tecnolog<6F>a, planificaci<63>n de la ciencia, m<>todos de diagn<67>stico de recursos,
sistemas de fijaci<63>n de prioridades tecnol<6F>gicas, etc. A finales de los 50s y dyrante los 60s y 70s, estas actividades eran soportadas casi de
forma exclusiva por el estado (incluyendo las universidades p<>blicas), estos esfuerzos no provocaron una din<69>mica sostenida de innovaci<63>n en el
conocimiento y en la econom<6F>a ya que en muchos sectores no se gener<65> un v<>nculo s<>lido entre la producci<63>n y la investigaci<63>n, esto debido a la
creaci<EFBFBD>n de dos modelos de investigaci<63>n en ciencia y tecnolog<6F>a:
\begin{itemize}
\item Ciencia Acad<61>mica: Basada en las universidades, es incorporada a la comunidad cient<6E>fica internacional, de quien recibe legitimidad, orientaci<63>n,
organizaci<EFBFBD>n.
\item Actividad Tecnol<6F>gica: Sustentada por organismos sectoriales, legitimada por instituciones estatales, su objetivo es dar soluci<63>n a problemas
pr<EFBFBD>cticos y a la transferencia de tecnolog<6F>a al sector productivo.
\end{itemize}
En los a<>os 80 disminuy<75> la confianza de poder encontrar un camino hacia un desarrollo end<6E>geno, lo que origin<69> un giro hacia pol<6F>ticas de ajuste,
estabilizaci<EFBFBD>n y apertura de la econom<6F>a que buscaban v<>as alternas para llegar a la globalizaci<63>n. La apertura de la econom<6F>a supon<6F>a un
abastecimiento de nuevos conocimientos por parte de las empresas locales para estar a tono con el estado internacional o la b<>squeda de nuevos
nichos de mercado; por otro lado, la apertura forzar<61>a una homogeneizaci<63>n tecnol<6F>gica, por lo que el aumento de la competitividad se lograr<61>a
a trav<61>s de la transferencia de productos externos y no la inventiva e innovaci<63>n local.
En los a<>os 90 los pa<70>ses de la regi<67>n realizan grandes compras a costa de su endeudamiento externo. La industria local se ve enfrentadas a
productos extranjeros baratos, lo que ocasiona el cierre de muchas industrias manufactureras y la transformaci<63>n de muchas en importadores;
esta pol<6F>tica desmantela el aparato productivo y no fomenta actividades de adaptaci<63>n, mejora y creaci<63>n de productos. La oferta tecnol<6F>gica
proviene del exterior, se diluye el sistema nacional de ciencia y tecnolog<6F>a basado en el aumento de la oferta interna de conocimiento.
Las pol<6F>ticas p<>blicas se reducen a la aceptaci<63>n de normas de la Organizaci<63>n Mundial de Comercio (OMC) basadas en presiones de Estados
Unidos y la Uni<6E>n Europea sobre patentes farmac<61>uticas, tecnolog<6F>as agr<67>colas y de otros tipos. No es que no existan esfuerzos e interacciones tecnol<6F>gicas entre la ciencia y la producci<63>n; el problema es que no constituyen un sistema autosostenido de relaciones din<69>micas que marquen un rumbo claro a la investigaci<63>n en ciencia y tecnolog<6F>a vinculado con las sociedades y las econom<6F>as donde se desenvuelven.
Seg<EFBFBD>n Gibbons y Schwartzman, la investigaci<63>n cient<6E>fica se origina y justifica cada vez m<>s en el contexto de aplicaci<63>n del conocimiento,
es decir, en la posibilidad de su utilizaci<63>n. Por lo que los temas de investigaci<63>n no son fijados por los cient<6E>ficos sino por redes formadas
por empresarios, ingenieros de planta e inversionistas. Lo que lleva a que las diferencias entre las dos formas de investigaci<63>n disminuyan.
En tal sentido, no es seguro que la inserci<63>n en el comercio internacional de Am<41>rica Latina favorezca su posici<63>n en la producci<63>n de
conocimientos en ciencia y tecnolog<6F>a.
La ciencia y la tecnolog<6F>a en la regi<67>n presenta dos grandes probleams: a) su escasa magnitud; b) su desvinculaci<63>n con la sociedad a
la que pertenece, con el agravante de la p<>rdida de legitimidad que se produjo en las <20>ltimas dos d<>cadas, sustentada por una parte en
el Estado, y en su integraci<63>n en una ciencia internacional fuertemente acad<61>mica, por la otra.
\subsection{Financiaci<63>n}
Seg<EFBFBD>n la Red de Indicadores de Ciencia y Tecnolog<6F>a (RYCIT), el gasto en actividades de ciencia y tecnolog<6F>a en los pa<70>ses latinoamericanos alcanza poco menos de los 8.000 millones de d<>lares anuales, lo cual representa el 2,3\% del gasto mundial en el sector. Mientras el PBI de Estados Unidos cuadruplica al de Am<41>rica Latina y el Caribe, su inversi<73>n en I+D es m<>s de 20 veces mayor que la latinoamericana. Dicho de otro modo, el esfuerzo de los pa<70>ses de la regi<67>n en ciencia y tecnolog<6F>a es inferior al que les corresponder<65>a realizar tomando en cuenta el valor del producto regional.
Seg<EFBFBD>n la Organization for Economic Co-operation and Development (OCED) los pa<70>ses Latinoamericanos dedican en promedio algo m<>s del 0,6\% de su Producto Interno Bruto a I+D. Esta inversi<73>n se concentra en Brasil, M<>xico y Argentina, en Colombia el gasto es del 0.18\% lo que contrasta fuertemente con el gasto militar de 3.4\%. En la Uni<6E>n Europea, en cambio, el porcentaje alcanza el 1,7\% del PIB, en Estados Unidos alcanza el 2,8\%, Jap<61>n (3,13\%), Corea del Sur (2,52\%) y otros como China e India en los cuales, aunque la inversi<73>n es algo inferior, la tendencia de los <20>ltimos a<>os hace pensar en un aumento progresivo de sus inversiones en I+D. El gasto en ciencia y tecnolog<6F>a como el recurso promedio que tienen los investigadores para llevar a cabo su tarea, en EEUU asciende a 171.000 d<>lares por investigador, y en el conjunto de pa<70>ses latinoamericanos a 59.000.
Un rasgo caracter<65>stico de la investigaci<63>n cient<6E>fica en Am<41>rica Latina es su gran dependencia del Estado, seg<65>n un estudio de la OCED, en el plano estrictamente tecnol<6F>gico, las estad<61>sticas sobre patentes describen un panorama entre el norte y el sur similar a los datos del I+D: el n<>mero de solicitudes de patentes en EEUU es del orden de los 200.000 por a<>o, m<>s de 50.000 y de 40.000 en Espa<70>a y Canad<61>, respectivamente. En Am<41>rica Latina, s<>lo Brasil y M<>xico (pero ambos con marcados desniveles anuales) presentan cifras algo significativas: entre 6.000 y 10.000 patentes anuales. Aun as<61> son valores marcadamente inferiores.
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%% Obstaculo %%%%%%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\section{Obst<73>culos para una Transferencia Exitosa}
La cantidad de conocimiento y tecnolog<6F>a transferida es afectada por pol<6F>ticas gubernamentales, la situaci<63>n econ<6F>mica, facilidades de educaci<63>n y capacitaci<63>n, personal calificado, aspectos organizacionales y sociales, proveedores de tecnolog<6F>a e infraestructura tecnol<6F>gica. El gobierno juega un papel importante en el proceso de transferencia tecnol<6F>gica ya que puede invertir en la infraestructura para impulsar una determinada tecnolog<6F>a o colocar restricciones para des-estimular su uso. Estas pol<6F>ticas son dependientes de la situaci<63>n econ<6F>mica del pa<70>s y del entendimiento de la importancia de la transferencia por parte de de sus dirigentes. La falta de facilidades en educaci<63>n y en capacitaci<63>n obstaculizan el proceso de transferencia, limitando el acceso. La falta de estas habilidades indica que los canales de transferencia no son eficientes porque la infraestructura del pa<70>s no lo permite. Las personas son las que finalmente absorben el know-how tecnol<6F>gico, si no existe el suficiente personal disponible y dispuesto, el proceso de transferencia se detendr<64>.
La administraci<63>n a nivel de organizaci<63>n juega el papel m<>s importante en el proceso de transferencia tecnol<6F>gica. La resistencia o el
desconocimiento a la tecnolog<6F>a, la adquisici<63>n de tecnolog<6F>a por motivos particulares no contemplan la implementaci<63>n y la capacitaci<63>n.
Por esta raz<61>n, es necesario que los encargados de tomar las decisiones y trazar pol<6F>ticas, conozcan la tecnolog<6F>a, o que est<73>n conscientes de
su importancia. La transferencia tecnol<6F>gica debe ser un proceso de dos v<>as, por lo que es indispensable tener habilidades adecuadas en
investigaci<EFBFBD>n, capacidades organizacionales y de ingenier<65>a para que estos conocimientos sean asimilados y utilizados en la soluci<63>n de
problemas locales. Es necesario que la adquisici<63>n de tecnolog<6F>a obedezca a un plan y que esta tecnolog<6F>a supla una necesidad real, de
lo contrario los equipos adquiridos y la capacitaci<63>n recibida no ser<65>n utilizados, por otro lado, la tecnolog<6F>a adquirida que no es
asimilada y transformada en herramienta para la soluci<63>n de problemas locales aumenta el grado de dependencia, lo que representa justamente
lo contrario a lo que se debe buscar en una actividad de transferencia tecnol<6F>gica.
Los procesos de transferencia tecnol<6F>gica son influenciados de forma directo o indirecta por las infraestructuras organizacionales y
tecnol<EFBFBD>gicas de los pa<70>ses, los cuales, deben exceder sus capacidades para absorber la tecnolog<6F>a transferida. Esta transferencia es efectiva solo
si la econom<6F>a en la cual es introducida es capaz de utilizarla. Si un pa<70>s cuenta con los recursos econ<6F>micos necesarios para adquirir la tecnolog<6F>a,
debe mejorar la infraestructura para soportarla, incluyendo la educaci<63>n y las facilidades de entrenamiento, as<61> como los enlaces de telecomunicaciones \cite{MO90}.
La falta de facilidades de educaci<63>n y capacitaci<63>n afecta la transferencia del knowhow, obstaculizando el desarrollo de habilidades a trav<61>s del proceso de aprendizaje. La carencia de estas facilidades limita la difusi<73>n del conocimiento; la p<>rdida de estas habilidades se pueden originar porque la transferencia no se realiz<69> o porque la infraestructura no lo permite.
Si no existen personas disponibles y dispuestas a absorber el knowhow el proceso de transferencia se detendr<64>. El proceso de transferencia
tecnol<EFBFBD>gico tambi<62>n es influenciado por la falta de pol<6F>ticas claras en la Tecnolog<6F>a de la Informaci<63>n, y los planes de negocios estrat<61>gicos,
los cuales pueden identificar las necesidades que traer<65>n beneficios a la naci<63>n o determinar lo que se puede lograr con los recursos disponibles.
Algunas pol<6F>ticas regulatorias sobre procesos de adquisici<63>n de hardware y software que existen en varios pa<70>ses obstaculizan los procesos de
transferencia de tecnolog<6F>a. Al hacer convenios con multinacionales para suministro de tecnolog<6F>a, a menudo estas multinacionales no est<73>n
interesadas en difundir el conocimiento necesario para reproducir sus productos y el soporte se limita a t<>picos relacionados con su manejo.
Ejemplos claros de esto se encuentran en el software propietario, los usuarios deben usar el programa como se les suministra y no tienen
acceso al c<>digo fuente, con lo que no pueden adquirir habilidades estudiando su estructura y no pueden hacer modificaciones para adaptarlo a
sus necesidades. Esto se traduce en una sub-utilizaci<63>n del producto y en el aumento de la dependencia del proveedor.
Las tecnolog<6F>as de la Informaci<63>n deben ser utilizadas como una facilidad en el proceso de educaci<63>n y capacitaci<63>n, es necesario tomar
conciencia de la importancia de la informaci<63>n a nivel organizacional y gubernamental.
La gran ausente en las pol<6F>ticas Tecnol<6F>gicas parece ser la sociedad. Nada permite suponer que el inter<65>s de los cultores del campo
se pretenda una democratizaci<63>n de la ciencia y la tecnolog<6F>a, una apropiaci<63>n de su din<69>mica y de sus resultados por parte de la sociedad
en su conjunto. Llama la atenci<63>n que, por una parte, no existan trabajos o programas que destaquen desde un punto de vista
cr<EFBFBD>tico los impactos tecnol<6F>gicos sobre la vida de la sociedad (calidad, tejido social, integraci<63>n social, distribuci<63>n de beneficios, etc.);
por otro lado, no se registran estudios o programas de formaci<63>n destinados a plantear la cuesti<74>n de la divulgaci<63>n cient<6E>fica y tecnol<6F>gica
como procesos de apropiaci<63>n simb<6D>lica por parte de los ciudadanos respecto de los contenidos de la ciencia y la tecnolog<6F>a.
\section{Recomendaciones Para una Transferencia Tecnol<6F>gica Exitosa}
Estudios consultados \cite{MO90} \cite{IAI} \cite{MDAG99} \cite{DZSC+07} \cite{MTRR07} \cite{Mar04}, coinciden en que para dar soluci<63>n a los problemas expuestos anteriormente se deben seguir las siguientes recomendaciones:
\subsection{Recomendaciones para los generadores de pol<6F>ticas}
\begin{itemize}
\item{Promover la Importancia de la Transferencia Tecnol<6F>gica como Motor de Desarrollo Econ<6F>mico}
\begin{itemize}
\item Proporcionar educaci<63>n en transferencia tecnol<6F>gica y comercializaci<63>n a las nuevas instituciones acad<61>micas.
\item Promover las asociaciones regionales de I+D.
\item Tomar conciencia que la innovaci<63>n involucra el desarrollo cient<6E>fico y tecnol<6F>gico a varios niveles, por diferentes medios y a trav<61>s de un amplio rango de instituciones acad<61>micas.
\item Promover las actividades de Transferencia tecnol<6F>gica que involucren transferencia de conocimiento que permita la creaci<63>n de nuevos productos y servicios. Del mismo modo, desalentar la compra de equipo y software propietario como pol<6F>tica para la transferencia tecnol<6F>gica.
\end{itemize}
\item{Fomentar la Generaci<63>n de Empresas Locales de Base Tecnol<6F>gica}
\begin{itemize}
\item Evaluar y abordar la transferencia de tecnolog<6F>a desde una perspectiva corporativa.
\item Revisi<73>n de la pol<6F>tica gubernamental de apoyo a las peque<75>as empresas.
\end{itemize}
\item{Promover el Mejoramiento de la Plataforma Tecnol<6F>gica}
\begin{itemize}
\item Desarrollar sistemas de medici<63>n para capturar de forma efectiva el valor de las actividades relacionadas con la innovaci<63>n.
\item Crear un centro de intercambio de informaci<63>n para transferencia tecnol<6F>gica y difundir la informaci<63>n de forma activa.
\end{itemize}
\end{itemize}
\subsection{Recomendaciones para la academia}
\begin{itemize}
\item{Actualizaci<63>n Curricular}
\begin{itemize}
\item Innovaci<63>n
\item Crear planes de transferencia de tecnolog<6F>a flexibles
\item hacer compromisos con el desarrollo econ<6F>mico.
\item Necesidad de mejorar las competencias y habilidades generales de los ingenieros, (continuo aprendizaje) habilidad para innovar, investigar, desarrollar nueva tecnolog<6F>a.
\item Innovaci<63>n curricular, actualizaci<63>n continua de profesionales.
\item Incentivar la formaci<63>n de maestr<74>as y doctorados nacionales acorde con una agenda de investigaci<63>n.
\end{itemize}
\item{Alianza con la industria}
\begin{itemize}
\item La Universidad debe desarrollar las habilidades y competencias que la empresa requiere.
\item Buscar alianzas industriales para lograr beneficios a largo-plazo.
\item Vinculaci<63>n de miembros de la industria a centros de investigaci<63>n para formar relaciones formales e informales.
\item Buscar tener fortalezas en <20>reas dominadas por las industrias locales
\item Promover y soportar la Transferencia de Tecnolog<6F>a
\item Fortalecer el esp<73>ritu empresarial para apoyar la comercializaci<63>n
\item Montar laboratorios de pruebas e incentivar a los productores nacionales para que logren una calidad que cumpla con los est<73>ndares internacionales.
\end{itemize}
\item{Promover y Soportar la Transferencia Tecnol<6F>gica}
\begin{itemize}
\item Elevar la transferencia tecnol<6F>gica a un nivel superior y promover la excelencia.
\item Concientizar a los creadores de pol<6F>ticas gubernamentales sobre la importancia de la transferencia tecnol<6F>gica y las alianzas con la investigaci<63>n industrial.
\item Interacci<63>n entre Universidades, Conviene que buena parte de los trabajos realizados en doctorado sean de investigaci<63>n aplicada, orientadas a mejorar la productividad del sector empresarial
\item Infraestructura institucional que impulse la actualizaci<63>n tecnol<6F>gica en el sector mediante desarrollo de proyectos de tecnolog<6F>a de punta con una posible transferencia de tecnolog<6F>a.
\end{itemize}
\item{B<>squeda de Financiaci<63>n para Investigaci<63>n y Desarrollo}
\begin{itemize}
\item Buscar de forma agresiva fondos para la investigaci<63>n.
\item Crear recursos empresariales en las instituciones acad<61>micas, y enlazarlos con actividades de transferencia tecnol<6F>gica.
\item Aumentar las alianzas con fuentes de inversi<73>n de capital para nuevas empresas.
\item Creaci<63>n de empresas como parte del proceso de transferencia tecnol<6F>gica de la instituci<63>n y de los compromisos con el desarrollo econ<6F>mico
\item Realizar seminarios y l<>neas de profundizaci<63>n de temas afines a la administraci<63>n y la gerencia en empresas de base tecnol<6F>gica.
\end{itemize}
\end{itemize}
\subsection{Recomendaciones para el Gobierno}
\begin{itemize}
\item{Promover la Relaci<63>n Universidad-Empresa}
\begin{itemize}
\item Fomento a centros de investigaci<63>n y productividad para fortalecer la relaciones universidad empresa.
\item Fomentar la colaboraci<63>n Universidad-Empresa en I+D, mediante la financiaci<63>n de becas de cooperaci<63>n, centros de investigaci<63>n e incentivos fiscales.
\item Crear estrategias para mejorar la relaci<63>n Universidad - empresa, creando premios para casos exitosos de transferencia tecnol<6F>gica.
\item Educar a las instituciones acad<61>micas sobre los recursos empresariales locales.
\item Trabajar con corporaciones y fundaciones para el fomento de patrocinios y participaci<63>n en transferencia de tecnolog<6F>a, I+D y desarrollo empresarial.
\item Desarrollar o mejorar infraestructuras regionales para capturar y retener empresas creadas en las instituciones acad<61>micas.
\end{itemize}
\item{Formular pol<6F>ticas Para Incentivar Actividades de Transferencia Tecnol<6F>gica}
\begin{itemize}
\item Fomentar en l<>deres universitarios el compromiso con el desarrollo econ<6F>mico.
\item Definir agendas de investigaci<63>n acordes con las tendencias mundiales y desarrollar capacidades en el pa<70>s.
\item Fomentar cooperaci<63>n internacional e inversi<73>n extranjera con transferencia de tecnolog<6F>a. a nivel gubernamental, Apoyo del gobierno a personas que tienen un alto potencial de crear y desarrollar tecnolog<6F>a.
\item Mejorar la plataforma Tecnol<6F>gica.
\end{itemize}
\item{Promover la Excelencia Acad<61>mica y la Investigaci<63>n}
\begin{itemize}
\item Promoci<63>n de las instituciones acad<61>micas como bienes econ<6F>micos
\item Trabajar con las instituciones acad<61>micas para identificar sus competencias.
\item Proporcionar fondos para temas espec<65>ficos de investigaci<63>n en instituciones acad<61>micas.
\item Promover la Investigaci<63>n y Desarrollo y la transferencia tecnol<6F>gica
\item Promover la investigaci<63>n, la colaboraci<63>n, la transferencia tecnol<6F>gica y el desarrollo empresarial.
\item Ayudar a las instituciones acad<61>micas a evaluar su impacto sobre las econom<6F>as locales y difundir los resultados a las instituciones gubernamentales.
\end{itemize}
\end{itemize}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%% CONCLUSIONES %%%%%%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\section{Actividades Prioritarias Para Obtener Una Transferencia de Tecnolog<6F>a Exitosa}
Las Anteriores recomendaciones coinciden en que para que se presente una Transferencia Tecnol<6F>gica exitosa, es decir, para que los elementos t<>cnicos, habilidades humanas, la documentaci<63>n y la organizaci<63>n asociadas a una determinada tecnolog<6F>a, puedan ser asimilados por personal calificado (disponible y dispuesto) para posteriormente transformar estos conocimientos en la creaci<63>n de nuevos productos o servicios que suplan necesidades locales es necesario:
\textbf{Fomentar la Creaci<63>n de Empresas de Base Tecnol<6F>gica} El gobierno debe crear facilidades y cr<63>ditos para que empresas tecnol<6F>gicas con la capacidad de innovaci<63>n puedan realizar su actividad comercial (productos o servicios) y de esta forma crear nuevos empleos, aumentar la demanda de servicios tecnol<6F>gicos. As<41> mismo, las universidades deben crear empresas que comercialicen productos derivados de sus actividades de Investigaci<63>n.
\textbf{Promoci<63>n de la Transferencia Tecnol<6F>gica} El gobierno y las Universidades deben centrar sus esfuerzos en identificar las necesidades de las empresas locales y cambiar sus prioridades para solucionarlas, las universidades deben realizar proyectos de aplicaci<63>n que puedan ser utilizados por el sector productivo a corto o mediano plazo. Las pol<6F>ticas de gobierno deben desalentar la compra de equipo que solo transfiera conocimiento sobre su operaci<63>n y no permita la creaci<63>n de nuevos conocimientos a partir de ellos, asi mismo, debe formular pol<6F>ticas que protejan las empresas locales de base tecnol<6F>gica impidiendo el ingreso de productos similares provenientes del mercado asi<73>tico premiando a las empresas locales que realicen productos innovadores ya sea con beneficios tributarios temporales o con la adjudiaci<63>n de cr<63>ditos condonables destinados al desarrollo de nuevos productos. Universidad, Gobierno e Industria deben trazar pol<6F>ticas que definan las <20>reas en las que se deben formar los profesionales en el exterior, las cuales deben estar en sinton<6F>a con el estado de la plataforma tecnol<6F>gica y el sector productivo, estas pol<6F>ticas deben cambiar a medida que se mejora la plataforma tecnol<6F>gica local y se presentan cambios en el entorno mundial. Se debe trabajar en la creaci<63>n de una cultura de la Transferencia Tecnol<6F>gica, resaltando su importancia para el desarrollo del pa<70>s.
\textbf{Promover la Excelencia Acad<61>mica} Debe exisitir una evaluaci<63>n continua de los planes acad<61>micos para que se adapten a las necesidades del sistema productivo local, proporcionando a sus profesionales las habilidades requeridas por la industria, en especial las requeridas para crear l<>deres emprendedores que puedan crear nuevas empresas y que sean conscientes de la importancia del aprendizaje continuo. Por otro lado, es necesaria la creaci<63>n de maestr<74>as y doctorados que sigan pol<6F>ticas nacionales encaminadas al desarrollo econ<6F>mico y crear mecanismos de medici<63>n que permitan comparar y clasificar las instituciones acad<61>micas seg<65>n las competencias de las habilidades (liderazgo y emprendimiento) de sus egresados y de esta forma determinar que instituciones son merecedoras de cr<63>ditos, becas, o financiaci<63>n para desarrollar actividades.
Los centro de educaci<63>n de diferentes niveles deben trabajar de forma conjunta para definir los objetivos y habilidades que requiere el sector productivo a nivel de formaci<63>n tecnol<6F>gica y profesional. Esto con el fin de delimitar sus funciones para que no interfieran en el mercado laboral. En la actualidad estos limites no est<73>n definidos, esto debido a la falta de producci<63>n tecnol<6F>gica del pais, somos un pa<70>s consumidor de tecnolog<6F>a y productos manufacturaodos, y las funciones de compra de productos pueden ser realizadas por t<>cnicos e ingenieros, adicionalmente la venta de estos productos tambien puede ser realizada por cualquier persona, raz<61>n por la cual lo ingenieros tienen problemas a la hora de conseguir empleo. Esta situaci<63>n se vuelve cr<63>tica debido a la gran cantidad de programas de Ingenier<65>a que se crearon en Colombia, solo en la Universidad Nacional de Colombia se grad<61>an cerca de 60 ingenieros electr<74>nicos al a<>o.
"Para hacer esto posible se requiere una comisi<73>n de regulaci<63>n de la educaci<63>n superior que vele, especialmente, por la calidad de los diferentes programas. <20>sta debe ser una comisi<73>n independiente y mixta con la participaci<63>n del sector privado. Por otra parte, es menester tener en cuenta que el programa planteado requerir<69> un incremento sustancial de inversi<73>n en la oferta docente, tecnol<6F>gica y de investigaci<63>n'" \footnote{Publicado en el Espectador: 16 de julio 1999 `\textit{Urge elevar la competitividad} Santiago Montenegro}
\textbf{Promover la Relaci<63>n Universidad Empresa} El sector productivo debe ser el principal inversionista para las actividades de Transferenica Tecnol<6F>gica e Investigaci<63>n y Desarrollo, ya que es el directamente beneficiado con ellas. El gobierno debe desalentar las pr<70>cticas comerciales que no generan actividades de I+D, en especial las que solo comercializan productos manufacturados en pa<70>ses asi<73>ticos ya que esto hace que la empresas no vean la necesidad de crear productos propios y por lo tanto no es necesario hacer inversi<73>n en Investigaci<63>n y Desarrollo. La academia debe proporcionar a la industria herramientas que le permitan competir con productos provenientes del mercado asi<73>tico, es una realidad que a corto plazo no podemos competir con la industra manufacturera asi<73>tica, pero si podemos utilizarla para producir productos dise<73>ados en el pa<70>s, por Colombianos, para satisfacer necesidades locales. Se debe crear consciencia en la industria de las ventajas de tener productos dise<73>ados localmente, resaltando los servicios adicionales que pieden generarse al personalisar estos productos y proporcionar servicios derivados de su uso. Adicionalmente, se deben crear espacios donde los empresarios participen en los procesos de toma de decisiones y creaci<63>n de pol<6F>ticas gubernamentales sobre educaci<63>n e Investigaci<63>n y Desarrollo, para esto es vital determinar que acividades econ<6F>micas contribuyen al desarrollo tecnol<6F>gico, cuales son generadoras de conocimientos y de esta forma incentivar su pr<70>ctica. Por otra parte, las Universidades deben continuar con sus labores de investigaci<63>n en temas de actualidad y aumentar la visibilidad de la academia colombiana en el entorno cent<6E>fico mundia, sin embargo, muchos de estos trabajo no se pueden aplicar a corto, mediano y algunos ni a muy largo plazo en Colombia debido al estado de la plataforma tecnol<6F>gica actual. Los centros acad<61>micos deben trabajar en problemas del entorno local, que aunque no tienen reconocimiento a nivel internacional si refleja un grado de compromiso con el entorno social en donde ellas operan.
\textbf{Alianzas Para Obtener y Compartir Recursos}
Como se mencion<6F> anteriormente Colombia es el pa<70>s de Sur-Am<41>rica que menos invierte en Investigaci<63>n y Desarrollo, por esta raz<61>n es necesario crear alianzas estrat<61>gicas para compartir los escasos recursos disponibles, en la actualidad no existe una red nacional de Universidades que trabajen conjuntamente en temas tecnol<6F>gicos, por eso vemos que muchas investigaciones se repiten y se compran costosos equipos que en muchos casos se sub-utilizan. En la actualidad el Servicio Nacional de Aprendizaje SENA posee una gran cantidad de recursos econ<6F>micos, de infraestructura y de equipos, adicionalmente tiene una muy buena relaci<63>n con peque<75>as empresas y conoce las necesidades de este sector, la funci<63>n del SENA es proporcionar formaci<63>n a nivel t<>cnico que soporte las actividades de las empresas Colombianas, sin embargo, los centros de educaci<63>n superior no utilizan esta coyuntura para acercarse a la empresa y de esta forma obtener recursos necesarios para sus actividades en investigaci<63>n.
\section{Actividades}
En la Figura \ref{thesis_flow} se hace un res<65>men de las recomendaciones formuladas anteriormente para lograr una transferencia tecnol<6F>gica exitosa y como estas est<73>n relacionadas con actividades requeridas para el mejoramiento de la plataforma tecnol<6F>gica y la creaci<63>n de una cultura de transferencia de tecnolog<6F>a en el <20>rea de Sistemas Embebidos. <20>rea en la que (como veremos m<>s adelante) el pa<70>s puede competir a corto plazo con productos provenientes de paises industrializados. Adicionalmente, los sistemas embebidos cubren un amplio campo de aplicaciones comerciales y requieren de conocimientos y habilidades especiales. Estas habilidades deben ser desarrolladas por los centros de formaci<63>n teniendo en mente la situaci<63>n actual del pa<70>s y la situaci<63>n a la que se quiere llegar.
\begin{sidewaysfigure}[ht]
\begin{center} \includegraphics[scale=.6]{./images/thesis_flow_diagram.png} \end{center}
\caption{esum<75>n de las Actividades Realizadas Para Encontrar una Metodolog<6F>a para la Transferencia Tecnol<6F>gica en Sistemas Embebidos} \label{thesis_flow}
\end{sidewaysfigure}
Todas las actividades desarrolladas buscan la creaci<63>n de conocimiento alrededor del tema de Transferencia Tecnol<6F>gica en el <20>rea de Sistemas Embebidos (SE), se parte del concepto \textit{El Conocimiento como Bien Com<6F>n} \cite{Ost00} \cite{EO92} \cite{EO90} \cite{AC09}, y por lo tanto, se deben crear mecanismos que permitan su distribuci<63>n, organizaci<63>n, mejoramiento y actualizaci<63>n. Este trabajo representa la semilla de este recurso y es el fruto del trabajo de 5 a<>os de estudio de metodolog<6F>as de dise<73>o, fabricaci<63>n y producci<63>n, experimentaci<63>n, establecimiento de relaciones de todo tipo para entender la din<69>mica de la industria Colombiana y mundial. Todo esto para identificar las habilidades con las que debe contar un profesional para que lidere proyectos innovadores y emprendedores que permitan la creaci<63>n de empresas locales y de esta forma generar empleo y mejorar las condiciones de vida de la comunidad asociada a la Universidad Nacional de Colombia. Y adicionalmente, detectar las necesidades de la industria Colombiana y generar actividades para la transferencia de estos conocimientos. Las actividades se dividieron en los siguientes cuatro grupos:
\begin{itemize}
\item \textbf{Creaci<63>n de Habilidades Necesarias Para una Transferenica Tecnol<6F>gica Exitosa}: Aplicaci<63>n del plan de estudios \textit{CDIO} \cite{WCI} a las asignaturas del <20>rea de Electr<74>nica Digital, utilizando las habilidades que requiere la industra electr<74>nica nacional. Para poder generar estas habilidades se requiere de una serie de conocimientos con los que no se contaba hasta el momento en la Concepci<63>n, Dise<73>o e Implementaci<63>n de Sistemas Embebidos, por lo que se realiz<69> un estudio sobre metodolog<6F>as de dise<73>o, implementaci<63>n y producci<63>n de sistemas digitales. El conocimiento y la experiencia adquirida se esta documentando en un servidor p<>blio y hace parte del proyecto QI-Hardware \cite{QH}, esta informaci<63>n le permitir<69> a cualquier personal entender, usar y modificar la gran variedad de plataformas de referencia ya sea para adquirir o mejorar habilidades en la Concepci<63>n, Dise<73>o e Implementaci<63>n de SE o para crear nuevos dispositivos que satisfagan una determinada necesidad. En el cap<61>tulo \ref{ch:embedded} se realizar<61> una descripci<63>n de las actividades realizadas y las plataformas dise<73>adas durante este estudio. En el cap<61>tulo \ref{ch:education} se hace una descripci<63>n del proceso que se llev<65> a cabo para la aplicaci<63>n del plan de estudios \textit{CDIO} a las asignaturas del <20>rea de Electr<74>nica Digital.
\item \textbf{Creaci<63>n de Empresas de Base Tecnol<6F>gica}: La principal fuente de informaci<63>n sobre la din<69>mica de la industria electr<74>nica Colombiana y el estado de la industria Electr<74>nica mundial (la que se utiliz<69> para determinar las necesidades de las empresas locales, y las habilidades que los prefesionales en el <20>rea deben poseer para suplirlas) fu<66> la empresa Colombiana emQbit, esta empresa fue creada por un grupo de egresados de la Universidad Nacional de Colombia, los cuales con la asesor<6F>a del autor de este trabajo de investigaci<63>n incursionaron en la concepci<63>n, dise<73>o e Implementaci<63>n de Sistemas Digitales, concirti<74>ndose en la primera y <20>nica empresa en Colombia que realiza el proceso completo del proceso de dise<73>o de SE \cite{CC06}.\cite{emQ}. En el cap<61>tulo \ref{ch:embedded} se enumerar<61>n las actividades realizadas con esta empresa.
\item \textbf{Hardware Copyleft}: El movimiento de Software Libre y de C<>digo Abierto (FOSS) es hoy en d<>a la estructura auto-gobernada m<>s exitosa, millones de personas alrededor del mundo trabajan de forma conjunta y distribuida en busca de un bien com<6F>n: Generaci<63>n y distribuci<63>n de herramientas software, sistema operativo y todo tipo de aplicaciones incluyendo el c<>digo fuente bajo una licencia que permite su distribuci<63>n y modificaci<63>n. Este movimiento busca romper los grandes monopolios en la industria del Software, donde el usuario final no puede participar en el proceso de creaci<63>n del mismo y debe pagar por aplicaciones que no se ajustan a sus necesidades, que presentan errores en su funcionamiento, acaptar todos estos problemas y pagar por actualizaciones. Adicionalmente, buscan difundir los conocimientos que un determinado programador adquiri<72> para el desarrollo de una aplicaci<63>n permitiendo el estudio del c<>digo fuente, creando listas de discusi<73>n donde se resuelven todo tipo de dudas y se planifica de forma conjunta el desarrollo de estas aplicaciones, desarrollando tutoriales y libros disponibles en l<>nea.
Este movimiento ha creado toda una serie de herramientas que compiten con las suministradas por multinacionales como Microsoft y Apple, dentro de las m<>s destacables se encuentran: La \textit{cadena de herramientas de compilaci<63>n GNU}, librer<65>as, el sistema operativo \textit{Linux}, aplicaciones como el servidor web \textit{Apache}, el explorador \textit{Mozilla}, la suite ofim<69>tica \textit{OpenOffice} y distribuciones como \textit{Debian}, \textit{Ubuntu}, \textit{Suse}, \textit{Redhat}. Gracias a esto es, se dispone de una cantidad enorme de aplicaciones en diversos campos que pueden ser utilizadas para adquirir conocimientos y desarrollar aplicaciones en diferentes <20>reas.
El resultado m<>s notable, es la creaci<63>n de un recurso de bien com<6F>n: el conocimiento contenido en las herramientas y aplicaciones, la infra-estructura f<>sica y tecnol<6F>gica para su distribuci<63>n y difusi<73>n, y una comunidad que se encarga de contribuir, mejorar y administrar este recurso. Este recurso est<73> basado en principios de libertad y de confianza, esto es, cualquier persona puede ser parte de la comunidad y participar en los procesos de toma de decisiones y creaci<63>n de normas, y deben conocer de antemano las reglas de interacci<63>n entre los miembros y como sus acciones afectan a los otros miembros y al recurso. En el cap<61>tulo \ref{ch:common} estudiaremos con m<>s detalle este movimiento.
Este trabajo contribuye con la creaci<63>n de un movimiento inspirado en el movimiento FOSS, pero dirigido al desarrollo de aplicaciones Hardware, esto es, Circuitos Integrados, Placas de Circuito Impreso, Dispositivos comercializables, programaci<63>n y generaci<63>n de bienes y servicios asociados a estos productos. En la actualidad existen varios proyectos que proporcionan los archivos de dise<73>o para reproducir el componente hardware, sin embargo, no existe un consenso sobre las caracter<65>sticas que se deben cumplir para que sea considerado \textit{copyleft}, esta es una de los t<>picos que se abordar<61>n en el cap<61>tulo \ref{ch:common}
\end{itemize}

View File

@@ -0,0 +1,79 @@
\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{KAK01}
\citation{WM91}
\@writefile{toc}{\contentsline {chapter}{\numberline {1}Introduci\'on}{3}}
\@writefile{lof}{\addvspace {10\p@ }}
\@writefile{lot}{\addvspace {10\p@ }}
\@writefile{toc}{\contentsline {section}{\numberline {1.1}Visi\'on, Paradigmas, y Dificultades}{3}}
\@writefile{toc}{\contentsline {subsection}{\numberline {1.1.1}Futuro de los Sistemas Computacionales}{3}}
\citation{Oxygen}
\@writefile{toc}{\contentsline {subsubsection}{Computador Ubicuo}{4}}
\@writefile{lof}{\contentsline {figure}{\numberline {1.1}{\ignorespaces Concepto de Computador Ubiquo.}}{4}}
\citation{WM91}
\citation{DS02}
\citation{MW93}
\citation{DS02}
\citation{DS02}
\citation{EA01}
\citation{WM91}
\citation{NRC01}
\citation{APaET03}
\@writefile{toc}{\contentsline {subsubsection}{Ambientes Inteligentes.}{5}}
\citation{DS02}
\@writefile{toc}{\contentsline {subsubsection}{Consecuencias de la aparici\'on de los sistemas de computaci\'on ubicua.}{6}}
\citation{Mok90}
\citation{Arr62}
\citation{Mar04}
\@writefile{toc}{\contentsline {section}{\numberline {1.2}Estado del Dise\~no Electr\'onico en Colombia}{7}}
\@writefile{toc}{\contentsline {subsection}{\numberline {1.2.1}Apropiaci\'on de Conocimiento}{7}}
\citation{Mar04}
\citation{Tee81}
\citation{FW00}
\citation{Mar04}
\citation{ETPoSSI(09}
\citation{Vc08}
\@writefile{toc}{\contentsline {subsection}{\numberline {1.2.2}Situaci\'on de la Industria Electr\'onica en Colombia}{8}}
\citation{MTRR07}
\citation{DZSC+07}
\citation{MDAG99}
\citation{HSL+04}
\citation{MJF05}
\@writefile{toc}{\contentsline {subsubsection}{Tecnolog\IeC {\'\i }as de Informaci\'on y Comunicaci\'on}{10}}
\@writefile{toc}{\contentsline {subsection}{\numberline {1.2.3}Estado de la Electr\'onica Digital en la Universidad Nacional de Colombia}{12}}
\@writefile{toc}{\contentsline {section}{\numberline {1.3}Descripci\'on de la T\'esis}{13}}
\@writefile{toc}{\contentsline {subsection}{\numberline {1.3.1}Objetivos e Hip\'otesis}{13}}
\@writefile{toc}{\contentsline {subsubsection}{Ojetivo Principal}{13}}
\@writefile{toc}{\contentsline {subsubsection}{Objetivos Secundarios}{13}}
\@writefile{toc}{\contentsline {subsubsection}{Hip\'otesis}{13}}
\@writefile{toc}{\contentsline {subsection}{\numberline {1.3.2}Aproximaciones}{14}}
\bibdata{biblio}
\bibcite{UNE}{1}
\bibcite{KAK01}{2}
\bibcite{WM91}{3}
\bibcite{Oxygen}{4}
\bibcite{DS02}{5}
\bibcite{MW93}{6}
\bibcite{EA01}{7}
\bibcite{NRC01}{8}
\bibcite{APaET03}{9}
\bibcite{Mok90}{10}
\bibcite{Arr62}{11}
\bibcite{Mar04}{12}
\bibcite{Tee81}{13}
\bibcite{FW00}{14}
\bibcite{ETPoSSI(09}{15}
\bibcite{Vc08}{16}
\bibcite{MTRR07}{17}
\bibcite{DZSC+07}{18}
\bibcite{MDAG99}{19}
\bibcite{HSL+04}{20}
\bibcite{MJF05}{21}

View File

@@ -0,0 +1,126 @@
\begin{thebibliography}{10}
\bibitem{UNE}
UNESCO-Uruguay.
\newblock Rasgos {P}rincipales de la {I}nstitucionalizaci\'on de la {C}iencia,
la {T}ecnolog\'{\i}a y la {I}nnovaci\'on en {A}m\'erica {L}atina y el
{C}aribe y {T}endencias de la {C}ooperaci\'on {I}nternacional.
\newblock {\em http://www.unesco.org.uy/}.
\bibitem{KAK01}
{K. A. Kahng}.
\newblock Design {T}echnology {P}roductivity in the {DSM} {E}ra.
\newblock In {\em A{SP}-{DAC}}, 2001.
\bibitem{WM91}
{Mark Weiser}.
\newblock The {C}omputer for the 21st {C}entury.
\newblock {\em http://www.ubiq.com/hy\'ertext/weiser/SciAmDraft3.html}.
\bibitem{Oxygen}
MIT.
\newblock Proyecto {O}x\'{\i}geno.
\newblock http://oxygen.lcs.mit.edu/.
\bibitem{DS02}
{D. Servant}.
\newblock Combining amorphous computing and reactive agent-based systems: a
paradigm for pervasive intelligence?
\newblock In {\em First international joint conference on {A}utonomous agents
and muktiagent systems: part 1}, 2002.
\bibitem{MW93}
{M. Weiser}.
\newblock Some computer science issues in ubiquitous computing.
\newblock {\em Commun. ACM}, 1993.
\bibitem{EA01}
{E. Arts}, {R. Harwing}, and {M. Schuurmans}.
\newblock {\em Ambient {I}ntelligence}, pages 235--250.
\newblock McGraw-Hill, 2001.
\bibitem{NRC01}
{National Research Council}.
\newblock {\em Embedded {E}verywhere}.
\newblock National Academic Press, 2001.
\bibitem{APaET03}
{A. Purhonen and E. Tuulari}.
\newblock {\em Ambient {I}ntelligence and the {D}evelopment of {E}mbedded
{S}ystem {S}oftware}, pages 51 -- 66.
\newblock Kluwer Academic Publishers, 2003.
\bibitem{Mok90}
Joel Mokyr.
\newblock {\em The {L}ever of {R}iches, {T}echnological {C}reativity and
{E}conomic {P}rogress.}
\newblock Oxford University Press, 1990.
\bibitem{Arr62}
Kenneth Arrow.
\newblock {\em Economic {W}elfare and the {A}llocation of {R}esources for
{I}nvention}.
\newblock Princeton University Press, 1962.
\bibitem{Mar04}
H\'ector Mart\'{\i}nez.
\newblock Apropiaci\'on de conocimiento en {C}olombia. {E}l caso de los
contratos de importaci\'on de tecnolog\'{\i}a.
\newblock {\em Revista Cuadernos de Econom\'{\i}a}, 2004.
\bibitem{Tee81}
D~Teece.
\newblock The {M}arket for {K}now-how. {T}echnology {T}ransfer: {N}ew {I}ssues,
{N}ew {A}nalysis.
\newblock {\em Special issue of the Annals of the American Academy of Political
and Social Science}, 1981.
\bibitem{FW00}
Naushad Forbes and David Wield.
\newblock Managing {R}\&{D} in technology-followers.
\newblock {\em Research Policy}, September 2000.
\bibitem{ETPoSSI(09}
{European Technology Platform on Smart Sistem Integration (EPoSS)}.
\newblock European {T}echnology {P}latform on {S}mart {S}ystems {I}ntegration.
{S}trategic {R}esearch {A}genda 2009.
\newblock 2009.
\bibitem{Vc08}
{VDC corp.}
\newblock Embedded {S}oftware 2008 {M}arket {I}ntelligence {S}ystem.
\newblock Technical report, VDC Research Group, 2008.
\bibitem{MTRR07}
{M. Tovar} and {R. Rodr\'{\i}guez}.
\newblock P{ROSPECTIVA} {Y} {VIGILANCIA} {TECNOL}\'{O}{GICA} {DE} {LA}
{ELECTR}\'{O}{NICA} {EN} {COLOMBIA}.
\newblock Master's thesis, Universidad Nacional de Colombia, 2007.
\bibitem{DZSC+07}
{D Zuluaga}, {S Campos}, {M Tovar}, {R Rodr\'{\i}guez}, {J S\'anchez}, {A
Aguilera}, {L Land\'{\i}nez}, and {J Medina}.
\newblock Informe de {V}igilancia {T}ecnol\'ogica: {A}plicaciones de la
{E}lectr\'onica en el {S}ector {A}gr\'{\i}cola.
\newblock Technical report, COLCIENCIAS, 2007.
\bibitem{MDAG99}
{M. Duque} and {A. Gauthier}.
\newblock Formaci\'on de {I}negnieros para la {I}nnovaci\'on y el {D}esarrollo
{T}ecnol\'ogico en {C}olombia.
\newblock {\em Revista de la Facultad de Minas - Universidad Nacional de
Colombia}, December 1999.
\bibitem{HSL+04}
Gregory~N. Hearn, Lynette~E. Simpson, June Lennie, and Megan~P. Kimber.
\newblock I{CT}s and regional sustainability: {A} critique and a way forward.
\newblock {\em Community Informatics Research Network Conference and Colloquium
2004: Sustainability and community technology}, 2004.
\bibitem{MJF05}
{Mesa J. F.} and {Polo A. A.}
\newblock C{ONSTRUYENDO} {UN} {JINU} {DE} {LA} {INFORMACI}\'{O}{N}.
\newblock Master's thesis, PONTIFICIA UNIVERSIDAD JAVERIANA Facultad de
Ingenier\'{\i}a, February 2005.
\end{thebibliography}

View File

@@ -0,0 +1,51 @@
This is BibTeX, Version 0.99c (TeX Live 2009/Debian)
The top-level auxiliary file: thesis.aux
The style file: unsrt.bst
Database file #1: biblio.bib
Warning--empty year in UNE
Warning--empty year in WM91
Warning--can't use both author and editor fields in EA01
Warning--can't use both author and editor fields in APaET03
Warning--empty journal in ETPoSSI(09
You've used 21 entries,
1791 wiz_defined-function locations,
567 strings with 6808 characters,
and the built_in function-call counts, 3456 in all, are:
= -- 285
> -- 139
< -- 2
+ -- 58
- -- 37
* -- 131
:= -- 586
add.period$ -- 63
call.type$ -- 21
change.case$ -- 18
chr.to.int$ -- 0
cite$ -- 26
duplicate$ -- 195
empty$ -- 368
format.name$ -- 37
if$ -- 781
int.to.chr$ -- 0
int.to.str$ -- 21
missing$ -- 21
newline$ -- 108
num.names$ -- 21
pop$ -- 91
preamble$ -- 1
purify$ -- 0
quote$ -- 0
skip$ -- 83
stack$ -- 0
substring$ -- 56
swap$ -- 38
text.length$ -- 2
text.prefix$ -- 0
top$ -- 0
type$ -- 0
warning$ -- 5
while$ -- 25
width$ -- 23
write$ -- 214
(There were 5 warnings)

Binary file not shown.

View File

@@ -0,0 +1,209 @@
[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=commons.tex
masterDocument=
name=thesis
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:commons.tex]
Bookmarks=
Encoding=ISO-8859-3
Highlighting=LaTeX
Indentation Mode=
Mode=LaTeX
ReadWrite=true
[document-settings,item:education.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:intro.tex]
Bookmarks=
Encoding=ISO-8859-3
Highlighting=LaTeX
Indentation Mode=
Mode=LaTeX
ReadWrite=true
[document-settings,item:platform.tex]
Bookmarks=
Encoding=ISO-8859-3
Highlighting=LaTeX
Indentation Mode=
Mode=LaTeX
ReadWrite=true
[document-settings,item:review.tex]
Bookmarks=
Encoding=ISO-8859-3
Highlighting=LaTeX
Indentation Mode=
Mode=LaTeX
ReadWrite=true
[document-settings,item:thesis.tex]
Bookmarks=
Encoding=ISO-8859-1
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:commons.tex]
archive=true
column=45
encoding=ISO-8859-3
highlight=LaTeX
line=284
mode=LaTeX
open=true
order=0
[item:education.tex]
archive=true
column=95
encoding=ISO-8859-3
highlight=LaTeX
line=327
mode=LaTeX
open=false
order=4
[item:embedded.tex]
archive=true
column=59
encoding=ISO-8859-3
highlight=LaTeX
line=604
mode=LaTeX
open=false
order=3
[item:intro.tex]
archive=true
column=188
encoding=ISO-8859-3
highlight=LaTeX
line=459
mode=LaTeX
open=false
order=2
[item:platform.tex]
archive=true
column=0
encoding=ISO-8859-3
highlight=LaTeX
line=1
mode=LaTeX
open=true
order=2
[item:review.tex]
archive=true
column=415
encoding=ISO-8859-3
highlight=LaTeX
line=194
mode=LaTeX
open=false
order=2
[item:thesis.kilepr]
archive=true
column=1
encoding=
highlight=
line=0
mode=
open=false
order=-1
[item:thesis.tex]
archive=true
column=0
encoding=ISO-8859-1
highlight=LaTeX
line=17
mode=LaTeX
open=true
order=1
[item:title.tex]
archive=true
column=33
encoding=ISO-8859-3
highlight=LaTeX
line=22
mode=LaTeX
open=false
order=6
[view-settings,view=0,item:commons.tex]
CursorColumn=45
CursorLine=284
ViRegisterContents=,\n\n
ViRegisterNames=-,0
[view-settings,view=0,item:education.tex]
CursorColumn=95
CursorLine=327
[view-settings,view=0,item:embedded.tex]
CursorColumn=59
CursorLine=604
[view-settings,view=0,item:intro.tex]
CursorColumn=188
CursorLine=459
[view-settings,view=0,item:platform.tex]
CursorColumn=0
CursorLine=1
[view-settings,view=0,item:review.tex]
CursorColumn=415
CursorLine=194
[view-settings,view=0,item:thesis.tex]
CursorColumn=0
CursorLine=17
ViRegisterContents=,\n\n
ViRegisterNames=-,0
[view-settings,view=0,item:title.tex]
CursorColumn=33
CursorLine=22
ViRegisterContents=,\n\n
ViRegisterNames=-,0

View File

@@ -0,0 +1,73 @@
\documentclass{book}
\usepackage{fontenc}
\usepackage[latin1]{inputenc}
\usepackage[spanish]{babel}
\usepackage{tikz}
\usetikzlibrary{arrows,shapes,snakes,automata,backgrounds,petri}
\usepackage{times}
\usepackage{multicol}
\usepackage{array}
\usepackage{multirow}
\usepackage{pdfpages}
\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=\footnotesize}
%\lstset{framexleftmargin=5mm, frame=shadowbox, rulesepcolor=\color{black}, backgroundcolor=\color[gray]{.9}}
\lstset{backgroundcolor=\color[gray]{.8}}
\usepackage{float}
\usepackage{rotating}
\usepackage{subfigure}
\usepackage{pstricks}
\definecolor{code-color}{cmyk}{0, 0, 0, 0.1}
\usepackage{amsmath,amssymb,latexsym,array, bm, times}
\pagestyle{myheadings}
\markboth{Sistemas Embebidos}{Carlos Iv<49>n Camargo Bare<72>o}
\usepackage{longtable}
\parindent 1cm
\parskip 0.2cm
\topmargin 0.2cm
\oddsidemargin 1cm
\evensidemargin 0.5cm
\textwidth 15cm
\textheight 21cm
\begin{document}
\bibliographystyle{unsrt}
\tableofcontents
\parindent=1cm
% \input title
\input intro
% \input review
% \input embedded
% \input commons
% \input education
\bibliography{biblio}
\end{document}
Such evidence stares at us from the performance of several Asian countries in the past few decades. These countries seem to understand that job creation must be the No. 1 objective of state economic policy. The government plays a strategic role in setting the priorities and arraying the forces and organization necessary to achieve this goal. The rapid development of the Asian economies provides numerous illustrations. In a thorough study of the industrial development of East Asia, Robert Wade of the London School of Economics found that these economies turned in precedent-shattering economic performances over the '70s and '80s in large part because of the effective involvement of the government in targeting the growth of manufacturing industries.

View File

@@ -0,0 +1,18 @@
\select@language {spanish}
\contentsline {chapter}{\numberline {1}Introduci\'on}{3}
\contentsline {section}{\numberline {1.1}Visi\'on, Paradigmas, y Dificultades}{3}
\contentsline {subsection}{\numberline {1.1.1}Futuro de los Sistemas Computacionales}{3}
\contentsline {subsubsection}{Computador Ubicuo}{4}
\contentsline {subsubsection}{Ambientes Inteligentes.}{5}
\contentsline {subsubsection}{Consecuencias de la aparici\'on de los sistemas de computaci\'on ubicua.}{6}
\contentsline {section}{\numberline {1.2}Estado del Dise\~no Electr\'onico en Colombia}{7}
\contentsline {subsection}{\numberline {1.2.1}Apropiaci\'on de Conocimiento}{7}
\contentsline {subsection}{\numberline {1.2.2}Situaci\'on de la Industria Electr\'onica en Colombia}{8}
\contentsline {subsubsection}{Tecnolog\IeC {\'\i }as de Informaci\'on y Comunicaci\'on}{10}
\contentsline {subsection}{\numberline {1.2.3}Estado de la Electr\'onica Digital en la Universidad Nacional de Colombia}{12}
\contentsline {section}{\numberline {1.3}Descripci\'on de la T\'esis}{13}
\contentsline {subsection}{\numberline {1.3.1}Objetivos e Hip\'otesis}{13}
\contentsline {subsubsection}{Ojetivo Principal}{13}
\contentsline {subsubsection}{Objetivos Secundarios}{13}
\contentsline {subsubsection}{Hip\'otesis}{13}
\contentsline {subsection}{\numberline {1.3.2}Aproximaciones}{14}

View File

@@ -0,0 +1,40 @@
% Title Page
\title{METODOLOG<EFBFBD>A PARA LA TRANSFERENCIA TECNOL<4F>GICA Y DE CONOCIMIENTOS EN EL <20>REA DE SISTEMAS EMBEBIDOS\\
\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
T<EFBFBD>cnicas de Auto-Organizaci<63>n de Sistemas Paralelos Inspiradas en la Naturaleza\\
\textsc{Author:} C.~Camargo\\
\textsc{e-mail:} cicamargoba@unal.edu.co\\
\vfill
Copyright \copyright 2009\ 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}

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.

View File

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

View File

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

View File

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

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
}

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
}

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.

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.

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.

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

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}

File diff suppressed because it is too large Load Diff

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

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.

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}

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}

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

Binary file not shown.

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)

Binary file not shown.

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}

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}

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}

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.

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.

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.

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}

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}

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)

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)

Binary file not shown.

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}

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}

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}

Binary file not shown.

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;
}

Binary file not shown.

Binary file not shown.

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}

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}

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}

View File

@@ -1,4 +1,4 @@
DIRS = lua_blink_led lua_calls_C1 lua_calls_C2 lua_calls_C3 lua_calls_C4 lua_calls_C5
DIRS = lua_blink_led lua_calls_C1 lua_calls_C2 lua_calls_C3 lua_calls_C5
all:
for n in $(DIRS); do $(MAKE) -C $$n || exit 1; done

View File

@@ -19,7 +19,6 @@ $(TARGET): $(COMMON_OBJECTS)
.c.o:
$(CC) -c $(CCFLAGS) $< -o $@
upload: $(TARGET)
scp $(TARGET).so test_gpio.lua $(NANO_PATH)

Binary file not shown.

View File

@@ -7,13 +7,17 @@ CCFLAGS = ${INCLUDE} ${DEBUG} ${WARNINGS} -std=c99 -fPIC
LDFLAGS = -L$(OPENWRT_BUILD_DIR)/usr/lib -llua -ldl
DEBUG = -O3 -g0
NANO_PATH = root@192.168.254.101:
TARGET = mylib
TARGET = wrap
$(TARGET):
$(CC) $(CCFLAGS) $(LDFLAGS) -shared liba.c liba_wrapper.c -o $(TARGET).so
COMMON_SOURCES = liba.c liba_wrapper.c
COMMON_OBJECTS = $(COMMON_SOURCES:.c=.o)
$(TARGET): $(COMMON_OBJECTS)
$(CC) $(CCFLAGS) $(LDFLAGS) -shared $(COMMON_OBJECTS) -o $(TARGET).so
.c.o:
$(CC) -c $(CCFLAGS) -o $@
$(CC) -c $(CCFLAGS) $< -o $@
upload: $(TARGET)
scp $(TARGET).so test.lua $(NANO_PATH)

View File

@@ -113,7 +113,7 @@ static const struct luaL_reg functions[] = {
//This is the init function that will be called when you require 'mylib'
int luaopen_mylib(lua_State *L) {
int luaopen_wrap(lua_State *L) {
luaL_newmetatable(L, metaname);
@@ -126,6 +126,6 @@ int luaopen_mylib(lua_State *L) {
luaL_newmetatable(L,metaname);
return 1;
}
luaL_register(L, "mylib", functions);
luaL_register(L, "wrap", functions);
return 1;
}

View File

@@ -1,16 +1,16 @@
package.cpath = "./?.so"
require "mylib"
require "wrap"
--test1
mylib.lib_a_f_1()
wrap.lib_a_f_1()
--test2
assert(6==mylib.lib_a_f_2(2,3))
assert(6==wrap.lib_a_f_2(2,3))
--test3
assert(5==mylib.lib_a_f_3("hello"))
assert(5==wrap.lib_a_f_3("hello"))
--test4 : use userdata to pass structure
t=mylib.point_new(3,6)
t=wrap.point_new(3,6)
assert(18 == mylib.lib_a_f_4(t))
--test5, return userdata
t=mylib.lib_a_f_5()
assert(600 == mylib.lib_a_f_4(t))
assert(mylib.point_geta(t) == 20)
assert(mylib.point_getb(t) == 30)
t=wrap.lib_a_f_5()
assert(600 == wrap.lib_a_f_4(t))
assert(wrap.point_geta(t) == 20)
assert(wrap.point_getb(t) == 30)