Ladeelektronik für Solarmodule (1x12V)

Basiert wesentlich auf http://dc7gb.darc.de/projekte/Solarlader.html . Das zugehörige Akkumodul für einen kleineren Bleiakku wurde unverändert nachgebaut.

Meine Änderungen an der Hardware:

  • Kein LCD
  • ATmega644 als Basis
  • Angepasstes Platinen-Layout

Die Software wurde auf Basis C selbst implementiert.

Lademodul Schaltung

 

RS232 Erweiterung für Lademodul

 

 


RS232 Erweiterung für Lademodul. Dient dem vorübergehenden Anschluss eines RS232-Geräts zum Debuggen

Nachtrag

In der Praxis von rund 18 Monaten Jahren Nutzung waren Nachbesserungen nötig.

Schwingungsneigung LM2936: In der Praxis stellte sich heraus, dass der Spannungsregler LM2936, wenn wie in der Originalschaltung verwendet, Neigung zum Selbstschwingen hat. Dann erzeugt er um die 5V Ausgangsspannung einen Sägezahn von 2,4V Amplitude. Dies führt zu Übertragungsfehlern im I2C Protokoll. Das Selbstschwingen ist nur beim Einschalten des Lademoduls und dann auch nur für die ersten 15..30 Sekunden vorhanden.
Abhilfe: Parallel zu C8 (1u) noch einen Elko 10u direkt an die Lötstellen des C8 anlöten. Dann ist die Schwingung nicht mehr mehr vorhanden.

Probleme mit USI TWI Hardware des ATtiny *61: Über einen Zeitraum von etwa einem Jahr habe ich an der Ansteuerung der USI Hardware des ATtiny immer wieder nachgebessert. Die Kommunikation lief nie ohne Probleme über einen längeren Zeitraum. Das USI Modul verhielt sich merkwürdig, so dass auch die TWI Hardwareimplementierung des ATmega aus dem Tritt kam. Z.B. wurde SDA durch USI aus unbekannten Gründen immer mal auf LOW gehalten, so dass der Master nicht mehr kommunizieren konnte. Schließlich habe ich einen selbtgeschriebene TWI Softwareimplementierung verwendet, mit der die Übertragung dann endlich stabil und dauerhaft ohne Aufsicht lief.

ATtiny 461 für TWI Software Implementierung zu klein: Ich musste auf einen ATtiny861 gehen, da die 4K Grenze überschritten wurde.

Weiterführendes

Breakout Board für das Pollin-AVR-Board

