LCD Display Erweiterung für SD2IEC

Hallo Diddl,

Zitat von Diddl

Die Dioden braucht man für diese 'Verrückten' die nix normal bedienen können und alles bis zum Excess ausprobieren. Ohne Dioden bringt man tatsächlich Tasten Kombinationen zustande die nicht mehr abfragbar sind. Außerdem kosten die Dioden nix, man kann sie aber auch einfach weglassen wenn man möchte.

Das ist aber etwas anderes. Damit Du wirklich alle Tasten abfragen kannst, auch wenn mehr als zwei gedrückt wurden, ist es nötig, vor jeden Taster eine Diode zu schalten, nicht nur vor jeder Tastergruppe!

Mit Deiner Beschaltung vermeidest Du nur, daß wenn Row0 bis Row2 Ausgänge sind, welche kein "Open Collector"-Ausgänge sind, beim Drücken von mehreren Tastern, zwei Ausgänge verschiedener Pegel zusammen-"gedrückt" werden können. Aber das könnte man auch mit "Open Collector"-Ansteuerung in Software gießen und diese Dioden einsparen. Col0 bis Col2 benötigen noch Pullups, welche aber auch intern am Port mittels Software geschaltet werden können.

Ausnahme, man möchte wirklich alle Taster gleichzeitig gedrückt abfragen wollen, dann kommt man eben nicht um eine Diode für jeden Taster drumherum.

Gruß Martin

Zitat von znarF

Irgendwie ist das Missverstanden worden der ISP passt schon 6polig nur sollte er folgende Belegung haben, eben wie beim sd2iec:

Die Belegung ist schon gleich, Standard Atmel.
Nur die mechanische Ausführung ist unterschiedlich.

Statt 2x3 Pins in 2,54 mm Pfostenleiste habe ich 1x6 Pins als 1,27 mm Reihe benutzt.
Das passt 1:1, ein Adapter mit Flachkabel ist dafür schnell gemacht.

Ich ziehe meine Lösung aber auch vor da die weniger Platinenfläche braucht und die Fläche an den Platinen für uns das teuerste ist.

Zitat von skoe

Es gab gestern gar keine Reaktion auf den Vorschlag, den ohnehin existenten Kommandoparser (doscmd.c IIRC) zu verwenden. Zu abwegig? Falls Unseen keine Zeit/Interesse hat, hätte ich sonst angboten, mir das anzuschauen. Aber ich will mich ja auch nicht aufdrängeln...

Theoretisch ginge das schon, aber dann muss irgendwas (im Zweifelsfall der Benutzer) darauf aufpassen das nicht zu machen wenn der C64 gerade aktiv ist weil der Puffer für Kommandos und Dateinamen statisch alloziert ist - spart ein wenig Platz, da man sich teilweise darauf verlassen kann welcher Kommandobuchstabe wo zu finden ist. Ausserdem kommt man nur mit den Kommandos nicht wirklich weit, einige davon brauchen auch noch einen zusätzlichen Buffer für die Daten (zB Blockzugriffe) und alle Dateizugriffe (dazu zählt auch das Laden eines Directories) laufen über fileops.c.

Zitat von Diddl

Die Frage ist nur ob dann das Display noch angesteuert werden kann? Dem I2C ist das wurscht weil OC.

Dem ist das nicht egal sobald die Schwelle für die High-Pegel-Erkennung unterschritten wird oder die Pins eines Chips Spannungen bekommen die oberhalb der maximal erlaubten liegen. Ein Pegelwandler für I2C ist trivial, siehe NXP Appnote AN97055.

Zitat

Versteh ich nicht, bei meinem MyAVR Testboard ist es auf GND und funzt. Aber ok, drin.

Man kann die Displays auch mit R/W auf Masse ansprechen, aber wenn man das Busy-Flag abfragen kann geht es deutlich schneller.

Zitat

bei meinem MyAVR Testboard ist das so ...

IIRC mögen manche Displays das nicht, wenn ein Datenblatt zum Display oder zum verwendeten Controllerchip (zum richtigen, nicht zu einem zu dem der kompatibel ist!) vorhanden ist kann das weiterhelfen. Schlimmstenfalls müssen eben ein paar Jumper oder Lötbrücken vorgesehen werden.

Zitat

Jetzt auf PWM Signal vom AVR. So kann man das Licht schön dimmen ...

