Última semana

Hemos estado yendo todos los días al laboratorio, pero no nos ha dado tiempo a integrar todo.
Los filtros parece que no estaban preparados, y nos daba un segmentation fault al intentar que funcionase todo junto. hemos estado varias horas probando cosas e intentando encontrar la fuente del error pero no nos ha dado tiempo a encontrarlo.
Estuvimos hasta 1 minuto antes de las presentaciones de las practicas intentando arreglarlo, y al final hicimos un video corto con el móvil de algunos módulos funcionando por separado, aun que con las prisas ha quedado un video cutre, en el que se aprecia poco la funcionalidad de cada módulo.

http://www.youtube.com/watch?v=ZJaozARW4nI

Sesión 21

Hemos comprobado que funciona el SW y HW de los LEDs aun que hemos estado un rato intentando deducir por que se encendían los que no tenían que encenderse----> el enunciado de la práctica estaba mal.

Por otro lado nos hemos dado cuenta de que las interrupciones iban lentas debido a los printk(), sin ellos van perfectas.

Con lo cual nuestro objetivo en la práctica se ha cumplido. Ahora falta la integración con la otra pareja.

Sesiones 19,20

En estos dos días hemos conseguido que funcione más o menos todo con la salvedad de que las interrupciones no se generan a la frecuencia que deberían.
Y a parte aún no hemos probado el hardware de la matriz de LEDs. Nos ha llevado bastante tiempo soldar todo y poner los cables correctamente para dicho hardware. Aquí se puede ver como ha quedado (nos hemos valido de una placa de puntos para las conexiones):

El problema ahora reside básicamente en integrar todo con la otra pareja (Carlos y Jorge).




Otra cosa que no había comentado, es que el error que nos daba el ADC, era debido a la placa 9441, (la verde que se aprecia en la foto) que nos servía como interfaz para la comunicación con el ordenador.
Así que hemos tenido que recurrir a una conexión por ethernet con la placa, valiedonos de un pequeño servidor FTP para la transferencia de archivos.

Sesión 18

Hoy hemos estado varias horas en el laboratorio y hemos hecho principalmente 2 cosas:

1- Soldar el hardware de la matriz de LEDs
2- Reestructurar un poco los driver, de tal manera que para hacer la lectura del ADC no haya que pasar por el plano de usuario, sino que el driver de interrupciones recurra al del ADC para efectuar la lectura.
El programa no acaba de funcionar, esperamos mañana conseguir que funcione.

El viernes hemos quedado con la otra pareja para unificar la practica así que a ver si mañana funciona.

Sesiones 15,16,17.

Esta semana hemos ido tres dias al laboratorio.

El Martes fue bastante frustrante: aún no conseguíamos que funcionase el ADC. Estuvimos 1h y media con nuestro tutor intentando solucionar el problema ( siempre leía el valor FFF7FFFF).
Después de no conseguir nada en toda la mañana Álvaro nos recomendo centrarnos en lo demás y el buscaría el problema del ADC.

El Jueves nos centramos en las interrupciones y los LEDs.
-En cuanto a las interrupciones, tuvimos que "buscar teoría" en internet ya que nosotros no tenemos ninguna experiencia con previa con drivers. Después de un rato conseguimos más o menos entender como funcionaba el manejador de interrupciones: es una forma de "instalar" una fuente de interrupción, hacer que el sistema sea sensible a ella y definir una rutina de atención.
Aún así nos quedaron algunas dudas.
-En cuanto a los LEDs, estuvimos mirando los diversos manuales y no acabábamos de comprender del todo como funcionaba el interfaz de entrada/salida.
Por un lado hay registros del EP9301 (chip) y por otro lado de la TS7400 (la placa). Al parecer había varios registros que tocaban las mismas cosas. Como no lo teníamos muy claro lo que hicimos fue programar el driver usando los registros del EP9301.
El objetivo básicamente era implementar una función de usuario "enciendeLeds( int banda, int nivel)" que encendiese los leds correspondientes a esa banda y ese nivel(utilizando el driver correspondiente).
Estuvimos un buen rato pensando como pasarle la banda de ganancia y el nivel de energía al driver desde la aplicación de usuario. Finalmente conseguimos terminar el driver aun que aún no sabíamos si habíamos usado los registros correctos.

