🖱 PS2 Mouse 🐭!

[charli va]

Hola a todos! os traigo una novedad, tenemos ratón usb/ps2! Abro nuevo hilo para separarlo el teclado.

Os dejo aquí el vídeo, para no sobrecargar los mails lo he subido a youtube:

https://youtu.be/6gbCgUIcYJ0

He estado trabajándolo con Demócrito si alguien se anima a probarlo sería fantástico, para confirmar que más o menos al igual que el teclado puede funcionar de forma más o menos general.

He hecho una redada importante de búsqueda por foros retro, Google....y en última instancia a la desesperada  pregunté a chatGPT sobre si había una forma de detectar la compatibilidad USB/PS2 que comentaba Fernando, también sin éxito. La ausencia de documentación es abrumadora, al final parece que no hay manera de detectarlo salvo probarlo. He buscado incluso bases de datos de dispositivos que lo soporten, pero tampoco existe el dato.

Parece que es un capricho del ingeniero que haya diseñado el dispositivo en cuestión. Al inicio de la incursión de los teclados y ratones usb,  parece que absolutamente todos los fabricantes lo metían, posiblemente como una forma de no cerrarse puertas al vender y no dar problemas de compatibilidad con el rey de la pista en ese momento.

Con el tiempo no tengo muy claro que dirección han tomado los fabricantes, parece bastante aleatoria  la decisión, o fruto del "copy/paste" porque por las pocas pruebas que he podido hacer y todos los posts que he visitado por foros, parece que no depende ni de si es de buena/mala marca, más antiguo o más nuevo. Me ha pasado una cosa surrealista como que en el mismo pack de ratón y teclado (en este caso el del pack de la RPI4) el teclado no soporta ps2 y el ratón sí.

Por aclarar, ni teclados ni ratones inalámbricos funcionan, estos al ser un transceiver usb/wireless  no mantienen ningún tipo de compatibilidad  (al menos todos los que hemos podido probar en esa línea no funcionan, y tiene su lógica, al ser este tipo de dispositivos totalmente anacrónicos al ps2).

Así que como conclusión para este tema sólo nos queda la prueba y error y compartir los modelos usados por tener alguna referencia.

Sin enrollarme más os adjunto el setup que he usado. Como al final el adaptador es un mero reconfigurador de cables, he optado por quitarlo y usar un socket USB sin más. Le he puesto los pullups externos con los valores que indicó Jesús (esto si que he comprobado que es importante, se ve que en algunos dispositivos sin el pullup la señal no tendrá suficiente voltage y la fpga no es capaz de detectar el cambio) y por no cerrarnos a primitivas de la ice40 por si alguien lo prueba con una ecp5 , los he preferido poner físicamente.

Por si alguno no localiza el mensaje de Jesús , aquí lo tenéis:

https://groups.google.com/g/fpga-wars-explorando-el-lado-libre/c/4x5SkqCPb_Q/m/2TE1QKnxBgAJ

También os dejo el diagrama del equivalente en ps2 al conector  usb (si usáis un teclado o ratón usb conectado a un  socket usb, simplemente os lo dejo para que sepáis dónde conectar clk y data):

El mérito no es mío, he localizado un código open source que he utilizado.  El código original es este, de John Clayton:

https://web.mit.edu/6.111/www/f2005/code/ps2_mouse.v

El único tema es que a mi al menos, el código original no me ha funcionado, en mi ratón se quedaba atascado en un estado del FSM esperando a recibir un ACK (esto me genera dudas de compatibilidad de protocolo, por lo que si alguien lo prueba sería genial para ir comprobando si le funciona a más gente, vamos saliendo de dudas).

En el código original hay dos módulos, el que he implementado (ps2_mouse_interface) y luego uno a modo de top level que lo usa el autor a modo de demo/main. Este último no lo he utilizado, he montado un main de prueba directamente en icestudio.

Del módulo que he utilizado  funcionaba perfectamente la inicialización del ratón (tema clave en los ratones ps2, si no inicializas bien el ratón se queda en modo disabled y aparentemente es como si estuviera muerto), pero después se quedaba atascado (no hacía nada), sin embargo en el osciloscopio empezaba a verse actividad al mover el ratón. Depurando un poco, encontré que el problema es que se quedaba enganchado en el estado m2_error_no_ack de la FSM.

Esto creo que puede ser un bug y que el código funcione en algún ratón en concreto pero no generalice, la solución que he pensado es bastante sencilla aunque no sé si robusta, símplemente cambiar :

m2_next_state <= m2_error_no_ack por m2_next_state <= m2_wait en el estado m2_error_no_ack. 

