Nachdem ich neulich über die Hardware und die Motivation dahinter berichtete wollte ich den Prototypen für ernsthafte Aufgaben umrüsten. Das erwies sich nicht als so einfach, wie ich gehofft hatte...

Der Grund dafür war, dass ich ein Stück Bash-Shell-Code auf eine der Makrotasten legen wollte - ich habe aber in meinem Ubuntu ein deutsches Tastaturlayout eingestellt. Die von mir benutzte Bibliothek geht aber von einem englischen Tastaturlayout aus - und da viele Sonderzeichen in meinem Einzeiler enthalten waren funktionierte zunächst nichts.

Grummelnd ging ich also an die Arbeit und erstellte eine Version der Bibliothek mit deutscher Tastaturbelegung Sie ist noch nicht ganz fertig - zum Beispiel das Euro-Zeichen fehlt noch.

Dabei wurde ich von einem unerwarteten Problem aufgehalten - in einem Ausmaß, dass ich nach über einer Stunde verzweifelten Probierens kurz davor stand, aufzugeben: Ich konnte nicht herausfinden, welcher Tastencode für das Pipe-Zeichen verantwortlich ist - die Taste, die dieses Zeichen produziert, befindet sich auf deutschen Tastaturen ja zwischen SHIFT und Y - auf vielen englischen Layouts ist aber die linke Taste für SHIFT breiter und es existiert keine weitere Taste zwischen dieser und Z. Endlich fand ich eine Ressource, die mir sagte, dass der korrekte Keycode dieser Taste 0x64 ist.

Nachdem ich dieses Problem ausgeräumt hatte wurde ich übermütig und versuchte, auch Umlaute korrekt zu behandeln. Hier wurde ich wieder überrascht: Die Umlaute sorgten für gar keine Tastendrücke - es kamen dieses Mal nicht die falschen Keycodes, sondern gar keine!

Auch um dieses Problem zu adressieren benötigte ich wieder sehr lange - letztlich fand ich aber die Lösung: Die ASCII-Codes dieser Zeichen liegen sämtlich über 127 - im Quelltext der Bibliothek wurde das Mapping von ASCII auf KeyCodes über ein großes Switch-Statement abgewickelt, dessen Signatur und Baginn wie folgt aussehen:

void ASCII_to_keycode(uint8_t ascii, uint8_t ledState, uint8_t* modifier, uint8_t* keycode)
{
	*keycode = 0x00;
	*modifier = 0x00;

	// see scancode.doc appendix C

	if (ascii >= 'A' && ascii <= 'Z')
	{
// some code omitted for brevity's sake...
	}
	else
	{
	//https://gist.github.com/MightyPork/6da26e382a7ad91b5496ee55fdc73db2
		switch (ascii) // convert ascii to keycode according to documentation
		{
			case '!':
				*modifier = _BV(1); // hold shift
				*keycode = 30;
				break;

Wichtig ist hier der Vergleich mit Zeichen-Literalen - Zeichen-Literale sind vom Typ char während das übergebene Zeichen im Parameter ascii vom Typ uint8_t ist, was ein typedef ist, der auf unsigned char abbildet. Da bei ASCII-Zeichen mit Codes größer als 127 aber das leftmost Bit - und damit das Vorzeichen-Bit gesetzt ist, kann dieser Vergleich bei solchen Zeichen nie true liefern. Gefixt habe ich das mit einer entsprechenden Anpassung des Vergleichs, wie hier exemplarisch illustriert:

			case (uint8_t)'Ü':
				*keycode = 0x2F;
				break;

Der Grund dafür ist die Unzulänglichkeit der Arduino (in diesem Fall) gewesen: Die Quelltexte werden als ASCII gespeichert und die IDE bzw. der Compiler wirft keine entsprechende Warnung aus - probiert man das zum Beispiel mit GCC mit folgendem Quelltext (als ISO-8859-15 gespeichert - als UTF-8 würde GCC hier ganz andere Probleme melden...):

 <stdio.h>
 <stdint.h>

void method(uint8_t ascii)
{
	switch(ascii)
	{
		case 'a':
		{
			printf("It's an a!\n");
			break;
		}
		case 'ü':
		{
			printf("It's an ü!\n");
			break;
		}
		default:
		{
			printf("did not recognize char!\n");
		}
	}
}

int main(int argc, char** argv)
{
	printf("huhu\n");
	method('a');
	method('ü');
}

wird man bereits bei der Kompilierung mittels folgender Fehlermeldung auf das Problem hingewiesen:

uint8_test.c:13:3: warning: case label value is less than minimum value for type

Artikel, die hierher verlinken