ZitierenWenn du uns deinen Code zeigst, können wir dir besser helfen.
Gruß
Rolf
Hallo,
ich experimentiere gerade ein wenig mit Grafik-Displays und wollte eigenlich Werte graphisch darstellen, sozusagen eine Verlaufslinie wie man es vom Oszilliskop her kennt. Leider ruckelt bei mir alles, weil ich halt linie Zeichne, die Werte nach links verschiebe, neu zeichne und die alte Linie lösche.
Jetzt habe ich schon öfters viel flüssigere Animationen solcher Dinge im Netz gesehen - es geht also auch besser.
Hat einer eine Idee wie? Da wäre ich ihm sehr dankbar.
Gruß
Wenn du uns deinen Code zeigst, können wir dir besser helfen.
Gruß
Rolf
Glaube ich nicht, da es ja nicht um meinen Code geht, sondern um die allgemeine Vorgehensweise bei dieser Sache. Und was mein Code macht, habe ich ja schon geschrieben...
Im Allgemeinen werden LCD Routinen so in Bascom geschrieben das auch das lahmste LCD noch läuft.
Gento
Edit:Wenn Du 16 MHZ Quarz hast , schreibt in den Quell 1 MHZ (Wirkt oft wie ein Wunder)
keiner ein Beispiel von solchen Animationen?
also am pc wird ja meistens in einen (ram) puffer gezeichnet, und dieser dann in einem rutsch auf den bildschirm übertragen. das lohnt sich aber nur, wenn sich viel auf dem schirm ändert.
bei einem oszisignal hast du ja nur einen pixel pro spalte, den du setzen oder löschen musst. du könntest also mal einen puffer mit deinen [anzahl spalten] messwerten darstellen lassen, dann spalte für spalte diese pixel löschen und dafür andere pixel aus einem 2ten puffer darstellen. schneller wird es ohne trickserei in Bascom nicht werden.
vielleicht kann man aber auch die zeichenroutinen noch optimieren, aber alle Projekte in der art, die ich bisher gesehen habe (links habe ich grad leider keine) waren in c und die zeitkritischen stellen in asm umgesetzt.
üblich ist, dass man entweder auf das ready flag des displays wartet, bevor man das nächste datenbyte überträgt; oder einen festen zeitraum abwartet, der normal so gestaltet ist, dass auch das langsamste display mitkommt. letzteres ist meistens um einiges langsamer.
beispielcode wirst du wahrscheinlich keinen bekommen, wenn du es nicht für nötig hältst, deinen code zu posten.
gruesse
hat nichts mit nötig halten zu tun, eher damit, daß er - wie schon gesagt - keine rolle spielt.
bin mittlerweile etwas fündig geworden, allerdings ruckelt es da genau so wie bei mir. scheint wohl mit Bascom (sind auch nur bascom-befehle) nicht anders zu gehen. schade eigentlich
ohne Beispielcode ist es in der Tat etwas schwierig zu helfen. ASM lässt sich auch in Bascom einbinden. Je nach Displayart und Auflösung lässt sich hier und da etwas optimieren. Ich mache das meist, indem ich die Libs manuell anpasse. (Das Original natürlich vorher sichern)
Wenn das Herz involviert ist, steht die Logik außen vor! \/
Dann hast du da Beispiele, also Video's von? Mich würde erstmal das Ergebnis intressieren, bevor ich da anfange mit meinen kleinen Kenntnissen was zu biegen *g
Finde raus, ob du das Display nur als Ganzes oder auch einzelne Pixel/Spalten/Felder steuern kannst.
Da du weder Code noch Displayart/-Treiber nennst, ist das alles fruchtlos...
Die Bacom-Routinen sind nicht immer optimal, mit nem eigenen Treiber ist das eventuell schneller.
Dazu suchste dir das Datenblatt des Controllers und programmierst es halt neu.
Berechtigungen
Lesezeichen