Esto asegura que el módulo no se atasque si falla el ack del ratón y pueda intentar recibir datos nuevamente, básicamente tiene una máquina de estados que espera un ACK y básicamente no le llega, no sé si por evolución de los ratones o por algún otro bug, pero bueno la realidad es que así funciona de lujo, aunque habría que revisarlo porque aquí hay algún bug/error o similar. 

En cualquier caso como veis en el vídeo que os adjunto a mi me ha funcionado bien, ahora es ver si es generalizable y funciona en muchos ratones.

Luego he ajustado el código para que funcione a 12MHz porque la temporización es clave (el código está para una placa de xilinx a más megaherzios ), así que los parámetros son claves y los valores los he calculado para temporizar contando los 12Mhz de la Alhambra,

 esto sería ideal calcularlo automáticamente pero bueno de momento vamos andando:

WATCHDOG_TIMER_VALUE_PP = 4800 (400 µs).

WATCHDOG_TIMER_BITS_PP = 13.

DEBOUNCE_TIMER_VALUE_PP = 45 (3.75 µs).

DEBOUNCE_TIMER_BITS_PP = 6.

Para seguir FSMs si son complejas o largas, suelo usar mermaid que de paso, puede quedar algún gráfico chulo para documentar, aquí os dejo por si os interesa la fsm del código del ratón (la url es un chorizo porque contiene en sí el diseño):

https://mermaid.live/edit#pako:eNplk-Fu2jAQx1_l5M-0C0kDTbRVohBaqrWq6NQPCxUyzlEsgp05TlUKPMyeYdoLrC-2ixM2TcuXxOf__3d39mXHhM6QxezZ8GIFX0YzBfQM0omSQmr4AFMs0T7ByckFXFJ0JRfSQFH6c5Gv4ePCXMCZ58Gvn-VTY7100mGaqBfJDQi94SrT4L2Ozxp5ovgiR3iwBvkGbil96xw65yhNygINWQ2WRYWl5ZBhDobb9x-qQRBs0JpGtWk_EGuSC6ot03tIUqJqQMdpHJ9laTUUnNYZt7r8z73kee7M4zQxRhtQes5F2-EUZX0cdTtS5Lo1j129SbNIHGmEFoUl3TLnSlAJ6nhUe7hKpyh03uwX_FtF2gYfBLCQ9ljTlSPdtwI6vyJHS4Vdp49o5FKKv_bWce0cj-_fmw4m6b3RAkvSuV6bJANhK57LN4qW9M54-Y_7TsPLEdC2NHH93aR32rZpG1xen2VLpQif00VmW_gE3ZZ444h1tA4Sj3XYBs2Gy4wmbVeLZsyucIMzFtNnxs16xmbqQDpeWf2wVYLF1lTYYVVBKXAkOQ3o5hg0unpesZjurKRVwdVXrf9sYiatNrfNWLvpdhIW79gri_2ge9rrhUH3PIqCbhh1gw7bsjigoBf2_TAK_Cjyw_NDh705qHca9b3QDzwa837QD7u9Dv0sdSdtLagyNENdKUuYyDv8Bm8KDwU

Este es más en detalle:

https://mermaid.live/edit#pako:eNqVVtty2jAQ_RWNZpInksE2BPAkmeEakkD6EJ5aMh5hK1gTI1FZbkJu_9Jv6Cfkx6q1IbGAGsoDl909Zw-7q7VesC8Cil08lWQeolFnzJF-xckkM4zxzHJRhyrq--zjD0cBRfcR4b6IEeVoHtueHz2McQaD19Bq_phZYPVCdDqR58iPKOFgQGfIukNHR-ev70vgqw5vQfg9iSLGpx4NpjRDGRYA5lO0gEV_tvPYR8KUEdVOcwV0IhLuU0-xGZVeIDiFtJ2VysjAdFJMTl4X4iSLTXV5w7q47lJcL4cEbduqkcf1iuQ2s0jKgzHf7JHtorbgSooIzSXjPpuTCFHEOPMZidgzSZtntMnWbbI9SWOq7jLBdgssoYiCrC6Z3mUpvJB5z1pyOS_ZTvvw-kiUHwZimpOMDtH75z_V-u02cAdEES8Sj571xZ3atpJn7ctX-hBNmPJ8XR-Fzs6QA8SdT-KQTcN_MRuVtju7mCvA3DUk2_tI7u4irgJxz5Rs7yO5t4u5AcwXhmRnH8kX68TA0zcVOvso7KdExrHVQ7DCAOslsBI4CjB3c8FjupshT3AFBFRKIT0uPOI_ZLoMy7qsy5TUKJVtA9k1kP2ikt0vDMDV8jQMwL--U-zrbD_oTFR5UyECoBpCaBIvd4NI1DxRXqyP42RjOywJ3tcYBvmQ4UpB3jjYKA7gbiDzlKiQSiPLTcHBNGox-jZqDrzW5eg2rcn_c5yuUbQKF5Xjoj7hQRySBwrPEt1Z_SSJWKw_jPXk6PXkZNMmKQkWX93-sqWznIo0Sq5VOC0TvQVpdMXJFhn4AL25bA8OYMHSJ6bf4MmnJEWzj98_E8ZJnIXoHZ2SGGuvtfK1trZvUOy-Wbm72w5pu9DbKfR2C729Qu9Fsej-0p2N8WZrmriE9STNCAv0veMFosdYD_CMjrGrvwZEpheKNx1HEiVuF9zHrpIJLeFkrntIO4zogZphV6eOtVWKZBp-_poT_l2I2QpCA6aEHGa3nPSyk4Zg9wU_YdeqlI-tul2xauVKreLUrJMSXmD3pHpslWt2vVKuV2tOtdp4K-HnlLR83LDr9ZOKYzVqVqVetqySvjvBX8nSST00VLbhaGC3ZtXe_gLRrer2

