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
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
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.
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ß
> 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).
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.....
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)
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
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.
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
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.
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
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?
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
Die Werte Variabeln sind volatile. Was meinst du mit atomar. Der Timerinterrupt geht.
http://www.avrfreaks.net/index.php?name=PNphpBB2&file=viewtopic&t=55347 http://www.mikrocontroller.net/articles/AVR-GCC-Tutorial#Variablen_gr.C3.B6.C3.9Fer_1_Byte Peter
Ich muss dir an dieser stelle zwischen drin einfach mal danken peter deine hilfe ist echt klasse.
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.
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
Hier noch ein Anbieter für TFT mit ATmega: http://www.shop.display3000.com/mikrocontrollermodule/index.html Peter
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) http://www.youtube.com/watch?v=foWnDZ3eQto&feature=related
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
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
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
Hast du mir zu Thema "External Memory Interface -> OLED". Ich finde nämlich nicht wirklich Beispiele,etc. über das External Memory Interface.
> 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/2.8%20AMOLED_CMEL%20C0283QGLD-T_preliminary.pdf daher kann cih dazu nichts sagen.
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
@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/OLED/AMOLED/Data/S6E63D6X_REV1.10.pdf @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
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
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.