Von Pollin (http://www.pollin.de) wird seit längerem das AVR Board angeboten. Es besitzt für den Anschluß eigener Bauelemente eine 40-polige Buchse („J4“).

Für diese Buchse habe ich ein Breakoutboard entworfen, welches die 32 Port-Leitungen sowie VCC und GND auf Lötstifte führt. Die Pins des Pollin-Boards können so leichter in Experimentierbaufbauten verwendet werden. Alle 40 Pole des Pollin-Boards sind auch auf dem Breakout-Board verfügbar. VCC und GND wurden auf jeweils drei Lötstifte geführt.
(Von Pollin ist ebenfalls ein Breakout Board erhältlich, dass allerdings auf eine 40-polige Stiftleiste geführt ist. Finde ich immer noch etwas fitzlig fürs Experimentieren).

Das Breakout-Board und das Pollin-Board werden über handelsübliche IDE-Flachkabel miteinander verbunden.

Das Breakout-Board kann mit einem 390 Ohm Widerstand+LED bestückt werden und zeigt so die Verfügbarkeit von VCC an. Die Buchse („Wannenstecker“, Bestellnummer „WSL 40G“) ist z.B. bei http://www.reichelt.de erhältlich.


Bestücktes Breakout-Board

 


Breakout-Board Lötseite

 


Verbindung der beiden Boards mittels IDE-Flachkabel

Eagle-Dateien (Schaltplan und Board-Datei): ZIP

SD-, SDHC- und MMC-Karten an AVR anschließen

SD-Karten (von der SD Association spezifiziert) und die älteren MMC-Karten sind billige Massenspeicher mit geringem Stromverbrauch. Neben einem eigenen Protokoll („native bus“) verstehen MMC- und SD-Karten auch eine Kommunikation mittels SPI. SPI spricht der AVR schon von Hause aus. Es ist daher nicht allzu schwer, eine solche Karte an den AVR anzuschließen.

Neben den SDSC-Karten (SC=Standard Capacity, normalerweise als SD-Karten bezeichnet) gibt es auch die elektrisch gleichen, aber software-technisch unterschiedlichen SDHC-Karten (HC=High Capacity) und seit 2009 SDXC-Karten. SDSC-Karten haben FAT12 oder FAT16-Filesystem. Mit FAT16 kann man bis 2GByte darstellen. Manche Hersteller bieten allerdings auch 4GB mit SD-Karten an. Mehr geht aber nur mit SDHC, die ein FAT32 Filesystem haben. SDHC ist bis 32GB spezifiziert, SDXC dann bis 2TB.

Neben den „normalen“ SD-Karten gibt es auch MicroSD-Karten, die deutlich kleiner sind. Abgesehen von den Abmessungen sind sie aber genauso zu nutzen wie die großen SD-Karten. Mit einem einfachen SD-Adapter können MicroSD-Karten genauso wie SD-Karten verwendet werden.

Für unterschiedliche Anwendungsbereiche gibt es unterschiedliche Geschwindigkeitsklassen, von „Class 2“ bis „Class 10“ (2011). Die Zahl steht für die Transferrate in MByte/s beim Schreiben.

Einige Speicherkarten, von oben links im Uhrzeigersinn: SDHC, SDHC, SD, MMS (8MB), alte SD (16MB). Die beiden SDHC-Karten sind mit dem Symbol für die Geschwindigkeitsklasse „Class 2“ versehen.


Eine MicroSD-Karte mit SD-Adapter

Hardware

Für das mechanische Anschließen der Karte kann man sich einen SD-Kartenslot fertig kaufen. Der Slot besitzt meist auch einen Pin, an dem man eine eingeschobene Karte erkennen kann. SD-Karten besitzen einen Schreibschutzschalter, den man abfragen kann. Wichtig sind die folgenden Pins:

SPI Funktion SD-Karte Pin-Nr. AVR Pin-Nr. (am Beispiel AT Mega 32) (Pin-Nr. Pollin-Board)
CS – Chip Select 1 SS – PB4 muss als Ausgabe-Pin konfiguriert werden, es kann aber ein beliebiger anderer Pin für das CS-Signal genutzt werden. Nur wenn SS aus Ausgabe-Pin konfiguriert ist, läuft der AVR als SPI-Master. z.B. 1 (=Port A, Pin0)
DI – Data In / CMD 2 MOSI – PB5 14
DO – Data Out / DATA 7 MISO – PB6 15
CLK – Clock 5 SCK – PB7 16
Ground 3 und 6 Beide Pins zusammenschalten! 39
Vcc 4 Vcc soll zwischen 2,7 und 3,6V liegen

Nach einem allgemein anerkannten Vorgehen wie bei Ulrich Radig beschrieben, kann die Vcc für die Karte aus 5V über den Spannungsabfall an zwei Dioden (je 0,7V) gewonnen werden. Die Pins CS, DI und CLK müssen über Spannungsteiler an den AVR angeschlossen werden, wenn dieser mit Spannungen >3,6V betrieben wird. Für 5V werden üblicherweise 1,8K Richtung AVR und 3,3K gegen Masse genommen. DO wird direkt auf den AVR-Eingang gelegt.


Pinbelegung, SD (oben) und MMC (unten)

Software

Das Thema SD-Kartenanschluss ist bereits vielfach von Null an angegangen worden. So gibt es fertige Bibliotheken und Anwendungen hierfür. Siehe hierzu ganz unten „Links“.
Ich habe mir mehrere Bibliotheken angesehen und dann mit der Bibliothek von Roland Riegel experimentiert, weil diese gut dokumentiert ist auch schon von vielen Nutzern erfolgreich eingesetzt wurde.

Kommunikationsbetrachtung

Obwohl das Thema also ausführlich beackert ist, habe ich trotzdem ziemlich viel herumprobieren müssen, bis meine Karten liefen. Die Anbindung verhält sich bei unterschiedlichen Karten leider nicht immer gleich. Ich habe mir daher mit dem Logikanalysator die Kommunikation des AVR mit einer funktionierenden Karte mal genau angesehen.

Eine 2G Transcend SD-Karte wurde an einen AT Mega32, der mit 8Mhz Quarz betrieben wird, angeschlossen. Die SPI-Taktfrequenz wurde auf 125Khz eingestellt. Ein Logikanalysator wurde auf 2 Mikrosekunden asynchroner Takt eingestellt. Ein Bit ist dann 8 Mikrosekunden und damit 4 Takte des Analysators lang.
Die Leitungen CS wurde auf Probe A0 („GRPA00“), DI auf Probe A1 („GRPA01“), DO auf Probe A2 („GRPA02“) gelegt. CLK wurde auf Probe A03 („GRPA03“) gelegt.

1. Der AVR möchte die Karte initialisieren.

Die Karte wird während der Initialisierung mit einer SPI-Taktfrequenz von 400Khz angesprochen. Nach der Initialisierung wird üblicherweise auf einen deutlich höheren Takt umgeschaltet. Man muss die 400Khz nicht sklavisch einhalten, ich habe 62,5Khz und 125Khz probiert, beides ging, ich vermute dass man die 400Khz nicht deutlich überschreiten darf. Nach Initialisierung kann man den SPI-Takt z.B. auf 2Mhz hoch schalten.

Der AVR wählt die Karte aus (CS auf 0) und sendet das Kommando „Go Idle State“/“CMD0“ an die Karte.

Auf dem folgenden Bild wurde der Trigger des Analysators auf „CS geht auf 0“ gesetzt. Der Triggermoment t=0 wird durch die gestrichelte rote Linie („CURSOR1“) dargestellt. Man sieht, dass unmittelbar nach dem Trigger Taktsignal vom AVR gesendet werden. Während aller 8 Taktzyklen hält der AVR seinen Ausgang MOSI („GRPA01“) auf 1. Im Ergebnis sendet der AVR ein 0xff. Dies ist korrekt, da vor dem Senden oder Lesen von der SD-Karte ein paar Taktzyklen zur Synchronisation von Master und Slave durch den Master gesendet werden. Im Code von Roland Riegel findet man dies in sd_raw.c, Funktion sd_raw_send_command_r1() wieder:

response = sd_raw_send_command_r1(CMD_GO_IDLE_STATE, 0);

Im Code wird die Synchronisation dadurch erreicht, dass sd_raw_rec_byte() ein 0xff sendet und ein „Dummy Byte“ von der Karte liest. Die Karte hat im Moment nichts sinnvolles zu senden und sendet acht 0-Bits, also 0x00.
Die gültigen Bit-Werte werden übrigens übernommen, wenn die Takt-Flanke von 0 auf 1 geht („rising edge“).

Als nächste Bitfolge wird 0100.0000, also 0x40 an die Karte gesendet. Die durchgezogene Rote Linie („CURSOR2“) steht genau auf dem 8. Bit dieses Bytes.Dies entspricht dem zu sendenden CMD0 (=0x00), geodert mit 0x40. Danach sendet der AVR viermal 0x00. Nur eines dieser vier Bytes ist komplett auf dem Bild zu sehen.

Auf dem folgenden Bild bin ich auf der Zeitachse nach rechts gegangen, man kann nun die letzten zwei 0x00-Bytes ganz sehen. Die 4 Bytes sind übrigens ein 32 Bit Argument zum Kommando CMD0, wobei das Argument den Wert 0 hat.

Nach den vier Argument-Bytes wird ein CRC-Byte gesendet. Dieses hat für die gesendete Bytefolge 0x40,0x00,0x00,0x00,0x00 den Wert 0x95. Tatsächlich lässt sich dieser Wert auch als Bitfolge 1001.0101 aus dem Bild ablesen (dritte komplette 8Bit-Folge im Bild, am Takt leicht erkennbar).

Als Antwort sendet die Karte nun ein 0xff. Der Cursor steht genau auf dem ersten Bit dieses Bytes. Solange die Karte noch keine Antwort komplett hat, sendet sie 0xff als Fülsel. Danach kommt die „echte“ Antwort, eine 0x01. Im Code von Roland Riegel findet man hierzu:

if(!(response & (1 << R1_IDLE_STATE)))
break;

D.h. das Kommando CMD0 wurde von der Karte akzeptiert, wenn sie ein 0x01, wie in unserem Falle, zurücksendet. Nach Verarbeiten von CMD0 ist die Karte nicht mehr im „native“ Mode und benötigt am Ende der Kommandos nun keine CRC-Bytes mehr.

CMD0 mit SPI

2. Der AVR wartet darauf, dass Karte sich initialisiert hat.

Die Karte benötigt eine gewisse Zeit für ihre Initialisierung. Wenn sie fertig ist, antwortet sie auf das Kommando „Send Op Cond“ / CMD1 als Antwort 0x00.

Im folgenden Bild wurde CMD1 gesendet, sowie die folgenden vier Argument-Bytes mit 0x00. Das CRC-Byte entfällt nun. Auch hier kann man erkennen, dass die Karte zunächst ein 0xff-Byte schickt. Danach schickt sie bis die Initialisierung fertig ist, 0x01. Das Ende der Initialisierung, d.h. die abzuwartende Antwort auf CMD1 ist 0x00.

SPI CMD1 command

Im folgenden Bild habe ich das Eintreffen der Antwort 0x00, auf CMD1, abgewartet. Da es etwa 60ms dauerte, bis die Karte die korrekte Antwort schickt, habe ich den Trigger hier anders definiert, somit stimmt die angegebene Zeit (Cursor Delta) von 0,1ms hier nicht mehr. Der Cursor steht direkt auf dem letzten Takt des Bytes 0x00.

SPI CMD1 end of init

3. Die SD-Karte ist fertig initialisiert. Man kann nun Lese- und Schreibkommandos zur Karte schicken.

Hier das Ergebnis des Lesens einer SD-Karte mit FAT16, Sektor 0 (Boot-Sektor):

0 - 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 
10 - 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 
20 - 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 
30 - 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 
40 - 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 
50 - 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 
60 - 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 
70 - 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 
80 - 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 
90 - 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 
A0 - 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 
B0 - 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 
C0 - 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 
D0 - 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 
E0 - 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 
F0 - 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 
100 - 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 
110 - 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 
120 - 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 
130 - 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 
140 - 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 
150 - 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 
160 - 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 
170 - 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 
180 - 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 
190 - 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 
1A0 - 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 
1B0 - 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 04 ................ 
1C0 - 04 00 06 1c dc cc ff 00 00 00 01 d3 3b 00 00 00 ....���....�;... 
1D0 - 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 
1E0 - 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 
1F0 - 00 00 00 00 00 00 00 00 00 00 00 00 00 00 55 aa ..............U�

Ich kann mit meiner Hardware und Software nicht jede Karte erkennen. Hier eine Aufstellung, was zur Zeit funktioniert:

Typ Hersteller Name Größe Filesystem Lesbar mit simpler Hardware und Roland Riegels FAT16-Bibliothek Speed Faktor Kommentar
MMC Palm PalmPak Card 8M FAT12 Hardwaremäßig erkannt, wegen FAT12 nicht lesbar Karte ist als „Rest“ eines Palms übrig geblieben.
SDSC Palm Palm Backup Card 16M FAT16 Nein, CMD0 wird falsch beantwortet Karte ist als „Rest“ eines Palms übrig geblieben.
SDSC PNY Technologies/
Toshiba
SD-M01G 1G FAT16 Nein, CMD0 wird falsch beantwortet
SDSC Transcend 6451AG 2G 02DS 2G FAT16 Ja
SDHC SanDisk TS4GSDHC6 4G FAT32 Nein, CMD0 wird falsch beantwortet Class 2
SDHC extrememory SDHC4GB 4G FAT32 Nein, CMD0 wird falsch beantwortet Class 2
SDHC Transcend TS4GSDHC6 4G FAT32 Ja Ultraspeed Class 6, MLC
SDHC Transcend TS16GSDHC6-S5W
(TS-RDS5W)
16G FAT32 Ja Ultraspeed Class 6

 

Die fehlerhafte Bearbeitung von CMD0 durch die Karte ist am Beispiel der extrememory-Karte hier zu sehen. Ich habe den Verdacht, dass die Karte zwar die erwartete Antwort schickt, aber vorher 1 Bit verschluckt wird, so dass das Alignment der Bits im Byte falsch ist und so die erwartete Antwort auf CMD0 (0x01) nicht gelesen wird, statt dessen wird 0x03 gelesen. Warum das so sein könnte ist mir aber völlig unklar. An alle Leser: Falls mir da jemand helfen kann, wäre ich glücklich(er)!

FAT32 Bibliothek

Da ich mehr als 2GB Daten verwalten muss (in einem MP3-Player), bin ich später auf SDHC-Karten übergegangen. Die Bibliothek von Roland Riegel unterstützt leider nur FAT16. Ich bin nach Analyse der verfügbaren Bibliotheken auf die FatFs von Elm Chan gegangen. Unterhalb des Filesystem-Layers verwende ich eine Mischung aus der sd_mmc-Schicht von Roland Riegel und der mmc-Schicht von Elm Chan, da Roland Riegels Bibliothek in der von mir genutzten Version keine HDSC unterstützte. Nachteil: Die Bibliothek von Elm Chan unterstützt leider keine langen Dateinamen.

Geschwindigkeit von SD-Karten

Der über die Speed Rate/Class gegebene Wert ist ein Minimalwert, d.h. die Karte kann in vielen Situationen schneller sein. Erst seit der Existenz des Standards SDHC gibt es diese Geschwindigkeitsklassen.

Der AVR schreibt nicht sonderlich schnell auf die Karte, so dass normalerweise  die Geschwindigkeit der Karte „nicht so wichtig“ ist. Trotzdem hier auch ein paar wahllose Messungen, die ich durchgeführt habe.
Unter Linux kann man -wenn der momentane Inhalt der Karte egal ist- mittels

Schreiben:
dd count=1k bs=1M if=/dev/zero of=/media/my-sd-card/test.img

Lesen:
dd count=500 bs=1M  if=/media/my-sd-card/test.img of=/dev/zero

die reale Schreibgeschwindigkeit prüfen. („my-sd-card“ steht dabei für den tatsächlichen Namen der gemounteten Partition der SD Karte. Auf der Karte muss dabei 1GB (1k*1M) frei sein. Vor dem Lesetest muss der Schreibtest ausgeführt werden und die Karte kurz vom Rechner unmounted/entfernt werden).

Karte Speed Rate ClassAufdruck Lesen [MB/s] Schreiben [MB/s]
SDHC extrememory  Allround, 4GB 2 20,1 11,2
SDHC
SanDisk, 4GB
2 10,8 6,1
SD
PNY, 1GB
(ohne) 8,5 2,7
SD
Noname? „SD Platinum „, 1GB
(ohne) 14,9 5,1

Links

Pollin LCD Roundup

Bei Pollin, einem günstigen Anbieter von Restposten elektronischer Bauteile, gibt es auch diverse LCD-Displays. Da ich auf der Suche war nach einem neuen „Standard“-Display für meine Prototypen habe ich einfach mal alle Displaytypen, die Pollin im Januar 2012 anbietet bestellt (Ausnahmen: die ganz teuren und die, welche offensichtlich keinen Controller haben). Ich habe für jedes Display versucht, dieses an einen AVR ATmega Controller anzuschließen. Meine Erfahrungen dazu sind weiter unten dokumentiert.

LCD-Displays

Es gibt unterschiedlichste LCD-Displays. Text-Displays zeigen nur alphanumerische Zeichen an, Grafik-Displays zeigen nur Punkte an. Durch Kombination dieser Punkte kann man tolle Graphiken darstellen. Ein Buchstabe ist auch nichts anderes als eine Menge von Punkten, somit kann man mit einem Grafik-Display natürlich auch Text darstellen.

Hintergrundbeleuchtung

Um Displays auch im Dunkeln lesen zu können, braucht man entweder so etwas wie eine Taschenlampe oder besser, ein LCD-Display mit integrierter Hintergrundbeleuchtung. Diese Beleuchtung kann auf verschiedenen Grundprinzipien beruhen.

LED-Hintergrundbeleuchtungen brauchen eine geringe Spannung von ein paar Volt, die man typischerweise sowieso zur Verfügung hat.

EL-Hintergrundbeleuchtungen erfordern eine hohe Wechselspannung von ein paar dutzend bis ein paar Hundert Volt, die man typischerweise nicht „ohnehin“ in seiner Schaltung zur Verfügung hat. Man muss dann die gewünschte Spannung zusätzlich erzeugen. Für einfache und/oder billige Sachen ist eine LED-Hintergrundbeleuchtung daher besser geeignet.

Textdisplays

Bei Textdisplays spielt die Anzahl der darstellbaren Zeilen und der pro Zeile darstellbaren Zeichen eine Rolle. Diese Displays sind auch festgelegt in Bezug auf die darstellbaren Zeichen (sie haben einen festen Zeichensatz). Oft kann man eigene Zeichen „hochladen“.

Zeichensätze von LCD-Displays

Mangels echter Standardisierung kann jeder Hersteller beliebige Zeichensätze  in seinem Display implementieren.  Für den sehr gängigen Controller HD44780 hat der Produzent Hitachi einen Zeichensatz festgelegt, den man so oder ähnlich in all den Nachbauten auch findet. Daher die Tabelle (von Wikipedia) hier eingefügt:

(Bild anklicken für größere Version)

Grafikdisplays

Bei Grafik-Displays ist die Anzahl der Pixel in X- und Y-Richtung von Bedeutung. Grafik-Displays können auch farbig sein, so dass ein Pixel nicht durch ein Bit sondern durch eine ganze Anzahl von Bits repräsentiert wird. In z.B. 8 Bit kann man so 256 RGB-Werte unterbringen, z.B. nach dem Schema RRRGGBBB, d.h. 3 Bits für Rot und Blau und 2 Bits für Grün.

Ansteuerung

Alle betrachteten Displays  haben einen Display-Controller, der einfache Befehle versteht und die Übersetzung in Pixel an- und ausknipsen-Tätigkeiten vornimmt. Bei Textdisplays kann man beispielsweise den Cursor an eine bestimmte Position setzen („Zeile 2, Zeichenposition 14“) oder ein bestimmtes Zeichen ausgeben.

Die Pin-Belegung aller LCDs folgt meist einem einheitlichen Vorgehen, wie man weiter unten erkennen kann.

Es gibt auch Displays ohne Controller, bei denen man sich um die Ansteuerung selbst kümmern kann. Auch dies ist möglich, aber unbequemer. Ich habe bei meiner Betrachtung nur Displays mit Controller berücksichtigt.

Controller

Bei den Displays hat eine Quasi-Standardisierung auf einige wenige Controller-Typen stattgefunden, so dass man mit einigen wenigen Controllern sehr viele LCDs herstellen kann. Anbei beispielhaft einige Controller, die in den betrachteten Displays eine Rolle spielen

Controller Kompatible Typen
Epson SED1520
Epson SED1530
Hitachi  HD44780 Epson SED1278,
Samsung KS0066, Sitronix ST7066, …
NEC D7228
Sanyo LC7980
Sharp LH155
Samsung KS0108 Samsung S6B0108
Samsung S6B33B2
Sitronix ST7920

Lesenswerte weiterführende Information zum HD47780 bei Wikipedia.

Hinweise zum Test

Da eine größere Menge von Displays in endlicher Zeit durchgetestet werden sollte, wurde folgendes Vorgehen festgelegt:

  • Informationsbeschaffung zu allen Displays aus Internet
  • Keine Eigenimplementierung der Testprogramme und der Ansteuerbibliotheken für die Tests. Verwendung von Sourcecode aus Foren, Websites etc. Ich will mich nicht mit fremden Federn schmücken, die Quellen sind immer zu Beginn der Beschreibung des Displays angegeben.
  • Anpassung der verfügbaren Software soweit erforderlich
  • An die Kandidaten wurden soweit möglich Stiftleisten angelötet, mit denen die Displays dann leicht mit Steckboards verbunden werden können.
  • Die Displays Alps LSU… und das NAN YA LMME… wurden nicht getestet, weil sie mir als nicht sinnvoll verwendbar erschienen. Das Alps-Display hat 41 Kontakte und ist damit in einem Eigenbauentwurf extrem unhandlich wegen der Pin-Anzahl, das NAN YA-Display ist vom Format her sehr groß und für eigene Projekte in vielen Fällen einfach zu groß

Testkandidaten

Die folgenden aufgelisteten Typen wurden untersucht.

Abkürzungen in der Tabelle:
NOK: Not OK, Display konnte nicht in Betrieb genommen werden
TBD: To Be Done, muss noch getestet werden
N.A.: Not Available, Display unbrauchbar

Hersteller Typ Display Werte Bel. Chip Preis 1/2012 Status
Alps LSU7S1011A und Bausatz sowie Beschreibung Controller SED1530 96×32 NEIN SED1530 2,95 zuviele Kontakte (41)
unbekannt C0802-04 2×8, 44x32mm NEIN HD47780 +5V 0,95 OK
Data Vision DG14032 (Pin-Belegung identisch mit DV-20208) 140×32, gelbgrün LED ST7920
+5V / 5,7V
2,95 OK
unbekannt DG016Z 2 bzw. 4  Zeilen zu 24/32 Zeichen 93x17mm NEIN LC7980 2,95 OK
Data Vision DG-12232 mit Adapterboard und Controller SED1520 122×32, 60,5×18,5mm EL SED1520DAA +5V 2,50 NOK
Data Vision DV-20208 2×20, 73×19,8mm, grün LED HD47780 +5V 3,95 OK
NAN YA Plastics Corp. LMMEJS068CDF

Pin-Belegung: Hier

2×20+1×35, 123×35,5mm, gelbgrün LED KS0066F03 (=HD47780) +5V 2,95 Zu groß für Verwendung
Optrex DMC-2047 2×8, 1 Zeile Sonderzeichen, 1x Balkengraph, div. LEDs LED NEC D7228AG 1,95 OK
Orient Display DM19264A-02 und altes Datasheet 192×64, 104x39mm
gelbgrün
LED KS0108 und KS0107
+5V
6,95 OK
Philips LPH 2673-1 50x11mm (ohne) 0,10 N.A.
Samsung UG12D228AA 128×128, 27x27mm, 4096 Farben LED S6B33B2 2,95 TBD
Sharp M078CKA-A3QKLA0057 und Controller LH155 240×64 Pixel, 72x32mm NEIN LH155
+5/+15V
2,95 TBD
Powertip PC1602-E 2×16, 61×15,9mm NEIN HD47780 +5V 2,95 OK
Tinsharp TC1602A-08 2×16, blau LED HD47780
+5V
4,95 OK
Tinsharp TC1604A-01 4×16, 56,2×20,8mm, gelbgrün LED HD47780
+5V
8,95 OK
Wintek WD-G1203T 12×3 bzw. 122×32, 53,5×15,5mm, grün LED D1250D bzw. 2xSED1520 2,50 OK

Pollin Katalogseiten 02/2012 hierzu:

 

Mechanische Aspekte LCD-Anschluss

LCD-Displays sind mit diversen Anschlusstechniken erhältlich.

  • Lötpads mit 2,54mm Abstand: Hier kann man meist eine Stiftleiste einlöten und diese dann z.B. mit einer passenden Buchse auf einem Controller-Board verbinden.
  • Lötpads mit 2mm Abstand: Im betrachteten Testfeld war dies nur 1 Kandidat (Das Wintek LCD)
  • Vorinstallierter Folienleiter: Diese Displays sind meist mit dem Ziel möglichst kleiner Abmessungen gebaut. Der Folienleiter hat am Ende versilberte Leiterbahnen zur Aufnahme in eine spezielle Buchse. Der Folienleiter heißt auf Englisch „Flat Flex(ible) Cable“, abgekürzt FFC. Es wird auch die Bezeichnung „Flexprint“ gebraucht. Diese Kabel gibt es in verschiedenen Rastermaßen („Pitch“), bei den verwendeten Displays ist es immer 1mm.
  • (Im Umfeld FFP kommt auch die Abkürzung FPC vor, die Flexible Printed Circuits“ bedeutet. Dies scheinen mir eine Art „Custom“ Version von FFCs zu sein, also FFCs für genau einen Anwendungszweck). Man braucht also zusammenfassend eine FFC-Buchse mit der passenden Pin-Zahl und dem passenden Pitch.
  • „Sonstige“: Hier fällt mir nur das Optrex ein, welches einfach vergoldete Pins bietet.

Alps LSU7S1011A

Dies ist ein Grafik-Display, 96×32 ohne Hintergrundbeleuchtung.

Zu diesem Display liefert Pollin einen kleinen Adapter-Bausatz mit Platine (extra bestellen, 1,95 Euro), an den das Display angelötet werden kann. Das Alps Display benötigt einige externe Bauteile (z.B. Elkos), die auf der Bausatzplatine mit drauf sind, es macht also Sinn diesen Adapter mitzubestellen.

Controller ist der SED1530.

Controller: Handbuch

Adapter-Bausatz Beschreibung

Anschluss und Pin-Belegung

Der Anschluss erfolgt über einen Folienleiter 1mm Pitch, einseitig 41 Pins.

 

Fazit

Das Alps Display hat m.E. zu viele Kontakte (41 !!!). Es gibt zwar eine Adapter-Platine von Pollin, welche die Anzahl der Kontakte reduziert. Allerdings ist es notwendig, den Folienleiter des Displays an die Adapterplatine anzulöten. Ein Folienleiter verträgt aber die Temperaturen des Lötkolbens nicht oder nur sehr schlecht. Das Anlöten ist daher als kritisch zu betrachten.

Diese ungünstige Situation bringt mich zu dem Schluss, das Display vorerst nicht weiter zu betrachten.

C0802-04

Kleines Text-Display, 2×8 Zeichen, Hersteller war nicht zu ermitteln. Kam mit Pixelfehlern bei mir an, die vermutlich durch Druckstellen beim Transport entstanden waren. Nach einigen Tagen verschwanden die Pixelfehler weitgehend.

Verwendet wird der Controller HD47780. Daher kann dieses Display in der absoluten „Standard-Beschaltung“ und mit der „Standard“-Bibliothek von Peter Fleury verwendet werden.

Handbuch Controller HD47780 oder KS0066.

Besprechung hier : http://www.mikrocontroller.net/topic/176029

Pin-Belegung und Anschluss

Das Display ist mit einem Folienleiter 1mm Pitch, einseitig 10 Pins. versehen.

Um das Display zu testen, wurde ein einfacher Adapter gebaut, der eine FFP-Buchse besitzt, in die der Folienleiter eingeführt werden kann. Die Pins der FFP-Buchse sind auf eine „normale“ 2,54mm Stiftleiste herausgeführt.

Pin Funktion AVR Pin
1 GND
2 VDD +5V
3 Vo Kontrastspannung
4 RS PC0
5 RW PC1
6 E PC2
7 D4 PA0
8 D5 PA1
9 D6 PA2
10 D7 PA3

 

 

 


Die Adapterplatine FFC-Buchse <-> Stiftleiste 2,54mm

 

 


Die FFC-Buchse aus der Nähe. Sie stammt aus einem alten DVD-Player, der zerlegt wurde. FFC-Buchsen sind Bauteile, die für den Endanwender eher schwer erhältlich sind.

 


Das Display im Testbetrieb

 


Der Versuchsaufbau

 

Software

Das Display beherrscht nur den 4-Bit-Modus.

Im Gegensatz zu den im oben erwähnten Foreneintrag Problemen machte die Initialisierung des Displays keinerlei Probleme, es konnte die Implementierung von Peter Fleury ohne jede Änderungen in lcd_init() hergenommen werden.

Link zu Peter Fleurys Bibliothek (LCD library for HD44780 based LCD’s: http://homepage.hispeed.ch/peterfleury/avr-software.html

Fazit

Kleines Display, sehr dünn, einfach anzusteuern. Kein Backlight. Sehr empfindlich beim Abziehen der Schutzfolie (verfärbt sich stark, Verfärbung geht aber wieder weg).
Leider nur 2×8 Zeichen, aber das kann in der einen oder anderen Situation ausreichend sein.
Sehr günstig.

Data Vision DG-12232

Dies ist ein kleineres Grafikdisplay mit 122×32 Punkten, EL-hintergrundbeleuchtet. Zum Display verschickt Pollin ein Adapterboard.

Controller ist SED1520DAA. Ein einzelner SED1520 kann 61×16 Pixelreihen/Zeilen verwalten. („DAA“ bezeichnet *A* die anzulegende externe Frequenz von 2Khz und D*A die Die-Form „Aluminium Pad“).
Dies bedeutet, dass im Display vier Controller verbaut sein müssen !?

Handbuch Controller SED1520

http://www.mikrocontroller.net/topic/171433

http://www.mikrocontroller.net/topic/125454

http://www.mikrocontroller.net/topic/105223

http://en.radzio.dxp.pl/sed1520/



Aus Datenblatt gelesen; das Display darf mit VDD bis zu 8V betrieben werden. Die LCD-Spannung VEE ist negativ und es gilt VDD-VEE<=16,5V. Wenn also z.B. VDD=5V ist, kann  VEE bis zu -11,5V annehmen. Laut Pollin-Datenblatt sind -5V ausreichend.

Backlight

Die Beleuchtung des Displays erfolgt mit einer hohen Wechselspannung von XXX Volt. Die beiden Pins der Beleuchtung sind auf der Adapterplatine als Pins „JP2/JP3“ herausgeführt. Da man eine solch hohe Spannung normalerweise nicht zur Verfügung hat, muss eine solche Spannung erst erzeugt werden. Die Kosten für einen solchen Spannungserzeuger sind zwar nur ein paar Euro, aber so gesehen erhöhen sie den Kaufpreis des Displays deutlich.

Anschluss und Pinbelegung

Das Data Vision DG-12232 wird von Pollin mit einem dazugehörigen Adapter-Board geliefert. Zum Adapter-Board gehören ein paar SMD-Bauteile, die noch anzulöten sind.
Sinn des Adapters: Das Display benötigt zur Funktion an seinem Eingang „CL“ ein Clocksignal von 2Khz. Auf dem Adapterboard ist eine kleine Schaltung mit dem NE555, um diese Frequenz zu erzeugen. Man kann diese Frequenz auch alternativ mit dem AVR erzeugen, aber wenn die Adapterplatine schon dabei ist, empfiehlt sich deren Einsatz. Die Verbindung zwischen Display und Adapter-Platine erfolgt über einen beiliegenden Moosgummi.
Leider folgt die Belegung des Pollin-Adapter-Boards nicht der bei LCDs schon fast üblichen Belegung der Pins.

Adapter Pin Funktion AVR Pin
1 „A0“ (eigentlich: RS) PC0
2 CS2 PC4
3 CS1 PC3
4 Clock
5 80xx: /READ
68xx: E
PC2
6 80xx: /WRITE
68xx: RW
PC1
7 GND GND
8 D0 PA0
9 D1 PA1
10 D2 PA2
11 D3 PA3
12 D4 PA4
13 D5 PA5
14 D6 PA6
15 D7 PA7
16 VDD +5V +5V
17 Res; L=80xx, H=68xx +5V via 10KOhm
18 VEE LCD Kontrastspannung -5..0V

 


Das Display und die Adapterplatine von Pollin, Displayseite.

 


Das Display und die Adapterplatine von Pollin, Bestückungsseite.

 

Status

Das Display konnte unter Verwendung des Pollin-Adapters nicht zum Laufen gebracht werden.
Beobachtung während des erfolglosen Tests:

  • 2Khz-Frequenz wird erzeugt (es sind ca. 1,8xx Khz)
  • Nach Anschluss an AVR und Ansteuerung mit passendem Programm aus Internet werden nur ein paar Linien unten angezeigt
  • Seltsamerweise hat die Einstellung der Kontrastspannung massiven Einfluss auf das was im Display dargestellt wird. Je nach Stellung sind es:
    • Ein paar zusammenhängende ruhigstehende Zeilen am unteren Rand
    • Flimmernde Zeilen unten, abwechselnd unterschiedlich viele
    • Bei bestimmten Einstellungen wird das ganze Display angesteuert, alle Zeilen flimmern
    • Manchmal wird gar nichts angesteuert

Vorgehensoptionen: Entfernen des Pollin-Adapters, anlöten eines Kabels und erneuter Test.

Fazit (vorläufig)

Die EL-Hintergrundbeleuchtung ist ein Nachteil des Displays. Diese erfordert erhöhten Aufwand und erhöhten Stromverbrauch. Das Display ist schon von daher weniger attraktiv und für transportable Geräte weniger geeignet.
Relativ geringe Auflösung.

Data Vision DG-14032

Das Display ist ein Grafik-Display 140×32 Pixel. Es beherrscht einen Text- und einen Grafikmodus, zwischen denen man beliebig hin- und herschalten kann.

Display besprochen in  http://www.mikrocontroller.net/topic/197156

Im Display ist ein Controller Sitronix ST7920 verbaut. Besonderheit dieses Controllers ist, dass er den chinesischen Zeichensatz mit 8192 Zeichen eingebaut hat 🙂

Handbuch Controller ST7920.

Für das Display ist GLCD-Source-Code verfügbar.

Die Pinbelegung dieses Displays ist identisch mit dem Data Vision DV-20208.

Pin Funktion AVR Pin
1 GND GND
2 +5V +5V
3 Kontrastspannung ~+0,7V
4 RS PC0
5 RW PC1
6 E PC2
7 D0 PA0
8 D1 PA1
9 D2 PA2
10 D3 PA3
11 D4 PA4
12 D5 PA5
13 D6 PA6
14 D7 PA7
15 GND
16 N.C.
17 N.C.
18 Metal Frame
19 Led Backlight +5,7V, 30mA +5,7V
20 Led Backlight GND GND

 

 

Am 20-poligen Anschluss lässt sich eine 2,54mm-Stiftleiste leicht anlöten.

Das Display bringt bei mir auch ohne Anlegen einer Kontrastspannung einen guten Kontrast.

Das Backlight leuchtet erst ab ~5,7V (es geht also nicht mit den ohnehin anliegenden 5V).

Software

Beim oben erwähnten Link von Mikrocontroller.net gibt es Software für dieses Display. Diese Software baut auf dem Code von http://en.radzio.dxp.pl/ auf.

Die Software wurde an meine Hardware-Situation (Pinbelegung) angepasst und funktionierte sofort im 4-Bit und im 8-Bit-Modus. Beim 8-Bit-Modus fand ich noch einen Fehler auf meinem AVR-Testboard, ein Kurzschluss zwischen D2 und D3.


Testausgabe im 4-Bit-Modus; Text, zwei Rechtecke, ein Kreis.

 


Erster Test mit dem 8 Bit Modus bringt dieses seltsame Ergebnis. Grund war, dass die Datenbits 2 und 3 durch einen Kurzschluss miteinander verbunden waren. Nach Korrektur verhielt sich das Display auch im 8-Bit-Modus wie gewünscht.

 


Blick auf die Testumgebung.

Fazit

Kleines Display, leider große Platine. Für tragbare Geräte wegen der Größe der Platine nicht optimal. Helles Backlight, guter Kontrast, bei geringem Stromverbrauch.
Kabel oder Stiftleiste sehr gut anlötbar.
Günstiger Preis.

Datavision DV-20208

Dies ist ein kleines Textdisplay mit 2 Zeilenx20 Zeichen. Die Platine ist groß im Verhältnis zum eigentlichen Display.

Verwendet wird der Controller HD47780. Daher kann dieses Display in der absoluten „Standard-Beschaltung“ und der „Standard“-Bibliothek von Peter Fleury verwendet werden.

Handbuch Controller HD47780.

Link zu Peter Fleurys Bibliothek (LCD library for HD44780 based LCD’s: http://homepage.hispeed.ch/peterfleury/avr-software.html

Pinbelegung und Anschluss

Die Pinbelegung dieses Displays ist identisch mit dem Data Vision DG-14032.

Pin Funktion AVR Pin
1 GND GND
2 +5V +5V
3 Kontrastspannung ~+0,7V
4 RS PC0
5 RW PC1
6 E PC2
7 D0 PA0
8 D1 PA1
9 D2 PA2
10 D3 PA3
11 D4 PA4
12 D5 PA5
13 D6 PA6
14 D7 PA7
15 GND
16 N.C.
17 N.C.
18 Metal frame
19 Led Backlight +5,7V, 30mA +5,7V
20 Led Backlight GND GND

Kontrastspannung: Pin 3 geht an Schleifer eines Trimmwiderstands 22K. Die beiden anderen Kontakte des Trimmwiderstands an GND und +5V.

Hinweis zur Pin-Belegung: Wie immer bei der 4-Bit-Ansteuerung sind die Datenleitungen D4..D7 zu verwenden, in Tabelle fett markiert. D4..D7 entsprechen den „logischen“ D0..D3 der 4-Bit-Ansteuerung.

 

 


Gesamtaufbau

 

 

Fazit

Das Display ist durch die Nutzung des Controllers HD44780 softwaretechnisch perfekt unterstützt. Es benötigt minimal 7 Pins vom AVR, ist also sparsam im „Pin-Verbrauch“. Das Backlight ist ausreichend hell und verbraucht sehr wenig Strom. Die Buchstaben sind ziemlich groß geraten, ca 6,5mm hoch, also auch von etwas weiter weg noch lesbar.

Background Beleuchtung benötigt ziemlich genau 5,7 Volt. Bei 5V ist die Beleuchtung nicht zu sehen.

Die Platine ist leider ziemlich groß in Relation zum Display. Dafür existieren dann aber Bohrungen zur Befestigung. Mit einer Dremel lässt sich die Platine oben direkt am Metallrahmen abflexen und wird dadurch etwas schlanker, nur die Backlight-Leiterbahnen werden dabei abgetrennt, was aber kein Problem darstellt, da die Anschlüße direkt am Display rechts nutzbar sind.

Preislich leider relativ teuer, ein Euro weniger wäre m.E. angemessener.

DG016Z

Dieses kleinere Display mit unbekanntem Hersteller ist ein Graphik-Display, 192×32 Pixel, wobei zwischen den oberen und den unteren 16 Pixeln eine einzelne Pixel-Leerzeile existiert. Es ist so gesehen eher ein Display das Graphikausgaben in zwei Zeilen a 192×16 erlaubt. Es ist vorgesehen zur Ausgabe chinesischer? japanischer? Zeichen, hat aber auch „übliche“ Zeichen eingebaut. Die Zeichensätze sind im EPROM untergebracht. Der Nutzen des RAMs ist mir unbekannt. Es gibt mehrere mögliche Zeichensätze:

  • 5×8 bei 32 Zeichen/Zeile, 4 Zeilen
  • 8×16 bei 24 Zeichen/Zeile, 2 Zeilen

Besprochen in : http://www.mikrocontroller.net/topic/235409

Das Display  besteht aus dem eigentlichen Displayboard und einem zweiten Board, auf dem das Display im Huckepack sitzt.
Auf dem zweiten Display findet sich der Controller, ein EPROM Atmel AT27C256 (256KBit) und ein S-RAM-Baustein Sanyo LC3664NML-10 (64KBit).

Controller ist ein Sanyo LC7980. Dessen Character-Speicher ist erweiterbar um ein externes ROM, dies ist das oben erwähnte EPROM.

Handbuch LC7980

Pinbelegung und Anschluss

Doppel-Stiftleiste 2×8 mit 2,54mm Stiftabstand kann eingelötet werden.

Pin Funktion AVR Pin
1 GND GND
2 +5V +5V
3 Kontrastspannung ~-4,1V
4 RS PC0
5 RW PC1
6 E PC2
7 D0 PA0
8 D1 PA1
9 D2 PA2
10 D3 PA3
11 D4 PA4
12 D5 PA5
13 D6 PA6
14 D7 PA7
15 AT27xxx Pin 30 = A13 siehe Text
16 AT27xxx Pin 31 = A14 siehe Text

Kontrastspannung: Pin 3 geht an Schleifer eines Trimmwiderstands 22K. Die anderen beiden Pole gehen an GND und eine negative Spannung von -5V, sie muss extern zugeführt werden.

Hinweis zur Pin-Belegung:

An Pin 15+16 sind die Adresspins A13 und A14 des EPROMS herausgeführt. Somit kann man durch Anlegen von HI/LOW and diesen beiden Anschlüßen 4 Bereiche im EPROM adressieren. Diese Bereiche zeigen auf unterschiedliche Zeichensätze. Folgende Belegungen sind möglich:

A14 A13 Effekt
0 0 Normaler ASCII-Charset+Sonderzeichen; evtl. der im Controller eingebaute?
0 1 ??? jap. Zeichen + ASCII ???
1 0 ??? jap. Zeichen + ASCII ???
1 1 ??? jap. Zeichen + ASCII ???

Alle Zeichensätze im EPROM sind 8×16 Zeichensätze (XXXX stimmt das?)

Möglicherweise kann das Display im 4-Bit-Modus angesteuert werden. Dies wurde nicht ausprobiert, sondern der 8-Bit-Modus verwendet.


 


RAM, Controller LC7980, EPROM. Unten der 2×8 Anschluß,

 


Display wurde bei schrägen Lichteinfall aufgenommen, daher wirkt es etwas verschwommen, ist es aber nicht.

 

Software

Für dieses eher ungewöhnliche Display gibt es keine mir bekannte GLCD-Implementierung. Im oben erwähnten Thread aus mikrocontroller.net finden sich jedoch zwei Implementierungen.

Die optisch ausgereifter aussehende Implementierung wurde als Ausgangsbasis hergenommen. Irritierend war, dass keinerlei Delays in der Display-Ansteuerung vorgesehen waren.

Für erste Tests wird A13=A14 auf LOW gelegt.

Der erwähnte Code funktionierte auf Anhieb. Er implementiert leider nur die Variante „Textmodus, 6×8 Font, 4×32 Zeichen“.

Fazit (vorläufig)

Das Display ist klein für seine 4×32 Zeichen, die es darstellen kann. Es hat leider kein Backlight und ist ziemlich dick, wegen der Huckepack-Platine. Der „normale“ Font sieht gut aus und der Kontrast ist ok, könnte aber stärker sein.

NAN YA LMEEJS068CDF

Dieses Display ist offensichtlich ein Teil eines Gerätes und eigentlich nicht dafür gedacht, in anderen Geräten eingebaut zu werden. Die Platine ist sehr groß.

Das Display ist ein Textdisplay mit 2 Zeilen zu 20 und einer weiteren Zeile mit 35 etwas kleineren Zeichen. Es besitzt LED Hintergrundbeleuchtung.

Verwendet wird der Controller HD47780. Daher kann dieses Display in der absoluten „Standard-Beschaltung“ und der „Standard“-Bibliothek von Peter Fleury verwendet werden.

Handbuch Controller HD47780.

Link zu Peter Fleurys Bibliothek (LCD library for HD44780 based LCD’s: http://homepage.hispeed.ch/peterfleury/avr-software.html

Besprechung hier: http://www.mikrocontroller.net/topic/216474 .

Pinbelegung und Anschluss

Das Display hat einen 40-poligen Wannenstecker (IDE-Buchse). Es hat so viele Anschlüsse, weil die Tasten herausgeführt sind, außerdem sind viele Kontakte mit GND belegt.

Pin Funktion AVR Pin
1 GND
2 GND
3 DB7
4 DB6
5 DB5
6 DB4
7 DB3
8 DB2
9 DB1
10 DB0
11 GND
12 E1 (obere 2 Zeilen)
13 RW
14 E2 (untere Zeile, Pfeile)
15 N.C.
16 N.C.
17 +5V
18 +5V
19 N.C.
20 N.C.
21 RS
24 LED Backlight +
26 LED Backlight –
27 GND
28 GND
29 GND
30-38 (Tastatur)
39 GND
40 GND

 

 

Laut einem Foreneintrag kann das Display direkt unterhalb der Buchse abgesägt werden und so etwas verkleinert werden. Ich habe dies nicht probiert, da das Display selbst dann für meine Zwecke immer noch zu groß wäre.

Von http://www.grassow.de/nan_tec.html: … Pin 26 + Betriebsspannung für Hintergrundbeleuchtung Display (über zwei parallel geschaltete 10 Ohm-Widerstände) …

Software

4 Bit Modus ist möglich.

Die Pfeile werden mit den Daten-RAM-Adressen 0xA3,0xA4,0xA5 und 0xA6
angesprochen. 


XXX

Fazit (vorläufig)

Das Display hat einen sehr ungünstigen Formfaktor, es ist für viele Zwecke einfach zu groß. Daher habe ich den Test mit diesem Display auf einen späteren Zeitpunkt verschoben.

Optrex DMC-2047

Dieses Display hat zwei Textzeilen mit je 8 Zeichen. Außerdem einen Balken mit 40 Punkten sowie eine Zeile mit einigen Sonderzeichen. Es besitzt eine LED Hintergrundbeleuchtung sowie 4 verschiedenfarbige LEDs (und eine IR-Empfangs-Diode).
Es stammt vermutlich aus einem Telefon.

Die Firma Optrex ist im Internet vertreten (http://www.optrex.com/), hier ein Link auf diverse LCD-Anzeigen. Diverse Optrex: LINK

Der verwendete Controller ist der NEC µPD7228A.

Datasheet NEC µPD7228A (nur 10 Seiten)

Nachfolger µPD16434, kompatibel zum 7228: Manual

Diskussion des Displays hier: http://www.mikrocontroller.net/topic/174018

Anschluß und Pinbelegung

Der Display-Anschluß hat 22 Pins im Abstand von 1,5mm.

Das Backlight besteht aus 4 in Serie geschalteten LEDs. Erst bei 10V kommt eine nennenswerte Helligkeit zustande, wirklich hell ist es erst bei 12V. Möglicherweise ist das aber zuviel für die 4 LEDs.

Pin Funktion
Seriell
AVR Pin
1 Backlight – siehe Text
2 Backlight + siehe Text
3 LED yellow1
4 LED yellow1
5 LED green
6 LED green
7 LED IR
8 LED IR
9 LED red
10 LED red
11 LED yellow
12 LED yellow
13 CLOCK Systemtakt  PD7 (siehe Text)
14 RESET PA4
15 CS PA3
16 CD Command / Data Select PA2
17 SCK – Serial Clock Input PA1
18 VSS, GND GND
19 VDD +5V +5V
20 BUSY
21 SI – Serial Input PA0
22 VLC5 GND

 

Software

Der Controller erlaubt sowohl 4-Bit-Parallel als auch serielle Ansteuerung. Leider sind D1,D2 und D3 an der Kontaktleiste nicht verfügbar, so dass mit dem Optrex-Display nur serielle Ansteuerung möglich ist.

Der C Code, der über das oben erwähnte Forum heruntergeladen werden kann (Stand: 02/2012) ist nicht lauffähig. Dort gibt es auch Assembler-Code für PIC-Controller und Basic-Code.

Nach diversem Herumprobieren konnte ich eine Art „Kompilat“ aller erwähnten Codes (Assembler, BASIC, C) erzeugen, die als C Source lauffähig war und das Display korrekt ansteuert. Die verwendete Taktfrequenz zusammen mit der Framesize (SFF-Kommando des upd7228) war kritisch. Bei mir hat ein Wert von 250Khz für den Takt für das Display und eine Framesize von 1 funktioniert. Mit anderen Werten gab es Darstellungsfehler. Das Timing müsste für dieses Display genauer angesehen werden.

Den Systemtakt für das Display habe ich mittels eines Timers des AVRs erzeugt, der selbsttätig einen Pin des AVRs ein und ausschaltet. Dieser Pin war OC2, beim verwendeten ATmega32 identisch mit PD7.


Oben: Bargraph
Mitte Sonderzeichen Zeile
Unten: 2 Zeilen a 8 ZeichenHintergrundbeleuchtung hier nicht angeschlossen. Durch den Betrachtungswinkel haben die Buchstaben eine Art „hellen Hintergrund“.

 

Gesamtaufbau

 

Fazit

Eigentlich witziges Display, Hintergrundbeleuchtung vorhanden. Die LEDs können auch für irgendwas verwendet werden, und der Bargraph ist auch nicht schlecht.

Die einzelnen Zeichen sind ziemlich weit voneinander entfernt.

Ungünstig die Anschlussvariante mit 1,5mm Pitch Platine (nur arbeitsaufwändig durch Handlötung anzuschließen).

Orient Display DM19264A

Shenzhen Orient Display ist im Internet vertreten: http://www.orientdisplay.com/

Das DM19264A-02 ist (Stand 01/2012) noch auf der Website beschrieben.

Verwendete Controller sind 3x KS0108B (Samsung S6B0108) als Segment Driver und 1x KS0107 (Samsung S6B0107) als Common Driver. Somit sind 64+64+64=192 Pixelspalten und 64 Pixelreihen adressierbar.

Im folgenden ist der Schaltplan des Displays -aus dem Datenblatt entnommen- dargestellt.

Manual S6B0107

Manual S6B0108

Bei http://www.mikrocontroller.net/topic/217600 ist das Display ausführlich besprochen, incl. Anschlussplan und Test-Sourcecode.

Polnische Site mit Erstimplementierung einer passenden C-Bibliothek für KS0108: http://en.radzio.dxp.pl/ks0108/ .

Wichtige Hinweise zur Platine

Laut Forenbeitrag sind die Verbindungen der Anschlusspins mit Pin 19 und Pin 20 nicht auf der Platine drauf. Prüfung zeigt dass das auch für mein Exemplar stimmt.

  • Durch vorsichtiges Abkratzen der Isolation am Ende der Leiterbahn und anschließendes Verzinnen kann leicht ein dünner Draht zwischen Pin 19 und der neu geschaffenen Lötstelle verlötet werden. Damit besteht die Verbindung von Pin 19 zu Vee wie im Datenblatt beschrieben.
  • Der masseseitige Anschluss des Backlights ist bei meinem Exemplar auch nicht mit der Masse (Pin 1) verbunden. Somit leuchtet nix, wenn man 4,2V an Pin1 und Pin 20 anlegt. Auch hier kann Abhilfe geschaffen werden: Die Leiterbahn, die dem „K“-Anschluss des Backlights am nächsten liegt, wird freigekratzt und, weil der Abstand so gering ist, mit einer superfetten Lötperle als Verbindung versehen. Danach leuchtet das Backlight, wenn man GND verbunden hat und +4,2V an Pin 20 anlegt.

Pinbelegung und Anschluss

Wenn man die Hinweise zur Platine oben beachtet hat, kann man das Display an seinen Controller anschließen.

Pin Symbol Funktion Etc. AVR
1 Vss Power Supply GND GND
2 Vdd Power Supply +5V +5V
3 Vo Contrast Adjust Coltage
4 RS Instruction/Data Register Select (H: Data; L=Inst.) PC0
5 RW Data Read/Write  (H=R;L=W) PC1
6 E Enable Signal PC2
7 DB0 Data Bus Line 0 PA0
8 DB1 PA1
9 DB2 PA2
10 DB3 PA3
11 DB4 PA4
12 DB5 PA5
13 DB6 PA6
14 DB7 Data Bus Line 7 PA7
15 /CS1 Chip Select 1 active L PC3
16 /RST Reset kann mittels 10 Ohm an Vdd gelegt werden PC6 oder +5V via 10K
17 /CS2 Chip Select 2 active L PC4
18 /CS3 Chip Select 3 active L PC5
19 Vee Negative Voltage Output (-5V or -10V) bei mir sinds -5V. Siehe Kommentar
20 A Power Supply LED Backlight +4,2V <= 300mA 4,2V

An Vdd wird via Poti 10K-22K Vss und Vee geführt, diese Spannung liegt also zwischen +5 und -5V (oder -10V).

 

 


Lötbrücke an Pin 20

 


Lötbrücke (Lötperle) an Kathode des Backlights

 


Gesamtaufbau beim Test

Die Ausgaben des Testprogramms (Text, Linie, Rechteck, Kreis, Graphik)

Fazit

Das Display hat eine relativ hohe Auflösung und einen guten Kontrast. Das Backlight hat, wenn es ausreichend hell sein soll, einen Stromverbrauch zwischen 200 und 300mA. Dies ist ein hoher Stromverbrauch und macht es für externe Geräte fast schon ungeeignet. Hier wird man das Backlight nur auf Knopfdruck zuschaltbar machen.

Ungünstig die notwendigen Nacharbeiten auf der Displayplatine.

Es wird auch über schwachen Kontrast des Displays bei bestimmten Bitmustern (0101010…) gesprochen. Dieser Effekt scheint aber nicht bei allen Displays vorzukommen.

Philips LPH 2673-1

Das LPH 2673-1 von Philips ist ein LCD Display ohne Controller. Man müsste also einen passenden Controller finden oder nachbauen. Das Display ist somit ein Sonderfall und wird hier nicht weiter betrachtet.


Philips LPH 2673-1, Displayseite.

Fazit

Sehr billig, für meine Zwecke aber unbrauchbar-> Mülleimer.

Powertip PC1602-E

Kleines Text-Display, 2×16 Zeichen. Powertip ist im Internet vertreten (http://www.powertip.com.tw/). Man findet das Display noch in der Produktliste des herstellers.

Display-Beschreibung: Datenblatt

Verwendet wird der Controller HD47780. Daher kann dieses Display in der absoluten „Standard-Beschaltung“ und mit der „Standard“-Bibliothek von Peter Fleury verwendet werden.

Controller HD47780 (bzw. kompatibler Chip) .

Besprechung hier : http://www.mikrocontroller.net/topic/44038

Pin-Belegung und Anschluß

Folienleiter 1mm Pitch, einseitig 14 Pins.

Es wurde derselbe Folienleiter<->Stiftleiste Adapter wie beim C0802 Display verwendet.

Pin Funktion AVR Pin
1 VDD +5V
2 Vo Kontrastspannung 0..5V via 10K
3 RS PC0
4 RW PC1
5 E PC2
6 DB0
7 DB1
8 DB2
9 DB3
10 DB4 PA0
11 DB5 PA1
12 DB6 PA2
13 DB7 PA3
14 GND

 

 

 


Display im Test

 


Testaufbau

Software

4- und 8-Bit sind möglich. 4-Bit-Modus wurde ausprobiert.

Link zu Peter Fleurys Bibliothek (LCD library for HD44780 based LCD’s: http://homepage.hispeed.ch/peterfleury/avr-software.html

Fazit

Sehr kleines und flaches Display.  einfach anzusteuern. Kein Backlight.

Samsung UG12D228AA

Grafik-Display 128×128 mit 4096 (?) Farben.

Besprechung hier: http://www.mikrocontroller.net/topic/221289

Controller Samsung S6B33B3

Handbuch Samsung S6B33B3

Pin-Belegung und Anschluß

Folienleiter 0,5mm Pitch, einseitig 20 Kontakte.

 

 

 

Fazit

noch nicht getestet.

Sharp MO78CKA-A3QKLA0057

Dies ist ein ziemlich großes Grafikdisplay mit 240×64 Pixeln ohne Hintergrundbeleuchtung. Der Anschluß erfolgt über einen Folienleiter. Auf dem Folienleiter ist der Controllerchip sowie andere Bauteile mit aufgebracht. Das Display ist demgemäß sehr flach.

Als Controller kommt der LH155 zum Einsatz. Im Datenblatt des LH155BA wird gesagt, dass dieser nur 128×64 Pixel unterstützt, möglicherweise befindet sich also eine erweiterte Version des Controllers im Display oder aber das Display bringt noch eigene Logik mit, um die zusätzlichen Pixel zu adressieren.

Zum Display liefert Pollin eine kleine Adapter-Platine mit, die die Kontrastspannung erzeugt, eine stabilisierte 5V-Spannung bereitstellt und eine Buchse für Parallelportanschluß des Displays an einen PC bietet.

Controller: LH155BA Datenblatt

Pollin-Doku zum Display: hier

Diskussion in Forum : http://www.mikrocontroller.net/topic/46635

Pin-Belegung und Anschluß

Der Folienleiter hat 1mm Pitch , einseitig 22 Pins.
Das Display kann nur den 8-Bit-Modus. Es kann mit 80xx-Mimik und 68xx-Mimik angesteuert werden.

Pin Funktion AVR-Pin
1 N.C.
2 GND GND
3 /RESB
4 /CSB
5 RS
6 M86
6800=HI, 80xx=LO
+5V
7 VDD, +5V +5V
8 6800: RW, 80xx: WE
9 6800: E, 80xx: RE
10 D0 PA0
11 D1 PA1
12 D2 PA2
13 D3 PA3
14 D4 PA4
15 D5 PA5
16 D6 PA6
17 D7 PA7
18 GND
19 VDD, +5V
20 VO, Kontrastspannung 14..17V
21 GND
22 N.C.

 

 

 

Die Adapter-Platine von Pollin

Diese Platine geht davon aus dass a) im 80xx-Modus angesteuert wird und b) die Ansteuerung via Parallelport erfolgt. Die Platine kann aber leicht so abgeändert werden dass sie den 6800-Modus unterstützt (LCD Pin 6 an +5V statt an GND anschliessen). Ausserdem muss man die Parallelport–Buchse nicht einlöten, ich habe Lötstifte eingelötet.


Die Pollin Adapter-Platine. Hier nicht mit Parallelport-Buchse bestückt, sondern mit den benötigten Lötstiften.
Die Adapter-Platine bringt eine eigene Spannungsversorgung mit 7805 mit, die man evtl. auch nicht braucht…

 


Pin 6 statt an GND jetzt an +5V (6800 Modus, Pin 6 wurde einfach durch einen dicken Lötpunkt mit Pin 7 verbunden).
Pin 9 statt „nicht angeschlossen“ an einem Pin für den Microcontroller. Pin 9 ist im 6800-Modus der Enable-Eingang des Displays.

Nach Anpassung der Pollin-Adapter-Platine wurde das Display mit dem AVR verbunden.

Software

Zu diesem Display gibt es zwar einen Thread im oben erwähnten Forum. Allerdings ist nach Eigenaussage keine der dort vorgestellten Software-Ansätze fertig und eher im Experimentierstadium

Fazit

noch nicht getestet.

Tinsharp TC1602A-08

Dies ist ein kleines Textdisplay 2 Zeilen x 16 Zeichen. Blaues LED-Backlight.Die Platine ist klein im Verhältnis zum Display.

Verwendet wird der Controller HD47780 (bzw. kompatibler). Daher kann dieses Display in der absoluten „Standard-Beschaltung“ und der „Standard“-Bibliothek von Peter Fleury verwendet werden.

Handbuch Controller HD47780.

Link zu Peter Fleurys Bibliothek (LCD library for HD44780 based LCD’s: http://homepage.hispeed.ch/peterfleury/avr-software.html

Pin-Belegung und Anschluß

 

Pin Funktion AVR Pin
1 GND, Vss GND
2 +5V +5V
3 Vo Kontrastspannung
4 RS PC0
5 RW PC1
6 E PC2
7 D0 PA0
8 D1 PA1
9 D2 PA2
10 D3 PA3
11 D4 PA4
12 D5 PA5
13 D6 PA6
14 D7 PA7
15 Led Backlight Anode ca. 2.7V, 20mA
16 Led Backlight Kathode GND

Kontrastspannung: Pin 3 geht an Schleifer eines Trimmwiderstands 22K. Die beiden anderen Kontakte des Trimmwiderstands an GND und +5V.

Hinweis zur Pin-Belegung: Wie immer bei der 4-Bit-Ansteuerung sind die Datenleitungen D4..D7 zu verwenden, in Tabelle fett markiert. D4..D7 entsprechen den „logischen“ Do..D3 der 4-Bit-Ansteuerung.

LED Backlight Spannung: Das Backlight ist sehr hell, ich habe mich nicht getraut die Spannung so hoch zu regeln dass wirklich 20mA verbraucht werden. Bei 2,7V ist es schon ausreichend hell und mein Netzteil zeigt da noch keinen nennenswerten Stromverbrauch an. Infos zur korrekten Backlight-Spannung habe ich keine gefunden.

 

 

 

Software

Bei der Verwendung der Bibliothek von Peter Fleury wurden die folgenden #defines verwendet (lcd.h):
#define LCD_LINES           2     /**< number of visible lines of the display */
#define LCD_DISP_LENGTH    16     /**< visibles characters per line of the display */
#define LCD_LINE_LENGTH    16     /**< internal line length of the display    */
#define LCD_START_LINE1  0x00     /**< DDRAM address of first char of line 1 */
#define LCD_START_LINE2  0x40     /**< DDRAM address of first char of line 2 */
#define LCD_START_LINE3  0x00     /**< DDRAM address of first char of line 3 */
#define LCD_START_LINE4  0x00     /**< DDRAM address of first char of line 4 */

Fazit

Kleineres Textdisplay, leider nur 16 Zeichen. Font ist für mein Empfinden schön. Sehr helles Backlight, attraktives Blau. Besonderheit ist, dass der Text im Display relativ zu den Anschlußpins „auf dem Kopf“ steht (vgl. mit anderen Textdisplays!).

Kleine Platine, geringer Stromverbrauch des Backlight trotz der großen Helligkeit. Nur 16 Anschlußpins. „Verbraucht“ im 4-Bit-Modus nur 7 Pins des AVRs. Befestigungsbohrungen sind kleiner als M3 (vermutlich M2,5)

Hoher Preis.

Tinsharp TC1604

Dies ist ein kleines Textdisplay 4 Zeilen x 16 Zeichen, der größere Bruder des TC1602. Grünes LED-Backlight. Die Platine ist klein im Verhältnis zum Display.

Verwendet wird der Controller HD47780 (bzw. kompatibler). Daher kann dieses Display in der absoluten „Standard-Beschaltung“ und der „Standard“-Bibliothek von Peter Fleury verwendet werden. Zur Ansteuerung der Zeilen 3 und 4 muss man die richtigen RAM-Adressen eingeben (siehe weiter unten unter „Software“).
Irgendwo habe ich im Zusammenhang mit dem TC1604 den Controller SPLC780D1 erwähnt gesehen, eventuell ist dies der verwendete Controller.

Handbuch Controller HD47780.

Handbuch Controller SPLC780D1.

Link zu Peter Fleurys Bibliothek (LCD library for HD44780 based LCD’s: http://homepage.hispeed.ch/peterfleury/avr-software.html

Pin-Belegung und Anschluß

Pin-Belegung identisch mit Tinsharp TC1602.

Pin Funktion AVR Pin
1 GND, Vss GND
2 +5V +5V
3 Vo Kontrastspannung
4 RS PC0
5 RW PC1
6 E PC2
7 D0 PA0
8 D1 PA1
9 D2 PA2
10 D3 PA3
11 D4 PA4
12 D5 PA5
13 D6 PA6
14 D7 PA7
15 Led Backlight Anode +5V
16 Led Backlight Kathode GND

Kontrastspannung: Pin 3 geht an Schleifer eines Trimmwiderstands 22K. Die beiden anderen Kontakte des Trimmwiderstands an GND und +5V.
Bei meinem Exemplar ist der maximale Kontrast in Nullstellung. Daher kann man den Trimmwiderstand weglassen und Pin 3 direkt mit GND verbinden – zumindest bei meinem Exemplar.

Hinweis zur Pin-Belegung: Wie immer bei der 4-Bit-Ansteuerung sind die Datenleitungen D4..D7 zu verwenden, in Tabelle fett markiert. D4..D7 entsprechen den „logischen“ Do..D3 der 4-Bit-Ansteuerung.

 


Gesamtaufbau

Das Display aus der Nähe

 

Software

Bei der Verwendung der Bibliothek von Peter Fleury wurden die folgenden #defines verwendet (lcd.h):
#define LCD_LINES           4     /**< number of visible lines of the display */
#define LCD_DISP_LENGTH    16     /**< visibles characters per line of the display */
#define LCD_LINE_LENGTH    16     /**< internal line length of the display    */
#define LCD_START_LINE1  0x00     /**< DDRAM address of first char of line 1 */
#define LCD_START_LINE2  0x40     /**< DDRAM address of first char of line 2 */
#define LCD_START_LINE3  0x10       /**< DDRAM address of first char of line 3 */
#define LCD_START_LINE4  0x50     /**< DDRAM address of first char of line 4 */

Fazit

Kleineres Textdisplay, leider nur 16 Zeichen. Font ist für mein Empfinden schön. Helles Backlight. Besonderheit ist, dass der Text im Display relativ zu den Anschlußpins „auf dem Kopf“ steht (vgl. mit anderen Textdisplays!).

Kleine Platine. Nur 16 Anschlußpins. „Verbraucht“ im 4-Bit-Modus nur 7 Pins des AVRs. Befestigungsbohrungen sind M3.

Hoher Preis.

Wintek WD-G1203T

Dies ist ein kleines Grafikdisplay mit 122×32 Pixeln. Es ist sehr flach und besitzt eine LED-Hintergrundbeleuchtung bestehend aus 6 grünen LEDs.

Besprechung hier:  http://www.mikrocontroller.net/topic/173195

Verwendeter Controller: 2xSED1520

Handbuch Controller SED1520

Pinbelegung und Anschluß

Stiftleiste 2mm (nicht 2,54!) mit 20 Pins.
Um das Display zu testen wurde ein Adapter gebaut, der die 2mm Stiftleiste auf eine 2,54mm Stiftleiste übersetzt.

Pin Funktion AVR Pin
1 Vss, GND
2 Vcc, +5V
3 N.C.
4 A0 (entspr. RS) PC0
5 /CS1, links PC2
6 /CS2, rechts PC3
7 interner Clock — offen lassen
8 E auf +5V legen
9 RW PC1
10 D0 PA0
11 D1 PA1
12 D2 PA2
13 D3 PA3
14 D4 PA4
15 D5 PA5
16 D6 PA6
17 D7 PA7
18 /Res: HI für 68xx Mode, LO für 80xx Mode auf +5V legen
19 Led Backlight + ~5V
20 Led Backlight –

Die 6 LEDs sind alle parallel geschaltet, jede LED mit einem eigenen Vorwiderstand 150 Ohm.

 


Das Display, hier falsch herum dargestellt („oben“ ist im Bild die untere Kante)

 


Der Adapter

Der Adapter wurde für ein weiteres Display (Optrex DMF 5002) gebaut, so dass er zusätzlich zur 2mm-Stiftleiste in der Mitte auch eine 2×10-polige Stiftleiste oben besitzt.


Der Adapter von unten.

 


Das Display im Betrieb (Textdarstellung)

 


Das Display im Betrieb (Grafikdarstellung, leider fehlerhaft)

 

Software

Bibliothek von hier: http://en.radzio.dxp.pl/sed1520/

Mit dieser Software konnte nach trivialen Anpassungen (Ports/Pins anpassen) Texte ausgegeben werden. Die Grafik-Ausgabe war fehlerhaft.

Fazit

Kleines, schmales Display. Ausreichende Hintergrundbeleuchtung. Es scheint keinen 4-Bit-Modus zu geben, von daher braucht es relativ viele Controller-Pins.

Grafik-Modus nicht nutzbar. Hier wäre noch etwas mehr Zeit in der Analyse des fehlers zu investieren.

Optrex DMF 5002N

Dieses grosse Display habe ich über ebay erstanden, es stammt also nicht aus der Pollin-Tranche.

Grafik-Display 128×112, EL-hintergrundbeleuchtet. Pixelgröße: 0,50 x 0,49 mm
Displaygröße: 75 x 65mm. Älteres Modell, das Datenblatt ist von 1997.

Hintergrundbeleuchtung 100V AC bei 400Hz laut Handbuch, max 12mA.

Controller ist der Toshiba T6963C, ein früher(?) sehr häufiger Chip. Auf der Platine finden sich noch 1x T6961B, 2x T7778A und ein TC5565AFL sowie ein paar kleinere 74xx.

Display Datenblatt und noch ein Datenblatt mit mechanischen Daten und noch ein Datenblatt.

Ausführliche Beschreibung der gesamten DMF500x Baureihe mit sehr guten Informationen und sogar mit Beispiel Source Code.

Controller Handbuch

Writing Software for T6963C based Graphic LCDs“ Application Notes

Fertige Software : http://en.radzio.dxp.pl/t6963/

Pin-Belegung und Anschluß

20-poliger doppelreihige Wannenstecker.

Kontrastspannung: Nach dem Schaltbild im Datenblatt: -21V an Vee. Zwischen Vee und GND ein Trimmer 10-20K in Serie mit einem Widerstand 5-10K. Der Widerstand ist an GND, der Trimmer an Vee. Den Schleifer des Trimmers an Vadj anschliessen.

EL-Spannung: AC 100V (?). Das Handbuch empfiehltz das Inverter-Modul „NEL-D32-49“.

Pin Funktion AVR Pin
1 Frame Ground
2 Vss GND GND
3 Vcc Power Supply Logic +5V
4 Vadj LCD Contrast Adjustment siehe Text
5 Vee Power Supply LCD Drive ~-21V siehe Text
6 /WR
7 /RD
8 /CE
9 C/D
10 /HALT – Stop Clock
11 /RESET – Controller Reset
12 D0
13 D1
14 D2
15 D3
16 D4
17 D5
18 D6
19 D7
20 N.C.
21 EL Backlight AC siehe Text
22 EL Backlight AC siehe Text

 

 

Status

Noch nicht getestet.

Schaltung für eine EL-Hintergrundbeleuchtung

Folgende Schaltung nutzt dem NE555 und einen kleinen Trafo, im Internet gefunden.

http://spurtikus.de/wp-content/uploads/2017/03/LM555-inverter-1.pdf

Es wird ein Transformator benötigt, der 8 Ohm auf 1KOhm übersetzt. Geeignet sind Ausgangsübertrager für Röhrenverstärker oder für 100V-Technik, möglichst winzige Typen suchen.
Beispiel (nicht getestet!): Contrad Teilenr. 516104

Weiterführende Infos

[[[
Intern:
Planung Bearbeitung:

1: Optrex DMF 5002N

2: Sharp M…: keine lauffähige SW vorhanden

3: Samsung: 0.5er Pitch, kein Stecker vorhanden

—: Nan Ya: Größe problematisch, kleinsägen? –> erst mal lassen

—: Alps: 41 Pins, kein FPC vorhanden –> erst mal lassen

]]]

 

Ein Datenlogger mit AVR – Nutzung von Sensoren

Hinweis: Diese Aktivität ist nicht abgeschlossen. Das Dokument beschreibt also den momentanen Stand.

Am AVR können zahlreiche (um nicht zu sagen: zahllose) Sensoren angeschlossen werden. Bei stromsparender Bauweise und Verwendung eines nichtflüchtigen Speichers (großes EEPROM, SD-Karte) können diese Werte über einen langen Zeitraum vom AVR autark gesammelt werden („Data Logger“). Ein bisschen habe ich da auch herumexperimentiert.

Luftdruck und Temperatursensor HopeRF HP03S

Dieser Sensor erfasst Luftdruck und Temperatur als 16-Bit Werte. Er kann mit dem I2C Protokoll  (auch „TWI“, Two Wire Interface genannt) angesprochen werden. Zum Sensor gibt es ein Datenblatt, dass auch die Programmierung darstellt. Allerdings ist das bei HopeRF abgedruckte Programm für 8051-CPUs.


Der Sensor (9,5x9x4,6mm) aus der Nähe. Das Innere ist mit einer gelartigen Masse gefüllt.

Um den Sensor nutzen zu können, muss man ihn elektrisch mit dem AVR verbinden. Ich habe ein Kabel angelötet. Evtl. kann man den Sensor auch direkt auf eine Platine auflöten.


An die sechs Kontakte kann man noch per Hand und ohne Lupe ein Kabel anlöten

Der Sensor wird mit maximal 3,6V betrieben. Man muss also evtl. aus einer 5V-Spannung noch eine geeignete Spannung (also z.B. 3,0 oder 3,3V) ableiten. Er hat einen XCLR-Eingang, der nur während der Messung High sein soll. Außerdem noch einen Masterclock-Eingang MCLK, an den eine Frequenz um 32768Hz anzulegen ist (auch nur während der Messung).  Schließlich noch SDA (Daten) und SCL (Clock) des  I2C-Interfaces um das EEPROM auszulesen.


Die sechs Anschlüsse des Sensors

Ich habe zum Experimentieren 3,0 Volt aus 5 in Serie geschalteten Dioden und einem Vorwiderstand gewonnen, die an +5V anliegen. MCLK, XCLR und SCL sind Leitungen, die nur der AVR beschreibt, daher kann man da die Pegelanpassung mittels zweier Widerstände machen. Der I2C-Bus erfordert, dass die beiden Leitungen mit einem Pullup-Widerstand gegen VCC gelegt sind.

Die SDA-Leitung wird in beide Richtungen genutzt, hier langt ein einfacher Spannungsteiler nicht aus. Man kann sich aber aus zwei Transistoren und drei Widerständen einen schönen Pegelwandler bauen (Erläuterungen dazu hier). Insgesamt ergibt sich das folgende Schaltbild.


Verkabelung zum AVR. Nicht eingezeichnet die beiden Pullup-Widerstände zu 4K7 gegen 3V an den Leitungen SDA und SCL.

Die vier Pins werden an den AVR angeschlossen, ich habe zum Experimentieren folgende Belegung gewählt:

AVR Sensor
PD7 MCLK
PD2 XCLR
PD3 SDA
PD6 SCL

Den Masterclock für den Sensor erzeugt der AVR mit einem Timer, der als PWM-Generator geschaltet ist. Mit einem 16Mhz- bzw. 8Mhz-Quarz bekomme ich nicht genau die Soll-Frequenz, sondern 31372 Hz. Erlaubt laut Datenblatt sind 30..35Khz, also ist meine Frequenz im erlaubten Rahmen.

Es dauerte einige Zeit, bis meine Hardware soweit war, die Calibration Werte auszulesen (hatte erst SDA auch nur mit einfachem Spannungsteiler versucht, was zu Lesefehlern führte). Bei mir kamen im Erfolgsfall folgenden Werte (mehrfache Auslesung):

Environmental Data Logger $Revision: 363 $ 
C1=17837, C2=3189, C3=358, C4=1474, C5=30695, C6=6333, C7=2500. A=7, B=29, C=6, D=11
Environmental Data Logger $Revision: 363 $
C1=17837, C2=3189, C3=358, C4=1474, C5=30695, C6=6333, C7=2500. A=7, B=29, C=6, D=11
Environmental Data Logger $Revision: 363 $
C1=17837, C2=3189, C3=358, C4=1474, C5=30695, C6=6333, C7=2500. A=7, B=29, C=6, D=11
Environmental Data Logger $Revision: 363 $
C1=17837, C2=3189, C3=358, C4=1474, C5=30695, C6=6333, C7=2500. A=7, B=29, C=6, D=11

Aus den Calibration Werten und den eigentlichen Messwerten, die als „raw“ 16-Bit-Werte vorliegen, muss nach einer (ohne Float-Arithmetik) nicht ganz simplem Formel die echten Werte für Temperatur und Luftdruck berechnet werden. Die Formeln sind im Datenblatt angegeben.
(Da der normale Luftdruck auf Meereshöhe eine Art Konstante ist und der Luftdruck mit der Höhe linear abnimmt, kann aus dem Luftdruck und einer passenden Tabelle/Formel übrigens  auch die Höhe des Messorts berechnet werden.)

Bei mir ergaben sich an einem schwülen Tag mit angekündigtem Gewitter (D1 und D2 sind die Raw-Werte, die anderen Werte Zwischenschritte der Umrechnung):

dUT=165
OFF=12774
SENS=17894
D1=41101, D2=30860
Temp=26.5 °Celsius, Pressure=1008.90 hPa (Height ~ 3.0m).
dUT=163
OFF=12773
SENS=17893
D1=41101, D2=30858
Temp=26.5 °Celsius, Pressure=1008.87 hPa (Height ~ 3.0m).

Die Höhe stimmt irgendwie nicht, zugegeben, es müssten um die 120 Meter sein 🙂

Zwei weitere digitale Thermometer, die ich direkt neben den Sensor stelle weichen nur minimal (0.1-0.3 Grad) von dem Messwert des Sensors ab. Die Temperatur stimmt also so in etwa. Genauer kann ich es nicht testen.

Weiterführende Infos

Luftfeuchtigkeitssensor HopeRF HH10D

Von Hope gibt es auch einen Luftfeuchtigkeitssensor, den HH10D. Dieser ist ein kleines Modul bestehend aus einem EEPROM sowie einem Sensor zuzüglich Beschaltung. Die Beschaltung macht aus einem Feuchtigkeitswert einen Frequenzwert. Im EEPROM stehen zwei Kalibrierwerte vom Hersteller.


Ansicht des Sensors HH10D von oben

Der EEPROM-Teil kann via I2C ausgelesen werden, für den Sensor-Teil muss man die entstehende Frequenz messen und mit den Kalibrierwerten in einen echten Messwert umrechnen. Eigentlich wäre es schöner, wenn der Sensor via I2C den Messwert bereitstellen würde, so wie das der HP03s macht. Ist aber nicht so. Die zu messende Frequenz liegt um 7Khz (5-10Khz).


Ansicht des Sensors HH10D von unten. Erkennbar sind das EEPROM und der Spannungs-Frequenz-Konverter. Die Unterseite des Moduls ist vergossen. Die Schnittkante der Platine (oben, unten) ist erstaunlich schlampig ausgeführt (es sieht wie mit der Hand an der Tischkante abgebrochen aus 🙂

Die Nutzung dieses Sensors besteht also darin dass man

  • Zunächst die Kalibrierkonstanten ausliest und dann
  • die Frequenz am Pin FOUT misst.

Mittels eines „Pin Changed“-Interrupts können Signalflankenwechsel an den Eingängen des AVRs erkannt und gezählt werden. Mit einem Timer-Interrupt, der z.B. alle Sekunde eintritt, kann nun der erreichte Zählwert als Frequenzwert des Sensors hergenommen werden.

Bei Experimenten mit einem 8Mhz-getakteten ATmega644, der nebenbei noch diverse Berechnungen machte und via RS232 kommunizierte (aber keine weiteren zeitkritische Interrupts ausführte), konnte ich Frequenzen bis etwa 70Khz sauber vom einem Eingangspin des AVRs lesen. Dies liegt weit über den geforderten maximalen 10Khz des Sensors.

Der HH10D wurde nach erfolgreichem Anschluss in das Logging des Datenloggers integriert. Es muss nur ein zusätzliches Byte mit abgespeichert werden.

Weiterführende Infos

Datenlogger

Nach dem prinzipiellen Anschluss des Sensors HP03s sollte ein Datenlogger entstehen. Designziele waren:

  • Loggen von Temperatur und Luftdruck, später kam noch Luftfeuchte hinzu
  • Speicherplatz für geloggte Daten („Samples“) für einen Zeitraum von mindestens 60 Tagen
  • Stromversorgung durch Akku o.ä. (nicht durch ein Netzteil!) autark für mindestens 60 Tage
  • Auslesen der Daten via RS232 oder USB
  • Nutzung einer Realtime-Clock für das Loggen der Uhrzeit
  • Die Möglichkeit, evtl. weitere Samples zu nehmen, insbesondere Nutzung der ADC-Eingänge des AVRs (Port A)

Aus den Designzielen habe ich abgeleitet:

  • Möglichst geringer Stromverbrauch des Datenloggers
  • Abspeicherung der Samples (Uhrzeit+Temperatur+Luftdruck+…) in einem EEPROM ausreichender Größe

Ein erster Grobentwurf des Dataloggers ist im Bild unten zu sehen. Ein AVR in einem möglichst stromsparenden Betrieb steuert Sensor, RTC (Real Time Clock) und EEPROM an.


Grobschaltbild des Datenloggers mit Sensor, Echtzeituhr und EEPROM (1. Enwurf, später durch ein Design mit 2 I2C-Bussen ersetzt. Das für die Realisierung gewählte EEPROM ist ein 24FC1025 und nicht wie hier im Bild noch beschrieben, ein 24LC1024).

Basierend auf den Designzielen wurde folgendes festgelegt:

  • Ablage der Daten in einem großen EEPROM. Das EEPROM ist ein 128KByte-Typ 24FC1025. Größere EEPROMs, die am I2C-Bus arbeiten, sind mir nicht bekannt.
  • Nutzung eines Realtime Chips (RTC). Die Wahl fiel auf den PCF8583. Vorab wurde bereits die Nutzung des PCF8583 und des EEPROMs am AVR ausprobiert.

Die Anzahl der pro Tag erzeugten Samples ist variabel.

Da ein „Environmental“ Datalogger entworfen wird, sind Temperatur und Luftdruck den natürlichen Gegebenheiten unterworfen. Ein Datalogger für einen Hochofen oder eine Druckkammer hätte mit anderen Wertebereichen zu arbeiten.

Datenplatzbedarf

Annahme: Der Datenlogger nimmt alle 30 Minuten ein Sample vom Sensor. D.h. es werden 48 Samples pro Tag erzeugt.

Abzubildender Temperaturbereich:

Die höchste jemals gemessene natürlich entstandene Temperatur ist +70,7 Grad Celsius (im Iran, 2007), der höchste europäische Wert ist höchstens +50,0 Grad (in Sevilla, Spanien, 1881).
Die niedrigste jemals gemessene natürlich entstandene Temperatur ist höchstens -91,5 Grad Celsius (Antaktis, Wostok-Station, 1997). in Europa höchstens -59,0 Grad Celsius (in Schweden unbestätigt gemessen).
Zu den erwähnten Extremtemperaturen siehe hier.
Mit einem Wertebereich -100…+100 Grad Celsius sind wir also auf der sicheren Seite.

Abzubildender Luftdruckbereich:

Der höchste jemals gemessene Luftdruck beträgt 1085,7hPa (Mongolei, 2001), der niedrigste jemals publizierte Wert beträgt 856hPa (Taifun bei Okinawa, Japan, 1958). Zu diesen Werten siehe hier und hier.
Mit einem Wertebereich 750..1250 käme man also ziemlich gut hin.

Pro Sample müssen folgende Informationen gespeichert werden:

  • Temperatur: Bereich -100 .. +100 Grad Celsius, zwei Nachkommastellen: Ganzzahlanteil 1 Byte, Nachkommaanteil 00..99: 1 Byte, also in Summe 2 Bytes.
  • Luftdruck: Bereich etwa 750..1250, zwei Nachkommastellen.
    Wenn man vom echten Luftdruckwert vor dem Speichern konstant 750 abzieht, kann man mit 9 Bit einen Ganzzahlanteil mit 512 Werten abbilden, also den Bereich 750 .. 1262. Für den Maximalwert 512 benötigt man 2 Bytes, eventuell kann man das 9.te Bit irgendwo anders unterbringen, dann nur 1 Byte. Nachkommaanteil 00..99: 1 Byte, also in Summe 3 Bytes. Evtl. oberstes Bit des 9-Bit Werts des Ganzzahlanteils in oberstem Bit des Nachkommateils mitcodieren, dann wären es in Summe nur 2 Bytes.
  • Zeitstempel: Hier wird z.B. alle 24 Stunden (immer um 0 Uhr) das Datum gespeichert: Jahr, Monat, Tag. Dann werden für die 47 weiteren Samples nur noch gespeichert: Samplenummer ab 1 gezählt.
    Für das Jahr braucht man (beim PCF8583)  2 Bit (0..3), Monat 4 Bit (1..12) und Tag 5 Bit (1..31). In Summe 11 Bit. Dies kann in 2 Bytes abgelegt werden. Für die Folgesamples wird jeweils 1 Byte benötigt, wenn man maximal 256 Samples pro Tag erlaubt oder halt 2 Bytes, dann kann man bis zu 65536 Samples / Tag abbilden.

Damit ergibt sich pro Tag folgender Bedarf (48 Samples / Tag):

1) Annahme: Luftdruck Wert braucht 2 Bytes: (2 Bytes Zeitstempel + 2 Bytes Temperatur + 2 Bytes Luftdruck) + 47 * (1 Byte Samplenummer + 2 Bytes Temperatur + 2 Bytes Luftdruck) = 6+47*5=241 Bytes

2) Annahme: Luftdruck Wert braucht 3 Bytes: (2 Bytes Zeitstempel + 2 Bytes Temperatur + 3 Bytes Luftdruck) + 47 * (1 Byte Samplenummer + 2 Bytes Temperatur + 3 Bytes Luftdruck) = 7+47*6=289 Bytes

Bei 128KByte EEPROM ergibt das in Tagen: 131.072 Bytes/241 = 543 Tage bzw. 453 Tage. Beide Werte sind mehr als ausreichend (Designziel waren 60 Tage).

Abzubildender Feuchte-Bereich

Dies ist mal einfach, es handelt sich um einen Prozentwert 0..100. Evtl. will man noch zwei Nachkommastellen haben, dann kommt ein weiterer Wert 00..99 hinzu. Also ein oder zwei Bytes Speicherbedarf.

Spannungsversorgung

Alle Bausteine hängen am I2C Bus.

Der Sensor wird mit 3,3V betrieben. Das EEPROM und die RTC kann ebenfalls mit 3,3V betrieben werden, ebenso der gewählte AVR ATMega644 (aber nur bis -offiziell- 10MHz Taktfrequenz). Somit wurde entschieden, alles mit 3,3V Versorgungsspannung aufzubauen.

Das Controllerboard ist das bewährte DD Megaboard mit einem 3,3V Spannungsregler LT1117 (statt dem „üblichen“ 7805; der LT1117 wurde gewählt, weil im Fundus vorhanden; der LT1117 ist jedoch eine schlechte Wahl, wenn es um geringen Stromverbrauch geht, siehe weiter unten). Die Schutzdiode vor dem Spannungsregler wurde diesmal durch eine Drahtbrücke ersetzt, um den Spannungsabfall an der Diode zu vermeiden.

Der MAX232CPE kann (inoffiziell) gerade so noch mit 3,3V betrieben werden, dies ist in diversen Foreneinträgen belegt.

Auch ISP funktioniert an 3,3V.

Die extern anliegende Versorgungspannung besteht im Zielbild aus 3-4 Batterien zu je 1,5V, also 4,5V -6,0V.

Stromverbrauch der gewählten Plattform

Nachmessen ergab, dass das DD Megaboard „ohne alles“ (also nur die Stromversorgung mit dem LT1117 3.3 alleine) schon 5,3mA braucht. Bei Betrieb mit Netzteil ist das lächerlich wenig, aber bei Batteriebetrieb schon zu viel.
Ohne das Sensorboard, ohne eingestecktes MAX232 und ohne eingesteckten RS232-Stecker und ohne eingestecktes ISP-Kabel werden 10,7mA verbraucht, d.h. der ATMega 644 verbraucht etwa 5mA bei 8Mhz.
Ein eingesteckter ISP-Stecker erhöht den Stromverbrauch um 0,4mA. Der MAX232CPE erhöht den Verbrauch um weitere satte 5,6mA. Alles zusammen verbraucht 16,7mA (ohne Sensorboard). Eine weitere Reduktion kann nur durch Programmierung des ATMega (Sleep-Modes, Aufwachen nur alle z.B. 10 Sekunden oder auch paar Minuten) erreicht werden.

Der Regler LT1117 3.3 ist nach Datenblatt für eine Anwendung bei minimalem Stromverbrauch definitiv nicht geeignet mit bis zu 5mA Eigenverbrauch. Laut Internet gibt es sparsamere Regler, z.B. den LP2950 in 3,3V Version, mit 75µA Eigenverbrauch, siehe hier: LINK. Ein LP2985 IM5 3,3 (SMD) ist ideal mit unglaublich niedrigen 1µA Ruhestrom.

Wenn der AVR mit set_sleep_mode(SLEEP_MODE_IDLE) und sleep_mode() schlafen geschickt wird, reduzieren sich die oben erwähnten 10,7mA auf 7,4mA. Mein Board braucht selbst wie erwähnt 5,3mA, so dass der AVR also in diesem Zustand nur 2,1mA bei 8Mhz braucht. Laut Quelle (http://www.mikrocontroller.net/articles/Sleep_Mode) soll der AVR bei nur 1Mhz sogar nur 0,3mA brauchen.

Mit einer optimierten Stromversorgung wie dem LP2950 denke ich, dass ohne Änderung der Hardware bei 8Mhz Gesamtverbrauchswerte um 3mA möglich sind. Bei einer Stromquelle, die nutzbare 1000mA liefert können so 333 Stunden überbrückt werden. Dies sind leider nur 333/24 ~ 13 Tage mit dem SLEEP_MODE_IDLE. Das langt aber nicht aus, um die Designziele zu erreichen (60 Tage Betrieb ohne Unterbrechung)

Momentan vorstellbarer Bestfall, wenn die Hardware verändert wird:

  • Die Stromversorgung benötigt 1µA (LP2985)
  • Statt des MAX232CP muß ein Typ verwendet werden, denn man in einen Sleep Zustand versetzten kann. Annahme: Auch dieser Chip verbraucht im Sleepmode nur 1µA
  • Der AVR ist während einer Stunde pro Minute nur 2 Sekunden aktiv, also nur 120 Sekunden in den 3600 Sekunden. Dabei verbraucht er die oben gemessenen 5mA. Pro Stunde sind dies 5000µA*120/3600=167µAh

Im Ergebnis sind dies 169µAh Gesamtverbrauch bei optimalen Annahmen.

Mit 2000mAh NiMh-Zellen, bei denen 1000mAh nutzbar sind (Annahme), kommt man so auf theoretisch 246 Tage (5917 Stunden). Bei solch großen Werten spielt schließlich die Selbstentladung der Akkus eine wesentliche Rolle. Die 60 Tage des Designziels sind aber unter diesen Annahmen sicher erreichbar.

Da mir momentan die entsprechenden Bauteile fehlen (kein passender Spannungsreger, kein abschaltbarer MAX232) mache ich erst mal mit dem weiter was ich habe. Ich kann den Datenlogger auch an eine vorhandene Solarzelle anschließen, die eine weit höhere Leistung liefert als der Datalogger braucht.

Interferenzen des Sensors HP03s mit anderen I2C Geräten

Ich habe ein EEPROM, eine RTC (Realtimeclock, PCF8583) sowie den genannten Sensor an einem I2C Bus betrieben. Dabei traten öfter Störungen auf. Das Auslesen der RTC war, wenn der Sensor gleichzeitig am Bus angeschlossen war, nicht zuverlässig. Variation der Bus-Pullup-Widerstände (an 3,3V Bus von 2K2 auf 1K gesenkt) brachte keine Verbesserung. Analysen mit dem Oszilloskop zeigen, dass das Acknowledge der RTC einen zu geringen Hi-Pegel hat, wenn der Sensor angeschlossen ist. Konkret waren es ohne Sensor ~2,4V, mit Sensor nur noch 1,78V. Dies langt zur Erkennung als HI nicht aus (Daumenregel: LO=weniger als 0,3*VCC, HI=mehr als 0,7*VCC). Herumsuchen in Foren brachte keine weiteren Erkenntnisse. Selbst wenn der Sensor softwaremäßig nicht angesprochen wird, funktioniert das Auslesen der RTC nicht immer (!). Nach drei Tagen Herumprobieren entschied ich mich dazu, das Design des Sensorboards zu ändern: Es gibt nun zwei getrennte I2C-Busse:

  • Einen für den/die Sensoren (Software Implementierung)
  • Einen für RTC und das EEPROM (Hardware-Implementierung)

Nach Änderung der Hardware können nun die drei Geräte (RTC, Sensor HP03S, EEPROM) sauber verwendet werden. Das Hardware-Design ist bereits vorbereitet, um den Luftfeuchtesensor HH10D aufzunehmen.


Schaltbild Sensorboard. Der Wannenstecker oben links dient der Verbindung mit dem AVR, die beiden Wannenstecker in der Mitte dem Anschluss der Sensoren HP03s und HH10D.

Verbindung AVR<->Sensorboard

AVR Pin AVR Pin Bedeutung Sensorboard Wannenstecker Pin Sensorboard Pin Bedeutung
PB3 OC0A PWM Generator Output 4 MCLK von HP03s
PC0 1 SCL (Hardware I2C)
PC1 2 SDA (Hardware I2C)
PC2 3 XCLR von HP03s
PC4 5 SCL2 (Software I2C)
PC5 6 SDA2 (Software I2C)
PC6 7 FOUT von HH10D
9 GND
10 VCC (3,3V)

 


Bild: DD Megaboard rechts, in der Mitte das Sensorboard und ganz links der Sensor HP03s.

 


Das Sensorboard aus der Nähe. Auf dem Sensorboard ist die RTC und das EEPROM sowie die Sicherungsbatterie zu sehen.

I2C Adressen

Die I2C Adressen der einzelnen Bausteine müssen eindeutig sein.

Baustein I2C Adresse Bus Kommentar
Hope HP03s 0xA0 SW Adresse nicht änderbar
Hope HH10 0xA2 SW Adresse nicht änderbar
EEPROM 24FC1025 0xAx11x HW Alternativen möglich (A0,A1,A2)
PCF8583 0xA2 HW Alternativen möglich (A0)

Hier kollidieren die Adressen von RTC und dem Luftdrucksensor. Da beide Bausteine an verschiedenen Bussen liegen, macht dies aber nichts. Über meist vorhandene Adressleitungen A0,A1,A2,… kann die Basisadresse eines I2C Bausteins variiert werden. Dies ist bei den beiden Sensoren nicht möglich, deren Adressen sind fix.

RTC PCF8583 geht viel zu schnell (läuft viel zu schnell)

Bei den ersten Tests zeigte es sich, dass die RTC PCF8583 viel zu schnell lief. Und zwar etwa eine Stunde in 4 Stunden, also satte ~20% zu schnell.

Nachforschen im Datenblatt und in Foren brachte die Erkenntnis, dass direkt an den Pins VCC und GND ein Kondensator zum Abblocken der hochfrequenten Störsignale aus der Versorgungsspannung benötigt wird. Ich hatte im Design einen 100n-Kondensator vorgesehen, diesen aber leider nicht direkt am PCF8583 platziert. Ich habe dann zur Nachbesserung einen 10uF-Kondenstator direkt an die Pins des Chips gelötet (Platinenunterseite). Danach war die Uhr sehr genau (in einem Tag ca. 12 Sekunden Abweichung). Ein weiteres Feintuning muss mit einem 20pF-Trimmer erfolgen (im Datenblatt beschrieben). Diesen Trimmer habe ich zur Zeit noch nicht an der Uhr. Die Datenlogger-Software erlaubt es aber, die Zeit direkt neu einzugeben, somit kann ich mit dem momentanen Zustand und einer leichten Gangabweichung nach einigen Wochen vorübergehend leben.

Weiter

– Einbau in Gehäuse

Betriebssoftware

Für den Datenlogger wurde eine kleine Software geschrieben. Diese ist mittels doxygen in den Sourcen dokumentiert. Die mit doxygen generierte Dokumentation ist unter folgendem Link als Kopie vorhanden:

Dokumentation, erzeugt mit doxygen (Englisch)

Format der Datenausgabe

Im folgenden ein Auszug eines Datendumps:

<dump> 
<header>
 Environmental Data Logger $Revision: 625 $
 number of samples per day: 144
 oldest sample with complete timestamp: 12.01. 16:10
 newest sample with complete timestamp: 11.02. 12:40
 samples in total: 4180
 eeprom start byte: 0x000006
 eeprom end byte: 0x00b3a1
 total bytes in eeprom: 45980
 <date>11.02.</date>
 <time>12:44:15</time>
</header> 
<logdata>
 <log type="long">12.1. 16:10 18.5 1006.40 56.0</log>
 <log type="long">12.1. 16:20 19.2 1006.37 56.9</log>
 <log type="long">12.1. 16:30 19.7 1006.40 56.3</log>
 <log type="long">12.1. 16:40 12.4 1006.9 59.1</log>
 <log type="long">12.1. 16:50 9.1 1005.62 63.6</log>
 <log type="long">12.1. 17:00 7.8 1005.56 65.5</log>
 <log type="long">12.1. 17:10 7.4 1005.56 65.8</log>
 <log type="long">12.1. 17:20 7.1 1005.43 65.7</log>
 <log type="long">12.1. 17:30 7.0 1005.46 65.5</log>
 <log type="long">12.1. 17:40 7.0 1005.43 65.2</log>
 ...
 <log type="long">10.2. 22:50 -9.5 1018.21 34.8</log>
 <log type="long">10.2. 23:00 -9.5 1018.18 34.7</log>
 <log type="long">11.2. 12:40 21.6 1018.9 48.8</log>
<statistics> 
 <temp-min>-14.0</temp-min>
 <temp-max>21.6</temp-max>
 <pressure-min>987.53</pressure-min>
 <pressure-max>1020.87</pressure-max>
 <moisture-min>19.4</moisture-min>
 <moisture-max>78.0</moisture-max>
</statistics>
</logdata>
</dump>

I2C Debugging

Da der I2C Bus nur aus zwei Leitungen besteht, kann man die Aktivitäten auf dem Bus noch gut mit einem Speicher-Oszilloskop mit zwei Eingängen ansehen.

Viele Oszilloskope haben einen externen Triggereingang, den man irgendwo in der Schaltung anklemmt, wo ein Signal zur Verfügung steht, dass als Start-Trigger geeignet ist. Die beiden Eingänge werden dann an SDL und SDA gelegt. Wenn das Oszilloskop eine große Speichertiefe hat, kann man nun das Oszilloskop auf „Single“ Trigger eingestellt und das Trigger-Event herbeigeführt. Danach steht die Geschichte um das Trigger-Event herum im Oszilloskop-Speicher. Man kann nun hineinzoomen, bis man die einzelnen Bits auf den beiden Leitungen sieht. Durch sorgfältiges Abzählen kommt man so auf die Bits und die Bytes.

Ein Datenbit wird in I2C immer bei einer steigenden SCL-Flanke übernommen.

ATmega Universal Board

Das ATmega Universal Board ist ein möglichst einfaches Board, um 40-polige AVR Controller in Applikationen verwenden zu können.
Designziele waren:

  • Einseitige Platine, maximal 80x100mm
  • Alle IO-Ports zugänglich und nicht durch board-eigene Funktionen zwangsbelegt
  • RS232, ISP und Spannungsregulierung on Board
  • Mindestens nutzbar für ATmega32 und ATmega64(4)

(dargestellt ist Board Revision 1.0)

Features

  • Alle 32 IO-Pins auf 4 Steckerleisten herausgeführt (Port A-D)
  • Verwendbar für ATmega 32, 64,  644, 644P, bzw. alle ATmegas mit 40-poligem Gehäuse, die zum ATmega 32 pinkompatibel sind.
  • Betrieb mit ca. 8..15V DC (bzw. der Bereich, in dem der 7805 betrieben werden darf zuzüglich 0,6V, die an der Eingangsdiode abfallen).
  • Regulierte Spannungsversorgung, Verpolungsschutz durch Eingangsdiode
  • Regulierte +5V über Jumper JP1 für eigene Applikationen herausgeführt
  • LED1 für Betriebsspannung (via Jumper abschaltbar ab Rev 1.2)
  • LED2 an PD6 für einfache Statusanzeigen etc. (via Jumper abschaltbar)
  • RESET Taster
  • ISP Anschluß 10-polig (bis Rev 1.3a) bzw. 6 polig (ab Rev 1.4)
  • RS 232 Anschluß
  • Trimmpoti für Kontrastreglung eines LCD-Displays (ab Rev 1.2)
  • 75x100mm Platinengröße (ab Rev 1.3; vorher 79x100mm)

Hardware

Die Hardware orientiert sich an zahllosen anderen Schaltungsvorschlägen aus dem Internet. Neben der Bereitstellung der 4×8 IO-Pins ist beim AVR nicht viel zu tun. An XTAL1/2 liegt ein Quarz an, die beiden Kondensatoren C3,C4 sind Standardbeschaltung. Der RESET-Pin geht über R1 an den RESET-Taster. Der ISP-Anschluß ist „standard“-beschaltet, ein handelsüblicher ISP-Programmer mit 10-poligem Ausgang sollte also direkt passen. Die RS232-Anbindung an Pin RxD,TxD mittels MAX232 ist ebenfalls absolute Standardbeschaltung.
Um einseitig routen zu können, wurden drei Drahtbrücken per Hand eingefügt.
Die Ports A..D stehen schließlich an den Buchsen SV_A..SC_D zur Verfügung. An Pin 1 der Buchse SV_X steht immer PortX0, an Pin 8 der Buchse PortX7 zur Verfügung, d.h. die Buchsen sind an allen Ports gleich beschaltet.

Die Steckerleisten etc. sind z.B. bei http://www.reichelt.de  erhältlich. Produktnummern besonderer Bauteile bei Reichelt:

Steckerleisten 10-polig WSL 10G
Pfostenbuchsen 10-polig (SV_x) PFL 10
RS232-Buchse (X2) D-SUB BU 09EU
Anschlußklemme 2-polig (X1) AKL 101-02
Reset-Taster TASTER 3301B


Es empfiehlt sich, für den ATmega einen Sockel einzubauen. Sinnvoll ist auch die Nutzung eines Sockels für den Quarz. So kann man zwischen Prozessoren und zwischen CPU-Frequenzen einfach wechseln.

Statt des MAX232 kann auch ein MAX202CPE verwendet werden. (Dann langt es aus, statt der 1µF-Kondensatoren 0,1µF-Kondensatoren zu nehmen, man kann es aber auch bei den 1µF-Typen belassen).

Hinweis: Alle im folgenden gezeigten Bilder können durch Anklicken vergrößert werden.

Schaltplan

Der Schaltplan für das Board (dargestellt ist Revision 1.4).

 

Belegung der Steckerleisten und Jumper

X1 – Power Supply Input

Pin Funktion
1 +8..15V DC
2 GND

JP1 – VCC out

VCC regulated.
Can be used for external hardware. If used, honor 7805 maximum ratings regarding output current and thermal characteristics.

Pin Funktion
1 +5V regulated
2 GND

 

JP2 – LED2 Connector

Connection Jumper, connects PD6 to LED2 (via R3).
Can be used by application to give general purpose visual feedback. Disconnect LED if PD6 is used by the application for other purposes.

Pin Funktion
1 to PD6
2 to R3 + LED2

 

JP3 – LCD contrast voltage

Variable voltage 0..VCC.
Can be used for control contrast of an external LCD display.

Pin Funktion
1 0..VCC (controlled via R5)

 

JP4 – Power indicator LED

Connection jumper, connects VCC to LED1.
Can be used to disconnect Power LED for applications with low power requirements.

Pin Funktion
1 VCC
2 to R2 LED1

 

SV_x – Port Connectors

ATmegas Port A..D.

Pin SV_A Funktion SV_B Funktion SV_C Funktion SV_D Funktion
1 PA0 PB0 PC0 PD0
2 PA1 PB1 PC1 PD1
3 PA2 PB2 PC2 PD2
4 PA3 PB3 PC3 PD3
5 PA4 PB4 PC4 PD4
6 PA5 PB5 PC5 PD5
7 PA6 PB6 PC6 PD6
8 PA7 PB7 PC7 PD7
9 GND (*) GND (*)
10 +5V regulated (*)

*: since Rev 1.1 only / erst ab Rev 1.1

SV1 – ISP Connector (6 pin)

Pin Funktion
1 MISO
2 VCC
3 SCK
4 MOSI
5 RESET
6 GND

 

SV1 – ISP Connector (10 pin)

Pin Funktion
1 MOSI
2 VCC
3 N.C.
4 N.C.
5 RESET
6 GND
7 SCK
8 GND
9 MISO
10 GND

X2 – RS232 Connector

Pin Funktion
1 N.C.
2 TxD of AVR
3 RxD of AVR
4 =6
5 GND
6 =4
7 =8
8 =7
9 N.C.

 

Board Layout / Bohrungen

Alle Bohrungen 0.8mm außer den folgenden:

  • Stecker X1: Bohrungen mit 1.0 oder 1.2mm.
  • Befestigungslöcher RS232 Buchse: 2.8mm.
  • Drahtbrücken J1-Jn (je nach Revision) nicht vergessen!

Bestückungsplan


Der Bestückungsplan des Boards (dargestellt ist Board Revision 1.4).

Ein Aufsichtsfoto nach erfolgter Bestückung


Komplett bestücktes Board (dargestellt ist Board Revision 1.0).

Revisionshistorie und Dateien zum Download

Revision 1.4

Erweiterungen/Veränderungen gegenüber Revision 1.3a:

  • 6-polige Standard ISP Buchse (statt bisher Standard 10-polig)
  • Optimierung des Board-Layouts (16mil Bahnen wo immer möglich statt bisher 10mil Bahnen)
  • Boardmaße weiter reduziert auf 100x72mm

Eagle-Dateien (Schaltplan, Board): ZIP-File

Revision 1.3a

Erweiterungen/Veränderungen gegenüber Revision 1.2:

  • Boardmaße reduziert auf 100x75mm, so dass man aus einer Europlatine zwei Boards herstellen kann

Eagle-Dateien (Schaltplan, Board): ZIP-File

Revision 1.2

Erweiterungen gegenüber Revision 1.1:

  • Optionaler Trimmwiderstand R5 eingefügt. Dieser kann auf eine Spannung zwischen 0..VCC eingestellt werden und dient der Erzeugung der Kontraststeuerspannung eines LCD-Displays. Steuerspannung abgreifbar an neuem Jumper JP3

Revision 1.1

Erweiterungen gegenüber Revision 1.0:

  • VCC/GND an SV_A verfügbar (Pin 10 und Pin 9)
  • GND an SV_D verfügbar (Pin 9)
  • Bauelemente und Leiterbahnführung wurden optimiert

Eigentlich sollte an jedem Port VCC/GND zur Verfügung stehen. Dies hätte aber zahlreiche Brücke zur Folge. Für Selbstbauprojekte ist es ist oft ausreichend, dass an mindestens einem Port VCC/GND verfügbar ist.

Eagle-Dateien (Schaltplan, Board): ZIP-File

Revision 1.0

In dieser Version waren jeweils nur Pin 1..8 der 10-poligen Wannenstecker belegt. Die Versorgungsspannung für eigene Applikationen mussten am dafür vorgesehenen Jumper JP1 abgenommen werden.

Breakout Board für das ATmega Universal Board

Da die 10-poligen Wannenstecker fürs Experimentieren doch etwas fuzzlig sind, habe ich ein passendes Breakout Board entworfen, dass alle Pins auf Lötstifte führt.

Das Breakout Board. Port A-D sind auf Lötstifte geführt.

Breakout Board Dateien zum Download

Breakout Board, Eagle-Dateien (Schaltplan und Board-Datei):

Weiterführende Links

OpenEEG

OpenEEG (http://openeeg.sourceforge.net/doc/) ist ein Open Source Projekt, um Gehirnwellen am PC sichtbar zu machen.

Aus diesem Bemühungen ist unter anderem eine Art „Produkt“ entstanden, das „ModularEEG“ heißt. ModularEEG besteht aus einem Hardware-Teil und einem Software-Teil.

Der Hardware-Teil besteht wiederum aus einem analogen und einem digitalen Teil.

Der analoge Teil ist im wesentlichen ein hochempfindlicher Verstärker und Filter um die Gehirnwellen aufzunehmen und die zahllosen Störsignale wegzufiltern.

Der digitale Teil basiert auf einem AVR-Mikrocontroller. Dieser besitzt einen 6-Kanal D/A-Wandler und wandelt die vom Analogteil kommenden Signale in digitale Daten um. Außerdem versteht er noch ein paar Kommandos. Der AVR wird gesteuert durch eine Firmware, der ModularEEG Firmware. Diese wird in den AVR mittels ISP hineingeladen. Die Firmware liegt als C-Sourcecode vor. Die Kommunikation zwischen dem AVR und dem PC erfolgt via RS232. Auf der PC-Seite ist dazu ein steuerndes Programm erforderlich. Es existieren unterschiedliche Programme, die die ModularEEG Hardware nutzen.

Die OpenEEG Hardware

ModularEEG wird auf zwei Platinen aufgebaut. Auf einer ist die gesamte hochempfindliche analoge Elektronik, auf der anderen der digitale Teil mit steuerndem AVR Mikrocontroller.

Die Platinen für  ModularEEG kann man fertig bestellen bei der bulgarischen Firma Olimex (http://www.olimex.com/gadgets/index.html).

Die Bauteile für ModularEEG sind zum Teil ziemlich speziell, bei Reichelt kriegt man aber fast alles.

Der Aufbau der Hardware ist auf der OpenEEG Website ausführlich beschrieben (Dokumente „Preparing to build the circuit boards“ und „Building the ModularEEG, Abschnitt Assembly).

Die Funktionsfähigkeit der Hardware kann man anhand mehrerer Tests verifizieren, wenn die Firmware auf den Controller geladen worden ist.

Firmware für den Controller

Die Firmware Source, die man aus dem Internet herunterladen kann (Stand 2009) wurde seit langem nicht weiterentwickelt und lässt sich mit aktuelleren avrlibc-Versionen nicht mehr übersetzen. Es handelt sich bei den problematischen Stellen aber nur um geänderte/weggefallene Makroschreibweisen, ich habe zwei Dinge korrigiert:

  1. Schreibweise des Makros „BV()“ in die neuere Variante „_BV()“ geändert, wo es im Sourcecode vorkam
  2. Am Anfang der Datei folgende Defines hinzufügen:
    // for compatibility purposes, support for old makros
    #define       inp(port)   (port)
    #define       outp(val, port)   (port) = (val)
    #define       inb(port)   (port)
    #define       outb(port, val)   (port) = (val)
    #define       sbi(port, bit)   (port) |= (1 << (bit))
    #define       cbi(port, bit)   (port) &= ~(1 << (bit))

Dann lies sich modeeg-p2.c übersetzen. (dies ist Version 2 der Firmware; Version 3 liegt auch bei, habe ich aber nicht weiter betrachtet, da Electric Guru nur mit Version 2 zurechtkommt) Ausserdem liegen fertige HEX-Dateien für Version 2 und 3 bei, so dass man auch gar nicht kompilieren muss.

Platine des Analogteils am Anfang der Bestückung

Fertig bestückte Analogplatine. Oben ist der Connector zu sehen, mit dem beide Platinen verbunden werden.

Fertig bestückte Digitalplatine. Unten der Connector, mit dem beide Platinen verbunden werden, oben der ISP Connector zum Programmieren des AVRs.

Funktionstest nach vollendeter Bestückung des Digitalteils und nach Einladen der Firmware. Der AVR produziert ein Rechtecksignal mit 14 HZ Frequenz. Dieses Signal kann gemessen werden. Wenn es produziert wird, war das Hochladen der Firmware erfolgreich.

Laut Oszillograph ist der Test erfolgreich. Das Signal ist vorhanden und die Frequenz stimmt. Dieses Signal wird auf der Analogseite als Signal zur Kalibrierung verwendet. Dort hat es allerdings nur noch 250µV Amplitude, um die Verstärker nicht zu überfahren.

Hier sind die beiden Platinen miteinander verbunden, und erste Tests der Gesamtfunktion laufen.

Hier das Ganzmetallgehäuse, das Störstrahlungen abmildert. Die Verdrahtung der Platinen mit den Gehäuse-Anschlüssen ist noch nicht erfolgt.

Gehäuse mit aufgesetztem Deckel.

Gehäuse, nun bereits verdrahtet. Die ursprünglichen Buchsen wurden durch andere ersetzt, da die ursprünglichen Buchsen von einer gemeinsamen Masse ausgingen.

dito.

Damit ist die Hardware schon mal testbar. Die Elektroden fehlen noch.

Erste Experimente mit der Software

Im folgenden wurde die Hardware via seriellem Kabel mit dem PC verbunden. Mangels unterstützender Linux-Software habe ich die Software „Electric Guru“ für Windows genommen. Ich habe Windows XP in einer VM laufen und die serielle Schnittstelle von Linux bis in die VM durchgeschaltet, so dass auch Windows auf diese Schnittstelle zugreifen kann. Funktioniert gut.

Die sehr hohe Empfindlichkeit der Hardware zeigt sich schon darin, dass bei fehlender Abschirmung die Störstrahlung im Raum durch Telefon, Netzleitung, Handy etc. massiv sichtbar sind. Die folgenden beiden Bilder zeigen dies beeindruckend.

Oben: So sehen die Signale aus, wenn der Deckel des Metallgehäuses abgenommen wird (Es sind keine Elektroden angeschlossen). Das erkannte „Hauptsignal“ ist zugestopft mit Störstrahlung.

… und so, wenn der Deckel aufliegt. Die Störstrahlung kommt nicht mehr durch.

Kalibrieren der Hardware

Wenn die Hardware funktioniert und die Firmware läuft, muss die Hardware zunächst kalibriert werden. Dieser Vorgang ist ebenfalls auf der OpenEEG Website ausführlich beschrieben. Ich empfehle das Dokument „ModularEEG Testing Tips“, Abschnitt „Troubleshooting, Testing, and Calibration“.

Es geht u.a. darum, den Signalpegel des Analogteils so einzustellen, dass die PC-Software (hier: ElectricGuru) das Signal so bekommt, wie sie es erwartet. Dazu muss die Amplitude eingestellt werden. Die beiden folgenden Bilder zeigen beispielhaft die Situation vor und nach dem Kalibrieren für einen (den unteren) Kanal.

Kalibrieren („Coarse Trim“) der Hardware. Es liegt im unteren Kanal das oben schon erwähnte Testsignal (Rechteck, 14Hz, hier nur noch 250µV Amplitude) an. die Amplitude muss justiert werden. Der obere Kanal läuft „frei“ vor sich hin.

Bild nach dem Kalibrieren. Die Amplitude ist eingestellt (sie soll zwischen den Werten 256 und 768 oszillieren)

Weiter Bau der Elektroden

Weiterführende Links

Atmel AVR Mikrocontroller mit OpenSuse: Tools

Man kann unter Linux und unter Windows Code für den AVR entwickeln. In meinen Texten ist das Linux-Umfeld beschrieben. Man kann zahlreiche Entwicklungsumgebungen und Tools verwenden, hier beschreibe ich meine Umgebung. Benötigt werden die folgenden Tools:

  • avr-gcc (Cross Compiler für C, erzeugt AVR Code). Dieser Compiler nutzt die avr-libc, eine libc-Implementierung für die AVR Plattform.
  • Eclipse (integrierte Entwicklungsumgebung) mit CDT (C/C++ Development Plugins) und AVR-Eclipse Plugin
  • avrdude (Kommandozeilentool für Code-Upload auf den Mikrocontroller, bedient ISP-Schnittstelle des Controllers, damit werden also die erzeugten Programme in den Controller geladen) und/oder Ponyprog (mit graphischer Oberfläche)

Die Installation der Tools unter OpenSuse geht einfach via Yast. In älteren Versionen war die avr-gcc Toolchain für AVRs im Hauptrepository vorhanden, mittlerweile muss man das AVR-Repository per Hand hinzufügen (YaST -> Software Repositories), zu finden für die jeweiligen Versionen unter:

http://download.opensuse.org/repositories/CrossToolchain:/avr/

die Repos-URL für OpenSuse 12.1 ist z.B.

http://download.opensuse.org/repositories/CrossToolchain:/avr/openSUSE_12.1/

Alle genannten Tools können nach Hinzufügen dieser Repositories einfach installiert werden. Nur Ponyprog (das es für Windows und Linux gibt) habe ich direkt von dessen Homepage (http://www.lancos.com/) geladen. Unter http://www.mikrocontroller.net/articles/AVR_Eclipse ist die Installation für verschiedene andere Linuxe beschrieben.

Vorgehen bei der Entwicklung

Der C-Code wird mit Eclipse erzeugt. avr-gcc führt das Cross-Compiling für die AVR-Plattform durch und erzeugt alle benötigten Dateien. Der eigentliche Code -als .hex-Datei- wird dann mittels avrdude oder Ponyprog über die ISP-Schnittstelle des AVRs in den AVR hineingeladen (ISP=In System Programming). Es gibt zahlreiche Möglichkeiten den Controller an den PC anzubinden (seriell, parallel, USB, …). Ich habe mir ein serielles Kabel gelötet, das war am einfachsten.

Code compiliert nicht? Für neueren Source-Code kann es notwendig sein, dass man eine aktuellere Version der avr-libc verwenden muss. Diese steht u.U. nicht als RPM o.ä. zur Verfügung, weil zu neu. Ein Vorgehen, wie das unter OpenSuse funktioniert, habe ich hier beschrieben.

Erstellen und Compilieren des Programms

Die Erstellung der C Source erfolgt mit dem Editor innerhalb von Eclipse. Mit diesem Tool kann unter Project die Compilierung mittels ‚make‘ direkt angestoßen werden („Build Project“), Ergebnis ist ein oder zwei HEX (.hex) Files. Eines geht in den Flash-Speicher, eines in den EEPROM-Speicher des Controllers. Nicht immer wird ein EEPROM-Teil benötigt.

AVR programmierung mit Eclipse
Erstellung des Codes für den AVR. Aus der C Source test.c wird die Hex-Datei flash.hex erzeugt.

Laden des Programms in den Controller

Eclipse legt alle Dateien in einem Workspace ab. Innerhalb des Workspaces erfolgt die Organisation nach Projekten. Hier ein Listing für mein erstes Testprojekt:

soc:/home/dennis/avr-eclipse-ws/avrtest000/Standard # ls -l
 insgesamt 48
 -rwxr-xr-x 1 dennis users 5892 28. Nov 21:50 avrtest000.elf
 -rw-r--r-- 1 dennis users   13 28. Nov 21:50 eeprom.hex
 -rw-r--r-- 1 dennis users  414 28. Nov 21:50 flash.hex
 -rw-r--r-- 1 dennis users 1028 28. Nov 21:50 makefile
 -rw-r--r-- 1 dennis users 9295 28. Nov 21:50 .map
 -rw-r--r-- 1 dennis users  229 28. Nov 20:49 objects.mk
 -rw-r--r-- 1 dennis users  343 28. Nov 21:50 sources.mk
 -rw-r--r-- 1 dennis users  589 28. Nov 21:50 subdir.mk
 -rw-r--r-- 1 dennis users 3976 28. Nov 21:50 test.obj

Wenn innerhalb von Eclipse der avrdude richtig konfiguriert wird, kann mittels des Eclipse-Buttons  der Code direkt auf den Controller geladen werden. Für mein besonderes Kabel musste ich die Pinbelegung für avrdude erst richtig definiere. Dies erfolgt in der Datei /opt/cross/etc/avrdude.conf. ich habe folgendes eingefügt:

programmer
 id    = "pony";
 desc  = "serial port banging ponyprog cable by DD";
 type  = serbb;
 reset = ~3;
 sck   = 7;
 mosi  = 4;
 miso  = 8;
 ;

 

(Übrigens habe ich später gesehen, dass genau diese Konfiguration unter der Namen „ponyser“ schon existiert…)

Ein „händischer“ Test von avrdude kann noch ohne Eclipse, wie folgt erfolgen (testweises Auslesen des AVRs, hier für einen atmega32, wenn ISP über die serielle Schnittstelle /dev/ttyS0 erfolgt):

avrdude -v -p m32 -P /dev/ttyS0 -c pony -U flash:r:ttt.hex:i

Das Schreiben erfolgt mittels

avrdude -v -p m32 -P /dev/ttyS0 -c pony -U flash:w:led01.hex:i

Unter OpenSuse muss der Nutzer in der Gruppe „uucp“ sein, um auf die serielle Schnittstelle als Non-Root zuzugreifen. Auch ein einfaches „chmod 666 /dev/ttyS0“ half bei mir nicht, erst das Hinzufügen der Gruppe erlaubte das Ausführen von avrdude.

Wenn avrdude per Hand funktioniert, kann die avrdude-Einbindung in Eclipse korrekt eingestellt werden. In meinem Fall sieht das wie folgt aus:

Konfiguration des avrdude-Programms innerhalb der Eclipse Preferences: Öffnen der Preferences mittels rechter Maustaste auf dem Projekt im Project Explorer View von Eclipse. Zunächst muß der zu verwendende ISP-Programmer definiert werden.

Als nächstes wird die genutzte Hardware (AVR-Typ) und die Taktfrequenz des AVRs eingetragen. Der Taktfrequenzwert steht im Programm als Define (F_CPU) zur Verfügung.

Bei den Build Settings sicherstellen, dass alle notwendigen HEX-Files miterzeugt werden.

Danach können alle Aktionen mit dem AVR innerhalb von Eclipse durchgeführt werden.

Nutzung von ponyprog: Ponyprog ist ein tolles Programm, um „mal schnell“ auf den AVR zuzugreifen. Man muss keine Manpages lesen und in Foren suchen, und kann in wenigen Minuten einen ersten Upload machen. Ponyprog läuft unter Windows und Linux. Ponyprog muss vor der Nutzung korrekt konfiguriert (wie ist der Controller angebunden, Setup -> Interface Setup) und kalibriert werden (Setup -> Calibration).

Hier Bilder zum Setup:

Einstellen des Controller-Typs (AVR micro) und des AVR-Typs (ATmega32).

Einstellen des Zugangs zum AVR, bei mir seriell über /dev/ttyS0, was COM1 entspricht

Danach kann ein HEX-File in Ponyprog eingeladen werden(Open Device File) und auf den Controller überspielt werden (Write Device). Es wird immer der komplette Speicher (also z.B. 8 Kbyte beim ATMega8) übertragen, auch wenn das eigentliche Programm nur ein paar Bytes lang ist. Nach dem Schreiben findet noch ein Verify statt. Das Programm startet unmittelbar nach dem Verify.

Herunterlesen des Codes von einem AVR auf den PC.

Im Erfolgsfall wird die Anzahl der übertragenen Bytes ausgegeben

Das Einladen des kompletten Speichers dauert beim ATMega8 mit 12MHz ca. 40 Sekunden, beim ATMega32 kann es entsprechend länger dauern.

Nutzung eines USB Programmers von Atmel

Mangels serieller Schnittstellen an neueren PCs (besonders bei Notebooks) bietet sich eher die Nutzung eines solchen Programmers an.

Der AVR ISP mkII von Atmel

Das Innere des Programmers – wesentlich komplexer als der triviale serielle Programmer

Falls bei Nutzung des USB-Programmers der Programmer nicht gefunden wird, sind eventuell die Regelkn für den Zugriff auf USB nicht ausreichend. Dazu die Datei /etc/udev/rules.d/15-usbavr.rules neu anlegen und dort  hineinschreiben:

# Atmel AVR ISP mkII SUBSYSTEM==“usb“, SYSFS{idVendor}==“03eb“, SYSFS{idProduct}==“2104″, GROUP=“users“, MODE=“0660″

Austausch der vorhandenen avr-libc durch eine neuere Version

Falls man Quellcode aus dem Internet bezieht, kann es vorkommen, dass dieser mit neueren Versionen der avr-libc entwickelt wurde. Man merkt das daran, dass Funktionen vom Compiler und dem Linker als unbekannt gemeldet werden. Man kann dann versuchen, ein neueres Paket für seine Plattform zu installieren. Wenn man OpenSuse und Yast regelmäßig nutzt, hat man allerdings schon das neueste Paket für diese Plattform. Man kann dann aber die avr-libc selbst compilieren. Ich habe dies wie folgt gemacht:

  1. Download der neuesten avr-libc von http://www.nongnu.org/avr-libc/. Die Source findet man unter  http://download.savannah.gnu.org/releases/avr-libc/
  2. Compilieren der avr-libc. Hier kann man nach dem README und dem INSTALL vorgehen. Diesen Schritt würde ich als Non-Root machen, um zu verhindern, dass man sich mit falschen Parametern die vorhandene avr-libc zerschießt. Ich habe das configure-Kommando wie folgt aufgerufen:
    ./configure –build=`./config.guess` –host=avr –prefix=/home/dennis/avrlibc
    Damit wird die libc unterhalb meines Homeverzeichnisses gebaut.
  3. Statt einem „make install“ habe ich dann per Hand die beiden erzeugten Verzeichnisse (avr/include, avr/lib) in das Verzeichnis kopiert, in dem die alte Bibliothek liegt. Dies ist bei OpenSuse /opt/cross. Die dort vorhandenen Verzeichnisse avr/lib und avr/include habe ich vorher gesichert.
  4. Zum Schluss noch aus dem gesicherten lib-Verzeichnis die ldscripts in das neue lib-Verzeichnis kopieren:
    cp -a ./lib.orig/ldscripts ./lib

Danach sollte ein Kompileren wieder möglich sein und die neue Bibliothek wird benutzt.

OpenSuse 11.3 ohne avrlibc-Paket

Aus mir unbekannten Gründen ist die avrlibc in OpenSuse 11.3 nicht dabei. Wie weiter oben beschrieben kann diese aber relativ einfach nachinstalliert werden. Erst nach mehreren Versuchen habe ich eine libc-Version gefunden, die mit dem gcc 4.5, der in 11.3 als Cross Compiler dabei ist, auch kompilierbar ist. Dies ist die Version 1.6.7 (nicht gingen bei mir: 1.7.0, 1.6.5, 1.6.9)

Der compilierte Inhalt unterhalb von …/avr/include muß nach/lib64/gcc/avr/4.5/include, der von …/avr/lib  nach /lib64/gcc/avr/4.5/.
Danach lässt sich AVR Code compilieren und Linken.

Zurück zur Hauptseite

Atmel AVR Mikrocontroller mit OpenSuse: Die Hardware

Die benötigte Hardware ist ein AVR Controller mit etwas zusätzlicher Beschaltung. Die kann man mutig selbst erstellen oder fertig kaufen. In den folgenden Abbildungen dargestellt sind drei Boards, ein einfaches, bei eBay fertig für ca. 15€ erstanden und ein komplexeres, von www.pollin.de für ebenfalls ca. 15€, zum Selbstaufbauen und schließlich ein fertig aufgebautes Board für ca. 50 Euro.

Für die ISP-Programmierung benötigt man ein RS232-Kabel, auf dem 1:1 die Anschlüsse 3,4,5,6,7,8,9 durchgeführt sind.

Anforderungen an den PC, mit dem die AVR-Programme erstellt werden, sind niedrig. Ein 600Mhz-Notebook ist dicke ausreichend. Unabdingbar ist die RS232-Schnittstelle, wenn seriell übertragen werden soll. Da man beim Herumbasteln theoretisch die RS232-Schnittstelle durch Fehlbeschaltung und Unachtsamkeit zerstören kann, sollte man zur Sicherheit nicht seinen besten Rechner für solche Hardware-Aktionen nutzen.

Der AVR Controller kommt mit einigen Milliampere Strom aus, so dass ein einfaches Steckernetzteil mit 9V Gleichspannung ausreicht. Ein komplettes einfaches AVR Board braucht auch nur einige Dutzend mA. Manchmal kann man auch Wechselspannung einspeisen, denn viele Boards besitzen eine eigene Gleichrichtung und Stabilisierung. Vorübergehend langt sogar eine 9V-Batterie.

Einfaches AVR-Board mit ATmega8. 4 Schalter und 8 Dioden dienen als Input- und Output-„Geräte“. Oben links wird die Stromversorgung angeschlossen, in der Mitte oben erkennt man den RESET-Taster. Das ISP-Programmierkabel ist oben rechts angeschlossen. Auf der mittleren braunen Buchsenleiste sind die IO-Pins des Controllers nach außen geführt.

Das Pollin Board ( http://www.pollin.de). On-Board sind die RS232-Umsetzung für die ISP-Programmierung, so dass oben links direkt der Computer angeschlossen werden kann. Unten links ist ein eigenständiger RS232-Anschluss vorhanden. Das Board erlaubt, diverse Typen der AVR-Controller (ATMega, ATtiny) in die Fassungen einzusetzen. Drei Taster und zwei LEDs sind die On-board I/O-Geräte. Ein Steckplatz für ein EEPROM 24Cxx ist vorhanden, des weiteren zwei Steckplätze für ISP und JTAG Programmierung und auf der 40-poligen Steckerleiste sind zahlreiche Pins der Controller herausgeführt. 2 Jumperleisten erlauben die flexible Anpassung des Boards. Dieses Board gibt es mittlerweile in mehreren Varianten und es gibt auch Erweiterungsboards dazu.

Das LAB-MEGA Board von Rakers (http://www.rakers.de) Dieses Board ist mit SMD-Elementen aufgebaut und besitzt daher geringe Abmessungen. Es nutzt den ATmega128, der satte 53 I/O Pins und 128KB Flash Speicher bietet. Auf der Karte findet sich neben den „üblichen“ Dingen wie Spannungsversorgung, ISP/JTAG Interfaces auch eine USB Schnittstelle, ein I2C Expander, eine Echtzeituhr (PCF8583) sowie 2 RS232 Interfaces. Zahlreiche Pins sind auf einer 64-poligen Messerleiste VC64 herausgeführt. Die SMD Bauweise erschwert (ohne geeignetes Werkzeug) leider das Auswechseln defekter Bauteile und auch die Fehlersuche. Zu diesem Board gibt es Erweiterungsboards von Rakers.

ISP-Adapter

 Es gibt unterschiedliche Adapter, für RS232, Parallel, USB, …

Serieller ISP-Adapter

Ich verwende einen selbstgebastelten. Bauanleitungen dazu gibt es zahlreich im Internet. Mein Adapter passt z.B. direkt an obiges Pollin-Board.

ISP-Adapter Schaltplan.

Die Schaltung passt komplett auf einer passend gemachten Lochrasterplatine
in einen RS232-Stecker hinein. Hier ist der Stecker ohne Gehäuse dargestellt.

Es gibt übrigens auch Boards mit einer 6-poligen Buchse statt der oben dargestellten 10-poligen. Dies gilt z.B. für das LAB-MEGA Board von Dr. Rakers.
Für solche Boards habe ich mir einen Adapter gelötet, der auf der einen Seite eine 10-polige Buchse und auf der anderen Seite einen 6-poligen Stecker hat.
Das Pin Mapping ist wie folgt:

10-polige Buchse (wie z.B. auf Pollin Board oder Ulrich Radigs Boards)  6-polige Buchse (z.B. Rakers LAB-MEGA)
9 – MISO 1
5 – /RESET 5
6 – GND 6
7 – SCK 3
1 – MOSI 4

Schließlichgibt es noch eine verwirrende Besonderheit beim ATmega128: Dort wird die ISP-Programmierung nicht über die auch vorhandenen Pins MOSI+MISO vorgenommen sondern über zwei „neue“ Pins namens PDI und PDO (nicht zu Verwechseln mit den Port-Pins PD1 und PD0 !!!).
Auch hier das Mapping:

ISP Pin Bezeichnung AT mega 128 Port-Pin am AT mega128
MOSI PDI PE0 (Port E, Pin 0)
MISO PDO PE1 (Port E, Pin 1)

Nutzung eines USB Programmers von Atmel

Mangels serieller Schnittstellen an neueren PCs (besonders bei Notebooks) bietet sich eher die Nutzung eines solchen Programmers an.


Der AVR ISP mkII von Atmel
Das Innere des Programmers – wesentlich komplexer als der triviale
RS232 Programmer

Falls bei Nutzung des USB-Programmers der Programmer nicht gefunden wird, sind eventuell die Regeln für den Zugriff auf USB nicht ausreichend. Dazu die Datei /etc/udev/rules.d/15-usbavr.rules neu anlegen und dort  hineinschreiben:

# Atmel AVR ISP mkII SUBSYSTEM==“usb“, SYSFS{idVendor}==“03eb“, SYSFS{idProduct}==“2104″, GROUP=“users“, MODE=“0660″

Kein serieller Port mehr am PC?

Die Nutzung der seriellen Schnittstelle für ISP-Programmierung ist ein sehr simpler Ansatz. RS232 kann auch zur bequemen Ausgabe z.B. von Fehlermeldungen, verwendet werden.

Leider haben viele neuere PCs keine serielle Schnittstelle mehr.
Manche Motherboards haben noch einen „seriellen Header“, der eine serielle Schnittstelle darstellt. Wenn man so etwas auf dem Motherboard hat, kann man sich einen Slot-Adapter kaufen und die Schnittstelle nutzen.

Wenn man nicht mal einen seriellen Header auf dem Mainboard hat, kann man einen USB<->Seriell-Adapter nutzen. Es gibt für unter 10 Euro Kabel, die als Adapter zwischen RS232 und USB dienen können. Unter Linux klinkt sich eine solches Kabel in den Gerätebaum z.B. als „/dev/ttyUSB0“ ein und kann dann genauso wie eine „echte“ serielle Schnittstelle genutzt werden.

Bei meinem OpenSuse 11.2 sieht die Einbindung (mittels dmesg ausgegeben) wie folgt aus:

 ...  [ 3529.694778] usbserial: USB Serial Driver core
 [ 3529.705376] USB Serial support registered for ch341-uart
 [ 3529.705409] ch341 6-1:1.0: ch341-uart converter detected
 [ 3529.718371] usb 6-1: ch341-uart converter now attached to ttyUSB0
 [ 3529.718650] usbcore: registered new interface driver ch341

Atmel AVR Mikrocontroller mit OpenSuse: Ansteuerung vonLCD-Displays

LCD-Displays gibt es in großer Mannigfaltigkeit. Üblich ist, dass die Displays bereits einen Controller enthalten, der die Pixel ansteuert. Auch in diesem Bereich hat eine Art Standardisierung stattgefunden, so dass nur gegen wenige Controllertypen programmiert werden muss. Ein sehr gebräuchlicher Controller ist der HD44780.

LCD-Display Seiko L2432 mit 2 Zeilen zu 24 Zeichen

Auf dem Display sitzt ein Controller HD44780, also absoluter „Standard“.
Das Display hat 2 Zeilen zu 24 Zeichen.


Vorderseite des Seiko L2432.

Unterseite des Seiko L2432, rechts der Controller HD44780. Ganz rechts der 14-polige Konnektor, an den ein Flachbandkabel angelötet wurde.

Das Display wird über einen Connector mit 14 Pins angeschlossen. Sogar die Pin-Belegung des Connectors ist quasi-standardisiert.

Pin Function
1 GND
2 V+, normalerweise +5V
3 VLC, Kontrastreglung
4 RS – Register Set
5 RW – Read/Write
6 E – Enable
7 DB0
8 DB1
9 DB2
10 DB3
11 DB4
12 DB5
13 DB6
14 DB7
15 (A – Anode for Backlight) optional
16 (K – Kathode for Backlight) optional

In Rot sind die für die 4-Bit-Ansteuerung notwendigen Pins gekennzeichnet. Diese müssen mit freien Ports des AVRs (bzw. V+ und GND) verbunden werden.

Neben der Datenleitungen (8 Datenbits D0..D7 bzw. 4 Datenbits D4..D7 im 4-Bit-Modus, Controllerauswahl, R/W, RS, Enable sowie GND und Vcc), muss unbedingt auch -wenn vorhanden- die Kontrastregelung angeschlossen werden. Das gezeigte Display benötigt beispielsweise eine Spannung, die irgendwo zwischen 0 und 5V liegt. Wird keine passende Regelspannung für den Kontrast eingestellt, ist absolut nichts zu sehen und man kann nicht erkennen, ob das Display überhaupt funktioniert! Die Kontrastspannung wird über einen Trimmer angeschlossen von typischerweise 10 KOhm, so dass man auf unterschiedliche Lichtverhältnisse reagieren kann.

Als Open Source gibt es eine Bibliothek für den AVR-Controller (LCD Library von Peter Fleury), welche LCDs ansteuern kann. Sie nutzt die 4-Bit-Ansteuerung (oder einen Memory-Mapped-Mode, der bei bestimmten AVRs möglich ist). Je nach Controller wird ein 8-Bit-Modus, ein 4-Bit-Modus oder beides unterstützt. Der 4-Bit-Modus hat den Vorteil, dass am AVR weniger Pins benötigt werden.

Hinweis: Im 4-Bit-Modus werden die Datenleitungen D4..D7 eines LCD-Moduls/Controllers genutzt. Auch wenn in der Peter-Fleury-Bibliothek immer von D0..D3 (=die logischen Datenleitungen des 4-Bit-Modes) die Rede ist, gemeint sind im 4-Bit-Modus immer D4..D7 (=die physikalischen Datenleitungen des LCD-Moduls).

Im folgenden ist die Nutzung der Funktionen dargestellt (Codeauszug, kompletten Source Code gibts weiter unten):

...
#include "lcd.h"
 
...
/* clear display and home cursor */
lcd_clrscr();
 
/* put string to display (line 1) with linefeed */
lcd_puts("LCD Test Line 1n");
 
/* cursor is now on second line, write second line */
lcd_puts("Line 2");
 
/* move cursor to position 8 on line 2 */
lcd_gotoxy(7,1);
 
/* write single char to display */
lcd_putc(':');
 
DO("wait for keynr");
/* wait until push button PD2 (INT0) is pressed */
wait_until_key_pressed();
DO("after keynr");
 
/*
 * Test 2: use lcd_command() to turn on cursor
 */
 
/* turn on cursor */
lcd_command(LCD_DISP_ON_CURSOR);
...

Die Bibliothek muss im Makefile als zusätzliche Bibliothek eingetragen werden. Die Funktionsprototypen stehen alle im Header „lcd.h“, den man im eigenen Programm eintragen muss.


Seiko L2432 angeschlossen und erste Datenausgabe

Die Bibliothek ist auch konfigurierbar, es gibt z.B. Controller, die mehr als zwei Zeilen beherrschen, dies kann in der Bibliothek eingestellt werden. Die Spezifika des Displays (Anzahl Zeilen, Anzahl Zeichen, ..) und die Anschlussbelegung am AVR muss in „lcd.h“ eingetragen werden.

Im Code findet sich übrigens auch der Makroaufruf DO(„text“), dies ist ein Debug-Makro („DEBUG OUT“) von mir, welchen Daten via RS232 ausgibt. Damit kann man erkennen, was der Controller gerade tut. Wie die RS232-Schnittstelle angesprochen wird, wird weiter unten in meinem Text besprochen.

LCD-Displays Wintek WD-C2704M-1HNN mit 4 Zeilen zu 27 Zeichen

Das Display hat 4 Zeilen zu 27 Zeichen. Auf dem Display sitzen zwei Controller, kompatibel zum HD44780. Einer ist für die oberen zwei Zeilen, der andere für die unteren zwei Zeilen verantwortlich. Beide Controller teilen sich alle I/O-Leitungen. Statt einem E(nable)-Pin gibt es zwei Enable-Pins E1 und E2 für die Auswahl zwischen den beiden Controllern.

Die Bibliothek von Peter Fleury unterstützt allerdings nur Displays mit einem Controller. Ich habe das Problem dadurch gelöst, dass ich in alle Funktionen der Bibliothek wo notwendig zwischen beiden Controllern unterschieden habe. So wird z.B. aus der Funktion lcd_clrscr(void) eine Funktion lcd_clrscr(int controllerId), der die Werte LCD_CRTLR_1 und LCD_CRTLR_2 übergeben werden können.

Die Pin-Belegung des Moduls ist in folgender Tabelle dargestellt. Die oben erwähnte „Quasi-Standardisierung“ist hier leicht verändert, da 2 Enable-Pins existieren.

Pin Function
1 GND
2 V+, normalerweise +5V
3 VLC, Kontrastreglung (0..4V)
4 RS – Register Set
5 RW – Read/Write
6 E1 – Enable Controller 1
7 E2 – Enable Controller 2
8 DB0
9 DB1
10 DB2
11 DB3
12 DB4
13 DB5
14 DB6
15 DB7
16-21 Key Input for Input Keys

In Rot sind die für die 4-Bit-Ansteuerung notwendigen Pins gekennzeichnet. Diese müssen mit freien Ports des AVRs (bzw. V+ und GND) verbunden werden.

Im folgenden ist die Nutzung der modifizierten Funktionen dargestellt (Codeauszug, kompletten Source Code gibts weiter unten):

...
#include "lcd.h"
 
...
/* clear display and home cursor */
lcd_clrscr(LCD_CRTLR_1);
lcd_clrscr(LCD_CRTLR_2);
 
/* put string to display (line 1) with linefeed */
lcd_puts(LCD_CRTLR_1, "LCD Test Line 1n");
 
/* cursor is now on second line, write second line */
lcd_puts(LCD_CRTLR_1, "Line 2");
 
/* move cursor to position 8 on line 2 */
lcd_gotoxy(LCD_CRTLR_1, 7,1);
 
/* write single char to display */
lcd_putc(LCD_CRTLR_1,':');
 
DO("wait for keynr");
/* wait until push button PD2 (INT0) is pressed */
wait_until_key_pressed();
DO("after keynr");
 
/*
 * Test 2: use lcd_command() to turn on cursor
 */
 
/* turn on cursor */
lcd_command(LCD_CRTLR_1, LCD_DISP_ON_CURSOR);
...

Für LCDs mit nur einem Controller ist die Bibliothek natürlich so wie sie ist zu benutzen.

Im Bild ist der Anschluss des LCDs an das einfache AVR-Board zu erkennen.

Experimentalaufbau – die Display-Schutzfolie wurde auf dem Display belassen, daher die schlechte Ablesbarkeit.

Hier der Source-Code zum Display:  lcd_2controller.zip

Erschöpfende Infos zur LCD-Ansteuerung unter http://www.mikrocontroller.net/articles/AVR-Tutorial:_LCD

Zurück zur Hauptseite