Y esto es todo amigos! os dejo el fichero de icestudio, el verilog generado por icestudio y el bitstream por si sólo queréis subirlo a la Alhambra para probar.

El setup es D0 como CLK y D1 como data.

Lo que hace la demo es usar los 8 leds con el formato:

Bits 0-2 : LSB posición X
Bits 3-5: LSB posición Y
Bit 6: botón izquierdo.
Bit 7: botón derecho.

Si validáramos que es un módulo más o menos estable o terminamos de depurarlo puede dar mucho juego.

Espero que lo disfrutéis tanto como yo en este proceso.

¡Buena tarde!

[Jesus Arias]

Hola,

El ratón es algo más complicado que el teclado porque necesita de una comunicación en los dos sentidos. El teclado PS2 también es bidireccional, pero si lo hacemos de sólo entrada no perdemos mucho: el poder encender los LEDs y poco más. Y lo malo de la bidireccionalidad, aparte de tener que incluir  también un transmisor en el diseño, es que complica la adaptación de 5V a 3.3V si la queremos hacer bien...

Saludos

[charli va]

Hola Jesús, efectivamente, en el ejemplo que os he pasado funciona tanto datos como clk como inout y en mi dos ratones funciona bien pero en uno de Demócrito no. En los que funciona se reciben los datos correctamente, es un modo ps2 no usb, el ratón tiene que soportar el ps2 igual que el tema del teclado.

Estoy trabajando con Demócrito en el usb puro os iremos contando!.

--
Has recibido este mensaje porque estás suscrito al grupo "FPGAwars: explorando el lado libre" de Grupos de Google.
Para cancelar la suscripción a este grupo y dejar de recibir sus mensajes, envía un correo electrónico a fpga-wars-explorando-el...@googlegroups.com.
Para ver este debate, visita https://groups.google.com/d/msgid/fpga-wars-explorando-el-lado-libre/d5a55fdc-c2e9-4aea-ba92-abba763d10c7n%40googlegroups.com.

[Jesus Arias]

Hola,

Este podría ser un posible circuito para la adaptación de niveles bidireccional. Tiene un truco, y es que cuando la tensión en el colector es baja el transistor funciona al revés (el emisor pasa a ser el colector) Y aunque en este caso el transistor es muy malo (hfe < 10) todavía sirve para lo que queremos.

Saludos

[charli va]

Me encanta todo lo que nos mandas siempre, no paro de aprender contigo.

Lo que no entiendo muy bien es por qué necesitamos esto para el ratón? creo que me he perdido en algún punto , no debería el ratón ser capaz  de gestionar el tristate que gestionamos desde la FPGA? Necesito comprender , ilumíname! :) 

Por otro lado os comparto un GRAN avance, tengo en unas 400 LCs un módulo usb low speed nativo para ratón :) según te leía, estaba subiendo el bitstream y como si fueras un chamán que hubiera lanzado sus palabras mágicas, el osciloscopio ha empezado ha moverse y se me ha parado el corazón :).

Demócrito me picó con esto, tuvo una auténtica genialidad, aunque parezca super obvia no se me había pasado por la cabeza y aunque esté siendo un mini proyecto a ratos, me ha generado mucha frustración (el tema usb, han sido días de osciloscopio plano sin saber en dónde narices estaba el error porque esque ni se movía 1mm).

La idea es minimizar al máximo posible el protocolo usb sabiendo que vamos a conectar un ratón y en conexión directa. Esto que parece obvio no lo es y con lo #@$!%& que es el protocolo usb, el recorte no es trivial. Por suerte llevo tiempo pegándome con el usb para otros temas a nivel software y con la frase de Demócrito se me alinearon las estrellas y más o menos creo que casi lo tenemos.

