Werd ich tun.
Du sagtest was gegen die PICS (das tun viele) - was spricht denn wirklich gegen die? Bis auf die Umschalterei mit den Banken, was man gerne mal vergisst.. ?
Werd ich tun.
Du sagtest was gegen die PICS (das tun viele) - was spricht denn wirklich gegen die? Bis auf die Umschalterei mit den Banken, was man gerne mal vergisst.. ?
Gibt noch mehr Gründe, habe ich hier mal geschrieben.
Auch wenn es schwer fällt, nicht einfach drauf los programmieren. Gehe so
etwas strukturiert an, überlege, welche Module (Unterprogramme) man
braucht, welchen Ablauf. Unterste I/O-Routinen schreiben, testen(!!), und
darauf sukzessive aufbauen... dann ist sowas ein Kinderspiel.
Hallo tcfka(o)/(t),
wollte nur mal Zwischenmeldung geben - ich habe es hinbekommen Zeichen zu senden durch Einhalten des Timings. Allerdings las ich auf einer anderen Seite, dass der Takt zwischen 10 und ca. 16 kHz sein muss. Damit hats dann letztendlich auch funktioniert. Muss mich aber demnächst nocheinmal näher damit befassen, weil ich unbedingt auch noch die Kommunikation PC -> Tastatur einbauen muss. Es funktioniert nämlich an dem Rechner nur, wenn vorher mal eine "richtige" Tastatur dranstecke. Scheinbar fragt der Rechner u.A. noch ab, was es überhaupt für eine ist.
Jedenfalls danke für deine Tipps.
Na, das ist doch mal was... über das "Normtiming" finden sich vielleicht
irgendwo noch Original-IBM-Specs.
Wie ich schon schrieb, beim Booten sendet der PC ein Init- bzw. Reset-
kommando ans keyb (sieht man, dass alle LEDs kurz aufleuchten), wenn das
nicht beantwortet wird, gilt das keyb als defekt oder nicht vorhanden.
Lässt sich vielleicht testweise ausschalten durchs Setup im BIOS, mal
ausprobieren. Besser natürlich, die Identifikation einzubauen...
Was soll das Ganze denn nun eigentlich werden?
Ja, ich weiss. Die Sache mit dem "Selbsttest" ist mir bewusst. Ich hab im BIOS schon eingestellt Halt on No Errros - nun, er startet ja auch. Aber er scheint das Keyboard wohl erkennen zu wollen. Wie auch immer, werd ich das noch einbauen. Wird so ein großes Problem auch nicht werden, und dann bin ich immer auf der sicheren Seite.
Du erinnerst dich sicher noch an mein Wakeup, nun die Software für den PC reagiert auch auf direkte Tasteneingaben.. so könnte ich RC5 -> SCANCODE wandeln, spare mir also so auf dem PC weitere Software. Desweiteren kann ich direkt die 5V vom Tastaturport nehmen und auch noch ein paar Taster für eine Nahbedienung anbringen. Ein HTPC der im Wohnzimmer unterm TV steht, hat sowieso keine Tastatur.
Ja, erinnere mich, nettes Projekt. Wenn Du die Protokoll-Gegenseite
in den MCU implementierst: Wie in dem Link beschrieben auf CLK und DATA
listen, während die beiden Pins in der MCUs als Input konfiguriert sind
(ich gehe davon aus, dass Du jetzt die OC-Emulation programmiert hast).
Beim Schreiben durch den PC erzeugt das keyb den CLK, nicht der PC! Der
PC stellt nur DATA zur Verfügung. Und nicht am Ende die Generierung des
ACK-Bits auf DATA durch das keyb vergessen.
Die Arbitrierung von solchen Zweidrahtbussen ist halt etwas krüppelig,
ähnlich wie bei I²C...
Beim Listen unbedingt saubere Starterkennung einbauen (mehrfach samplen
nach erkennen einer Startcondition) und eventuell Timeout einbauen, sonst
hängt sich die MCU beim Empfang eines Glitches auf ewig weg, und nichts
passiert mehr (weil es kommen nie die zu erwartenden Daten vom PC).
Ebenso eventuell in der Zwischenzeit eingehende RC5-Daten buffern, solange
die MCU als Slave für den PC geschaltet ist.