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?
