Ohne diese Abbildung: http://i.imgur.com/cNE7y83.png macht mein Gerede noch weniger sinn. rote farbe: oben steigt er nochmal an, ohne gründe, warum? und warum unten nicht? Und dann einfach nur so, ohne Zeitangabe. Okay, die müsste twl (minimal low enable time) sein, also mit impliziter Zeitangabe. ich dachte man fährt von links aus dem "idle state" rein und ist am ende wieder im "iddle state". Hmm, ja ist wohl egal, wenn ich die chip select ausschalte (active low, cs=1 setze) ist eh egal, was danach noch kommt. Lila farbe: twh und tdsu ist auch nicht nach maßstab :( also einfach E auf H und 450ns warten und dann noch tdhw=10ns min warten (10ns ist min. wieviel sollte man drauf packen auf sowas um auf der sicheren Seite zu sein?) grün: kann ich die daten nicht schon viel früher anlegen, wo ich grün eingefärbt habe, dann spielt tdsu für mich später nicht mehr so die rolle / muss ich nicht mehr drauf achten. Irgendwie ist es schwierig vor lauter Pfeile den durchblick zu kriegen um das timing für den AVR auszudenken... Naja, die flankensteilheits-angaben kann ich wohl ignorieren, der avr schaltet schnell genug... das timing ist leider von irgendeinem glcd, weil ich ein datenblatt zu meinem nicht finde.
Corny schrieb: > Ohne diese Abbildung: http://i.imgur.com/cNE7y83.png macht mein Gerede > noch weniger sinn. > > rote farbe: > oben steigt er nochmal an, ohne gründe, warum? und warum unten nicht? > Und dann einfach nur so, ohne Zeitangabe. Okay, die müsste twl (minimal > low enable time) sein, also mit impliziter Zeitangabe. > ich dachte man fährt von links aus dem "idle state" rein und ist am ende > wieder im "iddle state". Hmm, ja ist wohl egal, wenn ich die chip select > ausschalte (active low, cs=1 setze) ist eh egal, was danach noch kommt. Genau, es ist vollkommen egal, weil der Chipselect fehlt. > > Lila farbe: > twh und tdsu ist auch nicht nach maßstab :( > also einfach E auf H und 450ns warten und dann noch tdhw=10ns min warten > (10ns ist min. wieviel sollte man drauf packen auf sowas um auf der > sicheren Seite zu sein?) > Wie willst Du da was drauf packen? :) > grün: > kann ich die daten nicht schon viel früher anlegen, wo ich grün > eingefärbt habe, dann > spielt tdsu für mich später nicht mehr so die rolle / muss ich nicht > mehr drauf achten. > Du darfst die Daten erst anlegen, wenn R/W low ist sowie CS für diesen Chip aktiv ist, da es sonst zu Buskonflikten kommen wird.
Corny schrieb: > rote farbe: > oben steigt er nochmal an, ohne gründe, warum? und warum unten nicht? Hat der DB-Zeichner so gemacht, ohne weiter nachzudenken. Das Signal E kommt vom 68xx-Bus, dort ist es der Systemtakt, auf den sich alle anderen Bussignale beziehen. Beim 6502 (bekannt vom Apple II oder in leichter Abwandlung als 6510 vom VC64) heißt das Signal Phi2.
>Das Signal E kommt vom 68xx-Bus Ah, gut zu wissen wie das zustande kam. So kann ich noch mehr bei google schnüffeln. Enable E ist ja auch irgendwie clk-signal und enable-signal in einem. >Du darfst die Daten erst anlegen, wenn R/W low ist sowie CS für diesen >Chip aktiv ist, da es sonst zu Buskonflikten kommen wird. OK, nur beim Schreiben laut timing aus dem tri-state raus. >(active low, cs=1 setze) ok, Eigenkorrektur: cs12=H --> enable (active high). Hab das mit E, enable verwechselt, das ist active low. >> (10ns ist min. wieviel sollte man drauf packen auf sowas um auf der >> sicheren Seite zu sein?) >> >Wie willst Du da was drauf packen? :) Naja, ich dachte weil das der "absolute minimum wait" ist? Wenn ich dann delay_ns(10); mach währ er "scharf an der grenze" der zeit die erlaubt ist. Wenn dann die delay-routine eventuell noch runterrundet geht es schief?! Genauso wie: Minimum Voltage 3.1V. Dann nimmt man ja auch etwas mehr, wie eben 3.3V. >Du darfst die Daten erst anlegen, wenn R/W low ist sowie CS für diesen >Chip aktiv ist, da es sonst zu Buskonflikten kommen wird. Hmm, Ok. Aber da ist noch ein Problem: Wie ist das Datenanlegen vom AVR korrekt gemacht? Erst daten anlegen und dann auf output schalten klingt logisch. Aber beim Daten anlegen im input-mode schalte ich ja die Pullups ein, ist das ok, weil es ja nur kurz bis zum nächsten Befehl dauert? Es gibt da zwei mögliche Varianten: ( Anfgangsbedingung: Port in tri-state -> port auf input und pullups aus ) (A) -------------------- 1. Port=Data //Die Eins-Bits legen H-Pegel über die internen Pullup-Widerstände schon an. Die Null-Bits verursachen Tri-State auf der Leitung. 2. Port=OutputMode //Daten Stabil angelegt 3. Warte 4. Port=InputMode // Bus ist noch nicht Tri-State, sondern undefined-state/notAllowed?-State, wenn data-port nicht 0x00 -> manche pullups sind dann ein (Zustand der Leitungen: Ein Mix aus H-Pegel und tri-state) 5. Port=0x00 //Display-Bus ist Tri-State -------------------- ODER (B) -------------------- 1. Port=OutputMode// 0x00 auf dem Datenbus und nicht die gewünschten Daten 2. Port=Data // Daten Stabil angelegt 3. Warte 4. Port=0x00 //Kurzzeitig vor dem umschalten auf Input 0x00 auf dem Datenbus 5. Port=InputMode //Display-Bus ist Tri-State -------------------- Sollte man doch eher Variante (B) nehmen und (A) unbedingt meiden, weil man in (A 4.) in einen (von mir angenommenen) unerlaubten Zustand kommt?
Thread beobachten
Seitenaufteilung abschalten
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.