mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik MCU Auswahl für Temperaturanzeige mit OLED


Autor: Ralfi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nabend,

ich bin gerade in den Vorbereitungen eine Temperaturanzeige mit 12 
Sensoren
(voraussichtlich KTY) und einem OLED 2,8" Display zu planen/bauen/... 
nun ist meine Frage an euch was für einen MCU ich hierfür nehmen soll. 
Reicht da ein 8bitter oder soll ich hier für den Umstieg auf ARM wagen.

mfg

Autor: Sebastian Weidmann (code)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hast du schon Erfahrung in Sachen Microcontroller? Oder ist das dein 
erstes Projekt in dem du einen Microcontroller verwendest?

Mein Vorschlag ist, dass du einen 8 Bit Atmel Atmega nimmst. Der sollte 
dafür locker ausreichen um Temperaturen einzulesen und auf einem Display 
auszugeben. Das kannst du z.B. in Bascom relativ einfach programmieren 
und es gibt schon fertige Routinen um ein Display anzusteuern.

Ein ARM wäre meiner Meinung nach überdimensioniert.

mfg
Code

Autor: Ralfi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Danke erst mal für deine Antwort.
Nein, das ist nicht mein erstes Projekt.

Bei den AVR ist des halt so eine Sache weil des OLED hat 240x320 Pixel 
und das mit jeweils RGB. Packt der das wenn ich dann noch 12 Sensoren 
auszulesen habe.

Autor: Jean Player (fubu1000)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi,
die Temperatur Sensoren müßen ja maximal alle 30sek. ausgelesen werden 
(vermute ich mal, da du ja nit nennst was sie messen sollen).
Die Ansteuerung eines OLED Displays klappt mit nem Atmega auch locker.

Meine Vermutung, der kleine µC wird sich eher langweilen als auf seine 
Kosten kommen.

Gruß

Autor: Marius S. (lupin) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Die Ansteuerung eines OLED Displays klappt mit nem Atmega auch locker.

Kommt auf den Controller des OLEDs an. Das Display wird bei der Größe 
wahrscheinlich ohne Speicher sein, also eine RGB Ansteuerung mit Sync 
Signalen - braucht einiges an Pins und MHz wenn man das mit nem AVR in 
Software machen will.

Eigentlich ist das Display übertrieben um ein paar Temperaturen an zu 
zeigen. Wenn es unbedingt so ne hohe auflösung sein soll würde ich ein 
embedded linux system verwenden (welches die Display-Signale in Hardware 
erzeugt).

Autor: Ralfi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das OLED hat einen eingebauten Controller (OLED = C0283QGLD-T) von Glyn.
Meine Sensoren sollen Wasser,Innen,Aussen,Öl Temperaturen messen. Ich 
denke mal das ich sie in 2sec einmal auslese.

Den ADC kann ich ja in einer Timer Int auslesen.

Ich habe vor Tasten zur Umschaltung der Werte (4 gleichzeitig auf dem 
OLED) in der Main abzufragen wenn ich aber jetzt dan in ein Sub gehe die 
Temps berechne und dann das OLED beschriebe was denke ich mal sehr lange 
dauert wird die Umschaltung auf die nächsten Werte sehr langsam, oder?

Hier wäre dann mein 2.Problem wie Strukturiere ich dies wo Frage ich die 
Tasten ab, etc.....

Autor: Michael H. (morph1)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
rechne dir mal die datenmenge aus die du übertragen musst, dann den 
overhead (position setzen, register setzen etc) und du wirst sehen das 
du mit 8bit verdammt schnell am ende sein wirst!

ich hab beim halbwegs schnellen zeichnen (zb große schriften) mit einem 
pic24 schon zu kämpfen (wobei ich allerdings SPI verwende -> 
ultralangsam)

