Hello, Guest the thread was called3.5k times and contains 55 replays

last post from Shadowolf at the

LCD Display Erweiterung für SD2IEC

  • Hallo 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


  • 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.

  • 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.

  • Neue Displays kosten zum Teil mehr als ein SD2IEC und auf die Verfügbarkeit der teilweise sehr günstigen Restposten kann man sich leider garnicht verlassen.


    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 ...



    Das funktioniert so nicht, der Controller des SD2IEC läuft auf 3,0V, da kann man nicht einfach den I2C auf 5V laufen lassen -> der Mega48 sollte auch besser auf 3,0V laufen.


    ok.


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




    Den Quarz würde ich weglassen, mit dem internen RC-Oscillator läuft der Controller bei 3,0V mit etwa 7,5 MHz.
    Für ein Display und ein bisschen daddeldu ist das schnell genug.


    - AREF wird nicht mit VCC verbunden, so garnicht, stattdessen kommen da 100nF gegen Masse dran


    ok.



    - welche Funktion hat R2?


    Mein Fehler, hätte der Reset sein sollen.



    - die beiden LED's fehlen noch die wir von dem SD2IEC ja entfernen, dieses Tochter-Brett soll ja sozusagen als Bedienungs-Panel genutzt werden, daher finde ich gehören die LED's einfach da dran


    ok.



    - das Display bitte nicht mit R/W auf Masse auslegen, das führt in der Software nur zum Timing-Raten


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



    - ich bin mir auch nicht sicher ob D0 bis D3 für den 4-Bit Betrieb auf Masse gelegt werden sollen


    bei meinem MyAVR Testboard ist das so ...



    - der Vor-Widerstand für die Hintergrund Beleuchtung des LCD's fehlt


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



    - der PCF8583 und der GoldCap dazu fehlen auch noch :)[/quote]
    ok fehtl, da mach ich mich noch schlau ...



    - die mechanische Schnittstelle zum Display ist nicht wirklich definiert


    Insgesamt wäre es geschickter, die zu erfüllende Funktion von dem Teil *vor* dem Design festzulegen.
    Die Software muss dann ja auf beiden Seiten implementiert werden, man braucht also gleich eine definierte Schnittstelle.


    Davon versteh ich nix. Bitte besprechen, beschließen und festlegen.

  • 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.


    Daran sollten wir uns nicht aufhängen, hab grad nur dieses ISP Symbol. Sollte nur symbolisch gemeint sein dass da halt ein ISP Anschluss ist.

  • 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.


    Quote


    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.


    Quote


    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.


    Quote


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


    Das sieht nicht wirklich besser aus...


  • 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.


    Quote


    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.


    Quote


    Mein Fehler, hätte der Reset sein sollen.


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


    Quote


    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.


    Quote


    bei meinem MyAVR Testboard ist das so ...


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


    Quote


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


    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.


  • Sorry, bin nur ein Programmierer kein Elektroniker ... :)


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


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



    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 ... ;)

  • 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.

  • Quote


    Sorry, bin nur ein Programmierer kein Elektroniker ... :)


    Warum machst Du das dann eigentlich? :)
    Und nochmal von vorne? ;)


    Quote


    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.


    Quote


    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.


    Quote


    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.

  • Warum machst Du das dann eigentlich? :)
    Und nochmal von vorne?


    Du hast schon Recht, die Elektronik sollte ich euch Profis überlassen.


    Mir ist es am liebsten, ich habe fertige Elektronik und kann mich um Software kümmern. Die Hardware Dinge sehe ich nur als notwendiges Übel an. Wenn man sich mit AVR beschäftigt kommt man aber nicht ganz an der Hardware vorbei ... :roll:


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

  • > 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.


    Quote

    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"? :-)


    Quote

    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!

  • 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.

  • ok fassen wir mal zusammen was an der Hardware noch fehlt:

    • Vorwiderstand für Display ohne Wert, da der Wert vom dann verwendeten Display abhängt.


    • Aufs PWM verzichten wir weil es HF Störungen produziert? Oder gibt es einen "sauberen Weg"? Das mit den zwei Widerständen und dann nur zwei Helligkeitswerten finde ich nicht so toll ...


    • Display immer hell? Oder zumindest schaltbar?


    • Ein Elko für die Platine, - nur wegen dem PWM oder wär der immer gut? Wieviel µF?


    • Mit I2C habe ich mich noch nicht richtig beschäftigt. Ist da der Master fix oder kann das zwischen den Busteilnehmer wechseln? Wenn der Master fix ist, kann der Slave etwas vom Master anfordern (Directory Einträge)? Sonst wär vielleicht doch eine serielle Anbindung einfacher?



    Anforderungen der Software

    • Jiffy an/aus


      Könnte man per Menü einstellbar machen. Dem SD2IEC könnte man einfach eine Sequenz senden: #J=0, #J=1


    • Anzeigen des Momentanen Images


      Man könnte verschiedene Anzeige Modi machen, je nach Geschmack. Auch verschieden Display Größen könnte man dadurch anpassen. So ne Art Skin der am PC erstellt werden kann. Mit Platzhalter wie zb. bei der printf() Funktion.


    • Track/Sektor anzeigen???


      siehe oben


    • Uhrzeit setzen? (falls RTC vorh.?)


      Parameter Menu


    • Browsen (hoch/runter/rein/raus)


      Ein Filemenü quasi. Jetzt verstehe ich was vorher mit Kommando Interpreter gemeint war. Da wäre aber besser eine FAT / FAT32 Sicht als eine IEC Sicht. So MSDOS oder Linux Kommandos an das SD2IEC?


    • Swaplists bedienen wie gehabt


      Nur mit Textunterstützung ...




    Es gibt zwei Möglichkeiten wie man das Problem angehen kann:

    • Das LCD Modul ist ein simples Zusatzmodul um externe Hardware anzuschließen.


      In dem Falle würde alle Aktivität beim SD2IEC liegen. Das LCD Modul wäre ein simples Terminal und würde nur darstellen was das SD2IEC sendet. Wenn der Benutzer Tasten drückt werden die an das SD2IEC gesendet und die Firmware reagiert darauf.


      Vorteile:


      + Das LCD wäre multifunktional und in vielen anderen Projekten einsetzbar


      + Das SD2IEC Projekt würde komplett in einer Hand bleiben bzw. in einer Firmware (der des 644 im SD2IEC).


      + Das Master/Slave Konzept des I2C wäre voll erfüllt.


      + Es wäre eine moderne Software Architektur. In größeren Umgebungen spricht man von Client Server Prinzip.


      Nachteile:


      - Es würde die SD2IEC Firmware mehr belasten und damit mehr Arbeit für Unseen sein. Wobei man da natürlich auch Wege finden kann Logik und statische Texte aus zu lagern.


    • Das LCD Modul ist voll eigenständig und implementiert das komplette Benutzer Interface.


      In dem Falle würde das SD2IEC quasi das LCD Terminal "bedienen". Wenn der Benutzer Tasten drückt werden Parameter an das SD2IEC gesendet, wenn der Benutzer im Dateisystem navigiert fordert das LCD Terminal vom SD2IEC die Direktory Informationen an (LS v b) oder sendet Direktorywechsel (CD) und das SD2IEC reagiert darauf. Hier wäre eigentlich das LCD Interface der "Master und das SD2IEC hätte eine Dienstleister ("Slave") Funktion.


      Vorteile:


      + Das SD2IEC stellt eine Schnittstelle zur Verfügung und braucht sich um mehr nicht zu kümmern (geringerer Aufwand in der SD2IEC Firmware)


      + Es wären andere Erweiterungen denkbar als nur das LCD Display (PC Applikation)


      + Das LCD Display wäre in unterschiedlichsten Ausführungen denkbar (2 Zeilen, 4 Zeilen, 16 zeichen, 24 Zeichen) ohne dass es das SD2IEC betrifft. Nur die Firmware des LCD Teil muß angepasst werden.


      Nachteile:


      - Das LCD Teil wäre nur für den Zweck da und könnte für nichts anderes verwendet werden.



    Ich habe erst nur an die einfachere (erste) Variante gedacht. Aber natürlich könnte auch die zweite Variante interessant sein.

  • Also je mehr ich darüber nachdenke, desto mehr freunde ich mich wieder mit der ursprünglichen RS232 Idee an. Die Vorteile liegen auf der Hand:

    • Es gibt keinen Master/Slave, sondern es erfolgt Event gesteuert. Wenn das SD2IEC eine LED schalten will kommt ein Kommando dafür. Wenn das SD2IEC die Uhrzeit/Datum braucht kommt ein Request. Wenn der Benutzer ein Directory sehen will kommt ein Kommando vom Interface an das SD2IEC.


    • Ich brauche keinen Atmel, sondern kann alles am PC programmieren. Wenn es mal eine LCD Hardware gibt kann ich das immer noch portieren. Kein löten und kein Hardware gebastel, nur eine USB Bridge an das SD2IEC anlöten und gut. Und die habe ich schon da ...



    Unseen ist unbedingt notwendig für dieses Projekt. Es sind also nur noch drei Fragen zu klären:

    • Machen wir es? Hast du Lust Unseen?


    • Ist es ok wenn ich das "Protokoll" ausdenke und vorlege oder willst du es machen Unseen?


    • Wie ist der Zeitrahmen? Ziehen wir das rasch durch oder hat das niedrige Priorität für die SD2IEC Entwicklung? Machen wir es in einem Schwung oder erweitern wir es vor zu? Sollen wir uns einen Zeitplan überlegen oder kann man keinen Zeit Horizont setzen?
  • Vorschlag:


    Kommandos vom SD2IEC an das Interface:


    SO #


    set output. # ist eine Nummer. Jetzt mal nur 0 (Led 0) und 1 (Led 1). Schaltet LED ein.


    FO #


    flash output. # ist eine Nummer. Jetzt mal nur 0 (Led 0) und 1 (Led 1). Bewirkt dass die LED blinkt.


    RO #


    reset output. # ist eine Nummer. Jetzt mal nur 0 (Led 0) und 1 (Led 1). Schaltet LED aus.


    GT


    get timestamp. Das Interface antwortet mit "TS=hh:mm:ss dd.MM.yyyy". hh=Stunde, mm=Minute, ss=Sekunde, dd=Tag, MM=Monat, yyyy=Jahr


    SDS:"xxxxxxxxx"


    show disk status. Damit kann ein Anzeigefeld "Disk Status" aktualisiert werden.


    STR:


    show track. Damit kann die aktuelle Spur angezeigt werden.


    STR:


    show sector. Damit kann der aktuelle Sektor angezeigt werden.


    SIM:


    show image. Damit kann das aktuelle D64 image angezeigt werden.


    SDI:imagefile,#device


    show directory. Damit kann das aktuelle Verzeichnis nach einem CD vom C64 angezeigt werden.