Dafür habe ich mir bei Reichelt einen 500kHz Keramik-Oszillator und zwei 22pF-Keramik-Kondensatoren bestellt. Entsprechend dem Diagramm im Datenblatt habe ich die Bauteile an den AVR angeschlossen. Dann habe ich ihn über den ISP-Port mit dem PC verbunden und die Standard-Einstellungen der Fuse-Bits wieder hergestellt.

Jetzt läuft er wieder mit einem MHz internem Takt und rechnet fröhlich vor sich hin

Um den AVR auf einen externen Oszillator einzustellen, muss man die Fuse-Bits entsprechend setzen. Sollte an sich ja nicht so schwer sein. Das Problem ist nur, wenn man die Bits falsch setzt – z.B. auf einen anderen Oszillator als man besitzt – tut der AVR danach nix mehr

Mein Problem ist, dass ich die Fuse-Bits so gesetzt habe, dass der AVR einen externen Quarzkristall mit einer Frequenz zwischen 0,4 und 0,9MHz akzeptiert. 0,032768MHz sind da allerdings etwas zu wenig für… und so habe ich im Moment einen toten Mikrocontroller, da auch zum Ändern der Fuse-Bits ein Taktsignal benötigt wird.

Aber demnächst besorge ich mir einen passenden Oszillator und dann geht es weiter

Um das Display zu testen habe ich mir erstmal ein paar Routinen geschrieben, die das Display initialisieren und einen String darauf ausgeben. Dieses Programm hänge ich mal an den Beitrag an, damit ihr einen kleinen Eindruck kriegt Aber Achtung: Es fängt im Moment noch keinerlei (Bediener-)Fehler ab! D.h. ein zu langer String oder eine falsche Position auf dem Display können eine unvorhergesehene Reaktion nach sich ziehen…. oder es funktioniert einfach. Ich habe das noch nicht ausprobiert Mit Zahlen und Buchstaben funktioniert es bisher auf jeden Fall… Sonderzeichen habe ich noch nicht getestet.

Ich habe es auch geschafft, meinen Schaltplan mal halbwegs ordentlich umzusetzen, so dass der Sourcecode auch direkt etwas mehr Sinn ergibt

An einigen Stellen kann an der Verschaltung bestimmt noch gefeilt werden, aber für’s erste funktioniert es so schonmal.

Ein paar Probleme bzw. Unklarheiten, die bei mir aufgetreten sind:

• das E(nable)-Bit: Dieses Bit muss gesetzt werden, damit der Controller des LCD die anliegenden Daten übernimmt. Solange das Bit High ist, darf sich der Zustand der anderen Bits nicht ändern, sonst gibt es Probleme Damit dieses Bit immer einen definierten Zustand hat, habe ich es über einen parallelen 10k Ohm Widerstand auf Masse gelegt.
• die Versorungsspannung des Displays: Achtet darauf, dass die Versorgungsspannung groß und stabil genug ist. Ich hatte anfangs das Problem, dass ich statt 5 nur 3V anliegen hatte. Das Display lief damit zwar auch, aber nicht lange. Es erschien kurz der Text und danach verschwand er aber auch sofort wieder (da das Display einen Reset ausführte).

Klingt in der Theorie wieder mal alles ganz gut Aber leider sieht die Praxis schon wieder ganz anders aus: Auf der PC-Seite kommen sehr merkwürdige Dinge an. Sowohl mit meinem Programm als auch mit gtkterm, einem Terminalprogramm, bei dem man sehr bequem die Schnittstelle konfigurieren kann und sich die empfangenen Daten als HEX-Ziffern anzeigen lassen kann, kommt nicht annähernd das an, was ich gerne hätte.

Ich fürchte, dass die kleine Schaltung eben doch nicht die benötigte Qualität hat, um ein sauberes Signal an den PC zu schicken. Es führt also wohl kein Weg an einem Max232 vorbei…

Aber eventuell erklärt dieses Verhalten das Problem, das ich bei dem Sensor-Array hatte: Die stark schwankenden Probleme könnten auch hier in einem Übertragunsproblem begründet sein. Ich denke, ich werde hier nochmal ein wenig nachforschen.

Also wie ich im letzten Beitrag schon geschrieben habe, benutze ich für die Kommunikation zwischen dem PC und dem AVR I²C. Dazu habe ich eine Schaltung benutzt, die ich auf dieser Seite gefunden habe. Sie besteht nur aus 2 Z-Dioden und 2 4,7k Widerständen und ist somit recht leicht aufzubauen. Auf der Seite gab es auch direkt den Quellcode, der benötigt wird, um I²C mit dem AVR zu sprechen. Leider stellte sich heraus, dass I²C ein recht langsames Protokoll ist. Aber damit musste ich erstmal leben, da ich noch immer keinen MAX232 oder einen ähnlichen Wandlerbaustein besitze.

