|
Anzeige
|
Ist ein SPI TFT schneller auf einem ARM mit 72MHz als mit AVR 20?
Gast
#7507821
Sind die typischen Arduino TFTs mit SPI Schnittstelle mit einem 72MHz oder schnelleren ARM schneller in der Darstellung als mit einem 20MHz 8Bit AVR? Oder reizt der 8 Bit AVR die maximal mögliche SPI Geschwindigkeit der üblichen TFTs sowieso schon aus?
Vermutlich, weil . . .
Das allein reicht ja nicht, denn man muss ja auch die Daten für den Bildaufbau berechnen. Wenn man keine DMA für das SPI nutzt, erfolgt während dieser Berechnung keine Datenübertragung. Außerdem, ein AVR kann mit 20 MHz CPU-Takt mit max. 10 Mbit/s per SPI senden, ein 72 MHZ ARM aber mit mehr, vermutlich 36Mbit/s. Natürlich nur dann, wenn das auch das Display erlaubt. mit 27MHz SPI-Clock am STM32 lief bei mir so ein ILI9341-Display noch problemlos, auch über die typischen Dupont-Kabel fliegend verdrahtet. Seltsamerweise meint das ILI-Datenblatt, dass ein Serial Clock Cycle mindestens 100ns dauern soll, also 10MHz max... Und DMA ist da schon hilfreich, einen Buffer mit einem Bildschirm-Teil rausschieben während parallel der nächste Buffer berechnet wird, dann die Buffer tauschen. Und die STM32 gibt es mit reichlich mehr Speicher, ist für Grafik auch besser. So ein ILI9341 kann auch parallel über ein External Bus Interface von einem Mega2560 (Mega64/128/1280/1281/2560/2561) angesteuert werden. Ein Buszyklus dauert 4 Oszillatortakte, also kannst Du bei 16MHz maximal 4MByte/s oder 32MBit/s rausschreiben. Das sollte bei einem Display dieser Größenordnung reichen. Und SRAM kannst Du da auch noch parallel anklemmen. fchk
Ein LPC1768 schafft bei Write-Only auch problemlos 50 MHz SPI-Clock gegenueber einem ILI9341-Display. Will man auch lesen, muss man aber einen Gang herunterschalten. :) Allerdings ohne:
Ich selbst hab auch schon 40Mhz problemlos laufen gehabt. (EFM32GG230) Das reicht aber auch. Es reicht nicht um darauf Videos zu schauen, aber will man auch nicht. Aber wenn man einen halbwegs intelligenten Framebuffer implementiert der immer Blockweise arbeitet und nur das zum Display sendet was gerade Dirty ist, dann erreicht man damit vom User akzeptierte Echtzeit. Da flackert und ruckelt nichts mehr! Vanye Wenn man allerdings sowieso einen ARM nimmt, kann man auch ein paar Euro mehr spendieren und einen auswählen welcher ein paralleles Display-Interface hat (z.B. einige STM32) und ein dazu passendes Display. Damit kommt man auf noch viel höhere Übertragungsraten und kann auch hochauflösende Displays flüssig ansteuern (z.B. für Animationen). Das braucht natürlich DMA. Bei manchen STM32 Eval Boards ist das fertig so aufgebaut, z.B. 32F429IDISCOVERY oder 32F746GDISCOVERY. Für Grafik-Displays würde ich aber so oder so immer einen 32bitter (oder mehr...) nehmen, mit einem 8bitter stößt man da schnell an Grenzen ohne dass man wirklich einen Vorteil davon hätte. So Speicherinterfaces haben auch viele STM32, da heißt es dann FSMC. Wie man damit Displays ansteuert ist gut beschrieben in der AN2790: https://www.st.com/resource/en/application_note/an2790-tft-lcd-interfacing-with-the-highdensity-stm32f10xxx-fsmc-stmicroelectronics.pdf Geht mit den größeren F103, aber besser gleich einem F407 nehmen, 168 sind besser als 72 MHz. Ein ILI9340 läuft da mit 16 Bit parallel @10 MHz, damit kann man den Screen schon brauchbar scrollen. Die ESP32 sind da auch eine große Konkurrenz, Boards mit Display bekommt man für unter 15€, und dann ist noch WLAN dabei. Mit bis zu 80 MHz SPI können die auch recht schnell die Daten in das Display schaufeln.
Das funktioniert allerdings nur mit LCD-Controllern mit integriertem Speicher und hat auch nicht ganz die Performance von einem "echten" RGB-Display Interface wie es z.B. die STM32F429 haben (daran zu erkennen dass es VSYNC und HSYNC ausgibt). Von letzterem Ansatz heißt es in dem Dokument witzigerweise:
Aber es ist auch von 2008, da wusste man wohl noch nichts vom STM32F429 😉
Oder halt gleich den 429 mit echtem RGB-Interface. Die nächste Steigerung sind dann Controller mit MIPI-DSI Interface, wie z.B. STM32F769IG. Damit kann man dann praktisch jedes Smartphone- oder Tablet-Display ansteuern (billig, hochauflösend und gut verfügbar). Das ist das Schöne, bei den STM32 (und anderen Cortex-M) gibt es jede Menge Auswahl an Interfaces.
Die braucht ein Informatiker natuerlich unbedingt, um eine animierte Sanduhr anzuzeigen. Weil seine "Warteschleifensoftware" wieder noch nichts fertig hat. Der Rest der Welt erfreut sich derweil an den wenigen noetigen Anschlussen eines per SPI angesteuerten Displays.
Geht mit der Zeit und weiß, dass so gut wie alle (Multimedia-)Geräte mit Grafikdisplay alle möglichen Animationen anzeigen, vom Autonavi bis zum Verkaufsautomaten, weil das bei den Kunden/Nutzern gut ankommt, im Unterschied zu ruckeligen pixeligen Darstellungen welche höchstens Nostalgie erwecken. Außerdem kann man so visuelle Instruktionen zur Bedienung des Geräts darstellen, was internationaler und intuitiver als eine "Wall of Text" ist. Und was gut ankommt, lässt sich besser verkaufen.
Glücklickerweise haben heutige Controller ziemlich viele davon, insbesondere natürlich die, die so einen LCD-Controller enthalten. Von der Programmierung her ist es auch wunderbar einfach; nach der Initialisierung muss man bloß die gewünschten Pixel in ein Array schreiben, die Hardware macht den Rest. Es könnte sogar günstiger sein, weil Controller-Lose Displays in Massen hergestellt werden. "Mit hochauflösendem Grafikdisplay" macht sich als Verkaufsargument doch deutlich besser als "der Controller innen drin hat wenige Pins". Das hab ich noch in keinem Prospekt gesehen...
Nein. Als privater Bastler hab ich KEINEN Bock mir das routing mit den ganzen Leiterbahnen anzutun. Als Firmen-Hardwareentwickler habe ich keinen Bock wegen sowas das Risiko einer Ehrenrunde in der EMV zu erhoehen. Parallel nur wenn es wirklich nicht anders geht! Wie sagte der Prof fuer Theoretische Nachrichtentechnik von mir mal: Soll es schnell, nimm seriell. :D
Die bekommt man auch mit SPI problemlos hin wenn man nicht in Python programmiert. Aber vielleicht gibt es dafuer ja auch fuer Informatiker eine handoptimierte Assemblerlibary weil sie diese Funktion so oft brauchen. :-D Vanye
Dann kauf's halt fertig.
Also MIPI-DSI, ja?
Ah, Assembler programmieren Ja, Leiterbahnen routen Nein? Das sind die Skills aktueller Elektronikentwickler?
Wir haben seit kurzem in der Firma einen neuen Kaffeautomaten der immer huebsche Bilder anzeigt. Und jedesmal wenn man da nun eine Taste drueckt vergehen SEKUNDEN bis der auf die Eingabe reagiert. Und jedesmal wuensche ich mir von tiefsten Herzen das sowohl der Programmierer dieser Muellkiste wie auch dessen Projektleiter bei jedem Tastendruecken einen Elektroschock in ihre Eier bekommen. In der ersten Firmwareversion ist der sogar manchmal abgestuerzt weil Leute voller Ungeduld mehrmals auf die Taste gedrueckt haben. :-D Nein, nicht alle Programmierer sind bloed, ich kenne auch ein paar gute. Aber es gibt da draussen mittlerweile viele die besser was anderes geworden waeren. Vanye p.s: Ich frag mich sowieso wie Programmierer von Kaffeautomaten so aussehen. Ich meine die muessen ihre Software doch andauern testen! Hinterlaesst das nicht Folgen fuer Herz und Blutdruck? :-)
Fuer VGA und groesse sicher. Fuer QVGA reicht aber SPI noch aus. Und wie schon gesagt, es haengt von der Anwendung ab. Es gibt ausnahmen das ist Parallel sicher angesagt und vernuenftig, aber es sind halt seltene Ausnahmen. Vanye
Wie beim Therac-25. War nur etwas gefährlicher.
Die Firma ist wahrscheinlich zu geizig um den Programmieren so ein teures Teil hinzustellen.
Tja, aber dann hättet ihr gar keinen Kaffeeautomaten mit Display & Co...
So selten, dass so einige Controller und viele SoC's das hardwaremäßig eingebaut haben...
Das gleiche mit Fahrkartenautomaten und ähnlichem. Welche lausigen Praktikanten haben den Scheiß zusammengeschustert? Oder sind das am Ende doch "professionelle" Entwickler?
Solche Firmen haben halt seit jeher nur Ingenieure eingestellt. Nachdem die lästigen Kunden so neumodischen Kram wie "Displays" oder "Computer-Steuerung" haben wollten, haben sie halt noch mehr Ingenieure eingestellt um das zu programmieren. Die haben dann 1 Semester C-Programmieren gelernt und die Software dann mit diesen Kenntnissen zusammengeschustert.
Und du meinst, der durchschnittliche "Softwareentwickler" ist da besser? Da habe ich so meine Zweifel. Gutes Presonal ist immer knapp. Man kann schon mit einem Stm32F103 bei 18Mhz Daten via DMA aus einem Flash-Speicher direkt ins Display schreiben. Bedeutet, anstatt jetzt Punkte und Zeichnungen auf dem Display zu setzen kann man easy ganze Bilder Flimmerfrei aus dem Flash holen. Z.B. Das Alphabet in Highres. Echtes Scrollen wie man es kennt muss das Display unterstützen(Am besten auch Partielles Scrolling). Das schafft kein SPI Vollbild ruckelfrei von alleine. Ich selbst bin bei einfachen Projekten im Schwerpunkt Displays irgendwann zum ESP32 gekommen. Vorteil halt Wlan, es gibt Displays die den schon im Gehäuse Huckepack haben, eine Dual-Core CPU mit 200Mhz, 40Mhz SPI (mehr geht meist auch garnicht bei den Displays) und den Flash schon Onboard um Bilddaten, Buttons und Fonts wie auch Hintergründe vorzuspeichern. So nebenbei geht da auch alles mit Arduino.
Bei "1 Semester C" vs. "6-10 Semester an verschiedenen Programmiersprachen, Methodiken, mathematischen Grundlagen, Praxisprojekten" ist die Antwort relativ klar oder?
Das sowieso. PS: Wir haben in der Firma einen Kaffeeautomaten wo sowohl Hard- als auch Software vermurkst sind. Quasi ein harmonisches Ganzes.
Nö. Denn verdammt viele "Softwareentwickler" sind verspielte Akademiker, die sich mit jedem Schnulli beschäftigen und Software aufblasen ohne Ende. Performance? Who cares! Dazu kommen noch tonnenweise Quereinsteiger, die zwar einen anderen Hintergrund haben, aber auch nicht sonderlich performant orientiert sind. Und wenn der Kram dann ruckelt und knirscht ist NATÜRLICH die Hardware oder das Frameqwork schuld! Niemals der Softwerker!
Müll^2! Oder jemand wollte krampfhaft an seinem 8 Bitter festhalten: ‚das kann der auch alles‘
Wenn Ingenieure alles besser können, warum haben sie dann nicht Informatik studiert? Mit einem Informatik-Abschluss verdient man durchschnittlich mehr.
Kann auch sein, aber in den meisten Fällen ist es eher so, daß es nicht die Grenzen der Hardware sind, sondern eher die Bloatware die drauf läuft und die mangelnden Kenntnisse sowie der innere Antrieb der Softwerker, was richtig Gutes zu schaffen. OK, dazu mag auch kommen, daß viele Projekte sowieso von Zeitmangel bzw. massiven Projektzeitüberschreitungen geplagt sind und am Ende alle froh sind, wenn der Kram ÜBERHAUPT irgendwie läuft! Schnell und performant ist das erste Opfer in den "Optimierungsrunden".
Mit der Logik scheinst du es nicht so zu haben? Bist du Informatiker? Ich habe NICHT behauptet, das Ingenieure die besseren Softwareentwickler sind oder gar alles besser können. Ich habe nur deine Aussage in Frage gestellt. Um es ganz direkt zu sagen. Ich halte weder Ingenieure für die besseren Softwerker noch die Softwerker für bessere Softwareentwickler. Die wirklich Guten sind gut, weil sie eine bestimmte Mentalität haben, nicht weil sie Ingenieur oder Softwareentwickler mit sonstwie viel Semestern zu sonstwie coolen Themen auf dem Buckel haben. Das in der Uni/FH/Whatever sowie anschließend in der Praxis gelernte Handwerkszeug ist wichtig, steht aber nicht an erster Stelle.
Na dann mal los!
Der "1 Semester C" Ingenieur hat den Kaeffffautomaten fristgerecht(!) in einem Monat fertiggestellt. Das Userinterface ist uebersichtlich auf einem 4 x 20 LCD untergebracht. Fehlerzustaende der Maschine werden detailliert nebst ihrer moeglichen Behebung angezeigt. Abstuerze kennt man nur, wenn die Putze mit ihrer Bohnermaschine zu Nahe an den Kaeffffautomaten kommt. Der "6-10 Semester an verschiedenen BLA..." hat nach 3 Jahren eine erste experimentelle Version fertig. Deren Webbrowser, muss aber regelmaessig mit Updates versorgt werden. Die Javascriptengine meldet nach einigen Stunden Laufzeit nur noch "Not responding scripts". Ein Neustart dauert wegen der mitgestarteten "Updateautomatik" mindestens eine halbe Stunde. Fuer "gelegentliche" Abstuerze brauht es die Bohnermaschine der Putze nicht mehr... Die passieren mindestens taeglich. Die Mitarbeiter sind mittlerweile wieder auf eigene Wasserkocher umgestiegen.
Ich ab ja eher den Verdacht das die Probleme im Projektmanagement liegen, oder besser gesagt in der Idee das ich X Leute brauche und in Y Monaten fertig sein werde und das Marketing deshalb schon mal heute loslegen kann. Excel kann nicht luegen! Bei vielen heutigen Geraeten sind die Maengel bereits bei der ersten Bedienung/Nutzung offensichtlich. Ich frag mich dann immer, wenn irgendeiner der am Projekt beteiligten das Geraet schonmal genutzt hat, das MUSS dem einfach aufgefallen sein? Oder doch spaetestens der Qualitaetssicherung. Und dann wird das ganze noch multipliziert mit dem unseligen Geist des "Loesen wir mit einem Softwareupdate" und der Realitaet: "Programmierer arbeitet schon am naechsten Projekt und hat keine Zeit" Vielleicht sollte man auch jedes Projektteam um eine unbedarfte Oma erweitern die am Ende mal alles Bedienen muss. :-D Vanye
Das auch, aber nicht in erster Linie.
Nö, weil das alles Leute sind, die keine Ahnung von gescheiten GUIs und Softwarequelität haben! Und auch die haben meistens keine Ansprüche an Leistung! "Funktioniert doch. Wir haben doch eh keine Zeit, das zu verbessern." Etc.
Ja, ein DAU-Tester ist schon nicht verkehrt. Aber der löst nicht den Mangel an Leuten mit Designkenntnissen und Erfahrungen im Bereich GUI.
Das ist dann kalter Kaffee den keiner mehr haben will, weil die Mitbewerber zum gleichen Preis schon farbige Displays mit guter GUI haben und die machen mehr her. Also bekommt der Entwickler den Auftrag auch sowas zu bauen. Aber der hat sich nur mit ollen Textdisplays beschäfftigt weil 'es ja reicht' und was dann dabei rauskommt sieht man ja. Natürlich gibt es auch bedienbare GUI mit kleineren Prozessoren, sieht man bei den 3D Druckern. Aber auch da ist schon lange der Trend das für die Bedieneinheit ein 32 Bitter eingesetzt wird.
Die Frage war nicht, ob da eine 8 oder 32 Bit CPU drinsteckt, sondern ob die Bedienoberfläche, aka GUI was taugt! Ob sie logisch aufgebaut ist und flüssig reagiert.
Du hast meine Aussage in Frage gestellt, dass Informatiker wahrscheinlich die besseren Softwareentwickler abgeben als Ingenieure aufgrund des Umfangs dieses Themas in den beiden Studiengängen. Aber du hast angeblich auch nicht behauptet
sind. Das heißt also, du meinst schon dass Informatiker doch die besseren Software-Entwickler sind, aber nicht aufgrund des Studiums? Warum dann, weil die Sterne für Informatiker besser stehen?
Das klingt für mich nicht so:
Und wie soll das so im Durchschnitt sein? Durchschnitts-Informatiker vs. Durchschnitts-Ingenieur?
Wann hast du das letzte Mal ein neues Produkt gesehen das so ein Display hat? Auf so einem Display benutzerdefinierte Kaffee-Programme zusammenstellen oder Anweisungen für das Selbstreinigungs-Programm darzustellen ist doch totaler Krampf.
Lustige Geschichte, ich kenne sogar eine in JavaScript geschriebene und im Browser laufende Maschinensteuerung. Ist von einem Ingenieur. Die Embedded-Informatiker die ich kenne schreiben Steuerungen natürlich in C oder C++. Und die wissen auch wie man effizient programmiert und Fehler behandelt.
Doch, absolut. Gäbe das Management genug Zeit zur Einarbeitung in die Technologie, könnten auch Anfänger was vernünftiges bewerkstelligen. Weil aber Time-To-Market immer das Allerwichtigste ist, muss man halt die erstbesten Technologien nehmen die man schon kennt.
Tja, in welchen Studium man so etwas wohl lernt...
Ein besonders "missratenes" Exemplar habe ich neulich aufgespuert. Bei dieser "GUI" hatte man vollstaendig(!) auf jeden Text verzichtet. Ob es einen "Cafe Crema" oder "Espresso" gab, musste man an Hand von Grafiken "erraten". Das ist ja wohl voellig irre. Gluecklicherweise habe ich richtig "getippt". :)
Bilder sind international, Worte weniger. Kann aber natürlich auch schief gehen. Ich erinnere mich an ein digitalisiertes Trinkwasser-Zapfsystem an einem italienischen Campingplatz mit Grafikdisplay, wo man mit und ohne Kohlensäure auswählen konnte. Leider nur auf italienisch, und ich hatte kein Smartphone zum Übersetzen dabei. Das hätte man super mit ein paar Bildchen lösen können...
Das ist ein weit verbreiteter Irrglaube. Auch die Wahrnehmung und Interpretation von Bildern ist stark durch die lokale Kutur geprägt.
Richtig, aber zumindest innerhalb von z.B. Europa geht es schon, auf jeden Fall besser als "nur italienischer Text". Wenn man es richtig macht geht es auch "richtig" international.
Hoffentlich lernt man mittlerweile etwas zu UI/UX im Studium. Es gibt kaum etwas schlimmeres als GUI von Technikern. Hi
Gilt auch für Softwarefuzzis. Die GUIs müssen von Praktikern erstellt werden die sich mit der Materie auskennen. MfG Spess
Gast
#7508725
Idealerweise von den Anwendern.
Und noch idealer von linkshaendigen Anwendern! Vanye
Das ist ja wohl rassistisch und diskriminierend!
Nö. Denn die haben in den meisten Fällen auch keine Ahnung. Im Idealfall macht das jemand, der sich damit WIRKLICH auskennt in ZUSAMMENARBEIT mit den Anwendern! Dann entsteht eine sehr gute, manchmal optimale GUI.
Gast
#7508889
Die haben die meiste Ahnung:
Im Idealfall finden sie dann jemand der das versteht und praktisch umsetzt.
Gast
#7508906
Seid ihr bald fertig? Erstellen der GUI von einer Fachkraft und testen von einem DAU. Hand in Hand also. ... aber irgendwie ist das alles off Topic. Antwort schreibenBitte melde dich an, um einen Beitrag zu schreiben. |
Anzeige
|
