Público · Sistemas de entrada embebidos
Entorno QMK
Un entorno de firmware Vial/QMK orientado a producción para un teclado dividido compacto, que trata capas, encoders, estado de pantalla, persistencia y entregas como un único producto embebido y no como una colección de asignaciones de teclas.
- Nicho
- Entrada ergonómica compacta de alta capacidad
- Stack principal
- C · QMK · Vial · split firmware
- Hardware
- Halcyon Ferris · TFT + mitades con encoder
- Enfoque
- Comportamiento determinista y configuración persistente
Vista del sistema
El nicho
Un teclado dividido de 34 teclas solo funciona bien cuando las capas y los gestos dejan de sentirse como compromisos y empiezan a comportarse como un lenguaje de entrada coherente.
El firmware está diseñado alrededor de la edición cotidiana, no para exhibir el máximo número de funciones de QMK. La capa alfabética normal permanece estable mientras pulsaciones breves, acordes en la fila base y encoders exponen números, navegación, modificadores, teclas de función y controles sin exigir cambios de modo persistentes.
Qué lo hace diferente
El teclado se trata como un pequeño sistema embebido con estado.
La dirección de Repeat/Alternate Repeat permanece ligada a la orientación del par en Vial en lugar de invertirse según la última tecla que se haya pulsado.
La TFT comunica identidad de capa, estado animado y diagnósticos en lugar de funcionar como una pantalla de logotipo estática.
El comportamiento de iluminación por capa, modificador y acorde se modela como configuración en lugar de como un único efecto global.
La configuración canónica de Vial, los valores predeterminados del firmware, las dependencias fijadas, las pruebas de regresión y los artefactos UF2 exactos se mantienen auditables.
Enfoque de producto y diseño
La disposición está optimizada para transiciones breves fuera del estado principal de escritura.
Los números aparecen mediante una pulsación de pulgar; la navegación y las teclas de función mediante acordes momentáneos; y las acciones frecuentes Escape y Enter permanecen en la capa alfabética. El objetivo es preservar la memoria espacial y minimizar el coste cognitivo de un número reducido de teclas.
El comportamiento visual y de los encoders sigue el mismo principio: el estado debe ser comprensible y la dirección debe seguir siendo predecible incluso cuando la función subyacente del firmware dependa del historial.
Evolución reciente
La configuración cruzó el límite entre firmware y host sin convertir el firmware en una colección de excepciones específicas de la interfaz.
Un protocolo Raw HID propio y persistente permite editar desde el host la paleta, cadencia y estilo de la pantalla TFT, con almacenamiento seguro para teclado dividido y hooks de ejecución que mantienen el display sincronizado con el estado real.
El Atlas visual también modela la geometría física real del Ferris Sweep, incluidos escalonamiento y arco de pulgares, con pruebas de colisión. La documentación de combos y tap dance describe intención de comportamiento, no solo códigos de tecla.
Los ajustes TFT persistentes viajan por un contrato explícito en lugar de recompilar firmware para cada cambio visual.
El visualizador replica posiciones físicas y usa invariantes para impedir superposición de teclas o deriva de diseño.
Enfoque de desarrollo
El teclado físico es el estudio de diseño: una capa, un acorde, la dirección de un encoder o el ritmo de la pantalla tiene que sentirse bien en las manos antes de merecer convertirse en una regla.
La configuración editable por personas y los valores compilados comparten una única fuente de verdad.
El perfil Vial versionado alimenta los valores predeterminados generados del firmware; los cambios específicos del fork Vial-QMK permanecen como parches ordenados en lugar de desaparecer dentro de un árbol de proveedor. La regresión del código fuente, el éxito de compilación del firmware y la aceptación del hardware físico se tratan como clases de evidencia separadas.
Esto facilita evolucionar el firmware sin confundir “compiló” con “el teclado sigue comportándose correctamente después de suspensión, reconexión del split o cambios de módulo”.
Los ajustes editables desde el host, las comprobaciones de geometría y los artefactos de release repetibles acortan el antiguo ciclo editar → compilar → flashear → recordar qué cambió. Los experimentos táctiles rápidos siguen siendo posibles, mientras los comportamientos que sobreviven al uso diario quedan capturados como configuración, pruebas y evidencia de release en lugar de depender de la memoria.