Das sieht nicht wirklich besser aus...

Zitat von Diddl

Die von mir vorgeschlagenen Displays sind neu und auch in großer Menge zu kriegen.

Außerdem kann es durch fast jedes beliebige ersetzt werden. Das wichtige ist die LCD Platine, jeder kann sein Wunsch Display anschließen, weil die sind eh alle kompatibel ...

Also im Grunde genau das, was ich schon vorgeschlagen hatte.
Standard 16 Pin Buchsenleiste für HD44780 Display.
Fehlt nur die Grösse des Displays, also zum Beispiel 2x16 Zeichen weil die am weitesten verbreitet sind.

Zitat

ok.

Die Frage ist nur ob dann das Display noch angesteuert werden kann? Dem I2C ist das wurscht weil OC.

Dem I2C ist das nicht egal, weil man dann trotzdem nicht die maximalen Pegel verletzen darf.
Für die AVR's gilt VCC+0,5V.
Also bei 3,0V sind das maximal 3,5V am Mega644.
Die mindest-Spannung die als logisch 1 erkannt wird ist bei den meisten AVR's als VCC*0,7 angegeben.
Aber ich sehe gerade im Mega48 Datenblatt das bei VCC=2,4V-5,5V gilt Vih = VCC*0,6.
Das wären dann 5 * 0,6 = 3,0V.
Das müsste also mit einem einfachen Spannungsteiler auf 3,3V laufen, also statt des Pullup's.

Kann man ja alles auf dem Steckbrett ausprobieren.

Displays die ab 3V laufen sollten aber auch nicht das Problem sein.

Zitat

Mein Fehler, hätte der Reset sein sollen.

Ist überflüssig, da im Controller bereits integriert.

Zitat

Versteh ich nicht, bei meinem MyAVR Testboard ist es auf GND und funzt. Aber ok, drin.

Wenn man den Busy-Zustand nicht auslesen kann muss man raten, ob das Display bereits wieder
Daten annehmen kann.
Dieses Raten passiert meist durch die Verwendung von busy-wait delay()'s.

Das ist ganz schlechter Programmier-Stil.

Zitat

bei meinem MyAVR Testboard ist das so ...

Das MyAVR Board würde ich eher nicht als Referenz benutzen.
Um mich mal vorsichtig auszudrücken.

Zitat

Jetzt auf PWM Signal vom AVR. So kann man das Licht schön dimmen ...

Keine gute Idee, das erzeugt nämlich hochfrequente Störungen für ein kaum gebrauchtes Feature.
Ausserdem kostet das wieder einen Transistor.

Habe gerade erst den aktualisierten Schaltplan gesehen.

Q1 funktioniert so nicht.
An der Basis eines Transistors müssen typischerweise 0,7 gegenüber dem Emitter anliegen, damit der Transistor durchschaltet.

Daher legt man den Emittor normalerweise auf Masse.

Mit der Anode der LED am Emitter kann es passieren, das die Spannung an der Basis garnicht hoch genug werden kann, um den Transistor zu schalten.

Es gibt auch Displays mit blauen oder gar weissen LED's und Displays, bei denen mehrere LED's in Reihe hängen.

Und ein Vor-Widerstand ist immer noch nicht drin.

das finde ich aber auch nicht schlecht!

man wäre das geil wenn ich noch n display für sd2iec in den c64II einbauen könnte
das teil besteht bald nur noch aus tastatur + platine + schaltern und helben etc

Zitat von Diddl

Die Transistorschaltung ist exakt von meinem MyAVR Display Board abgekupfert. Kein Vorwiderstand, Emitter auf Anode der Beleuchtung.

Verwenden die da wirklich einen BC547? Mit einem PNP-Transistor und Vertauschen von Emitter und Kollektor sähe der Schaltplanteil schon spürbar sinnvoller aus.

Edit: Sie verwenden da laut eigenem Schaltplan wirklich einen 547C, aber der 1k2-Widerstand ist der Basisvorwiderstand und bei PWM-Jumperung nicht zwischen Kollektor und Basis geklemmt.

Zitat

Sorry, bin nur ein Programmierer kein Elektroniker ...

Warum machst Du das dann eigentlich?
Und nochmal von vorne?

Zitat

Die Transistorschaltung ist exakt von meinem MyAVR Display Board abgekupfert. Kein Vorwiderstand, Emitter auf Anode der Beleuchtung.