El viernes descubrimos que debíamos usar los registros de la TS7400 para entrada/salida. Tuvimos que modificar el driver e investigar acerca de la función "write(...)" ya que nos daba un error al ejecutarla.
También estuvimos pensando como conectar el hardware con la matriz de LEDs, ya que todos los pines de la placa están muy juntos y además hay una pequeña placa para facilitar la conexión con el ordenador que los tapa (como se puede apreciar en la foto de la placa que subimos hace unas semanas).
Ideamos una forma utilizando una "placa auxiliar" para sacar las lineas, aún que todavia no la hemos implementado.
En cuanto a las interrupciones, conseguimos solucionar las dudas que teníamos y hemos terminado el driver en casa.

Vamos bastante retrasados así que este martes esperamos que funcionen las interrupciones y que no nos lleve mucho tiempo conectar la matriz de LEDs con el sistema que hemos ideado.
Respecto al ADC, Álvaro nos ha dicho que ha encontrado el problema así que esperamos hacer que funcione también.

Un esquema general:

Sesión 14.

Hoy hemos estado investigando como implementar el vúmetro y hemos planeado como codificar el driver y la aplicación de usuario correspondiente.
Utilizaremos la interfaz GPIO (general purpose input/output). Por lo que hemos pensado no será muy difícil implementarlo: sólo habrá que configurar los registros PxDDR y enviar los datos por los PxDR.
Emplearemos el puerto F (3 bits) para seleccionar la banda (filas), y el puerto A (8 bits) para indicar el nivel de energía (columnas).
Esperamos no tener problemas de mapeado también con estos registros.

Sesiones 11,12,13.

La semana pasada hemos ido 3 dias laboratorio, sin embargo no hemos conseguido solucionar los problemas con el mapeado.
Por lo visto, la rutina descrita en la entrada anterior no asigna las direcciones correctas a los registros.
He aquí una captura de lo que creemos que es el problema:

La dirección del registro ADC RESULT debería ser: 0x8090008
Y como se puede apreciar en la captura, al hacer el remapeo le asigna la dirección 0xD4047008

Hemos estado muy bloqueados, así que hemos optado por ir haciendo lo relacionado con los LEDs y las interrupciones hasta que nuestro tutor pueda ayudarnos con el ADC.
Vamos bastante retrasados así que esperamos poder solucionar los problemas de mapeado pronto.

Sesión 10.

Por ahora no hemos conseguido solventar el error

Por lo visto el error se debe a esto: El EP9302 es un integrado que

incluye el ARM9 y algunos componentes adicionales. Pues bien, en el

Sistema Operativo, hay algunos componentes del EP9302 no están mapeados en memoria. Para poder mapearlos en memoria a nivel de drivernos han comentado que hay que seguir este tipo de estructura:

DIO_DIR7 0xDIRECCION 

//Definir los buffer 

 volatile char *ptr_1; 

//comprobar disponibilidad 

if(check_mem_region(DIO_DIR7, 1)) {               printk("DUMB: espacio de memoria en uso: DIO_DIR07\n");                    return -EBUSY;       } 

//Tomar memoriarequest_mem_region(DIO_DIR7, 1, "dumb_driver_07");  

     ptr_1 = __ioremap(DIO_DIR7, 1, 0); 

printk("dumb: ptr_1 remap = %p\n", ptr_1);

 //Dar valor 

 ptr_1[0] = 0xAA; 

 // Salir 

 release_mem_region(DIO_DIR7, 1);

Sin embargo, hemos desarrollado esa estructura para el driver y nos sigue dando exactamente el mismo error.

Aún seguimos en el laboratorio, pero sin ayuda, no creo que consigamos avanzar.

He aqui una foto del problema (en el log):

Sesión 9

Ha sido una de las sesiones menos productivas. Hemos descubierto que el driver del ADC no nos funciona, después de conectarle un voltaje a la entrada. A lo que dejamos hecho en la practica anterior faltaba asignarle el driver a su archivo:
"mknod   /dev/adc  c  70  0"
Al parecer cuando intentamos acceder a un registro desde el driver --> segmentation fault.
Hemos visto el log, y pone algo del estilo de "kernel paging error".
Como Álvaro no estaba para ayudarnos, nos hemos dedicado ha hacer el driver del Timer y a pensar como estructurar el driver/aplicación de interrupciones.

Esperamos arreglar esto pronto.

Sesión 8.