Autor: Dennis Schulz (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ich würde einen ARM nehmen, am besten einen Cortex-M3 ;)

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ralfi schrieb:
> Das OLED hat einen eingebauten Controller (OLED = C0283QGLD-T) von Glyn.

Dann bestehen ja überhaupt keine Echtzeitanforderungen, d.h. ein AVR 
schafft das dicke.

Den größten Platz wird der Schrift-Font benötigen, d.h. 8kB Flash 
solltens schon sein, z.B. ein ATtiny861.

Ich würde Dir allerdings raten, erstmal ein Text-LCD zu nehmen.

Und wenn dann alles läuft, kannst Du ja mal versuchen das Grafikdisplay 
zu proggen. Sowas ist allerdings für Anfänger ein harter Brocken, man 
muß alles mit Put-Pixel selber malen.


Peter

Autor: Ralfi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Also ich hab jetzt mein OLED mit einem AVR mal angesteuert. Und selbst 
bei 20Mhz (MCU 8080er Databus) sieht man wie er das Bild (Text) aufbaut. 
Demnach wird es jetzt wohl ein ARM.

Wie sollte ich die Temperaturauswertung/anzeige in das Programm 
einarbeiten sodass ich eine gute Button pressed resonanz habe.

Autor: Ralfi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Habt ihr mir da ein paar anregungen.

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ralfi schrieb:
> Also ich hab jetzt mein OLED mit einem AVR mal angesteuert. Und selbst
> bei 20Mhz (MCU 8080er Databus) sieht man wie er das Bild (Text) aufbaut.

Naja, man baut ja auch nicht immer komplette Bilder auf, sondern ändert 
nur einzelne Ziffern.

Welche GLCD-Lib hast Du denn dafür benutzt?


Das EDIPTFT (480*272) hat auch nur nen ATmega1280 drauf und ist schnell 
genug:

http://www.lcd-module.de/produkte/ediptft.html



> Wie sollte ich die Temperaturauswertung/anzeige in das Programm
> einarbeiten sodass ich eine gute Button pressed resonanz habe.

Was meinst Du damit?
Kannst Du das auch in deutsch formulieren?


Grob gesagt hat man mehrere Tasks.
Eine entprellt die Tasten (z.B. im Timerinterrupt).
Eine wird durch nen Timertick angestoßen und macht die Meßwertaufnahme.
Eine zeigt den gewünschten Wert auf dem Display an.
Und eine wertet das Tastenereignis aus und baut dann das dazugehörende 
Menü auf.
Fertig.
Der typische Durchlauf der Mainloop sollte damit wenige ms dauern, bei 
Menüwechsel etwas länger.


Peter

Autor: Ralfi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich habe keine GLIB verwendet ich hab mir da selber ein paar Routinen 
wie Line,Text und sowas gebastellt.
Gibt es vertige GLIBs Open Source für Color Dosplays die auf einem AVR 
(Resourcen sparend) laufen.


In mehreren Tasks also meinst du ich muss mir eine Art "Kernel/OS" 
schreiben.

Ich meinte damit wie ich das strukturieren soll also was ich am besten 
in Main packe, was in Ints, was in Subs (Berechnungen,... hab ich Teils) 
usw..
Was ich halt meine ist das mit den Grafikroutinen nachher das Programm 
nur schlecht auf Menüwechsel reagiert.

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ralfi schrieb:
> Gibt es vertige GLIBs Open Source für Color Dosplays die auf einem AVR
> (Resourcen sparend) laufen.

Such mal unter GLCD, ob LCD oder OLED ist ja egal.


> In mehreren Tasks also meinst du ich muss mir eine Art "Kernel/OS"
> schreiben.

Natürlich nicht.
Es ist kein Problem, in der Mainloop 100 und mehr Tasks hintereinander 
aufzurufen.
Sie müssen bloß so geschrieben sein, daß sie sofort zum Main 
zurückkehren, wenn sie grad nichts zu tun haben oder warten müssen.