Das MyAVR Teil gefällt mir immer weniger.
Also, Emitter gehört auf Masse, Anode LCD auf 5V, Kathode LCD auf Vor-Widerstand, Vor-Widerstand auf Collector.

Zitat

Bitte Vorwiderstand (Wert) oder Beleuchtungsschaltung vorschlagen, ich kann das leider nicht besser (nur abkupfern).

Der Vor-Widerstand scheint in den LCD-Modulen auf dem MyAVR LCD Add-on bereits eingebaut zu sein.
Für exakt dieses Display bräuchte man einen Wert von Null Ohm.
Für jedes andere Display hängt der Wert von der Farbe und der gewünschten Helligkeit ab.

Also zum Beispiel blaues Display, nicht so hell, 56 Ohm.

Den genauen Wert muss man dann anhand des Datenblattes vom Display ausrechnen.

Zitat

In einem Punkt muss ich widersprechen: Die PWM Beleuchtung sieht cool aus. Habe das hier laufen mit dem MyAVR Board: Nach 15 Sekunden keine Bedienung dimmt das Licht schön langsam runter. Bei einem Tastendruck wirds sofort hell. Ist irgendwie nett, bin halt ne verspielte Type ...

Und wo ist jetzt der Widerspruch?
Das das nett aussehen kann, dem habe ich ja garnicht angesprochen.
Ich habe geschrieben, dass man das kaum braucht und das es dafür zu sehr die Gefahr bringt, Störungen zu verursachen.
PWM bedeutet nichts weiter als die LED's schnell an und wieder aus zu schalten.
Schnelles Schalten bedeutet Störungen.

Für Deine Funktion würde es auch reichen einen Vor-Widerstand von der Kathode der Beleuchtung direkt an Masse zu klemmen und einen zweiten Widerstand parallel dazu über einen Transistor schaltbar zu machen.
Dann hätte man wenigstens zwei Helligkeitsstufen und nur jeweils einen Strom-Sprung.
Zusätzlich würde ich für sowas aber auf jeden Fall noch einen kleinen Elko vorsehen um die Strom-Spitze wenigstens ein klein wenig abzufedern.

> Muss weg. Gibt sonst Ärger...

Oh, das klang aber missverständlich. Gemeint war: *Ich* muss weg, sonst bekomme *ich* Ärger. Der Grund war der erhobene Zeigefinger meiner besseren Hälfte mit einem Blick auf die Uhr.

Wg. der Dioden: Ich stell mal die These auf, dass wenn Du immer _genau eine_ Zeile (oder von mir aus Spalte) auf Ausgang schaltet und die anderen 5 auf Eingang, dass Du beliebige zwei Tasten erscannen kannst. Mehr evtl. nicht, aber Kurzschlüsse kann es dann auch keine geben. Und wenn die Eingänge Pullups haben, brauchst Du keine disktrete beschaltung mehr. Das hatte HofMar vermutlich auch gemeint.

Zitat

Theoretisch ginge das schon, aber dann muss irgendwas (im Zweifelsfall der Benutzer) darauf aufpassen das nicht zu machen wenn der C64 gerade aktiv ist weil der Puffer für Kommandos und Dateinamen statisch alloziert ist - spart ein wenig Platz

Deshalb hatte ich im Hintergrund, den Parser den zu parsenden Puffer übergeben zu können. Würde aber den Code etwas größer machen. Eine weniger elegante aber sehr platzsparende Lösung wäre ein globaler Pointer, der vor dem Aufuf auf den zu parsenden Puffer zeigt. Dann braucht man den Parameter nicht durcheichen. Der Kommandopuffer für die Ansteuerung über I2C bräuchte nur ein paar Bytes groß sein, Grund s.u. Man sollte aus bereits genannten Gründen auf keinen Fall C64 und I2C in einen Puffer schreiben lassen.

> Davon versteh ich nix. Bitte besprechen, beschließen und festlegen.
Ich glaube, er meinte: Was _genau_ soll das Ding denn können und als nächster Schritt _wie_ genau kommunizieren die beiden Teile. Erst dann: Wie sieht die Hardware aus, um das Ziel zu erreichen. Du bist doch Software-Entwickler, da solltest Du doch was davon verstehen

Was heißt eigentlich "NUR Programmierer"?

Zitat