Bueno, la verdad es que ha sido una mañana en la que hemos aprendido bastante.
Hemos estado al principio repasando un poco todo lo de controladores y estudiando uno que nos habían proporcionado hecho (aun que era solo para los LEDs rojo y verde de la placa). Cuando hemos conseguido entenderlo todo nos hemos puesto manos a la obra para hacer nuestro propio controlador (el del ADC).
La verdad es que al final ha sido más facil de lo que pensábamos aun que hemos tenido que llamar a nuestro tutor para un par de cosas:
a) El primer problema era qué funciones del ADC meter en el controlador, y qué meter en la aplicación de usuario.
Álvaro nos ha comentado que esto está un poco en mano del programador y lo hemos hecho como nos ha parecido (aun que el nos ha dado el visto bueno).
b) El otro problema era que los los controladores solo se comunican con la aplicación mediante "char" y el registro de datos del ADC era de 12 bits, con lo cual hemos tenido que dividir el valor leido en 2 valores, y mandarselo a la aplicación en un buffer (buf[0] , buf[1]).
La aplicación a su ver tenía que reconvertirlo a un numero de 12 bits y calcular la tensión a la que equivale.

Finalmente hemos conseguido crear el controlador. Lo hemos compilado y cargado en la placa, así como el ejecutable de la aplicación.
El problema es que no nos dio tiempo a comprobar que funcionaba todo conectando un voltaje al pin del ADC, pero el programa se ejecutaba correctamente hasta el punto en el que tenía que leer el registro de datos del ADC (comprobado con printf y printk), lo cual es esperanzador.

Según nos han contado,una vez haces un driver los demás siguen el mismo esquema y todo te es más fácil, así que esperamos avanzar rápido (ya que las interrupciones estaban practicamente programadas para "micro desnudo" y solo tenemos que adaptarlas con un driver al sistema operativo ).

Clase de controladores y "Sesión 7".

Hemos tenido la clase de controladores con nuestro tutor esta mañana.
Básicamente hay dos opciones para programar un micro:
1-"Desnudo", es decir, tocando directamente los registros necesarios y programando sin nada mas "debajo".
2-Utilizando un sistema operativo y programando lo necesario: drivers (en nuestro caso de ADC, interrupciones, y GPIO (in/out)) y la aplicación en sí.
La placa tiene instalado un sistema Linux básico sobre el que pretendemos cargar los driver que creemos.
La verdad es que es meterse en un mundo más difícil, pero nos parece bastante interesante entender como funcionan y relacionar todas las capas de un sistema.
Es posible que nos quite tiempo para hacer una practica con más "extras" pero creemos que merece la pena. Ha sido una clase con muchos conceptos y aún no hemos asimilado todos: un nuevo Makefile, cargar y registrar controladores, funciones del controlador, mensajes del kernel, como implementar con aplicaciones de usuario, etc... Tendremos que dedicarle tiempo.
Os dejo un par de capturas para ilustrar en que "nivel" se encuentran los controladores (basicamente entre el kernel y la plataforma):

Después de la clase, hemos ido al laboratorio y conseguido cargar un controlador de prueba.
Además también hemos descubierto que aún no podemos probar el ADC ni las interrupciones(que ya tenemos hechos) ya que hay que acceder a registros a los que solo tiene acceso el kernel (es decir, tendremos que acceder mediante los drivers) y por eso en la sesión anterior nos daba un "segmentation fault" al intentar ejecutar el programa en la placa.

Esperemos que merezca la pena la elección, por ahora estamos un poco perdidos con esto de los driver, pero todo es ponerse.

Reunión y Sesión 6

Hoy hemos tenido por un lado una reunión con nuestro tutor y la otra pareja que hace esta práctica, y por otro lado hemos estado 3 horas en el laboratorio.

En la reunión nos hemos dividido un poco el trabajo "básico" para avanzar más rápido y tener más tiempo para mejoras.
A nosotros nos ha tocado desarrollar el ADC, interrupciones y LEDs.
También nos ha comentado el tutor que en vez de hacer la memoria, podríamos hacer los "tutoriales" de cada parte del micro (parecidos a los que existen para el ColdFire) y hemos aceptado.
Así mismo también hemos decidido "mejorar" el sistema  programando sobre un sistema operativo (es decir, con drivers) en vez de programar sobre el "micro desnudo".
Hemos quedado las dos parejas mañana con nuestro tutor para que nos de una clase de 1h de lo que tenemos que saber sobre drivers. ha sido decisión nuestra el hacerlo con drivers para aprender más (pues ya nos hemos estado pegando con el "micro desnudo" hasta ahora, y lo hemos entendido bastante bien).
Espero que esta decisión no sea un lastre a lo largo del resto del semestre.
Por último, también hemos definido unos hitos más concretos para cada pareja.

Después hemos estado en el laboratorio unas 3 horas. Hemos completado el archivo relacionado con el ADC (ADC.c) y hemos investigado un poco acerca de como implementar lo relacionado con los LEDs (mediante los pins del GPIO (entrada/salida)).
Sin embargo hemos tenido 2 problemas:
1.- A la hora de compilar el problema completo nos ha dado un error en un punto en el que antes no nos lo daba (al llamar al método "lectura_adc()" como rutina de atención a la interrupción).
2.-Habiendo omitido el error anteriormente nombrado (poniendo le linea que daba error como comentario) hemos cargado el ejecutable en el micro, y al intentar ejecutarlo nos ha dado "segmentation fail".