Ich habe dazu in der Mainloop nen Timertick für Tasks, die nur nach ner 
Wartezeit aufgerufen werden sollen. Dazu setzt ein Timerinterrupt ein 
Flag, z.B. alle 10ms.
Man kann dazu auch meinen Scheduler aus der Codesammlung nehmen.


> Was ich halt meine ist das mit den Grafikroutinen nachher das Programm
> nur schlecht auf Menüwechsel reagiert.

Warum sollte es?
Das Entprellen macht ein Timerinterrupt, d.h. der Tastendruck kann nicht 
verloren gehen.
Und selbst, wenn ein Menüaufbau 300ms dauern sollte, ist das doch kein 
Beinbruch.
Unter Windows wartet man sogar mal 10s und länger.

Ich habe auf dem vorhin genannten GLCD ein komplexes Menü für ne 
Gerätesteuerung geschrieben (Textausgaben in unterschiedlicher 
Schriftgröße). Man kann nach dem Einschalten gerade noch so erkennen, 
daß ich das Menü von oben nach unten aufbaue.


Peter

Autor: Ralfi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich hab gestern nacht mir mal ein wenig die Finger wund getippt. Nun 
wird in der MAIN der tastendruck an die laufende Task (z.B. zeige_temps) 
weiter gegeben nun dauert das auslesen der adc werte,berechnen der 
temp,und anzeigen der temps aber so lange das man zimlich lange auf den 
Tasten drücken muss um auf die nächsten temperaturen weiter zu schalten, 
sonst schält das programm nicht weiter. das heist doch ich müsste das 
jetzt irgend wie aufdröseln. nur weis ich rigendwie nicht wie ich das 
jetzt so hinpacke das alles sofort reagiert. ich wollte den adc in einen 
timer verschieben aber das hat nicht funktioniert. des ist doch aber 
schon richtig wenn ich das im int mache wie ich es normal machen würde, 
oder?

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ralfi schrieb:
> nur weis ich rigendwie nicht wie ich das
> jetzt so hinpacke das alles sofort reagiert.

Das muß es garnicht. Das einzige, was sofort ne Reaktion zeigen soll, 
ist die Tastenbetätigung.

Die 12 Messungen machst Du einfach nebenbei, z.B. alle 1s eine Messung. 
Schneller als 12s wird sich die Temperatur eh nicht nenneswert ändern.
Der AVR hat genug SRAM, um sich 12 Ergebnisse zu merken.

Und der Tastendruck schaltet einfach nur den Index weiter von dem 
anzuzeigenden Wert.


> ich wollte den adc in einen
> timer verschieben aber das hat nicht funktioniert.

Dann hast Du was falsch gemacht (gern gemacht werden volatile- oder 
atomar-Fehler).
Timerinterrupt geht.
Mainloop geht aber auch (spart Code, braucht kein atomar/volatile).


Peter

Autor: Ralfi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Die Werte Variabeln sind volatile. Was meinst du mit atomar. Der 
Timerinterrupt geht.

Autor: M. R. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Was meinst du mit atomar.

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert

Autor: Ralfi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich muss dir an dieser stelle zwischen drin einfach mal danken peter 
deine hilfe ist echt klasse.

Autor: Ralfi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
So, ich habe dieses Wochenende einmal intensiv dazu genutzt an dem 
Programm zu arbeiten.
Dabei bin ich zu dem Ergebnis gekommen das ein AVR zu langsam ist. Um 
z.B. das Bild am Anfang zu Löschen (schwarzer Hintergrund erstellen) 
brauch es bei 16MHz schon ziemlich lange (4sec). Auch das Schreiben 
eines Textes ist doch deutlich sichtbar.

Deshal werde ich an dieser stelle denke ich auf ARM (LPC2148) umsteigen.

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Du solltest erstmal feststellen, wo überhaupt der Flaschenhals liegt, 
sonst wird Dir der 32Bitter 0,nix bringen.

