API para el 68K

He encontrado las API's para el 68K y la descripcion de las estructuras de Administracion de Datos seriales, Constantes Serial Manager,funciones del Serial Manager, Serial Manager Application-Defined Functions.

Aca posteo algo:

Serial Manager Data Structures

DeviceInfoType Struct

Proposito
El proposito de la estructura DeviceInfoType es definir la informacion del dispositivo. Esta estructura es devuelta por la funcion SrmGetDeviceInfo().

SrmOpenConfigType Struct

Proposito
La estructura SrmOpenConfigType especifica los parametros para la apertura del puerto serial. Esta estructura es pasada como un parametro SrmExtOpen().

Husmeando el puerto USB

Estuve haciendo sniffing sobre el puerto usb al conectarle un teclado y aquí tengo los resultados.

Al conectar el teclado se envian y reciben varios datos... una vez que el protocolo ya esta iniciado, solo se envía la información de la tecla presionada y nada más.

Ahora solo hay que averiguar que es lo que envía el HOST (PC) al controlador integrado del teclado para que éste comience a enviar los datos de las teclas presionadas.

ESTO ES LO QUE SUCEDE CUANDO SE ENCHUFA EL TECLADO EN UN HOST CON WIN XP:

000005: PnP Event: Query ID (UP), 11.05.2006 18:34:20.3906250 +93.4062500
Hardware IDs: USB\Vid_0a81&Pid_0101&Rev_0110&MI_00, USB\Vid_0a81&Pid_0101&MI_00
000006: PnP Event: Query ID (UP), 11.05.2006 18:34:20.3906250 +0.0
Compatible IDs: USB\Class_03&SubClass_01&Prot_01, USB\Class_03&SubClass_01, USB\Class_03
000007: Get Descriptor Request (DOWN), 11.05.2006 18:34:20.4218750 +0.0312500
Descriptor Type: Device
Descriptor Index: 0x0
Transfer Buffer Size: 0x12 bytes

000008: Get Descriptor Request (UP), 11.05.2006 18:34:20.4218750 +0.0
Descriptor Type: Device
Descriptor Index: 0x0
Transfer Buffer Size: 0x12 bytes

000009: Get Descriptor Request (DOWN), 11.05.2006 18:34:20.4218750 +0.0
Descriptor Type: Configuration
Descriptor Index: 0x0
Transfer Buffer Size: 0x9 bytes

000010: Get Descriptor Request (UP), 11.05.2006 18:34:20.4218750 +0.0
Descriptor Type: Configuration
Descriptor Index: 0x0
Transfer Buffer Size: 0x9 bytes

000011: Get Descriptor Request (DOWN), 11.05.2006 18:34:20.4218750 +0.0
Descriptor Type: Configuration
Descriptor Index: 0x0
Transfer Buffer Size: 0x22 bytes

000012: Get Descriptor Request (UP), 11.05.2006 18:34:20.4218750 +0.0
Descriptor Type: Configuration
Descriptor Index: 0x0
Transfer Buffer Size: 0x22 bytes

000013: Select Configuration (DOWN), 11.05.2006 18:34:20.4218750 +0.0
Configuration Index: 1

000014: Select Configuration (UP), 11.05.2006 18:34:20.4218750 +0.0
Configuration Index: 1
Configuration Handle: 0xfe6d2980
000015: Class-Specific Request (DOWN), 11.05.2006 18:34:20.4218750 +0.0
Destination: Inrterface, Index 0
Reserved Bits: 34
Request: 0xa
Value: 0x0
Send 0x0 bytes to the device
000016: Control Transfer (UP), 11.05.2006 18:34:20.4218750 +0.0
Pipe Handle: 0xfe747568

Setup Packet

 21 0A 00 00 00 00 00 00
!.......
Recipient: Inrterface
Request Type: Class
Direction: Host->Device
Request: 0xa (Unknown)
Value: 0x0
Index: 0x0
Length: 0x0
000017: Get Descriptor Request (DOWN), 11.05.2006 18:34:20.4218750 +0.0
Descriptor Type: Unknown
Descriptor Index: 0x0
Transfer Buffer Size: 0x81 bytes


