Guten Morgen, ich schreibe gerade für den STM32 einen Treiber für ein DOGM163. Die Kommunikation ist ja per SPI sehr einfach gehalten. Das einzige was mich stört ist das je nach dem was für einen Befehl man an das Display sendet gewartet werden muss. Wie kann ich auf einfache weiße die paar µs warten ohne das ich ich nichts mache. Also ich was Sinnvolles mache. Danke für die Hilfe
Für diesen Fall würde ich sagen: gar nicht. Du könntest einen Timerinterrupt benutzen, der alle paar µs mal nachschaut. Aber für eine einmalige (oder zumindest seltene) Initialisierung einen Timer verballern? Du könntest auch ein OS benutzen und der Thread, in dem die Initialisierung läuft, wartet einfach und andere Threads können arbeiten. Wenn du aber eigens deswegen mit einem Betriebssystem anfängst würde ich das auch nicht als effizient bezeichnen. Ich bin gespannt was andere dazu sagen, mit Hardware kenne ich mich deutlich besser aus als mit Software.
Hi, beim Atmel habe ich einmach _delay_us() verwendet aber beim STM32 finde ich schade wenn der Gute mit 72Mhz rennt und im Code gewartet wird.
Bei den meisten Projekten (auch kleineren) habe ich immer einen Systemtimer drin, welcher solche Sachen wie Tastenentprellen, Echtzeituhr, etc macht. Den rufe ich aller 1 - 10ms auf. Wenn es dich nicht stört, dass du etwas länger warten musst, könnte man es über so eine Lösung machen. Du setzt ein Flag und wenn der Timer das 2. mal getriggert wird, kannst du weiter machen.
Hansjörg schrieb: > finde ich schade wenn Hast Du denn etwas, was der Prozessor in der Zeit tun kann? Dann nutz einen Timer, wenn nicht warte einfach. Du bekommst kein Geld zurück wenn der STM ständig ausgelastet ist, Warten ist eine der Hauptbeschäftigungen von Controllern.
Hansjörg schrieb: > Wie kann ich auf einfache weiße die paar µs > warten ohne das ich ich nichts mache. Indem du eben dort genau nicht nur die Ansteuerung des DOGM163 erledigst, sondern die Wartezeiten mit anderen Aufgaben füllst. Das widerspricht aber dem Konzept eines Treibers. Der Overhead, den du dir mit einem taskwechselfähigen OS einhandelst, wiegt die paar µs Gewinn höchstwahrscheinlich nicht auf, schon gar nicht auf "einfache weiße".
Bei jedem Zeichen das ich an das Display sende sind 45us zu warten. Das ist schon relativ viel Zeit in der man nichts tut. Oder sehe ich das falsch. Wenn ich zb einen String mit 10 Zeichen an das Display schicke muss ich 10mal 45us warten. Mit Interrupt Flag muss ich mir aber auch merken wo ich gerade beim Senden war. Das ist auch nicht gerade das gelbe vom Ei.....
Hansjörg schrieb: > Bei jedem Zeichen das ich an das Display sende sind 45us zu warten. > Das ist schon relativ viel Zeit in der man nichts tut. > Oder sehe ich das falsch. > Wenn ich zb einen String mit 10 Zeichen an das Display schicke muss ich > 10mal 45us warten. Mit Interrupt Flag muss ich mir aber auch merken wo > ich gerade beim Senden war. > Das ist auch nicht gerade das gelbe vom Ei..... du müsstest alles was ans Display gehen soll in einen Puffer packen und dann in jedem Interrupt ein Byte ausgeben. Ob die Initialisierung des Puffers und die INTs die 45μs aufwiegen müsste man mal ausrechnen. Wenn immer nur ein Byte raus muss könnte man das auch per DMA machen. Sascha
Moin, Es gibt so eine Zeitspanne im Bereich zwischen ein paar NOPs (µsec) und "vernuenftiger" IRQ Haeufigkeit (~ msec), da isses einfach kagge bei einer CPU mit warten. Ist halt so. Sollte man vermeiden. Also z.b. ein anderes Display einsetzen ;-/ Gruss WK
Genau da beginnt die Pragmatik beim Programmieren. Ich würde mir ja wünschen, man dürfte ein Byte senden, das nicht wirklich gesendet wird, sondern einfach eine entsprechend lange Pause macht. Dann kann man das alles ohne Sonderbehandlung machen. So musst Du abschatzz, wie oft das vorkommt, wie lange eine Interrupt Verarbeitung dauert und wie dein RTOS und dein uC getaktet ist. Und je nach Ergebnis warten (nops, Schleife von nops), einen Timer nutzen (gesonderter Interrupt), etwas anderes zwischendurch machen (was länger dauert oder per free running counter überwacht wird) oder halt ein sleep von 1 bzw 2 einlegen.
Das klingt nach einer Aufgabe für einen Timer getriggerten DMA. Die STM32 haben genug Timer, da lässt sich mal der eine oder andere für Spezialaufgaben nutzen. Buffer füllen -> SPI+Timer+DMA einstellen -> nach einem DMA Done IRQ kann der nächste Buffer gesendet werden.
Hansjörg schrieb: > Bei jedem Zeichen das ich an das Display sende sind 45us zu warten. Au weia ... Steht das so im Datenblatt? Dann hilf wohl nur senden aus einem Timer- Interrupt.
Hansjörg schrieb: > Wenn ich zb einen String mit 10 Zeichen an das Display schicke muss ich > 10mal 45us warten. Mit Interrupt Flag muss ich mir aber auch merken wo > ich gerade beim Senden war. DMA. Initialisierung mit Timer.
Hansjörg schrieb: > Hi, > beim Atmel habe ich einmach _delay_us() verwendet aber beim STM32 finde > ich schade wenn der Gute mit 72Mhz rennt und im Code gewartet wird. Die Forderung war "Warten ohne nichts zu tun", da wäre ein _delay_us() auch falsch ;) Zum Thema selbst: Ich würde da auch richtig DMA und Timer gehen wenns so wichtig ist nicht nichts zu tun.
Hansjörg schrieb: > Wie kann ich auf einfache weiße die paar µs warten ohne das ich ich nichts mache. Ich weiß nicht welchen STM32 du nutzt, aber Cortex-M3 besitzen einen CycleCounter. Das ist ein 32bit Counter, der mit jedem CPU Takt um eins inkrementiert wird.
Korrekt macht man das so, daß man nicht nach einem Befehl wartet, bis das Display damit fertig ist, sondern indem man vor dem Senden eines Befehls prüft, ob das Display den vorigen Befehl fertig hat. Die sinnvollste Variante dafür ist die Auswertung des BUSY Flags. Denn damit fängt man nicht nur Variationen des Display-Taktes ab (das ist ja nur ein simpler RC-Oszillator) sondern auch Variationen in der Ausführungszeit. Das Datenblatt nennt die maximale Ausführungszeit. Es kann durchaus auch schneller gehen. Dummerweise kann man das BUSY Flag unter Verwendung des SPI Interface nicht abfragen. Deswegen wäre die erste Frage: muß es wirklich SPI sein? Falls doch, dann kann man einen Timer dazu verwenden, die Ausführungszeit des Display-Controllers zu simulieren. Man setzt dafür einen Timer auf, der vom gesetzten Wert in µs-Intervallen auf 0 zählt. Nachdem man einen Befehl an das LCD sendet, setzt man den Timer auf die Ausführungszeit des Befehls (den Maximalwert aus dem Datenblatt). Immer bevor man einen (weiteren) Befehl absetzt, schaut man, ob der Timer schon auf 0 steht und wenn nicht, wartet man halt darauf.
Wenn das Display noch ein Busy Flag hat, könntest Du diesen an einen Interruptus hängen und damit einen Puffer abarbeiten .. ? Vorteil: Man ist zeitmäßig nicht auf ein bestimmtes Display festgelegt.
SPI... Bei einem LCD- Display mit 3*16 Zeichen ist es natürlich extrem sinnvoll, beim Schreiben auch noch die allerletzte Mikrosekunde einzusparen... Einfach per Timer die Zeiten aus dem Datenblatt abwarten, und fertig. Oliver
Klar, DMA mit Timer kann man alles machen. Aber mal anders herum gefragt: Wäre es so schlimm wenn nur z.B. jede ms ein Zeichen zum Display gesendet wird? Mehr wie 100 Zeichen wirst du wahrscheinlich nicht haben auf dem Display. Und selbst wenn wären es dann noch 10Hz Aktualisierungsrate. Ich würde mir also überlegen ob ich einen ms Interrupt anlege. In dem kannst du dann alles mögliche machen. Von Taster abfragen, LEDs bedienen oder eben auch ein neues Zeichen zum Display senden. Dann wartet der Controller effektiv garnicht und du hast die restliche Zeit für Echtzeit-Geschichten frei.
Man legt einen Puffer an für alle Zeichen des Text-LCD. Ein Timerinterrupt 1ms gibt dann immer ein Zeichen aus bzw. das Byte zur Zeilenumschaltung. Hier mal ein Beispiel für den AVR: Beitrag "Formatierte Zahlenausgabe in C"
Axel S. schrieb: > Korrekt macht man das so, daß man nicht nach einem Befehl wartet, bis > das Display damit fertig ist, sondern indem man vor dem Senden eines > Befehls prüft, ob das Display den vorigen Befehl fertig hat. Dann verbringt man vor dem Senden die Zeit mit "gucken ob fertig" und hat damit auch nicht richtig etwas gewonnen, weil irgendeine andere Aufgabe sich immer um "Busy-Gucken" kümmern muss.
Woher kommen die 45 us? Im Datenblatt des ST7036 Chips finde ich nur Wartezeiten waehrend der Initialisierung.
Wolfgang schrieb: > Axel S. schrieb: >> Korrekt macht man das so, daß man nicht nach einem Befehl wartet, bis >> das Display damit fertig ist, sondern indem man vor dem Senden eines >> Befehls prüft, ob das Display den vorigen Befehl fertig hat. > > Dann verbringt man vor dem Senden die Zeit mit "gucken ob fertig" und > hat damit auch nicht richtig etwas gewonnen, weil irgendeine andere > Aufgabe sich immer um "Busy-Gucken" kümmern muss. Ich habe ganz bewußt nichts konkretes dazu geschrieben, wie dieses "Warten" aussehen sollte. Denn das hängt ganz und gar davon ab, was das Programm sonst noch so treibt. Man könnte das auszugebende Zeichen widrigenfalls ja in einen Puffer schreiben. Und sich beim Ablauf des Timers per Interrupt informieren lassen. Eine ISR aufsetzen, die den Puffer leert. Oder gleich den ganzen Weg gehen und FIFO Pufferung für das Display implementieren. Aber im Zweifelsfall muß man zwischen den einzelnen Zeichen, die aufs Display gemalt werden, ja ohnehin noch andere Sachen tun. Und sei es nur, daß man die nächste Ziffer aus einer mehrstelligen Zahl extrahiert. Wenn die Wartezeit kurz genug ist, dann reicht das ja womöglich schon. PS: überhaupt ging es mir nicht darum, eine optimale Strategie zur Ausgabe von Zeichen zu formulieren. Mir ging es einzig darum, daß unmittelbar nach der Ausgabe des Zeichens der falschestmögliche Zeitpunkt zum Warten ist. Denn in diesem Moment habe ich ja schon alles erreicht, was zu erreichen war: ich bin mein Zeichen ans Display losgeworden. Ob es jetzt 10µs braucht, um es auf das Glas zu malen oder 10ms, das kann mir zu diesem Zeitpunkt vollkommen egal sein. Interessant wird das erst, wenn ich das nächste Zeichen ausgeben will. Aber ein Treiber weiß ja nicht (kann gar nicht wissen) wann das Hauptprogramm das nächste Zeichen ausgeben wird.
:
Bearbeitet durch User
Guten Morgen, danke für die guten Ansätze. Ich denke über folgende 3 Ansätze nach. SPI mit Dma mit Timer Display anstatt über SPI über 4/8 Bit ansteuern und Busy Flag nutzen Oder einfach die Interrupt Methode von Peter. Aber ganz entschieden habe ich mich noch nicht. Danke Allen für die Hilfe
Axel S. schrieb: > Interessant > wird das erst, wenn ich das nächste Zeichen ausgeben will. Aber ein > Treiber weiß ja nicht (kann gar nicht wissen) wann das Hauptprogramm > das nächste Zeichen ausgeben wird. die Frage muss doch mal gestellt werden, wer kann so schnell ein LCD ablesen dasmehr als 4 Aktualisierungen pro Sekunde gelesen werden können? Ich mache nur 4 Aktualisierungen pro Sekunde nur deswegen weil die angezeigte Uhrzeit relativ flüssig laufen soll, ob die Zeit nun 10ms früher oder später aufs Display gemalt wird ist doch egal! Auch bei der Überwachung einer Batterie-spannung oder -strom bekomme ich Peeks nicht mit, wenn ich sie gelesen habe sind sie lange vorbei, was nun, allenfalls könnte man peek detect einsetzen und extra irgendwo schreiben und stehen lassen, genau wie früher am analogen Zeigerinstrument mit Leuchtanzeige für peek (overload) Genau wie bei einer Stopuhr auf dem LCD, versucht doch mal 1/10 oder 1/100 Sekunden zu lesen!
:
Bearbeitet durch User
Joachim B. schrieb: > Ich mache nur 4 Aktualisierungen pro Sekunde nur deswegen weil die > angezeigte Uhrzeit relativ flüssig laufen soll, ob die Zeit nun 10ms > früher oder später aufs Display gemalt wird ist doch egal! Ja, 3 oder 4 pro Sekunde reichen als Refresh aus. Wenn man durch viele Menüs scrollen muss, dann sollte es jedoch bis zu 10/s sein, da man "sein" Menü durchaus so schnell erkennt (und dann halt 1 oder 2 zurück muss). Gilt aber nur bei sehr vielen Menüpunkten (>>10) Zudem kommt es noch darauf an, wie es gefüllt wird. Wenn man zuerst alles Löschen muss, dann sollte es sehr schnell (<20ms) wieder voll sein um ein "Blinken" zu vermeiden. Wenn man jedes Zeichen einzeln überpinselt, sollte das ganze trotzdem in 20-50ms fertig sein.
A. S. schrieb: > Zudem kommt es noch darauf an, wie es gefüllt wird. Wenn man zuerst > alles Löschen muss, dann sollte es sehr schnell (<20ms) wieder voll sein > um ein "Blinken" zu vermeiden. bei TFT Displays habe ich mir abgewöhnt alles zu Löschen, das dauerte zu lange, aber ich hatte den Text im SRAM zwischengespeichert und nur die geänderten Buchstaben Pixel mit SW übermalt somit änderten sich nur die neueren Pixel. Dummerweise ist da jede LIB jedes Display verschieden, z.B. für ein Nokia5110. Es gibt eine LIB (nur) für AVR die löscht automatisch das ganze Feld unter dem neuen Buchstaben und die von Adafruit (für ESP32) tut es eben nicht, da muss man dann selber erst mal das Feld löschen vor Neumalen des Buchstabens (oder Ziffer oder Sonderzeichen)
:
Bearbeitet durch User
Joachim B. schrieb: > die von Adafruit (für ESP32) tut es eben nicht, da muss man dann selber > erst mal das Feld löschen vor Neumalen des Buchstabens (oder Ziffer oder > Sonderzeichen) Bei der Adafruit_GFX kommt es darauf an wie man setTextColor() aufruft: mit nur einem Argument wird die Textfarbe gesetzt und Hintergrund ist transparent, bei zwei Argumenten wird Vorder- und Hintergrund gesetzt und der Hintergrund auch gefüllt. Außer bei den TT Fonts.
Johannes S. schrieb: > Bei der Adafruit_GFX kommt es darauf an wie man setTextColor() aufruft: > mit nur einem Argument wird die Textfarbe gesetzt und Hintergrund ist > transparent .setTextColor(BLACK); reicht also nicht? hast du ein Beispiel, das wusste ich nicht, ich wunderte mich nur das sich so langsam alle Pixel füllten!
:
Bearbeitet durch User
so stehts jedenfalls im Header und so funktioniert es auch bei verschiedenen Displays bei mir https://github.com/adafruit/Adafruit-GFX-Library/blob/8d7bdff6dc9dac30528469936959a446b661c8b9/Adafruit_GFX.h#L133-L154 Aber diese Lib ist für Grafikdisplays und die kann der TO bei seinem DOGM163 nicht gebrauchen.
Beitrag #6428080 wurde vom Autor gelöscht.
also statt Joachim B. schrieb: > .setTextColor(BLACK); .setTextColor(BLACK, WHITE)? hmm mal probieren, danke Funktioniert einwandfrei, danke dafür, ich sollte mal wieder anfangen Anleitungen zu lesen, fällt mir schwer weil ich ein Mann bin :)))) Johannes S. schrieb: > Aber diese Lib ist für Grafikdisplays und die kann der TO bei seinem > DOGM163 nicht gebrauchen. aber beim nokia5110 klappt das, bei anderen TFT bin ich nicht sicher, wäre zu probieren!
:
Bearbeitet durch User
Hansjörg schrieb: > Das einzige was > mich stört ist das je nach dem was für einen Befehl man an das Display > sendet gewartet werden muss. Stimmt doch garnicht. Also, nur zum Einrichten muß wirklich gewartet werden: ab Einschalten 40 ms, dann für Funktion, Oszillator, Kontrastspannung usw. jeweils etwa 30 µs und das war's dann. Die normalen Zugriffszeiten, also Byte schreiben usw. sind im unteren Nanosekundenbereich. Das längste davon ist die Zykluszeit von etwa 400..500 ns. Für all so etwas lohnt sich weder ein RTOS, noch ein Timer oder gar ein Timer+DMA - was für eine besonders grandiose Idee, insbesondere für den 4 Bit Betrieb. Nein, zum einmaligen Initialisieren darf schlichtweg per Trampelschleife gewartet werden und später ist das nicht mehr nötig. Allenfalls kann man das Busyflag auswerten um sicherzugehen. Und sowas wie ein Nachstellen des Kontrastes darf dann ruhig mal 30 µs dauern. Siehe Datenblatt vom st7036: http://www.lcd-module.de/eng/pdf/zubehoer/st7036.pdf W.S.
Hansjörg schrieb: > Die Kommunikation ist ja per SPI sehr einfach gehalten. Das einzige was > mich stört ist das je nach dem was für einen Befehl man an das Display > sendet gewartet werden muss. Wie kann ich auf einfache weiße die paar µs > warten ohne das ich ich nichts mache. > Also ich was Sinnvolles mache. > Danke für die Hilfe Das ist eine reine Effizienzbetrachtung. Es gibt einen Bereich von Wartezeiten, in dem SICHER das busywait die effizienteste Lösung ist. Und es gibt einen Bereich von Wartezeiten, bei denen SICHER eine Timer-getriebene Lösung (wie auch immer im Detail ausgeführt, kann z.B. eine Timer-ISR samt state-machine sein oder auch der Scheduler eines OS samt wartefähigem Task) die effizienteste Lösung ist. Die sicheren Bereiche kann man leicht ausrechnen, wenn man das Target, die Softwareumgebung und deren Zeitverhalten kennt. Wirklich Wert, darüber genauer nachzudenken, sind nur die Wartezeiten zwischen den beiden "SICHER"-Bereichen. Bei "µs" ist es aber nunmal leider so, dass die einen Bereich von drei Größenordnungen umfassen. Sprich: du hast nicht hinreichend über das Problem nachgedacht, insbesondere nicht über das, was für dein Target und dessen Zielumgebung als "sicher" gelten kann... Hol' das nach!
Was mir aufgefallen ist, gerade bei Display-Ansteuerung ist eine möglichst hohe Geschwindigkeit oft unnötig. Dem Benutzer bemerkt gar nicht, ob man bei sowas 30..50µs oder eine ganze Millisekunde wartet. Ich mache bei sowas daher entweder alles in Hardware oder mit irgendwelchen Wartezeiten, die gerade entstehen und auf jeden Fall lang genug sind.
Ben B. schrieb: > Was mir aufgefallen ist, gerade bei Display-Ansteuerung ist eine > möglichst hohe Geschwindigkeit oft unnötig. Dem Benutzer bemerkt gar > nicht, ob man bei sowas 30..50µs oder eine ganze Millisekunde wartet. wie schon geschrieben wurde, was soll denn der Prozzi in der verbleibenen Zeit noch alles machen? ob er 4x oder 10x pro Sekunde das Display aktualisiert welches sagen wir 1ms dauert, die Restzeit ist doch riesig
Hallo, Ihr vergesst dabei eine Sache. Die Wartezeiten addieren sich, je nach Länge der Displayausgabe. Die üblichen Libs warten mit harten delays. Wenn nebenbei zum Beispiel eine schnelle serielle Kommunikation läuft gehen Daten verloren, weil die Einlesefunktion nicht zum Zug kommt. Entweder man bekommt ein unkritisches Zeitfenster für die Displayausgabe hin. Oder man lässt den SPI Interrupt einen Buffer leeren welcher letztlich das Display bedient.
Veit D. schrieb: > Hallo, > > Ihr vergesst dabei eine Sache. Die Wartezeiten addieren sich, je nach > Länge der Displayausgabe. Die üblichen Libs warten mit harten delays. > Wenn nebenbei zum Beispiel eine schnelle serielle Kommunikation läuft > gehen Daten verloren, weil die Einlesefunktion nicht zum Zug kommt. Unsinn. Für sowas hat der liebe Gott Interrupts und Zwischenpuffer erfunden. > Entweder man bekommt ein unkritisches Zeitfenster für die Displayausgabe > hin. Oder man lässt den SPI Interrupt einen Buffer leeren welcher > letztlich das Display bedient. Und worüber reden wir denn WIRKLICH? Ein großes 4x20 LCD mit 80 Zeichen braucht bei 40us/Zeichen 3,2ms Updatezeit. Naja, nicht wirklich schnell aber auch kein Drama, wenn man das mit 10 Hz / 100ms aktualisiert, kostet halt 3,2% CPU-Zeit. Wer die Wartepausen WIRKLICH nicht mag oder gebrauchen kann schreibt in einem halbwegs schnellen Timer- Interrupt immer nur 1 Zeichen auf das LCD. Bei 1 kHz kommt man da auf 12,5Hz Updaterate mit geschätzt 5us/Zeichen bzw. 0,5% CPU Last.
W.S. schrieb: > Für all so etwas lohnt sich weder ein RTOS, noch ein Timer oder gar ein > Timer+DMA - was für eine besonders grandiose Idee, insbesondere für den > 4 Bit Betrieb. Mal wieder Leseverständnis: 6! Setzen! Hier gehts um den SPI Modus eines DOGM LCD. Anonsten ist es im Forum bekannt genug, dass du DMA nicht verstanden hast und es daher verteufelst.
Was will man denn ständig für ausgefallene Befehle an so ein 3 x 16 Text-Display schicken? Eine Updaterate höher, als 2 x die Sekunde kann keiner lesen, weil auch die LCs kaum schneller sind. Schreibst du alle 3 Zeilen 2 x die Sekunde komplett neu, dann gehen dafür keine 10 ms verloren. Also 1 % der "Arbeitszeit". - Wie schlecht ist der Rest programmiert, wenn da noch was rausgeholt werden muss?
Falk B. schrieb: > Und worüber reden wir denn WIRKLICH? Ein großes 4x20 LCD mit 80 Zeichen > braucht bei 40us/Zeichen 3,2ms Updatezeit. Naja, nicht wirklich schnell > aber auch kein Drama, wenn man das mit 10 Hz / 100ms aktualisiert, > kostet halt 3,2% CPU-Zeit. > > Wer die Wartepausen WIRKLICH nicht mag oder gebrauchen kann schreibt in > einem halbwegs schnellen Timer- Interrupt immer nur 1 Zeichen auf das > LCD. Bei 1 kHz kommt man da auf 12,5Hz Updaterate mit geschätzt > 5us/Zeichen bzw. 0,5% CPU Last. eben nur wenn ich es schreibe hagelt - Joachim B. schrieb: > wie schon geschrieben wurde, was soll denn der Prozzi in der > verbleibenen Zeit noch alles machen? > > ob er 4x oder 10x pro Sekunde das Display aktualisiert welches sagen wir > 1ms dauert, die Restzeit ist doch riesig Beitrag "Re: wie im µs Berich effizient warten"
Mw E. schrieb: > Hier gehts um den SPI Modus eines DOGM LCD. Was bist du doch für ein Blödmann, daß du nicht mal ein Manual lesen kannst. Die Periodendauer bei SPI beträgt 100 ns (und bei 3.3V 200 ns) und ist damit ebenfalls derart kurz, daß sich irgendwelches Warten per Timer/DMA und dergleichen garantiert nicht lohnt. Ein Byte ist auch per SPI in weniger als 2 µs durch und das reicht. W.S.
Hansjörg schrieb: > Wie kann ich auf einfache weiße die paar µs > warten ohne das ich ich nichts mache. > Also ich was Sinnvolles mache Lustige Frage übrigens... Der TO fragt also ernsthaft, was er in der Zeit, bis mal wieder ein Zeichen an das Display zu senden ist, Sinnvolles machen könne! Da kann die Antwort doch nur lauten: was weiße ich denn?? Wenn sein Programm also nichts anderes macht, als ab und zu ein Zeichen zu senden, woher soll dann in der "Zwischenzeit" was sinnvolles kommen? Offensichtlich verstehe ich das Problem nicht :-) Gruß Rainer
W.S. schrieb: > Was bist du doch für ein Blödmann Danke für die Freundlichkeiten ;) Der Rest des Postes ist wieder eine typische W.S. Nebelkerze, auch so lohnt sich DMA+Timer. Einmal einstellen, abfeuern und die CPU wichtigerere Dinge erledigen lassen.
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.