Se agregan algunos ejemplitos de matrices, aunque por ahora no muy útiles porque
no se pueden levantar automáticamente, pero sirve de ejemplo 'visual' para
dibujar en la interfaz gráfica.
Cliente con funcionalidad básica completa. El cliente tiene una interfaz de
línea de comandos que permite obtener y setear todos los valores básicos (delay,
pause, off y obtener la matriz). Además tiene una interfaz gráfica para dibujar
la matriz y enviarla (o recibirla).
Se implementa un sistema primitivo de 'locking' para los leds. Cada vez que se
lee o se escribe un registro de la placa de red, se deja de atender las
interrupciones del timer de los leds para evitar una condición de carrera del
puerto 2. También se hacen otros cambios pequeños:
* Se hace un cheque sobre el tamaño de la matriz que viene de la red.
* Se cambia el intervalo del timer de los leds (cuanto más grande menos
interrupciones se saltea). Hay algo más de trabajo por hacer en este área.
* Se corrige un bug en leds.asm, en algún momento se borró el .ds 1 que
reservaba memoria para curr_col, que estaba tomando 'prestado' el 1er byte de
la matriz (o peor, tomando un byte de vaya uno a saber dónde).
Actualiza protocolo para que concuerde con la nueva organización interna de la
matriz en el dispositivo. También saca el CRC y bit de paridad de la cabecera
porque UDP ya nos provee de un CRC del contenido del datagrama.
Integra leds con modulo de red. El programa está ahora recibiendo datos de la
red y poniéndolos en la matriz (a lo bruto, falta implementar bien el protocolo
para configurar nuestro dispositivo por red). Pero toda la funcionalidad
básica-básica está lista. De ahora en más es empezar a dejar algunas cosas más
prolijas (varias) y corregir algunos bugs.
Ejemplo completo del módulo de leds implementado en assembly y llamado desde un
programa en C. Está bastante prolijo y completo, e incluso incluye funciones
para escribir en los leds y para hacer testeo. Lo único que no hubo manera de
hacer es configurar el vector de interrupciones desde asm, porque se pisaba con
el de C, así que lejo esa parte solita al C (hay que incluir sólo la declaración
del ISR).
Nueva manejo de buffers, un poco más modular. El proyecto quedó como un echo
server de UDP en el puerto 9876, es decir, recibe un paquete y lo contesta con
el mismo contenido a quién lo envió.
Bugfixes:
1) Se arregla problema con paquetes con tamaño impar.
2) Se vuelve para atrás el cambio del OVW (estaba basado en el driver de Linux
que hace un manejo MUCHO más elegante del OVW porque puede darse el lujo de
usar mucha memoria =)
3) Se obtiene la MAC de la placa de forma un poco más elegante.
Arregla problema de la recepción de más de un paquete.
En realidad no arregla nada, porque el problema era no terminar de leer todos
los datos del DMA y los datos se leen sólo a modo de prueba, pero la necesidad
de leer completo un DMA será tenida en cuenta cuando se implemente el protocolo
nuestro (o mejor aún en el módulo de la DP8390).
La placa ya está recibiendo (es decir, recibiendo la placa y parseando Ethernet,
IP y UDP =), pero sigue habiendo algún problema que hace que al recibir el 2do
paquete los datos obtenidos del buffer no tengan sentido.
Ya ha surgido un problema similar y era por mal manejo de los buffers de la
placa, probablemente sea un bug similar.
También se separa la parte de los leds para simplificar su manejo y se agrega
código de debug (funciones de 'print' usando los leds =).
Primer intento de integración y creación del proyecto.
El programa es medio bobo, sólo recibe frames, los parsea (ethernet, ip, udp) y
muestra el payload de UDP. A pesar de esto no funciona, falta un poco de
debugging, pero como está basando en 2 grandes fragmentos que funcionaban por
separado, debería ser fácil ponerlo a andar.
Cambio el hack feo del retardo por un hack algo menos feo. Además de chequear
por el flag OVW me fijo si BNRY == CURR antes de resetear la placa.
Con esto anda como piña, la floodeo con todas las ganas y no se resetea nunca.
Seguían habiendo problemas al recibir varios paquetes seguidos, al parecer se
leía mal el ISR y eso provocaba que se resetea la placa sin que realmente haya
overflow del buffer. Con un asqueroso hack (poniendo un retardo antes de leer el
ISR _solo_ en ese lugar) parece mejorar considerablemente. Lo sigue haciendo,
pero MUY esporádicamente...
Primera implementación de Ethernet+IP+UDP. Falta el chequeo y cálculo de
checksum de IP (que aparentemente es obligatorio). La implementación se basa en
un par de funciones aún no implementadas que puede escribir y leer un byte de la
placa de red. Esa función probablemente haya que implementarla en ASM.
Por ahora no se implementa ARP e ICMP, porque no son estrictamente necesarios
para que el proyecto sea mínimamente funcional. De todas formas son altamente
deseables (en especial el ARP) y si queda tiempo la idea sería implementarlo.
Falta también, nuestro protocolo, que se monta sobre esto.
Bugfixes e integración del protocolo con la interfaz gráfica.
El cliente está terminado en cuanto a la funcionalidad pricipal (funcionalidad
vital básica =), pero faltan pulir varios detalles para que sea agradable de
usar.
Cambia el protocolo para que use CRC sólo para los datos, dejando en la cabecera
un bit de paridad para control de errores. Para este bit de paridad se usa uno
de los bits de las Variables.
Primer draft de la aplicación cliente.
Por ahora sólo responde a los eventos de dibujado. Falta hacer la parte de
cliente-servidor para que reciba y envie las cosas. En el futuro habrá que
extenderlo (o no?) para que se pueda cambiar el tamaño de la matriz (depende de
si llegamos a implementar esto en el dispositivo o no).
Agrego programa de prueba que muestra una matriz de 8x8 leds (conectados al
puerto 0) barriendola tipo gnuine perception. La parte de mostrar la matriz no
debería ser más que esto.
projects / z.facultad / 66.09 / etherled.git / log