Driver para joystick multiplexado para Raspberry PI: hasta 160 switches con 26 GPIOs

El pasado mes de Noviembre le regalé a mi hijo una consola arcade (concretamente una de estas http://arcademadrid.com/50-mando-consola-arcade-hdmi-tv-arcade-2-jugadores). Funciona mediante una Raspberry PI 2, el mueble esta bastante bien y tiene 2 joysticks y 16 pulsadores de buena calidad.
Trasteando con ella he observado que consume casi todos los GPIOs de la raspberry pi 2 para los switches de los pulsadores. Son 24 switches, conectados cada uno a un GPIO, y la raspberry PI 2 tiene 26 GPIOs.
Como me interesa añadir mandos de SNES y un volante de PS2 usando el driver «gamecon_gpio_rpi» https://github.com/RetroPie/RetroPie-Setup/wiki/GPIO-Modules he diseñado una esquema de conexionado nuevo, multiplexando la lectura de los switches, de forma que puedo conectar los 24 switches usando solo 10 GPIOs. Así puedo conectar los mandos SNES y PS2 en los pines que quedan libres
Usando este conexionado se pueden conectar los 24 switches incluso a una raspberry PI 1 que solo tiene 17 GPIOs disponibles en el conector de 26 pines.
Claro que para que esto funcione bien es necesario escribir un driver del kernel de linux que se encargue de leer el hardware y lo muestre en un dispositivo (en el arbol /dev) de forma que los programas lo puedan utilizar.

Una complicación autoimpuesta es que se pueda usar tanto para raspberry pi 1 con conector de 26 pines como con raspberry pi B+ ó 2 con conector de 40 pines intentando dejar siempre como última elección los pines de funciones especiales.
Gracias a esto es posible conectar 2 joysticks con 8 pulsadores (mas 4 de dirección) cada uno dejando libres los pines de TX y RX de UART0 y SDA1 SCL1 del I2C. En la versión 0.0.2 del driver intento también dejar libres los pines que necesita el driver «gamecon_gpio_rpi».

El conexionado eléctrico es fácil, solo se necesita un diodo de señal (1N4148, por ejemplo) por cada pulsador para evitar interferencias al actuar varios pulsadores a la vez. El driver permite 18 tipos distintos de esquemas de conexionado dependiendo del número de switcheslos y joysticks que se deseen usar y del número de GPIOs disponibles.
Yo usaré el «type=14» que permite hasta 5 joysticks de 2 ejes y 8 botones auque el mueble solo necesita 2 de ellos.
El conexionado que he usado es este:
Esquema type=14

En el esquema solo se nombreb los switches con «swX» donde X es un número. Dependiendo del parámetro del driver «map=n» se mapean a los distintos pulsadores de los joysticks siguiendo este mapa:
Mapa SWx

El conexionado multiplexado se basa en cablear los switches en forma de filas y columnas. Las filas se conectan a SALIDAS GPIO de la raspberry y las columnas a ENTRADAS GPIO con el pullup activo. De esta forma con un único grupo de entradas GPIO se pueden leer, de forma alternativa, cada una de las filas. Para leer una fila es necesario poner a nivel BAJO el GPIO correspondiente. Entonces existe un nivel bajo en la fila que los pulsadores pueden enviar a las entradas (columnas) cuando de actuan. El resto de filas se mantienen a nivel alto que es bloqueado por los diodos y es como si no estuvieran conectadas.
Para usar el menor número de GPIOs he subdividido cada fila en dos, de forma que hay dos GPIO de salida por cada fila pero solo la mitad de GPIOs de entrada (columnas).
Con 27 GPIOS disponibles en los conectores de 40 pines de las raspberry se pueden conectar hasta 160 switches (usando el conexionado «type=11») en una matriz de 8 x 20 (en realidad 16 x 10 por que he partido cada fila en dos, asi solo se usan 10 entradas en lugar de 20, pero se usan 16 + 10 pines de GPIO en lugar de 8 + 20).

El driver se instala desde un paquete .deb que he preparado. Se compila en la propia raspberry porque depende del hardware.
Antes de instalarlo es recomendable actualizar la raspberry con:
sudo apt-get update
sudo apt-get dist-upgrade -y
sudo reboot

Luego pueden eliminarse los paquetes fuente de la actualización para ahorrar espacio con:
sudo apt-get clean

Descargar el instalador, worpress no me permite subir .sh «por seguridad» y lo he ‘targzipeado’:
wget http://heli.xbot.es/wp-content/uploads/2016/05/install.tar.gz
tar -xzvf install.tar.gz
sudo ./install.sh

Primero descargará varios paquetes necesarios para la compilación: dkms, cpp-4.7, gcc-4.7 y joystick
Luego descargará los headers del kernel adecuado a la versión instalada, necesarios para la compilación del driver, con un «wget http://www.niksula.hut.fi/~mhiienka/Rpi/linux-headers-rpi/linux-headers-`uname -r`_`uname -r`-2_armhf.deb» y lo instalará con «sudo dpkg -i linux-headers-`uname -r`_`uname -r`-2_armhf.deb»
A continuación conectará con esta página, hará un wget del .deb heli-mpx-joystick-rpi-0.0.2.tar.gz y lo instalará con «sudo dpkg -i heli-mpx-joystick-rpi-0.0.2.deb». Por último eliminará el paquete fuente de los headers, que ya no es necesario, pero los headers se quedan instalados la raspberry en /usr/src/linux-headers-x.x.x.

Todo esto llevará bastante tiempo y es necesario tener una conexión a internet operativa en la raspberry.

En una de mis raspberries he observado un problema en la compilación, debido a la actualización de los headers a a la versión 4.4.9+
"No rule to make target 'kernel/time/timeconst.bc'"

Lo he solucionado copiando el fichero timeconst.bc de http://mirrors.neusoft.edu.cn/rpi-kernel/kernel/time/timeconst.bc a ‘kernel/time/timeconst.bc’

Una vez instalado puede cargarse con
sudo modprobe heli_mpx_joystick_rpi map=2 devices=2 type=14
y probarse con
jstest /dev/input/js0
jstest /dev/input/js1

Jstest tiene un fallo, conocido pero no parcheado (al menos en la versión del paquete ‘joystick’ del repositorio de la raspberry). No muestra correctamente los nombres de los botones del joystick. Es debido a un array de nombres donde faltan tres elementos y eso hace que queden descolocados los demás.
Mientras preparaba esta entrada veo que han actualizado linuxconsoletools, que es el paquete de fuentes donde viene jstest, a la versión 1.5.1 (la anterior era la 1.4.9). Supongo que habrán incluido el parche.
https://sourceforge.net/projects/linuxconsole/files/

El driver puede descargarse del kernel con
sudo rmmod heli_mpx_joystick_rpi

También puede desinstalarse totalmente con
sudo apt-get remove heli-mpx-joystick-rpi-dkms

Fuentes y el resto de los los ficheros del proyecto aqui: http://heli.xbot.es/wp-content/uploads/2016/05/heli_mpx_joystick_rpi_0.0.2_src.tar.gz

Documentos y esquemas del proyecto aqui: http://heli.xbot.es/wp-content/uploads/2016/05/Docs-0.0.2.rar

Para que cargue de forma automática al arrancar la raspberry es necesario añadir en ‘/etc/modules’ una línea:
heli-mpx-joystick-rpi
y crear un fichero de configuración ‘/etc/modprobe.d/heli-mpx-joystick-rpi.conf’ con los parámetros deseados:
options heli-mpx-joystick-rpi map=2 devices=2 type=14

Una vez recableados los switches del mueble original e instalado este driver quedan 16 pines libres donde se pueden cablear los los conectores de la SNES y de la PS2 extraidos de consolas averiadas que he montado en el mueble asi:
Conectores SNES y PS2

Luego uso el driver «gamecon_gpio_rpi» según se explica en https://github.com/RetroPie/RetroPie-Setup/wiki/GPIO-Modules.

Y todo ha quedado asi:
Consola Retropie con SNES y PS2

Usando un display indocumentado de DealExtreme YL-3 con drivers 595

Hace una semana compré unos displays de LED de 7 segmentos, de 8 dígitos, en DealExtreme pensando en un visualizador de coordenadas para un CNC.

Display YL-3

El sdisplay se suministra sin documentación esquema ni nada. En la serigrafía de la placa solo aparece el texto «YL-3» por lo que yo llamaré a este display así. No he sido capaz de encontrar informacion acerca de su uso, esquemas, ni nada. Tendré que hacer yo mismo el esquema y el código para su uso.

Un poco de ingenieria inversa:

En primer lugar será necesario el esquema para poder empezar a escribir el código que lo haga funcionar. Lo primero es buscar la documentación de los elementos que usa el display para saber or donde empezar a trazar el esquema.
Este modelo usa drivers HC595 que son simples registros de desplazamiento con latches de salida. De esta forma los datos desplazados no aparecen en la salida hasta que se activa el latch y se evita imagen fantasma en el display. Es curioso pero el sn74hc595 común es un registro de desplazamiento con salidas TTL, no adecuadas para encender LED, pero existen versiones de alta corriente de salida que son las que se usan aquí.
Los dos displays de 4 dígitos por 7 segmentos y punto decimal estan marcados «3461BS» y tampoco he encontrado un esquema, con el SuperProbe en modo prueba de diodos voy averiguanduando su conexionado. Están conectados los ánodos en común.
Por suerte en la placa esta serigrafiada la utilidad de los terminales de conexión y es facil seguir con el tester de continuidad el esquema.

Esquema YL-3

Ademas voy a probarlo con un Teensy 3.1 en lugar de usar un arduino convencional.

Solo son necesarios 5 cables, dos de alimentación, un clock, un data y un estrobe. Este es el montaje de pruebas, con una tarjeta SD para apreciar el tamaño de los componentes:

Prueba Teensy 3.1 + YL-3

El display trabaja multiplexado ya que los LED estan conectados en forma de matriz de 8×8.
Este es el código que uso: YL-3.RAR
El .rar contiene una libreria «hc595x2» para colocar en el directorio «libraries» de arduino y un sketch «Test_hc595x2″ para compilar y probar el display (para Teensy 3.1, no lo he probado con otros arduino).
El programa acepta caracteres ASCII por el puerto serie virtual USB y los visualiza en el display, también algunos símbolos y algunos caracteres de control.
Los caractres aceptados son:
Números 0-9, letras minúsculas a-z y letras mayúsculas A-Z.
Letra ñ (ASCII 209 ó 241)
Espacio en blanco » «, guión «-«, guión bajo «_», barra «/», grado «º» ASCII 186, punto «.», coma «,» (los dos encienden el punto decimal y no avanza el cursor), comilla «‘» ASCII 39 y comillas «»» ASCII 34.

Los códigos de control son:
Retroceso (Backspace) CTRL-H ASCII 8, retorno del carro (retorno del cursor al inicio del display) CTRL-M ASCII 13, Delete ASCII 127, Limpiar el display y retorno del cursor CTRL-J ASCII 10.

Mejor revisar el código para ver las funciones…

Otro detalle, el entorno arduino 1.0.5 se cuelga si en el nombre del archivo hay un guión: «test yl-3.ino» lo cuelga, «test yl_3.ino» funciona bien…

Asi funciona:

El display es muy barato y brillante, y no es dificil usarlo aunque el micro tenga que hacer el multiplexado no es mucha carga de trabajo.
Me comentan en el foro de ARDE que se pueden encontrar unos displays muy similares en EBAY con un enlace a su esquema en PDF.

PLC en Raspberry PI: classicladder

El proyecto «classicladder» consiste en un PLC (en inglés Programmable Logic Controller, autómata programable o solo autómata en español) programable en ladder (diagrama de contactos en español) o en grafcet. También integra un entorno de monitorización y comunicaciones, incluyendo MODBUS para las entradas y salidas. Esta escrito en C y usa el entorno GTK+2, puede compilarse para Windows y para Linux.
El autor de este programa es Marc Le Douarain, yo he hecho pequeñas contribuciones: https://sites.google.com/site/classicladder/
El software interpreta el programa, al contrario que otros PLCs que ejecutan código compilado en un PLC virtual, y es totalmente funcional. Es posible ejecutar el software en una máquina sin entorno gráfico y controlarlo desde otra con entorno gráfico mediante comunicaciones (tcp/ip o serie).
Compilarlo para Raspberry pi no debería ser dificil, corre un linux.

Trabajando en la propia raspberry pi con conexión a internet, primero descargamos los fuentes en C de la última versión a 18/2/2013 classicladder 0.9.6 desde el directorio de usuario PI:
«wget http://sourceforge.net/projects/classicladder/files/classicladder/classicladder-0.9.006.tar.gz»
Y lo descomprimimos con:
«tar -xvzf classicladder-0.9.006.tar.gz»
Esto crea el arbol de diecorios en ~/classicladder, ahora cambiamos los permisos de los ficheros, por seguridad.
Entrar en el directorio:
«cd «~/classicladder/projects_examples»
y hacer
«chmod 644 *»
Salir al directorio «~/classicladder»:
«cd ..»
y hacer:
«chmod 644 *»
«chmod 755 projects_examples»

Ya tenemos todos os fuentes listos.
Ahora podemos compilar el software CON o SIN entorno gráfico. Si lo hacemos sin entorno gráfico no podremos controlar el PLC classicladder si no es comunicándolo con otro classicladder que si tenga entorno gráfico.

Para compilar con entorno gráfico es necesario instalar las librerías del entorno GTK+2:
«sudo apt-get install libgtk2.0-dev»

Ya esta todo listo, compilar simplemente ejecutando make desde el directorio de los fuentes, el makefile que acompaña al royecto ya esta configurado para linux y funcionará perfectamente en la raspberry pi:
«cd «~/classicladder»
«make»
Esto habrá creado un fichero ejecutable «classicladder». Ya podemos probarlo ejecutarlo «./classicladder». Se desplegrán varias ventanas y podremos ver el estado del PLC…:

Escritorio de raspberry con classicladder

Podemos salvar esta versión del ejecutable con entorno gráfico con otro nombre:
«cp classicladder classicladder_gtk»

Para compilarlo SIN entorno gráfico y usarlo como aplicación embebida, mucho mas ligero (la aplicación gráfica con GTK+2 consume bastante CPU de la raspberry), hay que modificar un para de cosas en el fichero «Makefile»:

Comentar la siguiente línea:
«GTK_INTERFACE = 1» -> «#GTK_INTERFACE = 1»
Esto le dice al makefile que compile el proyecto SIN entorno gráfico.
Comentar las siguientes líneas:
«OWN_CFLAGS = -march=i486» -> «#OWN_CFLAGS= -march=i486»
«OWN_LIBS = -march=i486» -> «#OWN_LIBS = -march=i486»
Estas líneas son específicas para entornos intel x86, nosotros vamos a compilarlo para ARM.
Salvar el fichero modificado, hacer:
«make clean»
para limpiar cualquier compilación anterior y compilar de nuevo con:
«make»
Se habrá creado un nuevo ejecutable «classicladder».

Para que funcione correctamente en modo embebido SIN entorno gráfico hay que crear un directorio donde se almacenarán los programas recibidos y donde classicladder buscará para cargar automáticamente el programa en el arranque:
«cd /usr/local»
«md classicladder»
Esto creará un directorio «/usr/local/classicladder»

Ejecutar classicladder desde el directorio donde se creó:
«cd ~/classicladder/
«./classicladder»
Podremos ver una serie de mensajes y al final «SOCKET WAITING». Este será el PLC tarjet y ya esta funcionando y esperando órdenes. Ahora podremos comunicarnos con este PLC desde otra máquina con entorno gráfico.
Conectar la red a la raspberry y hacer «ifconfig» para ver su IP, si no la hemos anotado cuando arrancó.
En otro PC o raspberry arrancar el classicladder con entorno gráfico.
Cargar un programa con File->Load
Transferirlo al PLC tarjet con PLC->FileTransfer->Send Current Project To Tarjet y poner la IP del PLC tarjet (la raspberry pi).
Una vez que el PLC tarjet tenga el programa cargado arrancará en RUN cada vez que arranquemos classicladder en la raspberry pi.
Ahora podremos hacer PLC->Connect y poner la IP del PLC tarjet para monitorizar el estado y las variables del PLC. También podemos pararlo etc.

Podrá verse en el PLC tarjet distintos mensajes durante la recepción de datos.
Si todo va bién el programa recibido se grabará en «/usr/local/classicladder/nombredelprograma.clprjz»

CONECTANDOLO CON EL MUNDO REAL
Vale, esto es muy bonito, pero ¿y controlar directamente entradas y salidas reales desde la reaspberry pi y classicladder?. En principio basta con conectar el puerto serie de la raspberry, en el conector P1 pines 6(GND), 8(TXD) y 10(RXD) a cualquier dispositivo que use protocolo MODBUS (con el adaptador de nivel adecuado, la raspberry pi usa TTL a 3,3V).
Se puede usar un módulo IO MODBUS el propio autor del programa Marc Le Douarain: https://sites.google.com/site/classicladder/classicladder_io_module
También se pueden usar módulos ADAM de Advantech: http://www.advantech.es/producto/adquisicion-de-datos/data-acquisition-modules

Los pines tienen dos nombres: uno el original del chip (broadcom) y otro el que da el sistema operativo (raspberry pi):
Pines GPIO

¿Y por que no usar los pines GPIO directamente?. Son pocos, y puede que nos interese usarlos para mas cosas… pero como hace años ya diseñé una placa de ampliación de I/O (SIO) basada en registros de desplazamiento voy a revivirla y usarla aquí!!!!
Esta es el esquema adaptado a la raspberry pi, hay que conectar 8 hilos del conector P1 (6 señales y dos de alimentación) y listo.:

Esquema Shifted Input Output
Esquemas Eagle: http://heli.xbot.es/wp-content/uploads/2014/01/Raspberry_SIO.zip

La placa de registros de desplazamiento queda alimentada desde la raspberry pi. Ahora hay que modificar classicladder para que use este hardware. Hay varias formas de usar los GPIOs de la raspberry pi:
Mediante el sistema de archivos virtual «/sys/class/gpio»
Usando una librería como: http://www.open.com.au/mikem/bcm2835.
Accediendo directamente al hardware, esta es la que yo usaré: http://elinux.org/RPi_Low-level_peripherals#GPIO_Driving_Example_.28C.29
Despues de escribir el código mostrado y hacer unas pruebas veo que puedo escribir en los puertos sin problemas. Pero ¿y leer?. No hay ninguna función para leer los puertos en el ejemplo… Busco la datasheet del chip bcm2835 y busco el periférico GPIO. Perfecto en el apartado 6.1 (página 90), describe las direcciones de memoria donde estan mapeados los GPIOs, los pines se pueden en el offset 34h desde el inicio del mapa de GPIO. Como los accesos a memoria a 32 bit, para acceder a la dirección 34h usaré (gpio+13) porque (13*4) = 53d = 34h
Por lo tanto para leer los 32 GPIOs sería (g es el número de GPIO 0-53, gpio es la dirección base del periférico):
PINS_READ(g) *(gpio+(13+(g*3)) // Lee los 32 bits donde esta incluido el GPIO g
y para leer un pin individual:
PIN_READ(g) (((*(gpio+13)) & 1<< g)==1<< g) // Retorna el estado del GPIO g: 0 or 1 Me ha costado mucho que esto funcione, aunque hay mucha información acerca de la raspberry pi es dificil reunirla de forma consistente. Un problema que me ha hecho perder varias horas picando código y mirando con el osciloscopio es que el pin 13 de P1 (GPIO21 según Broadcom, o GPIO2 según Raspberry pi) en la versión V2 esta conectado a GPIO27 (según broadcom). El sistema operativo de la raspberry lo mapea a GPIO2 igual que en las V1, pero si se accede al hardware y no se usa el sistema operativo hay que tenerlo en cuenta!!! Ahora solo hay que incluir todo lo probado en el fichero "hardware.c" de classicladder y modificar "Makefile" para que se pueda compilar con o sin este hardware experiemental. Mis versiones de Makefile y hardware.c: http://heli.xbot.es/wp-content/uploads/2014/01/Makefile_y_hardware.zip
En Makeile ahora hay dos nuevos switches:
RASPBERRY_PI = 1
Si no se comenta con # al principio compila para raspberry pi.
MAKE_SIO_ACCESS = 1
Si no se comenta con # al principio compila con el hardware experimental SIO, esta opción puede usarse también para windows y para linux en entorno PC usando el puerto paralelo. Es similar a MAKE_IO_ACCESS.
Descargarse mi version desde la raspberry pi en el directorio «~/classicladder»:
«wget http://heli.xbot.es/wp-content/uploads/2014/01/Makefile_y_hardware.zip»
descomprimirla:
«unzip Makefile_y_hardware.zip»
Contestar «yes» cuando nos pregunte que si sobreescribe los ficheros existentes.
Compilarla:
«make»
Ahora para ejecutarla hay que hacerlo como superusuario. Esto es así porque necesita acceder a la menoria física del sistema (para leer y escribir en los GPIOs). Supongo que también funcionaría si el usuario tiene permisos de lectura y escritura sobre el dispositivo «/dev/mem».
«sudo ./classicladder»
Si alguien esta interesado en inspeccionar el código, las modificaciones hechas en «hardware.c» estan entre las directivas
#if defined (MAKE_SIO_ACCESS) – #endif

Asi se ve la placa SIO con la raspberry pi funcionando:
Esquema Shifted Input Output

CLASSICLADDER CON SIO EN PC
También podemos compilarlo para PC, si comentamos:
#RASPBERRY_PI = 1
en makefile. Si vamos a compilar bajo windows descomentamos:
WINDOWS = 1
Si lo hacemos bajo linux es necesario dejarlo comentado:
#WINDOWS = 1
Para usar el la placa SIO conectada al puerto paralelo hay que poner en «hardware.c» la dirección física del puerto LPT del PC:
#define SIO_PORT 0x378 // Base port for PC hardware LPT1, LPT2=0x278, LPT3=0x3BC
Y usamos este cable para conectar el PC con la placa SIO:

Esquema Shifted Input Output
Esquemas Eagle: http://heli.xbot.es/wp-content/uploads/2014/01/Raspberry_SIO.zip (El fichero contiene los dos esquemas, placa SIO para raspberry pi y cable PC).

El software es experimental, los parámetros de configuración deberían poder modificarse a través de los menús de «config_gtk.c», y estar definidos en «classicladder.h» en la estructura «infos_gene», por ejemplo. Pero para comenzar sirve…

He comprobado que con la raspberry pi es muy estable, sin embargo bajo windows se producen glitches periódicos que desactivan las salidas… Bajo linux (suse 12) también, pero en menor medida.
En windows con mas de un procesador va francamente mal, he tenido que incluir código para forzar el proceso en una sola CPU:
SetProcessAffinityMask(GetCurrentProcess(), 1); // Ejecutar solo en la CPU #1
Supongo que estos problemas son debidos al entorno multitarea, este mismo hardware con un micro PIC, atmel o similar y las mismas rutinas funciona perfectamente.

Yo no he usado una placa completa de 32 salidas y 32 entradas, sino una mas pequeña pero con entradas optoaisladas y con relés en las salidas (16 entradas y 8 salidas).

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

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.