einen zusätzlichen Buffer für die Daten (zB Blockzugriffe) und alle Dateizugriffe (dazu zählt auch das Laden eines Directories) laufen über fileops.c.

Darüber hab ich auch nachgedacht. Fangen wir doch mal mit der von Shadowolf zu recht geforderten Spezifikation an:
- Jiffy an/aus
- Anzeigen des Momentanen Images
- Track/Sektor anzeigen???
- Uhrzeit setzen? (falls RTC vorh.?)
- Browsen (hoch/runter/rein/raus)
- Swaplists bedienen wie gehabt
was noch?
Ohne das Browsen fände ich persönlich das Display nicht sonderlich nützlich.

Außer das Browsen ist das ganze von der Schnittstelle recht einfach.
Fürs browsen bräuchte man in etwa:
- ls
- cd ..
- cd <bla> (nur eine Ebene, deshalb vorhersehbare Länge)

Für das ls würde ich nicht load"$" umfunktionieren, sonder eine Extrawurst implementieren, die das Directory mehr oder weniger unbehandelt durchreicht. Könnte man dann auf den sonst benötigten 256-Byte-Puffer verzeichten?

Der Display-Module-Controller kann sich natürlich nicht beliebig lange Directories merken. Desalb sollte er sich z.B. 5 Zeile rausfischen, und wenn er oben oder unten angekommen ist, die nächsten anfordern (also wiederholtes "ls". Eventuell sinngemäß "ls 9 5" = ls ab Eintrag 9, 5 Einträge.

> Außerdem kann es durch fast jedes beliebige ersetzt werden.
Vorsicht, die Displays sind zwar meist pinkompatibel und haben kompatible Controller. Aber z.B. der Vorwiderstand für das Display ist anders und evtl. die aus dem Datenblatt erkennbare Initialisierungssequenz.

> ich bin mir auch nicht sicher ob D0 bis D3 für
> den 4-Bit Betrieb auf Masse gelegt werden sollen
Das hab ich auch mal versucht, für ein Display herauszubekommen. War dem Datenblatt einfach nicht zu entnehmen. Nur zwei verschiedene Initialisierungssequenzen waren abgedruckt. Kann es sein, dass die Initialisierungssequenzen am Anfang immer nur 4 relevante Bits benutzen und dadurch SW-mäßig auf die Bitbreite eingestellt werden? Nur eine Vermutung, müsste man mal Datenblätter verschiedener Displays vergleichen.

> Sorry, bin nur ein Programmierer kein Elektroniker ...
Die Posts klingen teilweise etwas vorwurfsvoll, dass stimmt schon. Aber ist sicher nicht so gemeint. Ich finde es super, wie Dich alle unterstützen. Trotzdem solltest Du vielleicht etwas weniger schnell "malen" und etwas mehr Datenblätter lesen. Da stehen immer solche Dinge wie maximale/minimale Pegel etc. drin.

> Die PWM Beleuchtung sieht cool aus.
PWM ist wirklich dafür bekannt, EMV-mäßig Dreck zu machen, das kann ich aus eigener Erfahrung bestätigen. Muss man dann im Layout aufpassen, dass die Leiterbahnen kurz sind und nicht dicht parallel zu anderen Signalen. Und ordnungsgemäße Kondensatoren in der Versorgung. Das Dimmen finde ich auch schick, aber kann man bei dem Teil nicht einfach immmer das Licht anlassen?

Wg der LEDs: Würdest Du das Licht immer anlassen, könntest Du die LEDs auch als Dezimalpunkte im Display anzeigen ---- ach nein, das ist Mist.

Viel Glück und vor allem viel Spaß noch!

Zitat von Diddl

Hab halt versucht etwas Bewegung in die LCD Geschichte zu bekommen ...

Ist doch voll und ganz gelungen.

Zitat von skoe

Ohne das Browsen fände ich persönlich das Display nicht sonderlich nützlich.

naja wenn ich ne swapliste habe mit sagen wir 50 images kann ich doch darin auswählen und weiß dank display immer in welchem image ich mich befinde!

wenn eine swapliste mal etwas länger wird verliert von ohne ende den überblick!

dann noch anzeigen geräteadresse
firmwareversion vllt
füllstand der SD karte
track zb bräuchte ich nicht
und eventuell das man zb zwischen 2 swaplisten wählen kann oder sowas.