000018: Control Transfer (UP), 11.05.2006 18:34:20.4218750 +0.0
Pipe Handle: 0xfe747568


 05 01 09 06 A1 01 05 07 19 E0 29 E7 15 00 25 01
 75 01 95 08 81 02 95 01 75 08 81 01 95 03 75 01
 05 08 19 01 29 03 91 02 95 05 75 01 91 01 95 06
 75 08 15 00 26 FF 00 05 07 19 00 2A FF 00 81 00
 C0
....¡....à)ç..%.
u.•..•.u..•.u.
....).‘.•.u.‘.•.
u...&ÿ.....*ÿ..
À
Setup Packet

 81 06 00 22 00 00 81 00
.."...
Recipient: Inrterface
Request Type: Standard
Direction: Device->Host
Request: 0x6 (GET_CONFIGURATION)
Value: 0x2200
Index: 0x0
Length: 0x81
000019: PnP Event: Query ID (UP), 11.05.2006 18:34:20.4375000 +0.0156250
Device ID: USB\Vid_0a81&Pid_0101&MI_00

000020: PnP Event: Query ID (UP), 11.05.2006 18:34:20.4375000 +0.0
Hardware IDs: USB\Vid_0a81&Pid_0101&Rev_0110&MI_00, USB\Vid_0a81&Pid_0101&MI_00

000021: Class-Specific Request (DOWN), 11.05.2006 18:34:22.1250000 +1.6875000
Destination: Inrterface, Index 0
Reserved Bits: 34
Request: 0x9
Value: 0x200
Send 0x1 bytes to the device


 01
.

000022: Control Transfer (UP), 11.05.2006 18:34:22.1250000 +0.0
Pipe Handle: 0xfe747568


 01
.
Setup Packet

 21 09 00 02 00 00 01 00
!.......
Recipient: Inrterface
Request Type: Class
Direction: Host->Device
Request: 0x9 (Unknown)
Value: 0x200
Index: 0x0
Length: 0x1
 
 
Esto es lo que sucede cuando presionamos la tecla "a":
 

000045: Bulk or Interrupt Transfer (UP), 11.05.2006 18:37:01.7343750 +12.9062500
Pipe Handle: 0xfe536a84 (Endpoint Address: 0x81)
Get 0x8 bytes from the device:

00 00 04 00 00 00 00 00

........

000046: Bulk or Interrupt Transfer (UP), 11.05.2006 18:37:01.8437500 +0.1093750
Pipe Handle: 0xfe536a84 (Endpoint Address: 0x81)
Get 0x8 bytes from the device:

00 00 00 00 00 00 00 00

........

IDEM PARA LA TECLA "b":

000047: Bulk or Interrupt Transfer (UP), 11.05.2006 18:50:16.6250000 +794.7812500
Pipe Handle: 0xfe536a84 (Endpoint Address: 0x81)
Get 0x8 bytes from the device:

 00 00 05 00 00 00 00 00
........
000048: Bulk or Interrupt Transfer (UP), 11.05.2006 18:50:16.7187500 +0.0937500
Pipe Handle: 0xfe536a84 (Endpoint Address: 0x81)
Get 0x8 bytes from the device:

 00 00 00 00 00 00 00 00
........

Algo de Comunicacion Serial

Esto es algo de lo que estoy leyendo y creo que esto es un poco util:
A partir de los Procesadores ARM para el ordennamiento de los bytes se utiliza "litle Endian", y que la aplicacion es responsable de la diferencia de orden del copiado de los byte.

"Little Endian" significa que el byte de menor peso se almacena en la dirección más baja de memoria y el byte de mayor peso en la más alta.

Así, un Long Int de 4 bytes

Byte3 Byte2 Byte1 Byte0

se almacenará en memoria de la siguiente manera:

