Re: [Neo] neo und nordtast
Am 13.05.2010 13:38, schrieb Frank Stähr: PS: Wenn du Hunger hast, hier noch etwas Tofu für dich ;) Bah Tofu auf Tufo¹ schmeckt gar nicht. Gruß Florian ¹ http://de.wikipedia.org/wiki/TOFU -- „Wegen dieses Schwerts … ich will es.“ -The Secret of Monkey Island (1990)
Re: [Neo] Hardware: Anzahl der Tasten
Hallo Karl, vielen Dank für deine Antwort. Am 13.05.2010 schrieb neo-n...@…: Die Minimierung der Tastenzahl stellt meiner Meinung nach nur ein Teil des anzustrebenden Ziels dar. Lieber möchte ich die Anzahl der Tasten maximieren, wobei auf die hinreichend gute Erreichbarkeit der Tastenanordnung aus der Grundstellung heraus geachtet wird. Daraus ergibt sich die Anzahl der Tasten von selbst. Ein paar Tasten am Rand sollen dahingehend als gerade noch vertretbar gelten - auch zwei Daumentasten -, um sie mit selteneren Zeichen oder Funktionen zu belegen. Erreichbar sind sie sicher alle gut. Aber brauchen wir sie? Ich habe die Standardtastatur genommen, den Nummernblock abgezogen, dann die Ebene4. Somit waren alle Doppelbelegungen weg. Effektiv fehlt nur das KP-Enter, Num-Lock und die höheren Ebenen des Ziffernblock. Davon vermisse ich nichts bis auf ein paar Zeichen vom Nummernblock, die mit dem modularen Ebenenkonzept von Neo 3 hoffentlich auf das Hauptfeld zu holen sind. Mit Zusatznumblock wäre alles wieder da. Anschließend habe ich 13, aus meiner Sicht selten benutzte, Tasten auf eine Fn-Ebene ausgelagert. Will man mehr Tasten belegen, so muss man: a) Irgedwas wieder doppelt haben, oder b) Ziffernblocktasten richtung Hauptfeld verschieben, oder c) Irgendwas wieder von der Fn-Ebene holen, oder d) Andere Scancodes senden (Multimediatasten, eigene erfinden, …) Was schlägst Du vor? Allerdings benötigt dieser Vorschlag mehr als einen Standard-Encoder. Vorgesehen ist der selber programmierbare Encoder SK5101 von Sprintek (3 Stück bekam ich zugesandt): http://www.sprintek.com/products/SK5100.aspx Den hast Du ja schon mal vorgestellt. Dazu wollte ich aber erst viel später was schreiben, aber wenn Du damit anfängst… Der wäre sehr einfach einzusetzen und benötigt wenig Softwareentwicklung. Wo kriegt man den her, was kostet er, ist er flexibel genug, kannst Du QFN mit der Hand löten? Hast du die Samples direkt vom Hersteller oder von einem Distributor? Bei Farnell, Digi-Key, Arrow, Bürklin und Schuricht habe ich ihn leider nicht finden können. Für meinen Gegenvorschlag habe ich allerdings noch nichts passendes gefunden. Mein Wunsch wäre ein Standard 8 bit μC mit USB-Interface in LQFP-32: + sehr wahrscheinlich billiger + leichter zu löten + flexibler einsetzbar (falls der Flash groß genug ist) + nicht auf Software des Herstellers angewiesen - erheblicher Programmieraufwand - habe noch keinen passenden μC gefunden Vielleicht ist der MC68HC908JB8 was für den Fall. Den gibts als SOIC-28 für 1,82 € ab 10 Stück bei Farnell. Laut Datenblatt¹ kann er an den USB-Pins auch genügend Strom für PS/2. ABER der hat nur 8 kB Flash (reicht das?), kein EEPROM und ist noch kein „modernerer“ HCS08. Es gibt aber auch Projekte, die μCs ohne USB-Interface für USB-Tastaturen nutzen². Da weiß ich allerdings nicht, ob die Lizenz für uns passt. In diesem Fall wäre der μC eventuell noch günstiger. Dies erfordert allerdings etwas Schaltungstechnik. Bei der Programmierung der Firmware könnte vielleicht die libusb³ nützlich sein. Am schlimmsten dürfte hier die Tatsache sein, dass ich zwar weiß, was ich in der Firmware drinhaben will, dass ich aber zum Programmieren zu doof bin. Meine Firmwareidee: • Firmware erkennt automatisch, ob USB oder PS/2 gesprochen wird. • Im EEPROM benutzerdefinierte Tastenbelegungen ablegbar. Ich habe in dem Vorschlag die Tasten F1 … F4 als Hardware eingeplant. Dazu wäre die F4-Position an einer zu schlecht greifbaren Stelle platziert. Hingegen ist für den rechten Zeigefinger an der vermutlich gerade noch gut genug vertretbaren Stelle zwischen den LEDs namens Mod4 und Fn keine Taste vorgesehen. Dann lieber zwei Funktionstasten auf die andere Hand legen und zwei LEDs in dem Bereich anordnen, wo F4 vorgeschlagen ist. Guter Vorschlag, danke. also F1 und F2 links, rechts F3 und F4. Allerdings würde ich die LEDs dann rechts lassen, weil wir sonst wahrscheinlich mehr als 12 Adern im Verbindungskabel der beiden Tastaturhälften brauchen. Bei der Funktion der Mod4 / Fn Taste habe ich in deiner Mail (hmk5qp$6fu$1 at dough.gmane.org) gewildert (Mod4 drücken + loslassen = Fn). Wahrscheinlich ist das gewöhnungsbedürftig. Wenn ich mich richtig erinnere, wurde die Idee gut begründet abgelehnt, weswegen lieber andere Möglichkeiten bedacht werden sollten. Ich glaube, die Einwände bezogen sich auf die vorhergehenden Mails mit komplizierteren Konzepten. Aber eine separate Fn-Taste ist bestimmt auch nicht das schlechteste. Damit fällt dann auch die Fn-LED weg. Also: an jedem Daumen eine? Oder deine Kleinfingerspreiz-Tasten? Die Tastatur soll bei betätigter Mod4 nämlich dann den Scancode von Enter statt Mod4+P senden. Damit wäre auch das Bios bedienbar. … Beim Booten wird Del bisweilen auf der ersten Ebene benötigt. Zudem sollte die Tastenkombination Ctrl+Alt+Del ohne eine weitere (Fn-) Taste gedrückt werden können. Evtl. kann für diese besonderen Zwecke eine Del-Taste als
Re: [Neo] Hardware: Anzahl der Tasten
Michael Ostermeier writes: Am 13.05.2010 schrieb neo-n...@…: Die Minimierung der Tastenzahl stellt meiner Meinung nach nur ein Teil des anzustrebenden Ziels dar. Lieber möchte ich die Anzahl der Tasten maximieren, wobei auf die hinreichend gute Erreichbarkeit der Tastenanordnung aus der Grundstellung heraus geachtet wird. Daraus ergibt sich die Anzahl der Tasten von selbst. Ein paar Tasten am Rand sollen dahingehend als gerade noch vertretbar gelten - auch zwei Daumentasten -, um sie mit selteneren Zeichen oder Funktionen zu belegen. Erreichbar sind sie sicher alle gut. Aber brauchen wir sie? Ja. Wo Tasten nicht für Funktionen gebraucht werden, ist es immer wünschenswert, mehr Zeichen auf vertretbar gut erreichbaren Positionen zu haben. Will man mehr Tasten belegen, so muss man: a) Irgedwas wieder doppelt haben, oder b) Ziffernblocktasten richtung Hauptfeld verschieben, oder c) Irgendwas wieder von der Fn-Ebene holen, oder d) Andere Scancodes senden (Multimediatasten, eigene erfinden, …) Was schlägst Du vor? e) mehr Zeichen pro Ebene. Wo Redundanz sinnvoll ist, durchaus auch a). Allerdings benötigt dieser Vorschlag mehr als einen Standard-Encoder. Vorgesehen ist der selber programmierbare Encoder SK5101 von Sprintek (3 Stück bekam ich zugesandt): http://www.sprintek.com/products/SK5100.aspx Den hast Du ja schon mal vorgestellt. Dazu wollte ich aber erst viel später was schreiben, aber wenn Du damit anfängst… Der wäre sehr einfach einzusetzen und benötigt wenig Softwareentwicklung. Wo kriegt man den her, was kostet er, ist er flexibel genug, kannst Du QFN mit der Hand löten? Hast du die Samples direkt vom Hersteller? Der Keyboard Encoder SK5101 ist direkt beim Hersteller erhältlich. Die Preise für Muster stehen auf der Internetseite: http://www.sprintek.com/order/OrderICs.aspx Der Hersteller zeigt sich auch bei sehr geringen Stückzahlen entgegenkommend. Drei Muster hat der Hersteller mir kostenlos zugesandt. Noch habe ich mich nicht im Detail mit dem SK5101 befasst, weswegen ich nicht abschätzen kann, ob der Chip flexibel genug ist. Mit der entsprechenden Ausrüstung (SMD-Technologie) sollten die ICs sich von Hand löten lassen. Bei Farnell, Digi-Key, Arrow, Bürklin und Schuricht habe ich ihn leider nicht finden können. Sprintek hat in Deutschland keinen Distributor. Bei diesem Hersteller ist es in dem Fall tatsächlich üblich, auch Kleinstmengen direkt bei ihm zu bestellen. Für meinen Gegenvorschlag habe ich allerdings noch nichts passendes gefunden. Mein Wunsch wäre ein Standard 8 bit μC mit USB-Interface in LQFP-32 Nach meinen Recherchen soll das Programmieren von Mikrocontrollern (µC) für USB-Zwecke selbst für erfahrene Kenner eine komplizierte Angelegenheit sein. Ferner sieht USB standardmäßig bis zu 6 gleichzeitig gedrückte Tasten vor, weswegen echtes n-key-rollover angeblich nur über Umwege realisierbar sein soll. Der Einfachheit halber sehe ich vorerst nur PS/2 vor. Zwar bietet der SK5101 sowohl PS/2 als auch USB, jedoch scheint mir der SK5101 weniger für die endgülige Hardware, als vielmehr für den Prototypenbau für unsere Zwecke gut geeignet zu sein. Wenn nach vielen praktischen Tests durch verschiedene Freiwillige klar ist, was der Keyboard Encoder im Detail macht, halte ich es für sinnvoll, die Funktionen auf einem preisgünstigen µC umzusetzen. Das hält sowohl den Entwicklunsaufwand als auch die Kosten gering. Vielleicht ist der MC68HC908JB8 was für den Fall. Den gibts als SOIC-28 für 1,82 € ab 10 Stück bei Farnell. Laut Datenblatt¹ kann er an den USB-Pins auch genügend Strom für PS/2. ABER der hat nur 8 kB Flash (reicht das?), kein EEPROM und ist noch kein „modernerer“ HCS08. Es gibt aber auch Projekte, die μCs ohne USB-Interface für USB-Tastaturen nutzen². Da weiß ich allerdings nicht, ob die Lizenz für uns passt. In diesem Fall wäre der μC eventuell noch günstiger. Dies erfordert allerdings etwas Schaltungstechnik. Bei der Programmierung der Firmware könnte vielleicht die libusb³ nützlich sein. Am schlimmsten dürfte hier die Tatsache sein, dass ich zwar weiß, was ich in der Firmware drinhaben will, dass ich aber zum Programmieren zu doof bin. So weitgehend habe ich mich mit der Hardwareentwicklung noch nicht befasst. Mir geht es derzeit darum, zunächst einen Prototyp in Händen zu halten, der nicht alle Neo2-Möglichkeiten bietet (weder Nummernblock noch funktionierende Fn-Tasten), aber geeignet sein soll, erste Eindrücke von mehreren Freiwilligen zu gewinnen, mit dem Ziel, einen Konsens für die Tastenanordnung (noch nicht deren Belegung) zu finden. Deshalb nehme ich erst mal einen Standard-Keyboard- Encoder, später den einfach zu handhabbaren SK5101 und wenn es um die Umsetzung für die Produktion geht, dann einen preisgünstigen µC. Alles zu seiner Zeit. Meine Firmwareidee: • Firmware erkennt automatisch, ob USB oder PS/2 gesprochen wird. • Im EEPROM benutzerdefinierte Tastenbelegungen ablegbar. Hoffentlich