Selbst, wenn Du jeden Pixel für jede Farbe einzeln setzt, hast Du bei:

16MHz * 4s  3  240 / 320 = 277 Befehle pro Pixel verbraten.

Und das ist viel zu viel.

Zeig dochmal Dein Programm.
Manchmal schafft es der Compiler nicht, alle konstanten Ausdrücke 
außerhalb der Schleife zu legen, dann sollte man das selber machen.

Oder vielleicht hast Du die Fuses nicht auf extern gesetzt oder den 
Prescaler /8 nicht abgeschaltet oder die Compileroptimierung nicht auf 
-Os gesetzt oder ...

Ich kann mir nicht vorstellen, daß Dein OLED komplizierter ist, als das 
oben erwähnte größere TFT mit ATmega1280 von ELECTRONIC ASSEMBLY.


Peter

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hier noch ein Anbieter für TFT mit ATmega:

http://www.shop.display3000.com/mikrocontrollermod...


Peter

Autor: Ralfi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Der Flaschenhals liegt im Beschreiben des OLED. Das schreiben einer 
Zeichenkette z.B. der Bezeichnung des Temperatursensors dauert viel zu 
lange.

Und wie gesagt am Anfang enthält das Display nur Farbrauschen nach dem 
Init (was normal ist) um z.B. nun das OLED mit meinem Hintergrund 
(Schwarz) zu beschreiben braucht es ca 4s. Auch wenn ich nur die vier 
Bezeichnungen für die Temperaturen schreibe ist das doch deutlich 
sichtbar. Ich hätte es halt gerne so das wenn eine Schrift oder 
dergleichen auf das Display geschrieben wird das nicht sichbar ist. 
Deshalb denke ich mit einer höheren Schreibrate auf das Display = 
höherer Takt wäre diese Problem gelöst.
Hier mal ein Beispiel das mir gerade in die Hände gefallen ist:
http://www.atmel.com/Atmel/video-sam3u-ek.html
Hier ist zwar auch einwenig der Bildaufbau sichtbar aber nur minimal.

Die Optimierung ist auf -Os (verwende ich i.d.R. immer).

Wird diese oben erwähnte Display direkt vom Atmega gesteuert oder hockt 
da noch was zwischen Atmega und LCD. Weil von der Auflösung her ist das 
Ding ja wesentlich größer, mein OLED hat ja nur 320*240 Pixel.

Desweiteren wollte ich dich noch nach etwas Theorie (PDF,Bücher,...) 
hinsichtlich meinem Projekts Fragen.


PS: Das ist flüssig (aber auch klein)
Youtube-Video "PIC micro with color LCD"

