Hola, ¿Cómo están?
Bienvenidos sean de nueva cuenta a este nuestro blog, donde yo escribo los debrayes y ustedes abuchean mis malos chistes n_n.
Como siempre, hay muchas cosas en el tintero digital que no encuentran el momento de ser plasmadas en estos finos y refinados pixeles. Sin embargo en esta ocasión he decidido pasar a saludar y compartir un poco de las cosas que se han cocinado en los últimos meses.
Thinclient (TC) Reloaded.
Empezamos esta ronda de debrayes dándole protagonismo a una vieja estrella de este blog, el Thinclient HP T5730 que estuvimos acondicionando el año pasado. Después de muchos tumbos, indecisiones y rezagos económicos decidimos dar el salto definitivo y probar en él todo el arsenal que tuvimos a nuestra disposición.
Uno de los primeros problemas que saltan a la vista al usar el TC es que en la actualidad disponer sólo de 1GB de memoria de almacenamiento interno son muy acotados para una computadora de propósito general. Si bien se puede aumentar la capacidad con dispositivos externos, para instalar un sistema operativo relativamente moderno se requiere de mayor capacidad. Para probar con medios de almacenamiento de mayor capacidad requerimos de un cable IDE de 44 pines, que además tenga conectores milimétricos, a diferencia de los cables IDE 40 convencionales que tienen conectores de décimas de pulgada.
Nos dimos la tarea de buscar un cable con las características adecuadas en la famosa "Plaza de la Tecnología" de la Ciudad de México, un lugar otrora conocido por ser la meca de la tecnología de cómputo en el país. Por desgracia no pudimos encontrar en ese sitio el cable adecuado, por lo que decidimos buscarlo en Mercado Libre. Ahí encontramos a un vendedor que ofrece una gran variedad de cables "poco convencionales" y entre sus publicaciones vimos unos cables IDE 44 hembra - hembra (justo de los que necesitábamos) por unos módicos $245.00 MXN con el envío incluido. En realidad no es un precio tan disparatado considerando que es un tipo de cable difícil de conseguir, pero el precio del cable estaba cerca de ser el 50% del precio pagado por del TC, por lo que decidimos evitar la compra del cable y ponernos manos a la obra.
Conseguimos unos pines hembra milimétricos en las tiendas de electrónica de la calle de República del Salvador de la Ciudad de México y nos dimos a la tarea de confeccionar un cable IDE44 casero. Paralelamente nuestro amigo
Dash "Shingo" Bandit nos apoyó en comprar desde China un adaptador de memorias SD a IDE44. Este adaptador es muy popular en internet entre los círculos de retrocomputación, pues los discos duros IDE en buen estado ya escasean. Por no mencionar discos duros IDE nuevos, que son virtualmente inexistentes en la actualidad.
 |
