Hallo, seit gut 18 Jahren programmiere ich nun die ATMEL 8 Biter, angefangen beim AT2313 bis heute zum ATmega2560. Bei meinem neuen Projekt soll ein 7" Touch Display eingesetzt werden. Die CPU ist derzeit ein ATmega 2560 mit 16 MHz. Sollte die Ausgabegeschwindigkeit zu langsam sein, welche CPU wäre denn ein sinnvoller Nachfolger, wenn ich die Umgebung ATMEL Studio und mein JTAG MK II weiter nutzen möchte? Gruß AVRli...
Nenne doch mal mehr Anforderungen, was der Controller sonst so tun soll. Die Größe des Displays ist ziemlich irrelevant; wichtig wäre die Auflösung und das Protokoll zur Ansteuerung.
ATXmega, die haben doppelte Taktfrequenz und ggf. DMA. Aber so ganz sinnvoll ist das auch nicht unbedingt, bestenfalls, wenn das Display viel Eigenintelligenz hat und dein AVR nicht allzuviel leisten muß.
Kim P. schrieb: > was spricht gegen den XMega? Was spricht gegen das Reiten von toten Pferden? Die Liste ist ähnlich.
"Nenne doch mal mehr Anforderungen" Wozu? Er braucht was leistungsfähigeres und will das Atmel Equipement weiter nutze. Die Frage ist doch recht eindeutig. Entweder ein schnellen Mega..da bin ich gerade nicht auf dem laufenden, aber dann eben gleich XMEGA, die sind super und er kann alles weiter nutzen und muss sich nicht groß umgewöhnen. Ansonsten natürlich STM32..aber die schiden aus wenn amn sich nicht komplett umgewöhnen will und erst recht wenn man das Atmestudio etc beibehalten will
@ Cyblord O Du hast die Frage verstanden x ich bin nicht aufmerksam und gehe nicht auf die eigentlich Frage ein, laber aber gerne rum
Kim P. schrieb: > Wozu? Insbesondere um einen Controller mit entsprechendem LCD-Interface zu wählen. Handelt es sich um ein "nacktes" LCD mit Parallel-RGB-Display wird ein Controller gebraucht welcher dieses Signal erzeugen kann. Einige STM32 können das; auf dem STM32F429-Discovery und dem STM32F746-Discovery ist das schon fertig aufgebaut. Ist aber kein 7". Das Waveshare Board kommt mit 7"-Display: https://www.amazon.de/dp/B00MJOCU2Q Aber nicht ganz billig. Interessant wären auch die Anforderungen bzgl. Echtzeit und sonstigen Interfaces. Wenn die nicht allzu hoch sind wäre ein R-PI mit zugehörigem Display eine Option. Der hat auch genug Leistung für anspruchsvolle GUIs.
Kim P. schrieb: > @ Cyblord > O Du hast die Frage verstanden > x ich bin nicht aufmerksam und gehe nicht auf die eigentlich Frage ein, > laber aber gerne rum Du kannst dir deine XMega so lange schön reden wie du willst, und auch gerne weiter rumzicken wie ein kleines Mädchen. Das ändert aber nichts an den Tatsachen.
schön das Du sachlich arguementierst..Deine Vorschläge gefallen mir gut. Viele andere sagen labern immer nur rum..sagen das alles doof ist und quatsch..Du dagegen argumentierst mit Hand und Fuss, daumen nach oben dafür von mir. TOP In diesem Forum gibt es so gut wie niemanden, der so viel zu Themen beiträgt wie Du Kompliment
Der µC soll einige Eingänge überwachen, PWM auf 4 Ausgängen per HArdware erzeugen, Pin Change Interrupts auf 4 Eingängen bieten. Min. 10 ADC Kanäle mit min. 11 Bit Auflösung bei 5V. Alles Sachen die nicht sooo aufregend sind. Das Display hat eine Auflösung von 800x480 und wird 16Bit parralel angesteuert. Derzeit habe ich ein 480x320 Pixel Display an einem ATmega 2560. Die Ausgabe funktioniert soweit flüssig ABER wenn ich die Ansichten komplett umschalte, merkt man das schon. Das dauert etwas... Eigene Intelligenz haben diese Display-Controller nicht. Es gibt die 7" Displays mit dem SSD1963 Chip oder dem MD070SD. Der MD070SD bietet wohl speicher für 8 Ansichten, welche auch mit einem Kommando umgeschalten werden können.
"Einige STM32" sidn aber kein AVR und untersützen weder das MK2 noch das Atmelstudio. Dann bliebe eher der ATSAM..nur auch da geh das MK2 nicht mehr Also bliebe nur der gesamt Umsteig aus STm32 und Atolic True Studio
Kim P. schrieb: > Ansonsten natürlich STM32..aber die schiden aus wenn amn sich nicht > komplett umgewöhnen will und erst recht wenn man das Atmestudio etc > beibehalten will Dafür steht ihm aber die komplette Palette an Atmel, ähem, Verzeihung, Microchip ARMs offen. Einzig das JTAGICEmkII tut's dann nicht mehr, das wäre mit den Xmegas in der Tat am Ende der Fahnenstange angelangt. Entweder ablösen durch ein AtmelICE (könnte man auch als nacktes PCB kaufen, wenn man sich das Gefummel mit den Anschlüssen selbst antun wöllte). Alternativ könnte man ein SAMD10 Xplained Mini kaufen und sehen, ob man das zum externen Programmer für andere SAMDs umfunktionieren kann. ST sind ja beileibe nicht die einzigen, die ARMs herstellen.
Kim P. schrieb: > schön das Du sachlich arguementierst.. Du kommst mir in der Tat vor wie jemand der noch versucht sachlich zu argumentieren und fleißig mit Verbesserungsvorschlägen aufwartet, wenn er jemanden sieht der versucht ein totes Pferd zu reiten. Ja so ein Typ bist du. Ich hingegen sage halt was Sache ist. > In diesem Forum gibt es so gut wie niemanden, der so viel zu Themen > beiträgt wie Du Genau aus diesem Grund. Manchmal muss man Klartext reden. Irgendwann kapiert auch mal ein Spaten was los ist. Mit Geschwurbel klappt das nie.
:
Bearbeitet durch User
AVRli .. schrieb: > Hallo, > > seit gut 18 Jahren programmiere ich nun die ATMEL 8 Biter, angefangen > beim AT2313 bis heute zum ATmega2560. > > Bei meinem neuen Projekt soll ein 7" Touch Display eingesetzt werden. > Die CPU ist derzeit ein ATmega 2560 mit 16 MHz. Bei üblichen Displayauflösungen ist das schon ziemlich sportlich. > Sollte die Ausgabegeschwindigkeit zu langsam sein, welche CPU wäre denn > ein sinnvoller Nachfolger, wenn ich die Umgebung ATMEL Studio und mein > JTAG MK II weiter nutzen möchte? Wenn ich von üblichen 800x480 Pixeln ausgehe, dann sind das für 60Hz bereits über 23MHz(!) Pixeltakt, d.h. selbst ein xmega wird da auch mit DMA schon ziemlich dicke Backen machen. An eine hohe Farbauflösung (24-Bit RGB) ist schon gar nicht zu denken. Wenn Du bei AVR bleiben willst (STM32F429 etc. wurden ja schon genannt), dann führt wohl kein Weg an einem externen Grafikkontroller vorbei (bspw. SSD1963). Dessen RAM kannst Du dann "in Ruhe" beschreiben und er erledigt den Rest der Displayansteuerung für Dich. Es gibt dafür auch schon fertige 7"-Module. Dank Smartphones dürfte es auch noch deutlich leistungsfähigere Controller mit 2D-Fähigkeiten geben. Edit: hat sich überschnitten :-)
:
Bearbeitet durch Moderator
Cyblord -. schrieb: > Manchmal muss man Klartext reden. Konstruktive Vorschläge sehen dennoch anders aus als das, was du bislang in diesem Thread von dir gegeben hast. Du hast nämlich lediglich genannt, was deiner Meinung nach nicht funktionieren würde, und selbst das komplett begründungslos.
Jörg W. schrieb: > Cyblord -. schrieb: >> Manchmal muss man Klartext reden. > > Konstruktive Vorschläge sehen dennoch anders aus als das, was du bislang > in diesem Thread von dir gegeben hast. Du hast nämlich lediglich > genannt, was deiner Meinung nach nicht funktionieren würde, und selbst > das komplett begründungslos. Umstieg auf ARM ist natürlich obligatorisch. STM32 wurde hier bereits mehrfach genannt. Ich muss nicht nochmal dasselbe schreiben wie alle anderen.
AVRli .. schrieb: > Eigene Intelligenz haben diese Display-Controller nicht. Es hat einen SRAM und erzeugt das LCD-Signal selbst. Also durchaus Intelligenz. AVRli .. schrieb: > Sollte die Ausgabegeschwindigkeit zu langsam sein, welche CPU wäre denn > ein sinnvoller Nachfolger, wenn ich die Umgebung ATMEL Studio und mein > JTAG MK II weiter nutzen möchte? Wenn das eine harte Anforderung ist, ist die Antwort eigentlich klar - es gehen nur Xmega, AVR32 und AVR. Wenn es auch ein anderer Debugger sein darf, kämen die Atmel Cortex-M Controller (ATSAMx) in Frage. Wenn es auch eine andere IDE sein darf, kommt alles in Frage. JTAG-Debugger sind nicht teuer und viele IDEs gratis; daher kann man sich diese Anforderung noch mal überlegen. AVRli .. schrieb: > Das dauert etwas... Für echt flüssige GUIs musst du den intelligenten Controller (alles was eigenen RAM hat) weglassen und das Signal direkt durch Controller-Hardware erzeugen lassen. Von den AVR's kann das m.W. keiner. Auf die Schnelle hab ich auch keinen anderen Atmel-Controller mit LCD-Interface gefunden. Daher wird das mit den gewünschten Anforderungen schwierig. Daher wie gesagt z.B. STM32, da haben das manche. Viele Boards haben auch den Debugger direkt inklusive.
:
Bearbeitet durch User
Cyblord -. schrieb: > Ich hingegen sage halt was Sache ist. Nö, du hast in dem ganzen Thread nicht ein sachliches Wort fallen lassen. Du darfst mich gerne des Irrtums überführen, zeig mir wo du sochlich für eine Prozessorfamilie argumentiert hast oder auh nur ein Prozessor/Familienname genannt hast.
Der Andere schrieb: > Du darfst mich gerne des Irrtums überführen, zeig mir wo du sochlich für > eine Prozessorfamilie argumentiert hast oder auh nur ein > Prozessor/Familienname genannt hast. Immerhin hat er sich indirekt dafür ausgesprochen, lebendige Pferde zu reiten. Ich empfinde das durchaus als hilfreich.
STM32 ist der Beste überhaupt, weil er von ARM ist. Das ist Standart, darum ist alles Andere total schlecht.
Also das Display hat entweder ein SSD1963 oder ein MD070SD Controller On Board. Die möchte ich schon einsetzen und mir war nicht bewusst das es schon als intelligent gilt. Richtig ist, dass man diesen Cotroller sagt was er machen soll und der dann das Display entsprechend ansteuert.
AVRli .. schrieb: > Die möchte ich schon einsetzen und mir war nicht bewusst das es > schon als intelligent gilt. Dann musst du immer mit etwas Latenz bei der Anzeige rechnen. Dann schau dir die ATSAM-Controller an, die gehen mit Atmel Studio, brauchen aber einen anderen JTAG-Debugger. Achte darauf, einen mit genug RAM für die Anzeige zu nehmen.
STM32Fanboy schrieb: > Das ist Standart, > darum ist alles Andere total schlecht. Plakative Behauptungen mit einem dicken Rechtschreibfehler sind wenig überzeugend.
Cyblord -. schrieb: > Umstieg auf ARM ist natürlich obligatorisch. STM32 wurde hier bereits > mehrfach genannt. Ich muss nicht nochmal dasselbe schreiben wie alle > anderen. Warum musst Du dann überhaupt schreiben?
Framulestigo schrieb: > Cyblord -. schrieb: >> Umstieg auf ARM ist natürlich obligatorisch. STM32 wurde hier bereits >> mehrfach genannt. Ich muss nicht nochmal dasselbe schreiben wie alle >> anderen. > > Warum musst Du dann überhaupt schreiben? Unsinnige Frage. Nur weil man nicht genau das schreibt, was alle anderen schreiben sollte man gar nichts schreiben? Was ist das für eine kausale Kette? Ordne mal deine Gedanken bevor du mit mir kommunizierst.
Framulestigo schrieb: > Cyblord -. schrieb: >> Umstieg auf ARM ist natürlich obligatorisch. STM32 wurde hier bereits >> mehrfach genannt. Ich muss nicht nochmal dasselbe schreiben wie alle >> anderen. > > Warum musst Du dann überhaupt schreiben? https://de.wikipedia.org/wiki/Persiflage Es ging hier um ATMEGA, lesen tut man "STM32 ist toll". "Woran erkennt man, dass jemand ein STM32-Fanboy ist?" ... ... ... "er wird es dir schon sagen".
AVRli .. schrieb: > Also das Display hat entweder ein SSD1963 oder ein MD070SD Controller On > Board. Die möchte ich schon einsetzen und mir war nicht bewusst das es > schon als intelligent gilt. Die sind auch nicht intelligent. Die schaufeln lediglich die Bilddaten aus dem internen RAM zur Anzeige. Folglich brauchst Du einen schnellen µC, der zum einen ein schnelles Interface für einen 16 Bit Datenbus und zum anderen hohe Rechenleistung hat, damit Schrift und Grafik zügig erzeugt werden können. Eine 5 x 8 Schrift würde zwar noch schnell angezeigt werden, nur wird sie viel zu klein geraten, um lesbar zu sein. Folglich ist das nichts mehr für AVR8. Such Dir einen 32 Bit µC aus: PIC, RX, ARM M3/M4/M7 (NXP, STM, o.ä.), wobei die Taktfrequenz >= 100 MHz liegen sollte. AVRli .. schrieb: > ein MD070SD Controller Davon scheint es kein aussagekräftiges Datenblatt geben. Die 7" Module, die damit angeboten werden, erscheinen mir Auslaufmodelle zu sein ("sale").
AVRli .. schrieb: > bei 5V ATSAMC21 Kein AVR, aber immerhin vom gleichen Hersteller -> Atmel Studio Nur wie weiter oben schon erwähnt, ein Atmel ICE braucht es dann schon, zumindest solange Microchip mit dem MPLAB-X und dem SNAP nicht weiter ist. > Das Display hat eine Auflösung von 800x480 und wird 16Bit parralel > angesteuert. Autsch. Mit einem Display-Controller ist das so viel einfacher. Ob nun integriert in einem deutlich dickeren Controller, oder extern. Und es gibt inzwischen mehrere da draussen unter denen man wählen kann, ich beschäftige mich mit den EVE von FDTI/BRT. Das hier ist ein 7", 800x480 von einem AT90CAN angesteuert: https://www.mikrocontroller.net/attachment/preview/324090.jpg Das ist ein EVE2, genauer ein FT813 in dem Display. Beitrag "FT800 / FT810 Library" Hier noch ein Bild von einem EVE2-35G Modul mit AT90CAN Platine daneben: https://www.mikrocontroller.net/attachment/363141/EVE2-35G_EVE2-38_FT813.JPG Die 595µs im Bild sind die Zeit die Daten für ein Bild aufzubereiten und die 232 Bytes per 8MHz SPI an das Display zu schicken. Für eine richtige Oberfläche mit mehreren Bildern, Rahmen, Tastern und so weiter bin ich gerade bei 1,7ms angekommen. Allerdings auf dem SAMC21 mit dem SPI auf 12MHz. Und um den Touch kümmert sich EVE auch noch, statt nur Koordinaten bekommt man die Information, welche Objekt-Gruppe berührt wurde.
> Min. 10 ADC Kanäle mit min. 11 Bit Auflösung bei 5V.
Schlecht und schon verloren. Der ATMega kommt über 10 Bit nicht hinaus.
Ben B. schrieb: >> Min. 10 ADC Kanäle mit min. 11 Bit Auflösung bei 5V. > Schlecht und schon verloren. Der ATMega kommt über 10 Bit nicht hinaus. Da nimmt man doch sowieso externe ADCs.
Cyblord -. schrieb: > Unsinnige Frage. Nur weil man nicht genau das schreibt, was alle anderen > schreiben sollte man gar nichts schreiben? Was ist das für eine kausale > Kette? Ordne mal deine Gedanken bevor du mit mir kommunizierst. In deinem ersten Beitrag hast du allerdings von toten Pferden geschrieben. Du hast demzufolge vorausgesehen, daß von anderen noch etwas Sinnvolles kommt. Respekt.
Cyblord -. schrieb: > Unsinnige Frage. Nur weil man nicht genau das schreibt, was alle anderen > schreiben sollte man gar nichts schreiben? Was ist das für eine kausale > Kette? Ordne mal deine Gedanken bevor du mit mir kommunizierst. Bla bla. Bemüh mal die Forensuche. Seit mindestens acht Jahren zerreißt sich dieses Forum das Maul über Sinn und Unsinn der XMega-Reihe. Dein Beitrag: Unausgegorenes Nachplappern von Meinungen. Einziger Fakt: Es gibt sie immer noch. Da ist nix schreiben definitiv besser.
AVRli .. schrieb: > wenn ich die Umgebung ATMEL Studio und mein > JTAG MK II weiter nutzen möchte? Da würde ich zuerst in die Kompatibilitätsliste des JTAG MK II schauen. Ich glaube, der kann nur klassische AVRs mit ISP oder JTAG, keine XMEGAs, keine ARM.
Detlev T. schrieb: > Da würde ich zuerst in die Kompatibilitätsliste des JTAG MK II schauen. > Ich glaube, der kann nur klassische AVRs mit ISP oder JTAG, keine > XMEGAs, keine ARM. Ab Hardware revision B kann er auch ATxmega mit PDI. Mehr aber wirklich nicht. STM32Fanboy schrieb: > STM32 ist der Beste überhaupt, weil er von ARM ist. Ist er natürlich nicht – aber was soll man von jemanden mit diesem Pseudonym schon an Korrektheit erwarten … Die Zeiten, da Acorn noch selbst Chips produzieren lassen hat, sind schon eine Weile vorbei.
AVRli .. schrieb: > Sollte die Ausgabegeschwindigkeit zu langsam sein Wieso sollte sie? Der 2560@16MHz schafft eine Busbandbreite von ca. 5MBytes/s. D.h.: selbst ein kompletter Ersatz des Displayinhalts würde bei einem 800x480-Display mit z.B. 16 Farben nur ca. 40ms dauern. Das entspricht der Framerate von PAL-Video... Und außerdem: wann muss für eine typische µC-Anwendung schon der komplette Screeninhalt erneuert werden? Das ist doch eher selten. Es sei denn, man baut damit ein Terminal und läßt das dann scanlineweise scrollen. Dann sollte man halt auch ein Terminal nehmen und keine Vollgrafik...
> 800x480-Display mit z.B. 16 Farben
Das sind 192kByte Bilddaten.
Da bin ich sehr gespannt, wo die herkommen sollen.
Beitrag #5732371 wurde von einem Moderator gelöscht.
Ben B. schrieb: >> 800x480-Display mit z.B. 16 Farben > Das sind 192kByte Bilddaten. > Da bin ich sehr gespannt, wo die herkommen sollen. Das kann uns wohl nur der TO sagen...
Beitrag #5732380 wurde von einem Moderator gelöscht.
Ein STMnucleo kostet keine 10€ und ist ein brauchbarer JTAG-Adapter inklusive Evalboard. Ob man nun AVR mag oder ARM oder nicht. Ich hab mich auch lange gewehrt und mit ATmegas und xmegas weitergemacht, aber letztlich bleibt gegen einen kleinen STM32F1 kaum was an Argumenten übrig. Der STM ist schon in kleinen Stückzahlen oft billiger als ein AVR in ähnlicher Ausstattung. Und das Debugging mit der ITM möchte ich auch nicht mehr missen. Aber was ich überhaupt nicht verstehe, ist, dass jemand ernsthaft das Atmel-Studio als Argument aufbringt. Ich habe selten mit einer rotzigeren IDE gearbeitet, als mit VisualStudio. Abgesehen von fast 800MB Arbeitsspeicherverbrauch im Leerlauf(!) ist am AtmelStudio echt alles Müll.
> Abgesehen von fast 800MB Arbeitsspeicherverbrauch im Leerlauf(!) Voll das schlagende Argument, wenn schon mein Laptop 16GB RAM hat ... Ich komme mit dem AVR-Studio jedenfalls gut zurecht.
Beitrag #5732450 wurde von einem Moderator gelöscht.
c-hater schrieb: > AVRli .. schrieb: > >> Sollte die Ausgabegeschwindigkeit zu langsam sein > > Wieso sollte sie? Der 2560@16MHz schafft eine Busbandbreite von ca. > 5MBytes/s. D.h.: selbst ein kompletter Ersatz des Displayinhalts würde > bei einem 800x480-Display mit z.B. 16 Farben nur ca. 40ms dauern. Heute ist doch weder Freitag noch der 1. April? Dann kann diese Rechnung ja nur bösartig gemeint sein. Wenn man mal ein bisschen Text auf Grafik Displays geschrieben hat, dann weiß man, daß das Setzen eines Punktes nur ein einziger Befehl ist. Um aber die richtige Adresse zu treffen, wo der Punkt landen soll, kommen noch einmal 30 - 50 Befehle dazu: bei einem AVR noch viel mehr, da er in einer Welt jenseits von 256 bzw. 65536 möglichen Adressen völlig verloren ist. Da ich davon ausgehe, daß das Display nicht nur ständig mit farbigen Flächen gefüllt werden soll, schlage ich den Faktor 50 - 100 vor, um obige Zeitangabe auf einen realen Wert zu bringen.
Ben B. schrieb: >> Abgesehen von fast 800MB Arbeitsspeicherverbrauch im Leerlauf(!) > Voll das schlagende Argument, wenn schon mein Laptop 16GB RAM hat ... Jo klar. Und das wiederum ist voll das schlagende Argument dafür, Bloatware noch weiter aufzublasen.
m.n. schrieb: > Wenn man mal ein bisschen Text auf Grafik Displays geschrieben hat, dann > weiß man, daß das Setzen eines Punktes nur ein einziger Befehl ist. Um > aber die richtige Adresse zu treffen, wo der Punkt landen soll, kommen > noch einmal 30 - 50 Befehle dazu: bei einem AVR noch viel mehr, da er in > einer Welt jenseits von 256 bzw. 65536 möglichen Adressen völlig > verloren ist. Hmm, wenn die Bilanz bei dir wirklich derart Scheiße ist, dann bist du schlicht ein völlig unfähiger Programmierer. Nur zur Erinnerung: die Homecomputer der späten 80er hatten auch nur 8Bitter, auch nur ein paar Dutzend k Ram, mussten auch mit Bankswitching klarkommen, haben aber trotzdem teils recht faszinierende animierte Grafik in Echtzeit hinbekommen. Es gibt keinen technischen Grund, der es einem (viel schnelleren) AVR8 verbieten würde, heute dasselbe zu leisten. Nur völlig unfähige Programmierer könnten das effektiv verhindern. Leute wie du halt...
Ben B. schrieb: > Voll das schlagende Argument, wenn schon mein Laptop 16GB RAM hat Es ist mehr eine Frage der Geschwindigkeit. Große Programme neigen dazu, langsam zu sein. Das Atmel Studio ist so eins.
> Jo klar. Und das wiederum ist voll das schlagende Argument dafür, > Bloatware noch weiter aufzublasen. Nö, das ist nur das schlagende Argument dafür, daß ich mich um solche Details nicht kümmere solange das Ding zufriedenstellend funktioniert.
>> Jo klar. Und das wiederum ist voll das schlagende Argument dafür, >> Bloatware noch weiter aufzublasen. Ben B. schrieb: > Nö, das ist nur das schlagende Argument dafür, daß ich mich um solche > Details nicht kümmere solange das Ding zufriedenstellend funktioniert. Vernünftig. Ich war jedenfalls nicht zufrieden. Mein Dual-Core Laptop mit 2,2GHz und 8GB war damit überfordert. Das Programm lief unerträglich langsam. Auf dem neuen Laptop mit Core i7 mit 4/8 Kernen geht es so gerade eben.
Versteh ich ehrlich gesagt nicht. Das hier ist auch nur ein i7-2670qm und ich habe keine Probleme mit der Geschwindigkeit. Um welchen Teil des AVR-Studios geht es Dir, wo Du mit der Geschwindigkeit unzufrieden bist?
Ben B. schrieb: > Versteh ich ehrlich gesagt nicht. Das hier ist auch nur ein > i7-2670qm > und ich habe keine Probleme mit der Geschwindigkeit. Um welchen Teil des > AVR-Studios geht es Dir, wo Du mit der Geschwindigkeit unzufrieden bist? Mit dem AVR Studio komme ich gut klar. Das Atmel Studio ist lahm. > Um welchen Teil ... geht es Dir? Alles. Fängt schon beim Start an, und beim Tippen bin ich zeitweise schneller, als der (alte) Rechner mit kommt.
Okay sorry dann habe ich das falsch verstanden. Ich dachte es geht um das AVR-Studio, wenn es da noch ein Atmel-Studio gibt, verwende ich das nicht.
Ben B. schrieb: >> Jo klar. Und das wiederum ist voll das schlagende Argument dafür, >> Bloatware noch weiter aufzublasen. > Nö, das ist nur das schlagende Argument dafür, daß ich mich um solche > Details nicht kümmere solange das Ding zufriedenstellend funktioniert. Das tun leider viele. Und wenn sich mal zwei treffen, dann knallts. Darum kann ja heute auch kaum mehr jemand "richtig" programmieren(tm), wenn man das mal so überspitzt darstellen darf. Das "pad left"-Drama finde ich da ganz repräsentativ[1]. Auch wenn ich den STM32, wie ich oben ja schrieb, dem AVR aus vielen Gründen vorziehen würde, muss ich ja trotzdem nicht mit dessen Ressourcen arg verschwenderisch umgehen. [1] https://www.davidhaney.io/npm-left-pad-have-we-forgotten-how-to-program/
Ich danke für alle konstruktiven Antworten! Wie schon geschrieben wurde, wird natürlich nicht immer der gesamte Bildschirminhalt aktualisiert. Bei der Umschaltung der Ansicht natürlich schon. Wenn die Ansicht dann gezeichnet ist, sind es nur noch die Bereiche, welche auch Änderungen enthalten. Es sind Teilbereiche. Derzeit liegt die Ausgabegeschwindigkeit bei den Werten mit einer Bargraph- Anzeige bei 8ms. Vielleicht habe ich einfach etwas zu viel Panik und das ganze hält sich auch bei dem größeren Display noch in Grenzen.
AVRli .. schrieb: > Derzeit liegt die Ausgabegeschwindigkeit bei den Werten mit einer > Bargraph- Anzeige bei 8ms. Dafür braucht man ein 7" TFT? > Vielleicht habe ich einfach etwas zu viel Panik und das ganze hält sich > auch bei dem größeren Display noch in Grenzen. Du kannst Dir ja einen Treiber für AVR schreiben und dann sehen, welche Zeit bei 800 x 480 Bildpunkten benötigt wird: 1. für das Löschen des Bildes 2. Zeichnen von Buchstaben im lesbaren Format (z.B. 16 x 32) 3. Textausgabe als Terminal inkl. 'scrolling', wenn die unterste Zeile vollgeschrieben ist. Welche Farbtiefe willst Du denn verwenden? 16 Bit? Dann sorge für zwei freie Ports, damit die Daten auch parallel ausgegeben werden können. Wenn Du ein guter Programmierer bist, schaffst Du auch locker die vorgegebenen 5 MB/s. Und nicht vergessen, zu jedem Bildpunkt zuvor die Zeile und die Spalte auszugeben. Vielleicht wird Dir dann klar, was an Prozessorleistung benötigt wird.
m.n. schrieb: > Dafür braucht man ein 7" TFT? Ja! Wenn man nicht mehr richtig sehen kann, muss alles etwas größer ausfallen. m.n. schrieb: > Welche Farbtiefe willst Du denn verwenden? 16 Bit? Ja dieses 5-5-6 Format. Zwei freie Ports nur für das Display sind vorhanden. m.n. schrieb: > Du kannst Dir ja einen Treiber für AVR schreiben und dann sehen, welche > Zeit bei 800 x 480 Bildpunkten benötigt wird: Ich glaube das ist der richtige Ansatz! Das werde ich beherzigen und dann sehen ob ich mich habe von einen "Leistungswahn" habe verrückt machen lassen oder ob ich wirklich mehr LEistung benötige. m.n. schrieb: > Und nicht vergessen, zu jedem Bildpunkt zuvor die > Zeile und die Spalte auszugeben. Hmm, beide favorisierten Chips haben wenigstens ein Auto- Inkrement, damit sollte ich hier einen Geschwindigkeitsvorteil haben, weil die Position-Information nicht bei jeder Pixelausgabe benötigt wird. Ich organisiere mir mal so ein 7" Display um genaueres sagen zu können. Gruß AVRli...
Ein 7" Display direkt mit einem AVR ansteuern zu wollen ist natürlich völliger Quatsch. Vielleicht kriegt man es hin, dass da mal ein Bild angezeigt wird, aber man wird sich immer einen Krampf programmieren müssen, damit es stabil funktioniert und am Schluss wird der Bildschirminhalt so aussehen wie eine Webseite aus den 90er Jahren. Sprich, sowas will kein Mensch haben. Wenn Du das unbedingt mit einem AVR machen willst, dann brauchst Du ein "ingelligentes" Display, also z.B. sowas https://www.glyn.de/Produkte/Mikrocontroller/A-D-A-M-Intelligentes-Display welches die ganze Schwerarbeit selber erledigt. Dieses arbeitet mit dem FTDI EVE Chip. https://www.ftdichip.com/EVE.htm Aber wie viele hier schon berichtet haben; es empfiehlt sich für solche Anwendungen, einen besseren Mikrocontroller zu benutzen. Als Einstieg wäre sowas sicher nicht schlecht: https://www.glyn.de/Produkte/Displays/Smart-Embedded Auf diesem Eval-Kit ist ein STM32F746 verbaut.
AVRli .. schrieb: > Ja! Wenn man nicht mehr richtig sehen kann, muss alles etwas größer > ausfallen. Da sind wir doch beim Thema ;-) Beachte bitte, daß ein 7" TFT unabhängig von der höheren Auflösung etwa die gleiche Höhe wie ein 5,7" (QVGA 320 x 240) hat, nur eben breiter ist. Was bei Displays geringer Auflösung noch schnell geht, da diese gut ablesbar sind, braucht bei feinerer Auflösung deutlich mehr Zeit. Um ein gesetztes Pixel von einem Staubkorn zu unterscheiden, ist es daher sinnvoll, es auf 2x2 oder 3x3 'aufzupusten', wenn man keine Lupe zur Hand hat. Auf einem 12" Monitor bei 256 x 192 Pixel Auflösung ist ein einzelnes Pixel schon größer, wenn man sich an die alten Zeiten erinnern mag ;-) Das von Dir angesprochene MD070SD benötigt allein zur Ausgabe der Adresse neun Ausgaben ans Display, die im "Datenblatt" als Beispiel für den 8051 als Funktionsaufrufe aufgeführt sind. Das dauert doch ewig! Natürlich wird man die Ausgabe nach Möglichkeit so organisieren, daß nachfolgende Pixel mit Autoinkrement ausgegeben werden, aber dennoch werden z.B. bei Schriftzeichen immer wieder neue Zeilen angewählt werden müssen, die eine komplette Adressvorgabe benötigen. Besser sieht erst dann aus, wenn ein Controller wie der oben genante FT8xx verwendet wird. Der hat interne Schriften in diverser Größe, die er eigenständig zeichnet. Das geht dann auch mit einem 8 Bitter halbwegs schnell. Mir persönlich gefallen diese Teile nicht, da der Zeichensatz nicht vollständig ist und die vorhandenen Symbole 'weichgepült' aussehen. Beispiel Einkaufszentren: kennst'e eins, kennst'e alle. Johnny B. schrieb: > Als Einstieg wäre sowas sicher nicht schlecht: > https://www.glyn.de/Produkte/Displays/Smart-Embedded > Auf diesem Eval-Kit ist ein STM32F746 verbaut. Verrate uns noch den Preis. Ich plane gerade eine Leiterplatte mit STM32H750. Da reicht der interne Speicher auch für 800 x 480.
m.n. schrieb: > Johnny B. schrieb: >> Als Einstieg wäre sowas sicher nicht schlecht: >> https://www.glyn.de/Produkte/Displays/Smart-Embedded >> Auf diesem Eval-Kit ist ein STM32F746 verbaut. > > Verrate uns noch den Preis. > Ich plane gerade eine Leiterplatte mit STM32H750. Da reicht der interne > Speicher auch für 800 x 480. Den Preis kenne ich nicht, aber wahrscheinlich als Eval-Kit nicht ganz so günstig. Ich frage mal an, es interessiert mich selber.
Johnny B. schrieb: > Den Preis kenne ich nicht, aber wahrscheinlich als Eval-Kit nicht ganz > so günstig. Ich frage mal an, es interessiert mich selber. Frag auch gleich mal, wo man das bekommt, Glyn macht eher nur B2B. Ich arbeite gerade mit so einem: https://www.digikey.de/products/de?keywords=EVE2-70G Klar schreckt der Preis erstmal ab, das ist aber auch ein ganz anderer Level an Qualität als der China-Ramsch mit resistiv-touch.
Rudolph schrieb: > ist aber auch ein ganz anderer > Level an Qualität als der China-Ramsch Das wird nämlich im Schwarzwald von hochqualifizierten Dipl. Kuckuksuhrbauern in Handarbeit hergestellt ... Aufwachen bitte. Fast alles von dem Kram kommt bereits aus China. Das wir so geizig sind deren Ausschussproduktion über Alibaba abzukaufen, statt qualitätsgeprüfter Distributionsware, dafür können die nix. Schau Dir China mal genauer an. Da bleibt Dir das Lachen im Hals stecken wenn du siehst mit welchem Investitionvolumen die in Richtung Technologie und Qualität preschen.
m.n. schrieb: > Dafür braucht man ein 7" TFT? Natürlich! Manche aktuelle Navis haben schließlich auch 17" Displays. Wenn wir schon untergehen, dann möglichst dekadent.
Michael K. schrieb: > Das wir so geizig sind deren Ausschussproduktion über Alibaba > abzukaufen, Na, das meinte ich doch mit China-Ramsch, die Reste vom Grabbeltisch, übrig gebliebene Ware von vor X Jahren.
Rudolph schrieb: > Johnny B. schrieb: >> Den Preis kenne ich nicht, aber wahrscheinlich als Eval-Kit nicht ganz >> so günstig. Ich frage mal an, es interessiert mich selber. > > Frag auch gleich mal, wo man das bekommt, Glyn macht eher nur B2B. Ich denke diese wurden speziell für Glyn entwickelt und sind nicht über andere Kanäle erhältlich. Also das 7" Evalkit kostet um die USD 310.- Wenn man ein paar hundert Stück abnimmt kosten die dann etwa die hälfte davon. > Klar schreckt der Preis erstmal ab, das ist aber auch ein ganz anderer > Level an Qualität als der China-Ramsch mit resistiv-touch. Aus Fernost kommt eh alles, aber Du hast recht. Vorallem die lange Verfügbarkeit kostet richtig Geld. Aber es lohnt sich, wenn man ein langlebiges Produkt für die Industrie entwickelt.
Johnny B. schrieb: > Also das 7" Evalkit kostet um die USD 310.- Wenn man ohne große Vorarbeit (Layout) mit der Programmentwicklung beginnen möchte, ist der Preis doch kein Problem. In der Serie wird man sich das Board auf die eigenen Bedürfnisse anpassen, wobei Glyn dann gerne die TFTs verkauft. Diese sind so angelegt, daß von 3,5" - 7" die gleiche 40-pol. Steckverbindung verwendet wird. Gleiche Schaltung, anders Display: kein Problem. Rudolph schrieb: > Ich arbeite gerade mit so einem: > https://www.digikey.de/products/de?keywords=EVE2-70G > > Klar schreckt der Preis erstmal ab, Auch der Preis schreckt nicht ab, wenn man µCs kleinerer Leistung verwendet und ein gebrauchsfertiges Modul (inkl. Frontrahmen) benötigt. Die Dokumentation dazu fehlt wohl noch?
m.n. schrieb: >> Klar schreckt der Preis erstmal ab, > > Auch der Preis schreckt nicht ab, wenn man µCs kleinerer Leistung > verwendet und ein gebrauchsfertiges Modul (inkl. Frontrahmen) benötigt. Aber schon, wenn man glaubt das geht für unter 20 Euro. > Die Dokumentation dazu fehlt wohl noch? Hmm, okay, da hat Digi-Key wohl versagt. https://www.matrixorbital.com/ftdi-eve/eve-ft812 https://www.matrixorbital.com/ftdi-eve/eve-ft812/eve2-70g https://brtchip.com/ft81x/
Ich halte diese "intelligenten" Display-Controller (FT81x, Nextion, ...)
mit integrierter Rendering-Funktion für ziemliche Krücken - nur dazu da,
um auf leistungsschwachen Controllern Grafikfunktion nachrüsten zu
können. Diese intelligenten Displays enthalten ja dann doch einen
ausreichend leistungsfähigen Prozessor für die Grafikfunktion, welchen
man dann vom schwachen Controller aus ansteuert. Warum nicht alles
zusammen auf einen großen, leistungsfähigen Controller integrieren? Eine
Software auf zwei Controller aufzuteilen ist m.M.n in vielen Fällen eine
Kapitulation vor der Software-Integration - wenn man es nicht schafft
Grafik-Rendering und sonstige Anwendung in eine Software zu integrieren,
behilft man sich durch Kauf eines Controllers mit vorhandener Software.
Die optimale Lösung ist hier ein Controller welcher direkt ein
paralleles LCD-Interface ("RGB") bietet, wie die genannten STM32 und
auch viele SoC. Hierbei kann man in der eigenen Software das Bild in den
internen SRAM, oder ggf. externen SDRAM rendern. Der LCD-Controller gibt
dieses Bild gleichzeitig und kontinuierlich auf dem LCD-Interface aus,
mit "beliebigem" Pixeltakt (z.B. bis 54 MHz bei 24bit RGB-Farbe beim
STM32F429). Solange sich das Bild nicht ändert, verursacht dies
keinerlei Prozessorlast. Man kann mit großer Geschwindigkeit neue
Bildinhalte berechnen und flüssige GUIs und sogar auch Videos ausgeben.
Man ist letztlich nur durch den internen Prozessorbus und den
Prozessortakt beschränkt - aber die sind skalierbar durch Auswahl
größerer Prozessoren, d.h. dieser Ansatz skaliert quasi beliebig.
Das einzige Problem ist hierbei, dass man eine Software braucht um die
GUI (und Schriften) darzustellen. Das kann man selber machen (schöne
Übung) oder auch eine fertige Bibliothek benutzen (z.B. emWin, Qt, ...).
Letztlich erhält man so:
- Maximale Flexibilität - man kann die gesamte Software nach eigenen
Wünschen anpassen, und nahezu beliebige Panels nutzen; es gibt sogar
Adapter-ICs auf MIPI-DSI oder HDMI, man ist nicht auf einen
intelligenten Controller festgenagelt; durch Austausch des
Low-Level-Treibers (ca. 200 LoC) kann man das ganze System simpel auf
komplett andere Controller und komplett andere Displays portieren
- Maximale Performance - Bildinhalte lassen sich so schnell ändern wie
das LCD-Panel erlaubt, es entfallen alle Wrapper für den externen Bus,
das Setzen eines Pixels ist äquivalent mit dem Schreiben von 24bits in
den RAM (1 Speicherzugriff)
- Wahrscheinlich auch noch geringster Preis - externer Controller
entfällt, SDRAM ist billig
Das funktioniert nur dann nicht, wenn man spezielle Anforderungen an den
Controller hat, welche von LCD-fähigen Controllern wie dem STM32F429
nicht erfüllt werden. Die Verwendung des LCD-Interface ist überraschend
simpel, vielleicht sogar simpler als die Ansteuerung von SSD1963 o.ä.
In Zeiten günstiger und für Bastler verfügbarer leistungsfähiger
Controller wie eben STM32 sollte man sich so etwas nochmal überlegen.
Niklas G. schrieb: > Das einzige Problem ist hierbei, dass man eine Software braucht um die > GUI (und Schriften) darzustellen. ST hat sich kürzlich die Firma einverleibt, welche TouchGFX entwickelt und vertrieben hat. Es ist nun kostenlos verfügbar: https://www.touchgfx.com/ Habs aber selber noch nie eingesetzt. Hat jemand von Euch Erfahrungen damit?
Niklas G. schrieb: > Diese intelligenten Displays enthalten ja dann doch einen > ausreichend leistungsfähigen Prozessor für die Grafikfunktion, welchen > man dann vom schwachen Controller aus ansteuert. Warum nicht alles > zusammen auf einen großen, leistungsfähigen Controller integrieren? Ganz einfach: bei Einzel- und Kleinstückzahlen hat man kalkulierbare und niedrige Kosten. Daß mir diese FT8xx nicht gefallen, sagte ich ja bereits. Aber wenn ein Kunde auf die Schnelle ein hochaufgelöstes TFT für Datenausgabe und grafische Darstellung braucht, hätte ich damit keine Berührungsängste. Der steuernde Prozessor kann ja trotzdem ein M4/M7/H7 sein. Dann gibt es noch einen Punkt, warum ein separates Display vorteilhaft sein kann: Bei einer Steuerung wird man den µC nebst Peripherie möglichst auf einer Leiterplatte unterbringen und in ein Gehäuse packen, welches günstig im Gerät platziert wird. Das Display (Bedienteil) muß für den Benutzer günstig angeordnet werden, was durchaus mit 1 m Leitung von der eigentlichen Steuerung entfernt sein kann. Mit einer schnellen seriellen Verbindung hat man keine Probleme diese Strecke zu überbrücken. Das TFT über das parallele Interface anzusteuern wäre ungeschickt.
Sollte FTDI's Eve weiterhin von Interesse sein werfe mal ein Blick auf die Displays von newhaven (bei Mouser zu bekommen). Hab mir dieses zugelegt, MVA Panel, noch gut hell, Kapazitiver Touch. https://www.mouser.de/ProductDetail/Newhaven-Display/NHD-70-800480FT-CSXV-CTP?qs=sGAEpiMZZMve4%2fbfQkoj%252bFsUY5UPqiIIl6FeNDbTLR0%3d War es mir soweit auch Wert gibt aber auch etwas preiswertere Alternativen mit einfachen TN Panel und oder Resitiven Touch.
m.n. schrieb: > Ganz einfach: bei Einzel- und Kleinstückzahlen hat man kalkulierbare und > niedrige Kosten. Und bei Parallel-RGB-Displays nicht? Auch da gibt es fix und fertig aufgebaute Eval-Boards. Man muss nur 1x den Treiber für den LCD-Controller und eine Grafikbibliothek einbinden. Erlernen muss man den Umgang mit der Bibliothek genauso wie den Umgang mit FT8xx. Für letzteren braucht es ja sogar auch eine Bibliothek, die aber nichts selber tut sondern nur weiter reicht. m.n. schrieb: > Das TFT über das parallele > Interface anzusteuern wäre ungeschickt. Das stimmt. Aber auch hier kann man einen eigenen Controller direkt ans Display anbinden und beide Controller per UART u.ä. verbinden. Dann kann man die GUI beliebig selbst gestalten - mit Bibliothek oder ohne - und tauscht über die serielle dann nur noch die Nutzdaten aus. Das ist sogar effizienter, denn man muss die Nutzdaten nicht mehr in Grafikbefehle verpacken. Man kann so beliebig flüssige und anspruchsvolle GUIs auf dem eigenen Grafik-Controller umsetzen deren Geschwindigkeit von der seriellen Schnittstelle komplett unabhängig ist. Der Prozess-Controller "im" Gerät kann dann je nach Bedarf auch ein sehr kleiner oder spezieller sein; er braucht nur eine serielle Schnittstelle, aber nichtmal genug RAM um komplexe Grafikbefehle abzulegen bzw. zusammenzubauen.
Wie angekündigt nun ein Feedback! Nun ist das 7" Display hier und ich habe die ersten Versuche anstellen können. Ich bin total begeistert! Für meinen Einsatzzweck ist die Gesamtgeschwindigkeit doch ausreichend! Dazu muss ich folgendes sagen: Die Grundanzeige, also die ganzen 800x480 Pixel zeichne ich im Displayspeicher und mit einem Befehl wird dieser Inhalt dann zur Anzeige gebracht. Das sieht super aus! Jetzt werden nur noch alle relevanten Daten und Bereiche direkt auf em Bildschirm aktualisiert. Das sind 6 große Bargraphanzeigen, 20 Zahlenwerte und mehrere kleine 32x32 Pixel Status-Animationen. 7 Tasten werden auch mit Gedrückt-Zustand am unteren Rand gezeichnet. Alles im ganzen dauert da eine Aktualisierung nun 10ms und die Reaktionszeiten auf die Touch-Eingabe ist praktisch Echtzeit. (eigener Beitrag hier: Beitrag "Touch - wie kalibrieren in C?") Als einfaches GUI mit maximaler Freiheit also durchaus mit 16 MHz zu betreiben. Selbst so ein "digitaler Bilderrahmen" ist möglich, wenn man in der Wartezeit das nächste Bild schon im Display-RAM einliest. Video oder der gleichen natürlich nicht! ;-) Wem es interessiert, sucht nach "Touch Display 7" mit MD070SD Controller", das gleiche Display gibt es mit SSD1963 Controller, da sieht es nicht ganz so flüssig aus, weil man die Funktion "zeichne im Speicher" nicht hat! Danke ALLEN für den Austausch! Gruß AVRli...
Ben B. schrieb: > Ich dachte es geht um das AVR-Studio, wenn es da noch ein Atmel-Studio > gibt, verwende ich das nicht. Vor wieviel Jahren ist AVR-Studio durch Atmel Studio ersetzt werden? Die letzte vernünftig nutzbare Version war IMHO die Version 4.19 von 2011. https://www.mikrocontroller.net/articles/Atmel_Studio#Direktlinks_Installer
my2ct schrieb: > Die letzte vernünftig nutzbare Version war IMHO die Version 4.19 von > 2011. Es gab dann noch ein AVR Studio 5, kurz danach wurde es schnell in 6 umversioniert und bei der Gelegenheit in Atmel Studio umgetauft, weil man nun auch auf die ARMs abzielte.
Kim P. schrieb: > und untersützen weder das MK2 noch das Atmelstudio Weder der Mk2 noch das Atmelstudio sind irgendwie erstrebenswert. Also sei doch froh wenn Du das alles endlich hinter Dir lassen darfst! Du wirst nie wieder zurückblicken wollen!
Die Sache ist gegessen, der TE hatte lediglich nochmal Feedback nach Umsetzen der Vorschläge gegeben – was durchaus sehr freundlich ist. Da ist es witzlos, wenn die, die den Thread damals verpasst haben nun meinen, auch noch alle ihren Senf dazugeben zu müssen.
:
Bearbeitet durch Moderator
@avrli Hat dein ATmega einen externen RAM dazugeschaltet? Die Frage, die schon jemand anders hier im Thread gestellt hat (wo du die 800x480 Pixel ablegst), hast du bis jetzt nicht beantwortet was ich gesehen hab.
AVRli .. schrieb: > Wem es interessiert, sucht nach "Touch Display 7" mit MD070SD > Controller" Es ist aber abgekündigt; würde ich daher nicht mehr einsetzen wollen.
Max M. schrieb: > @avrli > Hat dein ATmega einen externen RAM dazugeschaltet? Die Frage, die schon > jemand anders hier im Thread gestellt hat (wo du die 800x480 Pixel > ablegst), hast du bis jetzt nicht beantwortet was ich gesehen hab. Das Display selbst hat 8MB RAM drauf, ich nehme an er arbeitet mit diesem.
Johnny B. schrieb: > Es ist aber abgekündigt; würde ich daher nicht mehr einsetzen wollen. Habe ich nicht gesehen... Richtig, auf dem Displayboard ist am MD070SD ein externer RAM dran. Damit habe ich so nichts zu tun. Gruß AVRli...
Jörg W. schrieb: > Die Sache ist gegessen, der TE hatte lediglich nochmal Feedback > nach > Umsetzen der Vorschläge gegeben – was durchaus sehr freundlich ist. Ja, vielen Dank auch von mir, ich hab da gar kein Gefühl dafür, was geht, daher bin ich doppelt froh über "Hausnummern" :) > Da ist es witzlos, wenn die, die den Thread damals verpasst haben nun > meinen, auch noch alle ihren Senf dazugeben zu müssen. Oder diejenigen, die schon vergessen haben, dass sie zu dem Thread schon ihren Senf dazugegeben hatten ;) MfG, Arno
AVRli .. schrieb: > Johnny B. schrieb: > Es ist aber abgekündigt; würde ich daher nicht mehr einsetzen wollen. > > Habe ich nicht gesehen... > > Richtig, auf dem Displayboard ist am MD070SD ein externer RAM dran. > Damit habe ich so nichts zu tun. > > Gruß AVRli... Tut mir Leid wenn ich nochmal nachfrage, aber den Inhalt des Displays musst du doch zur Compilezeit auch irgendwo hinspeichern, oder lässt sich das bei dir alles dynamisch zur Laufzeit generieren?
Also die Kernfunktionen wie "zeichne Rechteck", "zeichne Linie", Text in Schriftart xyz usw. sind natürlich im Programm-Memory hinterlegt. Alle Ansichten werden zur Laufzeit vom Programm gezeichnet. Der Vorteil mit dem 8 Seiten Speicher ist für den kleinen µC wirklich spürbar. So kann man beim Start auch 6 Ansichten entspannt zeichnen und dem User derzeit eine Einschaltmeldung anzeigen. SPäter kann man dann per einzigen Befehl die Ansichten umschalten und diese dann nutzen. Eine Setupansicht oder was man so vor hat. Wenn man sich auf die Sachen nun konzentriert, welche sich wirklich nur ändern, dann kann man das so durchaus empfehlen. Gruß AVRli...
Thread beobachten
Seitenaufteilung abschalten
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.