Autor: Ralfi (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Die Fonts sind in einem 8Byte Array organisiert.

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Welchen AVR benutzt Du denn?

Die Zugriffe per Bitbefehle sind sehr aufwendig, jeder Bitbefehl braucht 
2 Zyklen.

Du solltest das OLED besser Memory mapped anschließen, dann dauert der 
komplette OLED-Zugriff nur 2 Zyklen.

Das können aber nur die größeren AVRs im 64-pol Gehäuse (z.B. 
ATmega1281).
Der ATmega162 kann das zwar auch, aber nur 16kB Flash könnte für die 
Bitmaps zu knapp werden.

Auch sollten die untersten Zugriffsfunktionen als Inline deklariert 
sein, um den CALL/RET Overhead zu sparen.


Peter

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
P.S.:
Port J ist ja besonders ungünstig, da er nicht bitadressierbar ist, 
jeder Bitzugriff dauert dann sogar 5 Zyklen.

Memory-mapped dürfte etwa 10-fachen Geschwindigkeitszuwachs ergeben.

Ein Adreßlatch braucht man nicht, nimm einfach nur die höherwertigen 
Adressen (A15..8) zur Auswahl.


Der ARM-7 ist auch nicht so der Bitschieber, braucht 6 Takte, ist aber 
durch die 60MHz etwas schneller.


Peter

Autor: Ralfi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ok, ich habe die unteren Funktionen als Inline deklariert.

Nun Memory mapped heißt wenn ich das richtig verstehe das OLED an das 
External Memory Interface anzuschließen?
Wie genau würde das dann Funktionieren?

PortJ ist nicht bitadressierbar! Warum das denn?

Wie hätte ich das anstatt mit Bitbefehlen anderst/besser lösen können?

mfg

Autor: Ralfi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hast du mir zu Thema "External Memory Interface -> OLED". Ich finde 
nämlich nicht wirklich Beispiele,etc. über das External Memory 
Interface.

Autor: MaWin (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> mein OLED hat ja nur 320*240 Pixel

Also das Schreiben von 320x240 braucht schon etwas Zeit,
da aber dein Dispaly einen eigenen Display-Buffer hat,
hast du keinerlei Problem.

Vergleiche einen ATmega mit OLED mit einem Apple ][ mit
6502, dessen Bildschirk auch per Hardware refresht wird.

Man musst beim Aplle schon nachdenken beim Code-schreiben
und manches in Assembler implementieren, aber das war
kein Hinderungsgrund blinkende und animiserte Spiele
darauf laufen zu lassen.

Man wird doch heute nicht blöder sein, als vor 30 Jahren....

Wenn ich deine Rechteck und Zeichen-Schreibfunktionen sehe,
die letztlich jeden Pixel einzeln setzt,
dann geht das bei vorhandenem Graphik-Controller sicher
schneller, so dass auch ein clear-screen blitzartig wird.

Irgendwie vermisse ich aber eine Controller Beschreibung in
http://www.datamodul.com/us/page/popup_pages/OLED/...
daher kann cih dazu nichts sagen.

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ralfi schrieb:
> Hast du mir zu Thema "External Memory Interface -> OLED". Ich finde
> nämlich nicht wirklich Beispiele,etc. über das External Memory
> Interface.

Der Anschluß erfolgt nach Datenblatt, Figure 9-2. External SRAM 
Connected to the AVR.
Nach Deinen Pindefinitionen müßte das gehen.
Ich hab ja kein Datenblatt zu Deinem OLED.

Und dann eben die Register setzen, um das Interface einzuschalten. Dann 
kannst Du direkt (char-Pointer) aus das OLED zugreifen, wie auf ne 
Variable.


Peter

Autor: Ralfi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@MaWin:

Apple mit 6502. Was meinst du genau. Komme nicht mit.

Wie meinst du schneller. Es wäre nett wenn du mir dabei hilfst, wenn du 
das hier schon so in die Runde wirfst.

Wenns nur am Controller leigt das hab ich dir: (@Google, 1.Link)
http://www.4dsystems.com.au/downloads/Displays/OLE...

@Peter:

Nach Datenblatt. Hierbei benötige ich aber ja kein Adress Latch. Dann 
nehme ich einfach AD0:7, ALE, RD, WR schliesse das an das OLED und 
setzte die Register (XMEM).
Nur wie meinst du das mit der Variabele?

mfg

Autor: Ralfi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich hab jetzt schon einmal angefangen an dem XMEM Interface zu 
schreiben. Das Init habe ich soweit denke ich hinbekommen also enablen 
und no wait state.
Was ich jetzt glaube auch weis ist das ich mit A0-Ax meine Daten anlege 
und die Controlsinganel (CS,WRB,RDB) (nicht ALE,usw. ,oder?). Nur wie 
"steuere" ich jetzt die Signale die zu OLED übertragen werden so an das 
ich:
1. Daten anlege
2. Signal zu übernehmen und CS "sende"
3. Ende der Übertragung (deselect CS,...)

mfg

Autor: Ralfi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ah, du meinst den Apple 2,stimmts?

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.