| Este adaptador también es ideal para sistemas embebidos. |
Con ayuda de ese adaptador se pueden rehabilitar computadoras antiguas sin muchos inconvenientes, pues la capacidad actual de las memorias SD suele equiparar o incluso superar las capacidades de disco duro habituales de finales de la década de 1990.
Pues bien, una vez que arribó el adaptador lo conectamos con nuestro cable IDE44 casero al TC, encendimos el TC, entramos al BIOS y... Nada... Pese a que el LED indicador del adaptador estaba encendido, en el BIOS no fue reconocida ninguna unidad. En este punto los posibles culpables eran un defecto de fabricación del adaptador o un defecto de fabricación del cable casero. Probamos el adaptador en una computadora de sobremesa (con un adaptador IDE40 a IDE44) y el adaptador fue reconocido sin inconvenientes. En este punto, el presunto culpable era el cable IDE44 casero, por lo que conectamos una memoria Compact Flash (CF) Sandisk de 8 GB con un adaptador CF a IDE44 al TC y la unidad de memoria fue reconocida sin inconvenientes. Después probamos con un disco duro IDE de laptop e incluso pudimos instalarle Windows XP sin problemas. Después de esto pudimos constatar que el culpable no era ninguno de los presuntos responsables, sino el propio TC que se negó a reconocer el adaptador.
Un detalle negativo del cable casero es que quedó con un perfil muy alto, por lo que no se puede colocar un disco duro sin que estorbe con la colocación de la tapa con ventilador que se hizo en el pasado. Así que decidimos dejar la expansión del almacenamiento para otra oportunidad. Sin embargo la idea de colocar de forma definitiva el Turion X2 64 en el TC nunca dejó de rondar por nuestras mentes, por lo que decidimos hacer los ajustes pertinentes. El principal obstáculo era conseguir una fuente de alimentación de 12[V] que tuviere una buena potencia y fiabilidad. Existen fuentes de alimentación para tiras LED que en la etiqueta presumen de excelentes prestaciones, sin embargo hemos aprendido a desconfiar de ellas ya que en muchas ocasiones las características eléctricas no coinciden con lo que la etiqueta marca. Además esas fuentes suelen ser de marcas genéricas o poco reconocidas, por lo que no tendremos ninguna garantía de su durabilidad.
Decidimos buscar alternativas y entre ellas la mejor fue modificar ligeramente una fuente de alimentación para Xbox 360, que entrega el voltaje correcto 12[V] y una potencia más que suficiente (podríamos incluso decir sobrada para esta aplicación). La fuente de alimentación debe ser modificada, en primer lugar se debe colocar un cable con el conector adecuado para conectarla al TC y en segundo lugar se debe conectar la terminal "Sense" con "5VSB" usando una resistencia de 1[kOhm] para que la fuente encienda en cuanto reciba alimentación. La incorporación de la resistencia no es necesaria, pero le hemos usado para limitar la corriente en caso de alguna falla. La ventaja de las fuentes de alimentación originales de Xbox 360 es que son de muy buena calidad, tienen marcados en la placa de circuito los nombres de las señales, componentes y terminales. Además cuentan con refrigeración activa que contribuye a su estabilidad.
Instalamos el procesador Turion X2 64 en el TC y comenzamos a exigir al equipo con diferentes emuladores y juegos para corroborar que tanto la fuente de alimentación como el ventilador fueran capaces de mantener el equipo en condiciones óptimas de operación. Y pues bien, los resultados son que la fuente de alimentación funciona muy bien, sin forzarse ni calentarse. Mientras que en el aspecto de las temperaturas notamos que a plena carga obtuvimos unos picos de 58°C (para ambos núcleos activos) lo que representa un alza considerable en las temperaturas (antes eran 36°C con carga al tope) pero aún así se encuentran en un rango muy seguro de operación y podemos exigir al procesador sin poner en riesgo su integridad. Recordemos que los Turion X2 64 pueden operar a temperaturas de hasta 110°C, antes de que se apaguen debido a sus sistemas de protección.
Windows 7 vs Windows XP.
Hace tiempo estuvimos probando alternativas para darle funcionalidad a una laptop Dell Latitude D610. Se trata de una computadora orientada para usuarios empresariales del año 2005. En su tiempo era una computadora envidiable, pues tenía muy buen desempeño, un diseño muy cómodo y robusto. El problema con esa computadora es que el disco duro ya presentaba en el S.M.A.R.T. un mensaje de falla inminente y programas como el Crystal Disk Info ya lo marcaban como disco en mal estado. Y por desgracia en este caso nos encontramos en una situación similar a la vivida con el TC, en que los puertos de conexión de la laptop son IDE (tanto el del disco duro como el de la unidad lectora). Por fortuna existen unos adaptadores que tienen la forma de una unidad lectora para laptop que pueden alojar un disco duro en su interior.
El propósito principal de estos adaptadores es dotar de mayor capacidad de almacenamiento a las laptops, pero en nuestro caso lo utilizaremos con el doble propósito de reemplazar la unidad lectora (que estaba inservible) por un disco duro con interfaz SATA, lo que nos brindará una mayor flexibilidad para mantener funcional la computadora. Con la experiencia adquirida gracias al proyecto del TC, decidí cambiar el disco duro defectuoso por una memoria CF y colocar un viejo disco duro SATA en el adaptador. En esta configuración de hardware instalé Windows XP y las cosas funcionaron bien. Sin embargo tuve que emplear el disco duro SATA para otra computadora y la configuración se tuvo que revertir.
Con la laptop de nuevo en su estado inicial traté de instalarle Linux Mint sin éxito, pues el sistema se negó a instalarse debido a los errores reportados por el disco. Optamos entonces por instalar Windows 7 (edición de 32 bits) y la sorpresa fue mayúscula al percibir que la computadora respondía con mayor agilidad que con Windows XP. Cabe aclarar que la computadora cuenta con 2GB de RAM. Sin lugar a dudas fue un resultado inesperado y que abre algunas posibilidades para exprimir aún más algunas computadoras algo viejas, pues Windows XP a pesar de ser un sistema consolidado y muy personalizable tiene el defecto de que ya no recibe actualizaciones de seguridad y las amenazas informáticas continúan apareciendo. Si se tiene un equipo "airgapped" (es decir, aislado sin acceso a redes) no hay inconveniente, pero si vamos a conectar el equipo a alguna red es preciso que se encuentre actualizado y con las configuraciones de seguridad pertinentes para que no se convierta en un vector de entrada para infecciones o ataques desde redes externas. Por ese motivo fue que cuando creamos la máquina virtual de Windows 98 en una entrada anterior del blog no le configuramos interfaces de red ni de carpetas compartidas, pues la máquina virtual con Windows 98 podría representar una brecha de seguridad.
Posteriormente las cosas se han ido acomodando de forma casi involuntaria, ya que conseguimos un disco duro SATA de 2.5 pulgadas pero de 11 mm de espesor, que no es posible colocar en la mayoría de las laptops pero que calza en el adaptador de forma perfecta. En ese disco instalamos Linux Mint y podemos darle uso cotidiano a una computadora que aún es bastante útil para cargas de trabajo ligeras o para hacer proyectos que no requieran de mucha potencia de cómputo, además de que con los tres sistemas operativos instalados nos permite mucha flexibilidad para probar programas.
La burra vuelve al trigo por enésima vez.
Recientemente hemos estado jugando con el PS3 y nos hemos topado de nueva cuenta con una realidad, y es que los accesorios para consolas originales tienen unos precios que rayan en lo ofensivo. Los controles de PS3 en particular se han vuelto muy escasos pues ya no se producen y sus precios en la actualidad son desorbitados. En el pasado existieron controles de empresas como Madcatz, Hori, Nyko o PowerA que trataban de innovar en la forma del control para brindar una mayor ergonomía y comodidad, pero incluso ahora esas alternativas son caras y difíciles de conseguir, más aún si lo que se requiere es que el control sea inalámbrico. Existen opciones genéricas muy baratas que se limitan a imitar las formas y funcionalidad de los controles originales Sony y funcionan bien, aunque se sienten un poco raro al tacto y la duración de la carga de la batería es muy escasa.
Por otra parte tenemos un viejo control inalámbrico para PS2 modelo Chameleon de la marca Pelican (la cual ya no existe en la actualidad) que aún funciona a pesar de los años y las malas reparaciones a las que lo hemos sometido. Es un control que a pesar de sus acabados "chafas" y sus materiales de dudosa calidad tiene un tacto cómodo y un rendimiento de baterías simplemente irreal para los estándares modernos.
 |
| Un control muy viejo, pero con una autonomía excepcional. |
Decidimos aprovechar el adaptador de controles de PS2 a Xbox 360 y PS3 que compramos hace unos años para usar ese control en el PS3. Y aunque en apariencia funcionaba bien comenzamos a percibir algunos comportamientos bastante extraños en algunos juegos, en particular el botón R2 era detectado como si se presionara de forma intermitente (como si tuviere la función de autodisparo), pero si se presionaba el botón, se comportaba como si estuviere sin presionar. Este comportamiento tiene sentido debido a que el botón R2 es el último botón en el reporte que el control manda indicando el estado de los botones. Además recordemos que en el protocolo de comunicación de los controles de PS2 los datos se envían con el bit más significativo hasta el final, por lo que si la comunicación no es del todo sólida y se pierde el último bit la mitad de las ocasiones, notaremos que el comportamiento del botón es precisamente intermitente.
La opción como siempre, fue recurrir a códigos viejos y un AVR para resolver la situación. Estuvimos probando y portando códigos viejos, que en su momento se usaron para hacer pruebas de ese mismo control con el Dreamcast y con la computadora pero en esta ocasión no funcionaban de forma satisfactoria. Pudimos rescatar un código funcional de un viejo respaldo, portarlo a uno de los microcontroladores con los que contamos actualmente y hacerlo funcionar con ese control en específico, ya que los controles originales o de otras marcas no funcionan con ese código.
Así también decidimos colocarle la funcionalidad del botón guía (o botón PS) al presionar de forma simultánea los botones SELECT y START. Hay algunos juegos que usan esa combinación, sin embargo son los menos y se usa de forma muy esporádica. Además el propio control usa esa combinación de botones para apagarse si se mantienen presionados por 5 segundos, por lo que es una combinación poco invasiva. Además hemos decidido probar algunos tips que hemos encontrado respecto a la implementación de la biblioteca VUSB en proyectos de bajo costo.
El principal debate respecto a la implementación de la biblioteca VUSB y uno de sus inconvenientes es la necesidad de limitar el voltaje de las líneas de datos (D+ y D-) a 3.3[V], cuando el voltaje de alimentacíón que provee el puerto USB es de 5[V]. En la página del proyecto VUSB proveen de tres alternativas para lidiar con ese dilema, las cuales son:
- Utilizar un regulador de voltaje de poco voltaje de caída (como los famosos AMS1117) para alimentar al AVR con 3.3[V] y mantener las líneas de datos en el nivel adecuado. Esto tiene como ventajas que las conmutaciones en los estados de las líneas de datos se realizan de forma más veloz y las señales son más limpias. La desventaja es que el consumo de corriente se eleva por el uso del regulador y que muchos AVR (sobretodo las piezas más viejas) pueden tener problemas para operar a las frecuencias necesarias por la biblioteca VUSB a un voltaje de 3.3[V].
- Utilizar un par de diodos rectificadores de silicio (como los famosos 1N4001) en serie para forzar una caída del voltaje de alimentación. La caída de voltaje a través de un diodo de silicio polarizado de forma directa es cercana a los 0.7[V], por lo que si se colocan dos diodos en serie la caída total de voltaje es de 1.4[V]. Reducir el voltaje a 3.6[V] suele ser suficiente para que el AVR se pueda comunicar de forma efectiva a través de USB. La desventaja es que no se tiene regulación y que se tiene que corroborar que en efecto la caída de voltaje a través de los diodos sea suficiente.
- Limitar el voltaje a través de las líneas de datos con diodos Zener de 3.6[V]. Esta alternativa es la que habiamos estado utilizando ya que a pesar de no ser la más barata, es la que en el papel se ve más segura, pues el AVR funciona a 5[V] y puede trabajar a su máxima velocidad sin inconvenientes. La desventaja es que las transiciones de voltaje en las líneas de datos son muy lentas, cosa que pasa desapercibida si no se cuenta con las herramientas adecuadas o con la información de las pruebas pertinentes.
- Una alternativa adicional que hemos visto en algunas páginas de internet y decidimos probar es la de colocar un LED rojo o verde en serie con la alimentación para bajar el voltaje a niveles cercanos a 3.3[V]. En teoría esta es la opción menos apropiada, pues además de que no hay regulación, los cambios en el consumo afectan la cantidad de voltaje que cae a través del LED, por lo que la potencia se encuentra variando de forma constante. Además se debe tener cuidado de no exigir mucha potencia, pues la mayoría de los LED rojos o verdes suelen soportar una corriente máxima de 20[mA]. Las ventajas de esta alternativa son que nos permite ahorrar en componentes, el LED tiene el doble propósito de acondicionar el voltaje e indicar el encendido del circuito y además, siendo francos, los AVR son microcontroladores de gama económica y en este caso no se le está encomendando una labor crítica como un soporte de vida o un sistema de seguridad.
Decidimos probar esta última variante para el adaptador que nos armamos y hasta el momento (40 horas de juego después) ha funcionado de forma adecuada la mayor parte del tiempo. En ocasiones hemos tenido problemas para que el adaptador sea reconocido de forma correcta, por lo que tenemos que intentar reconectarlo para que sea identificado por el PS3. Esta falla no se da siempre y por lo general al segundo o hasta tercer intento es reconocido y funciona con normalidad. Además existe la posibilidad de que esas fallas de conexión no se deban al LED, sino a algún error de programación, falla en el cable o en los conectores. De igual forma hemos probado con sesiónes largas de juego (en ocasiones de hasta seis horas continuas) sin que haya problemas.
La conclusión es que se trata de una alternativa bastante válida para hacer aún más económicos los proyectos, aunque si se pretende emplear para producción se tienen que probar las variables eléctricas pertinentes tanto del LED como del resto del circuito, para evitar estresar algún componente y comprometer la funcionalidad del circuito en el corto plazo.
En lo personal trataremos de emplear el adaptador lo más posible para poder hacer una evaluación del rendimiento de esta solución a largo plazo. En el caso de nuestro adaptador medimos una corriente en serie con el LED de 5[mA] y un voltaje en las terminales de alimentación del AVR de 2.8[V]. A pesar del bajo valor de voltaje el adaptador se mantiene funcionando a la perfección una vez que ha sido reconocido por la consola. En la computadora no hemos tenido inconvenientes para que el adaptador sea reconocido.
Como siempre, el código de este adaptador se encuentra
aquí.
Ha sido un placer saludarles de nuevo, estamos en contact!
