{"id":3073,"date":"2022-08-19T19:04:02","date_gmt":"2022-08-19T19:04:02","guid":{"rendered":"https:\/\/blog.rastersoft.com\/?p=3073"},"modified":"2023-12-25T19:46:21","modified_gmt":"2023-12-25T19:46:21","slug":"problemas-tecladiles","status":"publish","type":"post","link":"https:\/\/blog.rastersoft.com\/?p=3073","title":{"rendered":"Problemas tecladiles"},"content":{"rendered":"\n

Hace tiempo que quiero construirme un port\u00e1til\/cyberdeck alrededor de una Raspberry Pi 4, y basado en el dise\u00f1o del Z88 de Sinclair\/Cambridge Computers<\/a>. Sin embargo, algo que tengo muy claro es que quiero un teclado completo, no uno de port\u00e1til, pues, como programador, suelo utilizar mucho las teclas SUPR, INICIO, FIN, RePAG y AvPAG, y en los port\u00e1tiles algunas necesitan combinarse con Fn.<\/p>\n\n\n\n

La primera opci\u00f3n ser\u00eda utilizar un dise\u00f1o TenKeyless, tambi\u00e9n conocido como \u00abteclado 87%\u00bb, como \u00e9ste (pero sin lucecitas):<\/p>\n\n\n\n

\"\"<\/a><\/figure>\n\n\n\n

Sin embargo, hay mucho espacio desaprovechado. As\u00ed que sopes\u00e9 utilizar un dise\u00f1o \u00ab75%\u00bb, como \u00e9ste de Keychron:<\/p>\n\n\n\n

\"\"<\/a><\/figure>\n\n\n\n

Pero no ten\u00eda a mano la tecla de Imprimir pantalla, que uso mucho, ni tampoco la de SysReq, que utilizo de vez en cuando, as\u00ed que tampoco me convenc\u00eda.<\/p>\n\n\n\n

Al final, despu\u00e9s de mucho pensarlo, me decid\u00ed por hacer mi propio dise\u00f1o, y \u00e9sta es la distribuci\u00f3n final que decid\u00ed:<\/p>\n\n\n\n

\"\"<\/a><\/figure>\n\n\n\n

Como se puede ver, tiene todas las teclas de un Tenkeyless, pero es much\u00edsimo m\u00e1s compacto. E incluso tiene una tecla de Fn para funciones no tan comunes, como subir y bajar el volumen. Todo ventajas.<\/p>\n\n\n\n

Decid\u00ed construir uno en plan \u00abbarato\u00bb, y para ello utilic\u00e9 pulsadores de circuito impreso y los capuchones de un teclado que compr\u00e9 en el chino<\/s> el bazar de al lado de casa, y lo conect\u00e9 directamente a los pines de E\/S de la raspberry. Este fue el resultado:<\/p>\n\n\n\n

\"\"<\/a><\/figure>\n\n\n\n

La distribuci\u00f3n era buena, pero el tacto… en fin… hace unos treinta a\u00f1os hab\u00eda construido un teclado para mi Spectrum utilizando el mismo tipo de pulsadores, y no recordaba que fuese tan malo 🤣<\/p>\n\n\n\n

Pero ya ten\u00eda el gusanillo, as\u00ed que decid\u00ed coger el toro por los cuernos y dise\u00f1ar un teclado en condiciones. Para ello part\u00ed de un dise\u00f1o b\u00e1sico creado mediante el programa Klepcbgen, de Jeroen Bouwens<\/a>, al que hice varios cambios<\/a> para permitir, entre otras cosas, utilizar diodos normales en lugar de la versi\u00f3n de montaje superficial. A partir de ah\u00ed segu\u00ed puliendo el dise\u00f1o hasta llegar a la versi\u00f3n 1.<\/a>5<\/a> de mi teclado, que est\u00e1 disponible en mi repositorio de gitlab<\/a>.<\/p>\n\n\n\n

\"\"<\/a><\/figure>\n\n\n\n

En el dise\u00f1o utilic\u00e9 un Atmega32U4<\/a>, el mismo que se utiliza en las placas Teensy 2.0<\/a>. El motivo es que son las placas que m\u00e1s se utilizan para dise\u00f1os de teclados propios, por lo que podr\u00eda reutilizar mucho software. Adem\u00e1s, inclu\u00ed, como se puede ver en la imagen de arriba, dos filas de 10 pads cada una en donde est\u00e1n disponibles las filas y columnas del teclado. Esto permite conectar la misma placa a un microcontrolador externo (o, en mi caso, directamente a los pines de E\/S de la Raspberry PI) en lugar de utilizar el incorporado en la placa.<\/p>\n\n\n\n

La primera dificultad fue donde colocar el microcontrolador. Al principio junt\u00e9 todas las teclas de la primera fila hacia la izquierda y coloqu\u00e9 el microcontrolador y el conector USB arriba a la derecha, por el lado inferior de la placa. Esto ten\u00eda la ventaja de que las pistas del par diferencial del USB eran lo m\u00e1s cortas posible, y adem\u00e1s me dejaba sitio para un NeoPixel<\/a> en la esquina superior derecha, pero ten\u00eda el inconveniente de que la est\u00e9tica de la colocaci\u00f3n de las teclas no era muy all\u00e1, adem\u00e1s de que, por el espacio disponible, la placa sobresal\u00eda bastante por arriba.<\/p>\n\n\n\n

Ante esto, decid\u00ed intentar mover el microcontrolador a otra zona, en este caso debajo de la barra espaciadora, donde hab\u00eda mucho espacio libre, y as\u00ed poder mover el conector USB un poco m\u00e1s hacia las teclas. Sin embargo, me preocupaba que las pistas del par diferencial ser\u00edan muy largas… \u00bfdar\u00eda problemas con el USB?<\/p>\n\n\n\n

Decid\u00ed informarme, as\u00ed que me descargu\u00e9 la especificaci\u00f3n del est\u00e1ndar USB 1.1<\/a> y descubr\u00ed que el par diferencial tiene que tener una impedancia de 90 ohmios +\/- 15%. Ante esto, utilic\u00e9 la herramienta de c\u00e1lculo de Kicad para l\u00edneas de transmisi\u00f3n, y me sali\u00f3 que ten\u00eda que utilizar una anchura de pista de 0,9 mil\u00edmetros (s\u00ed, bastante ancha):<\/p>\n\n\n\n

\"\"<\/a><\/figure>\n\n\n\n

De todas formas, mi intenci\u00f3n era utilizar el modo low-speed<\/em>, de 1,5Mbps en lugar del full-speed<\/em> de 12Mbps, por lo que lo m\u00e1s probable es que incluso unas pistas sin ajustar funcionasen correctamente; pero decid\u00ed no arriesgarme e intentar hacer las cosas bien. Aqu\u00ed, adem\u00e1s, cont\u00e9 con la inestimable ayuda de mis compa\u00f1eros de A Industriosa<\/a>, que me resolvieron todas mis dudas sobre dise\u00f1o con Kicad<\/a>. A fin de cuentas, soy programador, no electr\u00f3nico.<\/p>\n\n\n\n

Para hacer bien un par diferencial, lo primero es definir una malla espec\u00edfica para \u00e9l en las clases de red<\/em>. De esta manera podremos estar seguros de que los par\u00e1metros de las pistas ser\u00e1n correctos:<\/p>\n\n\n\n

\"\"<\/a><\/figure>\n\n\n\n

Para trazar el par, tenemos que utilizar la herramienta espec\u00edfica. Ella nos permite asegurarnos de que ambas pistas est\u00e1n siempre a la distancia correcta:<\/p>\n\n\n\n

\"\"<\/a><\/figure>\n\n\n\n

Una vez trazado el par, veremos que los \u00e1ngulos son rectos (de 45 o 90 grados), cosa que no es buena. Para solucionar esto s\u00f3lo tenemos que escoger dos segmentos consecutivos, darle al bot\u00f3n derecho, y escoger pistas de filete<\/em>. Nos preguntar\u00e1 un valor para el radio, y una vez aceptado, a\u00f1adir\u00e1 una esquina curva entre las dos pistas. Aqu\u00ed tenemos un ejemplo de una esquina ya con el filete, y la esquina paralela a\u00fan sin \u00e9l:<\/p>\n\n\n\n

\"\"<\/a><\/figure>\n\n\n\n

Yo utilic\u00e9 un radio de 3 mil\u00edmetros para las curvas internas. Sin embargo, es importante recordar que las curvas deben ser conc\u00e9ntricas, lo que significa que las curvas externas tienen que tener un radio mayor. Dicho radio debe ser radio_interior + ancho_de_pista + separaci\u00f3n_de_pista<\/em>. En mi caso, con un radio interior de 3 mil\u00edmetros, un ancho de pista de 0,9 mil\u00edmetros, y una separaci\u00f3n de pista de 0,2 mil\u00edmetros, el resultado es que para los radios exteriores tengo que utilizar un radio de 4,1 mil\u00edmetros. Y as\u00ed queda:<\/p>\n\n\n\n

\"\"<\/a><\/figure>\n\n\n\n

Sin embargo, si seleccionamos cada una de las dos pistas del par y nos fijamos en el par\u00e1metro Longitud enrutada<\/em> de cada una, veremos que la longitud no es la misma. Aunque la diferencia es peque\u00f1a (casi dos mil\u00edmetros), quise hacer las cosas bien, as\u00ed que utilic\u00e9 la herramienta de Afinar desv\u00edo de un par diferencial<\/em> para asegurarme de que la diferencia de distancias estuviese por debajo de una d\u00e9cima de mil\u00edmetro:<\/p>\n\n\n\n

\"\"<\/a><\/figure>\n\n\n\n

Esta herramienta a\u00f1ade unas ondulaciones<\/em> en la pista, de manera que la distancia sea correcta a la vez que se mantiene la impedancia:<\/p>\n\n\n\n

\"\"<\/a><\/figure>\n\n\n\n

Distribuciones de teclado<\/h2>\n\n\n\n

Durante todo el dise\u00f1o inicial mantuve una distribuci\u00f3n ISO de las teclas<\/a>, pues es la que yo voy a utilizar. Sin embargo, dado que iba a publicarlo todo bajo una licencia libre, decid\u00ed intentar hacer una placa dual, que permitiese montar tambi\u00e9n una distribuci\u00f3n ANSI de teclas<\/a>. Sin embargo, me encontr\u00e9 con el problema de que hab\u00eda un par de agujeros que quedaban bastante cerca y no ve\u00eda claro que los estabilizadores que iban en ellos quedasen bien anclados, por lo que ese dise\u00f1o no parec\u00eda una buena idea. Pese a todo, quer\u00eda poder tener ambas distribuciones, as\u00ed que al final se me ocurri\u00f3 una idea relativamente sencilla: en main<\/em> tendr\u00eda la placa dual<\/em>, y luego tendr\u00eda dos ramas<\/em>, una para cada distribuci\u00f3n, que mantendr\u00eda actualizadas a partir de main<\/em>. Al principio era bastante pe\u00f1azo porque, al quitar los pulsadores que sobraban, quedaban muchas pistas mal situadas, lo que me obligaba a ajustar bastante ambos dise\u00f1os antes de poder hacer el merge<\/em>; pero despu\u00e9s de afinar la placa dual<\/em> consegu\u00ed solucionar esos problemas, y ahora me lleva segundos actualizar cada rama.<\/p>\n\n\n\n

\"\"<\/a>
Distribuci\u00f3n ISO renderizada desde Kicad<\/figcaption><\/figure>\n\n\n\n
\"\"<\/a>
Distribuci\u00f3n ANSI renderizada desde Kicad<\/figcaption><\/figure>\n\n\n\n

Otros detalles que a\u00f1ad\u00ed fueron un conjunto de pads<\/em> para un programador de Atmega (ese grupo de dos por tres que se ven junto al microcontrolador), dos pads<\/em> conectados a PE2 y masa para que, al cortocircuitarlos, se pueda entrar en el modo de carga del bootloader<\/em> de Atmega (que son esos dos que se ven entre el pulsador del espacio y el microcontrolador, y que est\u00e1 etiquetado por debajo como bootloader<\/em>), y dos pads<\/em> m\u00e1s para dos pines de E\/S que me quedaban libres (PE6 y PB0), pues puede ser interesante aprovecharlos. Teniendo en cuenta que PB1, PB2 y PB3 ya est\u00e1n disponibles en el conector del programador, el resultado es que casi todos los pines de E\/S del microcontrolador est\u00e1n accesibles a trav\u00e9s de pads<\/em>. La \u00fanica excepci\u00f3n es PB7, que se qued\u00f3 tan encerrado que no encontr\u00e9 una manera razonable de extraer una pista. Es cierto que podr\u00eda hacer sitio eliminando C7, el condensador de reset<\/em>, pero la verdad es que no me parece tan necesario poder acceder a ese pin. Ese condensador lo a\u00f1ad\u00ed \u00fanicamente por si acaso<\/em>, pero realmente no es buena idea ponerlo pues, al generar un reset<\/em> autom\u00e1tico al enchufar la placa, impide aprovechar la caracter\u00edstica de entrar en modo depuraci\u00f3n tras un reset<\/em> del bootloader<\/em>.<\/p>\n\n\n\n

Tambi\u00e9n inclu\u00ed un rect\u00e1ngulo en blanco<\/em> en cada lado de la placa, lo que permite hacer anotaciones con un rotulador.<\/p>\n\n\n\n

Protecci\u00f3n contra sobretensiones<\/h2>\n\n\n\n

Al principio no tuve en cuenta la necesidad de proteger contra sobretensiones en el bus USB. A fin de cuentas, aunque en la documentaci\u00f3n del Atmega32U4 dicen que es recomendable a\u00f1adirla, no aparec\u00eda en ninguno de los dise\u00f1os de referencia que inclu\u00edan. Es m\u00e1s: la propia placa Teensy 2.0 no incluye ning\u00fan tipo de protecci\u00f3n, sino que los dos pines del microcontrolador van a pelo<\/em> al conector.<\/p>\n\n\n\n

Sin embargo, un compa\u00f1ero de AIndustriosa me recomend\u00f3 encarecidamente que la a\u00f1adiese, pues parece ser que es habitual que en los conectores USB de los equipos de sobremesa (cuya alimentaci\u00f3n va directa a la fuente) haya picos de tensi\u00f3n en determinadas circunstancias. Le ech\u00e9 un vistazo a las opciones que me daba Kicad, y me encontr\u00e9 con que casi todas eran diminutas<\/em>: algunos chips med\u00edan aproximadamente un mil\u00edmetro de largo… algo imposible de soldar a mano. Afortunadamente hab\u00eda otras opciones, y al final me qued\u00e9 con el USB6B1<\/a>, pues adem\u00e1s de estar pensado espec\u00edficamente para USB, tiene un patillaje que simplifica el dise\u00f1o.<\/p>\n\n\n\n

Reloj, o no reloj… he ah\u00ed la cuesti\u00f3n<\/h2>\n\n\n\n

Cuando estaba haciendo el dise\u00f1o original descubr\u00ed que el Atmega32U4 incluye un oscilador RC que viene calibrado de f\u00e1brica de manera que su precisi\u00f3n es suficiente para que el USB funcione en modo low-speed<\/em>. Dado que meter un cuarzo de 16MHz me asustaba bastante (es una frecuencia relativamente alta, y yo no soy para nada un experto en dise\u00f1o electr\u00f3nico), decid\u00ed que ser\u00eda mejor hacer un sistema sin cuarzo externo, y utilizar s\u00f3lo el oscilador RC interno. Sin embargo, a la vez, tem\u00eda que hubiese alg\u00fan problema, as\u00ed que al final decid\u00ed que no usar\u00eda cuarzo, pero dejar\u00eda hechas las pistas para poder poner uno de ser necesario.<\/p>\n\n\n\n

\u00a1Menos mal que lo hice! Cuando mont\u00e9 la primera placa y quise programar el micro, descubr\u00ed que no funcionaba. Al principio pens\u00e9 que pod\u00eda ser un problema con el programador que estaba utilizando, un Bus Pirate<\/a>, pero despu\u00e9s de probar y probar una y otra vez, y de leerme la documentaci\u00f3n repetidamente, descubr\u00ed que la programaci\u00f3n mediante el puerto SPI (que es lo que estaba usando) necesita que haya un reloj activo para funcionar. Pero para que el chip utilizase el RC interno necesitaba programar los fuses<\/em> de configuraci\u00f3n, para lo cual… necesitaba un reloj activo… El huevo y la gallina. Fue aqu\u00ed cuando descubr\u00ed que se vend\u00edan dos modelos: el Atmega32U4 a secas<\/em>, que viene configurado de f\u00e1brica para trabajar con un cuarzo externo, y el Atmega32U4RC, id\u00e9ntico en absolutamente todo excepto en que, de f\u00e1brica, viene configurado para trabajar con el oscilador RC interno. Adivinad cual hab\u00eda encargado yo…<\/p>\n\n\n\n

Decid\u00ed no desesperarme y buscar una soluci\u00f3n, as\u00ed que intent\u00e9 utilizar la interfaz JTAG<\/a> para programarlo, confiando en que esa no necesitase un reloj externo. A fin de cuentas, el Bus Pirate es un dispositivo programable, y soporta todo tipo de interfaces…<\/p>\n\n\n\n

O no, porque como como estaban justos de espacio de c\u00f3digo en el microcontrolador, en las \u00faltimas revisiones eliminaron el soporte de JTAG. A fin de cuentas, \u00abera demasiado lento para ser \u00fatil\u00bb 😡<\/p>\n\n\n\n

Afortunadamente hab\u00eda un fork<\/em> del firmware del Bus Pirate mantenido por la comunidad<\/a> que, supuestamente, inclu\u00eda soporte de JTAG, as\u00ed que lo descargu\u00e9, lo compil\u00e9 con el MPlabX<\/a>, lo flashe\u00e9… y no hab\u00eda JTAG.<\/p>\n\n\n\n

Al final me cans\u00e9, me fui a la tienda de electr\u00f3nica de mi ciudad y me compr\u00e9 un cuarzo de 16MHz por 60 m\u00edseros c\u00e9ntimos de euro, lo sold\u00e9, y se acabaron mis problemas: el teclado aparece como un dispositivo OpenMoko (porque, adem\u00e1s, antes del cuarzo de 16MHz le puse, por error, uno de 12MHz pensando que era esa la frecuencia correcta, en base a los 12Mbps del bus USB; pero no…), y como no aparec\u00eda el dispositivo, prob\u00e9 a grabar un bootloader<\/em> diferente del que trae de f\u00e1brica: UdaBoot<\/a>.<\/p>\n\n\n\n

Moraleja: no compensa ahorrarse unos c\u00e9ntimos.<\/p>\n\n\n\n

\u00bfY ahora?<\/h2>\n\n\n\n

Ahora me queda la parte de programar el micro para que se comporte como un teclado, adem\u00e1s de ver c\u00f3mo puedo publicar<\/em> a trav\u00e9s de HID el NeoPixel<\/em>, de manera que sea f\u00e1cilmente controlable mediante software<\/em>. Una vez hecho esto, montar\u00e9 dos teclados m\u00e1s, y dise\u00f1ar\u00e9 la carcasa para el port\u00e1til, y una carcasa independiente para poder utilizar este teclado en mis ordenadores de casa.<\/p>\n","protected":false},"excerpt":{"rendered":"

Hace tiempo que quiero construirme un port\u00e1til\/cyberdeck alrededor de una Raspberry Pi 4, y basado en el dise\u00f1o del Z88 de Sinclair\/Cambridge Computers. Sin embargo, algo que tengo muy claro es que quiero un teclado completo, no uno de port\u00e1til, pues, como programador, suelo utilizar mucho las teclas SUPR, INICIO, FIN, RePAG y AvPAG, y … Seguir leyendo Problemas tecladiles<\/span> →<\/span><\/a><\/p>\n","protected":false},"author":2,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1],"tags":[19],"class_list":["post-3073","post","type-post","status-publish","format-standard","hentry","category-sin-categoria","tag-problemas-tecladiles"],"_links":{"self":[{"href":"https:\/\/blog.rastersoft.com\/index.php?rest_route=\/wp\/v2\/posts\/3073","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/blog.rastersoft.com\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/blog.rastersoft.com\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/blog.rastersoft.com\/index.php?rest_route=\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/blog.rastersoft.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=3073"}],"version-history":[{"count":9,"href":"https:\/\/blog.rastersoft.com\/index.php?rest_route=\/wp\/v2\/posts\/3073\/revisions"}],"predecessor-version":[{"id":3098,"href":"https:\/\/blog.rastersoft.com\/index.php?rest_route=\/wp\/v2\/posts\/3073\/revisions\/3098"}],"wp:attachment":[{"href":"https:\/\/blog.rastersoft.com\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=3073"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/blog.rastersoft.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=3073"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/blog.rastersoft.com\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=3073"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}