Tengo que verificar si lo que está llegando lo interpreto bien, pero en el osciloscopio las tramas  tienen muy buena pinta (y son de ida y vuelta, con la enumeración, asignación de dirección al dispositivo ,etc).

Voy a ver si monto alguna demo visual que podamos comprobar si lo que llega tiene pinta de coordenadas y si puedo os lo mando esta misma tarde para si os apetece me echéis una mano. Con esto funcionando el teclado lo puedo tener en un pispás, y posiblemente lo podamos optimizar mucho más.

Os dejo un vídeo del progreso, los leds ahora son de debug, estados de la fsm, un divisor de frecuencia y luego algunos con datos pero como va muy rápido simplemente se ve que están a medio gas por la frecuencia de muestreo pero vamos que la cosa está viva. En el osciloscopio el D+y D- con los mensajes de un lado para otro (y en el usb si el ratón responde es porque entiende lo que le mando si no se queda mutis o incluso se apaga, así que super buena señal):

https://youtube.com/shorts/ltsLNFn8TOk?feature=share

Un abrazo y buena tarde a todos!

Para ver este debate, visita https://groups.google.com/d/msgid/fpga-wars-explorando-el-lado-libre/d76475c1-c413-49ce-9fe1-41ca95a1507cn%40googlegroups.com.

[Jesus Arias]

Hola Carlos,

El ratón PS2 podría generar tensiones de 5V y no queremos que lleguen a los pines de la FPGA. Seguramente la resistencia de 200ohm que tiene la Alhambra en serie con cada pin es suficiente para evitar daños en la FPGA, pero me parece una resistencia un tanto pequeña. Puede que esto sea algo paranoico pues en el ratón los 5V se van a poner a través de una resistencia de pull-up. Si tienes a mano el osciloscopio comprueba las tensiones...

Y ya hace tiempo que probamos un controlador USB-host para el ratón:

https://groups.google.com/g/fpga-wars-explorando-el-lado-libre/c/oZoYQtFOV1U/m/vp4CIFJHAgAJ

Buenas tardes

[charli va]

Ah vale! pero te refieres a un ratón ps2, ps2 no usb con el adaptador no? Esque ratón ps2 no he conseguido ninguno aún y los que tenía de la época fueron muriendo o perdiéndose entre mudanzas, ya me haré con alguno para probar esto que me comentas que el circuito me ha parecido interesante y útil, de echo ojalá lo hubiera tenido a mano no hace mucho tiempo que tuve un problema similar y medio chapucee la solución electrónica.

Y sí,  la referencia del foro la lancé yo en su día, lo que pasa es que ahí usé un  módulo de un proyecto open source que a parte de ocupar algo más, también consume brams . Ese proyecto que fue una de las primeras cosas que tantee para empezar a aprender el protocolo usb, lo que usa es una micro cpu especializada para usb y luego utilizan una rom precargada ya con secuencias de comandos para implementar toda la pila. Funciona muy bien y con una variedad amplia de ratones y teclados sencillos, de echo ese módulo soporta teclado , ratón y jostick.

La idea de este nuevo módulo es por un lado hacerlo de cero, tengo ideas con el usb y me daba pereza extrema ponerme tal cual y esto ha sido como una excusa para retomar el protocolo en crudo, se ha juntado conque ando en poca prioridad con el proyecto del analizador lógico, mezclando lanal con el mio :) y estos meses pasados he indagado bastante con el usb y voy cogiendo cierta familiaridad ya con los comandos y el protocolo en sí, lo que me animó a la idea de intentar hacer un core mínimo usb para hid (realmente el mismo módulo con muy pocas variaciones nos va a valer para cualquier dispositivo hid) si consigo que ande.

El tema es por un lado implementar todas las partes farragosas  del usb (nrzi, crcs, bitstuffing...) y por otro el protocolo en sí y ver todo lo que se puede quitar de la pila que sólo se usa para generalizar y que en nuestro caso nos lo podríamos ahorrar ya que sabemos exactamente lo que se va a conectar. Creo que se podría conseguir algo entorno a 200-300LCs y sin brams una vez esté funcionando y podamos jugar a optimizar. Si consigo que funcione creo que soportar hubs o teclados con hub (que es super común) sería relativamente fácil, pero primero tengo que conseguir que funcione este primer módulo que podamos usar de base.

No sé si hoy porque la tarde se me está complicando pero yo creo que si no es hoy, mañana o pasado lo tendré para pasároslo a no ser que me atasque en algún agujero negro (que tampoco lo descarto) XD.

Para ver este debate, visita https://groups.google.com/d/msgid/fpga-wars-explorando-el-lado-libre/100a0cb8-52f7-4235-bfab-f73f3bf23051n%40googlegroups.com.