Ich habe dann also angefangen, das LED-Array zum Messen der Helligkeit zu nutzen. Dazu ist es nötig, die LED entgegen der Durchlassrichtung “aufzuladen” (sie verhält sich dann ähnlich wie ein Kondensator), den Pin mit hohem Potential auf Input zu schalten und die Zeit zu messen, bis man eine logische 1 misst. Diese sollte sich proportional zum einfallenden Licht ändern. Und damit wäre es dann leicht möglich, das LED-Array als Sensor-Array zu nutzen, indem man die LEDs schnell zwischen Licht emittieren und Licht messen umschaltet.

Soviel zur Theorie. In der Praxis sieht es derzeit bei mir leider so aus, dass die Messwerte von einer LED zur nächsten, aber auch von einer Messung zur nächsten bei der gleichen LED so stark schwanken, dass keine sinnvolle Auswertung möglich ist. Dabei spielt es keine Rolle, ob es gerade hell oder dunkel ist. Die Helligkeitsverältnisse haben zwar einen Einfluss auf die Messwerte insgesamt, aber die Fluktutation ist dennoch zu groß um eine sinnvolle Auswertung der Messwerte vorzunehmen.

Im Moment versuche ich mich daran, doch über den USART des AVR über RS232 mit dem PC zu sprechen, um eine größere Bandbreite zur Verfügung zu haben. Ich vermute nämlich, dadurch, dass ich nur eine Messung pro Sekunde vornehme, die LEDs sich irgendwie doch noch anders aufladen oder von der Helligkeit der Nachbar-LEDs zu stark beeinflusst werden. Ich hoffe, dass in einer kontinuierlicheren Messung diese Schwankungen entweder deutlicher als überlagertes Signal zu erkennen sind, das man ausfiltern kann oder sogar von alleine verschwinden.

Um die Kommunikation über RS232 zu ermöglichen, habe ich hier eine Schaltung gefunden, die auch ohne Wandlerbaustein funktionieren soll. Ich bin mal gespannt…

Falls jemand zufällig weiß, woran mein oben beschriebenes Problem liegen könnte, darf gerne einen Kommentar hinterlassen

Ach ja: Die versprochenen Bilder kann ich derzeit nicht liefern, da meine Handykamera nur ziemlich unscharfe Bilder produziert und ich die andere derzeit nicht finde.

Mit dieser Grundausstattung wollte (und will) ich mal ein bisschen Praxis in das sonst doch eher theoretische E-Technik Studium bringen. Die Motivation dazu kam unter anderem aus diesem netten Video und der hier beschriebenen Eigenschaft einer LED, auch als Lichtsensor verwendbar zu sein.

Nachdem der AVR nach nur 2 Tagen (Sonntag bestellt, Dienstag schon da) und das Breadboard dann am Donnerstag angeommen ist, konnte ich auch recht schnell loslegen. Am Dienstag habe ich mir direkt einen einfach Programmieradapter für den Parallelport nach diesem Schaltplan zusammengelötet – zum Glück hatte ich mir vorher darüber Gedanken gemacht

Als dann endlich auch das Breadboard bei mir war, konnte es richtig losgehen. Da mein Ziel ja ein LED-Sensor-Array war, habe ich damit angefangen, dieses auf dem Steckbrett aufzubauen. Ich habe dafür eine einfache Matix-Anordnung gewählt, bei der ich mit 8 Anschlüssen 16 LEDs einzeln steuern kann. Da ich erst abends mit dem Basteln angefangen hatte, habe ich an dem Tag auch nicht mehr geschafft. Aber für den Anfang war ich ganz zufrieden

Am nächsten Tag habe ich mich dann mal an die Programmierung des AVR gewagt: Zuerst habe ich erstmal herauszufinden versucht, wie ich einzelne Pins ansteuern kann, so dass ich die LEDs auch mit richtig gepolter Spannung versorgen kann. Dabei ist dann eine kleine Lichtshow entstanden, die das Array mit einer horizontalen und dann einer vertikalen Linie durchfährt und anschließend jede LED einzeln zum Leuchten bringt. Es sah ganz nett aus, war aber natürlich nichts besonderes. Sollte es aber auch gar nicht sein, schließlich wollte ich nur wissen, wie ich die Ausgänge ansteuern kann.
Später wollte ich dann ausprobieren, wie ich Daten in den AVR hinein bekommen kann, so dass ich meinem angestrebten Ziel etwas näher käme, aber das stellte sich dann doch schwieriger heraus als ich erst dachte. Es hieß jetzt erstmal die Dokumentation zu wälzen und herauszufinden, wie man den Timer, die (digitalen) Input-Pins und dergleichen benutzt. Außerdem wollte ich die Daten ja nicht nur messen, sondern auch an den PC übermitteln. Da ich keinen RS232-Wandlerbaustein habe, schied der USART des AVR erstmal aus und ich entschied mich für I²C. Auch das wollte erstmal verstanden, entwickelt bzw. gefunden und getestet werden…

Mehr dazu schreibe ich aber erst morgen, da ich für den Moment genug geschrieben habe. Morgen folgt dann die weitere Beschreibung, (hoffentlich) ein paar Fotos, vielleicht etwas Quelltext und die aktuellen Probleme.