mirror of
git://projects.qi-hardware.com/nn-usb-fpga.git
synced 2024-12-05 04:31:52 +02:00
aaa
This commit is contained in:
parent
d01e4f4f47
commit
0975cd73dc
@ -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);
|
||||
|
@ -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
2131
course/.docs/book/biblio.bib
Normal file
File diff suppressed because it is too large
Load Diff
2123
course/.docs/book/biblio.bib.bak
Normal file
2123
course/.docs/book/biblio.bib.bak
Normal file
File diff suppressed because it is too large
Load Diff
367
course/.docs/book/commons.tex
Normal file
367
course/.docs/book/commons.tex
Normal file
@ -0,0 +1,367 @@
|
||||
\chapter{Copyleft HW/SW y el Conocimiento Como Bien Común}
|
||||
\label{ch:common}
|
||||
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|
||||
%%% El conocimiento como bien común %%%%%%
|
||||
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|
||||
|
||||
\section{Introducción}
|
||||
|
||||
Es indudable que el desarrollo tecnológico de un país se encuentra ligado al mejoramiento de la calidad de vida de sus habitantes, y que para que un país en vía de desarrollo se realice una transferencia tecnológica (y de conocimientos asociados a la tecnología que se transfiere) exitosa que permita desarrollar productos similares, pero ajustados al contexto socio-económico local, es necesario que el país cuente con la capacidad de absorber las habilidades, técnicas, información y organización asociadas a dicha tecnología. Esta absorció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 él, debe ser un derecho y por lo tanto, la sociedad debe garantizar los mecanismos de difusión para que llegue a los sectores de la sociedad interesados en él. De igual forma, es un deber, de los sectores que utilizan este bien común contribuir a su difusión, actualización, mejoramiento, y crecimiento.
|
||||
|
||||
Un bien comú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ún esta asociado a la \textit{libertad de expresión}, \textit{libre acceso} y \textit{autogobierno}
|
||||
|
||||
El conocimiento en este trabajo se refiere a las ideas intangibles, información y datos de todo tipo en que el conocimiento es expresado u obtenido, como todo tipo de entendimiento adquirido a través de la experiencia o estudio ya sea propio, científico, académico o no académico. El conocimiento puede ser visto como una mercancía y como una fuerza constitutiva de la sociedad lo que evidencia la naturaleza compleja de este recurso, adicionalmente, la adqusición y descubrimiento de conocimiento es un proceso social y personal. \textit{El descubrimiento de conocimiento es un bien común y un tesoro que dejamoa a futuras generaciones y el reto de nuestra generación es en mantener los caminos del descubrimiento abiertos}.
|
||||
|
||||
El acceso al conocimiento debe garantizarse sin restricción alguna a las personas interesadas, al considerar el conocimiento como un producto comercial se limita su difusión favoreciendo a un grupo de la población, lo cual es inaceptable, ya que representa una forma de discriminación. En nuestro pais, el acceso a la información ha ido aumentando gracias a la aparició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és de un procesos de enseñanza formal. En Colombia el acceso a la educación superior de calidad es limitado, la cobertura de las Universidades públicas está limitada por la inversión del estado, y como pudimos ver anteriormente, en nuestro país la preocupación actual es la seguridad y no la educación. Por lo tanto, hacer del conocimiento un bien común requiere la intervenció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 énfasis en la transferencia y difusión del conocimiento, del \textit{saber hacer}, muchas políticas existentes se enfocan en la compra de equipo, lo que, como se vió antes no es el canal más eficiente para la transferencia tecnológica. Nuestros esfuerzos están enfocados a crear un conocimiento básico en la Concepción, Diseño, Implementación y Diseño de Sistemas Embebidos. Este conocimiento es el resultado de años de experimentación e investigación en el área, al ser colocado a disposición de usuarios interesados, se aumentan las posibilidades de difusión, ya que ya se realizó un trabajo previo de "adaptación" a las condiciones de la plataforma tecnológica local y al contexto econó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ón cobrando altos precios para acceder a ella.
|
||||
|
||||
En este capítulo estudiaremos las licencias \textit{Creative Commons} una nueva forma de licenciamiento que permite asignar diferentes "permisos" de utilizació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ó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ón de un movimiento que funcione con políticas similares pero centrado en el Desarrollo Hardware.
|
||||
|
||||
|
||||
\section{El Conocimiento Como Bien Común}
|
||||
El análisis del conocimiento como bien común tiene sus bases en el estudio de recursos naturales compartidos (agua, bosques, fauna, flora). El recurso puede ser pequeñ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ósfera, internet, conocimiento científico, etc), puden ser delimitados (la librerí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ún como un recurso o sistema de recursos y el bien común como un régimen de derechos de propiedad\cite{EO90}. El conocimiento posee caracterí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ún es lograr su máxima difusión. El beneficio asociado al acceso a la informació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ños. Para que este recurso sea útil se requiere una infra-estructura que permita su difusión, actualización, mejoramiento, realimentació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áficos?
|
||||
Como coordinar acciones de miles de usuarios para garantizar un recurso útil y sostenible? Como convertir este conocimiento en motor de Desarrollo y crecimiento empresarial? Estas preguntas serán respondidas a lo largo de este capítulo.
|
||||
|
||||
\subsection{Auto-Gobierno}
|
||||
|
||||
Ostrom \cite{Ost00} argumenta que la forma más eficiente de administrar un bien comú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ón o decisión que se haga es formulada pensando en el beneficio común se creará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ó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útil crear una organización alrededor de él.
|
||||
\item Indicadores: Disponibilidad de indicadores confiables y válidos sobre la condición del recurso.
|
||||
\item Predictibilidad: El flujo de unidades de recurso es relativamente predecible.
|
||||
\item El recurso es lo suficientemente pequeño, teniendo en cuenta las tecnologías de comunicació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ún: Conocimiento sobre el funcionamiento del sistema y como acciones individuales afectan a los demá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ían en que los demás mantendrán las promesas y se relacionarán entre ellos con reciprocidad.
|
||||
\item Autonomía: Los usuarios pueden determinar reglas sin la intervención de autoridades externas
|
||||
\item Experiencia Previa en Organización y Liderazgo Local: Los usuarios poseen habilidades mínimas de organización y liderazgo a través de la participació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ó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ún, un grupo de estas normas debe establecer mecanismos de resolución de conflictos, esto es vital ya que toda la organizació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 éxito de sus acciones y el sostenimiento del recurso depende de sus acciones, las cuales deben realizarse teniendo en cuenta el beneficio común. El conocimiento no se ve afectado por la sustracció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 área de la Electrónica digital) y por lo tanto inservible, para que esto no suceda se requiere de la actualización de este conocimiento para que refleje el estado actual en un área determinada.
|
||||
|
||||
\subsubsection{Ecuació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ón que describe el aná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ó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ón entre sub-grupos de usuarios, esta ecuació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án participando y promoviendo el desarrollo de productos y aplicaciones \cite{Mot} \cite{And} \cite{Mae} con la participación de la comunidad, lo que representa un giro de 180 grados en la políticas lideradas por multinacionales como Microsoft y Aple en las que todas sus creaciones están protegidas por licencias, acuerdos comerciales y contratos de exclusividad que restringen la participació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í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ón los grandes multinacionales está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ño}
|
||||
|
||||
El primer paso para gobernar un bien común es la identificación de los principios de diseño de un recurso común robusto de larga duración. Ostrom \cite{EO90} después de dirigir un gran número de estudios empíricos sobre gobernancia de recursos de bienes comúnes. Encontró una serir de principios de diseñ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ó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ón de conflictos de bajo costo.
|
||||
\item Las actividades de apropiación, suministro, monitoreo y sanción deben ser organizadas en estructuras anidadas con múltiples capas de actividades
|
||||
\end{itemize}
|
||||
|
||||
Es importante mencionar que no existe una combinación de principios que garantice el é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ía de las instituciones analizadas en cientos de estudios y constituyen un buen punto de partida para comenzar esta investigació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ún, ya que es un recurso comunal que prospera o decae gracias a la contribució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í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ón modificada de la ecuació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ó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ño, proporcionando:
|
||||
|
||||
|
||||
\begin{itemize}
|
||||
\item Herramientas de programación, depuración y librerías que facilitan el desarrollo de nuevas aplicaciones o mejoras a las ya existentes.
|
||||
\item Listas de discusión en donde los creadores de estas herramientas responden preguntas, y buscan en conjunto soluciones a problemas específicos
|
||||
\item Sistemas de control de versiones y protocolos de comunicación.
|
||||
\item Bases de datos de solución de problemas asociadas a las listas de discusión.
|
||||
\item Tutoriales, documentació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ñ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ón de \textit{Hadrware Copyleft}
|
||||
|
||||
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|
||||
%%% FOSS %%%%%%
|
||||
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|
||||
\section{FOSS}
|
||||
|
||||
Como se mencionó anteriormente, el movimiento FOSS es la estructura auto-gobernada más exitosa y será tomada como referencia en el desarrollo de nuestra iniciativa de Hardware Copyleft. Su principal innovación radica en un nuevo esquema de licencias unido a herramientas de colaboración basadas en Internet, lo que se cnvirtió en una nueva forma de bien común, donde los miembros de forma colectiva generan un buen común el \textit{software}. El desafí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ón de acción" que estos programadores encaran es, si en algún momento, vale la pena contribuir al desarrollo de este software. La interació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ú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ón), estabilización donde el número de participantes (normalmente pequeño) no varía, o el protecto se estanca y muere (sin participantes). Para que un proyecto sea exitoso, no es necesaria la participación de un gran número de programadores, es frecuente encontrar grupos pequeños de programadores con un gran número de usuarios. La clave del éxito está en la disponibilidad de un programador para contribuir al esfuerzo colectivo de por lo menos un pequeñ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ún, aplicado al movimiento FOSS. Como se mencionó anteriormente, el razgo que diferencia este movimiento es la utilización de una forma de licenciamiento especial. Richard Stallman \cite{Wikb}, a mediados de los 80 inició 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ía se basa en cuatro libertades que encarnan el principio \textit{copyleft}:
|
||||
|
||||
\begin{itemize}
|
||||
\item Libertad de ejecutar el software para cualquier propó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ó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ón para esto.
|
||||
\end{itemize}
|
||||
|
||||
Esta filosofía permite que los conocimientos y habilidades que el programador posee puedan ser transferidas a programadores, empresas, instituciones académicas y sociedades, ya sea en forma de producto o como herramienta de enseñanza. Esta actividad representa un proceso de Transferencia Tecnológica, en la que el que suministra la tecnología proporciona todos los medios para que el receptor pueda abosrverla y transformarla para satisfacer necesidades en su entorno social. Adicionalmente, Stallman ideó 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ó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ún aplicado al movimiento FOSS: Modificació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í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ún.
|
||||
|
||||
La clave para mantener un bien comú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ón, normas implícitas y explí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ían incluir:
|
||||
|
||||
\begin{itemize}
|
||||
\item Priorización de características a incluir en nuevas versiones del software.
|
||||
\item Definición de Reglas y procedimientos para evaluar y escoger nuevos aportes para que hagan parte de las nuevas versiones.
|
||||
\item Definición de Reglas y procedimientos para detectar y corregir errores en el software.
|
||||
\item Asignación y administración de tareas.
|
||||
\item Asistencia en la resolución de disputas entre miembros del equipo.
|
||||
\end{itemize}
|
||||
|
||||
Estas reglas varí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ó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ógicos, sociopolíticos, económicos y académicos. Desde el punto de vista tecnológico, resulta más efectivo en tiempo y en dinero, participar en un proyecto conjunto para la realización de una aplicación que satisface una determinada necesidad. La principal motivación sociopolítica es la creencia por parte del programador en la filosofí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ómicas y académicas pueden ser consideradas en forma conjunta ya que al participar en estos proyectos, los miembros adquieren o mejoran sus habilidades de programación ya sea revisando, leyendo y entendiendo el código existente o sometiendo a la revisión de los demás miembros sus contribuciones. Por otro lado, esta participació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ón es una forma de inversión y una forma de ganar experiencia y reputación \cite{VWJ+03}.
|
||||
|
||||
En proyectos con un gran número de personas asociadas, solo un pequeño porcentaje de ellos realizan la mayor parte del trabajo. En la actualidad muchas empresas está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ón a participar es el interes propio en estandarización, disminució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í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ú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ño o la estructura del software. Un código limpio (optimizado, documentado y óptimo) y modularizado permite el trabajo en paralelo, lo que reduce el tiempo de depuración y el requerido para implementar nuevas características.
|
||||
\item La infraestructura que hace posible coordinar y administrar la colaboración y la producción: El uso de Internet para soportar herramientas de control de versiones (como \textit{svn}, \textit{cvs} y \textit{git}) y la comunicación vía listas de discusión hace posible coordinar de forma eficiente los esfuerzos de cooperación. Permitiendo:
|
||||
\begin{itemize}
|
||||
\item Almacenar versiones de software.
|
||||
\item La descarga de módulos.
|
||||
\item La adición de Nuevas contribuciones y la protecció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ón, los proyectos FOSS evolucionan en el tiempo como resultado de la configuració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ón y herramientas efectivas para coordinació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ón de hardware) es necesario ampliar el término \textit{copyleft} de Stallman. El primer en esta dirección fué dado por el mismo Stallman al desarrollar la licencia GFDL (GNU Free Documentation License) aplicable a todo tipo de documentación técnica, guias de usuario, tutoriales, etc. Esta licencia gobierna el uso, modificación y distribución de la documentació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ón.
|
||||
|
||||
|
||||
\subsection{Licencias Creative Commons}
|
||||
|
||||
Creative Commons \footnote{http://creativecommons.org/} organización no gubernamental sin á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ón, con la única condición de dar cré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ón} (\textbf{BY}): Se permite la distribución pero se debe dar crédito al autor.
|
||||
\item \textit{No comercial} (\textbf{NC}): Se permite la distribución del trabajo sin fines comerciales, si se desea utilizar este trabajo para obtener dinero es necesaria una autorización del autor
|
||||
\item \textit{No a trabajos derivados} (\textbf{ND}): Permite la copia y la distribució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ón se relizará la definición del término \textit{hardware copyleft} como una extensión del proyecto \textit{FOSS}. Una de las hipótesis manejadas durante el desarrollo de este trabajo es que el conocimiento debe ser considerado como un bien comú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ógica y de conocimientos exitosa a la academia y a la industria electrónica nacional (en el área de sistemas digitales) se utilizará el principio del conocimiento como bien comú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ó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án diseñados para ejecutar una función única, por lo que el componente hardware se encuentra optimizado (funcionalidad, tamaño, consumo de potencia, costos) para la ejecución de dicha tarea. Como se mencionó anteriormente existe un movimiento muy fuerte (FOSS) que proporciona una gran variedad de herramientas para la implementación del componente software. Sin embargo, hasta el momento no existe un movimiento similar dirigido al desarrollo del componente hardware. Mi hipótesis es que un movimiento de hardware abierto permitirá el desarrollo de la industria electrónica local permitiendo la transferencia exitosa de tecnología y conocimientos en el área de diseño de sistemas embebidos.
|
||||
|
||||
Haciendo una analogía con el movimiento FOSS, la iniciativa \textit{hardware copyleft} permitiría el uso, distribución, y modificación de proyectos hardware existentes. La acción de modificación se origina por una necesidad que se debe satisfacer, implica un entendimiento del principio de funcionamiento y del proceso de fabricación asociados al proyecto original. Lo anterior cumple con la definición de transferencia tecnoló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ógica se considera exitosa cuando los receptores de la tecnología asimilan los conceptos anteriores para suplir sus necesidades locales''.
|
||||
|
||||
El reto en la definició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ón para modificar un proyecto existente ; los proyectos hardware involucran procesos de fabricación, montaje y pruebas que tienen asociados unos costos que varían dependiendo de la tecnologí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ómico en la formación de la comunidad, definiendo las características que deben poseer estos proyectos para minimizar el costo asociado.
|
||||
|
||||
|
||||
\subsection{Atributos de la Comunidad}
|
||||
|
||||
El éxito de la iniciativa \textit{FOSS} se debe en parte a la gran comunidad que comparte la ideología del software libre \cite{RS07},sus miembros buscan: satisfacer necesidades propias \cite{JK00}, aprendizaje \cite{HIH02}, reputación dentro y fuera de la comunidad, asociación e identidad \cite{GH03}, diversió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ó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ón inicial para la participació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ó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ó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ó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ían mucho tiempo o en algunos casos nunca se realizarían.
|
||||
|
||||
\item \textit{Contribución con la escritura de código fuente.} Algunos de los miembros de estas comunidades son empleados de compañías que utilizan resultados de estos proyectos en sus productos comerciales, y dentro de sus intereses está incluir en las distribuciones oficiales funcionalidades creadas por ellos.
|
||||
|
||||
\item \textit{Motivos profesionales.} Razones como reputación, desarrollo de habilidades tienen una importancia relativamente baja en la creación y contribución de código. La mayoría expresa que su participación busca conocimiento específico del proyecto y no para adquirir habilidades especí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ó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 área del problema inicial \\\cline{2-5}
|
||||
& Mejoras futuras & Variable, depende de la necesidad & Moderada & En el á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 área del problema inicial \\ \hline
|
||||
\textbf{\textit{Diversión y disfrute}}
|
||||
& Realimentación & Alto & Bajo & Comienza en un área determinada, y se expande \\ \hline
|
||||
\end{tabular}
|
||||
\caption{Motivación de la participació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ándose de tareas como mejora de la plataforma tecnoló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ón de código a la comunidad y que la forma de gobierno afecta dramáticamente la participació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ñ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.
|
||||
|
||||
|
||||
|
||||
|
||||
|
367
course/.docs/book/commons.tex.backup
Normal file
367
course/.docs/book/commons.tex.backup
Normal file
@ -0,0 +1,367 @@
|
||||
\chapter{Copyleft HW/SW y el Conocimiento Como Bien Común}
|
||||
\label{ch:common}
|
||||
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|
||||
%%% El conocimiento como bien común %%%%%%
|
||||
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|
||||
|
||||
\section{Introducción}
|
||||
|
||||
Es indudable que el desarrollo tecnológico de un país se encuentra ligado al mejoramiento de la calidad de vida de sus habitantes, y que para que un país en vía de desarrollo se realice una transferencia tecnológica (y de conocimientos asociados a la tecnología que se transfiere) exitosa que permita desarrollar productos similares, pero ajustados al contexto socio-económico local, es necesario que el país cuente con la capacidad de absorber las habilidades, técnicas, información y organización asociadas a dicha tecnología. Esta absorció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 él, debe ser un derecho y por lo tanto, la sociedad debe garantizar los mecanismos de difusión para que llegue a los sectores de la sociedad interesados en él. De igual forma, es un deber, de los sectores que utilizan este bien común contribuir a su difusión, actualización, mejoramiento, y crecimiento.
|
||||
|
||||
Un bien comú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ún esta asociado a la \textit{libertad de expresión}, \textit{libre acceso} y \textit{autogobierno}
|
||||
|
||||
El conocimiento en este trabajo se refiere a las ideas intangibles, información y datos de todo tipo en que el conocimiento es expresado u obtenido, como todo tipo de entendimiento adquirido a través de la experiencia o estudio ya sea propio, científico, académico o no académico. El conocimiento puede ser visto como una mercancía y como una fuerza constitutiva de la sociedad lo que evidencia la naturaleza compleja de este recurso, adicionalmente, la adqusición y descubrimiento de conocimiento es un proceso social y personal. \textit{El descubrimiento de conocimiento es un bien común y un tesoro que dejamoa a futuras generaciones y el reto de nuestra generación es en mantener los caminos del descubrimiento abiertos}.
|
||||
|
||||
El acceso al conocimiento debe garantizarse sin restricción alguna a las personas interesadas, al considerar el conocimiento como un producto comercial se limita su difusión favoreciendo a un grupo de la población, lo cual es inaceptable, ya que representa una forma de discriminación. En nuestro pais, el acceso a la información ha ido aumentando gracias a la aparició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és de un procesos de enseñanza formal. En Colombia el acceso a la educación superior de calidad es limitado, la cobertura de las Universidades públicas está limitada por la inversión del estado, y como pudimos ver anteriormente, en nuestro país la preocupación actual es la seguridad y no la educación. Por lo tanto, hacer del conocimiento un bien común requiere la intervenció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 énfasis en la transferencia y difusión del conocimiento, del \textit{saber hacer}, muchas políticas existentes se enfocan en la compra de equipo, lo que, como se vió antes no es el canal más eficiente para la transferencia tecnológica. Nuestros esfuerzos están enfocados a crear un conocimiento básico en la Concepción, Diseño, Implementación y Diseño de Sistemas Embebidos. Este conocimiento es el resultado de años de experimentación e investigación en el área, al ser colocado a disposición de usuarios interesados, se aumentan las posibilidades de difusión, ya que ya se realizó un trabajo previo de "adaptación" a las condiciones de la plataforma tecnológica local y al contexto econó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ón cobrando altos precios para acceder a ella.
|
||||
|
||||
En este capítulo estudiaremos las licencias \textit{Creative Commons} una nueva forma de licenciamiento que permite asignar diferentes "permisos" de utilizació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ó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ón de un movimiento que funcione con políticas similares pero centrado en el Desarrollo Hardware.
|
||||
|
||||
|
||||
\section{El Conocimiento Como Bien Común}
|
||||
El análisis del conocimiento como bien común tiene sus bases en el estudio de recursos naturales compartidos (agua, bosques, fauna, flora). El recurso puede ser pequeñ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ósfera, internet, conocimiento científico, etc), puden ser delimitados (la librerí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ún como un recurso o sistema de recursos y el bien común como un régimen de derechos de propiedad\cite{EO90}. El conocimiento posee caracterí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ún es lograr su máxima difusión. El beneficio asociado al acceso a la informació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ños. Para que este recurso sea útil se requiere una infra-estructura que permita su difusión, actualización, mejoramiento, realimentació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áficos?
|
||||
Como coordinar acciones de miles de usuarios para garantizar un recurso útil y sostenible? Como convertir este conocimiento en motor de Desarrollo y crecimiento empresarial? Estas preguntas serán respondidas a lo largo de este capítulo.
|
||||
|
||||
\subsection{Auto-Gobierno}
|
||||
|
||||
Ostrom \cite{Ost00} argumenta que la forma más eficiente de administrar un bien comú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ón o decisión que se haga es formulada pensando en el beneficio común se creará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ó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útil crear una organización alrededor de él.
|
||||
\item Indicadores: Disponibilidad de indicadores confiables y válidos sobre la condición del recurso.
|
||||
\item Predictibilidad: El flujo de unidades de recurso es relativamente predecible.
|
||||
\item El recurso es lo suficientemente pequeño, teniendo en cuenta las tecnologías de comunicació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ún: Conocimiento sobre el funcionamiento del sistema y como acciones individuales afectan a los demá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ían en que los demás mantendrán las promesas y se relacionarán entre ellos con reciprocidad.
|
||||
\item Autonomía: Los usuarios pueden determinar reglas sin la intervención de autoridades externas
|
||||
\item Experiencia Previa en Organización y Liderazgo Local: Los usuarios poseen habilidades mínimas de organización y liderazgo a través de la participació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ó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ún, un grupo de estas normas debe establecer mecanismos de resolución de conflictos, esto es vital ya que toda la organizació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 éxito de sus acciones y el sostenimiento del recurso depende de sus acciones, las cuales deben realizarse teniendo en cuenta el beneficio común. El conocimiento no se ve afectado por la sustracció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 área de la Electrónica digital) y por lo tanto inservible, para que esto no suceda se requiere de la actualización de este conocimiento para que refleje el estado actual en un área determinada.
|
||||
|
||||
\subsubsection{Ecuació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ón que describe el aná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ó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ón entre sub-grupos de usuarios, esta ecuació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án participando y promoviendo el desarrollo de productos y aplicaciones \cite{Mot} \cite{And} \cite{Mae} con la participación de la comunidad, lo que representa un giro de 180 grados en la políticas lideradas por multinacionales como Microsoft y Aple en las que todas sus creaciones están protegidas por licencias, acuerdos comerciales y contratos de exclusividad que restringen la participació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í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ón los grandes multinacionales está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ño}
|
||||
|
||||
El primer paso para gobernar un bien común es la identificación de los principios de diseño de un recurso común robusto de larga duración. Ostrom \cite{EO90} después de dirigir un gran número de estudios empíricos sobre gobernancia de recursos de bienes comúnes. Encontró una serir de principios de diseñ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ó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ón de conflictos de bajo costo.
|
||||
\item Las actividades de apropiación, suministro, monitoreo y sanción deben ser organizadas en estructuras anidadas con múltiples capas de actividades
|
||||
\end{itemize}
|
||||
|
||||
Es importante mencionar que no existe una combinación de principios que garantice el é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ía de las instituciones analizadas en cientos de estudios y constituyen un buen punto de partida para comenzar esta investigació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ún, ya que es un recurso comunal que prospera o decae gracias a la contribució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í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ón modificada de la ecuació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ó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ño, proporcionando:
|
||||
|
||||
|
||||
\begin{itemize}
|
||||
\item Herramientas de programación, depuración y librerías que facilitan el desarrollo de nuevas aplicaciones o mejoras a las ya existentes.
|
||||
\item Listas de discusión en donde los creadores de estas herramientas responden preguntas, y buscan en conjunto soluciones a problemas específicos
|
||||
\item Sistemas de control de versiones y protocolos de comunicación.
|
||||
\item Bases de datos de solución de problemas asociadas a las listas de discusión.
|
||||
\item Tutoriales, documentació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ñ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ón de \textit{Hadrware Copyleft}
|
||||
|
||||
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|
||||
%%% FOSS %%%%%%
|
||||
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|
||||
\section{FOSS}
|
||||
|
||||
Como se mencionó anteriormente, el movimiento FOSS es la estructura auto-gobernada más exitosa y será tomada como referencia en el desarrollo de nuestra iniciativa de Hardware Copyleft. Su principal innovación radica en un nuevo esquema de licencias unido a herramientas de colaboración basadas en Internet, lo que se cnvirtió en una nueva forma de bien común, donde los miembros de forma colectiva generan un buen común el \textit{software}. El desafí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ón de acción" que estos programadores encaran es, si en algún momento, vale la pena contribuir al desarrollo de este software. La interació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ú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ón), estabilización donde el número de participantes (normalmente pequeño) no varía, o el protecto se estanca y muere (sin participantes). Para que un proyecto sea exitoso, no es necesaria la participación de un gran número de programadores, es frecuente encontrar grupos pequeños de programadores con un gran número de usuarios. La clave del éxito está en la disponibilidad de un programador para contribuir al esfuerzo colectivo de por lo menos un pequeñ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ún, aplicado al movimiento FOSS. Como se mencionó anteriormente, el razgo que diferencia este movimiento es la utilización de una forma de licenciamiento especial. Richard Stallman \cite{Wikb}, a mediados de los 80 inició 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ía se basa en cuatro libertades que encarnan el principio \textit{copyleft}:
|
||||
|
||||
\begin{itemize}
|
||||
\item Libertad de ejecutar el software para cualquier propó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ó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ón para esto.
|
||||
\end{itemize}
|
||||
|
||||
Esta filosofía permite que los conocimientos y habilidades que el programador posee puedan ser transferidas a programadores, empresas, instituciones académicas y sociedades, ya sea en forma de producto o como herramienta de enseñanza. Esta actividad representa un proceso de Transferencia Tecnológica, en la que el que suministra la tecnología proporciona todos los medios para que el receptor pueda abosrverla y transformarla para satisfacer necesidades en su entorno social. Adicionalmente, Stallman ideó 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ó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ún aplicado al movimiento FOSS: Modificació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í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ún.
|
||||
|
||||
La clave para mantener un bien comú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ón, normas implícitas y explí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ían incluir:
|
||||
|
||||
\begin{itemize}
|
||||
\item Priorización de características a incluir en nuevas versiones del software.
|
||||
\item Definición de Reglas y procedimientos para evaluar y escoger nuevos aportes para que hagan parte de las nuevas versiones.
|
||||
\item Definición de Reglas y procedimientos para detectar y corregir errores en el software.
|
||||
\item Asignación y administración de tareas.
|
||||
\item Asistencia en la resolución de disputas entre miembros del equipo.
|
||||
\end{itemize}
|
||||
|
||||
Estas reglas varí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ó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ógicos, sociopolíticos, económicos y académicos. Desde el punto de vista tecnológico, resulta más efectivo en tiempo y en dinero, participar en un proyecto conjunto para la realización de una aplicación que satisface una determinada necesidad. La principal motivación sociopolítica es la creencia por parte del programador en la filosofí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ómicas y académicas pueden ser consideradas en forma conjunta ya que al participar en estos proyectos, los miembros adquieren o mejoran sus habilidades de programación ya sea revisando, leyendo y entendiendo el código existente o sometiendo a la revisión de los demás miembros sus contribuciones. Por otro lado, esta participació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ón es una forma de inversión y una forma de ganar experiencia y reputación \cite{VWJ+03}.
|
||||
|
||||
En proyectos con un gran número de personas asociadas, solo un pequeño porcentaje de ellos realizan la mayor parte del trabajo. En la actualidad muchas empresas está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ón a participar es el interes propio en estandarización, disminució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í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ú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ño o la estructura del software. Un código limpio (optimizado, documentado y óptimo) y modularizado permite el trabajo en paralelo, lo que reduce el tiempo de depuración y el requerido para implementar nuevas características.
|
||||
\item La infraestructura que hace posible coordinar y administrar la colaboración y la producción: El uso de Internet para soportar herramientas de control de versiones (como \textit{svn}, \textit{cvs} y \textit{git}) y la comunicación vía listas de discusión hace posible coordinar de forma eficiente los esfuerzos de cooperación. Permitiendo:
|
||||
\begin{itemize}
|
||||
\item Almacenar versiones de software.
|
||||
\item La descarga de módulos.
|
||||
\item La adición de Nuevas contribuciones y la protecció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ón, los proyectos FOSS evolucionan en el tiempo como resultado de la configuració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ón y herramientas efectivas para coordinació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ón de hardware) es necesario ampliar el término \textit{copyleft} de Stallman. El primer en esta dirección fué dado por el mismo Stallman al desarrollar la licencia GFDL (GNU Free Documentation License) aplicable a todo tipo de documentación técnica, guias de usuario, tutoriales, etc. Esta licencia gobierna el uso, modificación y distribución de la documentació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ón.
|
||||
|
||||
|
||||
\subsection{Licencias Creative Commons}
|
||||
|
||||
Creative Commons \footnote{http://creativecommons.org/} organización no gubernamental sin á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ón, con la única condición de dar cré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ón} (\textbf{BY}): Se permite la distribución pero se debe dar crédito al autor.
|
||||
\item \textit{No comercial} (\textbf{NC}): Se permite la distribución del trabajo sin fines comerciales, si se desea utilizar este trabajo para obtener dinero es necesaria una autorización del autor
|
||||
\item \textit{No a trabajos derivados} (\textbf{ND}): Permite la copia y la distribució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ón se relizará la definición del término \textit{hardware copyleft} como una extensión del proyecto \textit{FOSS}. Una de las hipótesis manejadas durante el desarrollo de este trabajo es que el conocimiento debe ser considerado como un bien comú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ógica y de conocimientos exitosa a la academia y a la industria electrónica nacional (en el área de sistemas digitales) se utilizará el principio del conocimiento como bien comú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ó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án diseñados para ejecutar una función única, por lo que el componente hardware se encuentra optimizado (funcionalidad, tamaño, consumo de potencia, costos) para la ejecución de dicha tarea. Como se mencionó anteriormente existe un movimiento muy fuerte (FOSS) que proporciona una gran variedad de herramientas para la implementación del componente software. Sin embargo, hasta el momento no existe un movimiento similar dirigido al desarrollo del componente hardware. Mi hipótesis es que un movimiento de hardware abierto permitirá el desarrollo de la industria electrónica local permitiendo la transferencia exitosa de tecnología y conocimientos en el área de diseño de sistemas embebidos.
|
||||
|
||||
Haciendo una analogía con el movimiento FOSS, la iniciativa \textit{hardware copyleft} permitiría el uso, distribución, y modificación de proyectos hardware existentes. La acción de modificación se origina por una necesidad que se debe satisfacer, implica un entendimiento del principio de funcionamiento y del proceso de fabricación asociados al proyecto original. Lo anterior cumple con la definición de transferencia tecnoló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ógica se considera exitosa cuando los receptores de la tecnología asimilan los conceptos anteriores para suplir sus necesidades locales''.
|
||||
|
||||
El reto en la definició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ón para modificar un proyecto existente ; los proyectos hardware involucran procesos de fabricación, montaje y pruebas que tienen asociados unos costos que varían dependiendo de la tecnologí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ómico en la formación de la comunidad, definiendo las características que deben poseer estos proyectos para minimizar el costo asociado.
|
||||
|
||||
|
||||
\subsection{Atributos de la Comunidad}
|
||||
|
||||
El éxito de la iniciativa \textit{FOSS} se debe en parte a la gran comunidad que comparte la ideología del software libre \cite{RS07},sus miembros buscan: satisfacer necesidades propias \cite{JK00}, aprendizaje \cite{HIH02}, reputación dentro y fuera de la comunidad, asociación e identidad \cite{GH03}, diversió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ó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ón inicial para la participació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ó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ó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ó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ían mucho tiempo o en algunos casos nunca se realizarían.
|
||||
|
||||
\item \textit{Contribución con la escritura de código fuente.} Algunos de los miembros de estas comunidades son empleados de compañías que utilizan resultados de estos proyectos en sus productos comerciales, y dentro de sus intereses está incluir en las distribuciones oficiales funcionalidades creadas por ellos.
|
||||
|
||||
\item \textit{Motivos profesionales.} Razones como reputación, desarrollo de habilidades tienen una importancia relativamente baja en la creación y contribución de código. La mayoría expresa que su participación busca conocimiento específico del proyecto y no para adquirir habilidades especí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ó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 área del problema inicial \\\cline{2-5}
|
||||
& Mejoras futuras & Variable, depende de la necesidad & Moderada & En el á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 área del problema inicial \\ \hline
|
||||
\textbf{\textit{Diversión y disfrute}}
|
||||
& Realimentación & Alto & Bajo & Comienza en un área determinada, y se expande \\ \hline
|
||||
\end{tabular}
|
||||
\caption{Motivación de la participació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ándose de tareas como mejora de la plataforma tecnoló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ón de código a la comunidad y que la forma de gobierno afecta dramáticamente la participació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ñ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.
|
||||
|
||||
|
||||
|
||||
|
||||
|
809
course/.docs/book/education.tex
Normal file
809
course/.docs/book/education.tex
Normal file
@ -0,0 +1,809 @@
|
||||
\chapter{Habilidades CDIO}
|
||||
\label{ch:education}
|
||||
|
||||
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|
||||
%%% INTRODUCCION %%%%%%
|
||||
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|
||||
\section{Introducció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ía, y ha sido adoptada por un creciente número de instiruciones académicas a lo largo del mundo.
|
||||
|
||||
La educación de la ingeniería y las demandas del mundo real están tomando caminos separados, la Iniciativa CDIO es un proyecto mundial que busca desarrollar una nueva visión de la educación en ingeniería. Hacer parte de este esfuerzo mundial nos ayuda a mantener nuestros planes académicos actualizados con los cambios que se realizan en países más industrializados. En este capítulo mostraremos como esta iniciativa se adapta perfectamemente a los cambios que se han inroducido en el área de la electrónica digital en la universidad Nacional de Colombia.
|
||||
|
||||
La Iniciativa CDIO se basa en la suposición que los egresados de los centros de formación en ingeniería deben ser capaces de: Concebir, Diseñar, Implementar y Operar sistemas complejos en un entorno basado en equipos para crear sistemas y productos. En Colombia, la mayoría de los centros de formación solo tienen en cuenta la Concepción y el Diseño, descuidando por completo la Implementación y la Operación de sistemas, esto, impide que se tenga una estrecha relació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ón y operación de nuevos productos y sistemas.
|
||||
\item Educar futuros investigadores para entender la importancia estratégica y el valor de su trabajo.
|
||||
\end{itemize}
|
||||
|
||||
El Departamento de Ingeniería Eléctrica y Electrónica de la Universidad Nacional de Colombia está realizando el trabajo de adaptar la Iniciativa CDIO a su programa académico, esta iniciativa coincidió con el desarrollo de esta investigación. Los objetivos de esta iniciativa se adaptan a los requerimientos que se exige a la plataforma tecnológica de un país para que pueda realizar una adecuada absorción del conocimiento transferido y posteriormente transformar ese conocimiento en nuevos productos adaptados a las necesidades del país.
|
||||
|
||||
Las premisas que capturan la visión, objetivos y fundamentos pedagógicos de la Iniciativa CDIO son:
|
||||
|
||||
\begin{itemize}
|
||||
\item Es posible cumplir las necesidades propias de la profesión mientras al mismo tiempo se realiza el proceso de Concebir, diseñar, implementar y operar sistemas en el contexto de los sistemas de Ingeniería.
|
||||
\item Los resultados de la formació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án en el ejercicio de su profesión.
|
||||
\item La adecuada construcción de esta cadena de actividades tendrán un doble impacto en la formación de los estudiantes, por un lado facilitará el aprendizaje de habilidades críticas e inter-personales y fortalecerá las habilidades de construcción de sistemas, productos y procesos, mientras se mejora el aprendizaje de los conceptos fundamentales.
|
||||
\end{itemize}
|
||||
|
||||
\subsubsection{liderazgo}
|
||||
|
||||
La situación actual por la que atraviesa la Industria electrónica nacional, requiere que los profesionales en el área tengan las capacidades de emprendimiento y liderazgo necesarias para la creación de nuevas empresas o para la creación de nuevos productos, la Figura \ref{cdio_emp_lid} muestra la relació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ú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ños experimentos para obtener informació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ón} Crear una visión para uno mismo y transmitir esta visión a los demás.
|
||||
\item \textit{Realización de la Visión}
|
||||
\end{itemize}
|
||||
|
||||
\subsubsection{Emprendimiento}
|
||||
El concepto clásico de emprendimiento involucra el re-direccionamiento y movilización de capital y recursos humanos para crear una nueva actividad económica. Actualmente, el emprendimiento esta asociado a la creación de une nueva empresa con una nueva línea de negocios. En algunas ocasiones las innovaciones tecnológicas no requieren cambios en el mercado. Cuando la ingeniería es el componente principal del producto, se debe enfatizar en el proceso de diseño y los ingenieros deben entender la relació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ón en la compañia y otras consideraciones de negocios que influyen en el diseño y las estrategias de implementació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áctica. Con el fín de desarrollar sistemas de ingenierí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ó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ñ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ñ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únes a los planes de estudio de las ingenierías modernas y son:
|
||||
|
||||
\begin{enumerate}
|
||||
\item Fundamentos Avanzados de Igeniería.
|
||||
\item Fundamentos del núcleo de Ingeniería.
|
||||
\item Conocimiento científico.
|
||||
\end{enumerate}
|
||||
|
||||
La razó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á este componente ya que para hacerlo es necesario un consenso con las demás carreras de la facultad de Ingenierí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ón de problemas, Descubrimiento de conocimiento y Pensamiento sistémico.
|
||||
\item Actitudes que incluyen integridad y comportamiento profesional así como las necesarias para planear la profesió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ácter, iniciativa, perseverancia, formas de pensar más genéricas como pensamiento crí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íficas de un equipo de trabajo técnico. La comunicación se compone de habilidades para idear estrategias de comunicación y aquellas para utilizar los medios orales, escritos, electrónicos y gráficos y en el caso Colombiano el uso del idioma Inglés. La Figura \ref{cdio_2_3} muestra la relació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ó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ñ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ía Eléctrica y Electrónica sean capaces de absorver los conocimientos que las nuevas tecnologías proporcionan, adaptarlos a la situación tecnológica y al contexto social del país para generar productos que resuelvan necesidades locales. Para satisfacer una necesidad de la sociedad es necesario conocer la dinámica empresarial, los principios que la rigen y como se debe actuar en una empresa de cualquier tipo y tamaño.
|
||||
|
||||
\subsection{Implementació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ículo de las asignaturas del área de electrónica digital. En primer lugar se encuentran los resultados esperados del proceso de aprendizaje, esto es, Qué 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á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ó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ó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ón e Identificación de las Habilidades CDIO}
|
||||
|
||||
El primer paso en la implementación del plan de estudios CDIO es definir e identificar las habilidades requeridas en una determinada área del plan de estudios, este estudio se centrará en las asignaturas del área de electrónica digital. En la Universidad Nacional de Colombia el área de Electrónica Digital esta compuesta por tres asignaturas para la carrera de Ingeniería Electrónica: Electrónica Digital 1, Electrónica Digital 2 y Sistemas Embebidos. Para la carrera de Ingeniería Eléctrica está compuesta por Electrónica Digital 1 (la misma en las dos carreras) únicamente.
|
||||
|
||||
|
||||
\subsection{Introducir, Enseñ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émico contribuya a generar una determinada habilidad, lo que requiere un consenso del personal académico. En el Departamento de Ingeniería Eléctrica y Electrónica de la Universidad Nacional de Colombia se está 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úa.
|
||||
\item Enseñar: Enseña y evalúa.
|
||||
\item Utilizar: Utiliza, puede ser evaluado o no.
|
||||
\end{enumerate}
|
||||
|
||||
|
||||
\subsection{Habilidades CDIO}
|
||||
A continuación se listan las habilidades CDIO que deben desarrollarse o reforzarse en el área de Electrónica Digital, algunas de las habilidades como la comunicación oral y escrita en Inglés es común a la mayoría de las asignaturas, mientras que otras como la Integració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;ítico y Resolución de problemas
|
||||
\begin{enumerate}
|
||||
\item Identificación y Formulación del problema
|
||||
\item Modelamiento
|
||||
\item Solución y recomendación
|
||||
\end{enumerate}
|
||||
\item Experimentación Investigación y Descubrimiento de Conocimiento
|
||||
\begin{enumerate}
|
||||
\item Formulación de hipótesis
|
||||
\item Investigación experimental
|
||||
\end{enumerate}
|
||||
\item Pensamiento Sistemático
|
||||
\begin{enumerate}
|
||||
\item Pensamiento Global
|
||||
\item Surgimiento e interacciones
|
||||
\end{enumerate}
|
||||
\item Pensamiento Crítico y Creativo y Habilidades y actitudes personales
|
||||
\begin{enumerate}
|
||||
\item Pensamiento creativo
|
||||
\item Pensamiento crítico
|
||||
\item Toma de conciencia de conocimientos propios y metaconocimiento.
|
||||
\item Aprendizaje permanente y Educar a otros.
|
||||
\end{enumerate}
|
||||
\item Ética, Responsabilidad Profesional, Equidad y Otros Valores Personales.
|
||||
\begin{enumerate}
|
||||
\item É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ó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ón
|
||||
\item Estructura de la comunicación
|
||||
\item Comunicación Escrita
|
||||
\item Comunicación Electrónica
|
||||
\item Presentación Oral
|
||||
\end{enumerate}
|
||||
\item Comunicación en Idioma Extranjero
|
||||
\begin{enumerate}
|
||||
\item Inglés
|
||||
\end{enumerate}
|
||||
\item Comunicaciones Informales: Relacionarse con los demás
|
||||
\begin{enumerate}
|
||||
\item Preguntar, Escuchar y Dialogar
|
||||
\item Negociación, compromiso y resolución de conflictos.
|
||||
\item Establecimiento de conexiones
|
||||
\end{enumerate}
|
||||
\end{enumerate}
|
||||
|
||||
% CDIO NIVEL 4
|
||||
\item \textbf{Concebir, Diseñar, Implementar y Operar Sistemas en el Contexto Social y Empresarial}
|
||||
\begin{enumerate}
|
||||
\item Contexto Externo, Social, Econó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íritu Empresarial Técnico
|
||||
\item Trabajo en organizaciones
|
||||
\item Finanzas y Economís de los Proyectos de Ingeniería
|
||||
\end{enumerate}
|
||||
\item Concepción y Administración de Sistemas en Ingeniería.
|
||||
\begin{enumerate}
|
||||
\item Entender las necesidades y establecer las metas
|
||||
\item Definir la función, concepto y arquitectura
|
||||
\end{enumerate}
|
||||
\item Diseño
|
||||
\begin{enumerate}
|
||||
\item Proceso de Diseño
|
||||
\item Fases del proceso de Diseño y enfoques
|
||||
\item Utilización de conocimiento científico en el diseño
|
||||
\item Diseño específico
|
||||
\item Diseño multi-disciplinario
|
||||
\end{enumerate}
|
||||
\item Implementación
|
||||
\begin{enumerate}
|
||||
\item Proceso de fabricación Hardware
|
||||
\item Proceso de Implementación de Software
|
||||
\item Integración Software - Hardware
|
||||
\item Pruebas, verificación, validación y certificación
|
||||
\end{enumerate}
|
||||
\item Liderar Esfuerzos en ingeniería
|
||||
\begin{enumerate}
|
||||
\item Pensar creativamente e Imaginar posibilidades
|
||||
\item Definir la solución
|
||||
\item Crear nuevas formas de solución
|
||||
\item Construir y liderar una organización y una organización extendida.
|
||||
\item Planear y administrar un prpyecto hasta su finalización.
|
||||
\item Innovar - la concepción, diseño e introducció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ía
|
||||
\begin{enumerate}
|
||||
\item Creación, Formulación y organización de una empresa.
|
||||
\item Desarrollo del plan de negocios.
|
||||
\item Finanzas y capitalización.
|
||||
\item Mercadeo de productos innovadores
|
||||
\item Cencepción de productos y servicios alrededor de nuevas tecnologías.
|
||||
\item Sistema de innovación, redes, infraestructura y servicios.
|
||||
\item Construyendo el equipo e iniciando el proceso de ingenierí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 área de Electró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ón de problemas de Ingeniería}} & \multicolumn{3}{c|} {EU} \\ \hline
|
||||
1 Identificación y Formulación del problema & \multicolumn{3}{c|} {EU} \\ \hline
|
||||
2 Modelamiento & \multicolumn{3}{c|} {EU} \\ \hline
|
||||
3 Solución y recomendación & \multicolumn{3}{c|} {EU} \\ \hline
|
||||
\textbf{\textit{Experimentación y Descubrimiento de Conocimiento}} & \multicolumn{3}{c|} {U} \\ \hline
|
||||
4 Formulación de hipótesis & \multicolumn{3}{c|} {U} \\ \hline
|
||||
5 Investigación experimental & \multicolumn{3}{c|} {U} \\ \hline
|
||||
\textbf{\textit{Pensamiento Sistemá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í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 É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ón & EU & U & U \\ \hline
|
||||
17 Estructura de la comunicación & EU & U & U \\ \hline
|
||||
18 Comunicación Escrita & EU & U & U \\ \hline
|
||||
19 Comunicación Electrónica & EU & U & U \\ \hline
|
||||
20 Presentación Oral & EU & U & U \\ \hline
|
||||
\textbf{\textit{Comunicación en Idioma Extranjero}} & \multicolumn{3}{c|} {U} \\ \hline
|
||||
21 Inglés & \multicolumn{3}{c|} {U} \\ \hline
|
||||
\textbf{\textit{Comunicaciones Informales: Relacionarse con los demás}} & \multicolumn{3}{c|} {U} \\ \hline
|
||||
41 Preguntar, Escuchar y Dialogar & EU & U & U \\ \hline
|
||||
42 Negociación, compromiso y resolució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ó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ón} de las tres asignaturas del área de Electró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ó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íritu Empresarial Técnico & \multicolumn{3}{c|} {I} \\ \hline
|
||||
27 Trabajo exitoso en organizaciones & \multicolumn{3}{c|} {I} \\ \hline
|
||||
45 Finanzas y Economía de los Proyectos de Ingeniería & IE & IE & IE \\ \hline
|
||||
\textbf{\textit{Concepción y Administración de Sistemas en Ingeniería.}} & \multicolumn{3}{c|} {IEU} \\ \hline
|
||||
28 Entender las necesidades y establecer las metas & IEU & EU & U \\ \hline
|
||||
29 Definir la función, concepto y arquitectura & IEU & EU & U \\ \hline
|
||||
\textbf{\textit{Diseño}} & \multicolumn{3}{c|} {IEU} \\ \hline
|
||||
30 Proceso de Diseño & IEU & EU & U \\ \hline
|
||||
31 Fases del proceso de Diseño y enfoques & IEU & EU & U \\ \hline
|
||||
32 Utilización de conocimiento científico en el diseño & IEU & EU & U \\ \hline
|
||||
33 Diseño específico & IEU & EU & U \\ \hline
|
||||
34 Diseño multi-disciplinario & I & E & U \\ \hline
|
||||
\textbf{\textit{Implementación}} & \multicolumn{3}{c|} {EU} \\ \hline
|
||||
35 Proceso de fabricación Hardware & IE & EU & U \\ \hline
|
||||
36 Proceso de Implementación de Software & I & EU & U \\ \hline
|
||||
37 Integración Software - Hardware & I & EU & U \\ \hline
|
||||
38 Pruebas, verificación, validación y certificación & IE & EU & U \\ \hline
|
||||
\end{tabular}
|
||||
\caption{Competencias para CDIO} \label{compet_4}
|
||||
\end{table}
|
||||
\end{center}
|
||||
|
||||
|
||||
\section{Integración de las Habilidades CDIO al Plan de Estudios}
|
||||
|
||||
\subsection{Objetivo General}
|
||||
Generar en el estudiante las habilidades necesarias para Concebir, Diseñar, Implementar y Operar Sistemas Digitales complejos que satisfagan necesidades de la sociedad y proporcionar un canal para la transferencia de Tecnología y conocimiento a la Industria Colombiana. La Figura \ref{design_method} muestra la metodología de diseño para las diferentes asignaturas del área.
|
||||
|
||||
\begin{figure}[H]
|
||||
\begin{center} \includegraphics[scale=.8]{./images/habilidades_digitales.png} \end{center}
|
||||
\caption{Metodología de Diseño para el área de Sistemas Digitales} \label{design_method}
|
||||
\end{figure}
|
||||
|
||||
\subsubsection{Electrónica Digital 1}
|
||||
Concebir y definir las especificaciones y requerimientos de un Sistema Digital, modelar su funcionamiento, y realizar la implementación siguiendo la metodología de diseño de Sistemas Embebidos utilizando únicamente tareas Hardware.
|
||||
|
||||
\subsubsection{Electrónica Digital 2}
|
||||
Concebir, definir las especificaciones, modelar, diseñar un Sistema Digital siguiendo la metodología de diseño de Sistemas Embebidos y realizar su implementación óptima utilizando tareas Hardware (que se ejecutan en un PLD) y tareas Software (que se ejecutan en un procesador).
|
||||
|
||||
\subsubsection{Sistemas Embebidos}
|
||||
Concebir, diseñar, e Implementar un sistema digital complejo utilizando la metodología de diseño de sistemas Embebidos y un Sistema Operativo para su Implementación.
|
||||
|
||||
|
||||
\subsection{Objetivos Específicos}
|
||||
|
||||
\subsection {Ojbetivos comúnes}
|
||||
\begin{itemize}
|
||||
\item Identificar las especificaciones funcionales del sistema, su arquitectura de alto nivel y definir su descomposición en elementos
|
||||
\item Explicar las actividades en las etapas del proceso de diseño,
|
||||
\item Desarrollar el pensamiento sistémico.
|
||||
\item Modelar funcionalmente Sistemas Digitales.
|
||||
\item Diseñar pruebas para comprobar el correcto funcionamiento de los sistemas implementados.
|
||||
\item Leer y entender material técnico escrito en inglé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ón de código.
|
||||
\item Desarrollar trabajo en equipo incluyendo presentaciones, describiendo los diversos roles y responsabilidades.
|
||||
\item Documentar los diseños realizados para crear una base de datos que contribuya a la difusión del conocimiento adquirido.
|
||||
\end{itemize}
|
||||
|
||||
\subsubsection{Electrónica Digital 1}
|
||||
\begin{itemize}
|
||||
\item Estudiar las fases de la metodología de diseño para Sistemas Embebidos.
|
||||
\item Estudiar los dominios de diseño Estructural, Funcional y Físico.
|
||||
\item Estudiar los Lenguajes de Descripción de Hardware.
|
||||
\item Estudiar los componentes básicos de la lógica combinatoria y secuencial.
|
||||
\end{itemize}
|
||||
|
||||
\subsubsection{Electrónica Digital 2}
|
||||
\begin{itemize}
|
||||
\item Estudiar los requisitos para un particionamiento Hardware / Software óptimo.
|
||||
\item Estudiar la arquitectura de un procesador, micro-arquitectura, set de instrucciones, interrupciones, direccionamiento.
|
||||
\item Estudiar el proceso de implementación de tareas software.
|
||||
\item Estudiar la integración Software-Hardware.
|
||||
\item Diseñar pruebas para comprobar el correcto funcionamiento de los sistemas implementados.
|
||||
\end{itemize}
|
||||
|
||||
\subsubsection{Sistemas Embebidos}
|
||||
\begin{itemize}
|
||||
\item Realizar aplicaciones que requieran diseño multi-disciplinario.
|
||||
\item Estudiar y realizar el proceso de Fabricación Hardware.
|
||||
\item Estudiar el principio básico de los sistemas operativos.
|
||||
\item Describir la integración de software en hardware electrónico
|
||||
\item Entender diagramas de circuitos electrónicos de sistemas digitales, identifcar sus componentes y su función.
|
||||
\item Estudiar diseños software y hardware existentes para entender su funcionamiento, arquitectura y adquirir experiencia en el diseño.
|
||||
\item Hacer parte de listas de discusión de temas técnicos que usen el inglés como lenguaje.
|
||||
\end{itemize}
|
||||
|
||||
\subsection{Contenido}
|
||||
|
||||
\subsubsection{Electrónica Digital 1}
|
||||
\begin{itemize}
|
||||
\item \textbf{Flujo de Diseño de Sistemas Embebidos}
|
||||
\begin{itemize}
|
||||
\item Sistemas Digitales: Panorama Y Perspectiva
|
||||
\item Metodología de Diseño
|
||||
\item Representaciones de Diseño y Niveles de Abstracción
|
||||
\end{itemize}
|
||||
\item \textbf{Sistemas Numéricos y Operaciones Aritméticas}
|
||||
\begin{itemize}
|
||||
\item Representación de Datos
|
||||
\item Sistemas numéricos: Binario, Octal Hexadecimal
|
||||
\item Representación de números negativos
|
||||
\item Algoritmos para la implementación de operaciones aritméticas
|
||||
\begin{itemize}
|
||||
\item Camino de Datos
|
||||
\item Control
|
||||
\end{itemize}
|
||||
\end{itemize}
|
||||
\item \textbf{Lógica Combinatoria}
|
||||
\begin{itemize}
|
||||
\item Definición.
|
||||
\item Ecuaciones Booleanas, Formas canónicas.
|
||||
\item Módulos Básicos: Multiplexores, codificadores, sumadores, restadores comparadores.
|
||||
\end{itemize}
|
||||
\item \textbf{Lógica Secuencial}
|
||||
\begin{itemize}
|
||||
\item Definició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ítmicas (ASM)
|
||||
\begin{itemize}
|
||||
\item Tareas Hardware
|
||||
\item Componentes: Camino de Datos y Máquina de Control
|
||||
\item Implementación de operaciones aritméticas utilizando ASM
|
||||
\item Identificación, funcionamiento e interfaz de bloques constructores.
|
||||
\item Interacción entre el Camino de Datos y la Máquina de Control
|
||||
\item Lenguajes de Descripción de Hardware
|
||||
\end{itemize}
|
||||
\end{itemize}
|
||||
\item \textbf{Tecnologías de Implementació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ño - Programación en Sistema
|
||||
\end{itemize}
|
||||
\end{itemize}
|
||||
\item \textbf{Introducción a los procesadores}
|
||||
\begin{itemize}
|
||||
\item Máquina de Estados Algorítmica Programable
|
||||
\end{itemize}
|
||||
\end{itemize}
|
||||
|
||||
|
||||
\subsubsection{Electrónica Digital 2}
|
||||
|
||||
\begin{itemize}
|
||||
\item \textbf{Codiseño Hardware-Software}
|
||||
\begin{itemize}
|
||||
\item Flujo de Diseño y Particionamiento HW/SW.
|
||||
\item Comunicación SW -> HW (Direccionamiento)
|
||||
\item Comunicación HW -> SW (Interrupciones)
|
||||
\item Componentes de un Sistema etherogéneo.
|
||||
\begin{itemize}
|
||||
\item Procesador
|
||||
\item Buses
|
||||
\item Perifé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éricos
|
||||
\item Mapa de Memoria
|
||||
\item Controlador de Interrupciones Programable
|
||||
\end{itemize}
|
||||
\item Definición de la Interfaz HS <-> SW
|
||||
\item Implementación de Tareas Hardware en Periféricos.
|
||||
\end{itemize}
|
||||
|
||||
\item \textbf{Flujo de Diseño Software}
|
||||
\begin{itemize}
|
||||
\item Cadena de Herramientas:
|
||||
\begin{itemize}
|
||||
\item Compilador
|
||||
\item Librerías standard
|
||||
\item Depurador
|
||||
\item Utilidades binarias
|
||||
\item Código de Inicio C RunTime crt0
|
||||
\item Herramienta \textit{make}
|
||||
\end{itemize}
|
||||
\item Integración del Software sobre hardware Electrónico.
|
||||
\begin{itemize}
|
||||
\item Ejecución en Memoria Interna
|
||||
\item Ejecución en Memoria Externa: Bootloaders
|
||||
\end{itemize}
|
||||
\item Implementación de tareas software y comunicació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ón,aplicaciones
|
||||
\item Metodología de Diseño
|
||||
\item Arquitectura
|
||||
\begin{itemize}
|
||||
\item Sistema Sobre Silicio
|
||||
\item Circuitos de Referencia
|
||||
\end{itemize}
|
||||
\end{itemize}
|
||||
\item Iniclialización
|
||||
\begin{itemize}
|
||||
\item Métodos de arranque
|
||||
\item Bootloaders
|
||||
\end{itemize}
|
||||
\item \textbf{Sistema Operativo Linux}
|
||||
\begin{itemize}
|
||||
\item Arquitectura
|
||||
\item Sincronización entre procesos
|
||||
\item Estructura del Kernel y Organización del código fuente
|
||||
\item Drivers de Dispositivos y módulos del kernel
|
||||
\item Imágen del kernel
|
||||
\item Inicializació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ón y niveles de ejecució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ñales de Entrada/Salida de propó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éricos Dedicados Implementados en PLDs}
|
||||
\begin{itemize}
|
||||
\item Configuración del PLD utilizando GPIOs del SoC
|
||||
\item Definición de la Interfaz HW y SW
|
||||
\item Comunicación con periféricos dedicados
|
||||
\end{itemize}
|
||||
\end{itemize}
|
||||
|
||||
\subsection{Metodología}
|
||||
Todas las actividades que se realizarán en estos cursos están encamindas a generar habilidades necesarias para Concebir, Diseñar, e Implementar Sistemas Digitales Complejos, y están articuladas alrededor de una única metodología de diseño (la aceptada internacionalmente para el diseño de sistemas embebidos). Los tres cursos se diferencian en el medio donde se realiza la implementación de las tareas y el tipo de las mismas, en el primer curso todas las tareas son Hardware y se implementarán en un PLD, en el segundo las tareas son de tipo hardware y software y serán implementadas en un PLD. El tercer curso tambié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á la base del siguiente curso.
|
||||
|
||||
Los tres cursos tienen un carácter teórico-práctico, el componente teórico tratará los diferentes temas de forma general, con el fín de no crear dependencia con las herramientas utilizadas (lo que permitirá realizar actualizaciónes de forma fácil). En el componente práctico se tratarán temas específicos de manejo de las herramientas (Lenguajes de Descripción de Hardware, lenguajes de programación, manejo de plataformas de desarrollo) y como estas se relacionan con la metodología de diseño utilizada.
|
||||
|
||||
El estudiante debe estudiar, profundizar y comprobar algunos temas tratados en clase y debe leer previamente la documentació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á para definir las especificaciones, diseñar e implementar un dispositivo que resuelva una determinada necesidad (con la complejidad adecuada para cada curso), en la sesión teórica se tratarán aspectos relacionados con la concepción, diseño, Identificación y definición de las funciones de los componentes del sistma, mientras que en los relacionados con la implementació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ón y somo se resolvieron los problemas encontrados, todo este proceso debe documentarse en el sitio web del curso.
|
||||
|
||||
El laboratorio está relacionado con la práctica y proporciona el conocimiento y habilidades para manejar y entender las herramientas Hardware y Software utilizadas en la implementación. Las actividades programadas, deben ser entregadas con un informe donde se evidencie el uso de la metodología de diseño utilizada, adicionalmente el estudiante debe defender y explicar su diseño.
|
||||
|
||||
Se utilizarán los siguientes métodos de calificación:
|
||||
\begin{itemize}
|
||||
\item Pruebas escritas donde se verificará la asimiliación de conocimiento.
|
||||
\item Sustentación oral de procesos de diseño e Implementación.
|
||||
\item Evaluación del avance del proceso de Concepción, Diseño e Implementació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ón que necesita para resolver un problema o tomar una decisión.
|
||||
|
||||
\subsubsection{Lectura de material Técnico en Inglés 10, 11, 6, 30, 33, 21}
|
||||
La mayor parte de la documentación de los componentes electrónicos esta escrita en inglé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és 21.
|
||||
|
||||
\subsubsection{Utilización de Metodologías de Diseño 1, 2, 3, 6, 7, 9, 28, 29, 30, 31, 32, 33, 34, 35, 36, 37, 38}
|
||||
|
||||
La metodología de diseño(30,31,) de sistemas embebidos requiere identificar un problema(1, 28), plantear una solució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 óptima (particionamiento HW/SW) y definir la función e interacción(37,7) de sus componentes software (36) y hardware (35).
|
||||
|
||||
\subsubsection{Implementación de Sistemas Digitales Sencillos 3, 14, 29, 30, 35, 36, 17, 18, 19}
|
||||
|
||||
La realización de prácticas de laboratorio en las que grupos de trabajo (14) implementan diseñ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ón de tareas HW y SW a bajo nivel (36). Con el fin de mejorar la capacidad de comunicación escrita (18, 19) se deben presentar informes que refuercen las habilidades generadas en la utilización de la metodología de diseñ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ón de alto nivel del algoritmo que implementa la solución (29).
|
||||
\item Un diagrama de bloques que indique el particionamiento y la interconexión entre sus componentes (30).
|
||||
\item Descripciones de alto nivel de cada uno de los componentes (31).
|
||||
\item La implementación y simulació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á para definir las especificaciones(1,2,3), diseñar(30,31,32,33,34) e implementar un dispositivo que resuelva una hipotética necesidad de la sociedad (22) (con la complejidad adecuada para cada curso), en la sesión teórica se tratarán aspectos relacionados con la concepción, diseño, Identificación y definición de las funciones de los componentes del sistema, mientras que en el componente práctico, los relacionados con la implementación de dichos componentes sobre PLDs o SoC.
|
||||
|
||||
A los estudiantes se les hace una descripción funcional de alto nivel del sistema, ellos deben organizarse en grupos de trabajo (14,15), definir la función de cada uno de estos grupos (27,14,31), establecer estrategias de comunicació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ón es la realización de presentaciones orales (20), en las que cada equipo de trabajo expondrá el estado de su sub-proyecto, indicando las razones que se tuvieron en cuenta en cada decisió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ñar y construir placas de circuito impreso con los circuitos necesarios para su aplicación (35) siguiendo las normas de diseño establecidas por el fabricante (resolución, número de capas, costo) y las restricciones del circuito (Capacidad de corriente, niveles de ruido, compatibilidad electromagné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ón de tareas, generación de un cronograma de actividades y fijar la estrategia de comunicación, razón por la cual el docente debe acompañar este proceso.
|
||||
|
||||
\subsubsection{Participación en listas de discución 21}
|
||||
Con el objeto de aumentar las capacidades en la comunicación en idioma extranjero, se alentará a los estudiantes a que hagan parte de listas de discusión en diferentes temas técnicos, algunos problemas que encontrarán en la realización de las diferentes prácticas deben ser consultados en estas listas para encontrar una forma de solución
|
||||
|
||||
|
||||
\subsection{Plataforma de Desarrollo SAKC}
|
||||
|
||||
La plataforma SAKC fué diseñada para ser utilizada como herramienta de implementación para los tres cursos de esta área. Está compuesta (ver Figura \ref{sakc_block}) por una FPGA y un Procesador, lo que permite la implementación de tareas Hardware y Software utilizando ú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á 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ón de estos y a construir circuitos que permitan la conexió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ón de procesadores soft-core (como plasma y microblaze), posibilitando la implementación de tareas Hadware y software en ella. El procesador será utilizado al finalizar el curso para comparar el desempeño (velocidad, consumo de potencia, costo) entre un procesador soft-core y un procesador comercial.
|
||||
|
||||
El ultimo curso utilizará el procesador para la ejecución de tareas software y la FPGA para ejecutar las tareas Software, se hará uso de herramientas utilizadas actualmente en el diseñ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ún y se debe garantizar el acceso a todo el mundo. Por esta razón SAKC proporciona la documentación necesaria para:
|
||||
|
||||
\begin{itemize}
|
||||
\item Estudiar. entender, y reproducir o modificar su Arquitectura.
|
||||
\item Conocer su proceso de fabricación.
|
||||
\item Entender su funcionamiento global y la interacción de sus componentes.
|
||||
\item Estudiar tutoriales que explican su programació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ón y crear nueva información.
|
||||
\end{itemize}
|
||||
|
||||
SAKC esta distribuido bajo la licencia Creative Commons \textit{(CC) BY - SA}, la que permite la distribución y modificación del diseño (incluso para aplicaciones comerciales), con el único requisito de que los productos derivadas deben tener la misma licencia.
|
||||
|
||||
|
||||
\section{Desarrollo de Métodos de Evaluació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.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
815
course/.docs/book/education.tex.backup
Normal file
815
course/.docs/book/education.tex.backup
Normal file
@ -0,0 +1,815 @@
|
||||
\chapter{Habilidades CDIO}
|
||||
|
||||
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|
||||
%%% INTRODUCCION %%%%%%
|
||||
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|
||||
\section{Introducció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ía, y ha sido adoptada por un creciente número de instiruciones académicas a lo largo del mundo.
|
||||
|
||||
La educación de la ingeniería y las demandas del mundo real están tomando caminos separados, la Iniciativa CDIO es un proyecto mundial que busca desarrollar una nueva visión de la educación en ingeniería. Hacer parte de este esfuerzo mundial nos ayuda a mantener nuestros planes académicos actualizados con los cambios que se realizan en países más industrializados. En este capítulo mostraremos como esta iniciativa se adapta perfectamemente a los cambios que se han inroducido en el área de la electrónica digital en la universidad Nacional de Colombia.
|
||||
|
||||
La Iniciativa CDIO se basa en la suposición que los egresados de los centros de formación en ingeniería deben ser capaces de: Concebir, Diseñar, Implementar y Operar sistemas complejos en un entorno basado en equipos para crear sistemas y productos. En Colombia, la mayoría de los centros de formación solo tienen en cuenta la Concepción y el Diseño, descuidando por completo la Implementación y la Operación de sistemas, esto, impide que se tenga una estrecha relació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ón y operación de nuevos productos y sistemas.
|
||||
\item Educar futuros investigadores para entender la importancia estratégica y el valor de su trabajo.
|
||||
\end{itemize}
|
||||
|
||||
El Departamento de Ingeniería Eléctrica y Electrónica de la Universidad Nacional de Colombia está realizando el trabajo de adaptar la Iniciativa CDIO a su programa académico, esta iniciativa coincidió con el desarrollo de esta investigación. Los objetivos de esta iniciativa se adaptan a los requerimientos que se exige a la plataforma tecnológica de un país para que pueda realizar una adecuada absorción del conocimiento transferido y posteriormente transformar ese conocimiento en nuevos productos adaptados a las necesidades del país.
|
||||
|
||||
Las premisas que capturan la visión, objetivos y fundamentos pedagógicos de la Iniciativa CDIO son:
|
||||
|
||||
\begin{itemize}
|
||||
\item Es posible cumplir las necesidades propias de la profesión mientras al mismo tiempo se realiza el proceso de Concebir, diseñar, implementar y operar sistemas en el contexto de los sistemas de Ingeniería.
|
||||
\item Los resultados de la formació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án en el ejercicio de su profesión.
|
||||
\item La adecuada construcción de esta cadena de actividades tendrán un doble impacto en la formación de los estudiantes, por un lado facilitará el aprendizaje de habilidades críticas e inter-personales y fortalecerá las habilidades de construcción de sistemas, productos y procesos, mientras se mejora el aprendizaje de los conceptos fundamentales.
|
||||
\end{itemize}
|
||||
|
||||
\subsubsection{liderazgo}
|
||||
|
||||
La situación actual por la que atraviesa la Industria electrónica nacional, requiere que los profesionales en el área tengan las capacidades de emprendimiento y liderazgo necesarias para la creación de nuevas empresas o para la creación de nuevos productos, la Figura \ref{cdio_emp_lid} muestra la relació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ú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ños experimentos para obtener informació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ón} Crear una visión para uno mismo y transmitir esta visión a los demás.
|
||||
\item \textit{Realización de la Visión}
|
||||
\end{itemize}
|
||||
|
||||
\subsubsection{Emprendimiento}
|
||||
El concepto clásico de emprendimiento involucra el re-direccionamiento y movilización de capital y recursos humanos para crear una nueva actividad económica. Actualmente, el emprendimiento esta asociado a la creación de une nueva empresa con una nueva línea de negocios. En algunas ocasiones las innovaciones tecnológicas no requieren cambios en el mercado. Cuando la ingeniería es el componente principal del producto, se debe enfatizar en el proceso de diseño y los ingenieros deben entender la relació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ón en la compañia y otras consideraciones de negocios que influyen en el diseño y las estrategias de implementació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áctica. Con el fín de desarrollar sistemas de ingenierí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ó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ñ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ñ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únes a los planes de estudio de las ingenierías modernas y son:
|
||||
|
||||
\begin{enumerate}
|
||||
\item Fundamentos Avanzados de Igeniería.
|
||||
\item Fundamentos del núcleo de Ingeniería.
|
||||
\item Conocimiento científico.
|
||||
\end{enumerate}
|
||||
|
||||
La razó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á este componente ya que para hacerlo es necesario un consenso con las demás carreras de la facultad de Ingenierí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ón de problemas, Descubrimiento de conocimiento y Pensamiento sistémico.
|
||||
\item Actitudes que incluyen integridad y comportamiento profesional así como las necesarias para planear la profesió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ácter, iniciativa, perseverancia, formas de pensar más genéricas como pensamiento crí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íficas de un equipo de trabajo técnico. La comunicación se compone de habilidades para idear estrategias de comunicación y aquellas para utilizar los medios orales, escritos, electrónicos y gráficos y en el caso Colombiano el uso del idioma Inglés. La Figura \ref{cdio_2_3} muestra la relació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ó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ñ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ía Eléctrica y Electrónica sean capaces de absorver los conocimientos que las nuevas tecnologías proporcionan, adaptarlos a la situación tecnológica y al contexto social del país para generar productos que resuelvan necesidades locales. Para satisfacer una necesidad de la sociedad es necesario conocer la dinámica empresarial, los principios que la rigen y como se debe actuar en una empresa de cualquier tipo y tamaño.
|
||||
|
||||
\subsection{Implementació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ículo de las asignaturas del área de electrónica digital. En primer lugar se encuentran los resultados esperados del proceso de aprendizaje, esto es, Qué 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á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ó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ó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ón e Identificación de las Habilidades CDIO}
|
||||
|
||||
El primer paso en la implementación del plan de estudios CDIO es definir e identificar las habilidades requeridas en una determinada área del plan de estudios, este estudio se centrará en las asignaturas del área de electrónica digital. En la Universidad Nacional de Colombia el área de Electrónica Digital esta compuesta por tres asignaturas para la carrera de Ingeniería Electrónica: Electrónica Digital 1, Electrónica Digital 2 y Sistemas Embebidos. Para la carrera de Ingeniería Eléctrica está compuesta por Electrónica Digital 1 (la misma en las dos carreras) únicamente.
|
||||
|
||||
|
||||
\subsection{Introducir, Enseñ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émico contribuya a generar una determinada habilidad, lo que requiere un consenso del personal académico. En el Departamento de Ingeniería Eléctrica y Electrónica de la Universidad Nacional de Colombia se está 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úa.
|
||||
\item Enseñar: Enseña y evalúa.
|
||||
\item Utilizar: Utiliza, puede ser evaluado o no.
|
||||
\end{enumerate}
|
||||
|
||||
|
||||
\subsection{Habilidades CDIO}
|
||||
A continuación se listan las habilidades CDIO que deben desarrollarse o reforzarse en el área de Electrónica Digital, algunas de las habilidades como la comunicación oral y escrita en Inglés es común a la mayoría de las asignaturas, mientras que otras como la Integració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;ítico y Resolución de problemas
|
||||
\begin{enumerate}
|
||||
\item Identificación y Formulación del problema
|
||||
\item Modelamiento
|
||||
\item Solución y recomendación
|
||||
\end{enumerate}
|
||||
\item Experimentación Investigación y Descubrimiento de Conocimiento
|
||||
\begin{enumerate}
|
||||
\item Formulación de hipótesis
|
||||
\item Investigación experimental
|
||||
\end{enumerate}
|
||||
\item Pensamiento Sistemático
|
||||
\begin{enumerate}
|
||||
\item Pensamiento Global
|
||||
\item Surgimiento e interacciones
|
||||
\end{enumerate}
|
||||
\item Pensamiento Crítico y Creativo y Habilidades y actitudes personales
|
||||
\begin{enumerate}
|
||||
\item Pensamiento creativo
|
||||
\item Pensamiento crítico
|
||||
\item Toma de conciencia de conocimientos propios y metaconocimiento.
|
||||
\item Aprendizaje permanente y Educar a otros.
|
||||
\end{enumerate}
|
||||
\item Ética, Responsabilidad Profesional, Equidad y Otros Valores Personales.
|
||||
\begin{enumerate}
|
||||
\item É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ó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ón
|
||||
\item Estructura de la comunicación
|
||||
\item Comunicación Escrita
|
||||
\item Comunicación Electrónica
|
||||
\item Presentación Oral
|
||||
\end{enumerate}
|
||||
\item Comunicación en Idioma Extranjero
|
||||
\begin{enumerate}
|
||||
\item Inglés
|
||||
\end{enumerate}
|
||||
\item Comunicaciones Informales: Relacionarse con los demás
|
||||
\begin{enumerate}
|
||||
\item Preguntar, Escuchar y Dialogar
|
||||
\item Negociación, compromiso y resolución de conflictos.
|
||||
\item Establecimiento de conexiones
|
||||
\end{enumerate}
|
||||
\end{enumerate}
|
||||
|
||||
% CDIO NIVEL 4
|
||||
\item \textbf{Concebir, Diseñar, Implementar y Operar Sistemas en el Contexto Social y Empresarial}
|
||||
\begin{enumerate}
|
||||
\item Contexto Externo, Social, Econó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íritu Empresarial Técnico
|
||||
\item Trabajo en organizaciones
|
||||
\item Finanzas y Economís de los Proyectos de Ingeniería
|
||||
\end{enumerate}
|
||||
\item Concepción y Administración de Sistemas en Ingeniería.
|
||||
\begin{enumerate}
|
||||
\item Entender las necesidades y establecer las metas
|
||||
\item Definir la función, concepto y arquitectura
|
||||
\end{enumerate}
|
||||
\item Diseño
|
||||
\begin{enumerate}
|
||||
\item Proceso de Diseño
|
||||
\item Fases del proceso de Diseño y enfoques
|
||||
\item Utilización de conocimiento científico en el diseño
|
||||
\item Diseño específico
|
||||
\item Diseño multi-disciplinario
|
||||
\end{enumerate}
|
||||
\item Implementación
|
||||
\begin{enumerate}
|
||||
\item Proceso de fabricación Hardware
|
||||
\item Proceso de Implementación de Software
|
||||
\item Integración Software - Hardware
|
||||
\item Pruebas, verificación, validación y certificación
|
||||
\end{enumerate}
|
||||
\item Liderar Esfuerzos en ingeniería
|
||||
\begin{enumerate}
|
||||
\item Pensar creativamente e Imaginar posibilidades
|
||||
\item Definir la solución
|
||||
\item Crear nuevas formas de solución
|
||||
\item Construir y liderar una organización y una organización extendida.
|
||||
\item Planear y administrar un prpyecto hasta su finalización.
|
||||
\item Innovar - la concepción, diseño e introducció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ía
|
||||
\begin{enumerate}
|
||||
\item Creación, Formulación y organización de una empresa.
|
||||
\item Desarrollo del plan de negocios.
|
||||
\item Finanzas y capitalización.
|
||||
\item Mercadeo de productos innovadores
|
||||
\item Cencepción de productos y servicios alrededor de nuevas tecnologías.
|
||||
\item Sistema de innovación, redes, infraestructura y servicios.
|
||||
\item Construyendo el equipo e iniciando el proceso de ingenierí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ónica Digital 1, Electró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ón de problemas de Ingeniería}} & \multicolumn{3}{c|} {EU} \\ \hline
|
||||
1 Identificación y Formulación del problema & \multicolumn{3}{c|} {EU} \\ \hline
|
||||
2 Modelamiento & \multicolumn{3}{c|} {EU} \\ \hline
|
||||
3 Solución y recomendación & \multicolumn{3}{c|} {EU} \\ \hline
|
||||
\textbf{\textit{Experimentación y Descubrimiento de Conocimiento}} & \multicolumn{3}{c|} {U} \\ \hline
|
||||
4 Formulación de hipótesis & \multicolumn{3}{c|} {U} \\ \hline
|
||||
5 Investigación experimental & \multicolumn{3}{c|} {U} \\ \hline
|
||||
\textbf{\textit{Pensamiento Sistemá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í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 É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ón & EU & U & U \\ \hline
|
||||
17 Estructura de la comunicación & EU & U & U \\ \hline
|
||||
18 Comunicación Escrita & EU & U & U \\ \hline
|
||||
19 Comunicación Electrónica & EU & U & U \\ \hline
|
||||
20 Presentación Oral & EU & U & U \\ \hline
|
||||
\textbf{\textit{Comunicación en Idioma Extranjero}} & \multicolumn{3}{c|} {U} \\ \hline
|
||||
21 Inglés & \multicolumn{3}{c|} {U} \\ \hline
|
||||
\textbf{\textit{Comunicaciones Informales: Relacionarse con los demás}} & \multicolumn{3}{c|} {U} \\ \hline
|
||||
41 Preguntar, Escuchar y Dialogar & EU & U & U \\ \hline
|
||||
42 Negociación, compromiso y resolució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ó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ó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íritu Empresarial Técnico & \multicolumn{3}{c|} {I} \\ \hline
|
||||
27 Trabajo exitoso en organizaciones & \multicolumn{3}{c|} {I} \\ \hline
|
||||
45 Finanzas y Economía de los Proyectos de Ingeniería & IE & IE & IE \\ \hline
|
||||
\textbf{\textit{Concepción y Administración de Sistemas en Ingeniería.}} & \multicolumn{3}{c|} {IEU} \\ \hline
|
||||
28 Entender las necesidades y establecer las metas & IEU & EU & U \\ \hline
|
||||
29 Definir la función, concepto y arquitectura & IEU & EU & U \\ \hline
|
||||
\textbf{\textit{Diseño}} & \multicolumn{3}{c|} {IEU} \\ \hline
|
||||
30 Proceso de Diseño & IEU & EU & U \\ \hline
|
||||
31 Fases del proceso de Diseño y enfoques & IEU & EU & U \\ \hline
|
||||
32 Utilización de conocimiento científico en el diseño & IEU & EU & U \\ \hline
|
||||
33 Diseño específico & IEU & EU & U \\ \hline
|
||||
34 Diseño multi-disciplinario & I & E & U \\ \hline
|
||||
\textbf{\textit{Implementación}} & \multicolumn{3}{c|} {EU} \\ \hline
|
||||
35 Proceso de fabricación Hardware & IE & EU & U \\ \hline
|
||||
36 Proceso de Implementación de Software & I & EU & U \\ \hline
|
||||
37 Integración Software - Hardware & I & EU & U \\ \hline
|
||||
38 Pruebas, verificación, validación y certificación & IE & EU & U \\ \hline
|
||||
\end{tabular}
|
||||
\caption{Competencias para el niveles 4 CDIO} \label{compet_2_3}
|
||||
\end{table}
|
||||
\end{center}
|
||||
|
||||
|
||||
\section{Integración de las Habilidades CDIO al Plan de Estudios}
|
||||
|
||||
\subsection{Objetivo General}
|
||||
Generar en el estudiante las habilidades necesarias para Concebir, Diseñar, Implementar y Operar Sistemas Digitales complejos que satisfagan necesidades de la sociedad y proporcionar un canal para la transferencia de Tecnología y conocimiento a la Industria Colombiana. La Figura \ref{design_method} muestra la metodología de diseño para las diferentes asignaturas del área.
|
||||
|
||||
\begin{figure}[ht]
|
||||
\begin{center} \includegraphics[scale=.8]{./images/habilidades_digitales.png} \end{center}
|
||||
\caption{Metodología de Diseño para el área de Sistemas Digitales} \label{design_method}
|
||||
\end{figure}
|
||||
|
||||
\subsubsection{Electrónica Digital 1}
|
||||
Concebir y definir las especificaciones y requerimientos de un Sistema Digital, modelar su funcionamiento, y realizar la implementación siguiendo la metodología de diseño de Sistemas Embebidos utilizando únicamente tareas Hardware.
|
||||
|
||||
\subsubsection{Electrónica Digital 2}
|
||||
Concebir, definir las especificaciones, modelar, diseñar un Sistema Digital siguiendo la metodología de diseño de Sistemas Embebidos y realizar su implementación óptima utilizando tareas Hardware (que se ejecutan en un PLD) y tareas Software (que se ejecutan en un procesador).
|
||||
|
||||
\subsubsection{Sistemas Embebidos}
|
||||
Concebir, diseñar, e Implementar un sistema digital complejo utilizando la metodología de diseño de sistemas Embebidos y un Sistema Operativo para su Implementación.
|
||||
|
||||
|
||||
\subsection{Objetivos Específicos}
|
||||
|
||||
\subsection {Ojbetivos comúnes}
|
||||
\begin{itemize}
|
||||
\item Identificar las especificaciones funcionales del sistema, su arquitectura de alto nivel y definir su descomposición en elementos
|
||||
\item Explicar las actividades en las etapas del proceso de diseño,
|
||||
\item Desarrollar el pensamiento sistémico.
|
||||
\item Modelar funcionalmente Sistemas Digitales.
|
||||
\item Diseñar pruebas para comprobar el correcto funcionamiento de los sistemas implementados.
|
||||
\item Leer y entender material técnico escrito en inglé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ón de código.
|
||||
\item Desarrollar trabajo en equipo incluyendo presentaciones, describiendo los diversos roles y responsabilidades.
|
||||
\item Documentar los diseños realizados para crear una base de datos que contribuya a la difusión del conocimiento adquirido.
|
||||
\end{itemize}
|
||||
|
||||
\subsubsection{Electrónica Digital 1}
|
||||
\begin{itemize}
|
||||
\item Estudiar las fases de la metodología de diseño para Sistemas Embebidos.
|
||||
\item Estudiar los dominios de diseño Estructural, Funcional y Físico.
|
||||
\item Estudiar los Lenguajes de Descripción de Hardware.
|
||||
\item Estudiar los componentes básicos de la lógica combinatoria y secuencial.
|
||||
\end{itemize}
|
||||
|
||||
\subsubsection{Electrónica Digital 2}
|
||||
\begin{itemize}
|
||||
\item Estudiar los requisitos para un particionamiento Hardware / Software óptimo.
|
||||
\item Estudiar la arquitectura de un procesador, micro-arquitectura, set de instrucciones, interrupciones, direccionamiento.
|
||||
\item Estudiar el proceso de implementación de tareas software.
|
||||
\item Estudiar la integración Software-Hardware.
|
||||
\item Diseñar pruebas para comprobar el correcto funcionamiento de los sistemas implementados.
|
||||
\end{itemize}
|
||||
|
||||
\subsubsection{Sistemas Embebidos}
|
||||
\begin{itemize}
|
||||
\item Realizar aplicaciones que requieran diseño multi-disciplinario.
|
||||
\item Estudiar y realizar el proceso de Fabricación Hardware.
|
||||
\item Estudiar el principio básico de los sistemas operativos.
|
||||
\item Describir la integración de software en hardware electrónico
|
||||
\item Entender diagramas de circuitos electrónicos de sistemas digitales, identifcar sus componentes y su función.
|
||||
\item Estudiar diseños software y hardware existentes para entender su funcionamiento, arquitectura y adquirir experiencia en el diseño.
|
||||
\item Hacer parte de listas de discusión de temas técnicos que usen el inglés como lenguaje.
|
||||
\end{itemize}
|
||||
|
||||
\subsection{Contenido}
|
||||
|
||||
\subsubsection{Electrónica Digital 1}
|
||||
\begin{itemize}
|
||||
\item \textbf{Flujo de Diseño de Sistemas Embebidos}
|
||||
\begin{itemize}
|
||||
\item Sistemas Digitales: Panorama Y Perspectiva
|
||||
\item Metodología de Diseño
|
||||
\item Representaciones de Diseño y Niveles de Abstracción
|
||||
\end{itemize}
|
||||
\item \textbf{Sistemas Numéricos y Operaciones Aritméticas}
|
||||
\begin{itemize}
|
||||
\item Representación de Datos
|
||||
\item Sistemas numéricos: Binario, Octal Hexadecimal
|
||||
\item Representación de números negativos
|
||||
\item Algoritmos para la implementación de operaciones aritméticas
|
||||
\begin{itemize}
|
||||
\item Camino de Datos
|
||||
\item Control
|
||||
\end{itemize}
|
||||
\end{itemize}
|
||||
\item \textbf{Lógica Combinatoria}
|
||||
\begin{itemize}
|
||||
\item Definición.
|
||||
\item Ecuaciones Booleanas, Formas canónicas.
|
||||
\item Módulos Básicos: Multiplexores, codificadores, sumadores, restadores comparadores.
|
||||
\end{itemize}
|
||||
\item \textbf{Lógica Secuencial}
|
||||
\begin{itemize}
|
||||
\item Definició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ítmicas (ASM)
|
||||
\begin{itemize}
|
||||
\item Tareas Hardware
|
||||
\item Componentes: Camino de Datos y Máquina de Control
|
||||
\item Implementación de operaciones aritméticas utilizando ASM
|
||||
\item Identificación, funcionamiento e interfaz de bloques constructores.
|
||||
\item Interacción entre el Camino de Datos y la Máquina de Control
|
||||
\item Lenguajes de Descripción de Hardware
|
||||
\end{itemize}
|
||||
\end{itemize}
|
||||
\item \textbf{Tecnologías de Implementació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ño - Programación en Sistema
|
||||
\end{itemize}
|
||||
\end{itemize}
|
||||
\item \textbf{Introducción a los procesadores}
|
||||
\begin{itemize}
|
||||
\item Máquina de Estados Algorítmica Programable
|
||||
\end{itemize}
|
||||
\end{itemize}
|
||||
|
||||
|
||||
\subsubsection{Electrónica Digital 2}
|
||||
|
||||
\begin{itemize}
|
||||
\item \textbf{Codiseño Hardware-Software}
|
||||
\begin{itemize}
|
||||
\item Flujo de Diseño y Particionamiento HW/SW.
|
||||
\item Comunicación SW -> HW (Direccionamiento)
|
||||
\item Comunicación HW -> SW (Interrupciones)
|
||||
\item Componentes de un Sistema etherogéneo.
|
||||
\begin{itemize}
|
||||
\item Procesador
|
||||
\item Buses
|
||||
\item Perifé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éricos
|
||||
\item Mapa de Memoria
|
||||
\item Controlador de Interrupciones Programable
|
||||
\end{itemize}
|
||||
\item Definición de la Interfaz HS <-> SW
|
||||
\item Implementación de Tareas Hardware en Periféricos.
|
||||
\end{itemize}
|
||||
|
||||
\item \textbf{Flujo de Diseño Software}
|
||||
\begin{itemize}
|
||||
\item Cadena de Herramientas:
|
||||
\begin{itemize}
|
||||
\item Compilador
|
||||
\item Librerías standard
|
||||
\item Depurador
|
||||
\item Utilidades binarias
|
||||
\item Código de Inicio C RunTime crt0
|
||||
\item Herramienta \textit{make}
|
||||
\end{itemize}
|
||||
\item Integración del Software sobre hardware Electrónico.
|
||||
\begin{itemize}
|
||||
\item Ejecución en Memoria Interna
|
||||
\item Ejecución en Memoria Externa: Bootloaders
|
||||
\end{itemize}
|
||||
\item Implementación de tareas software y comunicació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ón,aplicaciones
|
||||
\item Metodología de Diseño
|
||||
\item Arquitectura
|
||||
\begin{itemize}
|
||||
\item Sistema Sobre Silicio
|
||||
\item Circuitos de Referencia
|
||||
\end{itemize}
|
||||
\end{itemize}
|
||||
\item Iniclialización
|
||||
\begin{itemize}
|
||||
\item Métodos de arranque
|
||||
\item Bootloaders
|
||||
\end{itemize}
|
||||
\item \textbf{Sistema Operativo Linux}
|
||||
\begin{itemize}
|
||||
\item Arquitectura
|
||||
\item Sincronización entre procesos
|
||||
\item Estructura del Kernel y Organización del código fuente
|
||||
\item Drivers de Dispositivos y módulos del kernel
|
||||
\item Imágen del kernel
|
||||
\item Inicializació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ón y niveles de ejecució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ñales de Entrada/Salida de propó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éricos Dedicados Implementados en PLDs}
|
||||
\begin{itemize}
|
||||
\item Configuración del PLD utilizando GPIOs del SoC
|
||||
\item Definición de la Interfaz HW y SW
|
||||
\item Comunicación con periféricos dedicados
|
||||
\end{itemize}
|
||||
\end{itemize}
|
||||
|
||||
\subsection{Metodología}
|
||||
Todas las actividades que se realizarán en estos cursos están encamindas a generar habilidades necesarias para Concebir, Diseñar, e Implementar Sistemas Digitales Complejos, y están articuladas alrededor de una única metodología de diseño (la aceptada internacionalmente para el diseño de sistemas embebidos). Los tres cursos se diferencian en el medio donde se realiza la implementación de las tareas y el tipo de las mismas, en el primer curso todas las tareas son Hardware y se implementarán en un PLD, en el segundo las tareas son de tipo hardware y software y serán implementadas en un PLD. El tercer curso tambié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á la base del siguiente curso.
|
||||
|
||||
Los tres cursos tienen un carácter teórico-práctico, el componente teórico tratará los diferentes temas de forma general, con el fín de no crear dependencia con las herramientas utilizadas (lo que permitirá realizar actualizaciónes de forma fácil). En el componente práctico se tratarán temas específicos de manejo de las herramientas (Lenguajes de Descripción de Hardware, lenguajes de programación, manejo de plataformas de desarrollo) y como estas se relacionan con la metodología de diseño utilizada.
|
||||
|
||||
El estudiante debe estudiar, profundizar y comprobar algunos temas tratados en clase y debe leer previamente la documentació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á para definir las especificaciones, diseñar e implementar un dispositivo que resuelva una determinada necesidad (con la complejidad adecuada para cada curso), en la sesión teórica se tratarán aspectos relacionados con la concepción, diseño, Identificación y definición de las funciones de los componentes del sistma, mientras que en los relacionados con la implementació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ón y somo se resolvieron los problemas encontrados, todo este proceso debe documentarse en el sitio web del curso.
|
||||
|
||||
El laboratorio está relacionado con la práctica y proporciona el conocimiento y habilidades para manejar y entender las herramientas Hardware y Software utilizadas en la implementación. Las actividades programadas, deben ser entregadas con un informe donde se evidencie el uso de la metodología de diseño utilizada, adicionalmente el estudiante debe defender y explicar su diseño.
|
||||
|
||||
Se utilizarán los siguientes métodos de calificación:
|
||||
\begin{itemize}
|
||||
\item Pruebas escritas donde se verificará la asimiliación de conocimiento.
|
||||
\item Sustentación oral de procesos de diseño e Implementación.
|
||||
\item Evaluación del avance del proceso de Concepción, Diseño e Implementació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ón que necesita para resolver un problema o tomar una decisión.
|
||||
|
||||
\subsubsection{Lectura de material Técnico en Inglés 10, 11, 6, 30, 33, 21}
|
||||
La mayor parte de la documentación de los componentes electrónicos esta escrita en inglé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és 21.
|
||||
|
||||
\subsubsection{Utilización de Metodologías de Diseño 1, 2, 3, 6, 7, 9, 28, 29, 30, 31, 32, 33, 34, 35, 36, 37, 38}
|
||||
|
||||
La metodología de diseño(30,31,) de sistemas embebidos requiere identificar un problema(1, 28), plantear una solució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 óptima (particionamiento HW/SW) y definir la función e interacción(37,7) de sus componentes software (36) y hardware (35).
|
||||
|
||||
\subsubsection{Implementación de Sistemas Digitales Sencillos 3, 14, 29, 30, 35, 36, 17, 18, 19}
|
||||
|
||||
La realización de prácticas de laboratorio en las que grupos de trabajo (14) implementan diseñ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ón de tareas HW y SW a bajo nivel (36). Con el fin de mejorar la capacidad de comunicación escrita (18, 19) se deben presentar informes que refuercen las habilidades generadas en la utilización de la metodología de diseñ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ón de alto nivel del algoritmo que implementa la solución (29).
|
||||
\item Un diagrama de bloques que indique el particionamiento y la interconexión entre sus componentes (30).
|
||||
\item Descripciones de alto nivel de cada uno de los componentes (31).
|
||||
\item La implementación y simulació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á para definir las especificaciones(1,2,3), diseñar(30,31,32,33,34) e implementar un dispositivo que resuelva una hipotética necesidad de la sociedad (22) (con la complejidad adecuada para cada curso), en la sesión teórica se tratarán aspectos relacionados con la concepción, diseño, Identificación y definición de las funciones de los componentes del sistema, mientras que en el componente práctico, los relacionados con la implementación de dichos componentes sobre PLDs o SoC.
|
||||
|
||||
A los estudiantes se les hace una descripción funcional de alto nivel del sistema, ellos deben organizarse en grupos de trabajo (14,15), definir la función de cada uno de estos grupos (27,14,31), establecer estrategias de comunicació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ón es la realización de presentaciones orales (20), en las que cada equipo de trabajo expondrá el estado de su sub-proyecto, indicando las razones que se tuvieron en cuenta en cada decisió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ñar y construir placas de circuito impreso con los circuitos necesarios para su aplicación (35) siguiendo las normas de diseño establecidas por el fabricante (resolución, número de capas, costo) y las restricciones del circuito (Capacidad de corriente, niveles de ruido, compatibilidad electromagné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ón de tareas, generación de un cronograma de actividades y fijar la estrategia de comunicación, razón por la cual el docente debe acompañar este proceso.
|
||||
|
||||
\subsubsection{Participación en listas de discución 21}
|
||||
Con el objeto de aumentar las capacidades en la comunicación en idioma extranjero, se alentará a los estudiantes a que hagan parte de listas de discusión en diferentes temas técnicos, algunos problemas que encontrarán en la realización de las diferentes prácticas deben ser consultados en estas listas para encontrar una forma de solución
|
||||
|
||||
|
||||
\subsection{Plataforma de Desarrollo SAKC}
|
||||
|
||||
La plataforma SAKC fué diseñada para ser utilizada como herramienta de implementación para los tres cursos de esta área. Está compuesta (ver Figura \ref{sakc_block}) por una FPGA y un Procesador, lo que permite la implementación de tareas Hardware y Software utilizando ú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á 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ón de estos y a construir circuitos que permitan la conexió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ón de procesadores soft-core (como plasma y microblaze), posibilitando la implementación de tareas Hadware y software en ella. El procesador será utilizado al finalizar el curso para comparar el desempeño (velocidad, consumo de potencia, costo) entre un procesador soft-core y un procesador comercial.
|
||||
|
||||
El ultimo curso utilizará el procesador para la ejecución de tareas software y la FPGA para ejecutar las tareas Software, se hará uso de herramientas utilizadas actualmente en el diseñ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ún y se debe garantizar el acceso a todo el mundo. Por esta razón SAKC proporciona la documentación necesaria para:
|
||||
|
||||
\begin{itemize}
|
||||
\item Estudiar. entender, y reproducir o modificar su Arquitectura.
|
||||
\item Conocer su proceso de fabricación.
|
||||
\item Entender su funcionamiento global y la interacción de sus componentes.
|
||||
\item Estudiar tutoriales que explican su programació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ón y crear nueva información.
|
||||
\end{itemize}
|
||||
|
||||
SAKC esta distribuido bajo la licencia Creative Commons \textit{(CC) BY - SA}, la que permite la distribución y modificación del diseño (incluso para aplicaciones comerciales), con el único requisito de que los productos derivadas deben tener la misma licencia.
|
||||
|
||||
|
||||
\section{Desarrollo de Métodos de Evaluació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.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
647
course/.docs/book/embedded.tex
Normal file
647
course/.docs/book/embedded.tex
Normal file
@ -0,0 +1,647 @@
|
||||
\chapter{Sistemas Embebidos}
|
||||
\label{ch:embedded}
|
||||
|
||||
\section{Introducción}
|
||||
Uno de los objetivos de este trabajo, es la creación de una plataforma Embebida que permita la apropiación de nuevas herramientas y metodologías de diseño.
|
||||
El mercado de los sistemas embebidos continúa en aumento y su campo de acción se ha extendido en casi todas las actividades humanas.
|
||||
Segú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ón obtenido por la industria de los semiconductores en los \textit{SOC}, la disponibilidad de herramientas software
|
||||
de desarrollo gratuitas (compiladores, simuladores, librerí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ón de estos sistemas.
|
||||
|
||||
Más de un billón de dispositivos embebidos fueron vendidos en el 2004, segú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ón (tales como Ethernet, bluetooth, WiFi, etc); ademá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í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ón de Linux como herramienta de desarrollo esta fuertemente influenciada por su caracter libre, la gran disponibilidad de herramientas de
|
||||
desarrollo, aplicaciones, librerías y la posibilidad de modificar o adaptar código ya existente.
|
||||
|
||||
El corazón de todo sistema embebido es su procesador, en la actualidad existen diversos fabricantes que ponen a disposición de los desarrolladores
|
||||
\textit{System On Chip} (SOC) que incluyen una gran variedad de periféricos que incluyen dispositivos de comunicació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ía de los perifé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ón y contrario a lo que se podría esperar, el costo de este SOC es muy bajo (en comparación con el costo de cada perifé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 últimos
|
||||
los más populares en dispositivos de consumo como PDAs, Routers, teléfonos celulares, consolas de juego portátiles.\ref{cpu_trends}
|
||||
|
||||
\section{Definición}
|
||||
Un Sistema Embebido es un sistema de propósito específico en el cual, el computador es encapsulado completamente por el dispositivo que el controla.
|
||||
A diferencia de los computadores de propósito general, un Sistema Embebido realiza tareas pre-definidas, lo cual permite su optimización, reduciendo
|
||||
el tamaño y costo del producto \cite{Wik}
|
||||
|
||||
\subsection{Características}
|
||||
|
||||
\begin{itemize}
|
||||
\item Los sistemas embebidos son diseñados para una aplicación
|
||||
espec\'{\i}fica, es decir, estos sistemas realizan un grupo de funciones
|
||||
previamente definidasm y una vez el sistema es diseñ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ón con el entorno los ES deben cumplir
|
||||
esctrí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éricos y un componente software (procesador o DSP) capáz de ejecutar software,
|
||||
la parte del procesador está dividida en la CPU (En algunos casos posee una caché) 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ñ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ñías que fabrican procesadores de 32 bits
|
||||
integrados a una gran variedad de periféricos, lo cual simplifica el diseñ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ón es muy popular en los dispositivos de consumo
|
||||
masivo (Reproductores de MP3, consolas de juego, etc), debido a los grandes niveles de producción (del orden de millones de unidades) resulta más económico
|
||||
contar con un dispositivo que integre el mayor número de funcionalidades, esto disminuye el costo de componentes y reduce el á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éricos requerida para una
|
||||
determinada aplicación, o con una funcionalidad específica, es necesario recurrir a la utilización de dispositivos comerciales que implementen dicha
|
||||
operación, en algunas ocaciones el periférico puede relizar funciones poco comúnes y no se proporciona comercialmente, la solución es entonces, implementar estas funcionalidades en una FPGA; también se recomienda la utilización de FPGAs en sistemas que requieren la utilización de la misma funcionalidad un gran número de veces (Puertos seriales, Pines de Entrada/Salida). Esta decisión esta atada al nivel de producció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ón más flexible, pero la de menor desempeño, ya que al utilizar los recursos lógicos de la FPGA para la implementación del procesador (softcore) la longitud de los caminos de interconexión entre los bloques lógicos aumentan el retardo de las señ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ía de Diseño}
|
||||
|
||||
El proceso de diseñ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ñ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ñ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ñ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ñ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ñ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ñ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ó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ón;
|
||||
esta elección se debe a que la mayoría de los productos comerciales utilizan el toolchain de GNU\footnote{http://www.gnu.org} internamente y proporcionan un entorno gráfico para su fácil manejo. Otro factor considerado a la hora de realizar nuestra elección es el económico, ya que la mayorí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ñadores de sistemas embebidos y se encuentra un gran soporte en múltiples foros de discusió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ón de herramientas de desarrollo}\label{tools}
|
||||
\end{figure}
|
||||
|
||||
\subsubsection{GNU binutils\cite{A1}}
|
||||
Son una colecció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ón y un ejecutable, usa la información de depuración en el ejecutabe para determinar que nombre de atchivo y número de lpinea está asociado con la dirección dada.
|
||||
\item \textbf{ar} Esta utilidad crea, modifica y extrae desde ficheros. Un fichero es una colecció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 último paso en la construcció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í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ón sobre archivos tipo objeto.
|
||||
\item \textbf{ranlib} Genera un índice de contenidos de un fichero, y lo almacena en él.
|
||||
\item \textbf{readelf} Interpreta encabezados de un archivo ELF.
|
||||
\item \textbf{size} Lista el tamaño de las secciones y el tamañ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ó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ón, sin embargo, en el presente estudio solo lo utilizaremos como herramienta de compilación para C y C++. Una caracterí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ó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ás, la disponibilidad de librerías de múltiples propó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ón normal del mismo. Además, permite establecer sesiones remotas utilizando el puerto serie o TCP/IP. Aunque GDB no posee una interfaz gráfica, se han desarrollado varios front-ends como DDD o GDB/Insight.
|
||||
|
||||
\subsubsection{Librerías C}
|
||||
Adicionalmente es necesario contar con una librería que proporcione las librerí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ía C oficial del proyecto GNU. Uno de los inconvenientes al trabajar con esta librería en sistemas embebidos es que genera ejecutables de mayor tamaño que los generados a partir de otras librerías, lo cual no la hace muy atractiva para este tipo de aplicaciones.
|
||||
\item \textbf{uClibc\footnote{http://uclibc.org/}} Es una librería diseñada especialmente para sistemas embebidos, es mucho más pequeña que \textbf{glibc}.
|
||||
\item \textbf{newlib\footnote{http://sources.redhat.com/newlib/}} Al igual que \textbf{uClibc}, está diseñ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ón de \textit{libc} optimizada en tamaño, puede ser utilizada para crear ejecutables está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ño software}
|
||||
|
||||
En la figura \ref{toolchain_flow} se ilustra la secuencia de pasos que se realizan desde la creación de un archivo de texto que posee el código fuente de una aplicación hasta su implementación en la tarjeta de desarrollo.
|
||||
|
||||
|
||||
\begin{figure}[h]
|
||||
\begin{center} \includegraphics[scale=.6]{./images/SW_design_flow} \end{center}
|
||||
\caption{Flujo de diseño SW utilizando la cadena de herramientas GNU}\label{toolchain_flow}
|
||||
\end{figure}
|
||||
|
||||
A continuación se realiza una breve descripción de los pasos necesarios para generar un ejecutable para un sistema embebido:
|
||||
|
||||
\begin{enumerate}
|
||||
\item \textbf{Escritura del código fuente:} Creación del código fuente en cualquier editor de archivos de texto.
|
||||
\item \textbf{Compilació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ías la definición de una determinada funció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ías, si una determinada función no es edfinida por ninguna de las librerías pasadas como parámetro al linker, este generará un error y no se generará el ejecutable.
|
||||
\item Se define la posiciónes físicas de las secciones del ejecutable tipo ELF, esto se realiza a través de un link de enlazado el cual define de forma explícita su localización.
|
||||
\end{enumerate}
|
||||
\item \textbf{Extracción del archivo de programación} En algunas aplicaciones es necesario extraer únicamente las secciones que residen en los medios de almacenamiento no volátil y eliminar las demás secciones del ejecutable. Esto se realiza con la herramiento \textit{objcopy}, la cual, permite generar archivos en la mayorí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ón a la memoria de la plataforma de desarrollo:
|
||||
\begin{enumerate}
|
||||
\item Utilizando un \textit{loader}: El \textit{loader} es una aplicación que reside en un medio de almacenamiento no volá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ón de memoria.
|
||||
\end{enumerate}
|
||||
|
||||
\item \textbf{Depuración} Una vez se descarga la aplicació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ó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ó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áctico durante la etapa de desarrollo. Para realizar este proceso de forma automática, se creó 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ón, depuración, o programación, indicados en el archivo \textit{Makefile} o \textit{makefile}. Un ejemplo de este tipo de archivo se muestra a continuació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án utilizadas a lo largo del archivo; en las líneas 7 - 10 se definen las herramientas de compilación a utilizar, especí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á:\\ \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á 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í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ámetros:
|
||||
\begin{itemize}
|
||||
\item \textbf{-e 0}: Punto de entrada , utilice 0 como símbolo para el inicio de ejecució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í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ón necesaria para cargar en una memoria no volátil. Esto se explicará con mayor detalle más adelante.
|
||||
|
||||
\subsubsection{El formato \textbf{ELF}}
|
||||
|
||||
El formato ELF (\textit{Executable and Linkable Format}) Es un stándard para objetos, librerías y ejecutables y es el formato que genera las herramientas GNU. Como puede verse en la figura \ref{elf1} está compuesto por varias secciones (\textit{link view}) o segmentos (\textit{execution view}). Si un programador está interesado en obtener información de secciones sobre tablas de símbolos, código ejecutable específico o información de enlazado dinámico debe utilizar \textit{link view}. Pero si busca información sobre segmentos, como por ejemplo, la localización de los segmentos \textit{text} o \textit{data} debe utilizar \textit{execution view}. El encabezado describe el layout del archivo, proporcionando informació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ón de enlazado dinámico, datos de depuració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ón de la versión.
|
||||
\item \textbf{.data y .data1} Datos inicializados. (RAM)
|
||||
\item \textbf{.debug} Información para depuración simbólica.
|
||||
\item \textbf{.dynamic} Información sobre enlace dinámico
|
||||
\item \textbf{.dynstr} Strings necesarios para el enlacedinámico
|
||||
\item \textbf{.dynsym} Tabla de símbolos utilizada para enlace dinámico.
|
||||
\item \textbf{.fini} Código de terminación de proceso.
|
||||
\item \textbf{.init} Código de inicialización de proceso.
|
||||
\item \textbf{.line} Información de número de línea para depuración simbó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ó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á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ón \textit{.text}, como se dijo anteriormente contiene las instrucciones ejecutables, por esta razón se marca como ejecutable \textit{``X''} en la columna \textit{Flg}. Es posible ver las instrucciones que se ejecutan en esta secció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ó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ón \textit{.data} contiene \'unicamente el valor de inicializaci\'on de la variable \textit{global\_1} (1) y no muestra informació\'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ón \textit{.text} observamos que esta variable es asignada en tiempo de ejecució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ón de esta variable.
|
||||
|
||||
|
||||
La secció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ón \textit{.rodata} mantiene los datos que no cambian durante la ejecución del programa, es decir, de solo lectura, si examinamos esta sección obtenemos:
|
||||
|
||||
\textit{hexdump -C hello.o | grep -i 000000d0} (la sección \textit{.rodata} comienza en la posició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ó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ías necesarias para crear el ejecutable, este \textit{linker} permite definir donde será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ón. A continuació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ón de las memorias de la plataforma, en este ejemplo tenemos una memoria RAM de 64kB que comienza en la posición de memoria 0x00200000 y una memoria flash de 256k que comienza en la posición 0x0. A continuacion se definen las secciones y el lugar donde será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átil la flash. Cuando el sistema sea energizado el procesador ejecutará el código almacenado en su memoria no volátil. Las secciones \textit{.data} (variables inicializadas) y \textit{.bss} (variables no inicializadas) se almacenarán en la memoria volátil RAM, ya que el acceso a las memorias no volátiles son más lentas y tienen ciclos de lectura/escritura finitos.
|
||||
|
||||
En algunos SoCs no se dispone de una memoria no volátil, por lo que es necesario que la aplicación sea cargada por completo en la RAM. Algunos desarrolladores prefieren almacenar y ejecutar sus aplicaciones en las memorias volátiles durante la etapa de desarrollo, debido a que la programación de las memorias no volátiles toman mucho más tiempo. Obviamente una vez finalizada la etapa de desarrollo las aplicaciones deben ser almacenadas en memorias no volátiles.
|
||||
|
||||
\section{Herramientas hardware}
|
||||
En esta subsección se realizará una breve descripción de los dispositivos semiconductores más utilizados para la implementación de dispositivos digitales.
|
||||
|
||||
\subsubsection{SoC}
|
||||
La Figura \ref{at91rm} muestra la arquitectura de un SoC actual, específicamente del AT91RM920 de Atmel. En este diagrama podemos observar el núcleo central un procesador ARM920T de 180MHz y los periféricos asociados a él. En la actualidad podemos encontrar una gran variedad de SoC diseñados para diferentes aplicaciones: Multimedia, Comunicaciones, Asistentes Digitales; los perifé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é uno de los primeros que diseño ATMEL y está enfocado a tareas en las que se requiere una conexión de red. Dentro de los perifé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á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éricos que son indispensables en todo Sistema Embebido, los cuales facilitan la programación de aplicaciones y la depuración de las mismas. A continuación se realizará una descripción de los diferentes periféricos que se encuentran disponibles en este SoC, indicando los que fueron utilizados en la plataforma de desarrollo.
|
||||
|
||||
\subsubsection{Memorias Volátiles}
|
||||
|
||||
Como se estudió anteriormente existen secciones del ejecutable que deben ser almacenadas en memorias volátiles o en memorias no volátiles. Debido a esto la mayoría de los SoC incluyen periféricos dedicados a controlar diferentes tipos de memoria, las memorias volá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á 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ón de lectura es el siguiente: Una posición de memoria se determina colocando la dirección de la fila y la de la columna en las líneas de dirección de fila y columna respectivamente, un tiempo después el dato almacenado aparecerá en el bus de datos. El procesador coloca la dirección de la fila en el bus de direcciones y después activa la señal \textit{RAS} (Row Access Strobe). Después de un retardo de tiempo predeterminado para permitir que el circuito de la SDRAM capture la dirección de la fila, el procesador coloca la dirección de la columna en el bus de direcciones y activa la señ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ón por la cual es necesario recargar estos condensadores perió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ón, solo se recargan los condensadores para mantener la información. El periférico que controla la SDRAM está encargado de garantizar los ciclos de refresco de acuerdo con los requerimientos de la SDRAM \cite{CH06}.
|
||||
|
||||
\subsubsection{Memorias No Volátiles}
|
||||
La memorias no volátiles almacenan por largos períodos de tiempo información necesaria para la operació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ón con los requeridos por las memorias RAM.
|
||||
|
||||
Las memorias NOR poseen buses de datos y direcció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é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ón. Adicionalmente las memorias NAND consumen menos potencia que las memorias NAND, por esta razó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ón. A diferencia de las flash tipo NOR, los dispositivos NAND se acceden de forma serial utilizando interfaces complejas; su operación se asemeja a un disco duro tradicional. Se accede a la información utilizando bloques (más pequeñ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ñarse de forma espontánea durante la operació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ón del sistema de toda la RAM para actualizar esta lista de sectores defectuosos. El algoritmo de ECC (Error-Correcting Code) debe ser capáz de corregir errores tan pequeños como un bit de cada 2048 bits, hasta 22 bits de cada 2048. Este algorítmo es capaz de detectar bloques defectuosos en la fase de programacíón comparando la información almacenada con la que debe ser almacenada (verificación), si encuentra un error marca el bloque como defectuoso y utiliza un bloque sin defactos para almacenar la información.
|
||||
|
||||
La tabla \ref{flash_comp} resume las principales caracterí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ón & Almacenamiento & Almacenamiento & Solo lectura \\ \hline
|
||||
\end{tabular}
|
||||
\caption{Cuadro de comparació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ón con el procesador.
|
||||
|
645
course/.docs/book/embedded.tex.backup
Normal file
645
course/.docs/book/embedded.tex.backup
Normal file
@ -0,0 +1,645 @@
|
||||
\chapter{Sistemas Embebidos}
|
||||
|
||||
\section{Introducción}
|
||||
Uno de los objetivos de este trabajo, es la creación de una plataforma Embebida que permita la apropiación de nuevas herramientas y metodologías de diseño.
|
||||
El mercado de los sistemas embebidos continúa en aumento y su campo de acción se ha extendido en casi todas las actividades humanas.
|
||||
Segú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ón obtenido por la industria de los semiconductores en los \textit{SOC}, la disponibilidad de herramientas software
|
||||
de desarrollo gratuitas (compiladores, simuladores, librerí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ón de estos sistemas.
|
||||
|
||||
Más de un billón de dispositivos embebidos fueron vendidos en el 2004, segú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ón (tales como Ethernet, bluetooth, WiFi, etc); ademá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í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ón de Linux como herramienta de desarrollo esta fuertemente influenciada por su caracter libre, la gran disponibilidad de herramientas de
|
||||
desarrollo, aplicaciones, librerías y la posibilidad de modificar o adaptar código ya existente.
|
||||
|
||||
El corazón de todo sistema embebido es su procesador, en la actualidad existen diversos fabricantes que ponen a disposición de los desarrolladores
|
||||
\textit{System On Chip} (SOC) que incluyen una gran variedad de periféricos que incluyen dispositivos de comunicació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ía de los perifé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ón y contrario a lo que se podría esperar, el costo de este SOC es muy bajo (en comparación con el costo de cada perifé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 últimos
|
||||
los más populares en dispositivos de consumo como PDAs, Routers, teléfonos celulares, consolas de juego portátiles.\ref{cpu_trends}
|
||||
|
||||
\section{Definición}
|
||||
Un Sistema Embebido es un sistema de propósito específico en el cual, el computador es encapsulado completamente por el dispositivo que el controla.
|
||||
A diferencia de los computadores de propósito general, un Sistema Embebido realiza tareas pre-definidas, lo cual permite su optimización, reduciendo
|
||||
el tamaño y costo del producto \cite{Wik}
|
||||
|
||||
\subsection{Características}
|
||||
|
||||
\begin{itemize}
|
||||
\item Los sistemas embebidos son diseñados para una aplicación
|
||||
espec\'{\i}fica, es decir, estos sistemas realizan un grupo de funciones
|
||||
previamente definidasm y una vez el sistema es diseñ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ón con el entorno los ES deben cumplir
|
||||
esctrí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éricos y un componente software (procesador o DSP) capáz de ejecutar software,
|
||||
la parte del procesador está dividida en la CPU (En algunos casos posee una caché) 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ñ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ñías que fabrican procesadores de 32 bits
|
||||
integrados a una gran variedad de periféricos, lo cual simplifica el diseñ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ón es muy popular en los dispositivos de consumo
|
||||
masivo (Reproductores de MP3, consolas de juego, etc), debido a los grandes niveles de producción (del orden de millones de unidades) resulta más económico
|
||||
contar con un dispositivo que integre el mayor número de funcionalidades, esto disminuye el costo de componentes y reduce el á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éricos requerida para una
|
||||
determinada aplicación, o con una funcionalidad específica, es necesario recurrir a la utilización de dispositivos comerciales que implementen dicha
|
||||
operación, en algunas ocaciones el periférico puede relizar funciones poco comúnes y no se proporciona comercialmente, la solución es entonces, implementar estas funcionalidades en una FPGA; también se recomienda la utilización de FPGAs en sistemas que requieren la utilización de la misma funcionalidad un gran número de veces (Puertos seriales, Pines de Entrada/Salida). Esta decisión esta atada al nivel de producció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ón más flexible, pero la de menor desempeño, ya que al utilizar los recursos lógicos de la FPGA para la implementación del procesador (softcore) la longitud de los caminos de interconexión entre los bloques lógicos aumentan el retardo de las señ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ía de Diseño}
|
||||
|
||||
El proceso de diseñ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ñ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ñ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ñ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ñ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ñ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ñ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ó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ón;
|
||||
esta elección se debe a que la mayoría de los productos comerciales utilizan el toolchain de GNU\footnote{http://www.gnu.org} internamente y proporcionan un entorno gráfico para su fácil manejo. Otro factor considerado a la hora de realizar nuestra elección es el económico, ya que la mayorí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ñadores de sistemas embebidos y se encuentra un gran soporte en múltiples foros de discusió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ón de herramientas de desarrollo}\label{tools}
|
||||
\end{figure}
|
||||
|
||||
\subsubsection{GNU binutils\cite{A1}}
|
||||
Son una colecció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ón y un ejecutable, usa la información de depuración en el ejecutabe para determinar que nombre de atchivo y número de lpinea está asociado con la dirección dada.
|
||||
\item \textbf{ar} Esta utilidad crea, modifica y extrae desde ficheros. Un fichero es una colecció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 último paso en la construcció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í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ón sobre archivos tipo objeto.
|
||||
\item \textbf{ranlib} Genera un índice de contenidos de un fichero, y lo almacena en él.
|
||||
\item \textbf{readelf} Interpreta encabezados de un archivo ELF.
|
||||
\item \textbf{size} Lista el tamaño de las secciones y el tamañ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ó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ón, sin embargo, en el presente estudio solo lo utilizaremos como herramienta de compilación para C y C++. Una caracterí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ó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ás, la disponibilidad de librerías de múltiples propó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ón normal del mismo. Además, permite establecer sesiones remotas utilizando el puerto serie o TCP/IP. Aunque GDB no posee una interfaz gráfica, se han desarrollado varios front-ends como DDD o GDB/Insight.
|
||||
|
||||
\subsubsection{Librerías C}
|
||||
Adicionalmente es necesario contar con una librería que proporcione las librerí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ía C oficial del proyecto GNU. Uno de los inconvenientes al trabajar con esta librería en sistemas embebidos es que genera ejecutables de mayor tamaño que los generados a partir de otras librerías, lo cual no la hace muy atractiva para este tipo de aplicaciones.
|
||||
\item \textbf{uClibc\footnote{http://uclibc.org/}} Es una librería diseñada especialmente para sistemas embebidos, es mucho más pequeña que \textbf{glibc}.
|
||||
\item \textbf{newlib\footnote{http://sources.redhat.com/newlib/}} Al igual que \textbf{uClibc}, está diseñ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ón de \textit{libc} optimizada en tamaño, puede ser utilizada para crear ejecutables está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ño software}
|
||||
|
||||
En la figura \ref{toolchain_flow} se ilustra la secuencia de pasos que se realizan desde la creación de un archivo de texto que posee el código fuente de una aplicación hasta su implementación en la tarjeta de desarrollo.
|
||||
|
||||
|
||||
\begin{figure}[h]
|
||||
\begin{center} \includegraphics[scale=.6]{./images/SW_design_flow} \end{center}
|
||||
\caption{Flujo de diseño SW utilizando la cadena de herramientas GNU}\label{toolchain_flow}
|
||||
\end{figure}
|
||||
|
||||
A continuación se realiza una breve descripción de los pasos necesarios para generar un ejecutable para un sistema embebido:
|
||||
|
||||
\begin{enumerate}
|
||||
\item \textbf{Escritura del código fuente:} Creación del código fuente en cualquier editor de archivos de texto.
|
||||
\item \textbf{Compilació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ías la definición de una determinada funció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ías, si una determinada función no es edfinida por ninguna de las librerías pasadas como parámetro al linker, este generará un error y no se generará el ejecutable.
|
||||
\item Se define la posiciónes físicas de las secciones del ejecutable tipo ELF, esto se realiza a través de un link de enlazado el cual define de forma explícita su localización.
|
||||
\end{enumerate}
|
||||
\item \textbf{Extracción del archivo de programación} En algunas aplicaciones es necesario extraer únicamente las secciones que residen en los medios de almacenamiento no volátil y eliminar las demás secciones del ejecutable. Esto se realiza con la herramiento \textit{objcopy}, la cual, permite generar archivos en la mayorí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ón a la memoria de la plataforma de desarrollo:
|
||||
\begin{enumerate}
|
||||
\item Utilizando un \textit{loader}: El \textit{loader} es una aplicación que reside en un medio de almacenamiento no volá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ón de memoria.
|
||||
\end{enumerate}
|
||||
|
||||
\item \textbf{Depuración} Una vez se descarga la aplicació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ó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ó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áctico durante la etapa de desarrollo. Para realizar este proceso de forma automática, se creó 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ón, depuración, o programación, indicados en el archivo \textit{Makefile} o \textit{makefile}. Un ejemplo de este tipo de archivo se muestra a continuació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án utilizadas a lo largo del archivo; en las líneas 7 - 10 se definen las herramientas de compilación a utilizar, especí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á:\\ \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á 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í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ámetros:
|
||||
\begin{itemize}
|
||||
\item \textbf{-e 0}: Punto de entrada , utilice 0 como símbolo para el inicio de ejecució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í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ón necesaria para cargar en una memoria no volátil. Esto se explicará con mayor detalle más adelante.
|
||||
|
||||
\subsubsection{El formato \textbf{ELF}}
|
||||
|
||||
El formato ELF (\textit{Executable and Linkable Format}) Es un stándard para objetos, librerías y ejecutables y es el formato que genera las herramientas GNU. Como puede verse en la figura \ref{elf1} está compuesto por varias secciones (\textit{link view}) o segmentos (\textit{execution view}). Si un programador está interesado en obtener información de secciones sobre tablas de símbolos, código ejecutable específico o información de enlazado dinámico debe utilizar \textit{link view}. Pero si busca información sobre segmentos, como por ejemplo, la localización de los segmentos \textit{text} o \textit{data} debe utilizar \textit{execution view}. El encabezado describe el layout del archivo, proporcionando informació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ón de enlazado dinámico, datos de depuració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ón de la versión.
|
||||
\item \textbf{.data y .data1} Datos inicializados. (RAM)
|
||||
\item \textbf{.debug} Información para depuración simbólica.
|
||||
\item \textbf{.dynamic} Información sobre enlace dinámico
|
||||
\item \textbf{.dynstr} Strings necesarios para el enlacedinámico
|
||||
\item \textbf{.dynsym} Tabla de símbolos utilizada para enlace dinámico.
|
||||
\item \textbf{.fini} Código de terminación de proceso.
|
||||
\item \textbf{.init} Código de inicialización de proceso.
|
||||
\item \textbf{.line} Información de número de línea para depuración simbó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ó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á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ón \textit{.text}, como se dijo anteriormente contiene las instrucciones ejecutables, por esta razón se marca como ejecutable \textit{``X''} en la columna \textit{Flg}. Es posible ver las instrucciones que se ejecutan en esta secció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ó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ón \textit{.data} contiene \'unicamente el valor de inicializaci\'on de la variable \textit{global\_1} (1) y no muestra informació\'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ón \textit{.text} observamos que esta variable es asignada en tiempo de ejecució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ón de esta variable.
|
||||
|
||||
|
||||
La secció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ón \textit{.rodata} mantiene los datos que no cambian durante la ejecución del programa, es decir, de solo lectura, si examinamos esta sección obtenemos:
|
||||
|
||||
\textit{hexdump -C hello.o | grep -i 000000d0} (la sección \textit{.rodata} comienza en la posició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ó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ías necesarias para crear el ejecutable, este \textit{linker} permite definir donde será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ón. A continuació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ón de las memorias de la plataforma, en este ejemplo tenemos una memoria RAM de 64kB que comienza en la posición de memoria 0x00200000 y una memoria flash de 256k que comienza en la posición 0x0. A continuacion se definen las secciones y el lugar donde será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átil la flash. Cuando el sistema sea energizado el procesador ejecutará el código almacenado en su memoria no volátil. Las secciones \textit{.data} (variables inicializadas) y \textit{.bss} (variables no inicializadas) se almacenarán en la memoria volátil RAM, ya que el acceso a las memorias no volátiles son más lentas y tienen ciclos de lectura/escritura finitos.
|
||||
|
||||
En algunos SoCs no se dispone de una memoria no volátil, por lo que es necesario que la aplicación sea cargada por completo en la RAM. Algunos desarrolladores prefieren almacenar y ejecutar sus aplicaciones en las memorias volátiles durante la etapa de desarrollo, debido a que la programación de las memorias no volátiles toman mucho más tiempo. Obviamente una vez finalizada la etapa de desarrollo las aplicaciones deben ser almacenadas en memorias no volátiles.
|
||||
|
||||
\subsection{Herramientas hardware}
|
||||
Como se mencionó 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é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íficamente del AT91RM920 de Atmel. En este diagrama podemos observar el núcleo central un procesador ARM920T de 180MHz y los periféricos asociados a él. En la actualidad podemos encontrar una gran variedad de SoC diseñados para diferentes aplicaciones: Multimedia, Comunicaciones, Asistentes Digitales; los perifé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é uno de los primeros que diseño ATMEL y está enfocado a tareas en las que se requiere una conexión de red. Dentro de los perifé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á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éricos que son indispensables en todo Sistema Embebido, los cuales facilitan la programación de aplicaciones y la depuración de las mismas. A continuación se realizará una descripción de los diferentes periféricos que se encuentran disponibles en este SoC, indicando los que fueron utilizados en la plataforma de desarrollo.
|
||||
|
||||
\subsubsection{Memorias Volátiles}
|
||||
|
||||
Como se estudió anteriormente existen secciones del ejecutable que deben ser almacenadas en memorias volátiles o en memorias no volátiles. Debido a esto la mayoría de los SoC incluyen periféricos dedicados a controlar diferentes tipos de memoria, las memorias volá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á 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ón de lectura es el siguiente: Una posición de memoria se determina colocando la dirección de la fila y la de la columna en las líneas de dirección de fila y columna respectivamente, un tiempo después el dato almacenado aparecerá en el bus de datos. El procesador coloca la dirección de la fila en el bus de direcciones y después activa la señal \textit{RAS} (Row Access Strobe). Después de un retardo de tiempo predeterminado para permitir que el circuito de la SDRAM capture la dirección de la fila, el procesador coloca la dirección de la columna en el bus de direcciones y activa la señ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ón por la cual es necesario recargar estos condensadores perió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ón, solo se recargan los condensadores para mantener la información. El periférico que controla la SDRAM está encargado de garantizar los ciclos de refresco de acuerdo con los requerimientos de la SDRAM \cite{CH06}.
|
||||
|
||||
\subsubsection{Memorias No Volátiles}
|
||||
La memorias no volátiles almacenan por largos períodos de tiempo información necesaria para la operació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ón con los requeridos por las memorias RAM.
|
||||
|
||||
Las memorias NOR poseen buses de datos y direcció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é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ón. Adicionalmente las memorias NAND consumen menos potencia que las memorias NAND, por esta razó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ón. A diferencia de las flash tipo NOR, los dispositivos NAND se acceden de forma serial utilizando interfaces complejas; su operación se asemeja a un disco duro tradicional. Se accede a la información utilizando bloques (más pequeñ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ñarse de forma espontánea durante la operació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ón del sistema de toda la RAM para actualizar esta lista de sectores defectuosos. El algoritmo de ECC (Error-Correcting Code) debe ser capáz de corregir errores tan pequeños como un bit de cada 2048 bits, hasta 22 bits de cada 2048. Este algorítmo es capaz de detectar bloques defectuosos en la fase de programacíón comparando la información almacenada con la que debe ser almacenada (verificación), si encuentra un error marca el bloque como defectuoso y utiliza un bloque sin defactos para almacenar la información.
|
||||
|
||||
La tabla \ref{flash_comp} resume las principales caracterí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ón & Almacenamiento & Almacenamiento & Solo lectura \\ \hline
|
||||
\end{tabular}
|
||||
\caption{Cuadro de comparació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ón con el procesador.
|
471
course/.docs/book/intro.tex
Normal file
471
course/.docs/book/intro.tex
Normal file
@ -0,0 +1,471 @@
|
||||
\chapter{Introdución}
|
||||
|
||||
\section{Visión, Paradigmas, y Dificultades}
|
||||
El gran avance de las técnicas de fabricació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ón actuales
|
||||
permiten construir sistemas cada vez más pequeños, veloces y de menor
|
||||
consumo de potencia, lo cual ha favorecido su difusión. El uso de los sistemas
|
||||
digitales en \'áreas como la aviación, la industria automovil\'{\i}stica, la
|
||||
bioingenier\'{\i}a, etc. demanda de estos un alto desempeñ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ñ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ñ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ño se presentan a medida que los sistemas
|
||||
embebidos se integran a nuestra vida diaria, se hace necesario diseñ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ñ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ñ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ñ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ñ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ñ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ñ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ñ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ñ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ño.
|
||||
\end{itemize}
|
||||
|
||||
El diseño de estos sistemas requiere nuevas fuentes de inspiraci\'on; una
|
||||
direcci\'on promisoria es verlos y diseñ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ño Electrónico en Colombia}
|
||||
|
||||
En la actualidad Colombia atraviesa por una $''$\textit{\textit{crisis}}$''$ a
|
||||
nivel de diseñ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ñ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ñ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ón de Conocimiento}
|
||||
|
||||
Para que Colombia deje de ser un país que consume tecnología y llegue en algún momento a ser generador de productos tecnológicos, es necesario que se genere un conocimiento que permita esta transición. ``Para que el conocimiento sea motor de desarrollo es necesario el traspaso desde sus creadores a la sociedad, mediante la conversión a tecnologías que produzcan cambios radicales que incrementen la producción. Esa transmisión de tecnología generadora de crecimiento económico esta influenciada por diversos factores: medio geográfico, leyes de propiedad industrial, costos laborales, nivel de ciencia y tecnología, religión, tipos de instituciones, resistencia a innovar, políticas de estado, guerras, factores demográficos, entre otros'' \cite{Mok90}
|
||||
|
||||
Pero como apropiar este conocimiento? Arrow \cite{Arr62} afirma que la apropicació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ón, y distribución, mercadeo, servicio y soporte operativo o riesgo compartido. También se presentan alianzas entre firmas como: contratos de I+D, acuerdos de licencias, licencias cruzadas. La conformación de estas asociaciones permite crear redes tecnológicas dominadas por paí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á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ón de empleos especializados, desarrollo tecnológico e industrial sostenido, ampliación del acervo de conocimiento nacional y disminución de la salida de divisas (al mejorar los procesos de negociación) y creación de externalidades positivas \cite{Mar04}.
|
||||
|
||||
Ligado al problema de la senda tecnológica está el del grado de lo tácito del conocimiento científico. Teece \cite{Tee81} señala que al existir conocimiento tácito toda la tecnología disponible no se transfiere de los productores a los receptores o compradores de la misma. Por tanto, los países seguidores siempre van a estar a la zaga tecnológica. Forbes y Wield \cite{FW00} señ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ón y adquisición de tecnología por firmas pequeñas y medianas, las cuales carecen de recursos y tienen procesos deficientes de contratación.
|
||||
|
||||
En este orden de ideas, si el país no es un innovador neto ¿no debería más bien mostrar una tendencia a importar conocimiento? Y las firmas nacionales ¿no deberían ser las que más efectuaran este tipo de contratos, para así acceder al conocimiento de la tecnología adquirida? En resumen, conociendo mejor qué tecnología se importa y qué tipos de contratos se utilizan, es posible crear marcos de referencia para empresas nacionales que estén interesadas en adquirir tecnología. Esto produciría externalidades positivas en empresas importadoras de conocimiento y, a su vez, en la economía del país. Con una adecuada importación de conocimientos tecnológicos se crearía una ventaja competitiva de carácter estructural, basada en un acervo de conocimiento tecnológico que permita incrementar la productividad en todos los sectores económicos de manera permanente \cite{Mar04}.
|
||||
|
||||
Según los estudios realizados por Martínez, con base en registros del Decreto 259/92, del Incomex. La importación de conocimiento no está siendo empleada con el propósito de utilizar tecnologí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ón de tecnologí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ón encaminados a la disminución de la brecha tecnológica.
|
||||
|
||||
|
||||
\subsection{Situación de la Industria Electrónica en Colombia}
|
||||
|
||||
La industria electrónica nacional no es ajena a las políticas que siguen las empresas nacionales en cuanto a la apropiación de tecnología; Colombia depende totalmente de economías más desarrolladas para el suministro de dispositivos electrónicos en diversas areas (comunicaciones, entretenimiento, industria, medicina, etc). Mientras en otros sectores de la economía han pasado de ser consumidores a exportadores, y adquieren nuevas tecnologías para ser más competitivos, el sector electrónico del país ha reducido sus actividades de Investigació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ómicos.
|
||||
|
||||
En la actualidad la industria electrónica presenta una gran dinámica a nivel mundial, el uso de los sistemas electrónicos se extiende a todas las actividades humanas; La demanda mundial de este tipo de sistemas aumentará de forma dramática en los próximos años, especialmente en los sectores de tecnología médica, movilidad, seguridad, comunicaciones y consumo \cite{ETPoSSI(09}. El mercado de los sistemas embebidos es una industria que movió alrededor de 25 billones de dólares en el 2008 según Venture Development Corporation \cite{Vc08}. Por otro lado, la inversión de capital necesaria para el diseño de Sistemas Embebidos es relativamente baja, gracias a la gran demanda originada, los insumos y los servicios de fabricación son muy económicos, las herramientas de desarrollo necesarias para la programación y depuración de este tipo de sistemas son de libre distribución.
|
||||
|
||||
Desafortunadamente en Colombia la industria electrónica se encuentra muy rezagada en relación a las de los países industrializados, y las ventajas y oportunidades de negocios mencionadas anteriormente no son aprovechadas en la actualidad.
|
||||
|
||||
Según ASESEL \footnote{Asociación de entidades del Sector Electrónico} en el 2001 existían 154 empresas productoras de componentes y equipos de la cadena electrónica. Dentro de los productos que la industria electrónica exporta se encuentran registrados: Circuitos integrados, circuitos impresos, microestructuras, instrumentos para medida y control, Instrumentos y aparatos eléctricos o electró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íses desarrollados. Según Proexport el 91\% de las exportaciones son realizadas por Bogotá y los destinos se encuentran en países cercanos como Venezuela, Perú, Ecuador y USA.
|
||||
|
||||
La electró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ón constante de los
|
||||
avances tecnológicos y las proyecciones futuras del sector. Debido a la importancia del sector tecnológico es primordial que en Colombia se esté consciente del estado actual y que se puede hacer en términos de
|
||||
Investigación Científica y Desarrollo Tecnológico (I+D) en Ingeniería Electrónica.
|
||||
|
||||
Un estudio realizado en la Universidad Nacional de Colombia \cite{MTRR07} identificó los siguientes obstáculos para el desarrollo de la industria electrónica en Colombia: Deficientes relaciones Universidad Empresa, Pobre enfoque académico hacia la industria, baja calidad de los productos nacionales, políticas gubernamentales, falta de cultura de Investigación y Reducida apropiación tecnológica, competencia de países asiáticos, atraso tecnológico, limitado recurso humano con formación avanzada.
|
||||
|
||||
De los problemas expuestos anteriormente podemos identificar cuales son los que más afectan el desarrollo de la industria electrónica en Colombia, el que más perjudica sin lugar a dudas es el atraso tecnológico, no es posible ser competitivo en el mercado electrónico mundial con tecnologías y metodologías de diseñ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ón como el \textit{assembler}, para el cual el tiempo de aprendizaje, desarrollo y de depuración es muy largo} La culpa de este atraso tecnoló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í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ógico es el sector académico; Según el Sistema Nacional de Información Superior, durante los últimos 10 años se han abierto 230 programas relacionados con la industria electrónica, estos programas están repartidos entre programas de formación Universitaria, tecnológica terminal y de técnica profesional, la mayoría de estos centros de formación se encuentran ubicados en 3 Departamentos: Bogotá, 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íses en vía de desarrollo y doce veces mayor que los que se gradúan en los países desarrollados. En Colombia, este aumento es aportado por instituciones de poca consolidación; además, las preferencias en la educación superior son Formación técnica / form. tecnológica / form. profesional que es justamente lo opuesto a la de los países desarrollados \cite{MDAG99}.
|
||||
|
||||
Por otro lado, el contenido de las asignaturas relacionadas directamente con la industria electrónica se encuentran muy desactualizados, y fuera del contexto mundial, se utilizan metodologías de diseño antiguas en las que primaba la experiencia del diseñador, se realizan tareas manuales, repetitivas que pueden ser realizadas por herramientas de diseño moderno, los currículos son conservadores hay poca experimentación y su estructuración y metodologías son muy clásicas. Adicionalmente, muchos investigadores dedican sus estudios en proyectos que no aportan al desarrollo del país únicamente porque están de moda. Otro problema adicional radica en la falta de experiencia en el sector productivo por parte del personal acadé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ón de un producto comercial, razón por la cual se evita la experimentación y se da más énfasis al análisis y solo se llega a una simulación.
|
||||
|
||||
De lo anterior podemos concluir que en Colombia se presenta una sobre-oferta de profesionales en el área electrónica, muchos de los cuales provienen de instituciones educativas con poca consolidación, y que han sido formados con programas desactualizados que no tienen en cuenta los avances tecnológicos y metodológicos, lo cual explica la pobreza de ingenieros con altos niveles de formación. Por esta razón no es de extrañar la poca confianza que tienen los industriales en los productos nacionales.
|
||||
|
||||
Lo anterior unido a la falta de políticas de estado que: tracen normas encaminadas a incentivar la inversión en investigación y desarrollo, defina líneas y campos de investigación, regule la oferta laboral y los programas académicos, generan el clima perfecto para que el atraso tecnológico se mantenga durante mucho tiempo y Colombia no deje de ser un consumidor de tecnología. Según John Kao, uno de los grandes expertos del mundo en innovación, los países desarrollados no invierten en Ciencia Tecnología e Innovación (CTI) porque son ricos, sino que son ricos porque invierten en CTI.
|
||||
|
||||
|
||||
\subsubsection{Tecnologías de Información y Comunicación}
|
||||
En la actualidad existe un especial interés por parte del gobierno \footnote{ La Agenda de Conectividad es el programa del Ministerio de Comunicaciones, encargado de impulsar el uso y masificación de las Tecnologías de Información y Comunicación -TIC- como herramienta dinamizadora del desarrollo social y económico del país ()} en impulsar las Tecnologías de la Información y la Comunicació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ía es simplemente la infraestructura, si la infraestructura no está acompañada por la creación de habilidades y conocimiento la adopción de TICs no ayudará a obtener los beneficios que esperamos, sin embargo, ayudará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ón como pricipal herramienta para reducir la \textit{brecha tecnológica} que existe entre las diferentes regiones de nuestro país y de nuestro país con los paises desarrollados.
|
||||
|
||||
Hearn, Simpson, Lennie y Kimber \cite{HSL+04} \cite{MJF05} nombran las siguientes caracterí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ía se vuelva
|
||||
obsoleta y se acabe el proyecto por esta causa.
|
||||
\item Apalancar el desarrollo de la empresa pequeña ayudado por personal y
|
||||
financiació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ón, planeación y
|
||||
evaluación de proyectos. Hemos visto que para que un proyecto de
|
||||
tecnología tenga é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ía de aprendizaje a través de ciclos de evaluación
|
||||
basados en una acción investigativa.
|
||||
|
||||
\end{enumerate}
|
||||
|
||||
Adicionalmente es necesario buscar el bien común por encima del individual, razón por la cual debemos preguntarnos quienes son los favorecidos por la difusión de estas tecnologías, no tiene sentido invertir grandes sumas de dinero para llevar estas tecnologí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ón y sin entrenamiento no se le puede sacar provecho a estas tecnologías. Debemos crear herramientas que integren a nuestros pueblos y que permitan colaborar entre ellas.
|
||||
|
||||
En la actualidad esta polí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ógico del paí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ón. Microsoft utiliza una política de reducción de precios para los centros educativos y algunos centros gubernamentales, esta ``donación'' solo crea dependencia tecnológica y en la mayorí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áctica que se generaliza a todo el software no solo al de Microsoft lo que hace que las empresas medianas y pequeñ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ía de los computadores de una nación se está cediendo la soberanía para el beneficio de un particular foráneo.
|
||||
|
||||
Lo mismo sucede con los equipos que se utilizan para acceder a estas tecnologías, en la mayoría de los casos son fabricados en paises con diferentes culturas y diferentes necesidades. Es obvio que el país no puede fabricar ciertos equipos que se requieren para poder llevar estas tecnologí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ías. De esta forma impulsamos la industra electrónica produciendo de forma masiva un dispositivo electrónico en el pais, diseñado para suplir necesidades de la región. Esta plataforma no solo poroporcionará la base para el desarrollo de las TICs, sino la base tecnoló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ía necesaria para que las universidades y empresas locales sean capaces de desarrollar dispositivos que permitan el acceso a estas tecnologías.
|
||||
|
||||
|
||||
\subsection{Estado de la Electrónica Digital en la Universidad Nacional de Colombia}
|
||||
|
||||
Hasta hace un año en las asignaturas del área de electró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ía no es su año de creación, ni siquiera que en la actualidad se consideren obsoletas para el diseño de un sistema digital completo. \footnote{En la actualidad estas compuertas se utilizan para la implementación de pequeñas operaciones lógicas} El problema detrás del uso de esta tecnología se encuentra en la ausencia total de metodologías de diseño (en el caso Colombiano). Y el desconocimiento en herramientas tipo CAD. El proceso de diseño que realizaban los estudiantes era:
|
||||
|
||||
\begin{enumerate}
|
||||
\item Especificaciones del sistema.
|
||||
\item Generación manual de ecuaciones boolenas.
|
||||
\item Minimización manual utilizando mapas de Karnaugh.
|
||||
\item Implementació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émico se justifica el uso de las familias 7400 y 4000, sin embargo, el quedarse ahi no es bueno para una industria electrónica desactualizada, debido a que este tipo de implementaciones no pueden generar productos competitivos a nivel mundial. La razó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ón de ecuaciones booleanas, las cuales están sujetas a errores humanos originados por cansancio, falta de concentración, etc. Otro aspecto que vale la pena resaltar es la falta de una simulación funcional, la mayoría de los estudiantes consultados no realizaban simulaciones funcionales y preferían probar el diseño una vez implementado físicamente, esto unido a la dificultad de depuración innata a este tipo de implementaciones, aumentaba considerablemente el tiempo requerido para realizar la implementación y pruebas del sistema.
|
||||
|
||||
En el segundo curso del área de electrónica digital, se introduce al estudiante al uso de los dispositivos lógicos programables (PLD) y los lenguajes de descripción de hardware (HDL) como herramientas para el diseño de sistemas digitales, al comienzo, el contenido de estos cursos se limitaba al uso de una herramienta de diseño y la enseñanza de nociones básicas del lenguaje VHDL, se daba más importancia al uso de la herramienta y no a la metodología de diseño, de nuevo el estudiante ataca los problemas sin una metodología de diseño clara. Vale la pena indicar que este curso fue dictado por profesores ocasionales durante los ú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í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ía de diseño en la que los estudiantes emulan el comportamiento del microcontrolador antes de ser programado, sin embargo, esta práctica no es seguida por la mayoría de los estudiantes, una posible causa de este comportamiento puede ser la falta de metodologías de diseño en los cursos anteriores.
|
||||
|
||||
La sensación que queda al terminar el área de electrónica digital es que lo único que importa son los microcontroladores y que lo visto en los primeros cursos no es muy útil. La siguiente tabla muestra los problemas encontrados en el área de electrónica digital de las carreras de Ingeniería Eléctrica y Electrónica de la Universidad Nacional de Colombia:
|
||||
|
||||
\begin{enumerate}
|
||||
\item Falta de una metodología de diseño.
|
||||
\item Utilización de herramientas obsoletas: Familias Lógicas, lenguajes de programació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ón adecuada que ayude a la industria electronica a salir del retraso tecnológico.
|
||||
\end{enumerate}
|
||||
|
||||
|
||||
\section{Descripción de la Tésis}
|
||||
|
||||
\subsection{Objetivos e Hipótesis}
|
||||
|
||||
\subsubsection{Ojetivo Principal}
|
||||
|
||||
Desarrollar una metodología para la transferencia tecnológica y de conocimientos en el área de Sistemas Embebidos.
|
||||
El objetivo de este trabajo es contribuir a dar solución al problema del atraso tecnológico en Colombia, puntualmente en los siguientes puntos:
|
||||
|
||||
\subsubsection{Objetivos Secundarios}
|
||||
|
||||
\begin{itemize}
|
||||
\item Formulación de una metodología para la transferencia tecnológica y de conocimientos en el área de Sistemas Embebidos en Colombia.
|
||||
\item Formulación de una metodología de Diseño y producción para Sistemas Embebidos aplicable en el entorno local.
|
||||
\item Identificación de las habilidades requeridas para los profesionales y técnicos en la Industria Electrónica para estar acorde con la tendencia de la industria electrónica mundial y formulación de recomenadaciones para la industria y los organismos gubernamentales encaminadas a mejora la productividad de la industria electrónica del país.
|
||||
\item Desarrollo de Plataformas Hardware que utilicen tecnología de punta.
|
||||
\item Diseño de los programas de las asignaturas del área de electrónica digital en programas de pregrado para incorporar las nuevas metodologías modernas de diseño y producción.
|
||||
\end{itemize}
|
||||
|
||||
|
||||
|
||||
\subsubsection{Hipótesis}
|
||||
Las recomendaciones dadas por los estudios sobre como solucionar el problema del desarrollo tecnológico, hablan de como se debe trabajar de forma local, teniendo en cuenta la experiencia generada globalmente, Por lo que partiemos de la hipótesis que es posible utilizar técnicas de auto-organización para que diferentes centros de formación y producción distribuidos a lo largo del país encuentren la forma de distribuir de forma eficiente los recursos (Información, conocimiento, recursos económicos) comunes para alcanzar en forma conjunta el objetivo principal: Encontrar políticas de auto-gobierno que permitan el beneficio de la comunidad.
|
||||
|
||||
|
||||
\subsection{Aproximaciones}
|
||||
|
||||
El problema del atraso tecnológico en Colombia debe ser atacado desde varios flancos para que pueda ser resuelto de forma efectiva. Como se indicó anteriormente solo con el trabajo conjunto de la industria, la academia y las politicas gubernamentales podremos avanzar en la solución del problema. El trabajo realizado acá solo puede contribuir a la solución del problema con soluciones encaminadas a la industria y la academia.
|
||||
|
||||
Porqué se eligió el área de diseño de sistemas digitales para atacar el problema del atraso tecnológico? Básicamente porque este sector es el que presenta un mayor retraso en el pais, adicionalmente, muchas áreas del conocimiento (como control, instrumentación, medición, comunicaciones, robó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ón especiales y de procesamiento, tanto en el mercado de productos de consumo (Entretenimiento, electrodimésticos, etc), como en el mercado de productos espscializados (Sistemas de control, sistemas de medició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ño y fabricación de Circuitos Integrados o aplicaciones en nanotecnología, ya que los laboratorios necesarios son muy costosos y en el paí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ís podría llegar a ser competitivo a corto plazo y generar productos que compitan con los ofrecidos por industrias de países desarrollados, estas son:
|
||||
|
||||
\begin{itemize}
|
||||
\item Desarrollo de núcleos de Propiedad Intelectual (IPs)
|
||||
\item Desarrollo de dispositivos dedicados a resolver problemas específicos utilizando dispositivos semiconductores ya existentes.
|
||||
\begin{itemize}
|
||||
\item Diseño de plataformas de Desarrollo Hardware robustas.
|
||||
\item Creació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íses con mayor oferta en servicios de manufactura.
|
||||
\end{itemize}
|
||||
|
||||
Los sistemas embebidos proporcionan una visión completa del proceso de producción de nuevos dispositivos: Concepción, Diseño, Implementación y Operación, adicionalmente es un mercado que mueve miles de millones de Dólares al año y su campo de acción abarca casi todas las actividades humanas (Educación, entrtenimiento, transporte, salud, productividad), existe una infinidad de herramientas Hardware (Procesadores, SoCs, FPGAs, diseños de referencia, herramientas CAD) y Software (Compiladores, depuradores, librerías, Sistemas Operativos, Aplicaciones) y una gran dinámica en la industria que proporciona servicios de manufactura (suministro de componentes, fabricación, pruebas, distribución). Lo que permite ingresar a este mercado con bajas inversiones de dinero, lo que es ideal para la situación actual del país (baja inversión en I+D), y es perfecta para que recié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ón a diferentes niveles: Cursos de capacitación, Diplomados, Líneas de profundización en pregrado y posgrado; Modificar el contenido de las asignaturas de las materias relacionadas con la electrónica digital para actualizar sus contenidos y las metodologías de diseño adecuadas, tambien es necesario un cambio en el enfoque, debemos pasar de un perfil analítico a un perfil de diseñador-investigador, en el que todo diseño debe culminar en un producto funcional, y no quedarse solo en las simulaciones. Adicionalmente, es necesario contar con una buena documentación que facilite el proceso de adopción de estos nuevos conocimientos.
|
||||
|
||||
Las actividades anteriores pueden garantizar que a corto plazo el pais forme profesionales capaces de realizar diseño de sistemas digitales utilizando metodologías de diseño adecuadas y herramientas de diseño moderno, pero para que estos cambios sean adoptados por las industrias debe crearse un vínculo con las Universidades para que estas últimas proporcionen profesionales con las competencias requeridas en el medio. También es necesario que existan políticas gubernamentales que estimulen el consumo de los productos locales y protejan las industrias que realicen actividades encaminadas al desarrollo tecnológico del pais. Adicionalmente es necesario capacitar a las empresas en el uso de nuevas tecnologías y en el proceso de producció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ón se tomó una empresa recién formada, con poco capital de inversión, dedicada al diseño de sistemas digitales y se trabajó con ella en la realización de productos con tecnología de punta,
|
||||
|
||||
Por otro lado, aprovechando que la realización de este trabajo coincidió con la re-estructuración de todos los programas académicos de la Universidad Nacional de Colombia, se pudo realizar un cambio total en el contenido de las asignaturas pertenecientes al área de la electrónica digital, estos cambios está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áneos a creadores de empresas que desarrollan sus propios productos.
|
||||
|
||||
Por último y no menos importante, todo este proceso se realizó utilizando herramientas de libre distribución y utilizando una filosofí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ón sobre los archivos de diseño: Esquemáticos, lista de materiales, archivos gerber para la fabricación de los PCBs y software de configuración utilizando herramientas libres. Si queremos que nuestro pais salga del atraso tecnoló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í la importancia de los conceptos de los movimientos de HW y SW libre.
|
||||
|
||||
El movimiento de SW libre demostró 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ó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ítica del entorno académico e industrial Colombiano para aprovechar de una forma más eficiente, los pocos recursos que suministra el estado para el desarrollo tecnológico.
|
||||
|
||||
Aprovechando lo posición provilegiada que tiene la Universidad Nacional de Colombia como el centro de formación superior más importante de Colombia, así 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ónica a corto plazo. Para avanzar en este sentido, el presente trabajo suminstrará la base para generar los cambios en el área de electrónica digital, estas modificaciones están encaminadas a crear en nuestros profesionales las habilidades necesarias para la creación de empresas con productos que suplen las demandas de la industria local. Adicionalmente, se pone a disposición de la comunidad interesada, la información necesaria para construir, programar y modificar una plataforma de desarrollo que puede ser utilizada como base para la solución de problemas locales, siguiendo la filosofía del Software y Hardware libre, esta información se encuentra disponible para todo el mundo, y es el punto de partida para la formación de una comunidad que coopera para avanzar en el cumplimiento de un objetivo comú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ón:
|
||||
%
|
||||
% \begin{itemize}
|
||||
%
|
||||
% \item Adopción y transferencia tecnologica: Con el fín de lograr un estado en el que el país sea soberano en cuanto a la tecnología que utiliza se estudió profundamente el diseño de Sistemas Embebidos, se implementaron plataformas de desarrollo para las arquitecturas más utilizadas en esta á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ñadas en Colombia. La información necesaria para su fabricación y utilización hacen parte de este documento. Estas plataformas pueden ser utilizadas como base de aplicaciones comerciales, o como plataforma educativa para la enseñanza de Sistemas Embebidos.
|
||||
%
|
||||
% \item Una metodología de trabajo que permite compartir el trabajo realizado por diferentes grupos de investigación o departamentos de I+D para generar conocimiento que permita que Colombia desarrolle tecnología propia, específicamente en el área de los Sistemas Embebidos. Esta información es el recurso comú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ún y no el individual.
|
||||
%
|
||||
% \item Se realizó un cambio total en las asignaturas que hacen parte del área de Electrónica Digital en la universidad más importante del país, los contenidos fueron actualizados para que reflejaran el estado de la industria a nivel mundial; Adicionalmente, se cambió el enfoque para que los ingenieros adquieran capacidades que les permitan dar soluciones a problemas reales.
|
||||
%
|
||||
% \end{itemize}
|
||||
|
||||
|
||||
% \subsection{Organización}
|
||||
|
||||
|
472
course/.docs/book/intro.tex.backup
Normal file
472
course/.docs/book/intro.tex.backup
Normal file
@ -0,0 +1,472 @@
|
||||
\chapter{Introdución}
|
||||
|
||||
\section{Visión, Paradigmas, y Dificultades}
|
||||
El gran avance de las técnicas de fabricació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ón actuales
|
||||
permiten construir sistemas cada vez más pequeños, veloces y de menor
|
||||
consumo de potencia, lo cual ha favorecido su difusión. El uso de los sistemas
|
||||
digitales en \'áreas como la aviación, la industria automovil\'{\i}stica, la
|
||||
bioingenier\'{\i}a, etc. demanda de estos un alto desempeñ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ñ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ñ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ño se presentan a medida que los sistemas
|
||||
embebidos se integran a nuestra vida diaria, se hace necesario diseñ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ñ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ñ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ñ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ñ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ñ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ñ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ñ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ñ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ño.
|
||||
\end{itemize}
|
||||
|
||||
El diseño de estos sistemas requiere nuevas fuentes de inspiraci\'on; una
|
||||
direcci\'on promisoria es verlos y diseñ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ño Electrónico en Colombia}
|
||||
|
||||
En la actualidad Colombia atraviesa por una $''$\textit{\textit{crisis}}$''$ a
|
||||
nivel de diseñ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ñ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ñ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ón de Conocimiento}
|
||||
|
||||
Para que Colombia deje de ser un país que consume tecnología y llegue en algún momento a ser generador de productos tecnológicos, es necesario que se genere un conocimiento que permita esta transición. ``Para que el conocimiento sea motor de desarrollo es necesario el traspaso desde sus creadores a la sociedad, mediante la conversión a tecnologías que produzcan cambios radicales que incrementen la producción. Esa transmisión de tecnología generadora de crecimiento económico esta influenciada por diversos factores: medio geográfico, leyes de propiedad industrial, costos laborales, nivel de ciencia y tecnología, religión, tipos de instituciones, resistencia a innovar, políticas de estado, guerras, factores demográficos, entre otros'' \cite{Mok90}
|
||||
|
||||
Pero como apropiar este conocimiento? Arrow \cite{Arr62} afirma que la apropicació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ón, y distribución, mercadeo, servicio y soporte operativo o riesgo compartido. También se presentan alianzas entre firmas como: contratos de I+D, acuerdos de licencias, licencias cruzadas. La conformación de estas asociaciones permite crear redes tecnológicas dominadas por paí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á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ón de empleos especializados, desarrollo tecnológico e industrial sostenido, ampliación del acervo de conocimiento nacional y disminución de la salida de divisas (al mejorar los procesos de negociación) y creación de externalidades positivas \cite{Mar04}.
|
||||
|
||||
Ligado al problema de la senda tecnológica está el del grado de lo tácito del conocimiento científico. Teece \cite{Tee81} señala que al existir conocimiento tácito toda la tecnología disponible no se transfiere de los productores a los receptores o compradores de la misma. Por tanto, los países seguidores siempre van a estar a la zaga tecnológica. Forbes y Wield \cite{FW00} señ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ón y adquisición de tecnología por firmas pequeñas y medianas, las cuales carecen de recursos y tienen procesos deficientes de contratación.
|
||||
|
||||
En este orden de ideas, si el país no es un innovador neto ¿no debería más bien mostrar una tendencia a importar conocimiento? Y las firmas nacionales ¿no deberían ser las que más efectuaran este tipo de contratos, para así acceder al conocimiento de la tecnología adquirida? En resumen, conociendo mejor qué tecnología se importa y qué tipos de contratos se utilizan, es posible crear marcos de referencia para empresas nacionales que estén interesadas en adquirir tecnología. Esto produciría externalidades positivas en empresas importadoras de conocimiento y, a su vez, en la economía del país. Con una adecuada importación de conocimientos tecnológicos se crearía una ventaja competitiva de carácter estructural, basada en un acervo de conocimiento tecnológico que permita incrementar la productividad en todos los sectores económicos de manera permanente \cite{Mar04}.
|
||||
|
||||
Según los estudios realizados por Martínez, con base en registros del Decreto 259/92, del Incomex. La importación de conocimiento no está siendo empleada con el propósito de utilizar tecnologí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ón de tecnologí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ón encaminados a la disminución de la brecha tecnológica.
|
||||
|
||||
|
||||
\subsection{Situación de la Industria Electrónica en Colombia}
|
||||
|
||||
La industria electrónica nacional no es ajena a las políticas que siguen las empresas nacionales en cuanto a la apropiación de tecnología; Colombia depende totalmente de economías más desarrolladas para el suministro de dispositivos electrónicos en diversas areas (comunicaciones, entretenimiento, industria, medicina, etc). Mientras en otros sectores de la economía han pasado de ser consumidores a exportadores, y adquieren nuevas tecnologías para ser más competitivos, el sector electrónico del país ha reducido sus actividades de Investigació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ómicos.
|
||||
|
||||
En la actualidad la industria electrónica presenta una gran dinámica a nivel mundial, el uso de los sistemas electrónicos se extiende a todas las actividades humanas; La demanda mundial de este tipo de sistemas aumentará de forma dramática en los próximos años, especialmente en los sectores de tecnología médica, movilidad, seguridad, comunicaciones y consumo \cite{ETPoSSI(09}. El mercado de los sistemas embebidos es una industria que movió alrededor de 25 billones de dólares en el 2008 según Venture Development Corporation \cite{Vc08}. Por otro lado, la inversión de capital necesaria para el diseño de Sistemas Embebidos es relativamente baja, gracias a la gran demanda originada, los insumos y los servicios de fabricación son muy económicos, las herramientas de desarrollo necesarias para la programación y depuración de este tipo de sistemas son de libre distribución.
|
||||
|
||||
Desafortunadamente en Colombia la industria electrónica se encuentra muy rezagada en relación a las de los países industrializados, y las ventajas y oportunidades de negocios mencionadas anteriormente no son aprovechadas en la actualidad.
|
||||
|
||||
Según ASESEL \footnote{Asociación de entidades del Sector Electrónico} en el 2001 existían 154 empresas productoras de componentes y equipos de la cadena electrónica. Dentro de los productos que la industria electrónica exporta se encuentran registrados: Circuitos integrados, circuitos impresos, microestructuras, instrumentos para medida y control, Instrumentos y aparatos eléctricos o electró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íses desarrollados. Según Proexport el 91\% de las exportaciones son realizadas por Bogotá y los destinos se encuentran en países cercanos como Venezuela, Perú, Ecuador y USA.
|
||||
|
||||
La electró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ón constante de los
|
||||
avances tecnológicos y las proyecciones futuras del sector. Debido a la importancia del sector tecnológico es primordial que en Colombia se esté consciente del estado actual y que se puede hacer en términos de
|
||||
Investigación Científica y Desarrollo Tecnológico (I+D) en Ingeniería Electrónica.
|
||||
|
||||
Un estudio realizado en la Universidad Nacional de Colombia \cite{MTRR07} identificó los siguientes obstáculos para el desarrollo de la industria electrónica en Colombia: Deficientes relaciones Universidad Empresa, Pobre enfoque académico hacia la industria, baja calidad de los productos nacionales, políticas gubernamentales, falta de cultura de Investigación y Reducida apropiación tecnológica, competencia de países asiáticos, atraso tecnológico, limitado recurso humano con formación avanzada.
|
||||
|
||||
De los problemas expuestos anteriormente podemos identificar cuales son los que más afectan el desarrollo de la industria electrónica en Colombia, el que más perjudica sin lugar a dudas es el atraso tecnológico, no es posible ser competitivo en el mercado electrónico mundial con tecnologías y metodologías de diseñ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ón como el \textit{assembler}, para el cual el tiempo de aprendizaje, desarrollo y de depuración es muy largo} La culpa de este atraso tecnoló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í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ógico es el sector académico; Según el Sistema Nacional de Información Superior, durante los últimos 10 años se han abierto 230 programas relacionados con la industria electrónica, estos programas están repartidos entre programas de formación Universitaria, tecnológica terminal y de técnica profesional, la mayoría de estos centros de formación se encuentran ubicados en 3 Departamentos: Bogotá, 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íses en vía de desarrollo y doce veces mayor que los que se gradúan en los países desarrollados. En Colombia, este aumento es aportado por instituciones de poca consolidación; además, las preferencias en la educación superior son Formación técnica / form. tecnológica / form. profesional que es justamente lo opuesto a la de los países desarrollados \cite{MDAG99}.
|
||||
|
||||
Por otro lado, el contenido de las asignaturas relacionadas directamente con la industria electrónica se encuentran muy desactualizados, y fuera del contexto mundial, se utilizan metodologías de diseño antiguas en las que primaba la experiencia del diseñador, se realizan tareas manuales, repetitivas que pueden ser realizadas por herramientas de diseño moderno, los currículos son conservadores hay poca experimentación y su estructuración y metodologías son muy clásicas. Adicionalmente, muchos investigadores dedican sus estudios en proyectos que no aportan al desarrollo del país únicamente porque están de moda. Otro problema adicional radica en la falta de experiencia en el sector productivo por parte del personal acadé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ón de un producto comercial, razón por la cual se evita la experimentación y se da más énfasis al análisis y solo se llega a una simulación.
|
||||
|
||||
De lo anterior podemos concluir que en Colombia se presenta una sobre-oferta de profesionales en el área electrónica, muchos de los cuales provienen de instituciones educativas con poca consolidación, y que han sido formados con programas desactualizados que no tienen en cuenta los avances tecnológicos y metodológicos, lo cual explica la pobreza de ingenieros con altos niveles de formación. Por esta razón no es de extrañar la poca confianza que tienen los industriales en los productos nacionales.
|
||||
|
||||
Lo anterior unido a la falta de políticas de estado que: tracen normas encaminadas a incentivar la inversión en investigación y desarrollo, defina líneas y campos de investigación, regule la oferta laboral y los programas académicos, generan el clima perfecto para que el atraso tecnológico se mantenga durante mucho tiempo y Colombia no deje de ser un consumidor de tecnología. Según John Kao, uno de los grandes expertos del mundo en innovación, los países desarrollados no invierten en Ciencia Tecnología e Innovación (CTI) porque son ricos, sino que son ricos porque invierten en CTI.
|
||||
|
||||
|
||||
\subsubsection{Tecnologías de Información y Comunicación}
|
||||
En la actualidad existe un especial interés por parte del gobierno \footnote{ La Agenda de Conectividad es el programa del Ministerio de Comunicaciones, encargado de impulsar el uso y masificación de las Tecnologías de Información y Comunicación -TIC- como herramienta dinamizadora del desarrollo social y económico del país ()} en impulsar las Tecnologías de la Información y la Comunicació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ía es simplemente la infraestructura, si la infraestructura no está acompañada por la creación de habilidades y conocimiento la adopción de TICs no ayudará a obtener los beneficios que esperamos, sin embargo, ayudará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ón como pricipal herramienta para reducir la \textit{brecha tecnológica} que existe entre las diferentes regiones de nuestro país y de nuestro país con los paises desarrollados.
|
||||
|
||||
Hearn, Simpson, Lennie y Kimber \cite{HSL+04} \cite{MJF05} nombran las siguientes caracterí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ía se vuelva
|
||||
obsoleta y se acabe el proyecto por esta causa.
|
||||
\item Apalancar el desarrollo de la empresa pequeña ayudado por personal y
|
||||
financiació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ón, planeación y
|
||||
evaluación de proyectos. Hemos visto que para que un proyecto de
|
||||
tecnología tenga é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ía de aprendizaje a través de ciclos de evaluación
|
||||
basados en una acción investigativa.
|
||||
|
||||
\end{enumerate}
|
||||
|
||||
Adicionalmente es necesario buscar el bien común por encima del individual, razón por la cual debemos preguntarnos quienes son los favorecidos por la difusión de estas tecnologías, no tiene sentido invertir grandes sumas de dinero para llevar estas tecnologí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ón y sin entrenamiento no se le puede sacar provecho a estas tecnologías. Debemos crear herramientas que integren a nuestros pueblos y que permitan colaborar entre ellas.
|
||||
|
||||
En la actualidad esta polí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ógico del paí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ón. Microsoft utiliza una política de reducción de precios para los centros educativos y algunos centros gubernamentales, esta ``donación'' solo crea dependencia tecnológica y en la mayorí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áctica que se generaliza a todo el software no solo al de Microsoft lo que hace que las empresas medianas y pequeñ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ía de los computadores de una nación se está cediendo la soberanía para el beneficio de un particular foráneo.
|
||||
|
||||
Lo mismo sucede con los equipos que se utilizan para acceder a estas tecnologías, en la mayoría de los casos son fabricados en paises con diferentes culturas y diferentes necesidades. Es obvio que el país no puede fabricar ciertos equipos que se requieren para poder llevar estas tecnologí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ías. De esta forma impulsamos la industra electrónica produciendo de forma masiva un dispositivo electrónico en el pais, diseñado para suplir necesidades de la región. Esta plataforma no solo poroporcionará la base para el desarrollo de las TICs, sino la base tecnoló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ía necesaria para que las universidades y empresas locales sean capaces de desarrollar dispositivos que permitan el acceso a estas tecnologías.
|
||||
|
||||
|
||||
\subsection{Estado de la Electrónica Digital en la Universidad Nacional de Colombia}
|
||||
|
||||
Hasta hace un año en las asignaturas del área de electró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ía no es su año de creación, ni siquiera que en la actualidad se consideren obsoletas para el diseño de un sistema digital completo. \footnote{En la actualidad estas compuertas se utilizan para la implementación de pequeñas operaciones lógicas} El problema detrás del uso de esta tecnología se encuentra en la ausencia total de metodologías de diseño (en el caso Colombiano). Y el desconocimiento en herramientas tipo CAD. El proceso de diseño que realizaban los estudiantes era:
|
||||
|
||||
\begin{enumerate}
|
||||
\item Especificaciones del sistema.
|
||||
\item Generación manual de ecuaciones boolenas.
|
||||
\item Minimización manual utilizando mapas de Karnaugh.
|
||||
\item Implementació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émico se justifica el uso de las familias 7400 y 4000, sin embargo, el quedarse ahi no es bueno para una industria electrónica desactualizada, debido a que este tipo de implementaciones no pueden generar productos competitivos a nivel mundial. La razó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ón de ecuaciones booleanas, las cuales están sujetas a errores humanos originados por cansancio, falta de concentración, etc. Otro aspecto que vale la pena resaltar es la falta de una simulación funcional, la mayoría de los estudiantes consultados no realizaban simulaciones funcionales y preferían probar el diseño una vez implementado físicamente, esto unido a la dificultad de depuración innata a este tipo de implementaciones, aumentaba considerablemente el tiempo requerido para realizar la implementación y pruebas del sistema.
|
||||
|
||||
En el segundo curso del área de electrónica digital, se introduce al estudiante al uso de los dispositivos lógicos programables (PLD) y los lenguajes de descripción de hardware (HDL) como herramientas para el diseño de sistemas digitales, al comienzo, el contenido de estos cursos se limitaba al uso de una herramienta de diseño y la enseñanza de nociones básicas del lenguaje VHDL, se daba más importancia al uso de la herramienta y no a la metodología de diseño, de nuevo el estudiante ataca los problemas sin una metodología de diseño clara. Vale la pena indicar que este curso fue dictado por profesores ocasionales durante los ú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í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ía de diseño en la que los estudiantes emulan el comportamiento del microcontrolador antes de ser programado, sin embargo, esta práctica no es seguida por la mayoría de los estudiantes, una posible causa de este comportamiento puede ser la falta de metodologías de diseño en los cursos anteriores.
|
||||
|
||||
La sensación que queda al terminar el área de electrónica digital es que lo único que importa son los microcontroladores y que lo visto en los primeros cursos no es muy útil. La siguiente tabla muestra los problemas encontrados en el área de electrónica digital de las carreras de Ingeniería Eléctrica y Electrónica de la Universidad Nacional de Colombia:
|
||||
|
||||
\begin{enumerate}
|
||||
\item Falta de una metodología de diseño.
|
||||
\item Utilización de herramientas obsoletas: Familias Lógicas, lenguajes de programació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ón adecuada que ayude a la industria electronica a salir del retraso tecnológico.
|
||||
\end{enumerate}
|
||||
|
||||
|
||||
\section{Descripción de la Tésis}
|
||||
|
||||
\subsection{Objetivos e Hipótesis}
|
||||
|
||||
\subsubsection{Ojetivo Principal}
|
||||
|
||||
Desarrollar una metodología para la transferencia tecnológica y de conocimientos en el área de Sistemas Embebidos.
|
||||
El objetivo de este trabajo es contribuir a dar solución al problema del atraso tecnológico en Colombia, puntualmente en los siguientes puntos:
|
||||
|
||||
\subsubsection{Objetivos Secundarios}
|
||||
|
||||
\begin{itemize}
|
||||
\item Formulación de una metodología para la transferencia tecnológica y de conocimientos en el área de Sistemas Embebidos en Colombia.
|
||||
\item Formulación de una metodología de Diseño y producción para Sistemas Embebidos aplicable en el entorno local.
|
||||
\item Identificación de las habilidades requeridas para los profesionales y técnicos en la Industria Electrónica para estar acorde con la tendencia de la industria electrónica mundial y formulación de recomenadaciones para la industria y los organismos gubernamentales encaminadas a mejora la productividad de la industria electrónica del país.
|
||||
\item Desarrollo de Plataformas Hardware que utilicen tecnología de punta.
|
||||
\item Diseño de los programas de las asignaturas del área de electrónica digital en programas de pregrado para incorporar las nuevas metodologías modernas de diseño y producción.
|
||||
\end{itemize}
|
||||
|
||||
|
||||
|
||||
\subsubsection{Hipótesis}
|
||||
Las recomendaciones dadas por los estudios sobre como solucionar el problema del desarrollo tecnológico, hablan de como se debe trabajar de forma local, teniendo en cuenta la experiencia generada globalmente, Por lo que partiemos de la hipótesis que es posible utilizar técnicas de auto-organización para que diferentes centros de formación y producción distribuidos a lo largo del país encuentren la forma de distribuir de forma eficiente los recursos (Información, conocimiento, recursos económicos) comunes para alcanzar en forma conjunta el objetivo principal: Encontrar políticas de auto-gobierno que permitan el beneficio de la comunidad.
|
||||
|
||||
|
||||
\subsection{Aproximaciones}
|
||||
|
||||
El problema del atraso tecnológico en Colombia debe ser atacado desde varios flancos para que pueda ser resuelto de forma efectiva. Como se indicó anteriormente solo con el trabajo conjunto de la industria, la academia y las politicas gubernamentales podremos avanzar en la solución del problema. El trabajo realizado acá solo puede contribuir a la solución del problema con soluciones encaminadas a la industria y la academia.
|
||||
|
||||
Porqué se eligió el área de diseño de sistemas digitales para atacar el problema del atraso tecnológico? Básicamente porque este sector es el que presenta un mayor retraso en el pais, adicionalmente, muchas áreas del conocimiento (como control, instrumentación, medición, comunicaciones, robó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ón especiales y de procesamiento, tanto en el mercado de productos de consumo (Entretenimiento, electrodimésticos, etc), como en el mercado de productos espscializados (Sistemas de control, sistemas de medició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ño y fabricación de Circuitos Integrados o aplicaciones en nanotecnología, ya que los laboratorios necesarios son muy costosos y en el paí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ís podría llegar a ser competitivo a corto plazo y generar productos que compitan con los ofrecidos por industrias de países desarrollados, estas son:
|
||||
|
||||
\begin{itemize}
|
||||
\item Desarrollo de núcleos de Propiedad Intelectual (IPs)
|
||||
\item Desarrollo de dispositivos dedicados a resolver problemas específicos utilizando dispositivos semiconductores ya existentes.
|
||||
\begin{itemize}
|
||||
\item Diseño de plataformas de Desarrollo Hardware robustas.
|
||||
\item Creació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íses con mayor oferta en servicios de manufactura.
|
||||
\end{itemize}
|
||||
|
||||
Los sistemas embebidos proporcionan una visión completa del proceso de producción de nuevos dispositivos: Concepción, Diseño, Implementación y Operación, adicionalmente es un mercado que mueve miles de millones de Dólares al año y su campo de acción abarca casi todas las actividades humanas (Educación, entrtenimiento, transporte, salud, productividad), existe una infinidad de herramientas Hardware (Procesadores, SoCs, FPGAs, diseños de referencia, herramientas CAD) y Software (Compiladores, depuradores, librerías, Sistemas Operativos, Aplicaciones) y una gran dinámica en la industria que proporciona servicios de manufactura (suministro de componentes, fabricación, pruebas, distribución). Lo que permite ingresar a este mercado con bajas inversiones de dinero, lo que es ideal para la situación actual del país (baja inversión en I+D), y es perfecta para que recié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ón a diferentes niveles: Cursos de capacitación, Diplomados, Líneas de profundización en pregrado y posgrado; Modificar el contenido de las asignaturas de las materias relacionadas con la electrónica digital para actualizar sus contenidos y las metodologías de diseño adecuadas, tambien es necesario un cambio en el enfoque, debemos pasar de un perfil analítico a un perfil de diseñador-investigador, en el que todo diseño debe culminar en un producto funcional, y no quedarse solo en las simulaciones. Adicionalmente, es necesario contar con una buena documentación que facilite el proceso de adopción de estos nuevos conocimientos.
|
||||
|
||||
Las actividades anteriores pueden garantizar que a corto plazo el pais forme profesionales capaces de realizar diseño de sistemas digitales utilizando metodologías de diseño adecuadas y herramientas de diseño moderno, pero para que estos cambios sean adoptados por las industrias debe crearse un vínculo con las Universidades para que estas últimas proporcionen profesionales con las competencias requeridas en el medio. También es necesario que existan políticas gubernamentales que estimulen el consumo de los productos locales y protejan las industrias que realicen actividades encaminadas al desarrollo tecnológico del pais. Adicionalmente es necesario capacitar a las empresas en el uso de nuevas tecnologías y en el proceso de producció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ón se tomó una empresa recién formada, con poco capital de inversión, dedicada al diseño de sistemas digitales y se trabajó con ella en la realización de productos con tecnología de punta,
|
||||
|
||||
Por otro lado, aprovechando que la realización de este trabajo coincidió con la re-estructuración de todos los programas académicos de la Universidad Nacional de Colombia, se pudo realizar un cambio total en el contenido de las asignaturas pertenecientes al área de la electrónica digital, estos cambios está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áneos a creadores de empresas que desarrollan sus propios productos.
|
||||
|
||||
Por último y no menos importante, todo este proceso se realizó utilizando herramientas de libre distribución y utilizando una filosofí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ón sobre los archivos de diseño: Esquemáticos, lista de materiales, archivos gerber para la fabricación de los PCBs y software de configuración utilizando herramientas libres. Si queremos que nuestro pais salga del atraso tecnoló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í la importancia de los conceptos de los movimientos de HW y SW libre.
|
||||
|
||||
El movimiento de SW libre demostró 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ó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ítica del entorno académico e industrial Colombiano para aprovechar de una forma más eficiente, los pocos recursos que suministra el estado para el desarrollo tecnológico.
|
||||
|
||||
Aprovechando lo posición provilegiada que tiene la Universidad Nacional de Colombia como el centro de formación superior más importante de Colombia, así 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ónica a corto plazo. Para avanzar en este sentido, el presente trabajo suminstrará la base para generar los cambios en el área de electrónica digital, estas modificaciones están encaminadas a crear en nuestros profesionales las habilidades necesarias para la creación de empresas con productos que suplen las demandas de la industria local. Adicionalmente, se pone a disposición de la comunidad interesada, la información necesaria para construir, programar y modificar una plataforma de desarrollo que puede ser utilizada como base para la solución de problemas locales, siguiendo la filosofía del Software y Hardware libre, esta información se encuentra disponible para todo el mundo, y es el punto de partida para la formación de una comunidad que coopera para avanzar en el cumplimiento de un objetivo comú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ón:
|
||||
%
|
||||
% \begin{itemize}
|
||||
%
|
||||
% \item Adopción y transferencia tecnologica: Con el fín de lograr un estado en el que el país sea soberano en cuanto a la tecnología que utiliza se estudió profundamente el diseño de Sistemas Embebidos, se implementaron plataformas de desarrollo para las arquitecturas más utilizadas en esta á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ñadas en Colombia. La información necesaria para su fabricación y utilización hacen parte de este documento. Estas plataformas pueden ser utilizadas como base de aplicaciones comerciales, o como plataforma educativa para la enseñanza de Sistemas Embebidos.
|
||||
%
|
||||
% \item Una metodología de trabajo que permite compartir el trabajo realizado por diferentes grupos de investigación o departamentos de I+D para generar conocimiento que permita que Colombia desarrolle tecnología propia, específicamente en el área de los Sistemas Embebidos. Esta información es el recurso comú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ún y no el individual.
|
||||
%
|
||||
% \item Se realizó un cambio total en las asignaturas que hacen parte del área de Electrónica Digital en la universidad más importante del país, los contenidos fueron actualizados para que reflejaran el estado de la industria a nivel mundial; Adicionalmente, se cambió el enfoque para que los ingenieros adquieran capacidades que les permitan dar soluciones a problemas reales.
|
||||
%
|
||||
% \end{itemize}
|
||||
|
||||
|
||||
% \subsection{Organización}
|
||||
|
||||
|
349
course/.docs/book/note_tmp.tex
Normal file
349
course/.docs/book/note_tmp.tex
Normal file
@ -0,0 +1,349 @@
|
||||
Es necesario transferir todos los componentes de la tecnología para una efectiva transferenica.
|
||||
|
||||
|
||||
|
||||
En conclusión con la venta de equipos se transmite únicamente el conocimiento para operar, programar o mantener, sin embargo,
|
||||
este conocimiento sobre el sistema puede ayudar a concientizarse sobre la tecnología e impulsar la formación de capital humano.
|
||||
La transferencia tecnológica incluye la difusión de conocimiento científico y la preocupación por la transformación del conocimiento en
|
||||
innovaciones útiles
|
||||
|
||||
|
||||
|
||||
La transferencia tecnológica no ocurre cuando estudiantes formados en el exterior no pueden aplicar sus conocimientos en su país de origen,
|
||||
por lo que es necesario crear políticas que definan que áreas de estudio son prioritarias para el país. Adicionalmente, existen centros privados
|
||||
de capacitación que ofrecen cursos para el manejo de paquetes y lenguajes de
|
||||
programación, estos centros aprovechan la falta de centros de enseñanza tecnoló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ón con otros instrumentos como investigación extranjera, importación de maquinaria o de técnicos. Sin embargo, no es efectivo si no
|
||||
se acompaña de habilidades administrativas y de producción. Adicionalmente, es necesario contar con una infraestructura tecnológica adecuada,
|
||||
capacidades locales de fabricación de hardware y software y políticas de gobierno adecuadas.
|
||||
|
||||
|
||||
|
||||
Toda política debe contar con formas de medir la transferencia exitosa. Uno de los indicadores de éxito es la transferencia de habilidades.
|
||||
|
||||
|
||||
Muchos países en vía de desarrollo tienen dificultades al momento de diseñar estrategias efectivas para su transformación tecnológica y para una rápida
|
||||
industrialización y desarrollo tecnológico.
|
||||
|
||||
Problemas:
|
||||
Identificar que tecnología es adecuada, como adoptarla y adaptarla
|
||||
Como se escoge la tecnologí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ógicas
|
||||
|
||||
|
||||
Los PVD prefieren adoptar y asimilar nuevas tecnologí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íticas de transferencia tecnológica deben ser parte de las metas generales de la nación para sus planes de desarrollo económico, industrial y social. Las políticas de transferencia de tecnología deben centrarse en encontrar los métodos apropiados para utilizar la tecnología con el fin de lograr un rápido progreso económico e industrial. De esta forma los PVD reducen su dependencia de los países desarrollados.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
La transferencia vertical establece varios pasos en la transferencia, que pueden ser aplicados en diferentes niveles: Entre centros académicos, transferencia entre la academia y la empresa para generar aplicaciones, prototipos y producción en masa. La desconcexión entre la Universidad y la empresa en Colombia y en la mayoría de los países en desarrollo hace que los objetivos que persigue la Academia no está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ógica para hacerlo o porque la Universidad no proporciona el soporte necesario para que ese producto pueda ser utilizado en la práctica.
|
||||
|
||||
|
||||
|
||||
Las actividades realizadas durante este estudio están enmarcadas dentro del concepto: \textit{El conocimiento es un Bien Común}, toda la documentació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és de listas de discusión, adicionalmente se proporciona soporte comercial para permitir la producción de estas modificaciones.
|
||||
|
||||
|
||||
la investigación científica se origina y justifica cada vez más en el contexto de aplicación del conocimiento,
|
||||
es decir, en la posibilidad de su utilización. Por lo que los temas de investigación no son fijados por los científicos sino por redes formadas
|
||||
por empresarios, ingenieros de planta e inversionistas
|
||||
|
||||
|
||||
el esfuerzo de los países de la región en ciencia y tecnología es inferior al que les corresponderí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ógica?
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
2. Aptitudes personales y profesionales
|
||||
|
||||
2.1 Planteamiento y resolución de problemas de Ing.
|
||||
|
||||
2.1.1 Identificación y Formulació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ón y recomendación
|
||||
Analizar resultados de simulaciones y de soluciones
|
||||
Analizar las diferencias en los resultados.
|
||||
Formular recomendaciones.
|
||||
|
||||
2.2 Experimentación y Descubrimiento de Conocimiento
|
||||
|
||||
2.2.1 Formulación de hipótesis
|
||||
Formular hipótesis para ser probadas
|
||||
2.2.2 Investigación experimental
|
||||
Formular el concepto y la estrategia del experimento
|
||||
Comparar datos experimentales y simulaciones
|
||||
|
||||
|
||||
2.3 Pensamiento Sistemá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ón y abstracción
|
||||
Ejecutar el proceso de invención.
|
||||
2.4.2 Pensamiento crí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 Ética profesional, integridad, responsabilidad.
|
||||
Manifestar normas y principios éticos.
|
||||
Dar crédito a los colaboradores.
|
||||
2.5.2 Comportamiento profesional.
|
||||
Identificar normas internacionales de contacto inter-personal
|
||||
|
||||
3. Habilidades interpersonales, trabajo en equipo y comunicación.
|
||||
|
||||
3.1 Equipo de Trabajo
|
||||
|
||||
3.1.1 Formar grupos efectivos
|
||||
Identificar las etapas de la formación del grupo y el ciclo de vida.
|
||||
Identificar roles y responsabilidades
|
||||
3.1.2 Liderazgo
|
||||
Entrenamiento en procesos de administración del equipo
|
||||
Representación del equipo ante otros.
|
||||
|
||||
3.2 Comunicaciones
|
||||
|
||||
3.2.1 Estrategia de comunicación
|
||||
Analizar la situación
|
||||
Elegir una estrategia de comunicación
|
||||
3.2.2 Estructura de la comunicación
|
||||
Construir una estructura apropiada y relación entre las ideas.
|
||||
3.2.3 Comunicación Escrita
|
||||
Escritura de documentos técnicos.
|
||||
3.2.4 Comunicación Electrónica
|
||||
Utilizar varios estilos electrónicos ()
|
||||
3.2.5 Presentación Oral y Comunicación Inter-Personal
|
||||
Preparación de presentaciones
|
||||
|
||||
3.3 Comunicación en Idioma Extranjero
|
||||
|
||||
3.3.1 Inglés
|
||||
Leer y entender información técnica.
|
||||
Participar en listas de discusión.
|
||||
|
||||
|
||||
|
||||
4. Concebir, Diseñ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ón
|
||||
Aceptar las responsabilidades ante la sociedad
|
||||
4.1.2 Impacto sobre la sociedad.
|
||||
Impacto sobre el entorno sistemas sociales, conocimiento y econó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ón y difusión de conocimiento.
|
||||
|
||||
4.2 Empresa y contexto empresarial
|
||||
|
||||
4.2.1 Estrategias de empresa, metas y planificación
|
||||
Reconocer los procesos de investigación y tecnología
|
||||
Reconocer las alianzas estratégicas y las relaciones con los proveedores.
|
||||
4.3.2 Espíritu Empresarial Técnico
|
||||
Reconocer nuevas tecnologías que puedan generar nuevos productos y sistemas
|
||||
4.3.3 Trabajo exitoso en organizaciones
|
||||
Describir los diversos roles y responsabilidades en una organización
|
||||
|
||||
4.3 Concepció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ías o necesidades
|
||||
4.3.2 Definir la función, concepto y arquitectura
|
||||
Identificar las especificaciones funcionales del sistema
|
||||
Identificar la arquitectura de alto nivel.
|
||||
Definir la descomposición en elementos, su función y su interfaz.
|
||||
|
||||
|
||||
4.4 Diseño
|
||||
|
||||
4.4.1 Proceso de Diseño
|
||||
Definir las especificaciones de cada componente derivado del sistema global
|
||||
Analizar alternativas de diseño
|
||||
Utilizar prototipos en el proceso de desarrollo
|
||||
Sintetizar el proyecto final
|
||||
Demostrar capacidad de adaptación ante cambio en las especificaciones.
|
||||
4.4.2 Fases del proceso de Diseño y enfoques
|
||||
Explicar las actividades en las etapas del proceso de diseñ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ón de conocimiento científico en el diseño
|
||||
Utilizar conocimiento técnico y científico
|
||||
Practicar pensamiento crítico y creativo y solución de problemas
|
||||
4.4.4 Diseño específico
|
||||
Elección de técnicas herramientas y procesos adecuados
|
||||
Práctica de modelamiento, simulación y pruebas
|
||||
Discutir el refinamiento analítico del diseño
|
||||
4.4.5 Diseño multi-disciplinario
|
||||
Identificar las interacciones entre disciplinas
|
||||
|
||||
|
||||
4.5 Implementación
|
||||
|
||||
4.5.2 Proceso de fabricación Hardware
|
||||
Describir la fabricación de partes.
|
||||
Describir el ensamble de partes a gran escala
|
||||
4.5.3 Proceso de Implementación de Software
|
||||
Explicar el proceso de descomposición de componentes de alto nivel en módulos (incluyendo algoritmos y estructuras de datos)
|
||||
Realizar diseño de bajo nivel
|
||||
Describir el sistema de desarrollo
|
||||
4.5.4 Integración Software - Hardware
|
||||
Describir la integración de software en hardware electrónico (Tamaño del procesador, comunicaciones, memorias, períféricos)
|
||||
Describir la función y la seguridad del HW/SW
|
||||
4.5.5 Pruebas, verificación, validación y certificación
|
||||
Discutir procedimientos de análisis y pruebas
|
||||
Discutir la verificación de desempeño de los requerimientos del sistema.
|
||||
Discutir la validación del desempeño que el usuario necesita
|
||||
Explicar la certificació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ño multi-disciplinario.
|
||||
\item Estudiar y realizar el proceso de Fabricación Hardware.
|
||||
\item Estudiar el principio básico de los sistemas operativos.
|
||||
\item Describir la integración de software en hardware electrónico
|
||||
\item Entender diagramas de circuitos electrónicos de sistemas digitales, identifcar sus componentes y su función.
|
||||
\item Estudiar diseños software y hardware existentes para entender su funcionamiento, arquitectura y adquirir experiencia en el diseño.
|
||||
\item Hacer parte de listas de discusión de temas técnicos que usen el inglés como lenguaje.
|
||||
\end{itemize}
|
||||
|
||||
|
||||
|
||||
|
||||
\subsection{Recomendaciones para los generadores de políticas}
|
||||
\begin{itemize}
|
||||
|
||||
\item{Fomentar la Generación de Empresas Locales de Base Tecnológica}
|
||||
\item{Promover la Importancia de la Transferencia Tecnológica como Motor de Desarrollo Económico}
|
||||
\item{Promover el Mejoramiento de la Plataforma Tecnológica}
|
||||
|
||||
\end{itemize}
|
||||
|
||||
\subsection{Recomendaciones para la academia}
|
||||
|
||||
\begin{itemize}
|
||||
\item{Alianza con la industria}
|
||||
\item{Actualización Curricular}
|
||||
\item{Promover y Soportar la Transferencia Tecnológica}
|
||||
\item{Búsqueda de financiación para I+D}
|
||||
|
||||
\end{itemize}
|
||||
|
||||
|
||||
\subsection{Recomendaciones para el Gobierno}
|
||||
\begin{itemize}
|
||||
\item{Promover la Relación Universidad-Empresa}
|
||||
\item{Promover la Excelencia Académica y la Investigación}
|
||||
\item{Formular políticas Para Incentivar Actividades de Transferencia Tecnoló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ón depende de la calidad de esta, a mayor calidad de información, mayor el beneficio.
|
351
course/.docs/book/note_tmp.tex.backup
Normal file
351
course/.docs/book/note_tmp.tex.backup
Normal file
@ -0,0 +1,351 @@
|
||||
Es necesario transferir todos los componentes de la tecnología para una efectiva transferenica.
|
||||
|
||||
|
||||
|
||||
En conclusión con la venta de equipos se transmite únicamente el conocimiento para operar, programar o mantener, sin embargo,
|
||||
este conocimiento sobre el sistema puede ayudar a concientizarse sobre la tecnología e impulsar la formación de capital humano.
|
||||
La transferencia tecnológica incluye la difusión de conocimiento científico y la preocupación por la transformación del conocimiento en
|
||||
innovaciones útiles
|
||||
|
||||
|
||||
|
||||
La transferencia tecnológica no ocurre cuando estudiantes formados en el exterior no pueden aplicar sus conocimientos en su país de origen,
|
||||
por lo que es necesario crear políticas que definan que áreas de estudio son prioritarias para el país. Adicionalmente, existen centros privados
|
||||
de capacitación que ofrecen cursos para el manejo de paquetes y lenguajes de
|
||||
programación, estos centros aprovechan la falta de centros de enseñanza tecnoló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ón con otros instrumentos como investigación extranjera, importación de maquinaria o de técnicos. Sin embargo, no es efectivo si no
|
||||
se acompaña de habilidades administrativas y de producción. Adicionalmente, es necesario contar con una infraestructura tecnológica adecuada,
|
||||
capacidades locales de fabricación de hardware y software y políticas de gobierno adecuadas.
|
||||
|
||||
|
||||
|
||||
Toda política debe contar con formas de medir la transferencia exitosa. Uno de los indicadores de éxito es la transferencia de habilidades.
|
||||
|
||||
|
||||
Muchos países en vía de desarrollo tienen dificultades al momento de diseñar estrategias efectivas para su transformación tecnológica y para una rápida
|
||||
industrialización y desarrollo tecnológico.
|
||||
|
||||
Problemas:
|
||||
Identificar que tecnología es adecuada, como adoptarla y adaptarla
|
||||
Como se escoge la tecnologí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ógicas
|
||||
|
||||
|
||||
Los PVD prefieren adoptar y asimilar nuevas tecnologí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íticas de transferencia tecnológica deben ser parte de las metas generales de la nación para sus planes de desarrollo económico, industrial y social. Las políticas de transferencia de tecnología deben centrarse en encontrar los métodos apropiados para utilizar la tecnología con el fin de lograr un rápido progreso económico e industrial. De esta forma los PVD reducen su dependencia de los países desarrollados.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
La transferencia vertical establece varios pasos en la transferencia, que pueden ser aplicados en diferentes niveles: Entre centros académicos, transferencia entre la academia y la empresa para generar aplicaciones, prototipos y producción en masa. La desconcexión entre la Universidad y la empresa en Colombia y en la mayoría de los países en desarrollo hace que los objetivos que persigue la Academia no está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ógica para hacerlo o porque la Universidad no proporciona el soporte necesario para que ese producto pueda ser utilizado en la práctica.
|
||||
|
||||
|
||||
|
||||
Las actividades realizadas durante este estudio están enmarcadas dentro del concepto: \textit{El conocimiento es un Bien Común}, toda la documentació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és de listas de discusión, adicionalmente se proporciona soporte comercial para permitir la producción de estas modificaciones.
|
||||
|
||||
|
||||
la investigación científica se origina y justifica cada vez más en el contexto de aplicación del conocimiento,
|
||||
es decir, en la posibilidad de su utilización. Por lo que los temas de investigación no son fijados por los científicos sino por redes formadas
|
||||
por empresarios, ingenieros de planta e inversionistas
|
||||
|
||||
|
||||
el esfuerzo de los países de la región en ciencia y tecnología es inferior al que les corresponderí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ógica?
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
2. Aptitudes personales y profesionales
|
||||
|
||||
2.1 Planteamiento y resolución de problemas de Ing.
|
||||
|
||||
2.1.1 Identificación y Formulació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ón y recomendación
|
||||
Analizar resultados de simulaciones y de soluciones
|
||||
Analizar las diferencias en los resultados.
|
||||
Formular recomendaciones.
|
||||
|
||||
2.2 Experimentación y Descubrimiento de Conocimiento
|
||||
|
||||
2.2.1 Formulación de hipótesis
|
||||
Formular hipótesis para ser probadas
|
||||
2.2.2 Investigación experimental
|
||||
Formular el concepto y la estrategia del experimento
|
||||
Comparar datos experimentales y simulaciones
|
||||
|
||||
|
||||
2.3 Pensamiento Sistemá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ón y abstracción
|
||||
Ejecutar el proceso de invención.
|
||||
2.4.2 Pensamiento crí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 Ética profesional, integridad, responsabilidad.
|
||||
Manifestar normas y principios éticos.
|
||||
Dar crédito a los colaboradores.
|
||||
2.5.2 Comportamiento profesional.
|
||||
Identificar normas internacionales de contacto inter-personal
|
||||
|
||||
3. Habilidades interpersonales, trabajo en equipo y comunicación.
|
||||
|
||||
3.1 Equipo de Trabajo
|
||||
|
||||
3.1.1 Formar grupos efectivos
|
||||
Identificar las etapas de la formación del grupo y el ciclo de vida.
|
||||
Identificar roles y responsabilidades
|
||||
3.1.2 Liderazgo
|
||||
Entrenamiento en procesos de administración del equipo
|
||||
Representación del equipo ante otros.
|
||||
|
||||
3.2 Comunicaciones
|
||||
|
||||
3.2.1 Estrategia de comunicación
|
||||
Analizar la situación
|
||||
Elegir una estrategia de comunicación
|
||||
3.2.2 Estructura de la comunicación
|
||||
Construir una estructura apropiada y relación entre las ideas.
|
||||
3.2.3 Comunicación Escrita
|
||||
Escritura de documentos técnicos.
|
||||
3.2.4 Comunicación Electrónica
|
||||
Utilizar varios estilos electrónicos ()
|
||||
3.2.5 Presentación Oral y Comunicación Inter-Personal
|
||||
Preparación de presentaciones
|
||||
|
||||
3.3 Comunicación en Idioma Extranjero
|
||||
|
||||
3.3.1 Inglés
|
||||
Leer y entender información técnica.
|
||||
Participar en listas de discusión.
|
||||
|
||||
|
||||
|
||||
4. Concebir, Diseñ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ón
|
||||
Aceptar las responsabilidades ante la sociedad
|
||||
4.1.2 Impacto sobre la sociedad.
|
||||
Impacto sobre el entorno sistemas sociales, conocimiento y econó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ón y difusión de conocimiento.
|
||||
|
||||
4.2 Empresa y contexto empresarial
|
||||
|
||||
4.2.1 Estrategias de empresa, metas y planificación
|
||||
Reconocer los procesos de investigación y tecnología
|
||||
Reconocer las alianzas estratégicas y las relaciones con los proveedores.
|
||||
4.3.2 Espíritu Empresarial Técnico
|
||||
Reconocer nuevas tecnologías que puedan generar nuevos productos y sistemas
|
||||
4.3.3 Trabajo exitoso en organizaciones
|
||||
Describir los diversos roles y responsabilidades en una organización
|
||||
|
||||
4.3 Concepció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ías o necesidades
|
||||
4.3.2 Definir la función, concepto y arquitectura
|
||||
Identificar las especificaciones funcionales del sistema
|
||||
Identificar la arquitectura de alto nivel.
|
||||
Definir la descomposición en elementos, su función y su interfaz.
|
||||
|
||||
|
||||
4.4 Diseño
|
||||
|
||||
4.4.1 Proceso de Diseño
|
||||
Definir las especificaciones de cada componente derivado del sistema global
|
||||
Analizar alternativas de diseño
|
||||
Utilizar prototipos en el proceso de desarrollo
|
||||
Sintetizar el proyecto final
|
||||
Demostrar capacidad de adaptación ante cambio en las especificaciones.
|
||||
4.4.2 Fases del proceso de Diseño y enfoques
|
||||
Explicar las actividades en las etapas del proceso de diseñ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ón de conocimiento científico en el diseño
|
||||
Utilizar conocimiento técnico y científico
|
||||
Practicar pensamiento crítico y creativo y solución de problemas
|
||||
4.4.4 Diseño específico
|
||||
Elección de técnicas herramientas y procesos adecuados
|
||||
Práctica de modelamiento, simulación y pruebas
|
||||
Discutir el refinamiento analítico del diseño
|
||||
4.4.5 Diseño multi-disciplinario
|
||||
Identificar las interacciones entre disciplinas
|
||||
|
||||
|
||||
4.5 Implementación
|
||||
|
||||
4.5.2 Proceso de fabricación Hardware
|
||||
Describir la fabricación de partes.
|
||||
Describir el ensamble de partes a gran escala
|
||||
4.5.3 Proceso de Implementación de Software
|
||||
Explicar el proceso de descomposición de componentes de alto nivel en módulos (incluyendo algoritmos y estructuras de datos)
|
||||
Realizar diseño de bajo nivel
|
||||
Describir el sistema de desarrollo
|
||||
4.5.4 Integración Software - Hardware
|
||||
Describir la integración de software en hardware electrónico (Tamaño del procesador, comunicaciones, memorias, períféricos)
|
||||
Describir la función y la seguridad del HW/SW
|
||||
4.5.5 Pruebas, verificación, validación y certificación
|
||||
Discutir procedimientos de análisis y pruebas
|
||||
Discutir la verificación de desempeño de los requerimientos del sistema.
|
||||
Discutir la validación del desempeño que el usuario necesita
|
||||
Explicar la certificació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ño multi-disciplinario.
|
||||
\item Estudiar y realizar el proceso de Fabricación Hardware.
|
||||
\item Estudiar el principio básico de los sistemas operativos.
|
||||
\item Describir la integración de software en hardware electrónico
|
||||
\item Entender diagramas de circuitos electrónicos de sistemas digitales, identifcar sus componentes y su función.
|
||||
\item Estudiar diseños software y hardware existentes para entender su funcionamiento, arquitectura y adquirir experiencia en el diseño.
|
||||
\item Hacer parte de listas de discusión de temas técnicos que usen el inglés como lenguaje.
|
||||
\end{itemize}
|
||||
|
||||
|
||||
|
||||
|
||||
\subsection{Recomendaciones para los generadores de políticas}
|
||||
\begin{itemize}
|
||||
|
||||
\item{Fomentar la Generación de Empresas Locales de Base Tecnológica}
|
||||
\item{Promover la Importancia de la Transferencia Tecnológica como Motor de Desarrollo Económico}
|
||||
\item{Promover el Mejoramiento de la Plataforma Tecnológica}
|
||||
|
||||
\end{itemize}
|
||||
|
||||
\subsection{Recomendaciones para la academia}
|
||||
|
||||
\begin{itemize}
|
||||
\item{Alianza con la industria}
|
||||
\item{Actualización Curricular}
|
||||
\item{Promover y Soportar la Transferencia Tecnológica}
|
||||
\item{Búsqueda de financiación para I+D}
|
||||
|
||||
\end{itemize}
|
||||
|
||||
|
||||
\subsection{Recomendaciones para el Gobierno}
|
||||
\begin{itemize}
|
||||
\item{Promover la Relación Universidad-Empresa}
|
||||
\item{Promover la Excelencia Académica y la Investigación}
|
||||
\item{Formular políticas Para Incentivar Actividades de Transferencia Tecnoló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ón depende de la calidad de esta, a mayor calidad de información, mayor el beneficio.
|
||||
|
||||
|
2245
course/.docs/book/platform.tex
Normal file
2245
course/.docs/book/platform.tex
Normal file
File diff suppressed because it is too large
Load Diff
2874
course/.docs/book/platform.tex.backup
Normal file
2874
course/.docs/book/platform.tex.backup
Normal file
File diff suppressed because it is too large
Load Diff
516
course/.docs/book/problem.tex
Normal file
516
course/.docs/book/problem.tex
Normal file
@ -0,0 +1,516 @@
|
||||
\section{Definici\'on del problema }
|
||||
|
||||
\section{Introducción}
|
||||
Uno de los objetivos principales del presente trabajo es la realización de actividades que ayude al país en su desarrollo tecnológico; en la actualidad Colombia es un consumidor de tecnología, es decir, busca en el exterior soluciones a sus problemas, en la mayoría de las ocasiones, estas soluciones no se ajustan a los requerimientos, ya que no tienen en cuenta la situación política, cultural y social del país. En la mayoría de los casos, no se aumenta el conocimiento tecnológicos del paí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éndola de alguna forma frente a los productos forá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ógico nos llevará a la eliminación total de la industrias Colombianas. A continuación se presenta un resúmen del estudio realizado por Hector Martínez sobre la Apropiació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ñ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ñ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ñ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ón de Conocimiento}
|
||||
|
||||
Para que Colombia deje de ser un país que consume tecnología y llegue en algún momento a ser generador de productos tecnológicos, es necesario que se genere un conocimiento que permita esta transición. ``Para que el conocimiento sea motor de desarrollo es necesario el traspaso desde sus creadores a la sociedad, mediante la conversión a tecnologías que produzcan cambios radicales que incrementen la producción. Esa transmisión de tecnología generadora de crecimiento económico esta influenciada por diversos factores: medio geográfico, leyes de propiedad industrial, costos laborales, nivel de ciencia y tecnología, religión, tipos de instituciones, resistencia a innovar, políticas de estado, guerras, factores demográficos, entre otros'' \cite{Mok90}
|
||||
|
||||
Pero como apropiar este conocimiento? Arrow \cite{Arr62} afirma que la apropicació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ón, y distribución, mercadeo, servicio y soporte operativo o riesgo compartido. También se presentan alianzas entre firmas como: contratos de I+D, acuerdos de licencias, licencias cruzadas. La conformación de estas asociaciones permite crear redes tecnológicas dominadas por países industrializados con sus respectivas empresas multinacionales monopolizando conocimiento \cite{Mar04}
|
||||
|
||||
Para Colombia, el problema radica en que mediante contratos de importación de tecnología, las empresas de capital nacional no está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ón de empleos especializados, desarrollo tecnológico e industrial sostenido, ampliación del acervo de conocimiento nacional y disminución de la salida de divisas (al mejorar los procesos de negociación) y creación de externalidades positivas \cite{Mar04}.
|
||||
|
||||
Ligado al problema de la senda tecnológica está el del grado de lo tácito del conocimiento científico. Teece \cite{Tee81} señala que al existir conocimiento tácito toda la tecnología disponible no se transfiere de los productores a los receptores o compradores de la misma. Por tanto, los países seguidores siempre van a estar a la zaga tecnológica. Forbes y Wield \cite{FW00} señ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ón y adquisición de tecnología por firmas pequeñas y medianas, las cuales carecen de recursos y tienen procesos deficientes de contratación.
|
||||
|
||||
En este orden de ideas, si el país no es un innovador neto ¿no debería más bien mostrar una tendencia a importar conocimiento? Y las firmas nacionales ¿no deberían ser las que más efectuaran este tipo de contratos, para así acceder al conocimiento de la tecnología adquirida? En resumen, conociendo mejor qué tecnología se importa y qué tipos de contratos se utilizan, es posible crear marcos de referencia para empresas nacionales que estén interesadas en adquirir tecnología. Esto produciría externalidades positivas en empresas importadoras de conocimiento y, a su vez, en la economía del país. Con una adecuada importación de conocimientos tecnológicos se crearía una ventaja competitiva de carácter estructural, basada en un acervo de conocimiento tecnológico que permita incrementar la productividad en todos los sectores económicos de manera permanente \cite{Mar04}.
|
||||
|
||||
Según los estudios realizados por Martínez, con base en registros del Decreto 259/92, del Incomex. La importación de conocimiento no está siendo empleada con el propósito de utilizar tecnologí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ón de tecnologí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ón encaminados a la disminución de la brecha tecnológica.
|
||||
|
||||
\subsubsection{Situación de la Industria Electrónica en Colombia}
|
||||
|
||||
La industria electrónica nacional no es ajena a las políticas que siguen las empresas nacionales en cuanto a la apropiación de tecnología; Colombia depende totalmente de economías más desarrolladas para el suministro de dispositivos electrónicos en diversas areas (comunicaciones, entretenimiento, industria, medicina, etc). Mientras en otros sectores de la economía han pasado de ser consumidores a exportadores, y adquieren nuevas tecnologías para ser más competitivos, el sector electrónico del país ha reducido sus actividades de Investigació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ómicos.
|
||||
|
||||
En la actualidad la industria electrónica presenta una gran dinámica a nivel mundial, el uso de los sistemas electrónicos se extiende a todas las actividades humanas; La demanda mundial de este tipo de sistemas aumentará de forma dramática en los próximos años, especialmente en los sectores de tecnología médica, movilidad, seguridad, comunicaciones y consumo \cite{ETPoSSI(09}. El mercado de los sistemas embebidos es una industria que movió alrededor de 25 billones de dólares en el 2008 según Venture Development Corporation \cite{Vc08}. Por otro lado, la inversión de capital necesaria para el diseño de Sistemas Embebidos es relativamente baja, gracias a la gran demanda originada, los insumos y los servicios de fabricación son muy económicos, por otro lado, las herramientas de desarrollo necesarias para la programación y depuración de este tipo de sistemas son de libre distribución.
|
||||
|
||||
|
||||
Desafortunadamente en Colombia la industria electrónica se encuentra muy rezagada en relación a las de los países industrializados, y las ventajas y oportunidades de negocios mencionadas anteriormente no son aprovechadas en la actualidad.
|
||||
|
||||
|
||||
Según ASESEL \footnote{Asociación de entidades del Sector Electrónico} en el 2001 existían 154 empresas productoras de componentes y equipos de la cadena electrónica. Dentro de los productos que la industria electrónica exporta se encuentran registrados: Circuitos integrados, circuitos impresos, microestructuras, instrumentos para medida y control, Instrumentos y aparatos eléctricos o electró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íses desarrollados. Según Proexport el 91\% de las exportaciones son realizadas por Bogotá y los destinos se encuentran en países cercanos como Venezuela, Perú, Ecuador y USA.
|
||||
|
||||
La electró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ón constante de los
|
||||
avances tecnológicos y las proyecciones futuras del sector. Debido a la importancia del sector tecnológico es primordial que en Colombia se esté consciente del estado actual y que se puede hacer en términos de
|
||||
Investigación Científica y Desarrollo Tecnológico (I+D) en Ingeniería Electrónica.
|
||||
|
||||
Un estudio realizado en la Universidad Nacional de Colombia \cite{MTRR07} identificó los siguientes obstáculos para el desarrollo de la industria electrónica en Colombia: Deficientes relaciones Universidad Empresa, Pobre enfoque académico hacia la industria, Calidad de los productos nacionales, políticas gubernamentales, falta de cultura de Investigación y Reducida apropiación tecnológica, competencia de países asiáticos, atraso tecnológico, limitado recurso humano con formación avanzada.
|
||||
|
||||
De los problemas expuestos anteriormente podemos identificar cuales son los que más afectan el desarrollo de la industria electrónica en Colombia, el que más perjudica sin lugar a dudas es el atraso tecnológico, no es posible ser competitivo en el mercado electrónico mundial con tecnologías y metodologías de diseñ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ón como el assembler, para el cual el tiempo de aprendizaje, desarrollo y de depuración es muy largo. La culpa de este atraso tecnoló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í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ógico es el sector académico; según el Sistema Nacional de Información Superior, durante los últimos 10 años se han abierto 230 programas relacionados con la industria electrónica, estos programas están repartidos entre programas de formación Universitaria, tecnológica terminal y de técnica profesional, la mayoría de estos centros de formación se encuentran ubicados en 3 Departamentos: Bogotá, 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íses en vía de desarrollo y doce veces mayor que los que se gradúan en los países desarrollados, en Colombia, este aumento es aportado por instituciones de poca consolidación. Además las preferencias en la educación superior son Formación técnica / form. tecnológica / form. profesional que es justamente lo opuesto a la de los países desarrollados \cite{MDAG99}.
|
||||
|
||||
Por otro lado, el contenido de las asignaturas relacionadas directamente con la industria electrónica se encuentran muy desactualizados, y fuera del contexto mundial, se utilizan metodologías de diseño antiguas en las que primaba la experiencia del diseñador, se realizan tareas manuales, repetitivas que pueden ser realizadas por herramientas de diseño moderno, los currículos son conservadores hay poca experimentación y su estructuración y metodologías son muy clásicas. Otro problema adicional radica en la falta de experiencia en el sector productivo por parte del personal acadé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ón de un producto comercial, razón por la cual se evita la experimentación y se da más énfasis al análisis y solo se llega a una simulación.
|
||||
|
||||
De lo anterior podemos concluir que en Colombia se presenta una sobre-oferta de profesionales en el área electrónica, muchos de los cuales provienen de instituciones educativas con poca consolidación, y que han sido formados con programas desactualizados que no tienen en cuenta los avances tecnológicos y metodológicos, lo cual explica la pobreza de ingenieros con altos niveles de formación. Por esta razón no es de extrañar la poca confianza que tienen los industriales en los productos nacionales.
|
||||
|
||||
Lo anterior unido a la falta de políticas de estado que: tracen normas encaminadas a incentivar la inversión en investigación y desarrollo, defina líneas y campos de investigación, regulación de la oferta laboral, regulación de los programas académicos, generan el clima perfecto para que el atraso tecnológico se mantenga durante mucho tiempo y Colombia no deje de ser un consumidor de tecnología.
|
||||
|
||||
|
||||
\subsubsection{Pasos a seguir para iniciar la solución al problema de atraso tecnológico}
|
||||
|
||||
Estudios consultados \cite{MDAG99} \cite{DZSC+07} \cite{MTRR07} \cite{Mar04}, coinciden en que para dar solución a los problemas expuestos anteriormente se deben seguir las siguientes recomendaciones:
|
||||
|
||||
Al gobierno:
|
||||
|
||||
\begin{itemize}
|
||||
\item Fomento gubernamental de centros de investigación y productividad para fortalecer la relaciones universidad empresa.
|
||||
\item Fomentar cooperación internacional e inversión extranjera con transferencia de tecnología. a nivel gubernamental, Apoyo del gobierno a personas que tienen un alto potencial de crear y desarrollar tecnología.
|
||||
\item Definir agendas de investigación acordes con las tendencias mundiales y desarrollar capacidades en el país.
|
||||
\end{itemize}
|
||||
|
||||
A los centros de Enseñanza:
|
||||
\begin{itemize}
|
||||
\item Creación de portafolio de servicios.
|
||||
\item Realizar seminarios y líneas de profundización de temas afines a la administración y la gerencia en empresas de base tecnológica.
|
||||
\item Montar laboratorios de pruebas e incentivar los productores nacionales para que logren una calidad que cumpla con los estándares internacionales.
|
||||
\item Infraestructura institucional que impulse la actualización tecnológica en el sector mediante desarrollo de proyectos de tecnología de punta con una posible transferencia de tecnología.
|
||||
\item Incentivar la formación de maestrías y doctorados nacionales acorde con una agenda de investigación.
|
||||
\item Realización de proyectos de aplicación.
|
||||
\item El contacto con las empresas no debe ser encargada únicamente a los estudiantes, la Universidad debe desarrollar las competencias que la empresa requiere.
|
||||
\item Interacción entre Universidades, Conviene que buena parte de los trabajos realizados en doctorado sean de investigación aplicada, orientadas a mejorar la productividad del sector empresarial
|
||||
\item Innovación curricular, actualización continua de profesionales.
|
||||
\item Las facultades de Ingeniería deben acompañ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ía.
|
||||
\end{itemize}
|
||||
|
||||
|
||||
|
||||
\subsubsection{Estado de la Electrónica Digital en la Universidad Nacional de Colombia}
|
||||
|
||||
Hasta hace un año en las asignaturas del área de electró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ía no es su año de creación, ni siquiera que en la actualidad se consideren obsoletas para el diseño de un sistema digital completo. \footnote{En la actualidad estas compuertas se utilizan para la implementación de pequeñas operaciones lógicas} El problema detrás del uso de esta tecnología se encuentra en la ausencia total de metodologías de diseño (en el caso Colombiano). Y el desconocimiento en herramientas tipo CAD. El proceso de diseño que realizaban los estudiantes era:
|
||||
|
||||
\begin{enumerate}
|
||||
\item Especificaciones del sistema.
|
||||
\item Generación manual de ecuaciones boolenas.
|
||||
\item Minimización manual utilizando mapas de Karnaugh.
|
||||
\item Implementació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émico se justifica el uso de las familias 7400 y 4000, sin embargo, el quedarse ahi no es bueno para una industria electrónica desactualizada, debido a que este tipo de implementaciones no pueden generar productos competitivos a nivel mundial. La razó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ón de ecuaciones booleanas, las cuales están sujetas a errores humanos originados por cansancio, falta de concentración, etc. Otro aspecto que vale la pena resaltar es la falta de ua simulación funcional, la mayoría de los estudiantes consultados no realizaban simulaciones funcionales y preferían probar el diseño una vez implementado físicamente, esto unido a la dificultad de depuració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 área de electrónica digital, se introduce al estudiante al uso de los dispositivos lógicos programables (PLD) y los lenguajes de descripción de hardware (HDL) como herramientas para el diseño de sistemas digitales, al comienzo, el contenido de estos cursos se limitaba al uso de una herramienta de diseño y la enseñanza de nociones básicas del lenguaje VHDL, se daba más importancia al uso de la herramienta y no a la metodología de diseño, de nuevo el estudiante ataca los problemas sin una metodología de diseño clara. Vale la pena indicar que este curso fue dictado por profesores ocasionales durante los ú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í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ía de diseño en la que los estudiantes emulan el comportamiento del microcontrolador antes de ser programado, sin embargo, esta práctica no es seguida por la mayoría de los estudiantes, una posible causa de este comportamiento puede ser la falta de metodologías de diseño en los cursos anteriores.
|
||||
|
||||
La sensación que queda al terminar el área de electrónica digital es que lo único que importa son los microcontroladores y que lo visto en los primeros cursos no es muy útil. La siguiente tabla muestra los problemas encontrados en el área de electrónica digital de las carreras de Ingeniería Eléctrica y Electrónica de la Universidad Nacional de Colombia:
|
||||
|
||||
\begin{enumerate}
|
||||
\item Falta de una metodología de diseño.
|
||||
\item Utilización de herramientas obsoletas: Familias Lógicas, lenguajes de programació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ón adecuada que ayude a la industria electronica a salir del retraso tecnoló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ñ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ón realizaremos una revisión de los trabajos realizados en las áreas relacionadas con auto-organización con implementaciones Hardware.....
|
||||
|
||||
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% AUTO - ORGANIZACION
|
||||
\subsection{Auto-Organización}
|
||||
|
||||
Trabajos en Auto-Organización han sido desarrollados en muchos campos, Por ejemplo, en \cite{SOQX04} utilizan un protocolo de auto-organización para optimizar la energía de una red de sensores inalámbricos, proporcionar adaptabilidad (en tamaño, topologí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ón de alto nivel del sistema y utiliza herramientas como ecuaciones diferenciales. Trata cada parte del sistema complejo de forma genérica y es efectivo modelando casos promedio, donde la diferencia de comportamiento de los individuos puede ser ignorada. Sin embargo, esta aproximación no puede ser utilizada en todos los casos. Por ejemplo, las ecuaciones diferenciales no pueden modelar de forma precisa, la dinámica y el comportamiento emergente de algunos de los sistemas biológicos (la distribución de anticuerpos en el sistema inmunológico humano tiende a ser heterogéneo)
|
||||
\item Bottom-Up: Comienza con una descripción de la entidad más pequeña del sistema complejo y modela su funcionamiento de la siguiente forma:
|
||||
\begin{itemize}
|
||||
\item Autónomo: Los elementos del sistema son individuos racionales que actúan de forma independiente.
|
||||
\item Emergente: Exhiben comportamientos complejos que no estan presentes o son predefinidos en el funcionamiento de las unidades autó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ón bottom-up que intenta resolver problemas computacionales de alto grado de dificultad o caracterizar el funcionamiento de sistemas complejos basado en la observación de la naturaleza, los pasos para construir un modelo AOC son:
|
||||
|
||||
\begin{enumerate}
|
||||
\item Observar el comportamiento macroscópico del sistema natural
|
||||
\item Diseñar las entidades funcionamiento deseado asi como el entorno donde residen dichas entidades.
|
||||
\item Observar el comportamiento macroscópico del sistema artificial.
|
||||
\item Validar el comporatmiento del sistema artificial con su contraparte natural.
|
||||
\item Modificar el diseñ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ón de sensores}
|
||||
\cite{KPJZ}
|
||||
|
||||
|
||||
El CEBOT \cite{TUTF} esta conformado por un gran número de unidades robóticas autónomas, llamadas celúlas, cada una con capaz de realizar una función simple. CEBOT permite configurar de forma dinámica la estructura del SW y HW con el fín de realizar una determminada función o ante cambios en el entorno, esta reconfiguración se logra modificando la interacción entre las células. En este trabajo el comportamiento cooperativo se define como un comportamiento de la célula para generar la configuración estructural.
|
||||
|
||||
|
||||
|
||||
\section{Coordinació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ó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ón deliberativa es computacionalmente intensiva, ya que utiliza razonamiento o planeación explícita utilizando una representación simbó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ícil de obtener, por ejemplo, en entornos diná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ón, donde típicamente no existe ningún tipo de razonamiento\cite{BC86}\cite{Bro91}. El control reactivo no requiere la creació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ón, representación interna o cinicimiento del mundo. Esto hace al control reactivo adecuado para entornos diná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á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ón local de obstáculos. La parte deliberativa del control maneja tareas de alto nivel saobre una mayor escala de tiempo, tales como planeació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á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ó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ón en mantener una estrecha realación entre sensado y acció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ón ante múltiples entradas de sensores y funcionamientos secibe el nombre de \textit{Selección de acción}\cite{Pir00}. Uno de los mecanimos mejor conocidos para selección de acción es el uso de una jerarquí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á limitado por realidades fisicas, incertidumbres y consecuencias de sus acciones, todas ellas difíciles de predecir y 2) El robot está imerso en un mundo real y actúa directamente en base a la información de sus sensores, no sobre una representació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ándose únicamente en la informació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ón del costo total del sistema, al utilizar robots simples y económicos en lugar de un robot complejo y costoso. Ademá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ó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ñado pobremente, con robots individuales trabajando en oposición, puede ser menos efectivo que un sistema SRS diseñado cuidadosamente. El reto más grande en el diseño de sistemas MRS efectivos es el manejo de la complejidad introducida por la interacción entre los robots.
|
||||
|
||||
\subsubsection{Necesidad de Coordinació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áctico. Para que la interacción de los robots produzcan funcionamientos coherentes, debe existir algun mecanismo de coordinación que organice espacio-temporalmente las interacciones de forma apropiada para la tarea.
|
||||
|
||||
|
||||
\subsection{Coordinació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ón a través del entorno, interacción a través de sensores, e interacción a través de comunicacion. Estas clases no son mutuamente excluyentes ya que los MRS pueden y en algunos casos utilizan mecanismos simultáneos de cualquiera o de las tres clases para alcanzar un funcionamieno coordinado a nivel de sistema.
|
||||
|
||||
|
||||
\subsubsection{Interacción por medio del entorno}
|
||||
|
||||
El primer mecanismo de interacción es através del entorno compartido de los robots. Esta forma de interacción es indirecta, ya que no existe comunicación explícita o física entre los robots. En lugar de esto, el mismo entorno se utiliza como medio de la comunicación indirecta.
|
||||
|
||||
Con el cuidadoso diseñ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ón indirecta en un sistema de auto-organización emergente, donde sus partes individuales se comunican con las otras modificando su entorno local.}} en MRS. Este poderoso mecanismo de coordinación es muy atractivo ya que típicamente requiere capacidades mínimas de los robots individuales. Los robots no requieren comunicació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ón.
|
||||
|
||||
Las acciones de construcción de un robot alteran el entorno, y por lo tanto la información de los sensores disponible para los otros robots. Esta nueva información activa acciones de construcción posteriores.
|
||||
|
||||
\subsubsection{Iteracción através de sensores}
|
||||
El segundo mecanismo para la interacción entre robots es através de sensores. Como se describe en \cite{CFK97}, la interacción utilizando sensores se refiere a interacciones locales que pueden ocurrir entre robots como resultado de el sensado de otro robot., pero sin comunicación explícita. Al igual que la interacción por medio del entorno, la interacción utilizando sensores es también indirecta ya que no existe comunicación explí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ás robots, o clases de los otros robots. En otros casos, puede ser necesario distingir robots de otros objetos del entorno.
|
||||
|
||||
La interación por medio de sensores puede ser usada por un robot para modelar el comportamiento de otros robots o para determinar que está 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ón y velocidad de los vecinos locales \cite{Rey87}.
|
||||
|
||||
Otros dominios en los cuales la interacción a travé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ón a través de sensores también ha sido demostrada en el dominio de división adaptativa de tareas \cite{JM03}. En este dominio, cada robot cambia de forma dinámica las tarea que está ejecutando basándose en las acciones observadas de otros robots y la disponibilidad de tareas en el entorno.
|
||||
|
||||
\subsubsection{Caso de Estudio Interacción por medio de Sensores: Formación de marcha}
|
||||
|
||||
La aproximación a la formación de marcha aca descrita fué presentada en \cite{FM02}. La idea general de esta aproximació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ón relativa con respecto a su robot vecino, ningún robot esta, ni necesita estar pendiente de, la posición global de todos los robots en la formación. Cada robot solo necesita ser capaz de determinar la distancia y dirección a su vecino. La geometría global de la formación fue determinada a través de la cadena de vecinos. La formación puede ser cambiada de forma dinámica alterando la estructura de la relación local del vecino.
|
||||
|
||||
\subsubsection{Interacción por medio de comunicación}
|
||||
La comunicació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ón son factores de diseño muy importantes \cite{GM(.I.W01}.
|
||||
|
||||
Existen muchos tipos de comunicación. La comunicació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ás robots. Así mismo, los protocolos pueden ir desde esquemas simples carentes de protocolo a esquemas complejos basados en negociación y comunicación intensiva. La información codificada en una comunicación puede ser información de estado, un comando a uno o más robots, una petición de información adicional por otros robots.
|
||||
|
||||
\subsubsection{Casi de estudio Interacción por medio de comunicació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é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ón. La comunicación fue utilizada por cada robot para transmitir la posición y velocidad de todos los objetivos dentro de su rango de sensado a los demás robots dentro de su rango de comunicación.
|
||||
|
||||
Cada robot evalúa constantemente la importancia de su actual actividad de seguimiento y los posibles cambios de posición que podrían aumentar la importancia de sus actividades de seguimiento. La comunicación fue utilizada para permitir a cada robot mantener un mapa local de los movimientos de los objetivos dentro del rango de comunicació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ño formal y análisis de un Sistema Multi-Robot}
|
||||
|
||||
El diseño de los mecanismos de coordinación para un sistema multi-robot (MRS) ha probado ser un problema dificil de resolver. En la última década, el diseño de una variedad de tales mecanismos sobre un amplio rango de dominios de aplicació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ón para un dominio en particular.
|
||||
\item Que características de desempeño se pueden esperar de el.
|
||||
\item Como esta relacionado con otros mecanismos de coordinación.
|
||||
\item Como se puede modificar para aumentar el desempeño del sistema.
|
||||
\end{itemize}
|
||||
|
||||
El paradigma BB para control multi-robot es popular en MRS debido a su robustez a las interacciones diná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ás rebots. Esto hace que cualquier esquema de control que se base en razonamiento o planeación complejos no sean efectivos debido a que es muy difícil predecir de forma precisa futuros estados de un sistema MRS no trivial. Por esta razó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álisi externo para predecir el desempeño del sistema.
|
||||
|
||||
\subsubsection{Analisis de Sistemas Multi-Robot Utilizando Modelos Macroscópicos}
|
||||
|
||||
Los modelos macroscópicos se enfocan en el funcionamiento a nivel de sistema del MRS sin considerar de forma explícita cada robot individualmente en el sistema.
|
||||
|
||||
Un modelo matemático macroscópico MRS ha sido demostrado en el dominio de tareas de recolección de alimentos \cite{LG02}. El modelo fué 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 óptima de robots con el fín de maximizar el desempeño de la tarea. Un modelo analítico macroscópico ha sido aplicado para el estudio de la dinámica del comportamiento colectivo en un dominio colaborativo utilizando una serie de ecuaciones diferenciales \cite{LGM+01}.
|
||||
|
||||
Un modelo macroscópico general para el estudio de sistemas adaptativos multi-agente fué presentado en \cite{LG03} y fué aplicado al análisis en el dominio de localización de tareas que fué 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ícita con otros robots.
|
||||
|
||||
|
||||
\subsubsection{Análisi de Sistemas Multi-Robot Utilizando Modelos Microscópicos}
|
||||
|
||||
El modelamiento microscó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ón exacta del funcionamiento de cada robot. Sin embargo, la mayoría de las aproximaciones microscópicas modelan el funcionamienro de cada robot como una serie de eventos estocásticos. Típicamente, el controlador del robot individual es abstraido a algún grado y las trayectorias e interacciones no son consideradas directamente.
|
||||
|
||||
Una metodología de modelamiento microscópico probabilístico para el estudio de funcionamiento colectivo en en dominio de clustering fué presentado en \cite{MIM99}. El modelo fué validado a través de un acuerdo cuantitativo entre la predicción de la evolución del tamaño del cluster, con la simulación de experimentos y con experimentos sobre robots reales. La efectividad y precisión de las técnicas de modelamiento macroscópico y microscópico comparadas con los experimentos con robots reales y simulaciones se discuten en \cite{ME02}.
|
||||
|
||||
Un paso hacia adelante en las metodologías para el análisis formal de un determinado diseño MRS se encuentra en las metodologías formales para la síntesis de controladores MRS. La síntesis es el proceso de construcción de un controlador MRS que cumple con las restricciones del diseño, tales como alcanzar el nivel de desempeño deseado mientras cumple las restricciones impuestas por las limitadas capacidades del robot.
|
||||
|
||||
Ser capaz de definir un dominio de aplicación y tener un método formal que diseñe el MRS para cumplir con la tarea mientras se alcanza el criterio de desempeño especificado es uno de los objetivos de largo plazo en la comunidad MRS.
|
||||
|
||||
Una herramienta de trabajo importante en el diseño formal de MRS coordinados fué el desarrollo de \textit{information invariants}, la cual intenta definir los requerimientos de informació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é estudiado experimentalmente en el dominia de manipulación distribuida de tareas \cite{DJR95} y fué extendido a través de la definición de equivalencia de clases entre definiciones de tareas y capacidades del robot para ayudar en la elecció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én existen un número de entornos de diseño de MRS, arquitecturas de control, y lenguajes de programación, los cuales ayudan en el diseño de MRS coordinados \cite{Mat95b} \cite{AB97} \cite{AGH+00}
|
||||
|
||||
|
||||
%*******************************************************************************************************************
|
||||
|
||||
\subsection{Asignación díná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ño efectivo de un MRS coordinado está restringido por la carencia de herramientas de diseño y metodologías formales. El diseño de un SRS (Single Robot System) se ha visto beneficiado en gran medida por los formalismos proporcionados por la teoría de control -- el diseño de MRS esta necesitando un formalismo análogo.
|
||||
|
||||
Para que un grupo de robots realicen de forma efectiva una determinada tarea a nivel de sistema, el diseñador debe hacerse la pregunta: ¿Qué robot puede realizar que tarea y cuando?. La asignación dinámica de tareas es una clase de asignación de tareas en la cual, la asignación de robots a las sub-tareas es un proceso dinámico y puede requerir un ajuste continuo en respuesta a cambios en el entorno de la tarea o al desempeño del grupo. El problema de la asignación de la asigación de tareas en un MRS distribuido esta compuesto por el hecho que la asignació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ún robot posee una visión completa del estado del mundo. Con esta informació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én haciendo otros robots que la hayan realizado en el pasado, o que harían en el futuro \cite{KLCJ+}.
|
||||
|
||||
Existe un número de modelos y filosofías de asignación de tareas. Históricamente, la más popular se basa en la coordinación intencional para lograr la asignación de tareas \cite{Par98b}. En esta, los robots coordinan sus respectivas acciones de forma explícita a través de comunicaciones y negocioaciones deliberadas. Debido a problemas relacioados con la escala, dichas aproximaciones son utilizadas en MRS con un numero relativamente pequeñ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ñar e implementar, y más adecuado para el análisis formal \cite{BPG}.
|
||||
|
||||
Al aumentar el tamaño del MRS, la complejidad introducida al aumentar las interacciones de los robots, hace que estos sistemas sean más difíciles de analizar y diseñar. Esto lleva a la alternativa de coordinación intencional, es decir, asignación de tareas utilizando coordinación emergente. En sistemas que utilizan la coordinación emergente, los robots individuales coordinan sus acciones basadándose únicamente en información local de sensores e interacciones locales. Típicamente, existe muy poca o ninguna comunicación directa o negociaciones explí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ón de grandes números de robots coordinados.
|
||||
|
||||
|
||||
\subsubsection{Trabajo relacionado}
|
||||
|
||||
Sugawara et al \cite{KSMS97} \cite{KSMS+} desarrollaron un modelo simple de recolección de alimentos cooperativo en grupos de robots con y sin comunicación. Kazadi et al. [11] \cite{SKAA02} estudió la propiedad general de una agregación multi-robot utilizando modelos mocroscópicos fenomenológicos. Agassounon y Martinoli \cite{WAAM02} presentan un modelo de agregación en el cual el número de robots toman parte de en la tarea de clustering se basa en el mecanismo de división de labores de las antenas.
|
||||
|
||||
|
||||
Estos modelos son ad-hoc y e dominio específico, y los autores no dan explicación de como aplicar estos modelos a otros dominios. En trabajos recientes hemos desarrollado un marco de trabajo general para crear modelos fenomenológicos de funcionamiento colectivo en grupos de robots \cite{KLAG04} \cite{KLAM05}.
|
||||
|
||||
Muchas de las aproximaciones listadas arriba están de forma implícita o explícita basadas en la teoría de procesos estocásticos. Otro ejemplo de una aproximación estocástica es el modelo probabilí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álisis de sistemas multirobot en entornos dinámicos. En \cite{KLAG03} se extiende el marco de trabajo de los procesos estocásticos desarrollado en trabajos recientes, a robots que cambian su comportamiento basándose en la historia de observaciones locales del (probablemente cambiante) entorno \cite{LG03}.
|
||||
|
||||
En \cite{BAH88} Huberman y Hogg, realizaron un estudio matemático sobre funcionamiento colectivo de sistemas de agentes adaptativos utilizando la dinámica de juego como un mecanismo de adaptación. En los sistemas de dinámica de juegos, las estrategias ganadoras son premiadas, y los agentes utilizan las mejores estrategias para decidir su próximo movimiento.
|
||||
|
||||
|
||||
\subsubsection{Mecanismos de asignación de tareas}
|
||||
El esenario de asignación de tareas diná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íticas de control cuando lo determine apropiado (evitando cambios de tarea no necesarios).
|
||||
|
||||
El propósito de la asignación de tareas es asignar robots a las tareas de una forma que aumente el desempeño del sistema, lo que normalmente significa reducir el tiempo total de ejecución. Esto es, si todas las tareas toman igual cantidad de tiempo en completarse, en la mejor asignación, la fracción de robots en el estado \textit{i} será igual a la fracción de tareas de tipo \textit{i}. En general, sin embargo, la asignación deseada puede tomar otras formas, -- por ejemplo, puede estar relacionada a la recompensa relativa o costo de realización total (completing) de cada tipo de tarea -- sin cambiar nuestra aproximación. En el escenario de asignación diná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ñador es divisar un mecanismoque permita una asignació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é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ódicamente y actualiza su estado de acuerdo a una función de transición especificada por el diseñador \cite{LG03} \cite{CVJ03}.
|
||||
|
||||
|
||||
\subsection{Analisis de Asignción Automática de Tareas}
|
||||
|
||||
En esta sección asumiremos que existen dos tipos de tareas, -- denominadas de forma arbitraria \textit{red} y \textit{green}. Esta simplificación se hace con fines pedagó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ándolas, evitando obstáculos, etc. Sin embargo, ya que lo que se desea es modelar como evoluciona en el tiempo la fracció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ón de tareas}
|
||||
En esta sección estudiaremos en mecanismo en el cual los robots hacen decisiones paea cambiar de estado de tarea basándose únicamente en la observació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ó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ón de tal forma que la fracción de tiempo que el robot esté en el estado Red (Green) sea igual a la fracción de tareas Red (Green). Esto asegura que en promedio el número de robots Red y Green refleja la distribució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ía elegir cada estado con probabilidades igual a la fracción de las tareas del tipo correspondiente. Dicho conocimiento no está disponible; por eso, se desea investigar comoo el observamiento incompleto del entorno (a través de observaciones locales) así como de los cambios dinámicos del mismo (por ejemplo, cambiando la relación entre tareas Red y Green), afectan la asignación de tareas.
|
||||
|
||||
\subsection{Recolección múltiple con Múltiples Robots}
|
||||
|
||||
\subsubsection{Descripción de la tarea}
|
||||
La tarea tradicional de recolecció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ún \cite{DGMJM02}. La recolección múliple, es una variación de la recolecció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ón de un tipo en un instante de tiempo dado. Adicionalmente, todos los robots están recolectando todo el tiempo, es decir, no existen robots en estado de ``inactividad''. Un robot puede cambiar el tipo de objeto que está recolectando de acuerdo a su polí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ó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ón o la velocidad de convergencia a la asignación de tareas deseada. \textbf{Nos reservamos el estudio del impacto de la variación de densidad para trabajos futuros}}
|
||||
|
||||
El papel de la asignación diná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ón de robots converja a una situación en la que la proporción de robots recolectando objetos \textit{PuckRed} sea igual a la proporción de objetos \textit{PuckRed} presentes en la arena.
|
||||
|
||||
Se ha observado que las capacidades limitadas de sensado y la falta de comunicación directa de los robots, les impide adquirir información global tal como el tamaño y forma de la arena de recolecció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ípica para aumentar el conocimiento del robot sobre el entorno}
|
||||
|
||||
\subsubsection{Controlador del robot basado en funcionamiento}
|
||||
|
||||
Todos los robots tienen controladores idé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áculos en su camino.
|
||||
\item El comportamiento \textit{wandering (caminar sin una dirección determinada)} provoca que el robot se mueva hacia adelante y, después de un lapso de tiempo aleatorio, gire a la izquierda o a la derecha describiendo un arco aleatorio por un perí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ón de sus sensores y almacene los objetos y robots detectados en su respsctiva historia. El robot entonces actualiza su estado de recolección basado en esas historias.
|
||||
\end{itemize}
|
||||
|
||||
|
||||
\begin{tabular}{|c|c|c|c|c|}
|
||||
\hline
|
||||
\multirow{2}{1.8cm}{Obstáculo Detectado} & \multirow{2}{1.8cm}{Objeto Detectado} & \multirow{2}{2.7cm}{Gripper Break-Beam On} & \multirow{2}{2cm}{Señal de Observació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ón de los comportamientos}
|
||||
|
||||
Todos los robots mantienen tres tipos de información de estado: estado de recolecció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úa como una comunicación local, pasiva.
|
||||
|
||||
|
||||
Todos los robots mantienen una historia limitada de tamaño constante donde se almacena el estado de recolección de los robots observados recientemente. Ninguna de estas historias contiene una identidad única o localización de los objetos o robots detectados.
|
||||
|
||||
|
||||
Después que el robot hace una observación, hace una re-evaluación y cambia de forma probabilística su estado actual de recolección dadas las nuvas historias de objetos y robots. La probabilidad con la cual el robot cambia su estado de recolección se define con la función de transición.
|
||||
|
||||
|
||||
|
||||
|
||||
|
564
course/.docs/book/review.tex
Normal file
564
course/.docs/book/review.tex
Normal file
@ -0,0 +1,564 @@
|
||||
\chapter{TRANSFERENCIA TECNOLÓ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ía según Van Gigch involucra la adquisición de "actividad Inventiva" por parte de usuarios secundarios. Es decir, la
|
||||
transferencia tecnológica no involucra necesariamente maquinaria o dispositivos físicos. El conocimiento puede ser transferido a través de entrenamiento y
|
||||
educación, y puede incluir temas como manejo efectivo de procesos y cambios tecnológicos\cite{FBFP07} .
|
||||
|
||||
La transferencia tecnológica es un proceso dinámico que debe ser re-evaluado periódicamente, requiere una infraestructura adecuada que involucra
|
||||
instituciones, institutos de formación vocacional, técnica y administrativa, personal con diferentes especialidades y un entorno cultural adecuado.
|
||||
Es difícil que la tecnología desarrollada en un entorno determinado pueda ser transferida sin realizar modificaciones en la escala de producción y
|
||||
la adopción de productos al mercado local.
|
||||
|
||||
La transferencia de tecnología ha introducido técnicas de alta productividad y en muchos casos cambios técnicos en países menos desarrollados.
|
||||
La adquisición de tecnología foránea contribuye a mejorar la competitividad en los mercados locales e internacionales en estos países, en los que debe
|
||||
ser considerada como un proceso vital. Este proceso presenta problemas cuando se pierde capacidad de absorción por parte del país receptor y la
|
||||
renuencia del país que transfiere a transferir tecnología real y el know-how. Por lo que es necesario que estos países promuevan sus capacidades
|
||||
tecnológicas locales con el fin de absorber las tecnologías foráneas de forma eficiente en función de sus necesidades locales y de esta forma forma
|
||||
generar un rápido proceso de industrialización.
|
||||
|
||||
No debe confundirse la transferencia tecnológica con la apropiación de tecnología que se define como el proceso de interacción con la tecnología,
|
||||
la modificación de la forma como es usada y el marco social dentro del cual es usada. Un ejemplo de apropiación de tecnología lo podemos encontrar
|
||||
en la telefonía celular, nuestras sociedades han cambiado drásticamente su forma de comunicarse y han generado nuevas actividades alrededor de esta
|
||||
tecnología, los usuarios pueden generar aplicaciones que adicionan funcionalidades y servicios.
|
||||
|
||||
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|
||||
%%% DEFINICION DE TRANSFERENICA TECNOLOGíA %%%%%%
|
||||
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|
||||
\section{Tecnología}
|
||||
|
||||
La tecnologí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ó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ía \cite{FBFP07}:
|
||||
|
||||
\begin{itemize}
|
||||
\item Techno-ware Relacionado con objetos: Herramientas, equipos, máquinas, vehículos, facilidades físicas, instrumentos, dispositivos y fábricas
|
||||
\item Human-ware Relacionado con personas: Habilidades en conocimiento experimental, sabiduría y creatividad, experiencia, competencia, creatividad.
|
||||
\item Info-ware Relacionado con la Información: Incluye todo tipo de documentación y datos acumulados relacionados con especificación de procesos,
|
||||
procedimientos, diseños, teorías, y observaciones
|
||||
\item orga-ware Relacionado con la Organización: Acuerdos y Alianzas necesarias para facilitar la integración de los componentes Técnico, Humano, y
|
||||
de información. Involucra asignación, sistematización, organización, redes de comunicació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íficas para poder ser utilizado. Para mejorar la eficiencia del sistema el componente humano necesita de adaptación y motivación. A medida que la
|
||||
organización cambia para adaptarse a nuevas condiciones o requerimientos se debe actualizar el sector de la información. \textbf{No es posible realizar
|
||||
operaciones de transformación ante la ausencia de uno de estos cuatro componentes}
|
||||
|
||||
La interacción de estos cuatro componentes puedes ser resumida de la siguiente forma:
|
||||
|
||||
\begin{itemize}
|
||||
\item \textit{Tecnoware} constituye el núcleo de cualquier tecnología, es decir, una habilidad de transformación, y es desarrollada, instalada y operada
|
||||
por \textit{humanware}.
|
||||
\item \textit{Humanware} o las habilidades individuales representan el elemento clave de cualquier operación de transfomació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ón.
|
||||
Orgaware se compone de las actividades de planeación, organización, activación, motivación y control de operaciones.
|
||||
\end{itemize}
|
||||
|
||||
|
||||
La tecnología no esta asociada a un sistema socio-económico abstracto. La tecnologí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óricas de
|
||||
diferentes grupos sociales \cite{KGSB95}. En resúmen, la tecnología esta compuesta de conocimiento, herramientas, técnicas y actividades utilizadas
|
||||
para transformar las entradas de la organización en salidas.
|
||||
|
||||
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|
||||
%%% DEFINICION DE TRANSFERENICA TECNOLÓGICA %%%%%%
|
||||
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|
||||
\section{Definición}
|
||||
|
||||
Odedra \cite{Mo94} define la transferencia tecnoló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ógica se considera exitosa cuando los receptores de la tecnología asimilan los conceptos
|
||||
anteriores para suplir sus necesidades locales.
|
||||
|
||||
Según Jolly \cite{Jol77} La innovación tecnológica es entendida como un nuevo método, medio o capacidad del individuo para realizar una determinada actividad. El resultado de la transferencia tecnológica puede ser la aceptación de una práctica común en otros lugares, o la aplicación de una técnica
|
||||
diseñada para otro uso en la salución de problemas locales, debe distinguirse del proceso general de difusión de tecnología: un movimiento no planeado de artículos sociales y tecnológicos de un lugar a otro sin ningún esfuerzo centrado en la transferencia. La transferencia tecnológica incluye la difusión de conocimiento científico y la preocupación por la transformación del conocimiento en innovaciones útiles. El conocimiento es lo que queda al final de un proceso documentado y difundido de forma apropiada. Para que la transferencia tecnológica sea exitosa es necesario transferir los componentes de la tecnología, es decir: Los conocimientos técnicos, las habilidades humanas, la información y la estructura de la organización.
|
||||
|
||||
\subsection{Tipos de Transferencia Tecnológica}
|
||||
|
||||
Mansfield clasifica la transferencia tecnológica en transferencia de material, diseño y capacidades, la transferencia de material no constituye una transfencia tecnoló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ógicos: Materiales, productos finales, componentes, equipos
|
||||
\item Transferenica de diseño: Diseños, proyectos, know-how para fabricar productos diseñ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ías
|
||||
existentes para producir nuevos productos.
|
||||
\end{itemize}
|
||||
|
||||
La transferencia de diseños permite adquirir mayor conocimiento sobre la tecnología transferida, sin embargo, es necesario que el pais receptor cuente con la plataforma tecnológica adecuada para absorver estos conocimientos, de lo contario no se generarán nuevos productos y las actividades se limitará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á asociada a una transferencia de conocimiento, lo cual es vital para entender plenamente la tecnología, mejorando las habilidades de los profesionales del receptor.
|
||||
|
||||
Otra clasificación distingue entre Transferencia Vertical y Horizontal:
|
||||
|
||||
\begin{itemize}
|
||||
\item Transferencia Vertical: Transferencia de información técnica a diferentes niveles de un proceso innovativo determinado. Por ejemplo de
|
||||
investigación básica a investigación aplicada, de investigación aplicada a desarrollo y de desarrollo a producción. es decir, una progresión
|
||||
tecnológica desde la teoría al producto terminado.
|
||||
\item Transferencia Horizontal: Cuando se utiliza en un lugar, organizació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émicos, transferencia entre la academia y la empresa para generar aplicaciones, prototipos y producción en masa. La desconcexión entre la Universidad y la empresa en Colombia y en la mayoría de los países en desarrollo hace que los objetivos que persigue la Academia no está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ógica para hacerlo o porque la Universidad no proporciona el soporte necesario para que ese producto pueda ser utilizado en la práctica.
|
||||
|
||||
\subsection{Canales Para la Transferencia de tecnología}
|
||||
|
||||
Erdilec and Rapoport [45] clasifican los mecanismos en Formales: Acuerdos de licenciamiento, Inversión extranjera, compañías conjuntas, acuerdos de cooperación en investigación, arreglos de producción conjunta e Informales: No involucran acuerdos entre las partes y son difíciles de detectar y monitorear, por ejemplo, exportación de productos tecnológicos o bienes de capital, ingeniería inversa, intercambio de personal técnico y científico, conferencias de ciencia y tecnología, ferias y exposiciones, educación y entrenamiento realizado por extranjeros, visitas comerciales, literatura abierta (artículos, revistas, libros técnicos), espionaje industrial. Adicionalmente, existe una división basada en la naturaleza de la institución que proporciona los recursos para que se realice la transferencia, la institución puede ser de carácter:
|
||||
|
||||
\begin{itemize}
|
||||
\item \textit{Abierta} en donde la tecnología y el conocimiento són considerados bienes públicos, no existen restricciones para acceder a la información necesaria para adquirir, usar y transformar estos conocimientos en productos comerciales, y su éxito radica en obtener la máxima difusión posible para que los usuarios de este conocimiento mejoren el material existente y contribuyan con experiencias personale,
|
||||
\item \textit{Cerrada} La tecnología y el conocimiento se genera para fines privados, la utilización de este conocimiento esta sometida a acuerdos comerciales. No es posible entender las bases de la tecnología, por lo que no se pueden generar productos derivados.
|
||||
\end{itemize}
|
||||
|
||||
Las actividades realizadas durante este estudio están enmarcadas dentro del concepto: \textit{El conocimiento es un Bien Común}, toda la documentació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és de listas de discusión, adicionalmente se proporciona soporte comercial para permitir la producción de estas modificaciones. A continuación se realiza una descripción de los canales más utilizados para la transferencia de tecnología y conocimiento en países en vía de desarrollo (\cite{MO90} \cite{Mo94} \cite{MO91}) indicando en cada caso sus ventajes, limitaciones y desventajas.
|
||||
|
||||
\subsubsection{Adquisición de IT}
|
||||
|
||||
La adquisición de equipo ha sido uno de los mecanismos de transferencia más importantes para los paí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ón personalizada a las necesidades de los clientes. La
|
||||
transferencia tecnológica se presenta en el proceso de personalización, esto, unido a otras habilidades en programación ayudan a elevar
|
||||
el mercado de SW local. Sin embargo, en muchas ocasiones no se detectó ningún tipo de transferencia de knowhow en la adquisició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ñas compañías locales, lo que se traduce en que el mantenimiento y servicios asociados al hardware, así como los ajustes de Software
|
||||
sean realizados por los proveedores de las multinacionales y en muy pocos casos los usuarios de esta tecnologí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ón con la venta de equipos se transmite únicamente el conocimiento para operar, programar o mantener, sin embargo,
|
||||
este conocimiento sobre el sistema puede ayudar a concientizarse sobre la tecnología e impulsar la formación de capital humano.
|
||||
|
||||
La experiencia de países que lograron un rápido desarrollo económico e industrial muestra que la adquisición de una gran cantidad de
|
||||
tecnología foránea jugó un papel importante en este proceso. Colombia ha realizado un proceso de transformación tecnológica pero no ha
|
||||
diseñado políticas efectivas y eficientes para la transferencia de tecnologías de alto nivel
|
||||
.
|
||||
|
||||
\subsubsection{Educación y Entrenamiento}
|
||||
Educar a las personas a través de cursos y entrenamiento en el país y enviándolas al extranjero para otros estudios es una forma de adquirir
|
||||
know-how sobre nuevas tecnologías, o tecnologías que no se utilizan en el país de origen. Muchas instituciones ofrecen carreras en
|
||||
Ingeniería Electrónica, Ciencias de la computación y afines, algunas de ellas utilizan modelos pedagógicos utilizados en países desarrollados,
|
||||
los que no han sido adaptados plenamente a la infraestructura tecnológica local, y no es raro encontrar estudiantes que no están satisfechos
|
||||
con su profesión al finalizar los cursos\cite{Mo94}.
|
||||
|
||||
En muchas Universidades temas como Nanotecnología, Diseño de Circuitos integrados de muy alta integración (VLSI) hacen parte importante de las
|
||||
actividades de investigación; la pertinencia de estos tópicos avanzados ante la situación tecnológica del país es discutible ya que muchos
|
||||
estudiantes no aplicarán nunca estos conocimientos en el entorno local, por lo que la enseñanza de estos tópicos puede resultar una pérdida de
|
||||
recursos. Es más, con los rápidos cambios en la industria electrónica estos conocimientos pueden resultar irrelevantes, aún si la
|
||||
infraestructura del país se mejora. Es decir, es importante no dejarse llevar por el momento, o por la "fama" de un tópico de investigación
|
||||
o de una tecnología novedosa, es necesario evaluar la pertinencia de los cursos que se dictan en el entorno tecnológico local, por supuesto,
|
||||
es necesario que la academia impulse cambios en el sector, pero estos cambios deben ser consecuentes con el nivel tecnológico que posea el país.
|
||||
|
||||
La transferencia tecnológica no ocurre cuando estudiantes formados en el exterior no pueden aplicar sus conocimientos en su país de origen,
|
||||
por lo que es necesario crear políticas que definan que áreas de estudio son prioritarias para el país.
|
||||
|
||||
Las multinacionales también ofrecen cursos de capacitación, sin embargo, se limitan al uso de sus productos, creando dependencia hacia
|
||||
sus herramientas. Adicionalmente, existen centros privados de capacitación que ofrecen cursos para el manejo de paquetes y lenguajes de
|
||||
programación, estos centros aprovechan la falta de centros de enseñanza tecnológica y personal calificado para cobrar altas sumas de dinero,
|
||||
lo cual limita el acceso. Programas académicos inapropiados, acceso limitado a libros y computadores, falta de facilidades para capacitación, reduce la efectividad
|
||||
de la educación y capacitación como canal para la transferencia tecnoló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ía un gran esfuerzo
|
||||
y posiblemente se tendrí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án familiarizados con las condiciones y requerimientos locales, con lo que diseñan soluciones que no se
|
||||
ajustan perfectamente a las necesidades, lo que significa que el sistema es sub-utilizado y la transferencia de tecnologí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án dirigidas a aumentar la dependencia
|
||||
con los productos generados por dichas transnacionales y a ignorar de forma sistemática opciones que pueden ayudar a la transferencia de conocimiento,
|
||||
llegando hasta el punto de influir en la formulación de políticas para transferencia tecnoló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ó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 ú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ón con otros instrumentos como investigación extranjera, importación de maquinaria o de técnicos. Sin embargo, no es efectivo si no
|
||||
se acompaña de habilidades administrativas y de producción. Adicionalmente, es necesario contar con una infraestructura tecnológica adecuada,
|
||||
capacidades locales de fabricación de hardware y software y políticas de gobierno adecuadas \cite{Mo94}.
|
||||
|
||||
Un ejemplo de este tipo de práctica se presenta en el ensamble de dispositivos electrónicos, todos los componentes se importan completamente
|
||||
terminados y el dispositivo final es ensamblado probado y se carga la configuración inical, no se producen actividades de ingeniería inversa con
|
||||
lo que se transmite muy poco conocimiento.Odedra \cite{Mo94} define la transferencia tecnoló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ógica se considera exitosa cuando los receptores de la tecnologí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íticas de protección de los productos generados
|
||||
localmente, países de latinoamerica aplican este tipo de protecciones y solo permiten la importación de productos que no se fabriquen en el país.
|
||||
Esto aumenta la confianza en los productos generados localmente e impulsa el desarrollo industrial y la generación de empleo.
|
||||
|
||||
\subsubsection{Inversión Extranjera Directa}
|
||||
|
||||
La inversión directa de multinacionales es una forma de obtener tecnología externa. Esto asegura una rápida transferencia de información
|
||||
tecnológica, pero no necesariamente del entendimiento o know-how. Lo que hace que la tecnología transferida a través de este canal sea mínima.
|
||||
Las grandes multinacionales pueden tener cierto control político en los países en vía de desarrollo, hasta tal punto que son asesores de
|
||||
instituciones encargadas de fijar políticas para la transferencia tecnológica \cite{Mo94}.
|
||||
|
||||
El objetivo de la transferencia tecnoló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íses desarrollados y en vía de desarrollo. La compra de equipo o de software transfiere muy poco conocimiento
|
||||
sobre la tecnología, el servicio post-venta y el mantenimiento es realizado por el proveedor. Por otro lado, las facilidades en educación y capacitación
|
||||
son limitadas lo cual obstaculiza la formació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ón}
|
||||
|
||||
La efectividad de cada canal depende de la naturaleza de la tecnología que se va a adquirir, el tipo de organización y de las capacidades de absorción del recipiente. La tecnología es efectiva únicamente cuando la economía del país es capaz de utilizarla. Cuando se transfiere una tecnología se debe contar con el dinero para adquirirla y se deben generar las actividades necesarias para mejorar la plataforma tecnológica, incluyendo la educación y la capacitación, de tal forma que el país sea capaz de absorberla y generar nuevos productos que satisfagan necesidades locales.
|
||||
|
||||
El éxito de la transferencia tecnológica no depende de un factor único, sino de la confluencia de multiples factores dentro y fuera de la institución académica. Las relaciones personales entre los agentes de transferencia tecnológica y la facultad, licencias corporativas, y las comunidades de investigación y de negocios son la clave de esfuerzos exitosos. En muchos casos, las Universidades han liderado el proceso de transferencia tecnológica a través de sus directivos, estos a través de incentivos crean una cultura académica que recompensa la transferencia tecnológica y el emprendimiento.
|
||||
|
||||
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|
||||
%%% Modelo %%%%%%
|
||||
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|
||||
|
||||
\section{Modelo}
|
||||
|
||||
Un programa de transferencia tecnológica bebe incluir mecanismos que unan de forma eficiente la fuente del conocimiento con la utilización del mismo.
|
||||
Estos canales de comunicació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ó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ía} \label{tech_trans_model_global}
|
||||
\end{figure}
|
||||
|
||||
|
||||
\subsection{Los factores formales}
|
||||
|
||||
\subsubsection{Documentación}
|
||||
Es el formato, organización, o presentación de la tecnología que será transferida. El formato y el lenguaje se relacionan directamente con el entendimiento del material por parte del receptor. La información que no se entiende no se utiliza. Los científicos e ingenieros ocupan hasta 4 horas diarias leyendo artículos, hablando con sus pares o buscando informació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ón}
|
||||
Constituye el canal físico a través del cual la tecnología fluye e involucra tanto el número de entradas y el fácil acceso al canal, así como el plan de distribución. knox 1973, dice: "Una medida de la efectividad del sistema de información tecnológica es al capacidad de permitir el contacto entre personas con necesidades y con posibles soluciones. Ames 1965, Encontró que los abstracts y los papers son la fuente de información más importante, mientras que las reuniones y conferencias el mejor vehículo para crear conciencia, la cual es indispensable para que el proceso de distribución sea exitoso, por lo que, el intercambio personal debe ser considerado como parte del proceso de distribución de tecnología. Este canal ayuda a eliminar retardos en la investigación, ya que permite determinar el estado del arte de una determinada actividad o área de trabajo.
|
||||
|
||||
|
||||
\subsubsection{Organización}
|
||||
La percepción del receptor de la organización. Schon 1967, caracteriza a una organización que es favorable a la transferencia tecnológica y utilizació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íficos e ingenieros donde algunos de ellos sienten que una organización ocasionalmente puede actuar como una barrera a las nuevas ideas.
|
||||
|
||||
|
||||
\subsubsection{Selección de Proyectos}
|
||||
|
||||
Proceso de selección para proyectos de investigación y desarrollo realizado por el proveedor con ayuda del receptor. Es importante que la investigació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ía Indicando La Composición de Los Canales Formales e Informales} \label{tech_trans_model}
|
||||
\end{figure}
|
||||
|
||||
|
||||
\subsection{Factores Informales}
|
||||
Los factores informales son de naturaleza sociológica y/o comportamental, y contribuyen fuertemente al éxito de la utilización del conocimiento por una determinada organización.
|
||||
|
||||
\subsubsection{Capacidad}
|
||||
La capacidad del usuario para utilizar nuevas ideas que cubren un amplio espectro de rasgos que incluyen riesgo, riqueza, poder, educació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ón receptora. El enlace opera dentro de la organización receptora y exhibe características similares al supervisor, líder de opinión, innovador y previo conocedor de la innovación.
|
||||
|
||||
|
||||
\subsubsection{Credibilidad}
|
||||
|
||||
La credibilidad es una evaluación por parte del usuario, de la confiabilidad de la información. Es evaluada analizando la fuente y el canal del mensaje. La opinión cambia dependiendo de la fuente de la informació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ón}
|
||||
|
||||
La habilidad y/o deseo del individuo para aceptar un cambio en la organización de la cual es miembro. Así mismo es importante la capacidad de adopción de nuevas ideas, Gallup 1955 señaló que aunque una idea halla sido aceptada intelectualmente, toma un perí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ón, un interés, una motivación personal para utilizar un mejor método, proceso o concepto.
|
||||
|
||||
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|
||||
%%% Historia %%%%%%
|
||||
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|
||||
|
||||
\section{Transferenica Tecnológica en Latinoamérica \cite{UNE}}
|
||||
|
||||
\subsection{Trasfondo histórico}
|
||||
|
||||
Durante el período que va de los años 40 a la década de los 80, en América Latina y el Caribe se puso en práctica una política de
|
||||
industrialización por sustitución de importaciones mediante modalidades de proteccionismo de la industria manufacturera local.
|
||||
Con lo que se comenzó a importar los bienes de capital necesarios para la fabricación en el ámbito local, desarrollando
|
||||
de esta forma a las industrias locales. Mientras tanto, en los países de donde provenían estos bienes, se transformaba el conocimiento
|
||||
adquirido de la investigación, en nuevos productos, procesos y modelos de gestión más competitivos. Es decir, se importaron los equipos
|
||||
para realizar la transformación industrial, pero no se generaron las bases científico-tecnológicas que se encargaran de generar nuevos
|
||||
productos asociados a las materias primas proporcionadas por los recursos naturales locales, se descuidó el capital humano capaz de entender,
|
||||
adaptar y llevar estos inventos a la sociedad, salvo en algunas disciplinas agrícolas donde la especificidad local obligó a la investigación.
|
||||
Adicionalmente, no se generó demanda local que impulsara la producción de conocimiento, las nuevas empresas no contaban con departamentos de
|
||||
Investigación y desarrollo (I+D) y los gobiernos no estimulaban la creación de centros de investigación asociados a este proceso de industrialización.
|
||||
|
||||
Cuando los gobiernos de la región se dieron cuenta de esta situación crearon la Comisión para América Latina y el Caribe (CEPAL). A partir
|
||||
de las décadas de los cincuentas y setentas comenzaron a crear políticas en las áreas científicas y tecnológicas, creando instituciones
|
||||
destinadas al fomento de la ciencia y la tecnologí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ía eran una usina de crecimiento, en un rico
|
||||
suelo fertilizado por el deseo de la modernización y el desarrollo") exhibieron una continuidad notable. Esto unido al apoyo gubernamental y
|
||||
el interés de las universidades fue clave para la formulación de políticas de apoyo a la ciencia y la tecnología.
|
||||
|
||||
Gracias a estas políticas hubo un fuerte proceso de institucionalización de la investigación científica y de los mecanismos de desarrollo:
|
||||
Sistemas de promoción del I+D, legislación en transferencia de tecnología, planificación de la ciencia, métodos de diagnóstico de recursos,
|
||||
sistemas de fijación de prioridades tecnoló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ámica sostenida de innovación en el
|
||||
conocimiento y en la economía ya que en muchos sectores no se generó un vínculo sólido entre la producción y la investigación, esto debido a la
|
||||
creación de dos modelos de investigación en ciencia y tecnología:
|
||||
\begin{itemize}
|
||||
\item Ciencia Académica: Basada en las universidades, es incorporada a la comunidad científica internacional, de quien recibe legitimidad, orientación,
|
||||
organización.
|
||||
\item Actividad Tecnológica: Sustentada por organismos sectoriales, legitimada por instituciones estatales, su objetivo es dar solución a problemas
|
||||
prácticos y a la transferencia de tecnología al sector productivo.
|
||||
\end{itemize}
|
||||
|
||||
En los años 80 disminuyó la confianza de poder encontrar un camino hacia un desarrollo endógeno, lo que originó un giro hacia políticas de ajuste,
|
||||
estabilización y apertura de la economía que buscaban vías alternas para llegar a la globalización. La apertura de la economía suponí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ía una homogeneización tecnológica, por lo que el aumento de la competitividad se lograría
|
||||
a través de la transferencia de productos externos y no la inventiva e innovación local.
|
||||
|
||||
En los años 90 los países de la regió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ón de muchas en importadores;
|
||||
esta política desmantela el aparato productivo y no fomenta actividades de adaptación, mejora y creación de productos. La oferta tecnológica
|
||||
proviene del exterior, se diluye el sistema nacional de ciencia y tecnología basado en el aumento de la oferta interna de conocimiento.
|
||||
Las políticas públicas se reducen a la aceptación de normas de la Organización Mundial de Comercio (OMC) basadas en presiones de Estados
|
||||
Unidos y la Unión Europea sobre patentes farmacéuticas, tecnologías agrícolas y de otros tipos. No es que no existan esfuerzos e interacciones tecnológicas entre la ciencia y la producción; el problema es que no constituyen un sistema autosostenido de relaciones dinámicas que marquen un rumbo claro a la investigación en ciencia y tecnología vinculado con las sociedades y las economías donde se desenvuelven.
|
||||
|
||||
Según Gibbons y Schwartzman, la investigación científica se origina y justifica cada vez más en el contexto de aplicación del conocimiento,
|
||||
es decir, en la posibilidad de su utilización. Por lo que los temas de investigación no son fijados por los cientí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ón disminuyan.
|
||||
En tal sentido, no es seguro que la inserción en el comercio internacional de América Latina favorezca su posición en la producción de
|
||||
conocimientos en ciencia y tecnología.
|
||||
|
||||
La ciencia y la tecnología en la región presenta dos grandes probleams: a) su escasa magnitud; b) su desvinculación con la sociedad a
|
||||
la que pertenece, con el agravante de la pérdida de legitimidad que se produjo en las últimas dos décadas, sustentada por una parte en
|
||||
el Estado, y en su integración en una ciencia internacional fuertemente académica, por la otra.
|
||||
|
||||
\subsection{Financiación}
|
||||
|
||||
Según la Red de Indicadores de Ciencia y Tecnología (RYCIT), el gasto en actividades de ciencia y tecnología en los paí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érica Latina y el Caribe, su inversión en I+D es más de 20 veces mayor que la latinoamericana. Dicho de otro modo, el esfuerzo de los países de la región en ciencia y tecnología es inferior al que les correspondería realizar tomando en cuenta el valor del producto regional.
|
||||
|
||||
Según la Organization for Economic Co-operation and Development (OCED) los países Latinoamericanos dedican en promedio algo más del 0,6\% de su Producto Interno Bruto a I+D. Esta inversió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ón Europea, en cambio, el porcentaje alcanza el 1,7\% del PIB, en Estados Unidos alcanza el 2,8\%, Japón (3,13\%), Corea del Sur (2,52\%) y otros como China e India en los cuales, aunque la inversión es algo inferior, la tendencia de los últimos años hace pensar en un aumento progresivo de sus inversiones en I+D. El gasto en ciencia y tecnologí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íses latinoamericanos a 59.000.
|
||||
|
||||
Un rasgo característico de la investigación científica en América Latina es su gran dependencia del Estado, según un estudio de la OCED, en el plano estrictamente tecnológico, las estadí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ña y Canadá, respectivamente. En Amé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í son valores marcadamente inferiores.
|
||||
|
||||
|
||||
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|
||||
%%% Obstaculo %%%%%%
|
||||
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|
||||
\section{Obstáculos para una Transferencia Exitosa}
|
||||
|
||||
La cantidad de conocimiento y tecnología transferida es afectada por políticas gubernamentales, la situación económica, facilidades de educación y capacitación, personal calificado, aspectos organizacionales y sociales, proveedores de tecnología e infraestructura tecnológica. El gobierno juega un papel importante en el proceso de transferencia tecnológica ya que puede invertir en la infraestructura para impulsar una determinada tecnología o colocar restricciones para des-estimular su uso. Estas políticas son dependientes de la situación económica del país y del entendimiento de la importancia de la transferencia por parte de de sus dirigentes. La falta de facilidades en educación y en capacitació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ís no lo permite. Las personas son las que finalmente absorben el know-how tecnológico, si no existe el suficiente personal disponible y dispuesto, el proceso de transferencia se detendrá.
|
||||
|
||||
La administración a nivel de organización juega el papel más importante en el proceso de transferencia tecnológica. La resistencia o el
|
||||
desconocimiento a la tecnología, la adquisición de tecnología por motivos particulares no contemplan la implementación y la capacitación.
|
||||
Por esta razón, es necesario que los encargados de tomar las decisiones y trazar políticas, conozcan la tecnología, o que estén conscientes de
|
||||
su importancia. La transferencia tecnológica debe ser un proceso de dos vías, por lo que es indispensable tener habilidades adecuadas en
|
||||
investigación, capacidades organizacionales y de ingeniería para que estos conocimientos sean asimilados y utilizados en la solución de
|
||||
problemas locales. Es necesario que la adquisición de tecnología obedezca a un plan y que esta tecnología supla una necesidad real, de
|
||||
lo contrario los equipos adquiridos y la capacitación recibida no serán utilizados, por otro lado, la tecnología adquirida que no es
|
||||
asimilada y transformada en herramienta para la solució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ógica.
|
||||
|
||||
Los procesos de transferencia tecnológica son influenciados de forma directo o indirecta por las infraestructuras organizacionales y
|
||||
tecnológicas de los países, los cuales, deben exceder sus capacidades para absorber la tecnología transferida. Esta transferencia es efectiva solo
|
||||
si la economía en la cual es introducida es capaz de utilizarla. Si un país cuenta con los recursos económicos necesarios para adquirir la tecnología,
|
||||
debe mejorar la infraestructura para soportarla, incluyendo la educación y las facilidades de entrenamiento, así como los enlaces de telecomunicaciones \cite{MO90}.
|
||||
|
||||
La falta de facilidades de educación y capacitación afecta la transferencia del knowhow, obstaculizando el desarrollo de habilidades a través del proceso de aprendizaje. La carencia de estas facilidades limita la difusión del conocimiento; la pérdida de estas habilidades se pueden originar porque la transferencia no se realizó o porque la infraestructura no lo permite.
|
||||
|
||||
Si no existen personas disponibles y dispuestas a absorber el knowhow el proceso de transferencia se detendrá. El proceso de transferencia
|
||||
tecnológico también es influenciado por la falta de políticas claras en la Tecnología de la Información, y los planes de negocios estratégicos,
|
||||
los cuales pueden identificar las necesidades que traerán beneficios a la nación o determinar lo que se puede lograr con los recursos disponibles.
|
||||
|
||||
Algunas políticas regulatorias sobre procesos de adquisición de hardware y software que existen en varios países obstaculizan los procesos de
|
||||
transferencia de tecnología. Al hacer convenios con multinacionales para suministro de tecnología, a menudo estas multinacionales no está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ón del producto y en el aumento de la dependencia del proveedor.
|
||||
|
||||
Las tecnologías de la Información deben ser utilizadas como una facilidad en el proceso de educación y capacitación, es necesario tomar
|
||||
conciencia de la importancia de la información a nivel organizacional y gubernamental.
|
||||
|
||||
La gran ausente en las políticas Tecnológicas parece ser la sociedad. Nada permite suponer que el interés de los cultores del campo
|
||||
se pretenda una democratización de la ciencia y la tecnología, una apropiación de su dinámica y de sus resultados por parte de la sociedad
|
||||
en su conjunto. Llama la atención que, por una parte, no existan trabajos o programas que destaquen desde un punto de vista
|
||||
crítico los impactos tecnológicos sobre la vida de la sociedad (calidad, tejido social, integración social, distribución de beneficios, etc.);
|
||||
por otro lado, no se registran estudios o programas de formación destinados a plantear la cuestión de la divulgación científica y tecnológica
|
||||
como procesos de apropiación simbólica por parte de los ciudadanos respecto de los contenidos de la ciencia y la tecnología.
|
||||
|
||||
|
||||
\section{Recomendaciones Para una Transferencia Tecnológica Exitosa}
|
||||
Estudios consultados \cite{MO90} \cite{IAI} \cite{MDAG99} \cite{DZSC+07} \cite{MTRR07} \cite{Mar04}, coinciden en que para dar solución a los problemas expuestos anteriormente se deben seguir las siguientes recomendaciones:
|
||||
|
||||
\subsection{Recomendaciones para los generadores de políticas}
|
||||
\begin{itemize}
|
||||
|
||||
\item{Promover la Importancia de la Transferencia Tecnológica como Motor de Desarrollo Económico}
|
||||
\begin{itemize}
|
||||
\item Proporcionar educación en transferencia tecnológica y comercialización a las nuevas instituciones académicas.
|
||||
\item Promover las asociaciones regionales de I+D.
|
||||
\item Tomar conciencia que la innovación involucra el desarrollo científico y tecnológico a varios niveles, por diferentes medios y a través de un amplio rango de instituciones académicas.
|
||||
\item Promover las actividades de Transferencia tecnológica que involucren transferencia de conocimiento que permita la creación de nuevos productos y servicios. Del mismo modo, desalentar la compra de equipo y software propietario como política para la transferencia tecnológica.
|
||||
\end{itemize}
|
||||
|
||||
\item{Fomentar la Generación de Empresas Locales de Base Tecnológica}
|
||||
\begin{itemize}
|
||||
\item Evaluar y abordar la transferencia de tecnología desde una perspectiva corporativa.
|
||||
\item Revisión de la política gubernamental de apoyo a las pequeñas empresas.
|
||||
\end{itemize}
|
||||
|
||||
\item{Promover el Mejoramiento de la Plataforma Tecnológica}
|
||||
\begin{itemize}
|
||||
\item Desarrollar sistemas de medición para capturar de forma efectiva el valor de las actividades relacionadas con la innovación.
|
||||
\item Crear un centro de intercambio de información para transferencia tecnológica y difundir la información de forma activa.
|
||||
\end{itemize}
|
||||
|
||||
\end{itemize}
|
||||
|
||||
\subsection{Recomendaciones para la academia}
|
||||
|
||||
\begin{itemize}
|
||||
\item{Actualización Curricular}
|
||||
\begin{itemize}
|
||||
\item Innovación
|
||||
\item Crear planes de transferencia de tecnología flexibles
|
||||
\item hacer compromisos con el desarrollo económico.
|
||||
\item Necesidad de mejorar las competencias y habilidades generales de los ingenieros, (continuo aprendizaje) habilidad para innovar, investigar, desarrollar nueva tecnología.
|
||||
\item Innovación curricular, actualización continua de profesionales.
|
||||
\item Incentivar la formación de maestrías y doctorados nacionales acorde con una agenda de investigació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ón de miembros de la industria a centros de investigación para formar relaciones formales e informales.
|
||||
\item Buscar tener fortalezas en áreas dominadas por las industrias locales
|
||||
\item Promover y soportar la Transferencia de Tecnología
|
||||
\item Fortalecer el espíritu empresarial para apoyar la comercialización
|
||||
\item Montar laboratorios de pruebas e incentivar a los productores nacionales para que logren una calidad que cumpla con los estándares internacionales.
|
||||
\end{itemize}
|
||||
|
||||
\item{Promover y Soportar la Transferencia Tecnológica}
|
||||
\begin{itemize}
|
||||
\item Elevar la transferencia tecnológica a un nivel superior y promover la excelencia.
|
||||
\item Concientizar a los creadores de políticas gubernamentales sobre la importancia de la transferencia tecnológica y las alianzas con la investigación industrial.
|
||||
\item Interacción entre Universidades, Conviene que buena parte de los trabajos realizados en doctorado sean de investigación aplicada, orientadas a mejorar la productividad del sector empresarial
|
||||
\item Infraestructura institucional que impulse la actualización tecnológica en el sector mediante desarrollo de proyectos de tecnología de punta con una posible transferencia de tecnología.
|
||||
\end{itemize}
|
||||
|
||||
\item{Búsqueda de Financiación para Investigación y Desarrollo}
|
||||
\begin{itemize}
|
||||
\item Buscar de forma agresiva fondos para la investigación.
|
||||
\item Crear recursos empresariales en las instituciones académicas, y enlazarlos con actividades de transferencia tecnológica.
|
||||
\item Aumentar las alianzas con fuentes de inversión de capital para nuevas empresas.
|
||||
\item Creación de empresas como parte del proceso de transferencia tecnológica de la institución y de los compromisos con el desarrollo económico
|
||||
\item Realizar seminarios y líneas de profundización de temas afines a la administración y la gerencia en empresas de base tecnológica.
|
||||
\end{itemize}
|
||||
|
||||
\end{itemize}
|
||||
|
||||
|
||||
\subsection{Recomendaciones para el Gobierno}
|
||||
\begin{itemize}
|
||||
|
||||
\item{Promover la Relación Universidad-Empresa}
|
||||
\begin{itemize}
|
||||
\item Fomento a centros de investigación y productividad para fortalecer la relaciones universidad empresa.
|
||||
\item Fomentar la colaboración Universidad-Empresa en I+D, mediante la financiación de becas de cooperación, centros de investigación e incentivos fiscales.
|
||||
\item Crear estrategias para mejorar la relación Universidad - empresa, creando premios para casos exitosos de transferencia tecnológica.
|
||||
\item Educar a las instituciones académicas sobre los recursos empresariales locales.
|
||||
\item Trabajar con corporaciones y fundaciones para el fomento de patrocinios y participación en transferencia de tecnología, I+D y desarrollo empresarial.
|
||||
\item Desarrollar o mejorar infraestructuras regionales para capturar y retener empresas creadas en las instituciones académicas.
|
||||
\end{itemize}
|
||||
|
||||
|
||||
\item{Formular políticas Para Incentivar Actividades de Transferencia Tecnológica}
|
||||
\begin{itemize}
|
||||
\item Fomentar en líderes universitarios el compromiso con el desarrollo económico.
|
||||
\item Definir agendas de investigación acordes con las tendencias mundiales y desarrollar capacidades en el país.
|
||||
\item Fomentar cooperación internacional e inversión extranjera con transferencia de tecnología. a nivel gubernamental, Apoyo del gobierno a personas que tienen un alto potencial de crear y desarrollar tecnología.
|
||||
\item Mejorar la plataforma Tecnológica.
|
||||
\end{itemize}
|
||||
|
||||
|
||||
\item{Promover la Excelencia Académica y la Investigación}
|
||||
\begin{itemize}
|
||||
\item Promoción de las instituciones académicas como bienes económicos
|
||||
\item Trabajar con las instituciones académicas para identificar sus competencias.
|
||||
\item Proporcionar fondos para temas específicos de investigación en instituciones académicas.
|
||||
\item Promover la Investigación y Desarrollo y la transferencia tecnológica
|
||||
\item Promover la investigación, la colaboración, la transferencia tecnológica y el desarrollo empresarial.
|
||||
\item Ayudar a las instituciones académicas a evaluar su impacto sobre las economías locales y difundir los resultados a las instituciones gubernamentales.
|
||||
\end{itemize}
|
||||
|
||||
\end{itemize}
|
||||
|
||||
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|
||||
%%% CONCLUSIONES %%%%%%
|
||||
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|
||||
|
||||
|
||||
\section{Actividades Prioritarias Para Obtener Una Transferencia de Tecnología Exitosa}
|
||||
|
||||
Las Anteriores recomendaciones coinciden en que para que se presente una Transferencia Tecnológica exitosa, es decir, para que los elementos técnicos, habilidades humanas, la documentación y la organización asociadas a una determinada tecnología, puedan ser asimilados por personal calificado (disponible y dispuesto) para posteriormente transformar estos conocimientos en la creación de nuevos productos o servicios que suplan necesidades locales es necesario:
|
||||
|
||||
\textbf{Fomentar la Creación de Empresas de Base Tecnológica} El gobierno debe crear facilidades y créditos para que empresas tecnológicas con la capacidad de innovación puedan realizar su actividad comercial (productos o servicios) y de esta forma crear nuevos empleos, aumentar la demanda de servicios tecnológicos. Así mismo, las universidades deben crear empresas que comercialicen productos derivados de sus actividades de Investigación.
|
||||
|
||||
\textbf{Promoción de la Transferencia Tecnoló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ón que puedan ser utilizados por el sector productivo a corto o mediano plazo. Las políticas de gobierno deben desalentar la compra de equipo que solo transfiera conocimiento sobre su operación y no permita la creación de nuevos conocimientos a partir de ellos, asi mismo, debe formular políticas que protejan las empresas locales de base tecnológica impidiendo el ingreso de productos similares provenientes del mercado asiático premiando a las empresas locales que realicen productos innovadores ya sea con beneficios tributarios temporales o con la adjudiación de créditos condonables destinados al desarrollo de nuevos productos. Universidad, Gobierno e Industria deben trazar políticas que definan las áreas en las que se deben formar los profesionales en el exterior, las cuales deben estar en sintonía con el estado de la plataforma tecnológica y el sector productivo, estas políticas deben cambiar a medida que se mejora la plataforma tecnológica local y se presentan cambios en el entorno mundial. Se debe trabajar en la creación de una cultura de la Transferencia Tecnológica, resaltando su importancia para el desarrollo del país.
|
||||
|
||||
\textbf{Promover la Excelencia Académica} Debe exisitir una evaluación continua de los planes acadé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ón de maestrías y doctorados que sigan políticas nacionales encaminadas al desarrollo económico y crear mecanismos de medición que permitan comparar y clasificar las instituciones académicas según las competencias de las habilidades (liderazgo y emprendimiento) de sus egresados y de esta forma determinar que instituciones son merecedoras de créditos, becas, o financiación para desarrollar actividades.
|
||||
|
||||
Los centro de educación de diferentes niveles deben trabajar de forma conjunta para definir los objetivos y habilidades que requiere el sector productivo a nivel de formación tecnoló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án definidos, esto debido a la falta de producción tecnológica del pais, somos un país consumidor de tecnologí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ón por la cual lo ingenieros tienen problemas a la hora de conseguir empleo. Esta situación se vuelve crítica debido a la gran cantidad de programas de Ingeniería que se crearon en Colombia, solo en la Universidad Nacional de Colombia se gradúan cerca de 60 ingenieros electrónicos al año.
|
||||
|
||||
"Para hacer esto posible se requiere una comisión de regulación de la educación superior que vele, especialmente, por la calidad de los diferentes programas. Ésta debe ser una comisión independiente y mixta con la participación del sector privado. Por otra parte, es menester tener en cuenta que el programa planteado requerirá un incremento sustancial de inversión en la oferta docente, tecnológica y de investigación'" \footnote{Publicado en el Espectador: 16 de julio 1999 `\textit{Urge elevar la competitividad} Santiago Montenegro}
|
||||
|
||||
\textbf{Promover la Relación Universidad Empresa} El sector productivo debe ser el principal inversionista para las actividades de Transferenica Tecnológica e Investigación y Desarrollo, ya que es el directamente beneficiado con ellas. El gobierno debe desalentar las prácticas comerciales que no generan actividades de I+D, en especial las que solo comercializan productos manufacturados en países asiá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ón en Investigación y Desarrollo. La academia debe proporcionar a la industria herramientas que le permitan competir con productos provenientes del mercado asiático, es una realidad que a corto plazo no podemos competir con la industra manufacturera asiática, pero si podemos utilizarla para producir productos diseñados en el país, por Colombianos, para satisfacer necesidades locales. Se debe crear consciencia en la industria de las ventajas de tener productos diseñ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ón de políticas gubernamentales sobre educación e Investigación y Desarrollo, para esto es vital determinar que acividades económicas contribuyen al desarrollo tecnológico, cuales son generadoras de conocimientos y de esta forma incentivar su práctica. Por otra parte, las Universidades deben continuar con sus labores de investigación en temas de actualidad y aumentar la visibilidad de la academia colombiana en el entorno centí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ógica actual. Los centros acadé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ó anteriormente Colombia es el país de Sur-América que menos invierte en Investigación y Desarrollo, por esta razón es necesario crear alianzas estratégicas para compartir los escasos recursos disponibles, en la actualidad no existe una red nacional de Universidades que trabajen conjuntamente en temas tecnoló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ómicos, de infraestructura y de equipos, adicionalmente tiene una muy buena relación con pequeñas empresas y conoce las necesidades de este sector, la función del SENA es proporcionar formación a nivel técnico que soporte las actividades de las empresas Colombianas, sin embargo, los centros de educación superior no utilizan esta coyuntura para acercarse a la empresa y de esta forma obtener recursos necesarios para sus actividades en investigación.
|
||||
|
||||
|
||||
\section{Actividades}
|
||||
En la Figura \ref{thesis_flow} se hace un resúmen de las recomendaciones formuladas anteriormente para lograr una transferencia tecnológica exitosa y como estas están relacionadas con actividades requeridas para el mejoramiento de la plataforma tecnológica y la creación de una cultura de transferencia de tecnología en el área de Sistemas Embebidos. Área en la que (como veremos más adelante) el paí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ón teniendo en mente la situación actual del país y la situación a la que se quiere llegar.
|
||||
|
||||
\begin{sidewaysfigure}[ht]
|
||||
\begin{center} \includegraphics[scale=.6]{./images/thesis_flow_diagram.png} \end{center}
|
||||
\caption{esumén de las Actividades Realizadas Para Encontrar una Metodología para la Transferencia Tecnológica en Sistemas Embebidos} \label{thesis_flow}
|
||||
\end{sidewaysfigure}
|
||||
|
||||
Todas las actividades desarrolladas buscan la creación de conocimiento alrededor del tema de Transferencia Tecnológica en el área de Sistemas Embebidos (SE), se parte del concepto \textit{El Conocimiento como Bien Común} \cite{Ost00} \cite{EO92} \cite{EO90} \cite{AC09}, y por lo tanto, se deben crear mecanismos que permitan su distribución, organización, mejoramiento y actualización. Este trabajo representa la semilla de este recurso y es el fruto del trabajo de 5 años de estudio de metodologías de diseño, fabricación y producción, experimentación, establecimiento de relaciones de todo tipo para entender la diná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ó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ón de Habilidades Necesarias Para una Transferenica Tecnológica Exitosa}: Aplicación del plan de estudios \textit{CDIO} \cite{WCI} a las asignaturas del área de Electrónica Digital, utilizando las habilidades que requiere la industra electró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ón, Diseño e Implementación de Sistemas Embebidos, por lo que se realizó un estudio sobre metodologías de diseño, implementación y producció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ón le permitirá a cualquier personal entender, usar y modificar la gran variedad de plataformas de referencia ya sea para adquirir o mejorar habilidades en la Concepción, Diseño e Implementación de SE o para crear nuevos dispositivos que satisfagan una determinada necesidad. En el capítulo \ref{ch:embedded} se realizará una descripción de las actividades realizadas y las plataformas diseñadas durante este estudio. En el capítulo \ref{ch:education} se hace una descripción del proceso que se llevó a cabo para la aplicación del plan de estudios \textit{CDIO} a las asignaturas del área de Electrónica Digital.
|
||||
|
||||
\item \textbf{Creación de Empresas de Base Tecnológica}: La principal fuente de información sobre la dinámica de la industria electrónica Colombiana y el estado de la industria Electrónica mundial (la que se utilizó para determinar las necesidades de las empresas locales, y las habilidades que los prefesionales en el área deben poseer para suplirlas) fué la empresa Colombiana emQbit, esta empresa fue creada por un grupo de egresados de la Universidad Nacional de Colombia, los cuales con la asesoría del autor de este trabajo de investigación incursionaron en la concepción, diseño e Implementación de Sistemas Digitales, concirtiéndose en la primera y única empresa en Colombia que realiza el proceso completo del proceso de diseño de SE \cite{CC06}.\cite{emQ}. En el capítulo \ref{ch:embedded} se enumerará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ún: Generación y distribución de herramientas software, sistema operativo y todo tipo de aplicaciones incluyendo el código fuente bajo una licencia que permite su distribución y modificació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ó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ó para el desarrollo de una aplicación permitiendo el estudio del código fuente, creando listas de discusió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ón GNU}, librerías, el sistema operativo \textit{Linux}, aplicaciones como el servidor web \textit{Apache}, el explorador \textit{Mozilla}, la suite ofimá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 áreas.
|
||||
|
||||
El resultado más notable, es la creación de un recurso de bien común: el conocimiento contenido en las herramientas y aplicaciones, la infra-estructura física y tecnológica para su distribución y difusión, y una comunidad que se encarga de contribuir, mejorar y administrar este recurso. Este recurso está 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ón de normas, y deben conocer de antemano las reglas de interacción entre los miembros y como sus acciones afectan a los otros miembros y al recurso. En el capítulo \ref{ch:common} estudiaremos con más detalle este movimiento.
|
||||
|
||||
Este trabajo contribuye con la creació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ón y generación de bienes y servicios asociados a estos productos. En la actualidad existen varios proyectos que proporcionan los archivos de diseño para reproducir el componente hardware, sin embargo, no existe un consenso sobre las características que se deben cumplir para que sea considerado \textit{copyleft}, esta es una de los tópicos que se abordarán en el capítulo \ref{ch:common}
|
||||
|
||||
|
||||
\end{itemize}
|
563
course/.docs/book/review.tex.backup
Normal file
563
course/.docs/book/review.tex.backup
Normal file
@ -0,0 +1,563 @@
|
||||
\chapter{TRANSFERENCIA TECNOLÓ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ía según Van Gigch involucra la adquisición de "actividad Inventiva" por parte de usuarios secundarios. Es decir, la
|
||||
transferencia tecnológica no involucra necesariamente maquinaria o dispositivos físicos. El conocimiento puede ser transferido a través de entrenamiento y
|
||||
educación, y puede incluir temas como manejo efectivo de procesos y cambios tecnológicos\cite{FBFP07} .
|
||||
|
||||
La transferencia tecnológica es un proceso dinámico que debe ser re-evaluado periódicamente, requiere una infraestructura adecuada que involucra
|
||||
instituciones, institutos de formación vocacional, técnica y administrativa, personal con diferentes especialidades y un entorno cultural adecuado.
|
||||
Es difícil que la tecnología desarrollada en un entorno determinado pueda ser transferida sin realizar modificaciones en la escala de producción y
|
||||
la adopción de productos al mercado local.
|
||||
|
||||
La transferencia de tecnología ha introducido técnicas de alta productividad y en muchos casos cambios técnicos en países menos desarrollados.
|
||||
La adquisición de tecnología foránea contribuye a mejorar la competitividad en los mercados locales e internacionales en estos países, en los que debe
|
||||
ser considerada como un proceso vital. Este proceso presenta problemas cuando se pierde capacidad de absorción por parte del país receptor y la
|
||||
renuencia del país que transfiere a transferir tecnología real y el know-how. Por lo que es necesario que estos países promuevan sus capacidades
|
||||
tecnológicas locales con el fin de absorber las tecnologías foráneas de forma eficiente en función de sus necesidades locales y de esta forma forma
|
||||
generar un rápido proceso de industrialización.
|
||||
|
||||
No debe confundirse la transferencia tecnológica con la apropiación de tecnología que se define como el proceso de interacción con la tecnología,
|
||||
la modificación de la forma como es usada y el marco social dentro del cual es usada. Un ejemplo de apropiación de tecnología lo podemos encontrar
|
||||
en la telefonía celular, nuestras sociedades han cambiado drásticamente su forma de comunicarse y han generado nuevas actividades alrededor de esta
|
||||
tecnología, los usuarios pueden generar aplicaciones que adicionan funcionalidades y servicios.
|
||||
|
||||
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|
||||
%%% DEFINICION DE TRANSFERENICA TECNOLOGíA %%%%%%
|
||||
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|
||||
\section{Tecnología}
|
||||
|
||||
La tecnologí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ó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ía \cite{FBFP07}:
|
||||
|
||||
\begin{itemize}
|
||||
\item Techno-ware Relacionado con objetos: Herramientas, equipos, máquinas, vehículos, facilidades físicas, instrumentos, dispositivos y fábricas
|
||||
\item Human-ware Relacionado con personas: Habilidades en conocimiento experimental, sabiduría y creatividad, experiencia, competencia, creatividad.
|
||||
\item Info-ware Relacionado con la Información: Incluye todo tipo de documentación y datos acumulados relacionados con especificación de procesos,
|
||||
procedimientos, diseños, teorías, y observaciones
|
||||
\item orga-ware Relacionado con la Organización: Acuerdos y Alianzas necesarias para facilitar la integración de los componentes Técnico, Humano, y
|
||||
de información. Involucra asignación, sistematización, organización, redes de comunicació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íficas para poder ser utilizado. Para mejorar la eficiencia del sistema el componente humano necesita de adaptación y motivación. A medida que la
|
||||
organización cambia para adaptarse a nuevas condiciones o requerimientos se debe actualizar el sector de la información. \textbf{No es posible realizar
|
||||
operaciones de transformación ante la ausencia de uno de estos cuatro componentes}
|
||||
|
||||
La interacción de estos cuatro componentes puedes ser resumida de la siguiente forma:
|
||||
|
||||
\begin{itemize}
|
||||
\item \textit{Tecnoware} constituye el núcleo de cualquier tecnología, es decir, una habilidad de transformación, y es desarrollada, instalada y operada
|
||||
por \textit{humanware}.
|
||||
\item \textit{Humanware} o las habilidades individuales representan el elemento clave de cualquier operación de transfomació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ón.
|
||||
Orgaware se compone de las actividades de planeación, organización, activación, motivación y control de operaciones.
|
||||
\end{itemize}
|
||||
|
||||
|
||||
La tecnología no esta asociada a un sistema socio-económico abstracto. La tecnologí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óricas de
|
||||
diferentes grupos sociales \cite{KGSB95}. En resúmen, la tecnología esta compuesta de conocimiento, herramientas, técnicas y actividades utilizadas
|
||||
para transformar las entradas de la organización en salidas.
|
||||
|
||||
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|
||||
%%% DEFINICION DE TRANSFERENICA TECNOLÓGICA %%%%%%
|
||||
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|
||||
\section{Definición}
|
||||
|
||||
Odedra \cite{Mo94} define la transferencia tecnoló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ógica se considera exitosa cuando los receptores de la tecnología asimilan los conceptos
|
||||
anteriores para suplir sus necesidades locales.
|
||||
|
||||
Según Jolly \cite{Jol77} La innovación tecnológica es entendida como un nuevo método, medio o capacidad del individuo para realizar una determinada actividad. El resultado de la transferencia tecnológica puede ser la aceptación de una práctica común en otros lugares, o la aplicación de una técnica
|
||||
diseñada para otro uso en la salución de problemas locales, debe distinguirse del proceso general de difusión de tecnología: un movimiento no planeado de artículos sociales y tecnológicos de un lugar a otro sin ningún esfuerzo centrado en la transferencia. La transferencia tecnológica incluye la difusión de conocimiento científico y la preocupación por la transformación del conocimiento en innovaciones útiles. El conocimiento es lo que queda al final de un proceso documentado y difundido de forma apropiada. Para que la transferencia tecnológica sea exitosa es necesario transferir los componentes de la tecnología, es decir: Los conocimientos técnicos, las habilidades humanas, la información y la estructura de la organización.
|
||||
|
||||
\subsection{Tipos de Transferencia Tecnológica}
|
||||
|
||||
Mansfield clasifica la transferencia tecnológica en transferencia de material, diseño y capacidades, la transferencia de material no constituye una transfencia tecnoló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ógicos: Materiales, productos finales, componentes, equipos
|
||||
\item Transferenica de diseño: Diseños, proyectos, know-how para fabricar productos diseñ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ías
|
||||
existentes para producir nuevos productos.
|
||||
\end{itemize}
|
||||
|
||||
La transferencia de diseños permite adquirir mayor conocimiento sobre la tecnología transferida, sin embargo, es necesario que el pais receptor cuente con la plataforma tecnológica adecuada para absorver estos conocimientos, de lo contario no se generarán nuevos productos y las actividades se limitará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á asociada a una transferencia de conocimiento, lo cual es vital para entender plenamente la tecnología, mejorando las habilidades de los profesionales del receptor.
|
||||
|
||||
Otra clasificación distingue entre Transferencia Vertical y Horizontal:
|
||||
|
||||
\begin{itemize}
|
||||
\item Transferencia Vertical: Transferencia de información técnica a diferentes niveles de un proceso innovativo determinado. Por ejemplo de
|
||||
investigación básica a investigación aplicada, de investigación aplicada a desarrollo y de desarrollo a producción. es decir, una progresión
|
||||
tecnológica desde la teoría al producto terminado.
|
||||
\item Transferencia Horizontal: Cuando se utiliza en un lugar, organizació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émicos, transferencia entre la academia y la empresa para generar aplicaciones, prototipos y producción en masa. La desconcexión entre la Universidad y la empresa en Colombia y en la mayoría de los países en desarrollo hace que los objetivos que persigue la Academia no está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ógica para hacerlo o porque la Universidad no proporciona el soporte necesario para que ese producto pueda ser utilizado en la práctica.
|
||||
|
||||
\subsection{Canales Para la Transferencia de tecnología}
|
||||
|
||||
Erdilec and Rapoport [45] clasifican los mecanismos en Formales: Acuerdos de licenciamiento, Inversión extranjera, compañías conjuntas, acuerdos de cooperación en investigación, arreglos de producción conjunta e Informales: No involucran acuerdos entre las partes y son difíciles de detectar y monitorear, por ejemplo, exportación de productos tecnológicos o bienes de capital, ingeniería inversa, intercambio de personal técnico y científico, conferencias de ciencia y tecnología, ferias y exposiciones, educación y entrenamiento realizado por extranjeros, visitas comerciales, literatura abierta (artículos, revistas, libros técnicos), espionaje industrial. Adicionalmente, existe una división basada en la naturaleza de la institución que proporciona los recursos para que se realice la transferencia, la institución puede ser de carácter:
|
||||
|
||||
\begin{itemize}
|
||||
\item \textit{Abierta} en donde la tecnología y el conocimiento són considerados bienes públicos, no existen restricciones para acceder a la información necesaria para adquirir, usar y transformar estos conocimientos en productos comerciales, y su éxito radica en obtener la máxima difusión posible para que los usuarios de este conocimiento mejoren el material existente y contribuyan con experiencias personale,
|
||||
\item \textit{Cerrada} La tecnología y el conocimiento se genera para fines privados, la utilización de este conocimiento esta sometida a acuerdos comerciales. No es posible entender las bases de la tecnología, por lo que no se pueden generar productos derivados.
|
||||
\end{itemize}
|
||||
|
||||
Las actividades realizadas durante este estudio están enmarcadas dentro del concepto: \textit{El conocimiento es un Bien Común}, toda la documentació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és de listas de discusión, adicionalmente se proporciona soporte comercial para permitir la producción de estas modificaciones. A continuación se realiza una descripción de los canales más utilizados para la transferencia de tecnología y conocimiento en países en vía de desarrollo (\cite{MO90} \cite{Mo94} \cite{MO91}) indicando en cada caso sus ventajes, limitaciones y desventajas.
|
||||
|
||||
\subsubsection{Adquisición de IT}
|
||||
|
||||
La adquisición de equipo ha sido uno de los mecanismos de transferencia más importantes para los paí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ón personalizada a las necesidades de los clientes. La
|
||||
transferencia tecnológica se presenta en el proceso de personalización, esto, unido a otras habilidades en programación ayudan a elevar
|
||||
el mercado de SW local. Sin embargo, en muchas ocasiones no se detectó ningún tipo de transferencia de knowhow en la adquisició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ñas compañías locales, lo que se traduce en que el mantenimiento y servicios asociados al hardware, así como los ajustes de Software
|
||||
sean realizados por los proveedores de las multinacionales y en muy pocos casos los usuarios de esta tecnologí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ón con la venta de equipos se transmite únicamente el conocimiento para operar, programar o mantener, sin embargo,
|
||||
este conocimiento sobre el sistema puede ayudar a concientizarse sobre la tecnología e impulsar la formación de capital humano.
|
||||
|
||||
La experiencia de países que lograron un rápido desarrollo económico e industrial muestra que la adquisición de una gran cantidad de
|
||||
tecnología foránea jugó un papel importante en este proceso. Colombia ha realizado un proceso de transformación tecnológica pero no ha
|
||||
diseñado políticas efectivas y eficientes para la transferencia de tecnologías de alto nivel
|
||||
.
|
||||
|
||||
\subsubsection{Educación y Entrenamiento}
|
||||
Educar a las personas a través de cursos y entrenamiento en el país y enviándolas al extranjero para otros estudios es una forma de adquirir
|
||||
know-how sobre nuevas tecnologías, o tecnologías que no se utilizan en el país de origen. Muchas instituciones ofrecen carreras en
|
||||
Ingeniería Electrónica, Ciencias de la computación y afines, algunas de ellas utilizan modelos pedagógicos utilizados en países desarrollados,
|
||||
los que no han sido adaptados plenamente a la infraestructura tecnológica local, y no es raro encontrar estudiantes que no están satisfechos
|
||||
con su profesión al finalizar los cursos\cite{Mo94}.
|
||||
|
||||
En muchas Universidades temas como Nanotecnología, Diseño de Circuitos integrados de muy alta integración (VLSI) hacen parte importante de las
|
||||
actividades de investigación; la pertinencia de estos tópicos avanzados ante la situación tecnológica del país es discutible ya que muchos
|
||||
estudiantes no aplicarán nunca estos conocimientos en el entorno local, por lo que la enseñanza de estos tópicos puede resultar una pérdida de
|
||||
recursos. Es más, con los rápidos cambios en la industria electrónica estos conocimientos pueden resultar irrelevantes, aún si la
|
||||
infraestructura del país se mejora. Es decir, es importante no dejarse llevar por el momento, o por la "fama" de un tópico de investigación
|
||||
o de una tecnología novedosa, es necesario evaluar la pertinencia de los cursos que se dictan en el entorno tecnológico local, por supuesto,
|
||||
es necesario que la academia impulse cambios en el sector, pero estos cambios deben ser consecuentes con el nivel tecnológico que posea el país.
|
||||
|
||||
La transferencia tecnológica no ocurre cuando estudiantes formados en el exterior no pueden aplicar sus conocimientos en su país de origen,
|
||||
por lo que es necesario crear políticas que definan que áreas de estudio son prioritarias para el país.
|
||||
|
||||
Las multinacionales también ofrecen cursos de capacitación, sin embargo, se limitan al uso de sus productos, creando dependencia hacia
|
||||
sus herramientas. Adicionalmente, existen centros privados de capacitación que ofrecen cursos para el manejo de paquetes y lenguajes de
|
||||
programación, estos centros aprovechan la falta de centros de enseñanza tecnológica y personal calificado para cobrar altas sumas de dinero,
|
||||
lo cual limita el acceso. Programas académicos inapropiados, acceso limitado a libros y computadores, falta de facilidades para capacitación, reduce la efectividad
|
||||
de la educación y capacitación como canal para la transferencia tecnoló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ía un gran esfuerzo
|
||||
y posiblemente se tendrí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án familiarizados con las condiciones y requerimientos locales, con lo que diseñan soluciones que no se
|
||||
ajustan perfectamente a las necesidades, lo que significa que el sistema es sub-utilizado y la transferencia de tecnologí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án dirigidas a aumentar la dependencia
|
||||
con los productos generados por dichas transnacionales y a ignorar de forma sistemática opciones que pueden ayudar a la transferencia de conocimiento,
|
||||
llegando hasta el punto de influir en la formulación de políticas para transferencia tecnoló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ó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 ú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ón con otros instrumentos como investigación extranjera, importación de maquinaria o de técnicos. Sin embargo, no es efectivo si no
|
||||
se acompaña de habilidades administrativas y de producción. Adicionalmente, es necesario contar con una infraestructura tecnológica adecuada,
|
||||
capacidades locales de fabricación de hardware y software y políticas de gobierno adecuadas \cite{Mo94}.
|
||||
|
||||
Un ejemplo de este tipo de práctica se presenta en el ensamble de dispositivos electrónicos, todos los componentes se importan completamente
|
||||
terminados y el dispositivo final es ensamblado probado y se carga la configuración inical, no se producen actividades de ingenierí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íticas de protección de los productos generados
|
||||
localmente, países de latinoamerica aplican este tipo de protecciones y solo permiten la importación de productos que no se fabriquen en el país.
|
||||
Esto aumenta la confianza en los productos generados localmente e impulsa el desarrollo industrial y la generación de empleo.
|
||||
|
||||
\subsubsection{Inversión Extranjera Directa}
|
||||
|
||||
La inversión directa de multinacionales es una forma de obtener tecnología externa. Esto asegura una rápida transferencia de información
|
||||
tecnológica, pero no necesariamente del entendimiento o know-how. Lo que hace que la tecnología transferida a través de este canal sea mínima.
|
||||
Las grandes multinacionales pueden tener cierto control político en los países en vía de desarrollo, hasta tal punto que son asesores de
|
||||
instituciones encargadas de fijar políticas para la transferencia tecnológica \cite{Mo94}.
|
||||
|
||||
El objetivo de la transferencia tecnoló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íses desarrollados y en vía de desarrollo. La compra de equipo o de software transfiere muy poco conocimiento
|
||||
sobre la tecnología, el servicio post-venta y el mantenimiento es realizado por el proveedor. Por otro lado, las facilidades en educación y capacitación
|
||||
son limitadas lo cual obstaculiza la formació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ón}
|
||||
|
||||
La efectividad de cada canal depende de la naturaleza de la tecnología que se va a adquirir, el tipo de organización y de las capacidades de absorción del recipiente. La tecnología es efectiva únicamente cuando la economía del país es capaz de utilizarla. Cuando se transfiere una tecnología se debe contar con el dinero para adquirirla y se deben generar las actividades necesarias para mejorar la plataforma tecnológica, incluyendo la educación y la capacitación, de tal forma que el país sea capaz de absorberla y generar nuevos productos que satisfagan necesidades locales.
|
||||
|
||||
El éxito de la transferencia tecnológica no depende de un factor único, sino de la confluencia de multiples factores dentro y fuera de la institución académica. Las relaciones personales entre los agentes de transferencia tecnológica y la facultad, licencias corporativas, y las comunidades de investigación y de negocios son la clave de esfuerzos exitosos. En muchos casos, las Universidades han liderado el proceso de transferencia tecnológica a través de sus directivos, estos a través de incentivos crean una cultura académica que recompensa la transferencia tecnológica y el emprendimiento.
|
||||
|
||||
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|
||||
%%% Modelo %%%%%%
|
||||
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|
||||
|
||||
\section{Modelo}
|
||||
|
||||
Un programa de transferencia tecnológica bebe incluir mecanismos que unan de forma eficiente la fuente del conocimiento con la utilización del mismo.
|
||||
Estos canales de comunicació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ó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ía} \label{tech_trans_model_global}
|
||||
\end{figure}
|
||||
|
||||
|
||||
\subsection{Los factores formales}
|
||||
|
||||
\subsubsection{Documentación}
|
||||
Es el formato, organización, o presentación de la tecnología que será transferida. El formato y el lenguaje se relacionan directamente con el entendimiento del material por parte del receptor. La información que no se entiende no se utiliza. Los científicos e ingenieros ocupan hasta 4 horas diarias leyendo artículos, hablando con sus pares o buscando informació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ón}
|
||||
Constituye el canal físico a través del cual la tecnología fluye e involucra tanto el número de entradas y el fácil acceso al canal, así como el plan de distribución. knox 1973, dice: "Una medida de la efectividad del sistema de información tecnológica es al capacidad de permitir el contacto entre personas con necesidades y con posibles soluciones. Ames 1965, Encontró que los abstracts y los papers son la fuente de información más importante, mientras que las reuniones y conferencias el mejor vehículo para crear conciencia, la cual es indispensable para que el proceso de distribución sea exitoso, por lo que, el intercambio personal debe ser considerado como parte del proceso de distribución de tecnología. Este canal ayuda a eliminar retardos en la investigación, ya que permite determinar el estado del arte de una determinada actividad o área de trabajo.
|
||||
|
||||
|
||||
\subsubsection{Organización}
|
||||
La percepción del receptor de la organización. Schon 1967, caracteriza a una organización que es favorable a la transferencia tecnológica y utilizació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íficos e ingenieros donde algunos de ellos sienten que una organización ocasionalmente puede actuar como una barrera a las nuevas ideas.
|
||||
|
||||
|
||||
\subsubsection{Selección de Proyectos}
|
||||
|
||||
Proceso de selección para proyectos de investigación y desarrollo realizado por el proveedor con ayuda del receptor. Es importante que la investigació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ía Indicando La Composición de Los Canales Formales e Informales} \label{tech_trans_model}
|
||||
\end{figure}
|
||||
|
||||
|
||||
\subsection{Factores Informales}
|
||||
Los factores informales son de naturaleza sociológica y/o comportamental, y contribuyen fuertemente al éxito de la utilización del conocimiento por una determinada organización.
|
||||
|
||||
\subsubsection{Capacidad}
|
||||
La capacidad del usuario para utilizar nuevas ideas que cubren un amplio espectro de rasgos que incluyen riesgo, riqueza, poder, educació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ón receptora. El enlace opera dentro de la organización receptora y exhibe características similares al supervisor, líder de opinión, innovador y previo conocedor de la innovación.
|
||||
|
||||
|
||||
\subsubsection{Credibilidad}
|
||||
|
||||
La credibilidad es una evaluación por parte del usuario, de la confiabilidad de la información. Es evaluada analizando la fuente y el canal del mensaje. La opinión cambia dependiendo de la fuente de la informació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ón}
|
||||
|
||||
La habilidad y/o deseo del individuo para aceptar un cambio en la organización de la cual es miembro. Así mismo es importante la capacidad de adopción de nuevas ideas, Gallup 1955 señaló que aunque una idea halla sido aceptada intelectualmente, toma un perí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ón, un interés, una motivación personal para utilizar un mejor método, proceso o concepto.
|
||||
|
||||
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|
||||
%%% Historia %%%%%%
|
||||
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|
||||
|
||||
\section{Transferenica Tecnológica en Latinoamérica \cite{UNE}}
|
||||
|
||||
\subsection{Trasfondo histórico}
|
||||
|
||||
Durante el período que va de los años 40 a la década de los 80, en América Latina y el Caribe se puso en práctica una política de
|
||||
industrialización por sustitución de importaciones mediante modalidades de proteccionismo de la industria manufacturera local.
|
||||
Con lo que se comenzó a importar los bienes de capital necesarios para la fabricación en el ámbito local, desarrollando
|
||||
de esta forma a las industrias locales. Mientras tanto, en los países de donde provenían estos bienes, se transformaba el conocimiento
|
||||
adquirido de la investigación, en nuevos productos, procesos y modelos de gestión más competitivos. Es decir, se importaron los equipos
|
||||
para realizar la transformación industrial, pero no se generaron las bases científico-tecnológicas que se encargaran de generar nuevos
|
||||
productos asociados a las materias primas proporcionadas por los recursos naturales locales, se descuidó el capital humano capaz de entender,
|
||||
adaptar y llevar estos inventos a la sociedad, salvo en algunas disciplinas agrícolas donde la especificidad local obligó a la investigación.
|
||||
Adicionalmente, no se generó demanda local que impulsara la producción de conocimiento, las nuevas empresas no contaban con departamentos de
|
||||
Investigación y desarrollo (I+D) y los gobiernos no estimulaban la creación de centros de investigación asociados a este proceso de industrialización.
|
||||
|
||||
Cuando los gobiernos de la región se dieron cuenta de esta situación crearon la Comisión para América Latina y el Caribe (CEPAL). A partir
|
||||
de las décadas de los cincuentas y setentas comenzaron a crear políticas en las áreas científicas y tecnológicas, creando instituciones
|
||||
destinadas al fomento de la ciencia y la tecnologí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ía eran una usina de crecimiento, en un rico
|
||||
suelo fertilizado por el deseo de la modernización y el desarrollo") exhibieron una continuidad notable. Esto unido al apoyo gubernamental y
|
||||
el interés de las universidades fue clave para la formulación de políticas de apoyo a la ciencia y la tecnología.
|
||||
|
||||
Gracias a estas políticas hubo un fuerte proceso de institucionalización de la investigación científica y de los mecanismos de desarrollo:
|
||||
Sistemas de promoción del I+D, legislación en transferencia de tecnología, planificación de la ciencia, métodos de diagnóstico de recursos,
|
||||
sistemas de fijación de prioridades tecnoló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ámica sostenida de innovación en el
|
||||
conocimiento y en la economía ya que en muchos sectores no se generó un vínculo sólido entre la producción y la investigación, esto debido a la
|
||||
creación de dos modelos de investigación en ciencia y tecnología:
|
||||
\begin{itemize}
|
||||
\item Ciencia Académica: Basada en las universidades, es incorporada a la comunidad científica internacional, de quien recibe legitimidad, orientación,
|
||||
organización.
|
||||
\item Actividad Tecnológica: Sustentada por organismos sectoriales, legitimada por instituciones estatales, su objetivo es dar solución a problemas
|
||||
prácticos y a la transferencia de tecnología al sector productivo.
|
||||
\end{itemize}
|
||||
|
||||
En los años 80 disminuyó la confianza de poder encontrar un camino hacia un desarrollo endógeno, lo que originó un giro hacia políticas de ajuste,
|
||||
estabilización y apertura de la economía que buscaban vías alternas para llegar a la globalización. La apertura de la economía suponí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ía una homogeneización tecnológica, por lo que el aumento de la competitividad se lograría
|
||||
a través de la transferencia de productos externos y no la inventiva e innovación local.
|
||||
|
||||
En los años 90 los países de la regió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ón de muchas en importadores;
|
||||
esta política desmantela el aparato productivo y no fomenta actividades de adaptación, mejora y creación de productos. La oferta tecnológica
|
||||
proviene del exterior, se diluye el sistema nacional de ciencia y tecnología basado en el aumento de la oferta interna de conocimiento.
|
||||
Las políticas públicas se reducen a la aceptación de normas de la Organización Mundial de Comercio (OMC) basadas en presiones de Estados
|
||||
Unidos y la Unión Europea sobre patentes farmacéuticas, tecnologías agrícolas y de otros tipos. No es que no existan esfuerzos e interacciones tecnológicas entre la ciencia y la producción; el problema es que no constituyen un sistema autosostenido de relaciones dinámicas que marquen un rumbo claro a la investigación en ciencia y tecnología vinculado con las sociedades y las economías donde se desenvuelven.
|
||||
|
||||
Según Gibbons y Schwartzman, la investigación científica se origina y justifica cada vez más en el contexto de aplicación del conocimiento,
|
||||
es decir, en la posibilidad de su utilización. Por lo que los temas de investigación no son fijados por los cientí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ón disminuyan.
|
||||
En tal sentido, no es seguro que la inserción en el comercio internacional de América Latina favorezca su posición en la producción de
|
||||
conocimientos en ciencia y tecnología.
|
||||
|
||||
La ciencia y la tecnología en la región presenta dos grandes probleams: a) su escasa magnitud; b) su desvinculación con la sociedad a
|
||||
la que pertenece, con el agravante de la pérdida de legitimidad que se produjo en las últimas dos décadas, sustentada por una parte en
|
||||
el Estado, y en su integración en una ciencia internacional fuertemente académica, por la otra.
|
||||
|
||||
\subsection{Financiación}
|
||||
|
||||
Según la Red de Indicadores de Ciencia y Tecnología (RYCIT), el gasto en actividades de ciencia y tecnología en los paí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érica Latina y el Caribe, su inversión en I+D es más de 20 veces mayor que la latinoamericana. Dicho de otro modo, el esfuerzo de los países de la región en ciencia y tecnología es inferior al que les correspondería realizar tomando en cuenta el valor del producto regional.
|
||||
|
||||
Según la Organization for Economic Co-operation and Development (OCED) los países Latinoamericanos dedican en promedio algo más del 0,6\% de su Producto Interno Bruto a I+D. Esta inversió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ón Europea, en cambio, el porcentaje alcanza el 1,7\% del PIB, en Estados Unidos alcanza el 2,8\%, Japón (3,13\%), Corea del Sur (2,52\%) y otros como China e India en los cuales, aunque la inversión es algo inferior, la tendencia de los últimos años hace pensar en un aumento progresivo de sus inversiones en I+D. El gasto en ciencia y tecnologí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íses latinoamericanos a 59.000.
|
||||
|
||||
Un rasgo característico de la investigación científica en América Latina es su gran dependencia del Estado, según un estudio de la OCED, en el plano estrictamente tecnológico, las estadí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ña y Canadá, respectivamente. En Amé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í son valores marcadamente inferiores.
|
||||
|
||||
|
||||
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|
||||
%%% Obstaculo %%%%%%
|
||||
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|
||||
\section{Obstáculos para una Transferencia Exitosa}
|
||||
|
||||
La cantidad de conocimiento y tecnología transferida es afectada por políticas gubernamentales, la situación económica, facilidades de educación y capacitación, personal calificado, aspectos organizacionales y sociales, proveedores de tecnología e infraestructura tecnológica. El gobierno juega un papel importante en el proceso de transferencia tecnológica ya que puede invertir en la infraestructura para impulsar una determinada tecnología o colocar restricciones para des-estimular su uso. Estas políticas son dependientes de la situación económica del país y del entendimiento de la importancia de la transferencia por parte de de sus dirigentes. La falta de facilidades en educación y en capacitació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ís no lo permite. Las personas son las que finalmente absorben el know-how tecnológico, si no existe el suficiente personal disponible y dispuesto, el proceso de transferencia se detendrá.
|
||||
|
||||
La administración a nivel de organización juega el papel más importante en el proceso de transferencia tecnológica. La resistencia o el
|
||||
desconocimiento a la tecnología, la adquisición de tecnología por motivos particulares no contemplan la implementación y la capacitación.
|
||||
Por esta razón, es necesario que los encargados de tomar las decisiones y trazar políticas, conozcan la tecnología, o que estén conscientes de
|
||||
su importancia. La transferencia tecnológica debe ser un proceso de dos vías, por lo que es indispensable tener habilidades adecuadas en
|
||||
investigación, capacidades organizacionales y de ingeniería para que estos conocimientos sean asimilados y utilizados en la solución de
|
||||
problemas locales. Es necesario que la adquisición de tecnología obedezca a un plan y que esta tecnología supla una necesidad real, de
|
||||
lo contrario los equipos adquiridos y la capacitación recibida no serán utilizados, por otro lado, la tecnología adquirida que no es
|
||||
asimilada y transformada en herramienta para la solució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ógica.
|
||||
|
||||
Los procesos de transferencia tecnológica son influenciados de forma directo o indirecta por las infraestructuras organizacionales y
|
||||
tecnológicas de los países, los cuales, deben exceder sus capacidades para absorber la tecnología transferida. Esta transferencia es efectiva solo
|
||||
si la economía en la cual es introducida es capaz de utilizarla. Si un país cuenta con los recursos económicos necesarios para adquirir la tecnología,
|
||||
debe mejorar la infraestructura para soportarla, incluyendo la educación y las facilidades de entrenamiento, así como los enlaces de telecomunicaciones \cite{MO90}.
|
||||
|
||||
La falta de facilidades de educación y capacitación afecta la transferencia del knowhow, obstaculizando el desarrollo de habilidades a través del proceso de aprendizaje. La carencia de estas facilidades limita la difusión del conocimiento; la pérdida de estas habilidades se pueden originar porque la transferencia no se realizó o porque la infraestructura no lo permite.
|
||||
|
||||
Si no existen personas disponibles y dispuestas a absorber el knowhow el proceso de transferencia se detendrá. El proceso de transferencia
|
||||
tecnológico también es influenciado por la falta de políticas claras en la Tecnología de la Información, y los planes de negocios estratégicos,
|
||||
los cuales pueden identificar las necesidades que traerán beneficios a la nación o determinar lo que se puede lograr con los recursos disponibles.
|
||||
|
||||
Algunas políticas regulatorias sobre procesos de adquisición de hardware y software que existen en varios países obstaculizan los procesos de
|
||||
transferencia de tecnología. Al hacer convenios con multinacionales para suministro de tecnología, a menudo estas multinacionales no está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ón del producto y en el aumento de la dependencia del proveedor.
|
||||
|
||||
Las tecnologías de la Información deben ser utilizadas como una facilidad en el proceso de educación y capacitación, es necesario tomar
|
||||
conciencia de la importancia de la información a nivel organizacional y gubernamental.
|
||||
|
||||
La gran ausente en las políticas Tecnológicas parece ser la sociedad. Nada permite suponer que el interés de los cultores del campo
|
||||
se pretenda una democratización de la ciencia y la tecnología, una apropiación de su dinámica y de sus resultados por parte de la sociedad
|
||||
en su conjunto. Llama la atención que, por una parte, no existan trabajos o programas que destaquen desde un punto de vista
|
||||
crítico los impactos tecnológicos sobre la vida de la sociedad (calidad, tejido social, integración social, distribución de beneficios, etc.);
|
||||
por otro lado, no se registran estudios o programas de formación destinados a plantear la cuestión de la divulgación científica y tecnológica
|
||||
como procesos de apropiación simbólica por parte de los ciudadanos respecto de los contenidos de la ciencia y la tecnología.
|
||||
|
||||
|
||||
\section{Recomendaciones Para una Transferencia Tecnológica Exitosa}
|
||||
Estudios consultados \cite{MO90} \cite{IAI} \cite{MDAG99} \cite{DZSC+07} \cite{MTRR07} \cite{Mar04}, coinciden en que para dar solución a los problemas expuestos anteriormente se deben seguir las siguientes recomendaciones:
|
||||
|
||||
\subsection{Recomendaciones para los generadores de políticas}
|
||||
\begin{itemize}
|
||||
|
||||
\item{Promover la Importancia de la Transferencia Tecnológica como Motor de Desarrollo Económico}
|
||||
\begin{itemize}
|
||||
\item Proporcionar educación en transferencia tecnológica y comercialización a las nuevas instituciones académicas.
|
||||
\item Promover las asociaciones regionales de I+D.
|
||||
\item Tomar conciencia que la innovación involucra el desarrollo científico y tecnológico a varios niveles, por diferentes medios y a través de un amplio rango de instituciones académicas.
|
||||
\item Promover las actividades de Transferencia tecnológica que involucren transferencia de conocimiento que permita la creación de nuevos productos y servicios. Del mismo modo, desalentar la compra de equipo y software propietario como política para la transferencia tecnológica.
|
||||
\end{itemize}
|
||||
|
||||
\item{Fomentar la Generación de Empresas Locales de Base Tecnológica}
|
||||
\begin{itemize}
|
||||
\item Evaluar y abordar la transferencia de tecnología desde una perspectiva corporativa.
|
||||
\item Revisión de la política gubernamental de apoyo a las pequeñas empresas.
|
||||
\end{itemize}
|
||||
|
||||
\item{Promover el Mejoramiento de la Plataforma Tecnológica}
|
||||
\begin{itemize}
|
||||
\item Desarrollar sistemas de medición para capturar de forma efectiva el valor de las actividades relacionadas con la innovación.
|
||||
\item Crear un centro de intercambio de información para transferencia tecnológica y difundir la información de forma activa.
|
||||
\end{itemize}
|
||||
|
||||
\end{itemize}
|
||||
|
||||
\subsection{Recomendaciones para la academia}
|
||||
|
||||
\begin{itemize}
|
||||
\item{Actualización Curricular}
|
||||
\begin{itemize}
|
||||
\item Innovación
|
||||
\item Crear planes de transferencia de tecnología flexibles
|
||||
\item hacer compromisos con el desarrollo económico.
|
||||
\item Necesidad de mejorar las competencias y habilidades generales de los ingenieros, (continuo aprendizaje) habilidad para innovar, investigar, desarrollar nueva tecnología.
|
||||
\item Innovación curricular, actualización continua de profesionales.
|
||||
\item Incentivar la formación de maestrías y doctorados nacionales acorde con una agenda de investigació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ón de miembros de la industria a centros de investigación para formar relaciones formales e informales.
|
||||
\item Buscar tener fortalezas en áreas dominadas por las industrias locales
|
||||
\item Promover y soportar la Transferencia de Tecnología
|
||||
\item Fortalecer el espíritu empresarial para apoyar la comercialización
|
||||
\item Montar laboratorios de pruebas e incentivar a los productores nacionales para que logren una calidad que cumpla con los estándares internacionales.
|
||||
\end{itemize}
|
||||
|
||||
\item{Promover y Soportar la Transferencia Tecnológica}
|
||||
\begin{itemize}
|
||||
\item Elevar la transferencia tecnológica a un nivel superior y promover la excelencia.
|
||||
\item Concientizar a los creadores de políticas gubernamentales sobre la importancia de la transferencia tecnológica y las alianzas con la investigación industrial.
|
||||
\item Interacción entre Universidades, Conviene que buena parte de los trabajos realizados en doctorado sean de investigación aplicada, orientadas a mejorar la productividad del sector empresarial
|
||||
\item Infraestructura institucional que impulse la actualización tecnológica en el sector mediante desarrollo de proyectos de tecnología de punta con una posible transferencia de tecnología.
|
||||
\end{itemize}
|
||||
|
||||
\item{Búsqueda de Financiación para Investigación y Desarrollo}
|
||||
\begin{itemize}
|
||||
\item Buscar de forma agresiva fondos para la investigación.
|
||||
\item Crear recursos empresariales en las instituciones académicas, y enlazarlos con actividades de transferencia tecnológica.
|
||||
\item Aumentar las alianzas con fuentes de inversión de capital para nuevas empresas.
|
||||
\item Creación de empresas como parte del proceso de transferencia tecnológica de la institución y de los compromisos con el desarrollo económico
|
||||
\item Realizar seminarios y líneas de profundización de temas afines a la administración y la gerencia en empresas de base tecnológica.
|
||||
\end{itemize}
|
||||
|
||||
\end{itemize}
|
||||
|
||||
|
||||
\subsection{Recomendaciones para el Gobierno}
|
||||
\begin{itemize}
|
||||
|
||||
\item{Promover la Relación Universidad-Empresa}
|
||||
\begin{itemize}
|
||||
\item Fomento a centros de investigación y productividad para fortalecer la relaciones universidad empresa.
|
||||
\item Fomentar la colaboración Universidad-Empresa en I+D, mediante la financiación de becas de cooperación, centros de investigación e incentivos fiscales.
|
||||
\item Crear estrategias para mejorar la relación Universidad - empresa, creando premios para casos exitosos de transferencia tecnológica.
|
||||
\item Educar a las instituciones académicas sobre los recursos empresariales locales.
|
||||
\item Trabajar con corporaciones y fundaciones para el fomento de patrocinios y participación en transferencia de tecnología, I+D y desarrollo empresarial.
|
||||
\item Desarrollar o mejorar infraestructuras regionales para capturar y retener empresas creadas en las instituciones académicas.
|
||||
\end{itemize}
|
||||
|
||||
|
||||
\item{Formular políticas Para Incentivar Actividades de Transferencia Tecnológica}
|
||||
\begin{itemize}
|
||||
\item Fomentar en líderes universitarios el compromiso con el desarrollo económico.
|
||||
\item Definir agendas de investigación acordes con las tendencias mundiales y desarrollar capacidades en el país.
|
||||
\item Fomentar cooperación internacional e inversión extranjera con transferencia de tecnología. a nivel gubernamental, Apoyo del gobierno a personas que tienen un alto potencial de crear y desarrollar tecnología.
|
||||
\item Mejorar la plataforma Tecnológica.
|
||||
\end{itemize}
|
||||
|
||||
|
||||
\item{Promover la Excelencia Académica y la Investigación}
|
||||
\begin{itemize}
|
||||
\item Promoción de las instituciones académicas como bienes económicos
|
||||
\item Trabajar con las instituciones académicas para identificar sus competencias.
|
||||
\item Proporcionar fondos para temas específicos de investigación en instituciones académicas.
|
||||
\item Promover la Investigación y Desarrollo y la transferencia tecnológica
|
||||
\item Promover la investigación, la colaboración, la transferencia tecnológica y el desarrollo empresarial.
|
||||
\item Ayudar a las instituciones académicas a evaluar su impacto sobre las economías locales y difundir los resultados a las instituciones gubernamentales.
|
||||
\end{itemize}
|
||||
|
||||
\end{itemize}
|
||||
|
||||
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|
||||
%%% CONCLUSIONES %%%%%%
|
||||
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|
||||
|
||||
|
||||
\section{Actividades Prioritarias Para Obtener Una Transferencia de Tecnología Exitosa}
|
||||
|
||||
Las Anteriores recomendaciones coinciden en que para que se presente una Transferencia Tecnológica exitosa, es decir, para que los elementos técnicos, habilidades humanas, la documentación y la organización asociadas a una determinada tecnología, puedan ser asimilados por personal calificado (disponible y dispuesto) para posteriormente transformar estos conocimientos en la creación de nuevos productos o servicios que suplan necesidades locales es necesario:
|
||||
|
||||
\textbf{Fomentar la Creación de Empresas de Base Tecnológica} El gobierno debe crear facilidades y créditos para que empresas tecnológicas con la capacidad de innovación puedan realizar su actividad comercial (productos o servicios) y de esta forma crear nuevos empleos, aumentar la demanda de servicios tecnológicos. Así mismo, las universidades deben crear empresas que comercialicen productos derivados de sus actividades de Investigación.
|
||||
|
||||
\textbf{Promoción de la Transferencia Tecnoló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ón que puedan ser utilizados por el sector productivo a corto o mediano plazo. Las políticas de gobierno deben desalentar la compra de equipo que solo transfiera conocimiento sobre su operación y no permita la creación de nuevos conocimientos a partir de ellos, asi mismo, debe formular políticas que protejan las empresas locales de base tecnológica impidiendo el ingreso de productos similares provenientes del mercado asiático premiando a las empresas locales que realicen productos innovadores ya sea con beneficios tributarios temporales o con la adjudiación de créditos condonables destinados al desarrollo de nuevos productos. Universidad, Gobierno e Industria deben trazar políticas que definan las áreas en las que se deben formar los profesionales en el exterior, las cuales deben estar en sintonía con el estado de la plataforma tecnológica y el sector productivo, estas políticas deben cambiar a medida que se mejora la plataforma tecnológica local y se presentan cambios en el entorno mundial. Se debe trabajar en la creación de una cultura de la Transferencia Tecnológica, resaltando su importancia para el desarrollo del país.
|
||||
|
||||
\textbf{Promover la Excelencia Académica} Debe exisitir una evaluación continua de los planes acadé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ón de maestrías y doctorados que sigan políticas nacionales encaminadas al desarrollo económico y crear mecanismos de medición que permitan comparar y clasificar las instituciones académicas según las competencias de las habilidades (liderazgo y emprendimiento) de sus egresados y de esta forma determinar que instituciones son merecedoras de créditos, becas, o financiación para desarrollar actividades.
|
||||
|
||||
Los centro de educación de diferentes niveles deben trabajar de forma conjunta para definir los objetivos y habilidades que requiere el sector productivo a nivel de formación tecnoló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án definidos, esto debido a la falta de producción tecnológica del pais, somos un país consumidor de tecnologí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ón por la cual lo ingenieros tienen problemas a la hora de conseguir empleo. Esta situación se vuelve crítica debido a la gran cantidad de programas de Ingeniería que se crearon en Colombia, solo en la Universidad Nacional de Colombia se gradúan cerca de 60 ingenieros electrónicos al año.
|
||||
|
||||
"Para hacer esto posible se requiere una comisión de regulación de la educación superior que vele, especialmente, por la calidad de los diferentes programas. Ésta debe ser una comisión independiente y mixta con la participación del sector privado. Por otra parte, es menester tener en cuenta que el programa planteado requerirá un incremento sustancial de inversión en la oferta docente, tecnológica y de investigación'" \footnote{Publicado en el Espectador: 16 de julio 1999 `\textit{Urge elevar la competitividad} Santiago Montenegro}
|
||||
|
||||
\textbf{Promover la Relación Universidad Empresa} El sector productivo debe ser el principal inversionista para las actividades de Transferenica Tecnológica e Investigación y Desarrollo, ya que es el directamente beneficiado con ellas. El gobierno debe desalentar las prácticas comerciales que no generan actividades de I+D, en especial las que solo comercializan productos manufacturados en países asiá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ón en Investigación y Desarrollo. La academia debe proporcionar a la industria herramientas que le permitan competir con productos provenientes del mercado asiático, es una realidad que a corto plazo no podemos competir con la industra manufacturera asiática, pero si podemos utilizarla para producir productos diseñados en el país, por Colombianos, para satisfacer necesidades locales. Se debe crear consciencia en la industria de las ventajas de tener productos diseñ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ón de políticas gubernamentales sobre educación e Investigación y Desarrollo, para esto es vital determinar que acividades económicas contribuyen al desarrollo tecnológico, cuales son generadoras de conocimientos y de esta forma incentivar su práctica. Por otra parte, las Universidades deben continuar con sus labores de investigación en temas de actualidad y aumentar la visibilidad de la academia colombiana en el entorno centí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ógica actual. Los centros acadé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ó anteriormente Colombia es el país de Sur-América que menos invierte en Investigación y Desarrollo, por esta razón es necesario crear alianzas estratégicas para compartir los escasos recursos disponibles, en la actualidad no existe una red nacional de Universidades que trabajen conjuntamente en temas tecnoló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ómicos, de infraestructura y de equipos, adicionalmente tiene una muy buena relación con pequeñas empresas y conoce las necesidades de este sector, la función del SENA es proporcionar formación a nivel técnico que soporte las actividades de las empresas Colombianas, sin embargo, los centros de educación superior no utilizan esta coyuntura para acercarse a la empresa y de esta forma obtener recursos necesarios para sus actividades en investigación.
|
||||
|
||||
|
||||
\section{Actividades}
|
||||
En la Figura \ref{thesis_flow} se hace un resúmen de las recomendaciones formuladas anteriormente para lograr una transferencia tecnológica exitosa y como estas están relacionadas con actividades requeridas para el mejoramiento de la plataforma tecnológica y la creación de una cultura de transferencia de tecnología en el área de Sistemas Embebidos. Área en la que (como veremos más adelante) el paí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ón teniendo en mente la situación actual del país y la situación a la que se quiere llegar.
|
||||
|
||||
\begin{sidewaysfigure}[ht]
|
||||
\begin{center} \includegraphics[scale=.6]{./images/thesis_flow_diagram.png} \end{center}
|
||||
\caption{esumén de las Actividades Realizadas Para Encontrar una Metodología para la Transferencia Tecnológica en Sistemas Embebidos} \label{thesis_flow}
|
||||
\end{sidewaysfigure}
|
||||
|
||||
Todas las actividades desarrolladas buscan la creación de conocimiento alrededor del tema de Transferencia Tecnológica en el área de Sistemas Embebidos (SE), se parte del concepto \textit{El Conocimiento como Bien Común} \cite{Ost00} \cite{EO92} \cite{EO90} \cite{AC09}, y por lo tanto, se deben crear mecanismos que permitan su distribución, organización, mejoramiento y actualización. Este trabajo representa la semilla de este recurso y es el fruto del trabajo de 5 años de estudio de metodologías de diseño, fabricación y producción, experimentación, establecimiento de relaciones de todo tipo para entender la diná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ó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ón de Habilidades Necesarias Para una Transferenica Tecnológica Exitosa}: Aplicación del plan de estudios \textit{CDIO} \cite{WCI} a las asignaturas del área de Electrónica Digital, utilizando las habilidades que requiere la industra electró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ón, Diseño e Implementación de Sistemas Embebidos, por lo que se realizó un estudio sobre metodologías de diseño, implementación y producció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ón le permitirá a cualquier personal entender, usar y modificar la gran variedad de plataformas de referencia ya sea para adquirir o mejorar habilidades en la Concepción, Diseño e Implementación de SE o para crear nuevos dispositivos que satisfagan una determinada necesidad. En el capítulo \ref{ch:embedded} se realizará una descripción de las actividades realizadas y las plataformas diseñadas durante este estudio. En el capítulo \ref{ch:education} se hace una descripción del proceso que se llevó a cabo para la aplicación del plan de estudios \textit{CDIO} a las asignaturas del área de Electrónica Digital.
|
||||
|
||||
\item \textbf{Creación de Empresas de Base Tecnológica}: La principal fuente de información sobre la dinámica de la industria electrónica Colombiana y el estado de la industria Electrónica mundial (la que se utilizó para determinar las necesidades de las empresas locales, y las habilidades que los prefesionales en el área deben poseer para suplirlas) fué la empresa Colombiana emQbit, esta empresa fue creada por un grupo de egresados de la Universidad Nacional de Colombia, los cuales con la asesoría del autor de este trabajo de investigación incursionaron en la concepción, diseño e Implementación de Sistemas Digitales, concirtiéndose en la primera y única empresa en Colombia que realiza el proceso completo del proceso de diseño de SE \cite{CC06}.\cite{emQ}. En el capítulo \ref{ch:embedded} se enumerará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ún: Generación y distribución de herramientas software, sistema operativo y todo tipo de aplicaciones incluyendo el código fuente bajo una licencia que permite su distribución y modificació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ó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ó para el desarrollo de una aplicación permitiendo el estudio del código fuente, creando listas de discusió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ón GNU}, librerías, el sistema operativo \textit{Linux}, aplicaciones como el servidor web \textit{Apache}, el explorador \textit{Mozilla}, la suite ofimá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 áreas.
|
||||
|
||||
El resultado más notable, es la creación de un recurso de bien común: el conocimiento contenido en las herramientas y aplicaciones, la infra-estructura física y tecnológica para su distribución y difusión, y una comunidad que se encarga de contribuir, mejorar y administrar este recurso. Este recurso está 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ón de normas, y deben conocer de antemano las reglas de interacción entre los miembros y como sus acciones afectan a los otros miembros y al recurso. En el capítulo \ref{ch:common} estudiaremos con más detalle este movimiento.
|
||||
|
||||
Este trabajo contribuye con la creació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ón y generación de bienes y servicios asociados a estos productos. En la actualidad existen varios proyectos que proporcionan los archivos de diseño para reproducir el componente hardware, sin embargo, no existe un consenso sobre las características que se deben cumplir para que sea considerado \textit{copyleft}, esta es una de los tópicos que se abordarán en el capítulo \ref{ch:common}
|
||||
|
||||
|
||||
\end{itemize}
|
79
course/.docs/book/thesis.aux
Normal file
79
course/.docs/book/thesis.aux
Normal 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}
|
126
course/.docs/book/thesis.bbl
Normal file
126
course/.docs/book/thesis.bbl
Normal 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}
|
51
course/.docs/book/thesis.blg
Normal file
51
course/.docs/book/thesis.blg
Normal 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)
|
BIN
course/.docs/book/thesis.dvi
Normal file
BIN
course/.docs/book/thesis.dvi
Normal file
Binary file not shown.
209
course/.docs/book/thesis.kilepr
Normal file
209
course/.docs/book/thesis.kilepr
Normal 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
|
73
course/.docs/book/thesis.tex
Normal file
73
course/.docs/book/thesis.tex
Normal 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án Camargo Bareñ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.
|
||||
|
||||
|
||||
|
||||
|
18
course/.docs/book/thesis.toc
Normal file
18
course/.docs/book/thesis.toc
Normal 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}
|
40
course/.docs/book/title.tex
Normal file
40
course/.docs/book/title.tex
Normal file
@ -0,0 +1,40 @@
|
||||
% Title Page
|
||||
\title{METODOLOGÍA PARA LA TRANSFERENCIA TECNOLÓGICA Y DE CONOCIMIENTOS EN EL ÁREA DE SISTEMAS EMBEBIDOS\\
|
||||
\bigskip \bigskip \bigskip
|
||||
\bigskip \bigskip \bigskip
|
||||
UNIVERSIDAD NACIONAL DE COLOMBIA\\
|
||||
\bigskip \bigskip \bigskip
|
||||
\bigskip \bigskip \bigskip
|
||||
}
|
||||
\author{Carlos Iván Camargo Bareño}
|
||||
|
||||
\maketitle
|
||||
|
||||
\newpage
|
||||
\thispagestyle{empty}
|
||||
\parindent0pt
|
||||
Técnicas de Auto-Organizació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}
|
32
course/.docs/cambio_categoria/biblio.log
Normal file
32
course/.docs/cambio_categoria/biblio.log
Normal file
@ -0,0 +1,32 @@
|
||||
This is pdfeTeX, Version 3.141592-1.21a-2.2 (Web2C 7.5.4) (format=pdflatex 2006.8.24) 2 OCT 2006 15:54
|
||||
entering extended mode
|
||||
**biblio.tex
|
||||
(./biblio.tex
|
||||
LaTeX2e <2003/12/01>
|
||||
Babel <v3.8d> and hyphenation patterns for american, french, german, ngerman, b
|
||||
ahasa, basque, bulgarian, catalan, croatian, czech, danish, dutch, esperanto, e
|
||||
stonian, finnish, greek, icelandic, irish, italian, latin, magyar, norsk, polis
|
||||
h, portuges, romanian, russian, serbian, slovak, slovene, spanish, swedish, tur
|
||||
kish, ukrainian, nohyphenation, loaded.
|
||||
\bibdata{biblio_EL}
|
||||
No file biblio.bbl.
|
||||
)
|
||||
! Emergency stop.
|
||||
<*> biblio.tex
|
||||
|
||||
*** (job aborted, no legal \end found)
|
||||
|
||||
|
||||
Here is how much of TeX's memory you used:
|
||||
6 strings out of 94500
|
||||
122 string characters out of 1175788
|
||||
48348 words of memory out of 1000000
|
||||
3273 multiletter control sequences out of 10000+50000
|
||||
3640 words of font info for 14 fonts, out of 500000 for 2000
|
||||
580 hyphenation exceptions out of 8191
|
||||
5i,0n,3p,37b,8s stack positions out of 1500i,500n,5000p,200000b,5000s
|
||||
PDF statistics:
|
||||
0 PDF objects out of 300000
|
||||
0 named destinations out of 131072
|
||||
1 words of extra memory for PDF output out of 65536
|
||||
No pages of output.
|
2
course/.docs/cambio_categoria/biblio.tex
Normal file
2
course/.docs/cambio_categoria/biblio.tex
Normal file
@ -0,0 +1,2 @@
|
||||
|
||||
|
2
course/.docs/cambio_categoria/biblio.tex.backup
Normal file
2
course/.docs/cambio_categoria/biblio.tex.backup
Normal file
@ -0,0 +1,2 @@
|
||||
|
||||
|
2
course/.docs/cambio_categoria/biblio.tex~
Normal file
2
course/.docs/cambio_categoria/biblio.tex~
Normal file
@ -0,0 +1,2 @@
|
||||
\bibliography{biblio_EL}
|
||||
|
190
course/.docs/cambio_categoria/biblio_EL.bib
Normal file
190
course/.docs/cambio_categoria/biblio_EL.bib
Normal file
@ -0,0 +1,190 @@
|
||||
@comment{This file has been generated by Pybliographer}
|
||||
|
||||
|
||||
@Misc{LSC08,
|
||||
Author = {{Lattice Semiconductor Corporation}},
|
||||
Title = {Lattice{M}ico32 {O}pen, {F}ree 32-{B}it {S}oft
|
||||
{P}rocessor},
|
||||
HowPublished = {URL:
|
||||
http://www.latticesemi.com/products/intellectualproperty/ipcores/mico32/index.cfm},
|
||||
year = 2008
|
||||
}
|
||||
|
||||
@Misc{Wik,
|
||||
Author = {Wikipedia},
|
||||
Title = {Wikipedia, the free encyclopedia},
|
||||
HowPublished = {http://en.wikipedia.org/}
|
||||
}
|
||||
|
||||
@Misc{LD02,
|
||||
Author = {{L. Doolittle}},
|
||||
Title = {Building {L}inux for the nano{E}ngine},
|
||||
HowPublished = {http://recycle.lbl.gov/~ldoolitt/bse/},
|
||||
month = {26 } # jun,
|
||||
year = 2002
|
||||
}
|
||||
|
||||
@Misc{MLH98,
|
||||
Author = {{Michael L. Haungs}},
|
||||
Title = {The {E}xecutable and {L}inking {F}ormat ({ELF})},
|
||||
HowPublished = {http://www.cs.ucdavis.edu/~haungs/paper/node1.html},
|
||||
month = {21 } # sep,
|
||||
year = 1998
|
||||
}
|
||||
|
||||
@Article{OPPS05,
|
||||
Author = {{O. Pomerantz} and {P. Salzman} and {M. Burian}},
|
||||
Title = {The {L}inux {K}ernel {M}odule {P}rogramming {G}uide
|
||||
ver 2.6.1},
|
||||
Journal = {The Linux Documentation Project http://www.tldp.org/},
|
||||
month = {26 } # may,
|
||||
year = 2005
|
||||
}
|
||||
|
||||
@Misc{entry-0,
|
||||
Title = {An {I}ntroduction to the {L}inux {A}rchitecture},
|
||||
HowPublished = {http://wiki.cs.uiuc.edu/cs427/An+Introduction+to+the+Linux+Architecture}
|
||||
}
|
||||
|
||||
@Misc{CS04,
|
||||
Author = {{C. S\'eveillac}},
|
||||
Title = {Build {Q}t/{E}mbedded and {O}pie on a {L}inux, x86
|
||||
architecture, for {ARM} target architecture.},
|
||||
HowPublished = {http://dudu.dyn.2-h.org/nist/qt-notes.php},
|
||||
month = {20 } # nov,
|
||||
year = 2004
|
||||
}
|
||||
|
||||
@Misc{Mo05,
|
||||
Author = {{M. opdenacker}},
|
||||
Title = {Embedded {L}inux {K}ernel and driver development},
|
||||
HowPublished = {http://free-electrons.com},
|
||||
month = {14 } # aug,
|
||||
year = 2005
|
||||
}
|
||||
|
||||
@Misc{BG,
|
||||
Author = {{Bill Gatliff}},
|
||||
Title = {Porting and {U}sing {N}ewlib in {E}mbedded {S}ystems},
|
||||
HowPublished = {http://venus.billgatliff.com/node/3}
|
||||
}
|
||||
|
||||
@Article{MB03,
|
||||
Author = {{M. Barr}},
|
||||
Title = {How to {C}hoose a {R}eal-{T}ime {O}perating {S}ystem},
|
||||
Journal = {Embedded Systems Programming},
|
||||
month = jan,
|
||||
year = 2003
|
||||
}
|
||||
|
||||
@Misc{IBSS98,
|
||||
Author = {{I. Bowman} and {S. Siddiqi} and {M. Tanuan}},
|
||||
Title = {Concrete {A}rchitecture of the {L}inux {K}ernel},
|
||||
HowPublished = {http://plg.uwaterloo.ca/~itbowman/CS746G/a2},
|
||||
month = {12 } # feb,
|
||||
year = 1998
|
||||
}
|
||||
|
||||
@Article{JT04,
|
||||
Author = {{J. Turley}},
|
||||
Title = {Embedded systems survey: {O}perating systems up for
|
||||
grabs},
|
||||
Journal = {Embedded Systems Programming},
|
||||
month = may,
|
||||
year = 2004
|
||||
}
|
||||
|
||||
@Book{JCAR05,
|
||||
Author = {{J. Corbet} and {A. Rubini} and {G. Kroah-Hartman}},
|
||||
Title = {Linux {D}evice {D}rivers, {T}hird {E}dition},
|
||||
Publisher = {O'Reilly},
|
||||
year = 2005
|
||||
}
|
||||
|
||||
@Misc{AO,
|
||||
Author = {{Aleph One}},
|
||||
Title = {Porting the {L}inux {K}ernel to a {N}ew {ARM}
|
||||
{P}latform},
|
||||
HowPublished = {http://www.aleph1.co.uk}
|
||||
}
|
||||
|
||||
@Book{CH02,
|
||||
Author = {{Craig Hollabaugh.}},
|
||||
Title = {Embedded {L}inux: {H}ardware, {S}oftware, and
|
||||
{I}nterfacing},
|
||||
Publisher = {Addison Wesley Professional.},
|
||||
month = {7 } # mar,
|
||||
year = 2002
|
||||
}
|
||||
|
||||
@Misc{VDC06,
|
||||
Author = {{Venture Development Corp.}},
|
||||
Title = {Small teams dominate embedded software development},
|
||||
HowPublished = {http://www.linuxdevices.com/articles/AT7019328497.html},
|
||||
month = {1 } # jun,
|
||||
year = 2006
|
||||
}
|
||||
|
||||
@Article{JT05,
|
||||
Author = {{J. Turley}},
|
||||
Title = {Five irreversible decisions},
|
||||
Journal = {Embedded Systems Programming},
|
||||
month = {27 } # jan,
|
||||
year = 2005
|
||||
}
|
||||
|
||||
@Misc{SR08,
|
||||
Author = {{S. Rhoads}},
|
||||
Title = {Plasma - most {MIPS} {I}({TM}) opcodes},
|
||||
HowPublished = {URL: http://opencores.org/project,plasma},
|
||||
year = 2008
|
||||
}
|
||||
|
||||
@Misc{A1,
|
||||
Author = {{Aleph 1}},
|
||||
Title = {Building the {T}oolchain},
|
||||
HowPublished = {http://www.aleph1.co.uk/node/279}
|
||||
}
|
||||
|
||||
@Misc{Ale01,
|
||||
Author = {Aleph1},
|
||||
Title = {Boot {L}oader {G}uide},
|
||||
HowPublished = {http://www.aleph1.co.uk/armlinux/docs/ARM
|
||||
booting/t1.html},
|
||||
month = {7 } # sep,
|
||||
year = 2001
|
||||
}
|
||||
|
||||
@Misc{DK06,
|
||||
Author = {{Dan Kegel}},
|
||||
Title = {Building and {T}esting gcc/glibc cross toolchains},
|
||||
HowPublished = {http://www.kegel.com/crosstool/},
|
||||
month = {20 } # feb,
|
||||
year = 2006
|
||||
}
|
||||
|
||||
@Misc{IB98,
|
||||
Author = {{I. Bowman}},
|
||||
Title = {Conceptual {A}rchitecture of the {L}inux {K}ernel},
|
||||
HowPublished = {http://www.grad.math.uwaterloo.ca/~itbowman/CS746G/a1/},
|
||||
year = 1998
|
||||
}
|
||||
|
||||
@Article{Lin05,
|
||||
Author = {Linuxdevices},
|
||||
Title = {Embedded {L}inux market snapshot, 2005},
|
||||
Journal = {http://www.linuxdevices.com},
|
||||
month = {4 } # may,
|
||||
year = 2005
|
||||
}
|
||||
|
||||
@Article{CLSB05,
|
||||
Author = {{C. Lanfear} and {S. Balacco} and {M. Volckmann}},
|
||||
Title = {The 2005 {E}mbedded {S}oftware {S}trategic {M}arket
|
||||
{I}ntelligence {P}rogram},
|
||||
Journal = {Venture Development Corporation
|
||||
http://www.vdc-corp.com},
|
||||
month = aug,
|
||||
year = 2005
|
||||
}
|
||||
|
181
course/.docs/cambio_categoria/biblio_EL.bib.bak
Normal file
181
course/.docs/cambio_categoria/biblio_EL.bib.bak
Normal file
@ -0,0 +1,181 @@
|
||||
@comment{This file has been generated by Pybliographer}
|
||||
|
||||
|
||||
@Misc{Wik,
|
||||
Author = {Wikipedia},
|
||||
Title = {Wikipedia, the free encyclopedia},
|
||||
HowPublished = {http://en.wikipedia.org/}
|
||||
}
|
||||
|
||||
@Misc{LD02,
|
||||
Author = {{L. Doolittle}},
|
||||
Title = {Building {L}inux for the nano{E}ngine},
|
||||
HowPublished = {http://recycle.lbl.gov/~ldoolitt/bse/},
|
||||
month = {26 } # jun,
|
||||
year = 2002
|
||||
}
|
||||
|
||||
@Misc{MLH98,
|
||||
Author = {{Michael L. Haungs}},
|
||||
Title = {The {E}xecutable and {L}inking {F}ormat ({ELF})},
|
||||
HowPublished = {http://www.cs.ucdavis.edu/~haungs/paper/node1.html},
|
||||
month = {21 } # sep,
|
||||
year = 1998
|
||||
}
|
||||
|
||||
@Article{OPPS05,
|
||||
Author = {{O. Pomerantz} and {P. Salzman} and {M. Burian}},
|
||||
Title = {The {L}inux {K}ernel {M}odule {P}rogramming {G}uide
|
||||
ver 2.6.1},
|
||||
Journal = {The Linux Documentation Project http://www.tldp.org/},
|
||||
month = {26 } # may,
|
||||
year = 2005
|
||||
}
|
||||
|
||||
@Misc{entry-0,
|
||||
Title = {An {I}ntroduction to the {L}inux {A}rchitecture},
|
||||
HowPublished = {http://wiki.cs.uiuc.edu/cs427/An+Introduction+to+the+Linux+Architecture}
|
||||
}
|
||||
|
||||
@Misc{CS04,
|
||||
Author = {{C. S\'eveillac}},
|
||||
Title = {Build {Q}t/{E}mbedded and {O}pie on a {L}inux, x86
|
||||
architecture, for {ARM} target architecture.},
|
||||
HowPublished = {http://dudu.dyn.2-h.org/nist/qt-notes.php},
|
||||
month = {20 } # nov,
|
||||
year = 2004
|
||||
}
|
||||
|
||||
@Misc{Mo05,
|
||||
Author = {{M. opdenacker}},
|
||||
Title = {Embedded {L}inux {K}ernel and driver development},
|
||||
HowPublished = {http://free-electrons.com},
|
||||
month = {14 } # aug,
|
||||
year = 2005
|
||||
}
|
||||
|
||||
@Misc{BG,
|
||||
Author = {{Bill Gatliff}},
|
||||
Title = {Porting and {U}sing {N}ewlib in {E}mbedded {S}ystems},
|
||||
HowPublished = {http://venus.billgatliff.com/node/3}
|
||||
}
|
||||
|
||||
@Article{MB03,
|
||||
Author = {{M. Barr}},
|
||||
Title = {How to {C}hoose a {R}eal-{T}ime {O}perating {S}ystem},
|
||||
Journal = {Embedded Systems Programming},
|
||||
month = jan,
|
||||
year = 2003
|
||||
}
|
||||
|
||||
@Misc{IBSS98,
|
||||
Author = {{I. Bowman} and {S. Siddiqi} and {M. Tanuan}},
|
||||
Title = {Concrete {A}rchitecture of the {L}inux {K}ernel},
|
||||
HowPublished = {http://plg.uwaterloo.ca/~itbowman/CS746G/a2},
|
||||
month = {12 } # feb,
|
||||
year = 1998
|
||||
}
|
||||
|
||||
@Article{JT04,
|
||||
Author = {{J. Turley}},
|
||||
Title = {Embedded systems survey: {O}perating systems up for
|
||||
grabs},
|
||||
Journal = {Embedded Systems Programming},
|
||||
month = may,
|
||||
year = 2004
|
||||
}
|
||||
|
||||
@Book{JCAR05,
|
||||
Author = {{J. Corbet} and {A. Rubini} and {G. Kroah-Hartman}},
|
||||
Title = {Linux {D}evice {D}rivers, {T}hird {E}dition},
|
||||
Publisher = {O'Reilly},
|
||||
year = 2005
|
||||
}
|
||||
|
||||
@Misc{AO,
|
||||
Author = {{Aleph One}},
|
||||
Title = {Porting the {L}inux {K}ernel to a {N}ew {ARM}
|
||||
{P}latform},
|
||||
HowPublished = {http://www.aleph1.co.uk}
|
||||
}
|
||||
|
||||
@Book{CH02,
|
||||
Author = {{Craig Hollabaugh.}},
|
||||
Title = {Embedded {L}inux: {H}ardware, {S}oftware, and
|
||||
{I}nterfacing},
|
||||
Publisher = {Addison Wesley Professional.},
|
||||
month = {7 } # mar,
|
||||
year = 2002
|
||||
}
|
||||
|
||||
@Misc{VDC06,
|
||||
Author = {{Venture Development Corp.}},
|
||||
Title = {Small teams dominate embedded software development},
|
||||
HowPublished = {http://www.linuxdevices.com/articles/AT7019328497.html},
|
||||
month = {1 } # jun,
|
||||
year = 2006
|
||||
}
|
||||
|
||||
@Article{JT05,
|
||||
Author = {{J. Turley}},
|
||||
Title = {Five irreversible decisions},
|
||||
Journal = {Embedded Systems Programming},
|
||||
month = {27 } # jan,
|
||||
year = 2005
|
||||
}
|
||||
|
||||
@Misc{SR08,
|
||||
Author = {{S. Rhoads}},
|
||||
Title = {Plasma - most {MIPS} {I}({TM}) opcodes},
|
||||
HowPublished = {URL: http://opencores.org/project,plasma},
|
||||
year = 2008
|
||||
}
|
||||
|
||||
@Misc{A1,
|
||||
Author = {{Aleph 1}},
|
||||
Title = {Building the {T}oolchain},
|
||||
HowPublished = {http://www.aleph1.co.uk/node/279}
|
||||
}
|
||||
|
||||
@Misc{Ale01,
|
||||
Author = {Aleph1},
|
||||
Title = {Boot {L}oader {G}uide},
|
||||
HowPublished = {http://www.aleph1.co.uk/armlinux/docs/ARM
|
||||
booting/t1.html},
|
||||
month = {7 } # sep,
|
||||
year = 2001
|
||||
}
|
||||
|
||||
@Misc{DK06,
|
||||
Author = {{Dan Kegel}},
|
||||
Title = {Building and {T}esting gcc/glibc cross toolchains},
|
||||
HowPublished = {http://www.kegel.com/crosstool/},
|
||||
month = {20 } # feb,
|
||||
year = 2006
|
||||
}
|
||||
|
||||
@Misc{IB98,
|
||||
Author = {{I. Bowman}},
|
||||
Title = {Conceptual {A}rchitecture of the {L}inux {K}ernel},
|
||||
HowPublished = {http://www.grad.math.uwaterloo.ca/~itbowman/CS746G/a1/},
|
||||
year = 1998
|
||||
}
|
||||
|
||||
@Article{Lin05,
|
||||
Author = {Linuxdevices},
|
||||
Title = {Embedded {L}inux market snapshot, 2005},
|
||||
Journal = {http://www.linuxdevices.com},
|
||||
month = {4 } # may,
|
||||
year = 2005
|
||||
}
|
||||
|
||||
@Article{CLSB05,
|
||||
Author = {{C. Lanfear} and {S. Balacco} and {M. Volckmann}},
|
||||
Title = {The 2005 {E}mbedded {S}oftware {S}trategic {M}arket
|
||||
{I}ntelligence {P}rogram},
|
||||
Journal = {Venture Development Corporation
|
||||
http://www.vdc-corp.com},
|
||||
month = aug,
|
||||
year = 2005
|
||||
}
|
||||
|
666
course/.docs/cambio_categoria/chapter1.tex
Normal file
666
course/.docs/cambio_categoria/chapter1.tex
Normal file
@ -0,0 +1,666 @@
|
||||
\chapter{Diseño de Sistemas Embebidos}
|
||||
|
||||
\section{Definición}
|
||||
|
||||
Un Sistema Embebidos es un sistema de propósito específico en el cual, el computador es encapsulado completamente por el dispositivo que el controla. A diferencia de los computadores de propósito general, un Sistema Embebido realiza tareas pre-definidas, lo cual permite su optimización, reduciendo el tamaño y costo del producto \cite{Wik}
|
||||
|
||||
\section{Características}
|
||||
|
||||
\begin{itemize}
|
||||
\item Los sistemas embebidos son diseñados para una aplicación
|
||||
espec\'{\i}fica, es decir, estos sistemas realizan un grupo de funciones
|
||||
previamente definidasm y una vez el sistema es diseñ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ón con el entorno los ES deben cumplir
|
||||
esctrí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éricos y un componente software (procesador o DSP) capáz de ejecutar software, la parte del procesador está dividida en la CPU (En algunos casos posee una caché) 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ñías que fabrican procesadores de 32 bits integrados a una gran variedad de periféricos, lo cual simplifica el diseño y reduce costos (menos componentes y menos á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éricos requerida para una determinada aplicación, es necesario recurrir a la utilización de dispositivos comerciales que implementen dicha operación, en algunas ocaciones el periférico puede relizar funciones muy específicas de modo que no existe en el mercado, la solución es entonces implementar estos dispositivos en una FPGA, también se recomienda la utilización de FPGAs en sistemas que requieren una gran cantidad y variedad de periféricos ya que reduce la complejidad y costo del sistema.
|
||||
|
||||
\item Componente SW y HW en una FPGA: Esta es tal vez la opción más económica y flexible, pero la de menor desempeño, ya que al utilizar los recursos lógicos de la FPGA para la implementación del procesador (softcore) la lngitud de los caminos de interconexión entre los bloques lógicos aumentan el retardo de las señ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ía de Diseño}
|
||||
|
||||
La Figura \ref{des_flow}, muestra un diagrama de flujo genérico para diseño para sistemas embebidos {\cite{Cor05}}
|
||||
|
||||
\begin{figure}[H]
|
||||
\begin{center} \includegraphics[scale=.55]{./images/design_flow} \end{center}
|
||||
\caption{Flujo de Diseñ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ñ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ñ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ñ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ñ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ñ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ñ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ón; esta elección se debe a que la mayoría de los productos comerciales utilizan el toolchain de GNU\footnote{http://www.gnu.org} internamente y proporcionan un entorno gráfico para su fácil manejo. Otro factor considerado a la hora de realizar nuestra elección es el económico, ya que la mayorí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ñadores de sistemas embebidos y se encuentra un gran soporte en múltiples foros de discusió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ón de herramientas de desarrollo}\label{tools}
|
||||
\end{figure}
|
||||
|
||||
\subsection{Componentes del \textit{GNU toolchain} }
|
||||
|
||||
\subsubsection{GNU binutils\cite{A1}}
|
||||
Son una colecció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ón y un ejecutable, usa la información de depuración en el ejecutabe para determinar que nombre de atchivo y número de lpinea está asociado con la dirección dada.
|
||||
\item \textbf{ar} Esta utilidad crea, modifica y extrae desde ficheros. Un fichero es una colecció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 último paso en la construcció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í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ón sobre archivos tipo objeto.
|
||||
\item \textbf{ranlib} Genera un índice de contenidos de un fichero, y lo almacena en él.
|
||||
\item \textbf{readelf} Interpreta encabezados de un archivo ELF.
|
||||
\item \textbf{size} Lista el tamaño de las secciones y el tamañ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ó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ón, sin embargo, en el presente estudio solo lo utilizaremos como herramienta de compilación para C y C++. Una caracterí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ó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ás, la disponibilidad de librerías de múltiples propó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úmero promedio de desarrolladores por compañí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ón normal del mismo. Además, permite establecer sesiones remotas utilizando el puerto serie o TCP/IP. Aunque GDB no posee una interfaz gráfica, se han desarrollado varios front-ends como DDD o GDB/Insight. A continuación se muestra un ejemplo de una sesió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ía que proporcione las librerí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ía C oficial del proyecto GNU. Uno de los inconvenientes al trabajar con esta librería en sistemas embebidos es que genera ejecutables de mayor tamaño que los generados a partir de otras librerías, lo cual no la hace muy atractiva para este tipo de aplicaciones.
|
||||
\item \textbf{uClibc\footnote{http://uclibc.org/}} Es una librería diseñada especialmente para sistemas embebidos, es mucho más pequeña que \textbf{glibc}.
|
||||
\item \textbf{newlib\footnote{http://sources.redhat.com/newlib/}} Al igual que \textbf{uClibc}, está diseñ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ón de \textit{libc} optimizada en tamaño, puede ser utilizada para crear ejecutables estáticamente enlazados para linux en plataformas alpha, arm, hppa, ia64, i386, mips, s390, sparc, sparc64, ppc y x86\_64.
|
||||
\end{itemize}
|
||||
|
||||
|
||||
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|
||||
% SECCION Obtención y utilizació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ñ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ó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ó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án de forma adecuada.
|
||||
\item Utilizar un script de compilació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ón. En este estudio utilizaremos los \textit{scripts} creados por Dan Kegel \cite{DK06}.
|
||||
\end{enumerate}
|
||||
|
||||
\subsection{Flujo de diseño software}
|
||||
|
||||
En la figura \ref{toolchain_flow} se ilustra la secuencia de pasos que se realizan desde la creació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ó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ón del código fuente en cualquier editor de texto utilizando un lenguaje de alto nivel como C o C++.
|
||||
|
||||
\item \textbf{Compilació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ón que normalmente es de la familia x86); en este punto el compilador solo busca en los encabezados (\textit{headers}) la definición de una determinada función, esto es, la forma en que debe ser utilizada, el tipo de datos y el número de parámetros con que debe ser invocada, por ejemplo, la función \textit{printf} esta declarada en el archivo \textit{stdio.h} como: \textit{ int printf (const char *template, ...)}. Esta declaración es utilizada por el compilador para verificar el correcto uso de esta funció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ías precompiladas para el procesador de la plataforma, si una determinada función no es definida en ninguna de estas librerías, el \textit{enlazador} generará un error y no se generará el ejecutable.
|
||||
\item Se definen las posiciónes físicas de las secciones que componen el archivo ejecutable (tipo ELF), esto se realiza a través de un link de enlazado en el que se define de forma explícita su localización.
|
||||
\end{enumerate}
|
||||
|
||||
\item \textbf{Extracción del archivo de programació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á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í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ón a la memoria de la plataforma:
|
||||
\begin{enumerate}
|
||||
\item Utilizando un \textit{loader}: El \textit{loader} es una aplicación que reside en un medio de almacenamiento no volá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ón de memoria.
|
||||
\end{enumerate}
|
||||
|
||||
\item \textbf{Depuración} Una vez se descarga la aplicació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ó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ándard para objetos, librerías y ejecutables y es el formato que genera las herramientas GNU. Como puede verse en la figura \ref{elf1} está compuesto por varias secciones (\textit{link view}) o segmentos (\textit{execution view}). Si un programador está interesado en obtener información de secciones sobre tablas de símbolos, código ejecutable específico o información de enlazado dinámico debe utilizar \textit{link view}. Pero si busca información sobre segmentos, como por ejemplo, la localización de los segmentos \textit{text} o \textit{data} debe utilizar \textit{execution view}. El encabezado describe el layout del archivo, proporcionando informació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ón de enlazado dinámico, datos de depuració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ón de la versión.
|
||||
\item \textbf{.data y .data1} Datos inicializados. (RAM)
|
||||
\item \textbf{.debug} Información para depuración simbólica.
|
||||
\item \textbf{.dynamic} Información sobre enlace dinámico
|
||||
\item \textbf{.dynstr} Strings necesarios para el enlacedinámico
|
||||
\item \textbf{.dynsym} Tabla de símbolos utilizada para enlace dinámico.
|
||||
\item \textbf{.fini} Código de terminación de proceso.
|
||||
\item \textbf{.init} Código de inicialización de proceso.
|
||||
\item \textbf{.line} Información de número de línea para depuración simbó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ó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á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ón \textit{.text}, como se dijo anteriormente contiene las instrucciones ejecutables, por esta razón se marca como ejecutable \textit{``X''} en la columna \textit{Flg}. Es posible ver las instrucciones que se ejecutan en esta secció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ó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ón \textit{.data} contiene \'unicamente el valor de inicializaci\'on de la variable \textit{global\_1} (1) y no muestra informació\'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ón \textit{.text} observamos que esta variable es asignada en tiempo de ejecución, en la línea \textit{0c:} se ve la asignación de esta variable.
|
||||
|
||||
\begin{lstlisting}
|
||||
0c: e3a03002 mov r3, #2 ; 0x2
|
||||
10: e50b3008 str r3, [fp, #-8]
|
||||
\end{lstlisting}
|
||||
|
||||
|
||||
La secció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ón \textit{.rodata} mantiene los datos que no cambian durante la ejecución del programa, es decir, de solo lectura, si examinamos esta sección obtenemos:
|
||||
|
||||
\textit{hexdump -C hello.o | grep -i 000000d0} (la sección \textit{.rodata} comienza en la posició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ón aparece la cadena de caracteres \textit{Printing \%d\\n}, es decir, los datos que no cambian durante la ejecución.
|
||||
|
||||
|
||||
\subsection{Herramienta de compilación make}
|
||||
Como pudo verse en la sección es necesario realizar una serie de pasos para poder descargar una aplicació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áctico. Para realizar este proceso de forma automática se creó 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 última compilación y ejecuta los comandos necesarios para recompilarlos. Un ejemplo de este tipo de archivo se muestra a continuació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án utilizadas a lo largo del archivo; en las líneas 7 - 10 se definen las herramientas de compilación a utilizar, especí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ámetros de comportamiento de estas herramientas.
|
||||
|
||||
\begin{lstlisting}
|
||||
CFLAGS =-mcpu=arm920t -I. -Wall
|
||||
\end{lstlisting}
|
||||
|
||||
El parámetro \textit{-mcpu} le indica al compilador C para arquitecturas \textit{ARM} que utilice la familia \textit{arm920}; el pará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á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ámetro \textit{-L} le indica al enlazador la ruta del directorio donde se encuentran las librerí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ámetro \textit{-l} le indica al enlazador que debe utilizar la librería \textit{gcc} que se encuentra en el directorio definido previamente. En realidad el archivo de la librería tienen el nombre \textit{libgcc.a}, pero como todas las librerías tienen el nombre \textit{libXXXX.a} se eliminan el encabezado y la extensió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á 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á 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í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ámetros:
|
||||
\begin{itemize}
|
||||
\item \textbf{-e 0}: Punto de entrada , utiliza la direcció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í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ón necesaria para cargar en una memoria no volá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ías necesarias para crear el ejecutable, adicionalmente, permite definir donde será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ón. A continuació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ón de las memorias de la plataforma, en este ejemplo tenemos una memoria RAM de 64kB que comienza en la posición de memoria 0x00200000 y una memoria flash de 256k que comienza en la posición 0x0. A continuacion se definen las secciones y el lugar donde será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átil la flash. Cuando el sistema sea energizado el procesador ejecutará el código almacenado en su memoria no volátil. Las secciones \textit{.data} (variables inicializadas) y \textit{.bss} (variables no inicializadas) se almacenarán en la memoria volátil RAM, ya que el acceso a las memorias no volátiles son más lentas y tienen ciclos de lectura/escritura finitos.
|
||||
|
||||
\section{Herramientas hardware}
|
||||
En esta subsección se realizará una breve descripción de los dispositivos semiconductores más utilizados para la implementació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íficamente del AT91RM920 de Atmel. En este diagrama podemos observar el núcleo central un procesador ARM920T de 180MHz y los periféricos asociados a él. En la actualidad podemos encontrar una gran variedad de SoC diseñados para diferentes aplicaciones: Multimedia, Comunicaciones, Asistentes Digitales; los perifé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é uno de los primeros que diseño ATMEL y está enfocado a tareas en las que se requiere una conexión de red. La arquitectura de estos SoC evoluciona muy rápido acomodándose a los requerimientos de nuevas aplicaciones, básicamente, los cambios se producen en la velocidad del procesador central y la adición de periféricos que permiten el control directo de nuevos periféricos, como por ejemplo, la adición de controladores de pantallas de cristal líquido o salidas de video. Dentro de estos perifé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á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éricos que son indispensables en todo Sistema Embebido, los cuales facilitan la programación de aplicaciones y la depuración de las mismas. Uno de los más importantes y que están presentes en todos los SoC actuales es el controlador de memorias, este periférico permite controlar los medios de almecenamiento que son vitales para la correcta oepración del dispositivo, a continuación se hace un breve recuento de las memorias disponibles para el desarrollo de aplicaciones embebidas.
|
||||
|
||||
\subsection{Memorias Volátiles}
|
||||
|
||||
Como se estudió anteriormente existen secciones de un ejecutable que deben ser almacenadas en memorias volátiles o en memorias no volátiles. Debido a esto, la mayoría de los SoC incluyen periféricos dedicados a controlar diferentes tipos de memoria, las memorias volá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á 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ón por la cual es necesario recargar estos condensadores perió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ón, solo se recargan los condensadores para mantener la información.
|
||||
|
||||
Un ejemplo simplificado de una operación de lectura es el siguiente: Una posición de memoria se determina colocando la dirección de la fila y la de la columna en las líneas de dirección de fila y columna respectivamente, un tiempo después el dato almacenado aparecerá en el bus de datos. El procesador coloca la dirección de la fila en el bus de direcciones y después activa la señal \textit{RAS} (Row Access Strobe). Después de un retardo de tiempo predeterminado para permitir que el circuito de la SDRAM capture la dirección de la fila, el procesador coloca la dirección de la columna en el bus de direcciones y activa la señal \textit{CAS} (Column Access Strobe). El periférico que controla la SDRAM está encargado de garantizar los ciclos de refresco de acuerdo con los requerimientos de la SDRAM \cite{CH06}.
|
||||
|
||||
\subsection{Memorias No Volátiles}
|
||||
La memorias no volátiles almacenan por largos períodos de tiempo la información necesaria para la operació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ó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ó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é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ón. Adicionalmente las memorias NAND consumen menos potencia que las memorias NAND, por esta razó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ón. A diferencia de las flash tipo NOR, los dispositivos NAND se acceden de forma serial utilizando interfaces complejas; su operación se asemeja a un disco duro tradicional. Se accede a la información utilizando bloques (más pequeñ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ñarse de forma espontánea durante la operació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ón del sistema de toda la RAM para actualizar esta lista de sectores defectuosos. El algoritmo de ECC (Error-Correcting Code) debe ser capáz de corregir errores tan pequeños como un bit de cada 2048 bits, hasta 22 bits de cada 2048. Este algorítmo es capaz de detectar bloques defectuosos en la fase de programacíón comparando la información almacenada con la que debe ser almacenada (verificación), si encuentra un error marca el bloque como defectuoso y utiliza un bloque sin defactos para almacenar la información.
|
||||
|
||||
|
||||
La tabla \ref{flash_comp} resume las principales caracterí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ón & Almacenamiento & Almacenamiento & Solo lectura \\ \hline
|
||||
\end{tabular}
|
||||
\caption{Cuadro de comparació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ón con el procesador.
|
||||
|
||||
|
658
course/.docs/cambio_categoria/chapter1.tex.backup
Normal file
658
course/.docs/cambio_categoria/chapter1.tex.backup
Normal file
@ -0,0 +1,658 @@
|
||||
\chapter{Diseño de Sistemas Embebidos}
|
||||
|
||||
\section{Definición}
|
||||
|
||||
Un Sistema Embebidos es un sistema de propósito específico en el cual, el computador es encapsulado completamente por el dispositivo que el controla. A diferencia de los computadores de propósito general, un Sistema Embebido realiza tareas pre-definidas, lo cual permite su optimización, reduciendo el tamaño y costo del producto \cite{Wik}
|
||||
|
||||
\section{Características}
|
||||
|
||||
\begin{itemize}
|
||||
\item Los sistemas embebidos son diseñados para una aplicación
|
||||
espec\'{\i}fica, es decir, estos sistemas realizan un grupo de funciones
|
||||
previamente definidasm y una vez el sistema es diseñ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ón con el entorno los ES deben cumplir
|
||||
esctrí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éricos y un componente software (procesador o DSP) capáz de ejecutar software, la parte del procesador está dividida en la CPU (En algunos casos posee una caché) 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ñ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ñías que fabrican procesadores de 32 bits integrados a una gran variedad de periféricos, lo cual simplifica el diseño y reduce costos (menos componentes y menos á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éricos requerida para una determinada aplicación, es necesario recurrir a la utilización de dispositivos comerciales que implementen dicha operación, en algunas ocaciones el periférico puede relizar funciones muy específicas de modo que no existe en el mercado, la solución es entonces implementar estos dispositivos en una FPGA, también se recomienda la utilización de FPGAs en sistemas que requieren una gran cantidad y variedad de periféricos ya que reduce la complejidad y costo del sistema.
|
||||
|
||||
\item Componente SW y HW en una FPGA: Esta es tal vez la opción más económica y flexible, pero la de menor desempeño, ya que al utilizar los recursos lógicos de la FPGA para la implementación del procesador (softcore) la lngitud de los caminos de interconexión entre los bloques lógicos aumentan el retardo de las señ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ía de Diseño}
|
||||
|
||||
La Figura \ref{des_flow}, muestra un diagrama de flujo genérico para diseño para sistemas embebidos {\cite{Cor05}}
|
||||
|
||||
\begin{figure}
|
||||
\begin{center} \includegraphics[scale=.55]{./images/design_flow} \end{center}
|
||||
\caption{Flujo de Diseñ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ñ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ñ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ñ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ñ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ñ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ñ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ón; esta elección se debe a que la mayoría de los productos comerciales utilizan el toolchain de GNU\footnote{http://www.gnu.org} internamente y proporcionan un entorno gráfico para su fácil manejo. Otro factor considerado a la hora de realizar nuestra elección es el económico, ya que la mayorí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ñadores de sistemas embebidos y se encuentra un gran soporte en múltiples foros de discusión (ver Figura \ref{tools}).
|
||||
|
||||
\begin{figure}
|
||||
\begin{center} \includegraphics[scale=.7]{./images/embedded-linux-tool-trends-sm} \end{center}
|
||||
\caption{Tendencia de utilización de herramientas de desarrollo}\label{tools}
|
||||
\end{figure}
|
||||
|
||||
\subsection{Componentes del \textit{GNU toolchain} }
|
||||
|
||||
\subsubsection{GNU binutils\cite{A1}}
|
||||
Son una colecció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ón y un ejecutable, usa la información de depuración en el ejecutabe para determinar que nombre de atchivo y número de lpinea está asociado con la dirección dada.
|
||||
\item \textbf{ar} Esta utilidad crea, modifica y extrae desde ficheros. Un fichero es una colecció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 último paso en la construcció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í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ón sobre archivos tipo objeto.
|
||||
\item \textbf{ranlib} Genera un índice de contenidos de un fichero, y lo almacena en él.
|
||||
\item \textbf{readelf} Interpreta encabezados de un archivo ELF.
|
||||
\item \textbf{size} Lista el tamaño de las secciones y el tamañ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ó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ón, sin embargo, en el presente estudio solo lo utilizaremos como herramienta de compilación para C y C++. Una caracterí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ó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ás, la disponibilidad de librerías de múltiples propó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ñí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ón normal del mismo. Además, permite establecer sesiones remotas utilizando el puerto serie o TCP/IP. Aunque GDB no posee una interfaz gráfica, se han desarrollado varios front-ends como DDD o GDB/Insight. A continuación se muestra un ejemplo de una sesió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ía que proporcione las librerí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ía C oficial del proyecto GNU. Uno de los inconvenientes al trabajar con esta librería en sistemas embebidos es que genera ejecutables de mayor tamaño que los generados a partir de otras librerías, lo cual no la hace muy atractiva para este tipo de aplicaciones.
|
||||
\item \textbf{uClibc\footnote{http://uclibc.org/}} Es una librería diseñada especialmente para sistemas embebidos, es mucho más pequeña que \textbf{glibc}.
|
||||
\item \textbf{newlib\footnote{http://sources.redhat.com/newlib/}} Al igual que \textbf{uClibc}, está diseñ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ón de \textit{libc} optimizada en tamaño, puede ser utilizada para crear ejecutables estáticamente enlazados para linux en plataformas alpha, arm, hppa, ia64, i386, mips, s390, sparc, sparc64, ppc y x86\_64.
|
||||
\end{itemize}
|
||||
|
||||
|
||||
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|
||||
% SECCION Obtención y utilizació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ñ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ó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ó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án de forma adecuada.
|
||||
\item Utilizar un script de compilació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ón. En este estudio utilizaremos los \textit{scripts} creados por Dan Kegel \cite{DK06}.
|
||||
\end{enumerate}
|
||||
|
||||
\subsection{Flujo de diseño software}
|
||||
|
||||
En la figura \ref{toolchain_flow} se ilustra la secuencia de pasos que se realizan desde la creació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ó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ón del código fuente en cualquier editor de texto utilizando un lenguaje de alto nivel como C o C++.
|
||||
|
||||
\item \textbf{Compilació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ón que normalmente es de la familia x86); en este punto el compilador solo busca en los encabezados (\textit{headers}) la definición de una determinada función, esto es, la forma en que debe ser utilizada, el tipo de datos y el número de parámetros con que debe ser invocada, por ejemplo, la función \textit{printf} esta declarada en el archivo \textit{stdio.h} como: \textit{ int printf (const char *template, ...)}. Esta declaración es utilizada por el compilador para verificar el correcto uso de esta funció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ías precompiladas para el procesador de la plataforma, si una determinada función no es definida en ninguna de estas librerías, el \textit{enlazador} generará un error y no se generará el ejecutable.
|
||||
\item Se definen las posiciónes físicas de las secciones que componen el archivo ejecutable (tipo ELF), esto se realiza a través de un link de enlazado en el que se define de forma explícita su localización.
|
||||
\end{enumerate}
|
||||
|
||||
\item \textbf{Extracción del archivo de programació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á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í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ón a la memoria de la plataforma:
|
||||
\begin{enumerate}
|
||||
\item Utilizando un \textit{loader}: El \textit{loader} es una aplicación que reside en un medio de almacenamiento no volá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ón de memoria.
|
||||
\end{enumerate}
|
||||
|
||||
\item \textbf{Depuración} Una vez se descarga la aplicació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ó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ándard para objetos, librerías y ejecutables y es el formato que genera las herramientas GNU. Como puede verse en la figura \ref{elf1} está compuesto por varias secciones (\textit{link view}) o segmentos (\textit{execution view}). Si un programador está interesado en obtener información de secciones sobre tablas de símbolos, código ejecutable específico o información de enlazado dinámico debe utilizar \textit{link view}. Pero si busca información sobre segmentos, como por ejemplo, la localización de los segmentos \textit{text} o \textit{data} debe utilizar \textit{execution view}. El encabezado describe el layout del archivo, proporcionando informació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ón de enlazado dinámico, datos de depuració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ón de la versión.
|
||||
\item \textbf{.data y .data1} Datos inicializados. (RAM)
|
||||
\item \textbf{.debug} Información para depuración simbólica.
|
||||
\item \textbf{.dynamic} Información sobre enlace dinámico
|
||||
\item \textbf{.dynstr} Strings necesarios para el enlacedinámico
|
||||
\item \textbf{.dynsym} Tabla de símbolos utilizada para enlace dinámico.
|
||||
\item \textbf{.fini} Código de terminación de proceso.
|
||||
\item \textbf{.init} Código de inicialización de proceso.
|
||||
\item \textbf{.line} Información de número de línea para depuración simbó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ó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á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ón \textit{.text}, como se dijo anteriormente contiene las instrucciones ejecutables, por esta razón se marca como ejecutable \textit{``X''} en la columna \textit{Flg}. Es posible ver las instrucciones que se ejecutan en esta secció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ó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ón \textit{.data} contiene \'unicamente el valor de inicializaci\'on de la variable \textit{global\_1} (1) y no muestra informació\'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ón \textit{.text} observamos que esta variable es asignada en tiempo de ejecución, en la línea \textit{0c:} se ve la asignación de esta variable.
|
||||
|
||||
\begin{lstlisting}
|
||||
0c: e3a03002 mov r3, #2 ; 0x2
|
||||
10: e50b3008 str r3, [fp, #-8]
|
||||
\end{lstlisting}
|
||||
|
||||
|
||||
La secció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ón \textit{.rodata} mantiene los datos que no cambian durante la ejecución del programa, es decir, de solo lectura, si examinamos esta sección obtenemos:
|
||||
|
||||
\textit{hexdump -C hello.o | grep -i 000000d0} (la sección \textit{.rodata} comienza en la posició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ón aparece la cadena de caracteres \textit{Printing \%d\\n}, es decir, los datos que no cambian durante la ejecución.
|
||||
|
||||
|
||||
\subsection{Herramienta de compilación make}
|
||||
Como pudo verse en la sección es necesario realizar una serie de pasos para poder descargar una aplicació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áctico. Para realizar este proceso de forma automática se creó 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 última compilación y ejecuta los comandos necesarios para recompilarlos. Un ejemplo de este tipo de archivo se muestra a continuació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án utilizadas a lo largo del archivo; en las líneas 7 - 10 se definen las herramientas de compilación a utilizar, especí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ámetros de comportamiento de estas herramientas.
|
||||
|
||||
\begin{lstlisting}
|
||||
CFLAGS =-mcpu=arm920t -I. -Wall
|
||||
\end{lstlisting}
|
||||
|
||||
El parámetro \textit{-mcpu} le indica al compilador C para arquitecturas \textit{ARM} que utilice la familia \textit{arm920}; el pará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á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ámetro \textit{-L} le indica al enlazador la ruta del directorio donde se encuentran las librerí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ámetro \textit{-l} le indica al enlazador que debe utilizar la librería \textit{gcc} que se encuentra en el directorio definido previamente. En realidad el archivo de la librería tienen el nombre \textit{libgcc.a}, pero como todas las librerías tienen el nombre \textit{libXXXX.a} se eliminan el encabezado y la extensió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á 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á 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í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ámetros:
|
||||
\begin{itemize}
|
||||
\item \textbf{-e 0}: Punto de entrada , utiliza la direcció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í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ón necesaria para cargar en una memoria no volá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ías necesarias para crear el ejecutable, adicionalmente, permite definir donde será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ón. A continuació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ón de las memorias de la plataforma, en este ejemplo tenemos una memoria RAM de 64kB que comienza en la posición de memoria 0x00200000 y una memoria flash de 256k que comienza en la posición 0x0. A continuacion se definen las secciones y el lugar donde será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átil la flash. Cuando el sistema sea energizado el procesador ejecutará el código almacenado en su memoria no volátil. Las secciones \textit{.data} (variables inicializadas) y \textit{.bss} (variables no inicializadas) se almacenarán en la memoria volátil RAM, ya que el acceso a las memorias no volátiles son más lentas y tienen ciclos de lectura/escritura finitos.
|
||||
|
||||
\section{Herramientas hardware}
|
||||
En esta subsección se realizará una breve descripción de los dispositivos semiconductores más utilizados para la implementació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íficamente del AT91RM920 de Atmel. En este diagrama podemos observar el núcleo central un procesador ARM920T de 180MHz y los periféricos asociados a él. En la actualidad podemos encontrar una gran variedad de SoC diseñados para diferentes aplicaciones: Multimedia, Comunicaciones, Asistentes Digitales; los perifé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é uno de los primeros que diseño ATMEL y está enfocado a tareas en las que se requiere una conexión de red. La arquitectura de estos SoC evoluciona muy rápido acomodándose a los requerimientos de nuevas aplicaciones, básicamente, los cambios se producen en la velocidad del procesador central y la adición de periféricos que permiten el control directo de nuevos periféricos, como por ejemplo, la adición de controladores de pantallas de cristal líquido o salidas de video. Dentro de estos perifé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á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éricos que son indispensables en todo Sistema Embebido, los cuales facilitan la programación de aplicaciones y la depuración de las mismas. A continuación se realizará una descripción de los diferentes periféricos que se encuentran disponibles en este SoC, indicando los que fueron utilizados en la plataforma de desarrollo.
|
||||
|
||||
\subsubsection{Memorias Volátiles}
|
||||
|
||||
Como se estudió anteriormente existen secciones del ejecutable que deben ser almacenadas en memorias volátiles o en memorias no volátiles. Debido a esto la mayoría de los SoC incluyen periféricos dedicados a controlar diferentes tipos de memoria, las memorias volá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á 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ón de lectura es el siguiente: Una posición de memoria se determina colocando la dirección de la fila y la de la columna en las líneas de dirección de fila y columna respectivamente, un tiempo después el dato almacenado aparecerá en el bus de datos. El procesador coloca la dirección de la fila en el bus de direcciones y después activa la señal \textit{RAS} (Row Access Strobe). Después de un retardo de tiempo predeterminado para permitir que el circuito de la SDRAM capture la dirección de la fila, el procesador coloca la dirección de la columna en el bus de direcciones y activa la señ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ón por la cual es necesario recargar estos condensadores perió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ón, solo se recargan los condensadores para mantener la información. El periférico que controla la SDRAM está encargado de garantizar los ciclos de refresco de acuerdo con los requerimientos de la SDRAM \cite{CH06}.
|
||||
|
||||
\subsubsection{Memorias No Volátiles}
|
||||
La memorias no volátiles almacenan por largos períodos de tiempo información necesaria para la operació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ón con los requeridos por las memorias RAM.
|
||||
|
||||
Las memorias NOR poseen buses de datos y direcció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é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ón. Adicionalmente las memorias NAND consumen menos potencia que las memorias NAND, por esta razó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ón. A diferencia de las flash tipo NOR, los dispositivos NAND se acceden de forma serial utilizando interfaces complejas; su operación se asemeja a un disco duro tradicional. Se accede a la información utilizando bloques (más pequeñ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ñarse de forma espontánea durante la operació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ón del sistema de toda la RAM para actualizar esta lista de sectores defectuosos. El algoritmo de ECC (Error-Correcting Code) debe ser capáz de corregir errores tan pequeños como un bit de cada 2048 bits, hasta 22 bits de cada 2048. Este algorítmo es capaz de detectar bloques defectuosos en la fase de programacíón comparando la información almacenada con la que debe ser almacenada (verificación), si encuentra un error marca el bloque como defectuoso y utiliza un bloque sin defactos para almacenar la información.
|
||||
|
||||
La tabla \ref{flash_comp} resume las principales caracterí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ón & Almacenamiento & Almacenamiento & Solo lectura \\ \hline
|
||||
\end{tabular}
|
||||
\caption{Cuadro de comparació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ón con el procesador.
|
||||
|
512
course/.docs/cambio_categoria/chapter1.tex~
Normal file
512
course/.docs/cambio_categoria/chapter1.tex~
Normal file
@ -0,0 +1,512 @@
|
||||
\chapter{Conceptos Básicos de los Sistemas Embebidos}
|
||||
|
||||
\section{Definición}
|
||||
|
||||
Un Sistema Embebidos es un sistema de propósito específico en el cual, el computador es encapsulado completamente por el dispositivo que el controla. A diferencia de los computadores de propósito general, un Sistema Embebido realiza tareas pre-definidas, lo cual permite su optimización, reduciendo el tamaño y costo del producto \cite{Wik}
|
||||
|
||||
\section{Características}
|
||||
|
||||
\begin{itemize}
|
||||
\item Los sistemas embebidos son diseñados para una aplicación
|
||||
espec\'{\i}fica, es decir, estos sistemas realizan un grupo de funciones
|
||||
previamente definidasm y una vez el sistema es diseñ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ón con el entorno los ES deben cumplir
|
||||
esctrí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éricos y un componente software (procesador o DSP) capáz de ejecutar software, la parte del procesador está dividida en la CPU (En algunos casos posee una caché) 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ñ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ñías que fabrican procesadores de 32 bits integrados a una gran variedad de periféricos, lo cual simplifica el diseño y reduce costos (menos componentes y menos á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éricos requerida para una determinada aplicación, es necesario recurrir a la utilización de dispositivos comerciales que implementen dicha operación, en algunas ocaciones el periférico puede relizar funciones muy específicas de modo que no existe en el mercado, la solución es entonces implementar estos dispositivos en una FPGA, también se recomienda la utilización de FPGAs en sistemas que requieren una gran cantidad y variedad de periféricos ya que reduce la complejidad y costo del sistema.
|
||||
|
||||
\item Componente SW y HW en una FPGA: Esta es tal vez la opción más económica y flexible, pero la de menor desempeño, ya que al utilizar los recursos lógicos de la FPGA para la implementación del procesador (softcore) la lngitud de los caminos de interconexión entre los bloques lógicos aumentan el retardo de las señ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ía de Diseño}
|
||||
|
||||
La Figura \ref{des_flow}, muestra un diagrama de flujo de diseño genérico para sistemas
|
||||
embebidos {\cite{Cor05}}
|
||||
|
||||
\begin{figure}
|
||||
\begin{center} \includegraphics[scale=.55]{./images/design_flow} \end{center}
|
||||
\caption{Flujo de Diseñ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ñ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ñ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ñ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ñ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ñ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ó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ón;
|
||||
esta elección se debe a que la mayoría de los productos comerciales utilizan el toolchain de GNU\footnote{http://www.gnu.org} internamente y proporcionan un entorno gráfico para su fácil manejo. Otro factor considerado a la hora de realizar nuestra elección es el económico, ya que la mayorí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ñadores de sistemas embebidos y se encuentra un gran soporte en múltiples foros de discusió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ón de herramientas de desarrollo}\label{tools}
|
||||
\end{figure}
|
||||
|
||||
\subsection{Componentes del \textit{GNU toolchain} }
|
||||
|
||||
\subsection{GNU binutils\cite{A1}}
|
||||
Son una colecció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ón y un ejecutable, usa la información de depuración en el ejecutabe para determinar que nombre de atchivo y número de lpinea está asociado con la dirección dada.
|
||||
\item \textbf{ar} Esta utilidad crea, modifica y extrae desde ficheros. Un fichero es una colecció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 último paso en la construcció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í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ón sobre archivos tipo objeto.
|
||||
\item \textbf{ranlib} Genera un índice de contenidos de un fichero, y lo almacena en él.
|
||||
\item \textbf{readelf} Interpreta encabezados de un archivo ELF.
|
||||
\item \textbf{size} Lista el tamaño de las secciones y el tamañ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ó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ón, sin embargo, en el presente estudio solo lo utilizaremos como herramienta de compilación para C y C++. Una caracterí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ó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ás, la disponibilidad de librerías de múltiples propó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úmero promedio de desarrolladores por compañí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ón normal del mismo. Además, permite establecer sesiones remotas utilizando el puerto serie o TCP/IP. Aunque GDB no posee una interfaz gráfica, se han desarrollado varios front-ends como DDD o GDB/Insight. A continuación se muestra un ejemplo de una sesió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ía que proporcione las librerí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ía C oficial del proyecto GNU. Uno de los inconvenientes al trabajar con esta librería en sistemas embebidos es que genera ejecutables de mayor tamaño que los generados a partir de otras librerías, lo cual no la hace muy atractiva para este tipo de aplicaciones.
|
||||
\item \textbf{uClibc\footnote{http://uclibc.org/}} Es una librería diseñada especialmente para sistemas embebidos, es mucho más pequeña que \textbf{glibc}.
|
||||
\item \textbf{newlib\footnote{http://sources.redhat.com/newlib/}} Al igual que \textbf{uClibc}, está diseñ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ón de \textit{libc} optimizada en tamaño, puede ser utilizada para crear ejecutables estáticamente enlazados para linux en plataformas alpha, arm, hppa, ia64, i386, mips, s390, sparc, sparc64, ppc y x86\_64.
|
||||
\end{itemize}
|
||||
|
||||
|
||||
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|
||||
% SECCION Obtención y utilización del GNU toolchain
|
||||
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|
||||
|
||||
\section{Obtención y utilizació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ón es la ARM (Advanced Risc Machines), ya que un la más utilizada en la actualidad por los diseñ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ó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án de forma adecuada.
|
||||
\item Utilizar un script de compilació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ó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ño software, y el formato ELF.
|
||||
|
||||
\subsubsection{El formato \textbf{ELF}}
|
||||
|
||||
El formato ELF (\textit{Executable and Linkable Format}) Es un stándard para objetos, librerías y ejecutables. Como puede verse en la figura \ref{elf1} el formato ELF está compuesto por varias secciones (\textit{link view}) o segmentos (\textit{execution view}). Si un programador está interesado en obtener información de secciones sobre tablas de símbolos, código ejecutable específico o información de enlazado dinámico debe utilizar \textit{link view}. Pero si busca información sobre segmentos, como por ejemplo, la localización de los segmentos \textit{text} o \textit{data} debe utilizar \textit{execution view}. El encabezado describe el layout del archivo, proporcionando informació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ón de enlazado dinámico, datos de depuració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ón de la versión.
|
||||
\item \textbf{.data y .data1} Datos inicializados. (RAM)
|
||||
\item \textbf{.debug} Información para depuración simbólica.
|
||||
\item \textbf{.dynamic} Información sobre enlace dinámico
|
||||
\item \textbf{.dynstr} Strings necesarios para el enlacedinámico
|
||||
\item \textbf{.dynsym} Tabla de símbolos utilizada para enlace dinámico.
|
||||
\item \textbf{.fini} Código de terminación de proceso.
|
||||
\item \textbf{.init} Código de inicialización de proceso.
|
||||
\item \textbf{.line} Información de número de línea para depuración simbó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án en las secciones \textit{.bss} y \textit{.data} respectivamente, así mismo los caracteres ``Printing `` Estarán incluidos en la sección \textit{.rodata} ya que son datos que no cambian a lo largo de la ejecución del programa. Las instrucciones que forman el programa residen en la sección \textit{.text}. A continuación se muestra la información de este archivo una vez compilado, utilizando la herramienta \textit{objdump} de los utilitarios binarios \textit{binutils} y más especí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ón correspondiente a la sección \textit{.rodata}, la primera columna corresponde al tamaño de la sección, en este caso 16 bytes, las columnas 2 y 3 corresponden a la dirección de ejecución (VMA) y a la dirección de carga (LMA) respectivamente. La columna 4 indica la dirección dentro del ejecutable donde se encuentra almacenada esta información, en este caso la \textit{0x000004d0}, utilizando la herramienta \textit{hexdump} podemos ver el contenido de esa direcció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ño software}
|
||||
|
||||
En la figura \ref{toolchain_flow} se ilustra la secuencia de pasos que se realizan desde la creación de un archivo de texto que posee el código fuente de una aplicación hasta su implementació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ón se realiza una breve descripción de los pasos necesarios para generar un ejecutable para un sistema embebido:
|
||||
|
||||
\begin{enumerate}
|
||||
\item \textbf{Escritura del código fuente:} Creación del código fuente en cualquier editor de archivos de texto.
|
||||
\item \textbf{Compilació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ías la definición de una determinada funció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ías, si una determinada función no es edfinida por ninguna de las librerías pasadas como parámetro al linker, este generará un error y no se generará el ejecutable.
|
||||
\item Se define la posiciónes físicas de las secciones del ejecutable tipo ELF, esto se realiza a través de un link de enlazado el cual define de forma explícita su localización.
|
||||
\end{enumerate}
|
||||
\item \textbf{Extracción del archivo de programación} En algunas aplicaciones es necesario extraer únicamente las secciones que residen en los medios de almacenamiento no volátil y eliminar las demás secciones del ejecutable. Esto se realiza con la herramiento \textit{objcopy}, la cual, permite generar archivos en la mayorí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ón a la memoria de la plataforma de desarrollo:
|
||||
\begin{enumerate}
|
||||
\item Utilizando un \textit{loader}: El \textit{loader} es una aplicación que reside en un medio de almacenamiento no volá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ón de memoria.
|
||||
\end{enumerate}
|
||||
|
||||
\item \textbf{Depuración} Una vez se descarga la aplicació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ón que puede ser un puerto serie o un adaptador de red.
|
||||
|
||||
\end{enumerate}
|
||||
|
||||
\section{Makefile}
|
||||
Como pudo verse en la sección es necesario realizar una serie de pasos para poder descargar una aplicació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áctico. Para realizar este proceso de forma automática se creó 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ó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án utilizadas a lo largo del archivo; en las líneas 7 - 10 se definen las herramientas de compilación a utilizar, especí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í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á 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á 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í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ámetros:
|
||||
\begin{itemize}
|
||||
\item \textbf{-e 0}: Punto de entrada , utilice 0 como símbolo para el inicio de ejecució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í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ón necesaria para cargar en una memoria no volátil.
|
||||
|
||||
|
||||
|
24
course/.docs/cambio_categoria/chapter2.tex
Normal file
24
course/.docs/cambio_categoria/chapter2.tex
Normal file
@ -0,0 +1,24 @@
|
||||
\chapter{Sistema en un Chip (SoC)}
|
||||
|
||||
En esta sección estudiaremos la arquitectura básica de un SoC moderno, componentes, funcionamiento, programación y operación. Como se mencionó anteriormente, la tendencia actual de la industria de los semiconductores es integrar en un solo dispositivo las funcionalidades necesarias para la implementación de dispositivos digitales modernos. Esto es posibe gracias a los grandes avances en las técnicas de fabricación de circuitos integrados y a la demanda de nuevas características exigidas por los fabricantes de dispositivos digitales de consumo masivo como teléfonos celulares, PDAs, consolas de juegos y reproductores multimedia. Para utilizar estos avances tecnológicos es necesario conocer su arquitectura, principio de funcionamiento, programación e implementación, para esto, se estudiarán dos proyectos abiertos que implementan un SoC en un PLD utilizando lenguaje de descripció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é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éricos, dependiendo de la aplicación; dentro de los más comunes se encuentran: controladores de memorias externas (NOR, NAND, SDRAM, DDR), puertos de comunicación (I2C, SPI), puerto de depuració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á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á encargada de centralizar las tareas del sistema coordinando las acciones de los periféricos. Puede ser vista como una máquina de estados programable que controla un camino de datos compuesto por bloques aritmé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ón específica, indicandole paso a paso donde debe leer la información, como procesarla y como entregar el resultado. A Esta función se le conoce con el nombre de programa o tarea Software.
|
||||
|
||||
|
||||
\subsubsection{Periféricos}
|
||||
Los periféricos proporcionan la comunicación con el exterior, permiten el ingreso, almacenamiento y procesamiento de la información
|
||||
|
||||
|
16
course/.docs/cambio_categoria/chapter2.tex.backup
Normal file
16
course/.docs/cambio_categoria/chapter2.tex.backup
Normal file
@ -0,0 +1,16 @@
|
||||
\chapter{Sistema en un Chip (SoC)}
|
||||
|
||||
En esta sección estudiaremos la arquitectura básica de un SoC moderno, componentes, funcionamiento, programación y operación. Como se mencionó anteriormente la tendencia actual de la industria de los semiconductores es integrar en un solo dispositivo las funcionalidades necesarias para la implementación de dispositivos digitales modernos. Esto es posibe gracias a los grandes avances en las técnicas de fabricación de circuitos integrados y a la demanda de nuevas características exigidas por los fabricantes de dispositivos digitales de consumo masivo como teléfonos celuulares, PDAs, consolas de juegos y reproductores multimedia. Para utilizar estos avances tecnoló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án utilizados como base de nuestro estudio.
|
||||
|
||||
|
||||
\section{Arquitectura}
|
||||
|
||||
Un SoC, integra un conjunto de periféricos, memorias y una o varias unidades de procesamiento (CPUs) en un solo chip, lo cual facilita el desarrollo, los periféricos varían dependiendo de la aplicación, dentro de los más comunes se encuentran: controladores de memorias externas (NOR, NAND, SDRAM, DDR), puertos de comunicación (I2C, SPI), puerto de depuración (UART), timers, reloj de tiempo real. Según la aplicación es común encontrar: codecs de audio, controladores de LCD, controladores de red, controlador de puerto USB host, controlador para sensores de imá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éricos (la cual varía entre fabricantes).
|
||||
|
||||
\begin{figure}
|
||||
\begin{center} \includegraphics[scale=.6]{./images/Computer-simple} \end{center}
|
||||
\caption{Arquitectura mínima de un SoC}\label{min_soc_arch}
|
||||
\end{figure}
|
||||
|
2245
course/.docs/cambio_categoria/chaptera.tex
Normal file
2245
course/.docs/cambio_categoria/chaptera.tex
Normal file
File diff suppressed because it is too large
Load Diff
159
course/.docs/cambio_categoria/embedded.kilepr
Normal file
159
course/.docs/cambio_categoria/embedded.kilepr
Normal file
@ -0,0 +1,159 @@
|
||||
[General]
|
||||
def_graphic_ext=eps
|
||||
img_extIsRegExp=false
|
||||
img_extensions=.eps .jpg .jpeg .png .pdf .ps .fig .gif
|
||||
kileprversion=2
|
||||
kileversion=2.0.85
|
||||
lastDocument=chapter2.tex
|
||||
masterDocument=
|
||||
name=embedded
|
||||
pkg_extIsRegExp=false
|
||||
pkg_extensions=.cls .sty .bbx .cbx .lbx
|
||||
src_extIsRegExp=false
|
||||
src_extensions=.tex .ltx .latex .dtx .ins
|
||||
|
||||
[Tools]
|
||||
MakeIndex=
|
||||
QuickBuild=
|
||||
|
||||
[document-settings,item:chapter1.tex]
|
||||
Bookmarks=
|
||||
Encoding=ISO-8859-3
|
||||
Highlighting=LaTeX
|
||||
Indentation Mode=
|
||||
Mode=LaTeX
|
||||
ReadWrite=true
|
||||
|
||||
[document-settings,item:chapter2.tex]
|
||||
Bookmarks=
|
||||
Encoding=ISO-8859-3
|
||||
Highlighting=LaTeX
|
||||
Indentation Mode=
|
||||
Mode=LaTeX
|
||||
ReadWrite=true
|
||||
|
||||
[document-settings,item:embedded.tex]
|
||||
Bookmarks=
|
||||
Encoding=ISO-8859-3
|
||||
Highlighting=LaTeX
|
||||
Indentation Mode=
|
||||
Mode=LaTeX
|
||||
ReadWrite=true
|
||||
|
||||
[document-settings,item:embedded_book.tex]
|
||||
Bookmarks=
|
||||
Encoding=ISO-8859-3
|
||||
Highlighting=LaTeX
|
||||
Indentation Mode=
|
||||
Mode=LaTeX
|
||||
ReadWrite=true
|
||||
|
||||
[document-settings,item:introduction.tex]
|
||||
Bookmarks=
|
||||
Encoding=ISO-8859-3
|
||||
Highlighting=LaTeX
|
||||
Indentation Mode=
|
||||
Mode=LaTeX
|
||||
ReadWrite=true
|
||||
|
||||
[document-settings,item:title.tex]
|
||||
Bookmarks=
|
||||
Encoding=ISO-8859-3
|
||||
Highlighting=LaTeX
|
||||
Indentation Mode=
|
||||
Mode=LaTeX
|
||||
ReadWrite=true
|
||||
|
||||
[item:chapter1.tex]
|
||||
archive=true
|
||||
column=0
|
||||
encoding=ISO-8859-3
|
||||
highlight=LaTeX
|
||||
line=665
|
||||
mode=LaTeX
|
||||
open=true
|
||||
order=3
|
||||
|
||||
[item:chapter2.tex]
|
||||
archive=true
|
||||
column=9
|
||||
encoding=ISO-8859-3
|
||||
highlight=LaTeX
|
||||
line=5
|
||||
mode=LaTeX
|
||||
open=true
|
||||
order=5
|
||||
|
||||
[item:embedded.kilepr]
|
||||
archive=true
|
||||
column=1
|
||||
encoding=
|
||||
highlight=
|
||||
line=0
|
||||
mode=
|
||||
open=false
|
||||
order=-1
|
||||
|
||||
[item:embedded.tex]
|
||||
archive=true
|
||||
column=7
|
||||
encoding=ISO-8859-3
|
||||
highlight=LaTeX
|
||||
line=29
|
||||
mode=LaTeX
|
||||
open=true
|
||||
order=0
|
||||
|
||||
[item:embedded_book.tex]
|
||||
archive=true
|
||||
column=21
|
||||
encoding=ISO-8859-3
|
||||
highlight=LaTeX
|
||||
line=50
|
||||
mode=LaTeX
|
||||
open=true
|
||||
order=1
|
||||
|
||||
[item:introduction.tex]
|
||||
archive=true
|
||||
column=89
|
||||
encoding=ISO-8859-3
|
||||
highlight=LaTeX
|
||||
line=20
|
||||
mode=LaTeX
|
||||
open=true
|
||||
order=2
|
||||
|
||||
[item:title.tex]
|
||||
archive=true
|
||||
column=29
|
||||
encoding=ISO-8859-3
|
||||
highlight=LaTeX
|
||||
line=18
|
||||
mode=LaTeX
|
||||
open=true
|
||||
order=4
|
||||
|
||||
[view-settings,view=0,item:chapter1.tex]
|
||||
CursorColumn=0
|
||||
CursorLine=665
|
||||
|
||||
[view-settings,view=0,item:chapter2.tex]
|
||||
CursorColumn=9
|
||||
CursorLine=5
|
||||
|
||||
[view-settings,view=0,item:embedded.tex]
|
||||
CursorColumn=7
|
||||
CursorLine=29
|
||||
|
||||
[view-settings,view=0,item:embedded_book.tex]
|
||||
CursorColumn=21
|
||||
CursorLine=50
|
||||
|
||||
[view-settings,view=0,item:introduction.tex]
|
||||
CursorColumn=89
|
||||
CursorLine=20
|
||||
|
||||
[view-settings,view=0,item:title.tex]
|
||||
CursorColumn=29
|
||||
CursorLine=18
|
647
course/.docs/cambio_categoria/embedded.tex
Normal file
647
course/.docs/cambio_categoria/embedded.tex
Normal file
@ -0,0 +1,647 @@
|
||||
\chapter{Sistemas Embebidos}
|
||||
\label{ch:embedded}
|
||||
|
||||
\section{Introducción}
|
||||
Uno de los objetivos de este trabajo, es la creación de una plataforma Embebida que permita la apropiación de nuevas herramientas y metodologías de diseño.
|
||||
El mercado de los sistemas embebidos continúa en aumento y su campo de acción se ha extendido en casi todas las actividades humanas.
|
||||
Segú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ón obtenido por la industria de los semiconductores en los \textit{SOC}, la disponibilidad de herramientas software
|
||||
de desarrollo gratuitas (compiladores, simuladores, librerí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ón de estos sistemas.
|
||||
|
||||
Más de un billón de dispositivos embebidos fueron vendidos en el 2004, segú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ón (tales como Ethernet, bluetooth, WiFi, etc); ademá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í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ón de Linux como herramienta de desarrollo esta fuertemente influenciada por su caracter libre, la gran disponibilidad de herramientas de
|
||||
desarrollo, aplicaciones, librerías y la posibilidad de modificar o adaptar código ya existente.
|
||||
|
||||
El corazón de todo sistema embebido es su procesador, en la actualidad existen diversos fabricantes que ponen a disposición de los desarrolladores
|
||||
\textit{System On Chip} (SOC) que incluyen una gran variedad de periféricos que incluyen dispositivos de comunicació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ía de los perifé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ón y contrario a lo que se podría esperar, el costo de este SOC es muy bajo (en comparación con el costo de cada perifé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 últimos
|
||||
los más populares en dispositivos de consumo como PDAs, Routers, teléfonos celulares, consolas de juego portátiles.\ref{cpu_trends}
|
||||
|
||||
\section{Definición}
|
||||
Un Sistema Embebido es un sistema de propósito específico en el cual, el computador es encapsulado completamente por el dispositivo que el controla.
|
||||
A diferencia de los computadores de propósito general, un Sistema Embebido realiza tareas pre-definidas, lo cual permite su optimización, reduciendo
|
||||
el tamaño y costo del producto \cite{Wik}
|
||||
|
||||
\subsection{Características}
|
||||
|
||||
\begin{itemize}
|
||||
\item Los sistemas embebidos son diseñados para una aplicación
|
||||
espec\'{\i}fica, es decir, estos sistemas realizan un grupo de funciones
|
||||
previamente definidasm y una vez el sistema es diseñ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ón con el entorno los ES deben cumplir
|
||||
esctrí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éricos y un componente software (procesador o DSP) capáz de ejecutar software,
|
||||
la parte del procesador está dividida en la CPU (En algunos casos posee una caché) 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ñ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ñías que fabrican procesadores de 32 bits
|
||||
integrados a una gran variedad de periféricos, lo cual simplifica el diseñ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ón es muy popular en los dispositivos de consumo
|
||||
masivo (Reproductores de MP3, consolas de juego, etc), debido a los grandes niveles de producción (del orden de millones de unidades) resulta más económico
|
||||
contar con un dispositivo que integre el mayor número de funcionalidades, esto disminuye el costo de componentes y reduce el á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éricos requerida para una
|
||||
determinada aplicación, o con una funcionalidad específica, es necesario recurrir a la utilización de dispositivos comerciales que implementen dicha
|
||||
operación, en algunas ocaciones el periférico puede relizar funciones poco comúnes y no se proporciona comercialmente, la solución es entonces, implementar estas funcionalidades en una FPGA; también se recomienda la utilización de FPGAs en sistemas que requieren la utilización de la misma funcionalidad un gran número de veces (Puertos seriales, Pines de Entrada/Salida). Esta decisión esta atada al nivel de producció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ón más flexible, pero la de menor desempeño, ya que al utilizar los recursos lógicos de la FPGA para la implementación del procesador (softcore) la longitud de los caminos de interconexión entre los bloques lógicos aumentan el retardo de las señ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ía de Diseño}
|
||||
|
||||
El proceso de diseñ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ñ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ñ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ñ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ñ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ñ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ñ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ó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ón;
|
||||
esta elección se debe a que la mayoría de los productos comerciales utilizan el toolchain de GNU\footnote{http://www.gnu.org} internamente y proporcionan un entorno gráfico para su fácil manejo. Otro factor considerado a la hora de realizar nuestra elección es el económico, ya que la mayorí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ñadores de sistemas embebidos y se encuentra un gran soporte en múltiples foros de discusió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ón de herramientas de desarrollo}\label{tools}
|
||||
\end{figure}
|
||||
|
||||
\subsubsection{GNU binutils\cite{A1}}
|
||||
Son una colecció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ón y un ejecutable, usa la información de depuración en el ejecutabe para determinar que nombre de atchivo y número de lpinea está asociado con la dirección dada.
|
||||
\item \textbf{ar} Esta utilidad crea, modifica y extrae desde ficheros. Un fichero es una colecció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 último paso en la construcció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í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ón sobre archivos tipo objeto.
|
||||
\item \textbf{ranlib} Genera un índice de contenidos de un fichero, y lo almacena en él.
|
||||
\item \textbf{readelf} Interpreta encabezados de un archivo ELF.
|
||||
\item \textbf{size} Lista el tamaño de las secciones y el tamañ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ó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ón, sin embargo, en el presente estudio solo lo utilizaremos como herramienta de compilación para C y C++. Una caracterí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ó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ás, la disponibilidad de librerías de múltiples propó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ón normal del mismo. Además, permite establecer sesiones remotas utilizando el puerto serie o TCP/IP. Aunque GDB no posee una interfaz gráfica, se han desarrollado varios front-ends como DDD o GDB/Insight.
|
||||
|
||||
\subsubsection{Librerías C}
|
||||
Adicionalmente es necesario contar con una librería que proporcione las librerí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ía C oficial del proyecto GNU. Uno de los inconvenientes al trabajar con esta librería en sistemas embebidos es que genera ejecutables de mayor tamaño que los generados a partir de otras librerías, lo cual no la hace muy atractiva para este tipo de aplicaciones.
|
||||
\item \textbf{uClibc\footnote{http://uclibc.org/}} Es una librería diseñada especialmente para sistemas embebidos, es mucho más pequeña que \textbf{glibc}.
|
||||
\item \textbf{newlib\footnote{http://sources.redhat.com/newlib/}} Al igual que \textbf{uClibc}, está diseñ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ón de \textit{libc} optimizada en tamaño, puede ser utilizada para crear ejecutables está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ño software}
|
||||
|
||||
En la figura \ref{toolchain_flow} se ilustra la secuencia de pasos que se realizan desde la creación de un archivo de texto que posee el código fuente de una aplicación hasta su implementación en la tarjeta de desarrollo.
|
||||
|
||||
|
||||
\begin{figure}[h]
|
||||
\begin{center} \includegraphics[scale=.6]{./images/SW_design_flow} \end{center}
|
||||
\caption{Flujo de diseño SW utilizando la cadena de herramientas GNU}\label{toolchain_flow}
|
||||
\end{figure}
|
||||
|
||||
A continuación se realiza una breve descripción de los pasos necesarios para generar un ejecutable para un sistema embebido:
|
||||
|
||||
\begin{enumerate}
|
||||
\item \textbf{Escritura del código fuente:} Creación del código fuente en cualquier editor de archivos de texto.
|
||||
\item \textbf{Compilació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ías la definición de una determinada funció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ías, si una determinada función no es edfinida por ninguna de las librerías pasadas como parámetro al linker, este generará un error y no se generará el ejecutable.
|
||||
\item Se define la posiciónes físicas de las secciones del ejecutable tipo ELF, esto se realiza a través de un link de enlazado el cual define de forma explícita su localización.
|
||||
\end{enumerate}
|
||||
\item \textbf{Extracción del archivo de programación} En algunas aplicaciones es necesario extraer únicamente las secciones que residen en los medios de almacenamiento no volátil y eliminar las demás secciones del ejecutable. Esto se realiza con la herramiento \textit{objcopy}, la cual, permite generar archivos en la mayorí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ón a la memoria de la plataforma de desarrollo:
|
||||
\begin{enumerate}
|
||||
\item Utilizando un \textit{loader}: El \textit{loader} es una aplicación que reside en un medio de almacenamiento no volá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ón de memoria.
|
||||
\end{enumerate}
|
||||
|
||||
\item \textbf{Depuración} Una vez se descarga la aplicació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ó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ó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áctico durante la etapa de desarrollo. Para realizar este proceso de forma automática, se creó 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ón, depuración, o programación, indicados en el archivo \textit{Makefile} o \textit{makefile}. Un ejemplo de este tipo de archivo se muestra a continuació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án utilizadas a lo largo del archivo; en las líneas 7 - 10 se definen las herramientas de compilación a utilizar, especí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á:\\ \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á 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í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ámetros:
|
||||
\begin{itemize}
|
||||
\item \textbf{-e 0}: Punto de entrada , utilice 0 como símbolo para el inicio de ejecució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í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ón necesaria para cargar en una memoria no volátil. Esto se explicará con mayor detalle más adelante.
|
||||
|
||||
\subsubsection{El formato \textbf{ELF}}
|
||||
|
||||
El formato ELF (\textit{Executable and Linkable Format}) Es un stándard para objetos, librerías y ejecutables y es el formato que genera las herramientas GNU. Como puede verse en la figura \ref{elf1} está compuesto por varias secciones (\textit{link view}) o segmentos (\textit{execution view}). Si un programador está interesado en obtener información de secciones sobre tablas de símbolos, código ejecutable específico o información de enlazado dinámico debe utilizar \textit{link view}. Pero si busca información sobre segmentos, como por ejemplo, la localización de los segmentos \textit{text} o \textit{data} debe utilizar \textit{execution view}. El encabezado describe el layout del archivo, proporcionando informació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ón de enlazado dinámico, datos de depuració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ón de la versión.
|
||||
\item \textbf{.data y .data1} Datos inicializados. (RAM)
|
||||
\item \textbf{.debug} Información para depuración simbólica.
|
||||
\item \textbf{.dynamic} Información sobre enlace dinámico
|
||||
\item \textbf{.dynstr} Strings necesarios para el enlacedinámico
|
||||
\item \textbf{.dynsym} Tabla de símbolos utilizada para enlace dinámico.
|
||||
\item \textbf{.fini} Código de terminación de proceso.
|
||||
\item \textbf{.init} Código de inicialización de proceso.
|
||||
\item \textbf{.line} Información de número de línea para depuración simbó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ó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á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ón \textit{.text}, como se dijo anteriormente contiene las instrucciones ejecutables, por esta razón se marca como ejecutable \textit{``X''} en la columna \textit{Flg}. Es posible ver las instrucciones que se ejecutan en esta secció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ó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ón \textit{.data} contiene \'unicamente el valor de inicializaci\'on de la variable \textit{global\_1} (1) y no muestra informació\'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ón \textit{.text} observamos que esta variable es asignada en tiempo de ejecució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ón de esta variable.
|
||||
|
||||
|
||||
La secció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ón \textit{.rodata} mantiene los datos que no cambian durante la ejecución del programa, es decir, de solo lectura, si examinamos esta sección obtenemos:
|
||||
|
||||
\textit{hexdump -C hello.o | grep -i 000000d0} (la sección \textit{.rodata} comienza en la posició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ó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ías necesarias para crear el ejecutable, este \textit{linker} permite definir donde será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ón. A continuació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ón de las memorias de la plataforma, en este ejemplo tenemos una memoria RAM de 64kB que comienza en la posición de memoria 0x00200000 y una memoria flash de 256k que comienza en la posición 0x0. A continuacion se definen las secciones y el lugar donde será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átil la flash. Cuando el sistema sea energizado el procesador ejecutará el código almacenado en su memoria no volátil. Las secciones \textit{.data} (variables inicializadas) y \textit{.bss} (variables no inicializadas) se almacenarán en la memoria volátil RAM, ya que el acceso a las memorias no volátiles son más lentas y tienen ciclos de lectura/escritura finitos.
|
||||
|
||||
En algunos SoCs no se dispone de una memoria no volátil, por lo que es necesario que la aplicación sea cargada por completo en la RAM. Algunos desarrolladores prefieren almacenar y ejecutar sus aplicaciones en las memorias volátiles durante la etapa de desarrollo, debido a que la programación de las memorias no volátiles toman mucho más tiempo. Obviamente una vez finalizada la etapa de desarrollo las aplicaciones deben ser almacenadas en memorias no volátiles.
|
||||
|
||||
\section{Herramientas hardware}
|
||||
En esta subsección se realizará una breve descripción de los dispositivos semiconductores más utilizados para la implementación de dispositivos digitales.
|
||||
|
||||
\subsubsection{SoC}
|
||||
La Figura \ref{at91rm} muestra la arquitectura de un SoC actual, específicamente del AT91RM920 de Atmel. En este diagrama podemos observar el núcleo central un procesador ARM920T de 180MHz y los periféricos asociados a él. En la actualidad podemos encontrar una gran variedad de SoC diseñados para diferentes aplicaciones: Multimedia, Comunicaciones, Asistentes Digitales; los perifé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é uno de los primeros que diseño ATMEL y está enfocado a tareas en las que se requiere una conexión de red. Dentro de los perifé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á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éricos que son indispensables en todo Sistema Embebido, los cuales facilitan la programación de aplicaciones y la depuración de las mismas. A continuación se realizará una descripción de los diferentes periféricos que se encuentran disponibles en este SoC, indicando los que fueron utilizados en la plataforma de desarrollo.
|
||||
|
||||
\subsubsection{Memorias Volátiles}
|
||||
|
||||
Como se estudió anteriormente existen secciones del ejecutable que deben ser almacenadas en memorias volátiles o en memorias no volátiles. Debido a esto la mayoría de los SoC incluyen periféricos dedicados a controlar diferentes tipos de memoria, las memorias volá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á 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ón de lectura es el siguiente: Una posición de memoria se determina colocando la dirección de la fila y la de la columna en las líneas de dirección de fila y columna respectivamente, un tiempo después el dato almacenado aparecerá en el bus de datos. El procesador coloca la dirección de la fila en el bus de direcciones y después activa la señal \textit{RAS} (Row Access Strobe). Después de un retardo de tiempo predeterminado para permitir que el circuito de la SDRAM capture la dirección de la fila, el procesador coloca la dirección de la columna en el bus de direcciones y activa la señ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ón por la cual es necesario recargar estos condensadores perió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ón, solo se recargan los condensadores para mantener la información. El periférico que controla la SDRAM está encargado de garantizar los ciclos de refresco de acuerdo con los requerimientos de la SDRAM \cite{CH06}.
|
||||
|
||||
\subsubsection{Memorias No Volátiles}
|
||||
La memorias no volátiles almacenan por largos períodos de tiempo información necesaria para la operació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ón con los requeridos por las memorias RAM.
|
||||
|
||||
Las memorias NOR poseen buses de datos y direcció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é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ón. Adicionalmente las memorias NAND consumen menos potencia que las memorias NAND, por esta razó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ón. A diferencia de las flash tipo NOR, los dispositivos NAND se acceden de forma serial utilizando interfaces complejas; su operación se asemeja a un disco duro tradicional. Se accede a la información utilizando bloques (más pequeñ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ñarse de forma espontánea durante la operació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ón del sistema de toda la RAM para actualizar esta lista de sectores defectuosos. El algoritmo de ECC (Error-Correcting Code) debe ser capáz de corregir errores tan pequeños como un bit de cada 2048 bits, hasta 22 bits de cada 2048. Este algorítmo es capaz de detectar bloques defectuosos en la fase de programacíón comparando la información almacenada con la que debe ser almacenada (verificación), si encuentra un error marca el bloque como defectuoso y utiliza un bloque sin defactos para almacenar la información.
|
||||
|
||||
La tabla \ref{flash_comp} resume las principales caracterí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ón & Almacenamiento & Almacenamiento & Solo lectura \\ \hline
|
||||
\end{tabular}
|
||||
\caption{Cuadro de comparació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ón con el procesador.
|
||||
|
21
course/.docs/cambio_categoria/embedded_book.aux
Normal file
21
course/.docs/cambio_categoria/embedded_book.aux
Normal file
@ -0,0 +1,21 @@
|
||||
\relax
|
||||
\catcode`"\active
|
||||
\catcode`<\active
|
||||
\catcode`>\active
|
||||
\@nameuse{es@quoting}
|
||||
\bibstyle{unsrt}
|
||||
\select@language{spanish}
|
||||
\@writefile{toc}{\select@language{spanish}}
|
||||
\@writefile{lof}{\select@language{spanish}}
|
||||
\@writefile{lot}{\select@language{spanish}}
|
||||
\citation{SR08}
|
||||
\citation{LSC08}
|
||||
\bibdata{biblio_EL}
|
||||
\@writefile{toc}{\contentsline {chapter}{\numberline {1}Sistema en un Chip (SoC)}{3}}
|
||||
\@writefile{lof}{\addvspace {10\p@ }}
|
||||
\@writefile{lot}{\addvspace {10\p@ }}
|
||||
\@writefile{toc}{\contentsline {section}{\numberline {1.1}Arquitectura}{3}}
|
||||
\@writefile{lof}{\contentsline {figure}{\numberline {1.1}{\ignorespaces Arquitectura m\IeC {\'\i }nima de un SoC}}{4}}
|
||||
\newlabel{min_soc_arch}{{1.1}{4}}
|
||||
\bibcite{SR08}{1}
|
||||
\bibcite{LSC08}{2}
|
15
course/.docs/cambio_categoria/embedded_book.bbl
Normal file
15
course/.docs/cambio_categoria/embedded_book.bbl
Normal file
@ -0,0 +1,15 @@
|
||||
\begin{thebibliography}{1}
|
||||
|
||||
\bibitem{SR08}
|
||||
{S. Rhoads}.
|
||||
\newblock Plasma - most {MIPS} {I}({TM}) opcodes.
|
||||
\newblock URL: http://opencores.org/project,plasma, 2008.
|
||||
|
||||
\bibitem{LSC08}
|
||||
{Lattice Semiconductor Corporation}.
|
||||
\newblock Lattice{M}ico32 {O}pen, {F}ree 32-{B}it {S}oft {P}rocessor.
|
||||
\newblock URL:
|
||||
http://www.latticesemi.com/products/intellectualproperty/ipcores/mico32/inde%
|
||||
x.cfm, 2008.
|
||||
|
||||
\end{thebibliography}
|
45
course/.docs/cambio_categoria/embedded_book.blg
Normal file
45
course/.docs/cambio_categoria/embedded_book.blg
Normal file
@ -0,0 +1,45 @@
|
||||
This is BibTeX, Version 0.99c (TeX Live 2009/Debian)
|
||||
The top-level auxiliary file: embedded_book.aux
|
||||
The style file: unsrt.bst
|
||||
Database file #1: biblio_EL.bib
|
||||
You've used 2 entries,
|
||||
1791 wiz_defined-function locations,
|
||||
456 strings with 3823 characters,
|
||||
and the built_in function-call counts, 278 in all, are:
|
||||
= -- 22
|
||||
> -- 8
|
||||
< -- 0
|
||||
+ -- 4
|
||||
- -- 2
|
||||
* -- 4
|
||||
:= -- 49
|
||||
add.period$ -- 6
|
||||
call.type$ -- 2
|
||||
change.case$ -- 2
|
||||
chr.to.int$ -- 0
|
||||
cite$ -- 2
|
||||
duplicate$ -- 10
|
||||
empty$ -- 37
|
||||
format.name$ -- 2
|
||||
if$ -- 63
|
||||
int.to.chr$ -- 0
|
||||
int.to.str$ -- 2
|
||||
missing$ -- 0
|
||||
newline$ -- 13
|
||||
num.names$ -- 2
|
||||
pop$ -- 12
|
||||
preamble$ -- 1
|
||||
purify$ -- 0
|
||||
quote$ -- 0
|
||||
skip$ -- 6
|
||||
stack$ -- 0
|
||||
substring$ -- 0
|
||||
swap$ -- 2
|
||||
text.length$ -- 0
|
||||
text.prefix$ -- 0
|
||||
top$ -- 0
|
||||
type$ -- 0
|
||||
warning$ -- 0
|
||||
while$ -- 2
|
||||
width$ -- 3
|
||||
write$ -- 22
|
BIN
course/.docs/cambio_categoria/embedded_book.dvi
Normal file
BIN
course/.docs/cambio_categoria/embedded_book.dvi
Normal file
Binary file not shown.
380
course/.docs/cambio_categoria/embedded_book.log
Normal file
380
course/.docs/cambio_categoria/embedded_book.log
Normal file
@ -0,0 +1,380 @@
|
||||
This is pdfTeX, Version 3.1415926-1.40.10 (TeX Live 2009/Debian) (format=pdflatex 2010.5.7) 11 SEP 2010 21:52
|
||||
entering extended mode
|
||||
restricted \write18 enabled.
|
||||
%&-line parsing enabled.
|
||||
**embedded_book.tex
|
||||
(./embedded_book.tex
|
||||
LaTeX2e <2009/09/24>
|
||||
Babel <v3.8l> and hyphenation patterns for english, usenglishmax, dumylang, noh
|
||||
yphenation, loaded.
|
||||
(/usr/share/texmf-texlive/tex/latex/base/report.cls
|
||||
Document Class: report 2007/10/19 v1.4h Standard LaTeX document class
|
||||
(/usr/share/texmf-texlive/tex/latex/base/size10.clo
|
||||
File: size10.clo 2007/10/19 v1.4h Standard LaTeX file (size option)
|
||||
)
|
||||
\c@part=\count79
|
||||
\c@chapter=\count80
|
||||
\c@section=\count81
|
||||
\c@subsection=\count82
|
||||
\c@subsubsection=\count83
|
||||
\c@paragraph=\count84
|
||||
\c@subparagraph=\count85
|
||||
\c@figure=\count86
|
||||
\c@table=\count87
|
||||
\abovecaptionskip=\skip41
|
||||
\belowcaptionskip=\skip42
|
||||
\bibindent=\dimen102
|
||||
)
|
||||
(/usr/share/texmf-texlive/tex/latex/base/fontenc.sty
|
||||
Package: fontenc 2005/09/27 v1.99g Standard LaTeX package
|
||||
)
|
||||
(/usr/share/texmf-texlive/tex/latex/base/inputenc.sty
|
||||
Package: inputenc 2008/03/30 v1.1d Input encoding file
|
||||
\inpenc@prehook=\toks14
|
||||
\inpenc@posthook=\toks15
|
||||
|
||||
(/usr/share/texmf-texlive/tex/latex/base/latin1.def
|
||||
File: latin1.def 2008/03/30 v1.1d Input encoding file
|
||||
))
|
||||
(/usr/share/texmf-texlive/tex/generic/babel/babel.sty
|
||||
Package: babel 2008/07/06 v3.8l The Babel package
|
||||
|
||||
(/usr/share/texmf-texlive/tex/generic/babel/spanish.ldf
|
||||
Language: spanish.ldf 2009/01/02 v5.0h Spanish support from the babel system
|
||||
|
||||
(/usr/share/texmf-texlive/tex/generic/babel/babel.def
|
||||
File: babel.def 2008/07/06 v3.8l Babel common definitions
|
||||
\babel@savecnt=\count88
|
||||
\U@D=\dimen103
|
||||
)
|
||||
|
||||
Package babel Warning: No hyphenation patterns were loaded for
|
||||
(babel) the language `Spanish'
|
||||
(babel) I will use the patterns loaded for \language=0 instead.
|
||||
|
||||
\l@spanish = a dialect from \language0
|
||||
\es@datefmt=\count89
|
||||
\es@quottoks=\toks16
|
||||
\es@quotdepth=\count90
|
||||
Package babel Info: Making " an active character on input line 492.
|
||||
Package babel Info: Making . an active character on input line 585.
|
||||
Package babel Info: Making < an active character on input line 630.
|
||||
Package babel Info: Making > an active character on input line 630.
|
||||
)) (/usr/share/texmf-texlive/tex/latex/graphics/graphicx.sty
|
||||
Package: graphicx 1999/02/16 v1.0f Enhanced LaTeX Graphics (DPC,SPQR)
|
||||
|
||||
(/usr/share/texmf-texlive/tex/latex/graphics/keyval.sty
|
||||
Package: keyval 1999/03/16 v1.13 key=value parser (DPC)
|
||||
\KV@toks@=\toks17
|
||||
)
|
||||
(/usr/share/texmf-texlive/tex/latex/graphics/graphics.sty
|
||||
Package: graphics 2009/02/05 v1.0o Standard LaTeX Graphics (DPC,SPQR)
|
||||
|
||||
(/usr/share/texmf-texlive/tex/latex/graphics/trig.sty
|
||||
Package: trig 1999/03/16 v1.09 sin cos tan (DPC)
|
||||
)
|
||||
(/etc/texmf/tex/latex/config/graphics.cfg
|
||||
File: graphics.cfg 2009/08/28 v1.8 graphics configuration of TeX Live
|
||||
)
|
||||
Package graphics Info: Driver file: pdftex.def on input line 91.
|
||||
|
||||
(/usr/share/texmf-texlive/tex/latex/pdftex-def/pdftex.def
|
||||
File: pdftex.def 2009/08/25 v0.04m Graphics/color for pdfTeX
|
||||
\Gread@gobject=\count91
|
||||
))
|
||||
\Gin@req@height=\dimen104
|
||||
\Gin@req@width=\dimen105
|
||||
)
|
||||
(/usr/share/texmf-texlive/tex/latex/psnfss/times.sty
|
||||
Package: times 2005/04/12 PSNFSS-v9.2a (SPQR)
|
||||
)
|
||||
(/usr/share/texmf-texlive/tex/latex/colortbl/colortbl.sty
|
||||
Package: colortbl 2001/02/13 v0.1j Color table columns (DPC)
|
||||
|
||||
(/usr/share/texmf-texlive/tex/latex/tools/array.sty
|
||||
Package: array 2008/09/09 v2.4c Tabular extension package (FMi)
|
||||
\col@sep=\dimen106
|
||||
\extrarowheight=\dimen107
|
||||
\NC@list=\toks18
|
||||
\extratabsurround=\skip43
|
||||
\backup@length=\skip44
|
||||
)
|
||||
(/usr/share/texmf-texlive/tex/latex/graphics/color.sty
|
||||
Package: color 2005/11/14 v1.0j Standard LaTeX Color (DPC)
|
||||
|
||||
(/etc/texmf/tex/latex/config/color.cfg
|
||||
File: color.cfg 2007/01/18 v1.5 color configuration of teTeX/TeXLive
|
||||
)
|
||||
Package color Info: Driver file: pdftex.def on input line 130.
|
||||
)
|
||||
\everycr=\toks19
|
||||
\minrowclearance=\skip45
|
||||
)
|
||||
(/usr/share/texmf-texlive/tex/latex/tools/multicol.sty
|
||||
Package: multicol 2008/12/05 v1.6h multicolumn formatting (FMi)
|
||||
\c@tracingmulticols=\count92
|
||||
\mult@box=\box26
|
||||
\multicol@leftmargin=\dimen108
|
||||
\c@unbalance=\count93
|
||||
\c@collectmore=\count94
|
||||
\doublecol@number=\count95
|
||||
\multicoltolerance=\count96
|
||||
\multicolpretolerance=\count97
|
||||
\full@width=\dimen109
|
||||
\page@free=\dimen110
|
||||
\premulticols=\dimen111
|
||||
\postmulticols=\dimen112
|
||||
\multicolsep=\skip46
|
||||
\multicolbaselineskip=\skip47
|
||||
\partial@page=\box27
|
||||
\last@line=\box28
|
||||
\mult@rightbox=\box29
|
||||
\mult@grightbox=\box30
|
||||
\mult@gfirstbox=\box31
|
||||
\mult@firstbox=\box32
|
||||
\@tempa=\box33
|
||||
\@tempa=\box34
|
||||
\@tempa=\box35
|
||||
\@tempa=\box36
|
||||
\@tempa=\box37
|
||||
\@tempa=\box38
|
||||
\@tempa=\box39
|
||||
\@tempa=\box40
|
||||
\@tempa=\box41
|
||||
\@tempa=\box42
|
||||
\@tempa=\box43
|
||||
\@tempa=\box44
|
||||
\@tempa=\box45
|
||||
\@tempa=\box46
|
||||
\@tempa=\box47
|
||||
\@tempa=\box48
|
||||
\@tempa=\box49
|
||||
\c@columnbadness=\count98
|
||||
\c@finalcolumnbadness=\count99
|
||||
\last@try=\dimen113
|
||||
\multicolovershoot=\dimen114
|
||||
\multicolundershoot=\dimen115
|
||||
\mult@nat@firstbox=\box50
|
||||
\colbreak@box=\box51
|
||||
)
|
||||
(/usr/share/texmf-texlive/tex/latex/multirow/multirow.sty
|
||||
\bigstrutjot=\dimen116
|
||||
)
|
||||
(/usr/share/texmf-texlive/tex/latex/pdfpages/pdfpages.sty
|
||||
Package: pdfpages 2009/02/07 v0.4g Insert pages of external PDF documents (AM)
|
||||
|
||||
(/usr/share/texmf-texlive/tex/latex/base/ifthen.sty
|
||||
Package: ifthen 2001/05/26 v1.1c Standard LaTeX ifthen package (DPC)
|
||||
)
|
||||
(/usr/share/texmf-texlive/tex/latex/tools/calc.sty
|
||||
Package: calc 2007/08/22 v4.3 Infix arithmetic (KKT,FJ)
|
||||
\calc@Acount=\count100
|
||||
\calc@Bcount=\count101
|
||||
\calc@Adimen=\dimen117
|
||||
\calc@Bdimen=\dimen118
|
||||
\calc@Askip=\skip48
|
||||
\calc@Bskip=\skip49
|
||||
LaTeX Info: Redefining \setlength on input line 76.
|
||||
LaTeX Info: Redefining \addtolength on input line 77.
|
||||
\calc@Ccount=\count102
|
||||
\calc@Cskip=\skip50
|
||||
)
|
||||
(/usr/share/texmf-texlive/tex/latex/eso-pic/eso-pic.sty
|
||||
Package: eso-pic 2006/07/14 v1.1d eso-pic (RN)
|
||||
|
||||
(/usr/share/texmf-texlive/tex/latex/ms/everyshi.sty
|
||||
Package: everyshi 2001/05/15 v3.00 EveryShipout Package (MS)
|
||||
))
|
||||
(/usr/share/texmf-texlive/tex/latex/pdfpages/pppdftex.def
|
||||
File: pppdftex.def 2009/02/07 v0.4g Pdfpages driver for pdfTeX (AM)
|
||||
)
|
||||
\AM@pagebox=\box52
|
||||
\AM@toc@title=\toks20
|
||||
\c@AM@survey=\count103
|
||||
\AM@templatesizebox=\box53
|
||||
)
|
||||
(/usr/share/texmf-texlive/tex/latex/graphics/lscape.sty
|
||||
Package: lscape 2000/10/22 v3.01 Landscape Pages (DPC)
|
||||
)
|
||||
(/usr/share/texmf-texlive/tex/latex/listings/listings.sty
|
||||
\lst@mode=\count104
|
||||
\lst@gtempboxa=\box54
|
||||
\lst@token=\toks21
|
||||
\lst@length=\count105
|
||||
\lst@currlwidth=\dimen119
|
||||
\lst@column=\count106
|
||||
\lst@pos=\count107
|
||||
\lst@lostspace=\dimen120
|
||||
\lst@width=\dimen121
|
||||
\lst@newlines=\count108
|
||||
\lst@lineno=\count109
|
||||
\lst@maxwidth=\dimen122
|
||||
|
||||
(/usr/share/texmf-texlive/tex/latex/listings/lstmisc.sty
|
||||
File: lstmisc.sty 2007/02/22 1.4 (Carsten Heinz)
|
||||
\c@lstnumber=\count110
|
||||
\lst@skipnumbers=\count111
|
||||
\lst@framebox=\box55
|
||||
)
|
||||
(/usr/share/texmf-texlive/tex/latex/listings/listings.cfg
|
||||
File: listings.cfg 2007/02/22 1.4 listings configuration
|
||||
))
|
||||
Package: listings 2007/02/22 1.4 (Carsten Heinz)
|
||||
|
||||
(/usr/share/texmf-texlive/tex/latex/listings/lstlang1.sty
|
||||
File: lstlang1.sty 2004/09/05 1.3 listings language file
|
||||
)
|
||||
(/usr/share/texmf-texlive/tex/latex/listings/lstmisc.sty
|
||||
File: lstmisc.sty 2007/02/22 1.4 (Carsten Heinz)
|
||||
)
|
||||
(/usr/share/texmf-texlive/tex/latex/tools/longtable.sty
|
||||
Package: longtable 2004/02/01 v4.11 Multi-page Table package (DPC)
|
||||
\LTleft=\skip51
|
||||
\LTright=\skip52
|
||||
\LTpre=\skip53
|
||||
\LTpost=\skip54
|
||||
\LTchunksize=\count112
|
||||
\LTcapwidth=\dimen123
|
||||
\LT@head=\box56
|
||||
\LT@firsthead=\box57
|
||||
\LT@foot=\box58
|
||||
\LT@lastfoot=\box59
|
||||
\LT@cols=\count113
|
||||
\LT@rows=\count114
|
||||
\c@LT@tables=\count115
|
||||
\c@LT@chunks=\count116
|
||||
\LT@p@ftn=\toks22
|
||||
) (./embedded_book.aux)
|
||||
\openout1 = `embedded_book.aux'.
|
||||
|
||||
LaTeX Font Info: Checking defaults for OML/cmm/m/it on input line 44.
|
||||
LaTeX Font Info: ... okay on input line 44.
|
||||
LaTeX Font Info: Checking defaults for T1/cmr/m/n on input line 44.
|
||||
LaTeX Font Info: ... okay on input line 44.
|
||||
LaTeX Font Info: Checking defaults for OT1/cmr/m/n on input line 44.
|
||||
LaTeX Font Info: ... okay on input line 44.
|
||||
LaTeX Font Info: Checking defaults for OMS/cmsy/m/n on input line 44.
|
||||
LaTeX Font Info: ... okay on input line 44.
|
||||
LaTeX Font Info: Checking defaults for OMX/cmex/m/n on input line 44.
|
||||
LaTeX Font Info: ... okay on input line 44.
|
||||
LaTeX Font Info: Checking defaults for U/cmr/m/n on input line 44.
|
||||
LaTeX Font Info: ... okay on input line 44.
|
||||
LaTeX Font Info: Try loading font information for OT1+ptm on input line 44.
|
||||
|
||||
(/usr/share/texmf-texlive/tex/latex/psnfss/ot1ptm.fd
|
||||
File: ot1ptm.fd 2001/06/04 font definitions for OT1/ptm.
|
||||
)
|
||||
(/usr/share/texmf/tex/context/base/supp-pdf.mkii
|
||||
[Loading MPS to PDF converter (version 2006.09.02).]
|
||||
\scratchcounter=\count117
|
||||
\scratchdimen=\dimen124
|
||||
\scratchbox=\box60
|
||||
\nofMPsegments=\count118
|
||||
\nofMParguments=\count119
|
||||
\everyMPshowfont=\toks23
|
||||
\MPscratchCnt=\count120
|
||||
\MPscratchDim=\dimen125
|
||||
\MPnumerator=\count121
|
||||
\everyMPtoPDFconversion=\toks24
|
||||
) ABD: EveryShipout initializing macros
|
||||
\c@lstlisting=\count122
|
||||
(./title.tex
|
||||
LaTeX Font Info: External font `cmex10' loaded for size
|
||||
(Font) <12> on input line 11.
|
||||
LaTeX Font Info: External font `cmex10' loaded for size
|
||||
(Font) <8> on input line 11.
|
||||
LaTeX Font Info: External font `cmex10' loaded for size
|
||||
(Font) <6> on input line 11.
|
||||
[1
|
||||
|
||||
{/var/lib/texmf/fonts/map/pdftex/updmap/pdftex.map}]
|
||||
Underfull \hbox (badness 10000) in paragraph at lines 16--20
|
||||
|
||||
[]
|
||||
|
||||
LaTeX Font Info: Try loading font information for OMS+ptm on input line 23.
|
||||
(/usr/share/texmf-texlive/tex/latex/psnfss/omsptm.fd
|
||||
File: omsptm.fd
|
||||
)
|
||||
LaTeX Font Info: Font shape `OMS/ptm/m/n' in size <10> not available
|
||||
(Font) Font shape `OMS/cmsy/m/n' tried instead on input line 23.
|
||||
LaTeX Font Info: Try loading font information for OT1+pcr on input line 24.
|
||||
|
||||
(/usr/share/texmf-texlive/tex/latex/psnfss/ot1pcr.fd
|
||||
File: ot1pcr.fd 2001/06/04 font definitions for OT1/pcr.
|
||||
)
|
||||
Underfull \hbox (badness 10000) in paragraph at lines 23--25
|
||||
|
||||
[]
|
||||
|
||||
|
||||
Underfull \hbox (badness 10000) in paragraph at lines 26--30
|
||||
|
||||
[]
|
||||
|
||||
|
||||
Underfull \hbox (badness 10000) in paragraph at lines 31--34
|
||||
|
||||
[]
|
||||
|
||||
|
||||
Underfull \hbox (badness 10000) in paragraph at lines 35--36
|
||||
|
||||
[]
|
||||
|
||||
[1])
|
||||
LaTeX Font Info: Font shape `OT1/ptm/bx/n' in size <24.88> not available
|
||||
(Font) Font shape `OT1/ptm/b/n' tried instead on input line 47.
|
||||
(./embedded_book.toc
|
||||
LaTeX Font Info: Font shape `OT1/ptm/bx/n' in size <10> not available
|
||||
(Font) Font shape `OT1/ptm/b/n' tried instead on input line 2.
|
||||
LaTeX Font Info: External font `cmex10' loaded for size
|
||||
(Font) <7> on input line 3.
|
||||
LaTeX Font Info: External font `cmex10' loaded for size
|
||||
(Font) <5> on input line 3.
|
||||
)
|
||||
\tf@toc=\write3
|
||||
\openout3 = `embedded_book.toc'.
|
||||
|
||||
(./chapter2.tex [2
|
||||
|
||||
]
|
||||
Cap\'{\i }tulo 1.
|
||||
LaTeX Font Info: Font shape `OT1/ptm/bx/n' in size <20.74> not available
|
||||
(Font) Font shape `OT1/ptm/b/n' tried instead on input line 1.
|
||||
|
||||
Overfull \hbox (2.1569pt too wide) in paragraph at lines 3--4
|
||||
[]\OT1/ptm/m/n/10 En es-ta sec-ci[]on es-tu-di-are-mos la ar-qui-tec-tura b[]as
|
||||
ica de un SoC mod-er-no, com-po-nentes, fun-cionamien-
|
||||
[]
|
||||
|
||||
LaTeX Font Info: Font shape `OT1/ptm/bx/n' in size <14.4> not available
|
||||
(Font) Font shape `OT1/ptm/b/n' tried instead on input line 6.
|
||||
<./images/Computer-simple.png, id=15, 488.57532pt x 328.22626pt>
|
||||
File: ./images/Computer-simple.png Graphic file (type png)
|
||||
|
||||
<use ./images/Computer-simple.png>) (./embedded_book.bbl [3
|
||||
|
||||
] [4 <./images/Computer-simple.png (PNG copy)>]) [5
|
||||
|
||||
] (./embedded_book.aux) )
|
||||
Here is how much of TeX's memory you used:
|
||||
4384 strings out of 495061
|
||||
58680 string characters out of 1182622
|
||||
142655 words of memory out of 3000000
|
||||
7487 multiletter control sequences out of 15000+50000
|
||||
24721 words of font info for 48 fonts, out of 3000000 for 9000
|
||||
28 hyphenation exceptions out of 8191
|
||||
34i,8n,49p,1030b,263s stack positions out of 5000i,500n,10000p,200000b,50000s
|
||||
{/usr/share/texmf-texlive/fonts/enc/dvips/base/8r.enc}
|
||||
</usr/share/texmf-texlive/fonts/type1/public/amsfonts/cm/cmsy10.pfb></usr/share
|
||||
/texmf-texlive/fonts/type1/urw/courier/ucrr8a.pfb></usr/share/texmf-texlive/fon
|
||||
ts/type1/urw/times/utmb8a.pfb></usr/share/texmf-texlive/fonts/type1/urw/times/u
|
||||
tmr8a.pfb></usr/share/texmf-texlive/fonts/type1/urw/times/utmr8a.pfb></usr/shar
|
||||
e/texmf-texlive/fonts/type1/urw/times/utmri8a.pfb>
|
||||
Output written on embedded_book.pdf (6 pages, 104382 bytes).
|
||||
PDF statistics:
|
||||
47 PDF objects out of 1000 (max. 8388607)
|
||||
0 named destinations out of 1000 (max. 500000)
|
||||
6 words of extra memory for PDF output out of 10000 (max. 10000000)
|
||||
|
BIN
course/.docs/cambio_categoria/embedded_book.pdf
Normal file
BIN
course/.docs/cambio_categoria/embedded_book.pdf
Normal file
Binary file not shown.
61
course/.docs/cambio_categoria/embedded_book.tex
Normal file
61
course/.docs/cambio_categoria/embedded_book.tex
Normal 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ño y Sistemas Embebidos}{Universidad Nacional de Colombia}
|
||||
|
||||
\usepackage{longtable}
|
||||
|
||||
\parindent 1cm
|
||||
\parskip 0.2cm
|
||||
\topmargin 0.2cm
|
||||
\oddsidemargin 1cm
|
||||
\evensidemargin 0.5cm
|
||||
\textwidth 15cm
|
||||
\textheight 21cm
|
||||
|
||||
|
||||
\begin{document}
|
||||
\bibliographystyle{unsrt}
|
||||
\input title
|
||||
\tableofcontents
|
||||
|
||||
\parindent=1cm
|
||||
|
||||
% \input introduction
|
||||
|
||||
2010/8/12 Oscar Javier Fajardo Ruiz <ojfajardor@unal.edu.co>
|
||||
Nuestra idea es el ecualizador
|
||||
|
||||
% % \input chapter1
|
||||
\input chapter2
|
||||
|
||||
\bibliography{biblio_EL}
|
||||
|
||||
\end{document}
|
57
course/.docs/cambio_categoria/embedded_book.tex.backup
Normal file
57
course/.docs/cambio_categoria/embedded_book.tex.backup
Normal 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ño y Sistemas Embebidos}{Universidad Nacional de Colombia}
|
||||
|
||||
\usepackage{longtable}
|
||||
|
||||
\parindent 1cm
|
||||
\parskip 0.2cm
|
||||
\topmargin 0.2cm
|
||||
\oddsidemargin 1cm
|
||||
\evensidemargin 0.5cm
|
||||
\textwidth 15cm
|
||||
\textheight 21cm
|
||||
|
||||
|
||||
\begin{document}
|
||||
\bibliographystyle{unsrt}
|
||||
\input title
|
||||
\tableofcontents
|
||||
|
||||
\parindent=1cm
|
||||
|
||||
% \input introduction
|
||||
% \input chapter1
|
||||
\input chapter2
|
||||
|
||||
\bibliography{biblio_EL}
|
||||
|
||||
\end{document}
|
3
course/.docs/cambio_categoria/embedded_book.toc
Normal file
3
course/.docs/cambio_categoria/embedded_book.toc
Normal file
@ -0,0 +1,3 @@
|
||||
\select@language {spanish}
|
||||
\contentsline {chapter}{\numberline {1}Sistema en un Chip (SoC)}{3}
|
||||
\contentsline {section}{\numberline {1.1}Arquitectura}{3}
|
47
course/.docs/cambio_categoria/introduction.tex
Normal file
47
course/.docs/cambio_categoria/introduction.tex
Normal file
@ -0,0 +1,47 @@
|
||||
\chapter{Introducción}
|
||||
|
||||
La industria de los semiconductores ha crecido velozmente durante los últimos años, su campo de acción se ha extendido a casi todas las actividades del ser humano (Entretenimiento, salud, seguridad, transporte, educación, etc); los tiempos de los procesos de diseño son cada vez mas cortos, lo cual require herramientas Hardware, Software y metodologías de diseño que ayuden a cumplir con las exigencias impuestas al sistema.
|
||||
|
||||
Esta \textit{invasió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ísimo grado de integración ponen a disposición de los diseñadores \textit{Systems On Chip} (SoC) en los cuales se integran procesadores de 32 bits con una gran variedad de periféricos tales como: Controladores de dispositivos de red (cableada e inalámbricos), controladores de video, procesadores aritméticos, controladores de memorias (Flash, SDRAM, DDR, USB, SD), codecs de audio, controladores de touch screen, etc; lo cual permite la implementación de aplicaciones completas dentro de uno de estos SoCs.
|
||||
|
||||
Por otro lado, las empresas desarrolladoras de SW crean herramientas de programación que permiten manejar toda la capacidad de estos SoCs. colocando a disposición de los diseñadores: compiladores, simuladores, emuladores, librerí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ó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ón \cite{CLSB05}. La figura \ref{os2} muestra un cuadro comparativo de la utilización de herramientas comerciales y linux; de nuevo se observa que linux es el preferido por los diseñadores. Este resultado es interesante ya que uno de los supuestos puntos débiles del software de libre distribució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á disponible, es posible comprender perfectamente su funcionamiento, lo cual no sucede con el software comercial; además, existen muchos foros de diseñ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óricos, muy seguramente alguien más preguntó lo mismo antes que nosotros.
|
||||
|
||||
|
||||
El caracter gratutito de las herramientas de libre distribución no significa, ni mucho menos, mala calidad, todo lo contrario, existen muchas personas que escudriñ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án constantemente depurando y perfeccionando una determinada aplicació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ón empresas como PALM, han dejado de lado productos propietarios como el PALM OS para utilizar linux, SUN Microsystems, liberó el código fuente de su sistema operativo Solaris, ya que no era comparable con linux y está 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ó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ó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ómica \footnote{En la actualidad cerca del 60\% de los ingenieros trabajan en compañí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ón de los programas acedémicos: En muchas de las Universidades de Colombia se utilizan tecnologías obsoletas que impiden la aplicación de metodologías de diseño modernas además de impedir el desarrollo de aplicaciones comerciales, un ejemplo de este tipo de tecnologías es la lógica TTL (74XX) y sus equivalentes en CMOS. Aunque vale la pena aclarar que este tipo de tecnología es útil a la hora de enseñar conceptos básicos, no puede ser utilizada como única herramienta de implementación. Un ejemplo de desactualización de metodologías de diseño lo encontramos en las herramientas de programación para microcontroladores, una gran cantidad de Universidades utilizan lenguaje ensamblador, lo cual impide la re-utilización de código y crea dependencias con el HW utilizado.
|
||||
|
||||
\item Falta de interés de la Industria: Un gran porcentaje de la industria Colombiana es consumidora de tecnología, es decir, no generan sus propias soluciones, no cuentan con departamentos de Investigación y Desarrollo; esto se debe a la falta de confianza en los productos nacionales y en algunos casos a la inexistencia de producción nacional. Por otro lado, la cooperación entre la Universidad y la industria es muy reducida, debido a falta de políticas en las Universidades que regulen esta actividad y a la poca inversión por parte de las empresas.
|
||||
|
||||
\item Polí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ón, estos impuestos están por el orden del 26\% del valor del producto. Por otro lado la apertura econó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ón por parte de las políticas estatales condena a los desarrolladores de estos sistemas a la quiebra económica.
|
||||
|
||||
\end{enumerate}
|
||||
|
||||
Este proyecto resume el trabajo realizado durante los últimos cuatro años en el área de la electrónica digital y más exactamente en el estudio de las metodologías de diseño modernas con aplicaciones comerciales y es presentado para cumplir parcialmente los requisitos de cambio de categoría de profesor asistente a asociado. El presente informe está dividido de la siguiente forma:
|
||||
|
||||
|
||||
\begin{itemize}
|
||||
\item En el capítulo 1 se realiza una breve descripción de los sistemas embebidos, se enumeran sus características, aplicaciones y se hace una descripción de las herramientas HW y SW necesarias para el diseño de los mismos. En los capítulos siguientes se desarrollan casos de estudio encaminados a la comprensión de estos sistemas:
|
||||
\item En el capítulo dos se trabaja con una plataforma comercial de bajo costo: El GameBoy de Nintendo, (gracias a los elevados volúmenes de producción el costo de este dispositivo es bajo alrededor de 40 USD) esta plataforma nos permite desarrollar conceptos básicos como la compilación cruzada, la interfaz HW-SW y los sistemas operativos.
|
||||
\item En el capítulo tres se muestra la implementación de la primera plataforma de desarrollo para sistemas embebidos diseñada en la Universidad Nacional, a pesar de ser muy sencilla permite dar un gran paso en el proceso de fabricación de este tipo de dispositivos.
|
||||
\item En el capítulo cuatro se realiza la implementció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ón en el área del Hardware Reconfigurable.
|
||||
\item El capítulo cinco es una guía de adaptación del sistema operativo linux para una arquitectura ARM.
|
||||
\end{itemize}
|
||||
|
||||
Por último se muestra como algunos de los resultados de este estudio han sido introducidos a los cursos del área de los sistemas digitales en la Universidad Nacional de Colombia y como se ha realizado su difusión en otras Universidades de Colombia.
|
47
course/.docs/cambio_categoria/introduction.tex.backup
Normal file
47
course/.docs/cambio_categoria/introduction.tex.backup
Normal file
@ -0,0 +1,47 @@
|
||||
\chapter{Introducción}
|
||||
|
||||
La industria de los semiconductores ha crecido velozmente durante los últimos años, su campo de acción se ha extendido a casi todas las actividades del ser humano (Entretenimiento, salud, seguridad, transporte, educación, etc); los tiempos de los procesos de diseño son cada vez mas cortos, lo cual require herramientas Hardware, Software y metodologías de diseño que ayuden a cumplir con las exigencias impuestas al sistema.
|
||||
|
||||
Esta \textit{invasió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ísimo grado de integración ponen a disposición de los diseñadores \textit{Systems On Chip} (SoC) en los cuales se integran procesadores de 32 bits con una gran variedad de periféricos tales como: Controladores de dispositivos de red (cableada e inalámbricos), controladores de video, procesadores aritméticos, controladores de memorias (Flash, SDRAM, DDR, USB, SD), codecs de audio, controladores de touch screen, etc; lo cual permite la implementación de aplicaciones completas dentro de uno de estos SoCs.
|
||||
|
||||
Por otro lado, las empresas desarrolladoras de SW crean herramientas de programación que permiten manejar toda la capacidad de estos SoCs. colocando a disposición de los diseñadores: compiladores, simuladores, emuladores, librerí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ó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ón \cite{CLSB05}. La figura \ref{os2} muestra un cuadro comparativo de la utilización de herramientas comerciales y linux; de nuevo se observa que linux es el preferido por los diseñadores. Este resultado es interesante ya que uno de los supuestos puntos débiles del software de libre distribució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á disponible, es posible comprender perfectamente su funcionamiento, lo cual no sucede con el software comercial; además, existen muchos foros de diseñ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óricos, muy seguramente alguien más preguntó lo mismo antes que nosotros.
|
||||
|
||||
|
||||
El caracter gratutito de las herramientas de libre distribución no significa, ni mucho menos, mala calidad, todo lo contrario, existen muchas personas que escudriñ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án constantemente depurando y perfeccionando una determinada aplicació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ón empresas como PALM, han dejado de lado productos propietarios como el PALM OS para utilizar linux, SUN Microsystems, liberó el código fuente de su sistema operativo Solaris, ya que no era comparable con linux y está 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ó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ó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ómica \footnote{En la actualidad cerca del 60\% de los ingenieros trabajan en compañí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ón de los programas acedémicos: En muchas de las Universidades de Colombia se utilizan tecnologías obsoletas que impiden la aplicación de metodologías de diseño modernas además de impedir el desarrollo de aplicaciones comerciales, un ejemplo de este tipo de tecnologías es la lógica TTL (74XX) y sus equivalentes en CMOS. Aunque vale la pena aclarar que este tipo de tecnología es útil a la hora de enseñar conceptos básicos, no puede ser utilizada como única herramienta de implementación. Un ejemplo de desactualización de metodologías de diseño lo encontramos en las herramientas de programación para microcontroladores, una gran cantidad de Universidades utilizan lenguaje ensamblador, lo cual impide la re-utilización de código y crea dependencias con el HW utilizado.
|
||||
|
||||
\item Falta de interés de la Industria: Un gran porcentaje de la industria Colombiana es consumidora de tecnología, es decir, no generan sus propias soluciones, no cuentan con departamentos de Investigación y Desarrollo; esto se debe a la falta de confianza en los productos nacionales y en algunos casos a la inexistencia de producción nacional. Por otro lado, la cooperación entre la Universidad y la industria es muy reducida, debido a falta de políticas en las Universidades que regulen esta actividad y a la poca inversión por parte de las empresas.
|
||||
|
||||
\item Polí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ón, estos impuestos están por el orden del 26\% del valor del producto. Por otro lado la apertura econó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ón por parte de las políticas estatales condena a los desarrolladores de estos sistemas a la quiebra económica.
|
||||
|
||||
\end{enumerate}
|
||||
|
||||
Este proyecto resume el trabajo realizado durante los últimos cuatro años en el área de la electrónica digital y más exactamente en el estudio de las metodologías de diseño modernas con aplicaciones comerciales y es presentado para cumplir parcialmente los requisitos de cambio de categoría de profesor asistente a asociado. El presente informe está dividido de la siguiente forma:
|
||||
|
||||
|
||||
\begin{itemize}
|
||||
\item En el capítulo 1 se realiza una breve descripción de los sistemas embebidos, se enumeran sus características, aplicaciones y se hace una descripción de las herramientas HW y SW necesarias para el diseño de los mismos. En los capítulos siguientes se desarrollan casos de estudio encaminados a la comprensión de estos sistemas:
|
||||
\item En el capítulo dos se trabaja con una plataforma comercial de bajo costo: El GameBoy de Nintendo, (gracias a los elevados volúmenes de producción el costo de este dispositivo es bajo alrededor de 40 USD) esta plataforma nos permite desarrollar conceptos básicos como la compilación cruzada, la interfaz HW-SW y los sistemas operativos.
|
||||
\item En el capítulo tres se muestra la implementación de la primera plataforma de desarrollo para sistemas embebidos diseñada en la Universidad Nacional, a pesar de ser muy sencilla permite dar un gran paso en el proceso de fabricación de este tipo de dispositivos.
|
||||
\item En el capítulo cuatro se realiza la implementció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ón en el área del Hardware Reconfigurable.
|
||||
\item El capítulo cinco es una guía de adaptación del sistema operativo linux para una arquitectura ARM.
|
||||
\end{itemize}
|
||||
|
||||
Por último se muestra como algunos de los resultados de este estudio han sido introducidos a los cursos del área de los sistemas digitales en la Universidad Nacional de Colombia y como se ha realizado su difusión en otras Universidades de Colombia.
|
47
course/.docs/cambio_categoria/introduction.tex~
Normal file
47
course/.docs/cambio_categoria/introduction.tex~
Normal file
@ -0,0 +1,47 @@
|
||||
\chapter{Introducción}
|
||||
|
||||
La industria de los semiconductores ha crecido velozmente durante los últimos años, su campo de acción se ha extendido a casi todas las actividades del ser humano (Entretenimiento, salud, seguridad, transporte, educación, etc); los tiempos de los procesos de diseño son cada vez mas cortos, lo cual require herramientas Hardware, Software y metodologías de diseño que ayuden a cumplir con las exigencias impuestas al sistema.
|
||||
|
||||
Esta \textit{invasió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ísimo grado de integración ponen a disposición de los diseñadores \textit{Systems On Chip} (SoC) en los cuales se integran procesadores de 32 bits con una gran variedad de periféricos tales como: Controladores de dispositivos de red (cableada e inalámbricos), controladores de video, procesadores aritméticos, controladores de memorias (Flash, SDRAM, DDR, USB, SD), codecs de audio, controladores de touch screen, etc; lo cual permite la implementación de aplicaciones completas dentro de uno de estos SoCs.
|
||||
|
||||
Por otro lado, las empresas desarrolladoras de SW crean herramientas de programación que permiten manejar toda la capacidad de estos SoCs. colocando a disposición de los diseñadores: compiladores, simuladores, emuladores, librerí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ó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ón \cite{CLSB05}. La figura \ref{os2} muestra un cuadro comparativo de la utilización de herramientas comerciales y linux; de nuevo se observa que linux es el preferido por los diseñadores. Este resultado es interesante ya que uno de los supuestos puntos débiles del software de libre distribució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á disponible, es posible comprender perfectamente su funcionamiento, lo cual no sucede con el software comercial; además, existen muchos foros de diseñ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óricos, muy seguramente alguien más preguntó lo mismo antes que nosotros.
|
||||
|
||||
|
||||
El caracter gratutito de las herramientas de libre distribución no significa, ni mucho menos, mala calidad, todo lo contrario, existen muchas personas que escudriñ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án constantemente depurando y perfeccionando una determinada aplicació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ón empresas como PALM, han dejado de lado productos propietarios como el PALM OS para utilizar linux, SUN Microsystems, liberó el código fuente de su sistema operativo Solaris, ya que no era comparable con linux y está 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ó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ó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ómica \footnote{En la actualidad cerca del 60\% de los ingenieros trabajan en compañí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ón de los programas acedémicos: En muchas de las Universidades de Colombia se utilizan tecnologías obsoletas que impiden la aplicación de metodologías de diseño modernas además de impedir el desarrollo de aplicaciones comerciales, un ejemplo de este tipo de tecnologías es la lógica TTL (74XX) y sus equivalentes en CMOS. Aunque vale la pena aclarar que este tipo de tecnología es útil a la hora de enseñar conceptos básicos, no puede ser utilizada como única herramienta de implementación. Un ejemplo de desactualización de metodologías de diseño lo encontramos en las herramientas de programación para microcontroladores, una gran cantidad de Universidades utilizan lenguaje ensamblador, lo cual impide la re-utilización de código y crea dependencias con el HW utilizado.
|
||||
|
||||
\item Falta de interés de la Industria: Un gran porcentaje de la industria Colombiana es consumidora de tecnología, es decir, no generan sus propias soluciones, no cuentan con departamentos de Investigación y Desarrollo; esto se debe a la falta de confianza en los productos nacionales y en algunos casos a la inexistencia de producción nacional. Por otro lado, la cooperación entre la Universidad y la industria es muy reducida, debido a falta de políticas en las Universidades que regulen esta actividad y a la poca inversión por parte de las empresas.
|
||||
|
||||
\item Polí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ón, estos impuestos están por el orden del 26\% del valor del producto. Por otro lado la apertura econó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ón por parte de las políticas estatales condena a los desarrolladores de estos sistemas a la quiebra económica.
|
||||
|
||||
\end{enumerate}
|
||||
|
||||
Este proyecto resume el trabajo realizado durante los últimos cuatro años en el área de la electrónica digital y más exactamente en el estudio de las metodologías de diseño modernas con aplicaciones comerciales y es presentado para cumplir parcialmente los requisitos de cambio de categoría de profesor asistente a asociado. El presente informe está dividido de la siguiente forma:
|
||||
|
||||
|
||||
\begin{itemize}
|
||||
\item En el capítulo 1 se realiza una breve descripción de los sistemas embebidos, se enumeran sus características, aplicaciones y se hace una descripción de las herramientas HW y SW necesarias para el diseño de los mismos. En los capítulos siguientes se desarrollan casos de estudio encaminados a la comprensión de estos sistemas:
|
||||
\item En el capítulo dos se trabaja con una plataforma comercial de bajo costo: El GameBoy de Nintendo, (gracias a los elevados volúmenes de producción el costo de este dispositivo es bajo alrededor de 40 USD) esta plataforma nos permite desarrollar conceptos básicos como la compilación cruzada, la interfaz HW-SW y los sistemas operativos.
|
||||
\item En el capítulo tres se muestra la implementación de la primera plataforma de desarrollo para sistemas embebidos diseñada en la Universidad Nacional, a pesar de ser muy sencilla permite dar un gran paso en el proceso de fabricación de este tipo de dispositivos.
|
||||
\item En el capítulo cuatro se realiza la implementció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ón en el área del Hardware Reconfigurable.
|
||||
\item El capítulo cinco es una guía de adaptación del sistema operativo linux para una arquitectura ARM.
|
||||
\end{itemize}
|
||||
|
||||
Por último se muestra como algunos de los resultados de este estudio han sido introducidos a los cursos del área de los sistemas digitales en la Universidad Nacional de Colombia y como se ha realizado su difusión en otras Universidades de Colombia.
|
79
course/.docs/cambio_categoria/main.aux
Normal file
79
course/.docs/cambio_categoria/main.aux
Normal file
@ -0,0 +1,79 @@
|
||||
\relax
|
||||
\catcode`.\active
|
||||
\catcode`\.=12
|
||||
\catcode`"\active
|
||||
\catcode`<\active
|
||||
\catcode`>\active
|
||||
\es@quoting
|
||||
\bibstyle{unsrt}
|
||||
\select@language{spanish}
|
||||
\@writefile{toc}{\select@language{spanish}}
|
||||
\@writefile{lof}{\select@language{spanish}}
|
||||
\@writefile{lot}{\select@language{spanish}}
|
||||
\citation{A1}
|
||||
\citation{Wik}
|
||||
\citation{Wik}
|
||||
\citation{CLSB05}
|
||||
\@writefile{toc}{\contentsline {chapter}{\numberline {1}Introducci\'on}{3}}
|
||||
\@writefile{lof}{\addvspace {10\p@ }}
|
||||
\@writefile{lot}{\addvspace {10\p@ }}
|
||||
\citation{JT04}
|
||||
\citation{VDC06}
|
||||
\@writefile{lof}{\contentsline {figure}{\numberline {1.1}{\ignorespaces Utilizaci\'on actual de OS para aplicaciones embebidas: Fuente \cite {JT04}.}}{4}}
|
||||
\newlabel{os}{{1.1}{4}}
|
||||
\@writefile{lof}{\contentsline {figure}{\numberline {1.2}{\ignorespaces Utilizaci\'on actual de OS para aplicaciones embebidas: Fuente http://www.linuxdevices.com/articles/AT7070519787.html.}}{5}}
|
||||
\newlabel{os2}{{1.2}{5}}
|
||||
\citation{Wik}
|
||||
\@writefile{toc}{\contentsline {chapter}{\numberline {2}Conceptos B\'asicos de los Sistemas Embebidos}{7}}
|
||||
\@writefile{lof}{\addvspace {10\p@ }}
|
||||
\@writefile{lot}{\addvspace {10\p@ }}
|
||||
\@writefile{toc}{\contentsline {section}{\numberline {2.1}Definici\'on}{7}}
|
||||
\@writefile{toc}{\contentsline {section}{\numberline {2.2}Caracter\IeC {\'\i }sticas}{7}}
|
||||
\@writefile{toc}{\contentsline {section}{\numberline {2.3}Arquitectura}{7}}
|
||||
\@writefile{lof}{\contentsline {figure}{\numberline {2.1}{\ignorespaces Arquitectura de un Sistema Embebido}}{8}}
|
||||
\newlabel{es_arch}{{2.1}{8}}
|
||||
\citation{Cor05}
|
||||
\@writefile{toc}{\contentsline {section}{\numberline {2.4}Metodolog\IeC {\'\i }a de Dise\~no}{9}}
|
||||
\@writefile{lof}{\contentsline {figure}{\numberline {2.2}{\ignorespaces Flujo de Dise\~no de un Sistema Embebido}}{10}}
|
||||
\newlabel{des_flow}{{2.2}{10}}
|
||||
\citation{A1}
|
||||
\@writefile{toc}{\contentsline {subsection}{\numberline {2.4.1}Herramientas Software de libre distribuci\'on \textit {GNU toolchain}}{11}}
|
||||
\@writefile{lof}{\contentsline {figure}{\numberline {2.3}{\ignorespaces Tendencia de utilizaci\'on de herramientas de desarrollo}}{11}}
|
||||
\newlabel{tools}{{2.3}{11}}
|
||||
\@writefile{toc}{\contentsline {subsection}{\numberline {2.4.2}Componentes del \textit {GNU toolchain} }{11}}
|
||||
\@writefile{toc}{\contentsline {subsection}{\numberline {2.4.3}GNU binutils\cite {A1}}{11}}
|
||||
\citation{Wik}
|
||||
\@writefile{toc}{\contentsline {subsection}{\numberline {2.4.4}GNU Compiler Collection\cite {Wik}}{12}}
|
||||
\@writefile{toc}{\contentsline {subsubsection}{Lenguajes}{12}}
|
||||
\@writefile{toc}{\contentsline {subsubsection}{Arquitecturas}{13}}
|
||||
\@writefile{lof}{\contentsline {figure}{\numberline {2.4}{\ignorespaces N\'umero promedio de desarrolladores por compa\~n\IeC {\'\i }a. Fuente Venture Development Corp}}{14}}
|
||||
\newlabel{group}{{2.4}{14}}
|
||||
\@writefile{toc}{\contentsline {subsection}{\numberline {2.4.5}GNU Debugger}{14}}
|
||||
\citation{BG}
|
||||
\citation{Lin05}
|
||||
\citation{DK06}
|
||||
\citation{MLH98}
|
||||
\@writefile{toc}{\contentsline {subsection}{\numberline {2.4.6}C Libraries}{15}}
|
||||
\@writefile{toc}{\contentsline {section}{\numberline {2.5}Obtenci\'on y utilizaci\'on del \textit {GNU toolchain}}{15}}
|
||||
\@writefile{toc}{\contentsline {subsection}{\numberline {2.5.1}Conceptos Previos}{15}}
|
||||
\citation{Lin05}
|
||||
\@writefile{lof}{\contentsline {figure}{\numberline {2.5}{\ignorespaces Tendencia del mercado de procesadores para sistemas embebidos. Fuente:\cite {Lin05} }}{16}}
|
||||
\newlabel{arch}{{2.5}{16}}
|
||||
\@writefile{toc}{\contentsline {subsubsection}{El formato \textbf {ELF}}{16}}
|
||||
\@writefile{lof}{\contentsline {figure}{\numberline {2.6}{\ignorespaces Tendencia del mercado de procesadores para sistemas embebidos. Fuente:\cite {Lin05} }}{16}}
|
||||
\newlabel{elf1}{{2.6}{16}}
|
||||
\citation{Lin05}
|
||||
\@writefile{toc}{\contentsline {subsection}{\numberline {2.5.2}Flujo de dise\~no software}{18}}
|
||||
\@writefile{lof}{\contentsline {figure}{\numberline {2.7}{\ignorespaces Tendencia del mercado de procesadores para sistemas embebidos. Fuente:\cite {Lin05} }}{18}}
|
||||
\newlabel{toolchain_flow}{{2.7}{18}}
|
||||
\@writefile{toc}{\contentsline {section}{\numberline {2.6}Makefile}{19}}
|
||||
\bibdata{biblio_EL}
|
||||
\bibcite{A1}{1}
|
||||
\bibcite{Wik}{2}
|
||||
\bibcite{CLSB05}{3}
|
||||
\bibcite{JT04}{4}
|
||||
\bibcite{VDC06}{5}
|
||||
\bibcite{BG}{6}
|
||||
\bibcite{Lin05}{7}
|
||||
\bibcite{DK06}{8}
|
||||
\bibcite{MLH98}{9}
|
51
course/.docs/cambio_categoria/main.bbl
Normal file
51
course/.docs/cambio_categoria/main.bbl
Normal file
@ -0,0 +1,51 @@
|
||||
\begin{thebibliography}{1}
|
||||
|
||||
\bibitem{A1}
|
||||
{Aleph 1}.
|
||||
\newblock Building the {T}oolchain.
|
||||
\newblock http://www.aleph1.co.uk/node/279.
|
||||
|
||||
\bibitem{Wik}
|
||||
Wikipedia.
|
||||
\newblock Wikipedia, the free encyclopedia.
|
||||
\newblock http://en.wikipedia.org/.
|
||||
|
||||
\bibitem{CLSB05}
|
||||
{C. Lanfear}, {S. Balacco}, and {M. Volckmann}.
|
||||
\newblock The 2005 {E}mbedded {S}oftware {S}trategic {M}arket {I}ntelligence
|
||||
{P}rogram.
|
||||
\newblock {\em Venture Development Corporation http://www.vdc-corp.com}, August
|
||||
2005.
|
||||
|
||||
\bibitem{JT04}
|
||||
{J. Turley}.
|
||||
\newblock Embedded systems survey: {O}perating systems up for grabs.
|
||||
\newblock {\em Embedded Systems Programming}, May 2004.
|
||||
|
||||
\bibitem{VDC06}
|
||||
{Venture Development Corp.}
|
||||
\newblock Small teams dominate embedded software development.
|
||||
\newblock http://www.linuxdevices.com/articles/AT7019328497.html, 1 June 2006.
|
||||
|
||||
\bibitem{BG}
|
||||
{Bill Gatliff}.
|
||||
\newblock Porting and {U}sing {N}ewlib in {E}mbedded {S}ystems.
|
||||
\newblock http://venus.billgatliff.com/node/3.
|
||||
|
||||
\bibitem{Lin05}
|
||||
Linuxdevices.
|
||||
\newblock Embedded {L}inux market snapshot, 2005.
|
||||
\newblock {\em http://www.linuxdevices.com}, 4 May 2005.
|
||||
|
||||
\bibitem{DK06}
|
||||
{Dan Kegel}.
|
||||
\newblock Building and {T}esting gcc/glibc cross toolchains.
|
||||
\newblock http://www.kegel.com/crosstool/, 20 February 2006.
|
||||
|
||||
\bibitem{MLH98}
|
||||
{Michael L. Haungs}.
|
||||
\newblock The {E}xecutable and {L}inking {F}ormat ({ELF}).
|
||||
\newblock http://www.cs.ucdavis.edu/~haungs/paper/node1.html, 21 September
|
||||
1998.
|
||||
|
||||
\end{thebibliography}
|
47
course/.docs/cambio_categoria/main.blg
Normal file
47
course/.docs/cambio_categoria/main.blg
Normal file
@ -0,0 +1,47 @@
|
||||
This is BibTeX, Version 0.99c (Web2C 7.5.4)
|
||||
The top-level auxiliary file: main.aux
|
||||
The style file: unsrt.bst
|
||||
Database file #1: biblio_EL.bib
|
||||
Warning--I didn't find a database entry for "Cor05"
|
||||
You've used 9 entries,
|
||||
1791 wiz_defined-function locations,
|
||||
500 strings with 4568 characters,
|
||||
and the built_in function-call counts, 1212 in all, are:
|
||||
= -- 97
|
||||
> -- 43
|
||||
< -- 0
|
||||
+ -- 20
|
||||
- -- 11
|
||||
* -- 31
|
||||
:= -- 204
|
||||
add.period$ -- 27
|
||||
call.type$ -- 9
|
||||
change.case$ -- 9
|
||||
chr.to.int$ -- 0
|
||||
cite$ -- 9
|
||||
duplicate$ -- 54
|
||||
empty$ -- 151
|
||||
format.name$ -- 11
|
||||
if$ -- 274
|
||||
int.to.chr$ -- 0
|
||||
int.to.str$ -- 9
|
||||
missing$ -- 3
|
||||
newline$ -- 48
|
||||
num.names$ -- 9
|
||||
pop$ -- 42
|
||||
preamble$ -- 1
|
||||
purify$ -- 0
|
||||
quote$ -- 0
|
||||
skip$ -- 33
|
||||
stack$ -- 0
|
||||
substring$ -- 0
|
||||
swap$ -- 9
|
||||
text.length$ -- 0
|
||||
text.prefix$ -- 0
|
||||
top$ -- 0
|
||||
type$ -- 0
|
||||
warning$ -- 0
|
||||
while$ -- 9
|
||||
width$ -- 10
|
||||
write$ -- 89
|
||||
(There was 1 warning)
|
475
course/.docs/cambio_categoria/main.log
Normal file
475
course/.docs/cambio_categoria/main.log
Normal file
@ -0,0 +1,475 @@
|
||||
This is pdfTeXk, Version 3.141592-1.40.3 (Web2C 7.5.6) (format=pdflatex 2009.4.27) 16 JUL 2009 14:24
|
||||
entering extended mode
|
||||
Source specials enabled.
|
||||
%&-line parsing enabled.
|
||||
**main.tex
|
||||
(./main.tex
|
||||
LaTeX2e <2005/12/01>
|
||||
Babel <v3.8h> and hyphenation patterns for english, usenglishmax, dumylang, noh
|
||||
yphenation, ukrainian, russian, bulgarian, loaded.
|
||||
(/usr/share/texmf-texlive/tex/latex/base/report.cls
|
||||
Document Class: report 2005/09/16 v1.4f Standard LaTeX document class
|
||||
(/usr/share/texmf-texlive/tex/latex/base/size10.clo
|
||||
File: size10.clo 2005/09/16 v1.4f Standard LaTeX file (size option)
|
||||
)
|
||||
\c@part=\count79
|
||||
\c@chapter=\count80
|
||||
\c@section=\count81
|
||||
\c@subsection=\count82
|
||||
\c@subsubsection=\count83
|
||||
\c@paragraph=\count84
|
||||
\c@subparagraph=\count85
|
||||
\c@figure=\count86
|
||||
\c@table=\count87
|
||||
\abovecaptionskip=\skip41
|
||||
\belowcaptionskip=\skip42
|
||||
\bibindent=\dimen102
|
||||
)
|
||||
(/usr/share/texmf-texlive/tex/latex/base/fontenc.sty
|
||||
Package: fontenc 2005/09/27 v1.99g Standard LaTeX package
|
||||
)
|
||||
(/usr/share/texmf-texlive/tex/latex/base/inputenc.sty
|
||||
Package: inputenc 2006/05/05 v1.1b Input encoding file
|
||||
\inpenc@prehook=\toks14
|
||||
\inpenc@posthook=\toks15
|
||||
|
||||
(/usr/share/texmf-texlive/tex/latex/base/latin1.def
|
||||
File: latin1.def 2006/05/05 v1.1b Input encoding file
|
||||
))
|
||||
(/usr/share/texmf-texlive/tex/generic/babel/babel.sty
|
||||
Package: babel 2005/11/23 v3.8h The Babel package
|
||||
|
||||
(/usr/share/texmf-texlive/tex/generic/babel/spanish.ldf
|
||||
Language: spanish.ldf 2005/03/31 v4.2b Spanish support from the babel system
|
||||
|
||||
(/usr/share/texmf-texlive/tex/generic/babel/babel.def
|
||||
File: babel.def 2005/11/23 v3.8h Babel common definitions
|
||||
\babel@savecnt=\count88
|
||||
\U@D=\dimen103
|
||||
)
|
||||
|
||||
Package babel Warning: No hyphenation patterns were loaded for
|
||||
(babel) the language `Spanish'
|
||||
(babel) I will use the patterns loaded for \language=0 instead.
|
||||
|
||||
\l@spanish = a dialect from \language0
|
||||
\es@quottoks=\toks16
|
||||
\es@quotdepth=\count89
|
||||
Package babel Info: Making . an active character on input line 509.
|
||||
Package babel Info: Making " an active character on input line 540.
|
||||
Package babel Info: Making < an active character on input line 641.
|
||||
Package babel Info: Making > an active character on input line 642.
|
||||
)) (/usr/share/texmf-texlive/tex/latex/graphics/graphicx.sty
|
||||
Package: graphicx 1999/02/16 v1.0f Enhanced LaTeX Graphics (DPC,SPQR)
|
||||
|
||||
(/usr/share/texmf-texlive/tex/latex/graphics/keyval.sty
|
||||
Package: keyval 1999/03/16 v1.13 key=value parser (DPC)
|
||||
\KV@toks@=\toks17
|
||||
)
|
||||
(/usr/share/texmf-texlive/tex/latex/graphics/graphics.sty
|
||||
Package: graphics 2006/02/20 v1.0o Standard LaTeX Graphics (DPC,SPQR)
|
||||
|
||||
(/usr/share/texmf-texlive/tex/latex/graphics/trig.sty
|
||||
Package: trig 1999/03/16 v1.09 sin cos tan (DPC)
|
||||
)
|
||||
(/etc/texmf/tex/latex/config/graphics.cfg
|
||||
File: graphics.cfg 2007/01/18 v1.5 graphics configuration of teTeX/TeXLive
|
||||
)
|
||||
Package graphics Info: Driver file: pdftex.def on input line 90.
|
||||
|
||||
(/usr/share/texmf-texlive/tex/latex/pdftex-def/pdftex.def
|
||||
File: pdftex.def 2007/01/08 v0.04d Graphics/color for pdfTeX
|
||||
\Gread@gobject=\count90
|
||||
))
|
||||
\Gin@req@height=\dimen104
|
||||
\Gin@req@width=\dimen105
|
||||
)
|
||||
(/usr/share/texmf-texlive/tex/latex/psnfss/times.sty
|
||||
Package: times 2005/04/12 PSNFSS-v9.2a (SPQR)
|
||||
)
|
||||
(/usr/share/texmf-texlive/tex/latex/colortbl/colortbl.sty
|
||||
Package: colortbl 2001/02/13 v0.1j Color table columns (DPC)
|
||||
|
||||
(/usr/share/texmf-texlive/tex/latex/tools/array.sty
|
||||
Package: array 2005/08/23 v2.4b Tabular extension package (FMi)
|
||||
\col@sep=\dimen106
|
||||
\extrarowheight=\dimen107
|
||||
\NC@list=\toks18
|
||||
\extratabsurround=\skip43
|
||||
\backup@length=\skip44
|
||||
)
|
||||
(/usr/share/texmf-texlive/tex/latex/graphics/color.sty
|
||||
Package: color 2005/11/14 v1.0j Standard LaTeX Color (DPC)
|
||||
|
||||
(/etc/texmf/tex/latex/config/color.cfg
|
||||
File: color.cfg 2007/01/18 v1.5 color configuration of teTeX/TeXLive
|
||||
)
|
||||
Package color Info: Driver file: pdftex.def on input line 130.
|
||||
)
|
||||
\everycr=\toks19
|
||||
\minrowclearance=\skip45
|
||||
)
|
||||
(/usr/share/texmf-texlive/tex/latex/tools/multicol.sty
|
||||
Package: multicol 2006/05/18 v1.6g multicolumn formatting (FMi)
|
||||
\c@tracingmulticols=\count91
|
||||
\mult@box=\box26
|
||||
\multicol@leftmargin=\dimen108
|
||||
\c@unbalance=\count92
|
||||
\c@collectmore=\count93
|
||||
\doublecol@number=\count94
|
||||
\multicoltolerance=\count95
|
||||
\multicolpretolerance=\count96
|
||||
\full@width=\dimen109
|
||||
\page@free=\dimen110
|
||||
\premulticols=\dimen111
|
||||
\postmulticols=\dimen112
|
||||
\multicolsep=\skip46
|
||||
\multicolbaselineskip=\skip47
|
||||
\partial@page=\box27
|
||||
\last@line=\box28
|
||||
\mult@rightbox=\box29
|
||||
\mult@grightbox=\box30
|
||||
\mult@gfirstbox=\box31
|
||||
\mult@firstbox=\box32
|
||||
\@tempa=\box33
|
||||
\@tempa=\box34
|
||||
\@tempa=\box35
|
||||
\@tempa=\box36
|
||||
\@tempa=\box37
|
||||
\@tempa=\box38
|
||||
\@tempa=\box39
|
||||
\@tempa=\box40
|
||||
\@tempa=\box41
|
||||
\@tempa=\box42
|
||||
\@tempa=\box43
|
||||
\@tempa=\box44
|
||||
\@tempa=\box45
|
||||
\@tempa=\box46
|
||||
\@tempa=\box47
|
||||
\@tempa=\box48
|
||||
\@tempa=\box49
|
||||
\c@columnbadness=\count97
|
||||
\c@finalcolumnbadness=\count98
|
||||
\last@try=\dimen113
|
||||
\multicolovershoot=\dimen114
|
||||
\multicolundershoot=\dimen115
|
||||
\mult@nat@firstbox=\box50
|
||||
\colbreak@box=\box51
|
||||
)
|
||||
(/usr/share/texmf-texlive/tex/latex/multirow/multirow.sty
|
||||
\bigstrutjot=\dimen116
|
||||
)
|
||||
(/usr/share/texmf-texlive/tex/latex/pdfpages/pdfpages.sty
|
||||
Package: pdfpages 2006/08/12 v0.4a Insert pages of external PDF documents (AM)
|
||||
|
||||
(/usr/share/texmf-texlive/tex/latex/base/ifthen.sty
|
||||
Package: ifthen 2001/05/26 v1.1c Standard LaTeX ifthen package (DPC)
|
||||
)
|
||||
(/usr/share/texmf-texlive/tex/latex/tools/calc.sty
|
||||
Package: calc 2005/08/06 v4.2 Infix arithmetic (KKT,FJ)
|
||||
\calc@Acount=\count99
|
||||
\calc@Bcount=\count100
|
||||
\calc@Adimen=\dimen117
|
||||
\calc@Bdimen=\dimen118
|
||||
\calc@Askip=\skip48
|
||||
\calc@Bskip=\skip49
|
||||
LaTeX Info: Redefining \setlength on input line 75.
|
||||
LaTeX Info: Redefining \addtolength on input line 76.
|
||||
\calc@Ccount=\count101
|
||||
\calc@Cskip=\skip50
|
||||
)
|
||||
(/usr/share/texmf-texlive/tex/latex/eso-pic/eso-pic.sty
|
||||
Package: eso-pic 2006/07/14 v1.1d eso-pic (RN)
|
||||
|
||||
(/usr/share/texmf-texlive/tex/latex/everyshi/everyshi.sty
|
||||
Package: everyshi 2001/05/15 v3.00 EveryShipout Package (MS)
|
||||
))
|
||||
(/usr/share/texmf-texlive/tex/latex/pdfpages/pppdftex.def
|
||||
File: pppdftex.def 2006/08/12 v0.4a Pdfpages driver for pdfTeX (AM)
|
||||
)
|
||||
\AM@pagebox=\box52
|
||||
\AM@toc@title=\toks20
|
||||
\c@AM@survey=\count102
|
||||
)
|
||||
(/usr/share/texmf-texlive/tex/latex/graphics/lscape.sty
|
||||
Package: lscape 2000/10/22 v3.01 Landscape Pages (DPC)
|
||||
)
|
||||
(/usr/share/texmf-texlive/tex/latex/listings/listings.sty
|
||||
\lst@mode=\count103
|
||||
\lst@gtempboxa=\box53
|
||||
\lst@token=\toks21
|
||||
\lst@length=\count104
|
||||
\lst@currlwidth=\dimen119
|
||||
\lst@column=\count105
|
||||
\lst@pos=\count106
|
||||
\lst@lostspace=\dimen120
|
||||
\lst@width=\dimen121
|
||||
\lst@newlines=\count107
|
||||
\lst@lineno=\count108
|
||||
\c@lstlisting=\count109
|
||||
\lst@maxwidth=\dimen122
|
||||
|
||||
(/usr/share/texmf-texlive/tex/latex/listings/lstpatch.sty
|
||||
File: lstpatch.sty 2004/10/17 1.3b (Carsten Heinz)
|
||||
)
|
||||
(/usr/share/texmf-texlive/tex/latex/listings/lstmisc.sty
|
||||
File: lstmisc.sty 2004/09/07 1.3 (Carsten Heinz)
|
||||
\c@lstnumber=\count110
|
||||
\lst@skipnumbers=\count111
|
||||
\lst@framebox=\box54
|
||||
)
|
||||
(/usr/share/texmf-texlive/tex/latex/listings/listings.cfg
|
||||
File: listings.cfg 2004/09/05 1.3 listings configuration
|
||||
))
|
||||
Package: listings 2004/10/17 1.3b (Carsten Heinz)
|
||||
|
||||
(/usr/share/texmf-texlive/tex/latex/listings/lstlang1.sty
|
||||
File: lstlang1.sty 2004/09/05 1.3 listings language file
|
||||
)
|
||||
(/usr/share/texmf-texlive/tex/latex/listings/lstmisc.sty
|
||||
File: lstmisc.sty 2004/09/07 1.3 (Carsten Heinz)
|
||||
)
|
||||
(/usr/share/texmf-texlive/tex/latex/tools/longtable.sty
|
||||
Package: longtable 2004/02/01 v4.11 Multi-page Table package (DPC)
|
||||
\LTleft=\skip51
|
||||
\LTright=\skip52
|
||||
\LTpre=\skip53
|
||||
\LTpost=\skip54
|
||||
\LTchunksize=\count112
|
||||
\LTcapwidth=\dimen123
|
||||
\LT@head=\box55
|
||||
\LT@firsthead=\box56
|
||||
\LT@foot=\box57
|
||||
\LT@lastfoot=\box58
|
||||
\LT@cols=\count113
|
||||
\LT@rows=\count114
|
||||
\c@LT@tables=\count115
|
||||
\c@LT@chunks=\count116
|
||||
\LT@p@ftn=\toks22
|
||||
) (./main.aux)
|
||||
\openout1 = `main.aux'.
|
||||
|
||||
LaTeX Font Info: Checking defaults for OML/cmm/m/it on input line 43.
|
||||
LaTeX Font Info: ... okay on input line 43.
|
||||
LaTeX Font Info: Checking defaults for T1/cmr/m/n on input line 43.
|
||||
LaTeX Font Info: ... okay on input line 43.
|
||||
LaTeX Font Info: Checking defaults for OT1/cmr/m/n on input line 43.
|
||||
LaTeX Font Info: ... okay on input line 43.
|
||||
LaTeX Font Info: Checking defaults for OMS/cmsy/m/n on input line 43.
|
||||
LaTeX Font Info: ... okay on input line 43.
|
||||
LaTeX Font Info: Checking defaults for OMX/cmex/m/n on input line 43.
|
||||
LaTeX Font Info: ... okay on input line 43.
|
||||
LaTeX Font Info: Checking defaults for U/cmr/m/n on input line 43.
|
||||
LaTeX Font Info: ... okay on input line 43.
|
||||
LaTeX Font Info: Try loading font information for OT1+ptm on input line 43.
|
||||
|
||||
(/usr/share/texmf-texlive/tex/latex/psnfss/ot1ptm.fd
|
||||
File: ot1ptm.fd 2001/06/04 font definitions for OT1/ptm.
|
||||
)
|
||||
(/usr/share/texmf/tex/context/base/supp-pdf.tex
|
||||
[Loading MPS to PDF converter (version 2006.09.02).]
|
||||
\scratchcounter=\count117
|
||||
\scratchdimen=\dimen124
|
||||
\scratchbox=\box59
|
||||
\nofMPsegments=\count118
|
||||
\nofMParguments=\count119
|
||||
\everyMPshowfont=\toks23
|
||||
\MPscratchCnt=\count120
|
||||
\MPscratchDim=\dimen125
|
||||
\MPnumerator=\count121
|
||||
\everyMPtoPDFconversion=\toks24
|
||||
) ABD: EveryShipout initializing macros (./title.tex
|
||||
LaTeX Font Info: External font `cmex10' loaded for size
|
||||
(Font) <12> on input line 11.
|
||||
LaTeX Font Info: External font `cmex10' loaded for size
|
||||
(Font) <8> on input line 11.
|
||||
LaTeX Font Info: External font `cmex10' loaded for size
|
||||
(Font) <6> on input line 11.
|
||||
[1
|
||||
|
||||
{/var/lib/texmf/fonts/map/pdftex/updmap/pdftex.map}]
|
||||
Underfull \hbox (badness 10000) in paragraph at lines 16--20
|
||||
|
||||
[]
|
||||
|
||||
LaTeX Font Info: Try loading font information for OMS+ptm on input line 23.
|
||||
(/usr/share/texmf-texlive/tex/latex/psnfss/omsptm.fd
|
||||
File: omsptm.fd
|
||||
)
|
||||
LaTeX Font Info: Font shape `OMS/ptm/m/n' in size <10> not available
|
||||
(Font) Font shape `OMS/cmsy/m/n' tried instead on input line 23.
|
||||
LaTeX Font Info: Try loading font information for OT1+pcr on input line 24.
|
||||
|
||||
(/usr/share/texmf-texlive/tex/latex/psnfss/ot1pcr.fd
|
||||
File: ot1pcr.fd 2001/06/04 font definitions for OT1/pcr.
|
||||
)
|
||||
Underfull \hbox (badness 10000) in paragraph at lines 23--25
|
||||
|
||||
[]
|
||||
|
||||
|
||||
Underfull \hbox (badness 10000) in paragraph at lines 26--30
|
||||
|
||||
[]
|
||||
|
||||
|
||||
Underfull \hbox (badness 10000) in paragraph at lines 31--34
|
||||
|
||||
[]
|
||||
|
||||
|
||||
Underfull \hbox (badness 10000) in paragraph at lines 35--36
|
||||
|
||||
[]
|
||||
|
||||
[1])
|
||||
LaTeX Font Info: Font shape `OT1/ptm/bx/n' in size <24.88> not available
|
||||
(Font) Font shape `OT1/ptm/b/n' tried instead on input line 46.
|
||||
(./main.toc
|
||||
LaTeX Font Info: Font shape `OT1/ptm/bx/n' in size <10> not available
|
||||
(Font) Font shape `OT1/ptm/b/n' tried instead on input line 2.
|
||||
LaTeX Font Info: External font `cmex10' loaded for size
|
||||
(Font) <7> on input line 4.
|
||||
LaTeX Font Info: External font `cmex10' loaded for size
|
||||
(Font) <5> on input line 4.
|
||||
)
|
||||
\tf@toc=\write3
|
||||
\openout3 = `main.toc'.
|
||||
|
||||
(./introduction.tex [2
|
||||
|
||||
]
|
||||
Cap\'{\i }tulo 1.
|
||||
LaTeX Font Info: Font shape `OT1/ptm/bx/n' in size <20.74> not available
|
||||
(Font) Font shape `OT1/ptm/b/n' tried instead on input line 1.
|
||||
[3
|
||||
|
||||
] <./images/Current_OS.jpg, id=19, 401.5pt x 460.72125pt>
|
||||
File: ./images/Current_OS.jpg Graphic file (type jpg)
|
||||
|
||||
<use ./images/Current_OS.jpg>
|
||||
<./images/OS_embedded.jpg, id=20, 301.125pt x 232.79893pt>
|
||||
File: ./images/OS_embedded.jpg Graphic file (type jpg)
|
||||
|
||||
<use ./images/OS_embedded.jpg>
|
||||
Underfull \hbox (badness 10000) in paragraph at lines 21--21
|
||||
[][]\OT1/ptm/m/n/10 Figura 1.2: Uti-lizaci[]on ac-tu-al de OS para apli-ca-cion
|
||||
es em-be-bidas: Fuente
|
||||
[]
|
||||
|
||||
[4 <./images/Current_OS.jpg>] [5 <./images/OS_embedded.jpg>]) (./chapter1.tex
|
||||
[6]
|
||||
Cap\'{\i }tulo 2.
|
||||
LaTeX Font Info: Font shape `OT1/ptm/bx/n' in size <14.4> not available
|
||||
(Font) Font shape `OT1/ptm/b/n' tried instead on input line 3.
|
||||
<./images/ES_Architecture.png, id=32, 488.82625pt x 407.5225pt>
|
||||
File: ./images/ES_Architecture.png Graphic file (type png)
|
||||
|
||||
<use ./images/ES_Architecture.png> [7
|
||||
|
||||
] [8 <./images/ES_Architecture.png (PNG copy)>]
|
||||
|
||||
LaTeX Warning: Citation `Cor05' on page 9 undefined on input line 62.
|
||||
|
||||
<./images/design_flow.jpg, id=39, 675.52374pt x 1068.99374pt>
|
||||
File: ./images/design_flow.jpg Graphic file (type jpg)
|
||||
|
||||
<use ./images/design_flow.jpg>
|
||||
|
||||
LaTeX Warning: Float too large for page by 24.60542pt on input line 67.
|
||||
|
||||
[9] [10 <./images/design_flow.jpg>]
|
||||
LaTeX Font Info: Font shape `OT1/ptm/bx/n' in size <12> not available
|
||||
(Font) Font shape `OT1/ptm/b/n' tried instead on input line 149.
|
||||
LaTeX Font Info: Font shape `OT1/ptm/bx/it' in size <12> not available
|
||||
(Font) Font shape `OT1/ptm/b/it' tried instead on input line 149.
|
||||
|
||||
<./images/embedded-linux-tool-trends-sm.jpg, id=46, 301.125pt x 227.04292pt>
|
||||
File: ./images/embedded-linux-tool-trends-sm.jpg Graphic file (type jpg)
|
||||
|
||||
<use ./images/embedded-linux-tool-trends-sm.jpg> [11 <./images/embedded-linux-t
|
||||
ool-trends-sm.jpg>] [12] [13]
|
||||
<./images/vdc_embedded_dev_company_size.jpg, id=59, 1806.75pt x 843.15pt>
|
||||
File: ./images/vdc_embedded_dev_company_size.jpg Graphic file (type jpg)
|
||||
|
||||
<use ./images/vdc_embedded_dev_company_size.jpg>
|
||||
LaTeX Font Info: Font shape `OT1/ptm/bx/n' in size <8> not available
|
||||
(Font) Font shape `OT1/ptm/b/n' tried instead on input line 241.
|
||||
LaTeX Font Info: Font shape `OMS/ptm/m/n' in size <8> not available
|
||||
(Font) Font shape `OMS/cmsy/m/n' tried instead on input line 253.
|
||||
[14 <./images/vdc_embedded_dev_company_size.jpg>]
|
||||
LaTeX Font Info: Font shape `OT1/ptm/bx/it' in size <14.4> not available
|
||||
(Font) Font shape `OT1/ptm/b/it' tried instead on input line 287.
|
||||
|
||||
<./images/embedded-processor-trends-sm.jpg, id=64, 301.125pt x 223.84514pt>
|
||||
File: ./images/embedded-processor-trends-sm.jpg Graphic file (type jpg)
|
||||
|
||||
<use ./images/embedded-processor-trends-sm.jpg>
|
||||
|
||||
LaTeX Warning: `h' float specifier changed to `ht'.
|
||||
|
||||
[15] <./images/ELF_Link_exec1.png, id=68, 509.905pt x 312.16624pt>
|
||||
File: ./images/ELF_Link_exec1.png Graphic file (type png)
|
||||
|
||||
<use ./images/ELF_Link_exec1.png> [16 <./images/embedded-processor-trends-sm.jp
|
||||
g> <./images/ELF_Link_exec1.png (PNG copy)>]
|
||||
LaTeX Font Info: Try loading font information for OML+ptm on input line 337.
|
||||
|
||||
|
||||
(/usr/share/texmf-texlive/tex/latex/psnfss/omlptm.fd
|
||||
File: omlptm.fd
|
||||
)
|
||||
LaTeX Font Info: Font shape `OML/ptm/m/n' in size <8> not available
|
||||
(Font) Font shape `OML/cmm/m/it' tried instead on input line 337.
|
||||
[17]
|
||||
<./images/SW_design_flow.png, id=76, 564.1075pt x 438.63875pt>
|
||||
File: ./images/SW_design_flow.png Graphic file (type png)
|
||||
|
||||
<use ./images/SW_design_flow.png> [18 <./images/SW_design_flow.png (PNG copy)>]
|
||||
[19]
|
||||
Underfull \hbox (badness 10000) in paragraph at lines 491--492
|
||||
|
||||
[]
|
||||
|
||||
|
||||
Overfull \hbox (72.41374pt too wide) in paragraph at lines 496--497
|
||||
[][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][
|
||||
][]
|
||||
[]
|
||||
|
||||
) (./main.bbl [20]
|
||||
Underfull \hbox (badness 10000) in paragraph at lines 26--29
|
||||
[][]\OT1/ptm/m/n/8 Venture De-vel-op-ment Corp. Small teams dom-i-nate em-bed-
|
||||
ded soft-ware de-vel-op-ment.
|
||||
[]
|
||||
|
||||
) [21
|
||||
|
||||
] (./main.aux)
|
||||
|
||||
LaTeX Warning: There were undefined references.
|
||||
|
||||
)
|
||||
Here is how much of TeX's memory you used:
|
||||
5331 strings out of 94834
|
||||
67806 string characters out of 1179181
|
||||
152743 words of memory out of 1500000
|
||||
8415 multiletter control sequences out of 10000+50000
|
||||
38234 words of font info for 65 fonts, out of 1200000 for 2000
|
||||
212 hyphenation exceptions out of 8191
|
||||
34i,9n,49p,1368b,1776s stack positions out of 5000i,500n,6000p,200000b,5000s
|
||||
{/usr/share/texmf-texlive/fonts/enc/dvips/base/8r.enc}</usr/share/texmf-texli
|
||||
ve/fonts/type1/bluesky/cm/cmmi8.pfb></usr/share/texmf-texlive/fonts/type1/blues
|
||||
ky/cm/cmsy10.pfb></usr/share/texmf-texlive/fonts/type1/bluesky/cm/cmsy7.pfb></u
|
||||
sr/share/texmf-texlive/fonts/type1/bluesky/cm/cmsy8.pfb></usr/share/texmf-texli
|
||||
ve/fonts/type1/urw/courier/ucrr8a.pfb></usr/share/texmf-texlive/fonts/type1/urw
|
||||
/times/utmb8a.pfb></usr/share/texmf-texlive/fonts/type1/urw/times/utmbi8a.pfb><
|
||||
/usr/share/texmf-texlive/fonts/type1/urw/times/utmr8a.pfb></usr/share/texmf-tex
|
||||
live/fonts/type1/urw/times/utmr8a.pfb></usr/share/texmf-texlive/fonts/type1/urw
|
||||
/times/utmri8a.pfb>
|
||||
Output written on main.pdf (22 pages, 648643 bytes).
|
||||
PDF statistics:
|
||||
123 PDF objects out of 1000 (max. 8388607)
|
||||
0 named destinations out of 1000 (max. 131072)
|
||||
46 words of extra memory for PDF output out of 10000 (max. 10000000)
|
||||
|
BIN
course/.docs/cambio_categoria/main.pdf
Normal file
BIN
course/.docs/cambio_categoria/main.pdf
Normal file
Binary file not shown.
56
course/.docs/cambio_categoria/main.tex.backup
Normal file
56
course/.docs/cambio_categoria/main.tex.backup
Normal 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ñ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ía de 1.5 cm al comienzo de cada párrafo
|
||||
|
||||
\input introduction
|
||||
\input chapter1
|
||||
% \input information}
|
||||
|
||||
\bibliography{biblio_EL}
|
||||
|
||||
\end{document}
|
56
course/.docs/cambio_categoria/main.tex~
Normal file
56
course/.docs/cambio_categoria/main.tex~
Normal 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ñ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ía de 1.5 cm al comienzo de cada párrafo
|
||||
|
||||
\input introduction
|
||||
\input chapter1
|
||||
% \input information}
|
||||
|
||||
\bibliography{biblio_EL}
|
||||
|
||||
\end{document}
|
20
course/.docs/cambio_categoria/main.toc
Normal file
20
course/.docs/cambio_categoria/main.toc
Normal file
@ -0,0 +1,20 @@
|
||||
\select@language {spanish}
|
||||
\contentsline {chapter}{\numberline {1}Introducci\'on}{3}
|
||||
\contentsline {chapter}{\numberline {2}Conceptos B\'asicos de los Sistemas Embebidos}{7}
|
||||
\contentsline {section}{\numberline {2.1}Definici\'on}{7}
|
||||
\contentsline {section}{\numberline {2.2}Caracter\IeC {\'\i }sticas}{7}
|
||||
\contentsline {section}{\numberline {2.3}Arquitectura}{7}
|
||||
\contentsline {section}{\numberline {2.4}Metodolog\IeC {\'\i }a de Dise\~no}{9}
|
||||
\contentsline {subsection}{\numberline {2.4.1}Herramientas Software de libre distribuci\'on \textit {GNU toolchain}}{11}
|
||||
\contentsline {subsection}{\numberline {2.4.2}Componentes del \textit {GNU toolchain} }{11}
|
||||
\contentsline {subsection}{\numberline {2.4.3}GNU binutils\cite {A1}}{11}
|
||||
\contentsline {subsection}{\numberline {2.4.4}GNU Compiler Collection\cite {Wik}}{12}
|
||||
\contentsline {subsubsection}{Lenguajes}{12}
|
||||
\contentsline {subsubsection}{Arquitecturas}{13}
|
||||
\contentsline {subsection}{\numberline {2.4.5}GNU Debugger}{14}
|
||||
\contentsline {subsection}{\numberline {2.4.6}C Libraries}{15}
|
||||
\contentsline {section}{\numberline {2.5}Obtenci\'on y utilizaci\'on del \textit {GNU toolchain}}{15}
|
||||
\contentsline {subsection}{\numberline {2.5.1}Conceptos Previos}{15}
|
||||
\contentsline {subsubsection}{El formato \textbf {ELF}}{16}
|
||||
\contentsline {subsection}{\numberline {2.5.2}Flujo de dise\~no software}{18}
|
||||
\contentsline {section}{\numberline {2.6}Makefile}{19}
|
BIN
course/.docs/cambio_categoria/src/hello
Executable file
BIN
course/.docs/cambio_categoria/src/hello
Executable file
Binary file not shown.
17
course/.docs/cambio_categoria/src/hello.c
Normal file
17
course/.docs/cambio_categoria/src/hello.c
Normal file
@ -0,0 +1,17 @@
|
||||
#include <stdio.h>
|
||||
|
||||
int global;
|
||||
int global_1 =7;
|
||||
|
||||
int main(void)
|
||||
{
|
||||
int local_i; // Variable no inicializada
|
||||
int local_j = 8; // Variable inicializada
|
||||
for(local_i=0; local_i<10; local_i++){
|
||||
printf("Printing %d\n", local_i*local_j); // Caracteres constantes
|
||||
local_j = local_j + 1;
|
||||
global = local_i;
|
||||
global_1 = local_i+local_j;
|
||||
}
|
||||
return 0;
|
||||
}
|
BIN
course/.docs/cambio_categoria/src/hello.o
Normal file
BIN
course/.docs/cambio_categoria/src/hello.o
Normal file
Binary file not shown.
BIN
course/.docs/cambio_categoria/src/test
Executable file
BIN
course/.docs/cambio_categoria/src/test
Executable file
Binary file not shown.
41
course/.docs/cambio_categoria/title.tex
Normal file
41
course/.docs/cambio_categoria/title.tex
Normal file
@ -0,0 +1,41 @@
|
||||
% Title Page
|
||||
\title{Sistemas Embebidos: Teoría, Implementación y Metodologías de Diseño \\
|
||||
\bigskip \bigskip \bigskip
|
||||
\bigskip \bigskip \bigskip
|
||||
UNIVERSIDAD NACIONAL DE COLOMBIA\\
|
||||
\bigskip \bigskip \bigskip
|
||||
\bigskip \bigskip \bigskip
|
||||
}
|
||||
\author{Carlos Iván Camargo Bareño}
|
||||
|
||||
\maketitle
|
||||
|
||||
\newpage
|
||||
\thispagestyle{empty}
|
||||
\parindent0pt
|
||||
{\scshape Informe Final}\\
|
||||
Sistemas Embebidos: Teoría, Implementación y Metodologías de Diseño\\
|
||||
\textsc{Author:} C.~Camargo\\
|
||||
\textsc{e-mail:} cicamargoba@unal.edu.co\\
|
||||
|
||||
\vfill
|
||||
|
||||
Copyright \copyright 2004, 2005\ Universidad Nacional de Colombia\\
|
||||
\texttt{http://www.unal.edu.co}\\
|
||||
|
||||
Permission is granted to copy, distribute and/or modify this document
|
||||
under the terms of the \textsc{gnu} Free Documentation License, version
|
||||
1.2, with no invariant sections, no front-cover texts, and no back-cover
|
||||
texts. A copy of the license is included in the end.\\
|
||||
|
||||
This document is distributed in the hope that it will be useful, but
|
||||
without any warranty; without even the implied warranty of merchantability
|
||||
or fitness for a particular purpose.\\
|
||||
|
||||
Published by the Universidad Nacional de Colombia\\
|
||||
|
||||
|
||||
\newpage
|
||||
\normalsize
|
||||
|
||||
\thispagestyle{empty}
|
41
course/.docs/cambio_categoria/title.tex.backup
Normal file
41
course/.docs/cambio_categoria/title.tex.backup
Normal file
@ -0,0 +1,41 @@
|
||||
% Title Page
|
||||
\title{UNIVERSIDAD NACIONAL DE COLOMBIA\\
|
||||
\bigskip \bigskip \bigskip
|
||||
\bigskip \bigskip \bigskip
|
||||
Proyecto de Investigación:\\
|
||||
\bigskip \bigskip \bigskip
|
||||
\bigskip \bigskip \bigskip
|
||||
Sistemas Embebidos: Teoría, Implementación y Metodologías de Diseño}
|
||||
\author{Carlos Iván Camargo Bareño}
|
||||
|
||||
\maketitle
|
||||
|
||||
\newpage
|
||||
\thispagestyle{empty}
|
||||
\parindent0pt
|
||||
{\scshape Informe Final}\\
|
||||
Sistemas Embebidos: Teoría, Implementación y Metodologías de Diseño\\
|
||||
\textsc{Author:} C.~Camargo\\
|
||||
\textsc{e-mail:} cicamargoba@unal.edu.co\\
|
||||
|
||||
\vfill
|
||||
|
||||
Copyright \copyright 2004, 2005\ Universidad Nacional de Colombia\\
|
||||
\texttt{http://www.unal.edu.co}\\
|
||||
|
||||
Permission is granted to copy, distribute and/or modify this document
|
||||
under the terms of the \textsc{gnu} Free Documentation License, version
|
||||
1.2, with no invariant sections, no front-cover texts, and no back-cover
|
||||
texts. A copy of the license is included in the end.\\
|
||||
|
||||
This document is distributed in the hope that it will be useful, but
|
||||
without any warranty; without even the implied warranty of merchantability
|
||||
or fitness for a particular purpose.\\
|
||||
|
||||
Published by the Universidad Nacional de Colombia\\
|
||||
|
||||
|
||||
\newpage
|
||||
\normalsize
|
||||
|
||||
\thispagestyle{empty}
|
41
course/.docs/cambio_categoria/title.tex~
Normal file
41
course/.docs/cambio_categoria/title.tex~
Normal file
@ -0,0 +1,41 @@
|
||||
% Title Page
|
||||
\title{UNIVERSIDAD NACIONAL DE COLOMBIA\\
|
||||
\bigskip \bigskip \bigskip
|
||||
\bigskip \bigskip \bigskip
|
||||
Proyecto de Investigación:\\
|
||||
\bigskip \bigskip \bigskip
|
||||
\bigskip \bigskip \bigskip
|
||||
Sistemas Embebidos: Teoría, Implementación y Metodologías de Diseño}
|
||||
\author{Carlos Iván Camargo Bareño}
|
||||
|
||||
\maketitle
|
||||
|
||||
\newpage
|
||||
\thispagestyle{empty}
|
||||
\parindent0pt
|
||||
{\scshape Informe Final}\\
|
||||
Sistemas Embebidos: Teoría, Implementación y Metodologías de Diseñ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}
|
@ -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
|
||||
|
||||
|
@ -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.
@ -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)
|
||||
|
@ -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;
|
||||
}
|
||||
|
@ -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)
|
||||
|
Loading…
Reference in New Issue
Block a user