Dirección Base +0 ===> Byte0
Dirección Base +1 ===> Byte1
Dirección Base +2 ===> Byte2
Dirección Base +3 ===> Byte3

Por otro lado el Serial Manager a partir del Palm OS Cobalt la API conocida como "Nueva Administracion Serial" las funciones que comienzan con "Srm" son soportadas, mientras que las funciones del viejo Serial Manager que comienzan con "Ser" no son soportadas bajo Palm OS Cobalt, version 6 o superior.

Debido a que ahora el Serial Manager esta basado en la arquitectura de E/S de la Palm OS Cobalt, el concepto de "Drivers Seriales Virtuales" ya no es aplicable. El Serial Manager trabaja con los subsistemas de E/S y el Connection Center para el soporte de cualquier interfaz de comunicación.

EL Serial Manager recibe datos de forma Asincrona. EL API Serial Manager se ejecuta de forma sincronica. Si una funcion del Manager Serial se bloquea durante su ejecucion, esta no inhabilita la posibilidad de recibir datos.

Material sobre Comunicacion de alto y bajo nivel

He encontrado unos apuntes de como se realizan las comunicaciones de alto y bajo nivel y se encuentra lo de transmision USB, por lo visto hay algunas API que simplifican un poco el proceso.

Pruebas con el puerto

Estuve capturando las transmisiones del teclado hacia la pc para ver que obtenía. Quiero entender que hace el teclado para empezar a transmitir los datos de las teclas presionadas. La cosa es mas o menos así: el usb tiene muchos datos acerca del protocolo, que son necesarios para poder enchufar varios dispositivos (127) a un solo host y que no se choquen. Tambien identifica el dispositivo, lo enumera, le asigna algunas propiedades y hasta saca los datos del fabricante... muchas cosas que no vamos a necesitar cuando lo que queremos en realidad es que envie la informacion de las teclas presionadas a la palm. No vamos a tener varios dispositivos enchufados al mismo tiempo, no necesitamos asignarle interrupciones, y ni siquiera necesitamos saber si es en realidad lo que enchufamos en la palm un teclado. Simplemente activamos un programa en la palm que toma los datos que recive de un dispositivo conectado a ella por los cables DATA + y DATA - del puerto minUSB, y los convierte a letras. Si luego enchufamos un pendrive, no nos importa, escrbirá basura.
Si logro acceder al hardware directo desde la palm, con leer los cambios de tension que generan las teclas al ser pulsadas bastaría para tranformarlas en información. El primer problema que surje es que no se si el teclado empezará a enviar la información de las teclas presionadas si no recibe una confirmación de que puede empezar a hacerlo. Es por eso que voy a enchufar el TEclado USB a un Osciloscopio para registrar los cambios de tension en las patas de datos al presionar teclas. Todo esto sin enviarle ningun tipo de información al teclado. Si no emitiera nada al presionar las teclas habría que diseñar algo que le envíe la informació protocolar para empezar a transmitir. Pero no veo por que si el card export puede enviar la información de descriptor de medios al Host, yo no voy a poder enviarle al teclado la informacion necesaria para que comience a transmitir? No creo que requiera de ningun hardware específico, tan solo una batería de alimentación para el teclado.

Etapa de recopilacion de información

Estoy buscando material sobre el modo de enviar datos en el usb. No protocolos sinó más bien la capa física. Si averiguo como recibir y enviar datos lo unico que queda por hacer es capturar lo que envía el teclado al presionar una tecla y luego convertir esa información en un dato en la palm.
Si alguien sabe algo sobre la tensión con la que trabajan los cables de datos o si consiguen los bits que envían las pulsaciones de un teclado usb, por favor pónganse en contacto.
Por lo pornto conseguí analizadores de bits por software y voy a ver que informacion consigo haciendo unas pruebas.

Comienzo

Empezamos el proyecto...
La idéa es simple y el blog es simple.

Dos personas con conocimiento de programación y circuitos electrónicos tratan de encontrar la forma de conectar un teclado USB flexible al puerto miniUSB de una Palm Zire72 y lograr que funcione.