Mini algoritmo de cifrado XXTEA para arduino

Estoy metido en tres fregados simultáneos de IOT (ahora se llama así, antes solo eran redes de sensores distribuidos) y estaba buscando un algoritmo de encriptación aceptable para dispositivos embebidos (no hay que perder de vista la seguridad de la IOT, que luego vienen los disgustos..)
De momento estoy usando Arduino Uno (Atmega328) y había reciclado un DES que usé en otro proyecto (librería de arduino http://spaniakos.github.io/ArduinoDES) pero como voy justo de memoria y tiempo de ciclo pensé en mejorarlo.

Valoré un AES del que también tengo librería para arduino https://github.com/DavyLandman/AESLib pero ocupaba demasiado espacio en flash.

Entonces me encuentro la sorpresa, viendo avr-crypto-lib un listado de algoritmos para micros AVR de atmel, veo que existe uno llamado XTEA muy sencillo de implementar y pensado para dispositivos embebidos. Desgraciadamente la implementación de avr-crypto-lib es muy básica y no es la versión mejorada XXTEA
Buscando por la red he encontrado algunas librerías de XXTEA para Arduino, pero son un calco de la publicación original y no aportan mejoras.

Después de un cortapega de la wikipedia y de machacar el teclado un rato he dejado el algorítmo bastante óptimo para Arduino.

En los test que he realizado, un arduino Uno a 16Mhz tarda en cifrar y descifra un bloque de 64 bytes:
Con DES en modo CBC tarda 284568us y ocupa 2572 bytes de flash
Con XTEA en modo CBC tarda 11008us y ocupa 916 bytes de flash
Con XXTEA tarda 4168us y ocupa 1086 bytes de flash
O sea que es rapidísimo y pequeñito…

La KEY es de 128 bits (mejor que el DES que solo es de 56) aceptable para mi aplicación. Se conocen ataques pero se basan en usar mas de 2^59 “textos planos escogidos”, también aceptable!!

El código es extremadamente sencillo, la única desventaja es que sobreescribe los datos planos con los datos encriptados, aunque he preparado una versión con un simple memcpy que soluciona este problema con unas decenas de microsegundos de trabajo extra.

El código fuente con DES, XTEA y XXTEA y algunas pruebas: XxteaTest

Mini programa para iniciar la EEprom del ATmega328 del Arduino UNO

Llevo bastante tiempo liado desarrollando aplicaciones para Arduino…
En algunos proyectos me encuentro que es dificil inicalizar la EEprom del Arduino (ATmega328). El IDE arduino (la version actual es 1.8.2) no genera los ficheros .eep que necesita avrdude para grabar el atmega, entonces declarar variables con EEMEM e inicializarlas en el IDE no sirve para nada.

Para solucionar este problema he escrito un pequeño programa que se carga en el arduino UNO (valdría para otros modelos con algunas modificaciones) y mediante comandos por el puerto serie permite leer o escribir la EEprom y dejarla ya inicializada. Luego se carga el programa que se necesite y se encuentra las EEprom inicada con los valores adecuados.

El proceso es el siguiente:
Se carga este programa en el Arduino UNO (renombrarlo a .ino):

SetEEprom.ino

A continuación se abre el monitor serie y se configura a 115200 baudios y enviar CR LF.
En el monitor serie se pueden escribir los comandos adecuados para ir iniciando la EEprom a los valores deseados. Lo mejor es prepararlo en un archivo de texto y hacer corta-pega sobre el monitor serie.
Estos son los comandos disponibles en el programa:

SetEEprom.txt

Por ejemplo se puede borrar toda ea EEprom (ponerla a 0xFF) con:
Write Init EEprom

Y luego iniciar una cadena de 10 caracteres en la dirección 0 con el valor “hola mundo”
Write String 0 10 Hola Mundo

y un bloque de 10 datos en la dirección 20:
Write EEprom 20 10 0F0302B1421CA7485823

Una vez iniciada la EEprom se carga el programa que necesitamos en el Arduino UNO y cuando arranque se encontrará la EEprom ya iniciada con los valores que introdujimos.

Solucion al crash en mame4all 0.37b5 para raspberry pi con 6 joysticks

Intentando configurar MAME en mi consola con RPI2 y retropie ( esta: http://heli.xbot.es/?p=365 ) con los joysticks /dev/input/js4 y /dev/input/js5 que son tipo PSX, veo que hay algún error en la distribución actual de mame 0.37b5.
Mame4all “casca” con “fallo de segmentación” (técnicamente es un “crash” con “segmentation fault”) cuando activo alguno de los botones de los joysticks, incluso aunque no estén configurados en el mame. Basta con tenerlos conectados y usarlos.

Gracias a que el software es de fuente abierta he podido analizar el código (es c y c++) y usando mis superpoderes de programador he conseguido encontrar el error y crear un parche que soluciona el problema.

En primer lugar es necesario descargar los sources actuales de mame4all para RPI.

Esta versión que distribuyen con retropie: https://github.com/RetroPie/mame4all-pi
Esta versión es un poco mas moderna, aunque solo tiene cambios precisamente en la gestión de joysticks de PSX, pero no solucionan mi problema:
https://sourceforge.net/p/mame4allpi/code/ci/master/tree/src/

Desde la RPI con conexión a internet hacer, como usuario pi desde su directorio personal:
git clone git://git.code.sf.net/p/mame4allpi/code mame4allpi-code

Esto creará un directorio “~/mame4allpi-code” con los fuentes actuales V0.37b5 a fecha de hoy (Octubre de 2016).
En “~/mame4allpi-code/src/rpi” se encuentran los dos ficheros que hay que modificar.
El problema se presenta porque se crea un array de 4 elementos para almacenar los datos de 4 joysticks. Un comentario en el código indica que solo se trabajará con 4 joysticks. Pero en una función posterior existe un bucle que rellena los arrays de datos de los joysticks. El buche tiene tantas interaciones como joysticks tenga el sistema (detectado mediante una llamada a la API). Entonces si esa llamada devuelve mas de 4 la función acaba escribiendo datos fuera del los arrays declarados.

En el fichero “minimal.cpp”, en la línea 140 se encuentra la función “int init_SDL(void)”
Voy a comentar los cambios necesarios y los problemas que problema el código original de “minimal.cpp”:
//SDL_Joystick* myjoy[4]; // Original: solo soporta 4 joysticks
SDL_Joystick* myjoy[6]; // Nuevo: Ahora tiene cabida para 6 joysticks

int init_SDL(void)
{
myjoy[0]=0;
myjoy[1]=0;
myjoy[2]=0;
myjoy[3]=0;
myjoy[4]=0; // Nuevo: Inicializar los nuevos elementos
myjoy[5]=0; // Nuevo: Inicializar los nuevos elementos

if (SDL_Init(SDL_INIT_JOYSTICK) < 0) {
fprintf(stderr, "Unable to init SDL: %s\n", SDL_GetError());
return(0);
}
sdlscreen = SDL_SetVideoMode(0,0, 16, SDL_SWSURFACE);

//We handle up to four joysticks
if(SDL_NumJoysticks)
{
int i;
SDL_JoystickEventState(SDL_ENABLE);

for(i=0;i<SDL_NumJoysticks;i++) { // Aqui estaba el problema, SDL_NumJoysticks() puede devolver mas de 4
myjoy[i]=SDL_JoystickOpen(i); // Pero solo habia mjoy[] para 4, si SDL_NumJoysticks() devuelve > 4 se escribe fuera del array!

Esto NO SOLUCIONA TODO EL PROBLEMA porque si el sistema tiene configurados mas de 6 joysticks estamos igual. Solo hemos actualizado el mame para que soporte 6 joysticks, pero cascará igual si hay mas.
La solución definitiva sería modifica la función “int init_SDL(void)” en minimal.cpp de forma que solo procese 6 joysticks independientemente del número de ellos que devuelva la llamada al sistema, así:
//We handle up to SIX joysticks
int NumJoysticks = SDL_NumJoysticks();

if (NumJoysticks > 6) NumJoysticks=6; // Ignoramos los demas joysticks
if(NumJoysticks)
{
int i;
SDL_JoystickEventState(SDL_ENABLE);
{
for(i=0;i<NumJoysticks;i++) { // Aqui estaba el problema,
myjoy[i]=SDL_JoystickOpen(i); // Ya no puede escribir escribe fuera del array!

A consecuencia de estos cambios también hay que modificar “input.cpp” para que pueda gestionar los nuevos joysticks:
En la línea 8:
unsigned long ExKey1=0;
unsigned long ExKey2=0;
unsigned long ExKey3=0;
unsigned long ExKey4=0;
unsigned long ExKey5=0; // Nuevo
unsigned long ExKey6=0; // Nuevo
unsigned long ExKeyKB=0;
// int num_joysticks=6; // Original: solo 4 joysticks
int num_joysticks=6; // Nuevo: ahora 6

En la función “void joyprocess(Uint8 button, SDL_bool pressed, Uint8 njoy)”
Uint32 val=0;
unsigned long *mykey=0;

if(njoy == 0) mykey = &ExKey1;
if(njoy == 1) mykey = &ExKey2;
if(njoy == 2) mykey = &ExKey3;
if(njoy == 3) mykey = &ExKey4;
if(njoy == 4) mykey = &ExKey5; // Nuevo
if(njoy == 5) mykey = &ExKey6; // Nuevo

y En la función “void gp2x_joystick_clear(void)”:

ExKey1=0;
ExKey2=0;
ExKey3=0;
ExKey4=0;
ExKey5=0; // Nuevo
ExKey6=0; // Nuevo

Lo mas rápido es descargar estos parches que ya he preparado con los cambios:
http://heli.xbot.es/wp-content/uploads/2016/10/minimal.patch_.txt
http://heli.xbot.es/wp-content/uploads/2016/10/input.patch_.txt
cd mame4allpi-code/src/rpi
wget http://heli.xbot.es/wp-content/uploads/2016/10/minimal.patch_.txt
mv minimal.patch_.txt minimal.patch
patch minimal.cpp minimal.patch
wget http://heli.xbot.es/wp-content/uploads/2016/10/input.patch_.txt
mv input.patch_.txt input.patch
patch input.cpp input.patch

Compilar y copiar el ejecutable al directorio que usa retropie:

cd ..
cd ..
make
sudo mv /opt/retropie/emulators/mame4all/mame /opt/retropie/emulators/mame4all/mame.old
sudo cp mame /opt/retropie/emulators/mame4all

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

Probando las fuentes de alimentación api3fs25 / 24R2639 12,2V 48A

Voy a probar un poquito la fuente…
Conecto dos resistencias de 1,1 Ohmios + 1,1 Ohmios en paralelo para que den 0,55 Ohmios y a su vez en paralelo de nuevo con otra igual. La resistencia total es de 0,275 Ohmios. A 12,2V circulará una corriente de unos 44A, cerca del límite de la fuente.
Uso treinta centímetros de cable de 6mm2 de sección para las conexiones de la carga.

Primera prueba, 12,09V medidos en la fuente y 43A (ó 42,9A incertidumbre de medida del amperímetro): 519,9 Watios!!!
42,9A midiendo en fuente

Segunda prueba, 11,97V medidos en la carga y 43A: 514,7 Watios en la carga. Tenemos 120mV de caida de tensión en los cables. A 43A son aproximadamente 5,2W de pérdidas que estarán usándose en calentar el cableado!!!
43A medido en carga

Ahora conecto las entradas SENSE- a GND y SENSE+ a +12V. Esto compensará los 120mV de caída y la tensión en la carga es ahora mas alta: 12,05V. Esto es importante para tener la tensión deseada justo en la carga, pero las pérdidas en el cableado continúan igual, ahora la fuente da 120mV mas que antes para compensarlas.
43A con SENSE

514 W son muchos watios, aunque las resistencias tienen circulación forzada de aire con un ventilador se calientan como una estufa: 209,9 Grados centígrados… y mas que mi termómetro no alcanza a medir:
Temperatura

También he observado que los cables estan a unos 35 grados y la temperatura ambiente es de 21 grados… ahí estan los 5,2W de pérdidas que medía.

Ahora conecto dos fuentes en paralelo y conecto el terminal CURRENT SHARE de una con el de la otra. 12,23V (se nota que trabajan mas descasadas) y 20A una de ellas, la mitad de la carga aproximadamente.
Dos fuentes A

La otra fuente entrega algo mas: 23,7A:
Dos fuentes B

Comprobado: las fuentes responden muy bien cerca del máximo de potencia. Una pena que no haya podido tenerlas unas horas probando, mi carga no soportaría disipar esa potencia durante tanto tiempo.

Usando una fuente de alimentación api3fs25 / 24R2639 12,2V 48A

Han caido en mis manos 4 fuentes de alimentación ACBEL modelo api3fs25 IBM P/N 24R2639 de 12,2V y 48A. Estas fuentes pueden proporcionar hasta 585W en una sola tensión de salida y son de calidad IBM (eran de dos servidores IBM Xseries x336). También pueden encontrarse en EBAY baratas http://www.ebay.es/sch/i.html?_from=R40&_trksid=m570.l1313&_nkw=api3fs25&_sacat=0
4 fuentes api3fs25

Para poder usarlas lo primero es analizarlas externamente… En una cara tienen un conector de aimentación para la entrada 220V con dos LED verdes AC y DC.
Parte trasera

En la otra un conector de flanco de tarjeta de doble cara con 20 contactos se señal y 6 contactos de potencia.
Parte delantera

Esta claro que será necesario buscar mas información para poder encenderlas al menos. Buscando api3fs25 y 24R2639 en google encuentro que son muy apreciadas como alimentadores para cargadores de baterías de RC:
http://www.rcgroups.com/forums/showthread.php?t=1005309&page=74

En www.rcgroups.com hay “algo” de información:
Fuente acbel

En principio la encienden conectando A8 con A10, pero otro autor usa A8 con B4: http://piercecollegefoundation.com/software/18539

¿Quien lo hace bien…? Porque yo he probado los dos métodos y funcionan!.

Vamos con un poco de ingenieria inversa, esta fuente es cambiable en caliente (HOT-SWAP) y ademas puede paralelizarse con otras (current sharing), o sea que será bastante complicadilla.
Lo primero es abrir la fuente para sacar un esquema parcial de las áreas que interesan:
Fuente abierta

El conector de flanco de tarjeta esta mayormente conectado a dos conectores J1 y J2 que unen la placa de potencia de la fuente con una pequeña placa montada perpendicularmente que contiene la elecrónica de control, regulación y protección.
Placa de regulacion

Esa placa contiene un PIC16F73, supongo que para controlar las funciones de diagnóstico. El controlador PWM es un UCC3895. También lleva un controlador para la conpartición de corriente (load share controller) uc3907.

Lo mejor es dessoldar la placa para poder hacer el esquema mas comodamente, aunque luego tenga que volverla a soldar en su lugar.
Placa dessodada

El borrador del esquema parcial de la zona digital de la placa es este (algun fallo en la polaridad de los transistores??? … es un borrador):
Zona digital

De este esquema se puede deducir que la fuente lleva varias entradas y salidas de diagnóstico y comunicaciones….
¿Era correcto conectar A8 a A10 ó B4 para encenderla? NO.
La conexión A8 es, efectivamente, la señal “Power ON”. Va conectada a una pata del PIC de uso general (Pin 28, RB7) y tiene un pullup (3K a +5V). En estas condiciones dejarla al aire introduce un 1 en el PIC y la fuente se mantiene apagada.
Introduciendo un 0 debería encenderse, comno así ocurre, pero ni A10 ni B4 son terminales de masa. B4 es SENSE- que es “casi” masa pero usarlo para encender la fuente introducirá un voltaje extraño en SENSE- y hará que varíe la regulación de tensión.
A10 es una entrada/salida de señalización, se pone a 0 cuando se enciende el LED verde DC de la trasera. Esta salida va conectada al colector de un transistor NPN y la base a la pata 17 del PIC (RB6) y un transistor NPN. Otro transistor enciende el LED verde. Para que el LED verde se encienda es necesario conectar un pullup externo, de forma que esta patilla acual como salida de señalicación y entrada para controlar el LED (si el PIC de la fuente lo permite).

La forma correcta de encender la fuente es unir A8 con B10.

B10 es GND, la misma GND que la del conector de potencia. El server identifica que la fuente esta conectada cuando ve esta conexión a masa.

B9 y B8 son salidas +5V VSB de 200mA. Estas salidas estan siempre presentes mientas este alimentada la fuente, aunque no este encendida.

A10 es la salida de la señal DC (igual que el LED trasero DC) y A9 es la salida de la señal AC (igual que el LED trasero AC)

A2 (pin 17 del PIC) y A3 (pin 16 del PIC) son ENTRADAS que indican a la fuente su posición en en server 00 la de la derecha y 01 la de la izquierda (visto desde la parte trasera del server). Sirven para seleccionar la dirección de la fuente en el bus I2C.

A4 (pin 22 del PIC) y A7 (pin 18 del PIC) son entradas /salidas de control (A4 podría ser /RESET) conectadas a la lógica del server.

A5 (pin 14 del PIC) y A6 (pin 15 del PIC) son SCL y SDA respectivamente. Posiblemente un SMBUS basado en I2C que se suele usar en el control de energía de los ordenadores. He probado a interrogarlo con el BusPirate y ha respondido a una direccion, que dependiendo del estado de A2 y A3, es: (en binario 001000A2A3) o sea e 0x20 a 0x23.
Esto solo si se mantiene A4 a 0, si se pone a 1 responde también a otra dirección: (en binario 010100A2A3) o sea e 0x50 a 0x53.
No he conseguido que esa dirección me responda a ningún comando, posiblemente el protocolo usa PEC, un chequeo de integridad de mensajes basado en CRC8 y yo no estoy enviando mensajes válidos…

B1, B2 y B3 van en paralelo en las dos fuentes que montanlos servers, son salidas de estado en colector abierto. La B1 se pone a 0 cuando la fuente arranca, y continua a 0 hasta que se quita tensión. Poniendo A4 a 0 se apaga (es A4 algún tipo de RESET?). No he investigado mas.

Este es el PINOUT del conecor de flanco de tarjeta, y del conector ICSP para programar el PIC:
Pinout API3FS25

La parte analógica es bastante compleja y solo he obtenido el esquema de la parte que me interesaba para la regulación de tensión.
Regulación de tensión

En los foros de RC he leído acerca de métodos para variar la tensión de salida (que funcionan) pero ¿son adecuados?.
Variar la tensión en www.rcgroups.com
Variando la tensión

Para aumentar la tensión de salida recomiendan conectar una resistencia de 33K entre dos puntos determinadados (color verde en la imagen).
Según mi esquema eléctrico estos puntos corresponden a los extremos de la resistencia de 6K (que puede verse en el esquema rotulada como 76b). La resistencia de 33K quedararía en paralelo con esta de 6K resultando una resistencia equivalente de 5,07K. Con el potenciómetro el mínimo (máxima tensión) la salida sería de 14,5V.
Esto es correcto, es la forma adecuada de aumentar el máximo de la tensión de salida. No se verá afectada la calidad de la regulación, aunque hay que tener en cuenta que los condensadores de la fuente son de 16V y estaríamos bastante cerca del límite de trabajo y se acortará su vida útil.
Para disminuírla recomiendan conectar una resistencia de 10K entre la pata 10 del UC3907 y un extremo del potenciómetro de regulación de tensión. Aunque funciona esto no es correcto porque la pata 10 del UC3907 es la alimentación del mismo, que viene de otra sección de la fuente de alimentación. Estamos introduciendo en el circuito de regulación de una fuente una tensión proveniente de otra fuente por lo que van a interferirse. Variará la tensión de salida al variar la tensión de la fuente interna, cuando deberían ser independientes entre si.
La forma correcta de disminuír la tensión mínima de la fuente es sustituir el potenciómetro de 500 ohmios por otro de otro valor. Por ejemplo con uno de 10K se puede conseguir que la tensión mínima baje hasta 6,5V. Por desgracia las otras tensiones internas de la fuente también bajan y la fuente se vuelve inestable en estas condiciones, llegando a no arrancar. Pero 7,2V si es una tensión bastante baja a la que la fuente funciona bien.

Regulacion
Eliminando la resistencia SMD de 6K y conectando un potenciómetro de 10K con una pareja de resistencias en serie de 2K2 y 3K3 en los puntos que se ve en la foto se consigue una variación de tensión de 6,13V a 13,57V.

A1 sirve para que las fuentes se coordinen en la corriente que entregan cuando se ponen en paralelo “current share”. Si se van a conectar varias fuentes en paralelo hay que conectar entre sí todas las trata de unir todas las conexiones A1 de todas las fuentes. De esta forma se coordinan y si una tiene algunos milivoltios mas de regulación de tensión no entrega mas corriente, sino que la demanda de corriente se balancea autmáticamente entre todas las fuentes. Este trabajo lo controla el integrado UC3907.

A4 y A7 son SENSE- y SENSE+. Si no se usan no pasa nada, estan conctadas iternamente a GND y +12V mediante series de resistencias de 10 ohmios. Pero si queremos tener un control preciso de la tensión en el punto de conumo debemos unir SENSE- con GND y SENSE+ con +12V justo en el punto de consumo (carga). Estas señales son las que realimentan al circuito de regulación de tensión y la fuente intentará mantener la tensión programada justo en el punto donde se conecten SENSE- y SENSE+ independientemente de la tensión de salida. De esta forma se compensa la caida de tensión en los cables.

He construido unos conectores de flanco de tarjeta macho con unos trozos de circuito impreso de doble cara y una fresadora de PCBs.
Conectores

Listo para probar:
Conectores listos

El esquema de prueba es este:
Esquema de prueba

Para probar la fuente “con chicha” dispongo de dos resistencias bobinadas de 2,2 Ohmios de unos cientos de watios. Conectándolas en paralelo tengo una resistencia de 1,1 Ohmios que a 12,2V son 11,09A, pero tienen que disipar 135W !!!. Con un ventilador de PC ayudaré a disipar el calor para poder probar durante unos minutos…

Listo para jugar:
Probando...