Parece que compilar el gcc 4.1.1 es algo molesto, sin embargo existe el AVR-Wiki con instrucciones bastante agradables de como compilar e incluso un script para compilar todo el tool chain.
Por mi parte prefiero hacer todo a mano, pero pues es una bonita alternativa.
Dos set de parches importantes para utilizar el AT90USB128:
http://www.freebsd.org/cgi/cvsweb.cgi/ports/devel/avr-gcc/files/
http://www.freebsd.org/cgi/cvsweb.cgi/ports/devel/avr-binutils/files/
EOT
Bien, por fin voy a trabajar un poco con USB y AVR.
El AT90USB128 Hasta ahora es una versi’on muy similar al ATMega128 pero se sacrifican algunos modulos funcionales por el controlador USB. El que estoy usando viene en empaquetado QFN64 algo molesto para soldar en el prototipo pero se gana algo de espacio en el PCB a la hora de hacer el final. Es pin a pin compatible con otras versiones de AVR de 64 pines, pero no con el ATMega128 para la programaci’on ISP pues el ATMega128 me consta que hace algunos cambio para esta programaci’on y en este chip estos pines los de la USART0 se utilizan para el driver USB.
Mi versi’on antigua del UISP reconocio el chip como un ATMEGA103 alike, la versi’on CVS lo reconoce como tal, revise el c’odigo fuente del programador e hice unas actualizaciones para que le pusiera bien el nombre y lo tratara como un ATMEGA128 internamente, y con las correcciones en los tamagnos. Las pruebas posteriores han indicado que no hace falta hacer mayores cambios al programador para que funcione. Escribir/leer fusibles, flash y eeprom ha sido exitoso hasta ahora.
Una vez superada esta etapa que me preocupaba sobre las otras, voy a probar GCC 4.1.1 para AVR y Binutils 2.17 y AVR-LIBC CVS por que revisando los changelogs y los fuentes, parece que tiene ya soporte con nombre para el at90usb128.
En unas horas que termine la experimentaci’on har’e un informe de que cambios hay con respecto a el tutorial anterior sobre el tool chain AVR.
EOT
Distcc, TOL Awards ?, y me *** la board
Como me urge tener la m\’aquina a sacrificar m\’as plata del viaje a Italia -_-
\end{rant}
\begin{new}
Hoy descubri que estoy nominado como el blog m\’as \~no\~no de la TOL.
Voten por mi XD
\end{new}
\begin{log}
Bueno ahora tengo como pasatiempo compilar gcc,glibc,binutils, kernel y hacer linux from sratch para las nuevas plataformas de desarrollo que los nuevos proyectos exigen.
Como este pasatiempo es sumamente divertido y variado, decid\’i hacerme un favor y configurar en mis maquinitas el distcc para hacerlo un poco menos divertido.
Esto no es nuevo de hecho ya lo hab\’ia hecho antes pero me di cuenta que no tenia en log y me toco buscar en la documentaci\’on nuevamente, para evitar futuros inconvenientes:
Distcc es un programa que permite distribuir la carga de la compilaci\’on en diferentes computadores a traves de la red.
Slack ya tiene instalado el distcc por lo que me importa poco esta parte y sin embargo, es poco relevante.
La configuraci\’on se realiza por m\’aquina que va a recibir pedazos de la compilaci\’on.
\begin{code}
/usr/bin/distccd –daemon –user nobody -a 192.168.1.0/24 –log-file /var/log/distccd.log
\end{code}
Se pueden recibir compilaciones de toda una subred o de un cliente en especial, me interesa una subred para poder compilar desde diferentes terminales.
Esa es toda la “configuraci\’on” necesaria para cada m\’aquina que va a recibir tareas.
Por otra parte si se trata de cross-compilers, como en mi caso, debe estar disponible el kit completo en cada m\’aquina que va a realizar compilaci\’on.
En la m\’aquina principal de compilaci\’on la tarea es:
\begin{code}
export CC=distcc
export DISTCC_HOSTS=”host1 host2 … hostn”
alias make=’make -jn*3+1 # donde n es el n\’umero de m\’aquinas disponibles
\end{code}
Luego de esto, la mayoria de compilaciones con y sin autotools funcionan en el “farm”, sin embargo a veces toca editar los Makefiles y/o otros scripts de compilaci\’on para asegurarse que hace uso del “farm”.
Algo que me toco hacer para asegurarme que make siempre usara todo el farm:
\begin{code}
mv make make_orig
make:
#!/bin/sh
/usr/bin/make_orig -j(n*3+1) $*
EOF
chmod 755 make
\end{code}
Es sucio, se ve feo, pero funciona.
Si se trata de cross-compile, o si no se trata de gcc, se llama distcc seguido del nombre del compilador que se va a usar.
Por si no se noto al principio: Odio tener que compilar la herramientas b\’asicas del sistema y odio a\’un m\’as cuando tengo que hacer linux from scratch, pero me persigue…
\end{log}
\end{post}
Por otro lado Diffie un desarrollador de dropline-gnome se encarga de Xorg 7.0 y de XGL en distribución binaria. A Diffie se le encuentra facilmente en los foros de Dropline GNOME.
La tarea se resume en:
En general eso es suficiente, sin embargo las librerias MESA de NVIDIA y que Dropline colisionan un poco a la hora de cargar Xgl server y el WM Compiz, por que cada uno quire usar una en particular. Al final de buscar por los foros se me ocurrio solucionar el problema de la siguiente forma:
Listing startxgl.sh
#!/bin/bash
LIBGL1=/usr/lib/libGL.so.1.0.8178 #NVIDIA Lib Notese la version particular de mi driver de NVIDIA
LIBGL2=/usr/lib/libGL.so.1.2 # Dropline Mesa Lib
echo “>Starting XGL at Display: $1″
echo “========= XGL ============”
# nvidia
LD_PRELOAD=$LIBGL1 Xgl :$1 -ac -accel xv:fbo -accel glx:pbuffer &
# ati
#Xgl :1 -ac -accel glx:pbuffer -accel xv:pbuffer &
sleep 3
echo “======= COMPIZ ===========”
DISPLAY=:$1 LD_PRELOAD=$LIBGL2 LD_LIBRARY_PATH=/usr/lib compiz –replace decoration wobbly fade switcher minimize cube rotate zoom scale move resize place opacity &
sleep 3
echo “====== DECORATIONS =======”
DISPLAY=:$1 gnome-window-decorator &
sleep 3
echo “======= GNOME ============”
DISPLAY=:$1 gnome-session
EOF
Cosa que funciona a medias por que en mi opinión el LiveCD de Korora tiene un desempeño muy superior y menos “aritfacts” en la presentación.
Es bueno probarlo y saber que mi startx usual funciona aun con esta modificación, solo me daño las fuentes Artwiz que tendre que instalarlas otra vez.
Enlaces
EOT
La foto no esta centrada intencionalmente
Luego me mude y blogsome sugería utilizar codificación UTF-8 para los envíos y durante la mudanza aparecieron mezclas de codificaciones por lo que decidi investigar un poco el asunto y me encontre que quizá esa sería la solución que estaba buscando para mi bandera.
El resultado fue una migración total de mi entorno de trabajo de codificación ISO 8859-1 (Latin-1) a ISO 10646 Nivel 3 (UTF-8). A primera vista el cambio de codificación no resulta gran cosa, solo la aparición de la dichosa bandera, sin embargo como pueden ver en el screenshot, va mucho más allá, ahora mis terminales son mucho más poderosas de lo que eran anteriormente, con formulas matemáticas y mezclas de caracteres de diferentes lenguas.
EXTENDED BODY:
Básicamente toda la información necesaria para hacer la migración, o simplemente establecerse en UTF-8 esta en el siguiente enlace :
[UTF-8 and Unicode FAQ for Unix/GNU/Linux](http://www.cl.cam.ac.uk/~mgk25/unicode.html)
De todas formas el soporte para UTF-8 Bajo GNU/Linux-CLI ha sido poco menos que perfecto por lo que el cambio ha sido completamente satisfactorio.
Para empezar la migración para X11, aún no he probado en la consola plana, hace falta :
Conseguir estas fuentes puede ser complicado ya que las opciones no son muchas y son colecciones son bastante tradicionales.
Sin embargo la gamma disponible para mi resulta bastante satisfactoria.
Por ahora la fuente que he escogido para mis terminales es:
-Misc-Fixed-Medium-R-Normal–18-120-100-100-C-90-ISO10646-1
Que seguramente esta disponible en casi toda distribución reciente de Xorg.
Como dije la gran mayoria de programas en GNU soportan UTF-8 así que se reduce a configurarlos. Con la mayoria de los programas de CLI no es nisiquiera necesario configurarlos ya que la terminal es quien se encarga de interpretar los caracteres. Por otra parte los editores si es conveniente configurarlos.
Una lista de programas que soportan UTF-8 esta en el enlace anterior, por lo que no me extiendo.
Mi terminal favorita aterm fue reemplazada por unicode-rxvt; que hasta ahora se ha comportado igual y mejor que aterm.
xterm tambien soporta UTF-8, sin embargo es posible que tenga que ser parchado el código fuente.
La configuración de emuladores de terminal se puede dar en distintas partes como parametros en la llamada al emulador o como parametros en el Xresources o .Xresources, dependiendo hasta que punto se desea realizar la migración.
Voy a dejar este envio incompleto por que me da pereza terminarlo en este punto ya que lo tengo atrasado hace mucho tiempo, solo me queda decir :
Espero que lo poco que esta les sea útil.
EOT
Recientemente decidi que debia utilizarla completamente y compre un pequeño juego de sonido 5.1.
Para hacer funcionar todos los canles con ALSA resulto algo cercado a trivial solo que es tan tonto que no se espera:
$aplay -Dplug:surround51 archivo_de_6_canales.wav
Encontre algunos WAV de 6 Canales con los que probar y todo va de maravilla hasta este punto.
Pero existe un grave problema!! el 99.9% de mis Mp3/Ogg/FLAC/MUSE son de dos canales exceptuando algunas canciones que Herulor me paso (Sailormoon PST Versión Español, Con P de pirata).
| M | T | W | T | F | S | S |
|---|---|---|---|---|---|---|
| « Jan | ||||||
| 1 | ||||||
| 2 | 3 | 4 | 5 | 6 | 7 | 8 |
| 9 | 10 | 11 | 12 | 13 | 14 | 15 |
| 16 | 17 | 18 | 19 | 20 | 21 | 22 |
| 23 | 24 | 25 | 26 | 27 | 28 | 29 |
| 30 | ||||||