Vamos a intentar subsanar estos errores en los días sucesivos, y mañana comentaremos como ha ido la clase de drivers.

Edit: El segmentation fail era por intentar acceder con aplicaciones de usuario a registros a los que solo tiene acceso el kernel. Tendremos que acceder a ellos con drivers.

Nota (Sesión 4 y 5)

Al final hemos conseguido que compile con ayuda de alvaro.
Habia que cambiar algunas cosas de programación que no sabiamos.

Sesión 4 y 5

Esta semana hemos venido 2 dias la laboratorio y hemos estado entendiendo y configurando las interrupciones y los timer.
La verdad es que nos ha costado entender como funcionaba todo.
Nos hemos ayudado de parte de un código para interrupciones  que aparecía en un foro de ARM.
La mayoría del tiempo hemos estado intentando entender el cógido y pensando como escribir el nuestro.
También nos ha quitado bastante tiempo buscar y entender los registros de configuración.

A día de hoy hemos conseguido aclarar casi todas las dudas que teníamos y hemos dejado el programa bastante estructurado (aun que nos sigue dando algún error de compilación y por tanto no hemos probado aún que funcione).
La verdad es que esta semana le hemos dedicado mucho tiempo a la asignatura, pero espero que la fluidez que hemos cogido en configurar (y buscar en la documentación) registros y programar nos ayude a ir mas rápido en los días sucesivos.

Sesión 2-3

Esta semana hemos venido dos días al laboratorio del departamento:

El primer día nos centramos en comprender la comunicación con la placa, en saber manejar la terminal para compilar cruzado(utilizar el Makefile, comandos, etc...) y en estructurar el programa para hacer en casa los .c y los .h necesarios (implementando las funciones solo con un printf).
La verdad es que perdimos bastante tiempo en "tonterias" por ser la primera vez y tuvimos que recurrir a nuestro tutor (Álvaro Araujo) varias veces, por ejemplo: no teníamos permisos para ejecutar el programa "minicom" y estuvimos un rato intentando abrirlo de diversas formas hasta que Álvaro nos dijo que era por eso.
Otro ejemplo es que no sabíamos que para enviar datos a la placa no sólo había que seleccionar "Send Files" (comando del minicom) sino que además antes había que ejecutar el comando "lrz".
También nos dio tiempo a pensar un poco como estructurar el programa (hablando de .c y .h)  y a hacer un par de .c
En resumen, un día en el que no hicimos mucho pero aprendimos bastante.
Durante esta semana hemos elaborado en casa los .c y .h restantes.

Hoy, (segundo día) hemos comprobado que nos compilaba el programa (creando un ejecutable llamado main).
Por alguna razón que desconocemos, al intentar ejecutar el minicom, nos vuelve a dar el mismo error que el primer día, pero el manos hoy no nos hace falta.

Por último, como Álvaro nos ha comentado que esta práctica está orientada a que otros alumnos la hagan otros años, hemos de decir que se necesita una "clase tutorial" para aprender:
-Los comandos básicos de la terminal (Linux).
-Cómo establecer la conexión con la placa.
-Cómo estructurar un programa en C (esquema general de .c y .h)

Os adjuntamos un esquema que hemos pensado para el programa, aun que estará sujeto a cambios, pero nos servirá para irlo desarrollando de forma ordenada.
Así mismo también adjuntamos un diagrama de las funciones de la placa sacado del manual:
(pulsar para ampliar)

Desarrollo del hito 1

Buenas tardes y bienvenidos al blog de Pino y Julio. En él vamos a hablar del desarrollo de nuestra práctica especial, tratándose en este caso, de la misma práctica que la normal pero utilizando otro micro. En este caso vamos a utilizar el ARM9.
Antes de nada hemos de comentar que nos decidimos por hacer esta práctica la semana pasada, con lo cual ya teníamos hecha la parte del "Menú". O eso creemos.
Nuestro hito consiste en elaborar un "esqueleto" del programa (crear los archivos .c y .h necesarios así como definir las funciones que contengan, pero sin desarrollarlas), un flujograma y este blog.
A día de hoy, hemos estado repasando un poco sobre C para saber cómo estructurar el programa.
Aún nos queda por investigar, pero pretendemos dejar hoy bastante hecho.

Aquí os dejamos una foto de la placa y algo del hardware externo que vamos a emplear: