Raspberry PI y arduino UNO

Resulta que me entero en la página de Arduino http://arduino.cc/es/Main/Buy que la tienda de un amigo aquí en Alcalá de Henares (Componentes Escobedos, http://www.electronicaalcala.net) es distribuidora de arduino y voy el martes a comprar uno…
Y no les queda ninguno… cuando me voy a ir desilusionado me dicen: si quieres tenemos una raspberry pi…
Coño!, resulta que tienen una, modelo B Versión 2 (512Mb de ram, 2 Usb, ethernet) y esta esperándome en el expositor… y ademas me prometen que al dia siguiente tendrán un arduino UNO V3 para mí.
Efectivamente, justo el día de San Valentín, tenía mi equipo completo para programar arduinos desde la raspberry pi.
Así empieza esta historia de ¿amor? entre una raspberry pi y un arduino UNO…

Para empezar a trabajar hay que conectar la raspberry e instalar el sistema operativo en la SD. Yo he usado una de 2Gb y el sistema operativo raspbian descargado de http://www.raspberrypi.org/downloads
Concretamente la versión http://downloads.raspberrypi.org/images/raspbian/2013-02-09-wheezy-raspbian/2013-02-09-wheezy-raspbian.zip
Como voy a cargar el sistema operativo en la SD desde Windows necesito el copiador de imágenes http://sourceforge.net/projects/win32diskimager/files/latest/download
Desde mi portatil Acer 5920 he tenido problemas para que me detecte la SD, he tenido que usar una versión vieja del Win32DiskImager.exe, http://learn-gdx.googlecode.com/files/win32diskimager-RELEASE-0.1-r15-win32.zip
Otras versiones pueden encontrarse aquí: http://sourceforge.net/projects/win32diskimager/files/Archive/

Descomprimir la imagen del Raspbian y copiarla a la SD mediante el Win32DiskImager.exe
Conectar la SD en la rasperry y alimentar… Aparece una pantalla de configuración del sistema operativo de la raspberry. Yo he cambiado pocas cosas:

Overscan -> no lo he tocado, disable (por defecto)
Configure_keyboard -> Cambiarlo: Generic 105 (mi caso)
Keyboard layout -> Other -> Spanish -> Spanish
Key to function as AltGr -> Right Alt (AltGr)
Compose Key -> Right Logo Key (mi caso)
Use Control+Alt+Backspace to terminate the X server -> TES
Change_pass: Las raspberry se estan haciendo muy populares y si se usa la con conexion a internet mejor cambiarlo.
Change_locale -> cambiarlo a: es_ES.UTF-8 UTF-8, por defecto viene en_GB_UTF-8 UTF-8
Default Locale for the sysstem enviroment -> es_ES.UTF-8
Change Timezone -> Geographic area -> Europe
Time Zone -> Madrid
Memory Split -> No lo he tocado, 64 (por defecto)
Overclock -> No lo he tocado.
ssh -> Enable. Opción muy interesante!!!
boot_behaviour -> no lo he tocado, por defecto: NO (Me gusta mas que arranque en linea de comandos, luego puedo arrancar el entorno gráfico con startx).
update -> Si, como ya tengo la conexión a internet lista por cable actualizo ahora el sistema…
Expand_rootfs
Finish

Se reinicia el sistema y aparecerá el prompt. Nos logeamos como usuario “pi”, el password por defecto es “raspberry”, si no lo hemos cambiado antes:
Pi puede hacer sudo sin password, es la mejor opción en vez de usar el usuario root.
El superusuario root no tiene password por defecto, mejor ponerlo con “sudo passwd root”.

También podemos actualizar ahora el sistema con “sudo apt-get update”

Este es el entorno de desarrollo minimalista para arduino, basado en raspberry pi:

Estación de trabajo para arduino raspberry con raspberry pi

Para instalar el entorno arduino basta con hacer “sudo apt-get install arduino”. Esto instalará el entorno versión 1.0.1 (a fecha 14/2/2013) y todos los paquetes necesarios, java, compilador avr-gcc etc.
También pueden instalarse los paquetes por separado, o actualizar alguno de forma independiente (con :”sudo apt-get install paquete” o “sudo apt-get update paquete”)

avr-libc
libftdi1
avrdude
openjdk-6-jre
librxtx-java

Si falla alguna instalación se puede recuperar con “sudo apt-get install paquete –fix-missing”.

Con esto basta, se crea un acceso directo en el menú de inicio llamado arduino…
Arrancar el entorno gráfico con “startx” y ejecutar arduino. También puede ejecutarse una ventana de terminal, el navegador web…

Escritorio de raspberry con arduino

He usado un viejo teclado multimedia que tiene un hub con dos USB, de forma que el teclado, el ratón y el arduino solo me consumen un puerto USB y el otro lo tengo disponible para el pendrive de intercambio de datos…

Puede verse que he instalado un par de programas adicionales, el MC (soy de la vieja escuela y para trabajar desde terminal me gusta ese gestor de ficheros):

sudo apt-get install mc

Para usarlo basta con hacer “mc” desde un terminal. Si el terminal es de putty (http://www.chiark.greenend.org.uk/~sgtatham/putty/download.html) mejor hacer “mc -a” para que muestre correctamente los caracteres gráficos que componen el dibujo de los paneles.

Otra herramiente que he instalado es un capturador de pantallas scrot:

sudo apt-get install scrot

Desde un terminal, para capturar la pantalla despues de 5 segundos teclear “scrot -d 5”.
Para capturar inmediatamente basta “scrot”

Si queremos la ultima versión del entorno arduino 1.0.3 (a fecha 14/2/2013) podemos descargarla con “wget http://arduino.googlecode.com/files/arduino-1.0.3-linux64.tgz”.
Descomprimirla en el directorio de usuario con “tar zxvf arduino-1.0.3-linux64.tgz”.
La pega es que los binarios vienen compilados para Intel x64 y estamos trabajando con ARM, no nos valen. Eliminamos la carpeta “~/arduino-1.0.3/hardware/tools” de forma que el entorno de programación trabaje con los binarios ya instalados del entorno 1.0.1.
No estan desactualizados, si havemos “avr-gcc -v” desde un terminal veremos que tenemos instalada la versión 4.7.2 que es la última disponible.
También eliminamos de la carpeta “~/arduino-1.0.3/lib” los ficheros “librxtxSerial.so” y “librxtxSerial64.so”, estan compilados también para intel x86 y el entorno 1.0.1 instalado ya nos los proporciona.
Ahora podemos arrancar el entorno 1.0.1 desde el enlace en el menú de inicio o el entorno 1.0.3 esde la carpeta “~/arduino-1.0.3/”. Podemos hacerle un enlace al escritorio llamado “arduino1.0.3” y otro al entorno antiguo “arduino1.0.1”. Es posible usar los dos indistintamente sin interferencias. Hay que tener en cuenta que el compilador y todos los binarios compilados (el entorno esta escrito en java) que se usan son los que se instalaron con la versión 1.0.1, los que hemos descargado con la versión 1.0.3 los hemos borrado anteriormente porque estan compilados para intel x86.

Al conectar el arduino, en mi caso el UNO V3, el entorno detecta automáticamente y nos añade el puerto “/dev/ttyACM0” a la lista de puertos disponibles.

Aunque el entorno arduino es un poco pesado para la raspberry pi a (ARM11 a 700Mhz, 512Mb Ram) funciona perfectamente y no es necesario un PC para programar arduinos!!

Super Probe Plus: Sencillo multitester con PIc y 20 funciones

Rebuscando por la red encontré hace tiempo el SuperProbe aquí: http://mondo-technology.com/super.html
El diseño original con firmware V38 cuenta con 18 funciones. Me pareció un proyecto muy sencillo para un aficionado, y muy completo para llevar siempre en la caja de herramientas. El coste del proyecto es de solo unos 15 Euros!!
Usando partes del código original y otras escritas por mi he creado este clon con 20 funciones.
La única diferencia con el SuperProbe original es que el SuperProbePlus lleva intercambiadas entre si las resistencias R13 y R14 de 150 Ohmios y 100K. Esto es necesario para usar el generador de tensión de referencia interno del PIC a través del pin 4 (RA2) y dejar libre el pin 17 (RC6). Este pin antes se usaba para crear un divisor resistivo y generar 2.5 V para la detección de nivel flotante en el probador lógico. Ahora se usa para detectar el estado del nuevo selector de voltaje alto (25V) – bajo (5V). Permutando estas dos resistencias puede usarse mi código en un SuperProbe original. Si no se usa el conmutador del selector de voltaje alto – bajo poner el pin 17 (RC6) a nivel bajo (masa).
Opcionalmente puede conectarse un altavoz sustitución de la resistencia de 150 Ohmios y, prescindiendo de la generación de señal NTSC que necesita esa resistencia, tener un zumbador para medir cotinuidad.

Esquema Super Probe Plus 1.1

Las mejoras sobre el SuperProbe original son muchas:

Prob: nuevos modos
Puls: nuevas frecuencias y calibración exacta.
Voll: Calibración exacta y filtrado.
Diod: Salida de 10mA al pulsar PB1 para encender LED.
Ohms: Nuevo modo.
Cap: Mejorada la precisión.
Coil: Ahora solo inicia medida al pulsar PB1 para evitar bloqueo al entrar en el modo.
Freq: Calibrado exacto, nuevo modo RPM.
Cnt: Mejorada la visualización low-all.
Sig: Calibrado exacto.
Ser: Nuevas velocidades y modo auto.
rc.ou: repetición de los pulsos exacta a 50hz.
rc.in: Nuevo modo.
[]: Nueva forma de cambiar frecuencia, calibración exacta a 1Hz.
ir.ou: Nuevas frecuencias.
stop: ahora trabaja en milisegundos y formato h:mm:ss:nnn

Además ahora el programa fuente compatible con MPLAB esta mejor comentado y es mas versatil. Usando las directivas #define puede configurarse para distintas versiones de hardware y con distintas funciones.
Los datos de calibración y escalado se guardan en EEPROM de forma que es posible cambiarlos sin reprogramar el IC, por ejemplo para usar un divisor de tensión distinto.
Usando el regulador LP2950 se mejora la precisión analógica hasta 1,5%, bastante mejor del 5% del LM28L05 o del LM2931. El consumo es de alrededor de 40mA a 9V con multiplexado 1:32 (el original) ó 75mA a 9V con multiplexado 4:32 (usando transistores, da mas brillo y menos parpadeo).

Este es el manual del Super Probe Plus V42:

A fecha 8 de Marzo de 2012 he actualizado algunos errores y POR FIN HAY PCB!!

SuperProbe2

En el siguiente RAR hay: Fuentes para MPASM, esquema con Eagle, ficheros .ps listos para imprimir y “planchar” la placa, lista de componentes con los precios y códigos de RS etc.
He ensamblado dos versiones lista para usar, sin transistores para displays de ánodo común, una con generador NTSC y otra con zumbador en medición de continuidad. Cambiando los defines adecuados en el código fuente puede compilarse con o sin transistores, para displays de ánodo o cátodo común, con generador de señal o no y con ntsc o zumbador.

Descargar todos los ficheros del proyecto.

Esquema Super Probe Plus 1.1

Galeria de fotos de SuperProbe

LaserGame V4.1 Alfa, esquemas y fuentes

Atención estos son esquemas V4.1 y fuentes V4.5 en estado ALFA, aunque son totalmente operativos quizás tengan algunos fallos no descubiertos. Todavía queda algo de trabajito…

Actualizado 27/07/2011, efectivamente, en un solo día, ANONIMO me ha comentado que tengo invertida la alimentación del PIC en los esquemas. Un error de principiante, al pasar a limpio los borradores, que ya he corregido.
El circuito principal, que va montado en el arma, lleva incluido el convertidor DC-DC. Un fallo conocido es que no puede usarse el ICSP mientras la salida del convertidor DC-DC está conectada al circuito. La solución es sacar el jumper JP1 entre la salida del convertidor DC-DC y la alimentación de circuito (+5V) para usar el ICSP.
Aunque no he diseñado todavía el circuito impreso hay que tener mucho cuidado con el diseño de pistas de la parte analógica de Q7 y los componentes asociados, ya que es muy sensible al ruido eléctrico. La conexión del fototransistor en P8 ha de ser con cable apantallado. La ganancia del circuito esta programada a 250 y es muy justo teniendo en cuenta el margen de BETA de los BC547B-BC847B. Mejor usar BC547C-BC847C que tienen mas BETA. He observado diferencias de sensibiliad entre varios prototipos y podría deberse a esto.
Esquema principal

Este es el esquema de cableado de los elementos externos del LaserGame. Las memorias I2C son opcionales, no soportadas por el firmware V4.5.
Esquema de cableado

Ese es el esquema de los sensores I2C. A cada sensor se le asigna una dirección mediante los jumper JP0-JP3. Un fallo conocido es que no puede usarse el ICSP mientras haya alguno de estos puentes instalados. Pueden usarse hasta 8 sensores simultáneos con cada arma, y cada sensor dispone de hasta 4 fototransistores para aumentar la superficie sensible al láser. Igual que en el esquema principal la parte analógica es muy delicada, hay que usar cables apantallados y un buen diseño de pistas para los fototransistores. El bloque “modulador emisor” es opcional, normalmente los sensores no lo usarán pero podría ser útil en versiones posteriores del firmware.
Esquema de los sensores

Fuentes de la versión V4.5 de firmware para hardware V4.1, para placa principal y sensores, junto con el programa para PC de configuración.

Esquemas con KiCad de la versión V4.1 del hardware (compatible con el firmware V4.5)

Como puede verse en los esquemas el conjunto es muy sencillo, teniendo en cuenta todas las funciones que realiza. Los componentes mas caros son la PCB (no diseñada todavía) el display 2,17€ en Farnell y el laser 4€ en dealextreme.
El ajuste también e sencillo: regular los potenciómetros de 2K hasta que la señal cuadrada en la pata 5 del PLL LM567 sea de 38,5Khz.

LaserGame V4.1 Alfa

Por fin he encontrado un momento para publicar el trabajo de estos meses. El LaserGame Alfa es una versión preliminar (Alfa) de la evolución del LaserGame original. Ahora es un juego totalente operativo, con muchas funciones avanzadas, pero manteniendo la sencillez del original.

Licencia:
(c) Heli Tejedor, Julio 2011, http://heli.xbot.es, helitp@arrakis.es
Este Software se distribuye bajo licencia
Creative Commons 3.0 Reconocimiento, No Comercial, Compartir Igual(CC BY-NC-SA 3.0)
http://creativecommons.org/licenses/by-nc-sa/3.0/deed.es_ES
http://creativecommons.org/licenses/by-nc-sa/3.0/
Para usos comerciales contactar con el autor en helitp@arrakis.es

Armas: En la última versión del hardware V4.1 usan un PIC16F690 de 20 patillas, un display LED de 7 segmentos y 7 LED para informar del estado del arma. Mediante 7 pulsadores se interacciona con ella: Gatillo, puntero, cerrojo y cargador, además de 3 pulsadores arriba, menú y abajo.
Sensores: Usan otro PIC16F690 y un esquema similar al arma, pero sin display y con mas LED.
La comunicación es mediante un PLL LM567 se genera una onda cuadrada de 38,5Khz que es modulada mediante un transistor por la señal TX RS232 del PIC y se aplica a un transistor amplificador de potencia que alimenta el diodo láser (o infrarrojo).
El receptor funciona mediante un fototransistor sensible a la luz visible (aunque puede usarse uno infrarrojo). Se acopla en alterna a un amplificador y filtro paso banda centrado en 38,5Khz que amplifica la señal por 250. Esta señal se acopla en alterna a la entrada del PLL, que tiene una sensibilidad de 10mV, y la salida de enganche del PLL se lleva al RX RS232 del PIC.

La comunicación entre el arma y los sensores (pueden usarse hasta 8 sensores programados de distintas formas) es mediante un bus I2C, que también permite usar menorias I2C tipo 24cxx.

Estos son los prototipos que he montado para validar los esquemas y probar el firmware. Están montados en el interior de unas postolas (revolver) de juguete. En un bazar pueden encontrarse por 2,50€ y, una vez eliminado los elementos no deseados, queda aprovechable: un portapilas para 3 pilas tamaño AA, un altavoz y 4 LED.

Prototipo de revolver 1

Interior del prototipo de revolver 1

FAQ:
Por que 3 pilas Ni-Mh.
Esta versión de hardware 4.1 Puede funcionar con alimentaciones entre 3,2V y 4,5V. Un convertidor DC-DC eleva esta tensión hasta 5V, que es la que necesitan el PIC y el PLL para trabajar. Podrían usarse 3 baterías NI-MH, tres pilas alcalinas de 1,5V o una batería de litio de 3,7V. El diseño actual no incluye cargador de baterías porque el PIC no dispone de patillas libres, por lo que hay que extraer las baterías y cargarlas externamente. Para esto lo mas cómodo es usar baterías tamaño AA, que además es lo mas barato.

Por que PIC16F690.
La primera versión usaba PIC16F628 y bastaba, aunque limitando el display a 3 dígitos. Para solucionar los problemas de conectar los sensores de forma analógica decido usar sensores inteligentes con I2C. El PIC16F628 no dispone de I2C mientas que el PIC16F690 si. Además se puede usar un display de 4 dígitos.
El PIC16F690 es el PIC más pequeño y barato que soporta este firmware. Podría usarse uno mas potente sin problemas: PIC16F877, PIC18F2550 etc…

Por que láser.
No es imprescindible usar comunicación por láser rojo. Podrían usarse LED y fototransistores infrarrojos con filtro de luz visible. Incluso sensores IR completos como el TSOP1738 ó TSOP1740 e inyectar la señal tras el PLL. El sistema comunica a través de un enlace óptico que puede ser de cualquier longitud de onda (rojo, infrarrojo, verde…) y no es imprescindible que sea de luz coherente (laser). Dependiendo del tipo de luz escogida para la comunicación así serán las prestaciones. Con láser se simplifica el emisor, al no necesitar lentes de enfoque (los módulos laser las llevan incorporadas) ni ajustes complicados. Otra ventaja es que con laser se aumenta el alcance a cientos de metros y se aumenta la precisión a centímetros.
Láser: emisor más sencillo y sin ajustes, largo alcance, alta precisión. Punto visible para ayudar al tirador. Gafas de protección.
Infrarrojo: emisor con lentes y ajuste de enfoque, alcance hasta 10 metros, haz difuso e impreciso. Necesidad de un puntero láser adicional. No es necesaria ninguna medida de protección.

Por que comunicación serie.
Normalmente para enlaces ópticos se usan modulaciones NRZ, pulsos etc. Sin embargo esto complica el hardware y el software del PIC. Transmitiendo los datos serie por RS232 y modulando externamente a 38,5 Khz el hardware y el software son muy sencillos porque puede usarse la UART interna del PIC y el hardware externo es un simple PLL para la detección de las ráfagas de 38,5Khz. Para la transmisión de se aprovecha el oscilador del mismo PLL para generar la portadora y un para de transistores para modularla. El sistema no tiene el alcance ni la inmunidad al ruido que otros pero es mucho más sencillo.

Por que displays LED.
Por precio y disponibilidad. Los displays LED de 7 segmentos son muy comunes, fáciles de conseguir y baratos. El primer prototipo usaba displays reciclados porque era lo que tenía a mano. Los LCD suelen ser más grandes y caros. Aunque el multiplexado de los displays consume bastante potencia de CPU y son menos eficientes, son visibles siempre (excepto con luz solar intensa, pero el entonces tampoco funcionan los detectores) son mas fáciles de leer de un vistazo y le dan un aire retro bastante atractivo.

Por que no hay resistencia limitadoras en el los LED ni en el display.
No son necesarias ya que el firmware del PIC se encarga de limitar la corriente media en los LED a menos de 20 mA. Esto lo hace usando corrienentes de pico altas (al no haber limitación) pero usando ciclos de trabajo variables en el multiplexado se limita la corriente y se facilita variar el brillo del display.

Por que mosfet.
No son imprescindibles. Las primeras versiones usaban transistores bipolares BC548 y BC558. Una mejora es usar mosfet que tienen menos consumo (eliminan VCE ~0,4V de pérdida) y no necesitan resistencias limitadoras en la base. En el modulador su uso tiene más ventajas ya que, al no tener consumo de corriente, no derivan la frecuencia del PLL al extraer la portadora. Como inconveniente son muy frágiles, hay que tomar medidas de protección antiestática al montarlos (yo he averiado un cuarto de los que he montado por tener la punta del soldador derivada).

Es necesario programar los parémetros del arma antes de jugar.
NO. Las armas tienen una EEPROM interna donde se guarda el perfil del jugador y los parámetros del juego. Tras encenderla esta lista para funcionar con los últimos datos memorizados. La única limitación es que no se puede jugar con armas recién programadas y otras con la programación por defecto. Esto es así a propósito par evitar que, en un juego organizado donde cada jugador deba programar su arma según el esquema de juego escogido, alguien pueda resetear su arma y recuperar los parámetros por defecto para recuperar la vida, disparos etc. Al hacer esto esa arma dejará de comunicar con las demás.

Como se cuantos blancos he hecho.
El arma que efectúa el disparo no sabe si ha acertado o no. Sin embargo el arma del jugador que recibe un disparo sabe de que otra arma proviene y lo guarda en memoria. También guarda en memoria el tiro de gracia, el disparo que le mató. Al terminar el juego pueden descargarse los datos de las armas en un PC y cruzarse unos con otros con lo que se sabe quién acertó a quien y quien recibió disparos de que arma y cuantos. También puede verse que arma fue el que mató a cada jugador.

Que es la recamara.
El arma dispara la munición ó energía almacenada en la recámara. Para hacerlo hay que transferirla del cargador a la recámara, de modo automático o usando el pulsador recamara. Incluso cuando el cargador muestra cero puede haber energía o munición en la recámara para realizar otro disparo. Simula la recámara de un arma automática/semiautomática o el percutor levantado en un revolver. En modo potencia variable puede no haber suficiente energía para llenar la recámara con un disparo completo, entonces se muestra PAR por disparo parcial. Si en la recámara hay un disparo de menos potencia que la programada (disparo parcial) parpadea el LED RECAMARA.

Por que tantas opciones de configuración.
Por flexibilidad. Sirven para equilibrar el juego y permitir jugar a novatos con expertos equilibrando las deficiencias de los jugadores con mejores prestaciones de sus armas. También sirven para crear perfiles de jugadores específicos o roles: un francotirador puede tener un arma muy potente pero con una cadencia de disparos baja. Otro jugador puede querer avanzar rápido y estar mucho tiempo a descubierto y escoge un arma con muchos disparos y alta cadencia pero de poca potencia.

Que es el modo oculto.
Es un modo que se activa presionando el pulsador central más de 1,5 segundos y que apaga el display y los LED de los sensores. También desconecta los sonidos y los vibradores. Tiene que estar habilitado en FLAGS0 (Permitir modo oculto). Esto permite al jugador ir en silencio y sin luces que lo puedan delatar. Sin embargo deja de tener información de la munición restante, vida, tiempo etc. Tampoco puede sentir los disparos que recibe. No es un modo “todo ventajas” sino que tiene sus inconvenientes.

Que es el modo especial.
Es un modo en el que no se realizan disparos, sino que se pide vida o cargadores a los puntos de recarga. Se selecciona pulsando puntero + recamara, y se muestra “ESP” en el display. Se deselecciona de la misma forma. Si un arma recibe un disparo de este tipo transferirá un cargador. Puede ocurrir que, durante el juego, alguien realice disparos en ese modo. Solo conseguirá restar cargadores a los contrarios, no vida.

Por que potencia variable.
Cada arma lleva un número determinado de cargadores que permiten un número de disparos de una potencia determinada. La potencia total del arma, la capacidad para restar vida al contrario, es el producto de esos tres valores. En modo normal cada disparo tiene una potencia fija. Si se habilita la potencia variable la potencia de cada disparo puede modificarse, variando a la vez el número de disparos disponibles por cargador para dejar el producto total invariado. Si partimos de una potencia 2 y 20 disparos (la energía de cada cargador sería 40) podemos subirla a 5 y solo podríamos hacer 8 disparos (la energía sigue siendo 40). Si un jugador tiene 50 de vida es necesaria una energía de 50 para matarlo, o bien en un solo disparo de 50 o en 5 de 10…
Si se simula un revólver u otra arma convencional lo normal es que la potencia no pueda variarse. Si se simula un arma de energía futurista es interesante que pueda variarse la potencia. La máxima potencia configurable esta limitada por un parámetro de configuración.

Pueden usarse cargadores físicos.
Existe la posibilidad, desde la versión de hardware 4.0 que usa bus I2C, de conectar memorias 24C01, 24C02, 24C04 ó 24C08 de 128 a 1K bytes. Deben ser de Atmel O ST, no de Microchip que no llevan chip select. Aunque en los esquemas esta reflejado, sin embargo el firmware 4.5 todavía no lo soporta.

Que es el contador de reinicios.
Es un contador que se incrementa cada vez que se inicia un juego, al pulsar. Puede valer de 0 a 255 y no es posible resetearlo. Sirve para evitar trampas, que algún jugador cambie la configuración del arma durante el juego. Este contador puede visualizarse a través del software de programación del PC. Al terminar el juego debe valer una unidad más que al comienzo. Si no es así el arma ha sido reiniciada o recargada durante el juego y eso no esta permitido porque permite recargar el valor de vida, cargadores etc, o incluso variar el perfil del jugador respecto del asignado.

Que significan los LED:
En el encendido del arma, antes y durante la cuenta atrás de inicio de juego, todos los LED excepto “CON CARGADOR” parpadean indicando que no se ha comenzado a jugar.
• DL1 Rojo “FIN DE JUEGO”. Durante el juego permanece apagado. Mientras el arma esta inactiva por haber sido alcanzado por un disparo se enciende. Si la vida alcanza cero parpadea indicando que el fin del juego. Si el tiempo de juego termina se queda encendido fijo.
• DL2 Verde “RECAMARA”. Indica si la recámara esta cargada. Cuando esta apagado el arma no dispara. Parpadeando indica que la recamara esta cargada con un disparo parcial, de menor potencia que la programada.
• DL4 Tricolor “CON CARGADOR”. Apagado indica que no hay cargador. Encendido verde indica que hay un cargador montado. Encendido rojo indica “SIN CARGADOR”, que se han acabado los cargadores. Ámbar significa que se esta usando el último cargador. Verde parpadeando significa que esta seleccionado el modo de transferir cargador. El siguiente disparo será un mensaje de transmisión de cargador, no un disparo real
• DL5 Rojo “MODO AUTO” y DL6 Rojo “MODO SEMI”. Estos dos LED indican el modo de disparo seleccionado.
APAGADOS: Modo manual
MODO SEMI: Modo semiautomático.
MODO AUTO: Modo automático.
MODO SEMI y MODO AUTO: A ráfagas
• DL7 Rojo “SIN ENERGIA”. Encendido significa que se han agotado todos los cargadores y toda la energía incluida la de la recámara. Se acabó la munición. Parpadeando significa que no hay energía suficiente en el cargador para llenar la recamara con un disparo completo a la potencia programada.

Que significan los colores de los sensores.
Actualmente hay cinco secuencias de colores que tienen distintos significados según el estado del arma, pero puden modificarse en el firmware del sensor:
1. Alternancia rojo-azul: Sensor encendido pero sin inicializar por parte del arma.
2. Alternancia 2 rojos-1 rojo: El arma ha inicializado correctamente el sensor, listo para comenzar la cuenta atrás de inicio de juego.
3. Color fijo: Es el color seleccionado para ese jugador (Param.Color). Hay 256 colores distintos mezclando distintas intensidades: 8 de rojo, 8 de verde y 4 de azul.
4. Secuencia 3-2-1 verde: El sensor ha sido apuntado por otra arma (se ha recibido un mensaje correcto de puntero). El vibrador realiza dos cortas vibraciones. Esta función puede desactivarse en FLAGS0 (sentir puntero).
5. Secuencia 1-2-3 roja: El sensor ha recibido un disparo (se ha recibido un mensaje correcto de disparo). El vibrador realiza una secuencia de 6 vibraciones. Esta función puede desactivarse en FLAGS0 (sentir disparo).
6. Alternancia rojo intenso con rojo débil: Fin de juego por tiempo o fin de vida.
Si el arma esta en modo oculto los modos 3, 4 y 5 no se visualizan, quedando los sensores apagados.

Videos improvisados acerca del LaserGame V4.1 Alfa:




Grabador de EPROM para ZX Spectrum (1985)

Historia de un abuelo informático

Zx Spectrum 48K (Wikimedia)

Estamos en el año 1985 y yo tengo 15 años, mi padre me ha regalado un ZX Spectrum con la esperanza de que deje de acudir a casa de un amigo a trastear con su ORIC-ATMOS.

El spectrum me parece peor que el oric y usaba un Z80 (yo ya había comenzado a programar en ensamblador el R6502) sin embargo el zx spectrum tiene muchísimas ventajas: una comunidad enorme de usuarios, programadores y desarrolladores.
Había comenzado a comprar la revista Microhobby (todavía conservo desde el numero 1 hasta no recuerdo cual) y a animarme con sus programas, cursos y esquemas.

En los números 35, 36 37 y 38 de la primera época de la revista aparece un esquema interesante y su correspondiente programa de control: un grabador de EPROM.
Entremos en situación: la carga de programas en los ordenadores de esa época era mediante cintas de cassette a velocidades entre 600 y 1200 bps (esta última velodidad era la usada por el spectrum) y con muchos fallos. Una verdadera desesperación. El grabador de EPROM (yo tenía muchas EPROM 2764 de 8Kbytes procedentes de mis desguaces electrónicos) era la solución ideal para cargar programas de forma instantánea.
Solo necesitaba un pequeño programa cargador en cinta mediante el que leía la EEPROM a la memoria del spectrum. Instantáneo. Hasta conseguí alguna 27256 y 27512 (32K y 64K, una enormidad para la época).

Claro, que con 15 años y viviendo en un pueblo de 3000 habitantes no tenía acceso a medios técnicos sofisticados para construírlo (y menos a dinero para comprarlo, o comprar piezas) así que, como pude, construí esto:

Grabador de EPROM para Spectrum

Grabador de EPROM para Spectrum

Todos los componentes son reciclados de placas electrónicas de máquinas tragaperras, el soldador que utilicé fué uno de calderero de 60W (comprado en la ferretería local) y los hilos de conexionado son de pares telefónicos. La base no es circuito impreso de baquelita, es cartón de las tapas de los cuadernos de clase, que taladraba con un punzón para pasar las patillas de los componentes. Rústico pero funcionaba!!

Cableado del grabador de EPROM

Para borrar las memorias bastaba ponerlas al sol directo durante un par de días. Todavía conservo mi EEPROM mas preciada (de las que tenía dos copias, la seguridad ante todo): la que contiene el software de grabación y el ensamblador Z80.
Con este grabador programé la EPROM de mi primer ordenador autoconstruido (también sobre cartón y con hilos telefónicos) con Z80, 1K de RAM y 32 displays de 7 segmentos. Desgraciadamente lo desguacé unos años después para reutilizar sus componentes.

El zx-spectrum no esta muerto, todavía vive en la red en las páginas de los nostálgicos:

Microhobby

Hardware del spectrum

Programas de microhobby para Spectrum

Spectrum +3

El Spectrum en el siglo 21

Modificando un WRT300n V2

Tengo abandonados en el trastero un par de routers inalámbricos WTR300N V2 (draft N) y voy a hacerles una actualización…
La verdad es que son unos chismes majos, procesador ARM de 266 Mhz, 16Mb de SDRAM, 4Mb de FLASH, wireless atheros draft N de 300Mbps etc, pero el firmware que monta Linksys es muy limitado para las posibilidades que presenta este hardware.
Montaré un puerto serie, un conector JTAG, ampliaré la memoria e instalaré OpenWRT.
Estas modificaciones son aplicables sólo al WRT300n V2, que lleva un chip intel XScale IXP423 de 266, Mhz, el WRT300 V1 usa uno broadcom y es totalmente distinto. El V2 es intel/arm y el V1 es broadcom/mips.
En primer lugar instalo un puerto serie con niveles TTL para la cónsola de depuración. Es imprescindible para tener acceso a él si no esta correctamente configurada la red.
En este foro puede verse el conexionado del puerto serie.

Son 4 pines en línea, el que esta encerrado en un cuadrado de serigrafía es +3,3V, el siguiente RX, TX y el último GND.

En este conector uso mi convertidor RS232-TTL que, aunque usa un MAX232 a 5V trabaja bien con los niveles de este puerto de 3,3V. He aprovechado los conectores de audio de 4 pines de viejos CD-ROM para esta tarea:

Puerto serie

A continuación monto un conector JTAG para asegurarme que podré cambiar el firmware de la flash aunque estropee el bootloader que lleva de fábrica.

Jtag

Pinout del conector JTAG.

He construido un cable tipo wiggler para comunicarme por el JTAG con el router, visto aquí (cable wiggler). Yo he usado un conector de 12 pines en lugar de uno de 14, porque es lo que tenía a mano, aprovechando que 2 no se usaban.
Por último he cambiado la memoria, para ampliarlo de 16Mb a 32Mb. Este router viene con 2 memorias SDRAM a 133Mhz de 1Mb x 16 bits x 4 bancos. Yo las he sustituido por unas de 2Mb x 16bits x 4 bancos tipo K4S281632d que he obtenido de viejos módulos SDRAM (de los que montaban los PIII) de 256Mb (8 chips de 32 Mb). También sirven unas HY57V281620h

SDRAM

Ahora enciendo el router y compruebo la salida de la cónsola mediante el cable serie y un programa de terminal como realterm configurado a 115200 baudios 8n1. Para sacar el máximo partido a la cónsola de programación mejor usar un programa de telnet con posibilidad de puerto serie como PuTTY. Comienzan los problemas: el linux solo reconoce 16Mb de RAM:

RedBoot(tm) bootstrap and debug environment [ROMRAM]
Red Hat certified release, version 2.02 - built 14:59:11, Aug 16 2006

Platform: Intel Generic Residential Gateway (IXP42X 266MHz) BE
Copyright (C) 2000, 2001, 2002, 2003, 2004 Red Hat, Inc.

RAM: 0x00000000-0x01000000, [0x00066480-0x00ff4000] available
FLASH: 0x50000000 - 0x50400000, 64 blocks of 0x00010000 bytes each.
== Executing boot script in 2.000 seconds - enter ^C to abort
RedBoot> boot;exe
eRcOmM signature found
Copying kernel. Size: 11c190
Using base address 0x00400000 and length 0x0011c190
Uncompressing Linux.............................................................................. done, booting the kernel.
Linux version 2.6.13.2 (root@5c10-187-9-1) (gcc version 3.4.3) #1 Thu Oct 12 14: 53:29 CST 2006
CPU: XScale-IXP42x Family [690541f1] revision 1 (ARMv5TE)
Machine: ADI Engineering Coyote
Memory policy: ECC disabled, Data cache writeback
CPU0: D VIVT undefined 5 cache
CPU0: I cache: 32768 bytes, associativity 32, 32 byte lines, 32 sets
CPU0: D cache: 32768 bytes, associativity 32, 32 byte lines, 32 sets
Built 1 zonelists
Kernel command line: console=ttyS0,115200 root=/dev/mtdblock2 noinitrd rootfstyp e=squashfs mem=16M@0x00000000 init=/sbin/init
PID hash table entries: 128 (order: 7, 2048 bytes)
Console: colour dummy device 80x30
Dentry cache hash table entries: 4096 (order: 2, 16384 bytes)
Inode-cache hash table entries: 2048 (order: 1, 8192 bytes)
Memory: 16MB = 16MB total
Memory: 13316KB available (1686K code, 838K data, 324K init)

Buscando en foros deduzco que el problema es del BootLoader (RedBoot) que es el que se encarga de inicializar los periféricos del procesador (incluido el controlador de SDRAM). El kernel de linux lee la configuración que esta usando el RedBoot. Necesito un RedBoot que reconozca los 32Mb de RAM.

En primer lugar necesito un PC con Linux, yo estoy usando OpenSuse 11.1 pero podrían usarse otras versiones o “sabores”.

A continuación descargo los fuentes OpenSource del firmware de Linksys: fuentes GPL del wrt300nV2 o Fuentes desde Cisco (Linksys). Lo descomprimo en ~/WRT300N-GPL-v2.00.21
Hacer “cd ~/WRT300N-GPL-v2.00.21” y ejecutar “./build” como root para que compile, de esta forma probamos que todo esta bien configurado para compilar los fuentes originales. Los binarios generados quedan en “~/WRT300N-GPL-v2.00.21/binfile”. “wrt300n.bin” es el bootloader+linux completo. Sin embargo esto no compila el bootloader, sino que usa un binario que ya existía en /binfile.

Para compilar el bootloader RedBoot, que esta incluido en los fuentes originales dentro del directorio “/wrt300n_redboot_GPL” es necesario descargar la toolchain “i686-pc-linux-gnulibc2.2-x-xscale-elf”. Extraigo el fichero “Install” y ejecuto como root “./Install — file=i686-pc-linux-gnulibc2.2-x-xscale-elf.tar.Z”. Esto descomprime el fichero y lo instala en “/opt/redhat/xscale-030422”

Pruebo a compilar el RedBoot:
“export PATH=/opt/redhat/xscale-030422/H-i686-pc-linux-gnulibc2.2/bin:$PATH”
(Para que makefile encuentre una utilidad llamada “ecosconfig” de la toolchain que se instaló en /opt/redhat/xscale-030422/H-i686-pc-linux-gnulibc2.2)
Como estoy usando una versión “moderna” de linux, en comparación a la que se usó para crear la toolchain, obtengo un error cuando make ejecuta ecosconfig, porque busca una librería antigua: “libstdc++.so.5”. La consigo instalando el paquete “libstdc++33” con yast como root.
Compilar el RedBoot puede hacerse como usuario normal:
“cd ~/WRT300N-GPL-v2.00.21/wrt300n_redboot_GPL”
“make”
“cd ~/WRT300N-GPL-v2.00.21/wrt300n_redboot_GPL/build/wrt300n/install/bin”
Copio el RedBoot recién construido para evitar confundirlo:
“mv redboot.bin a redboot.bin.old”

Ahora ya he probado que todo va bien y que puedo compilar los fuentes que he descargado. Tengo que modificar el RedBoot para que reconozca los 32Mb de mi placa:
En primer lugar he de cambiar un par de switches en la configuración del RedBoot. Tal y como viene configurado en los fuentes descargados no permite usar todas los comandos disponibles.
En “~/WRT300N-GPL-v2.00.21/wrt300n_redboot_GPL/options/startup_ROMRAM.ecm” modifico estas dos líneas:
cdl_component CYGSEM_REDBOOT_FLASH_CONFIG {
user_value 1
};
cdl_option CYGOPT_REDBOOT_FIS {
user_value 1
};

Anteriormente tenían “user_value 0″.

Cambio los defines adecuados para que reconozca los 32Mb:
En:”~/WRT300N-GPL-v2.00.21/wrt300n_redboot_GPL/packages/hal/arm/xscale/grg/current/include/grg.h”
Me aseguro de que NO este definido “WRT300N-16MB” para que defina 32Mb de RAM.
#undef WRT300N-16MB
// #define WRT300N-16MB

Este paso es MUY IMPORTANTE, yo dejé “bricked” mi router antes de descubrirlo. El RedBoot, tal y como viene configurado en los fuentes, solo soporta un tipo de memoria FLASH de 8Mb. Si se compila y se instala tal cual, al arrancar, no detectará la FLASH y será imposible cargar el linux ni sustituir el RedBoot. Esto es debido a que los routers comerciales suelen llevar una FLASH de sólo 4Mb tipo MX29LV320, compatible con AM29LV320D.
Existen unos defines que permiten configurar el RedBoot con los drivers adecuados para varios tipos de FLASH. Comprobar los tipos de FLASH soportadas en “~/WRT300N-GPL-v2.00.21/wrt300n_redboot_GPLpackagesdevsflashamdam29xxxxxv2_0includeflash_am29xxxxx_parts.inl”
Para que soporte la flash MX29LV320 y AM29LV320D yo añado en:
“~/WRT300N-GPL-v2.00.21/wrt300n_redboot_GPL/packages/hal/arm/xscale/grg/current/misc/redboot_ROMRAM.ecm”
y en
“~/WRT300N-GPL-v2.00.21/wrt300n_redboot_GPL/packages/hal/arm/xscale/grg/current/misc/redboot_RAM.ecm”

cdl_option CYGHWR_DEVS_FLASH_AMD_AM29LV320D {
inferred_value 1
};

Añado una cadena de texto para que cuando se ejecute el RedBoot pueda identificar que es el que yo he modificado:
“cd ~/WRT300N-GPL-v2.00.21/wrt300n_redboot_GPL/packages/redboot/current/src/”
En version.c añado “compiLed by helitp@arrakis.es”

Para compilar de nuevo el RedBoot:
“export PATH=/opt/redhat/xscale-030422/H-i686-pc-linux-gnulibc2.2/bin:$PATH”
“cd ~/WRT300N-GPL-v2.00.21/wrt300n_redboot_GPL”
“make”
“cd ~/WRT300N-GPL-v2.00.21/wrt300n_redboot_GPL/build/wrt300n/install/bin”
“mv redboot.bin redbot_mio.bin”

Ahora habría que probarlo, pero ¿y si falla y el router queda inutilizado?. Pues existe una forma de probar el RedBoot sin tener que flashearlo. Puede cargarse en RAM usando el redboot original y ejecutarlo. Si no va como esperamos, al rearrancar el router usará de nuevo el de la flash. Si todo va bien podemos flashearlo definitivamente.
Para preparar un RedBoot que corra en ram:
“cd ~/WRT300N-GPL-v2.00.21/wrt300n_redboot_GPL”
“cp Makefile Makefile.romram”
cambio en Makefile
ecosconfig import ${ECOS_REPOSITORY}/hal/arm/xscale/grg/current/misc/redboot_ROMRAM.ecm &&
por
ecosconfig import ${ECOS_REPOSITORY}/hal/arm/xscale/grg/current/misc/redboot_RAM.ecm &&
“cp Makefile Makefile.ram”
“make”
“cd ~/WRT300N-GPL-v2.00.21/wrt300n_redboot_GPL/build/wrt300n/install/bin”
“mv redboot.img redboot_mio.img”
Llegado a este punto tendremos un “redboot_mio.bin” que creamos que es el que corre desde flash y un “redboot_mio.img” que es el que corre desde ram. Para construir uno u otro copiar “cp Makefile.romram Makefile” o “cp Makefile.ram Makefile” y luego ejecutar “make”. Dejo aquí mis dos RedBoot ya compilados.

Ahora usaré otro ordenador con Windows XP para comunicarme con el router. Descargo tftpd32. Es un pequeño programa servidor de tftp que enviará los ficheros al router cuando se los pidamos a través del RedBoot.
Conecto un cable ethernet entre el wrt300n y el PC, configurando la terjeta de red en IP:192.168.0.3 NETMASK:255.255.255.0. Esta es la dirección IP que usa por defecto el RedBoot para conectar con el tftp. Arranco tftpd32 desde el directorio donde tengo los binarios del RedBoot y escojo en ua pestaña de IP la de la tarjeta ethernet 192.168.0.3
El RedBoot configurará la IP del wrt300n en 192.168.0.10 unos segundos durante el arranque, mientras tiene el control. Puede comunicarse por TELNET con Putty configurando telnet, servidor en 192.168.0.3, puero 9000 pero es mas fiable el cable serie.

Arranco en Putty una conexión serie a 115200 baudios y conecto el convertidor rs232-TTL. Conecto el router y podré ver en el Putty:

RedBoot(tm) bootstrap and debug environment [ROMRAM]
Red Hat certified release, version 2.02 - built 14:59:11, Aug 16 2006

Platform: Intel Generic Residential Gateway (IXP42X 266MHz) BE
Copyright (C) 2000, 2001, 2002, 2003, 2004 Red Hat, Inc.

RAM: 0x00000000-0x01000000, [0x00066480-0x00ff4000] available
FLASH: 0x50000000 - 0x50400000, 64 blocks of 0x00010000 bytes each.
== Executing boot script in 2.000 seconds - enter ^C to abort

En ese momento pulso CTRL-C para abortar el arranque del linux y comenzar a usar el RedBoot.
Ejecutamos el comando “fis” (Flash Image System):
fis
solo debera mostrar disponibles erase y write, es el redboot original
ether (esto activa la ethernet)
ip -h 192.168.0.3 (esto configura la ip del host, solo es necesario si esta en una ip distinta a la predefinida 192.168.0.3)
load redboot_mio.img (esto cargará en la RAM del wrt300n el fichero por ftpd)
go (ejecuta el programa cargado)
arrancará un nuevo redboot, parar el arranque de linux con CTRL-C
Comprobar que muestra la cadena “compiLed by helitp@arrakis.es” incluida en la modificacion del redboot
Comprobar que detecta la flash! si no es asi comprobar el tipo de flash montada en el wrt300n y añadir los modelos correctos en redboot_RAM.ecm o redboot_RAMROM.ecm
Ejecutar:
fis
debera mostrar los comandos init, load, list etc ademas de los erase y write, es el redboot modificado
Una vez comprobado que todo va bien podemos cargar el RedBoot definitivo y grabarlo en la FLASH, reiniciamos el router y pulsamos CTRL-C:
ether
ip -h 192.168.0.3
load -r -b 0x70000 -m tftp redboot_mio.bin (esto carga el fichero binario en la dirección 0x70000)
fis write -f 0x50000000 -b 0x70000 -l 0x4f978 (graba el el cotenido de la dirección 0x70000 longitud 0x4f978 enla flash)
reset (reinicia el router)
Es importante saber que en la dirección de memoria 0xCFFA0 se guarda la MAC del router. Si se sobreescribe por error la MAC se perderá. Puede recuperarse preparando un fichero binario de 6 bytes con la MAC en mac.bin y subiéndolo al router con
load -r -b 0xCFFA0 -m tftp mac.bin
luego subir el RedBoot y grabarlo TODO junto:
load -r -b 0x70000 -m tftp redboot_mio.bin
fis write -f 0x50000000 -b 0x70000 -l 0x60000
También es interesante saber que los parámetros por defecto del RedBoot pueden modificarse con
fconfig -i
Run script at boot: true
Es script de inicio para autoarranque del linux debe ser:
Boot script:
ether
fis load kernel
exec

Ahora, en el PC con Linux, descargo las fuentes últimas de OpenWrt
cd ~/
svn co svn://svn.openwrt.org/openwrt/trunk
svn checkout svn://svn.openwrt.org/openwrt/trunk/ ~/trunk/
cd ~/trunk/
Descargo tambien la última versión de LUCI, el interfaz gráfico basado en web para la configuración de OpenWrt:
./scripts/feeds update packages luci
./scripts/feeds install -a -p luci

Para seleccionar opciones adecuadas para el wrt300n:
make menuconfig
Esto generará un fichero .config con la configuración deseada. Este es el mio.

Para compilar:
make

en “~trunk/bin/ixp4xx/” quedan las imagenes binarias. Copio “openwrt-wrt300nv2-zImage” y “openwrt-ixp4xx-generic-squashfs.img” al PC con Windows, al directorio donde tengo corriendo el tftpd.
Desde el RedBoot hago:
fis init (formatea la flash)
load -r -b 0x6b000 -m tftp openwrt-wrt300nv2-zImage (sube al router el kernel de linux)
fis create kernel (graba el kernel en una particoión de flash)
load -r -b 0x6b000 -m tftp openwrt-ixp4xx-generic-squashfs.img (sube el sistema de ficheros al router)
fis create rootfs (graba el sistema de ficheros en otra partición)
fis load kernel (carga el kernel en RAM)
exec (lo ejecuta)

RedBoot(tm) bootstrap and debug environment, compiLed by helitp@arrakis.es [ROMRAM]
Red Hat certified release, version 2.02 - built 21:54:28, Apr 4 2011

Platform: Intel Generic Residential Gateway (IXP42X 266MHz) BE
Copyright (C) 2000, 2001, 2002, 2003, 2004 Red Hat, Inc.

RAM: 0x00000000-0x02000000, [0x0006ac98-0x01fe1000] available
FLASH: 0x50000000 - 0x50400000, 64 blocks of 0x00010000 bytes each.
== Executing boot script in 2.000 seconds - enter ^C to abort
RedBoot> ether

Trying NPE-B...success. Using NPE-B with PHY 16.
Ethernet eth0: MAC address 00:18:39:2f:fa:74
IP: 192.168.0.10/255.255.255.0, Gateway: 0.0.0.0
Default server: 192.168.0.125
RedBoot> fis load kernel
RedBoot> exec
Using base address 0x0006b000 and length 0x000d5724
Uncompressing Linux... done, booting the kernel.
Linux version 2.6.37.6 (heli@asus) (gcc version 4.5.2 (Linaro GCC 4.5-2011.02-0) ) #7 Fri Apr 8 06:50:08 CEST 2011
CPU: XScale-IXP42x Family [690541f1] revision 1 (ARMv5TE), cr=000039ff
CPU: VIVT data cache, VIVT instruction cache
Machine: Linksys WRT300N v2
Memory policy: ECC disabled, Data cache writeback
Built 1 zonelists in Zone order, mobility grouping on. Total pages: 8128
Kernel command line: root=/dev/mtdblock2 rootfstype=squashfs,jffs2 noinitrd console=ttyS0,115200
PID hash table entries: 128 (order: -3, 512 bytes)
Dentry cache hash table entries: 4096 (order: 2, 16384 bytes)
Inode-cache hash table entries: 2048 (order: 1, 8192 bytes)
Memory: 32MB = 32MB total
Memory: 30016k/30016k available, 2752k reserved, 0K highmem

Ahora ya detecta los 32Mb correctamente. Ya esta todo. Este kernel con LUCI va muy bien con 32Mb de RAM pero iba muy lento y se podía colgar al usar LUCI en un router original con 16Mb de ram.

PLC clónico de Hitachi EC