Ich arbeite gerade mit einem 1,8" TFT. Das von einem PIC18F25K22 angesteuert wird. Der PIC läuft mit intern 16MHz OC, und dem SPI MOdul 1 bei 4MHz. Nur leider dauert der Bildaufbau mir noch etwas zu lange. Mein Aufruf der Funktion lcd_fill_screen(farbe) dauert aktuell 125 ms, besser habe ich es noch nicht hinbekommen. Daher meine Frage an die Experten hier im Forum: 1. Code optimieren, möglich 2. Wie schnell kann ich maximal Daten aus dem SPI Bus herausgeben Wenn ich den SPI Bus mit 4MHz betreibe kommen doch da 500kbyte / Sekunde raus. Und mein Display hat 128x160 Pixel das sind 20480 Pixel x 2Byte = 40560 Bytes die ich übertragen muss. Somit dürfte es doch nur 90 ms dauern bis er damit fertig ist. + ein paar ms für die Sprünge im Programm Der XC8 Compiler schmeißt mir auch noch ein paar Warnungen heraus, die am Anfang der main.c ignoriert werden. Wenn die jemand weg bekommt kann er es ja hier Posten. Danke im Voraus
:
Bearbeitet durch User
Norbert S. schrieb: > keine Antwort ? Ich kann dir nicht direkt helfen aber .... Wegen dir habe ich mal meine ST7735 Firmware herausgekramt. Auf meinem Mega644 mit 20 MHz betreibe ich die SPI mit 10 Mhz und komme damit bei Clearscreen auf 87ms (mit einem internen 1 ms Timer gemessen). So schlecht stehst du also geschwindigkeitsmässig nicht da. Der Unterschied zu deinen 125msec dürfte von deiner langsameren SPI und dem geringfügig langsameren Prozessor stammen. Du kannst lcd_fill_Rect und lcd_fill_Screen trennen und in lcd_fill_Screen die innerste Schleife um den Faktor 2 oder 4 oder 8 (usw) "aufrollen" um ein paar Schleifenabfragen zu sparen und damit Zeit zu gewinnen. Aber das wird die Sache nicht wesentlich beschleunigen. Auch kann man lcd_fill_Screen in einer einfachen Schleife ausführen und muss nicht x und y separat zählen.
Was passiert denn in den ~40 ms die deine Routine länger braucht? Ich habe keine Pics, aber nach dem Durchblättern vom Datasheet bekomme ich den Eindruck, dass da kein Puffer im SPI-(MSSP-)Modul vorhanden ist. Meine Vermutung aus dem Bauch heraus ist, dass die 50% Zeit der Overhead zwischen den einzelnen Bytes ist. Ich empfehle dir mit einem Oszi das ausgegebene Signal anzuschauen ob die Bytes auch wirklich so eng sind wie erwartet oder ob eine Lücke dazwischen ist und diese Lücke den Overhead erklärt. Falls du kein Oszi hast, versuche mal das Register früher zu beschreiben. Wobei du wieder experimentieren kannst ob es funktioniert oder alternativ im Disassembly Zyklen zählen. Weil du ca 50% mehr Zeit brauchst als erwartet gehe ich davon aus, du durchschnittlich 12 anstatt 8 CPU-Zyklen pro Byte hast. Ich nehme mal an, dass das Registerladen in einem Befehl passiert. Dann brauchst du nur noch 7 nops zwischen den Registerbefehlen anstatt 10. und für die Forschleife wird es vermutlich ähnlich aussehen.
Mitlesa schrieb: > und komme damit bei Clearscreen auf 87ms .... oooops, hatte vergessen das Double Speed Bit der SPI zu setzen. Dieser Wert war also mit 5 Mhz Clock erreicht. Jetzt mit 10 Mhz Clock sind es glatte 50 ms für einen Clearscreen Durchlauf. Ja ja, die AVRs sind einfach besser ;-)
Alternativ koennte man das Bild in einem Speicher vorhalten und nur die geaenderte Differenz neu beschreiben.
Oder D. schrieb: > Alternativ koennte man das Bild in einem Speicher vorhalten und > nur die geaenderte Differenz neu beschreiben. Welches Bild? Ja klar, das ist voll praktikabel, sozusagen sehr realitätsnahe. Danke für diesen Hinweis auf den sonst niemand gekommen wäre. Ein Display von 128x160 hat 20480 Pixel a 16 Bit, und ein üblicher Mikrocontroller der so ein LCD benutzt hat 2 bis 8 K RAM. Passt gut zusammen, wa?
Thread beobachten
Seitenaufteilung abschaltenBitte 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.