Hallo miteinander Ich habe ein kleines Problem mit einer LCD-Ansteuerung: Das LCD (20x4) braucht selbst zum löschen ein Delay von 2ms, und für jedes weitere Zeichen werden die Controll-Pins auch noch im us-Delay getacktet (10 bis 50us). Des weiteren werden die Funktionen so abgearbeitet, dass der ganze String in einer While-Schlaufe gesendet wird. -> ein Delay von mehreren ms ist das Resultat. (Die Funktionen habe ich aus dem Tutorial). Das eigentliche Problem ist jetzt aber, dass ich einen möglichst schnellen Programm-Durchlauf (< 10us) brauche, und dies auch erreiche. Sobald aber das LCD irgend einen neuen Text ausgibt, wird alles verzögert und somit schmiert mir eine Kommunikation und Anzeige ab. Könnte man zwischen LCD und Main-Prozessor noch einen weiteren Prozessor schalten, welcher die Control-Pins auf den externen Interrupteingängen hat? Dann eine parallele 4-Bit Kommunikation aufbauen, welche zum Ziel hat, den Main-Prozessor soweit zu entlasten, dass dort keine unnötigen verzögerungen stattfinden. Der Zusatzprozessor müsste nur einen String buffern und falls komplett ihn nur ausgeben. Gibt es so etwas überhaupt schon? Und ist dies relativ einfach realisierbar? Besten Dank für die Ratschläge MFG Patrick
Warte einfach nicht in der Ausgaberoutine bis das Delay vorbei ist. Schreibe die Zeichen und Kommandos, evtl. plus dem notwendigen Delay in einen Ringbuffer, setze nach der Ausgabe einen Timer mit dem Delay. Die davon ausgelöste ISR liest (sofern vorhanden) ein weiteres Zeichen aus dem Ringbuffer, gibt den an das LCD weiter und setzt wieder den Timer. Poste auch bitte mal den Link auf das Tutorial, wo Du das her hast.
Ein weiterer Prozessor ist unnötig. Das Programm kannst du relativ einfach anpassen, zumindest deiner Beschreibung nach zu urteilen: Es gibt eine Hauptschleife, die deine geforderte Durchlaufgeschwindigkeit hat. In der Schleife lässt du einfach zwei Variablen abfragen: 1. ob von der Schnittstelle neue Daten anliegen & 2. ob das Display sein Busy-Flag gelöscht hat. Wenn Daten anliegen, kannst du entsprechend schnell reagieren. Ist das Display fertig, kannst du einfach das nächste Bit reinschieben und in die Schleife zurückspringen. Dem Display ist es recht egal, ob die Daten "am Stück" kommen, es kann nur in der Darstellung etwas schlechter aussehen, wenn alles zu langsam wird.
warum die LCD nicht in eine zustandsmaschine packen ein 1ms takt ruft diese auf und wenn zeichen zum schreiben da sind werden die im 1ms takt rausgeschoben also daten an port legen und raus aus der statemaschine beim nächsten durchlauf die nächsten .. usw damit dauert das ausgeben zwar länger .. aber bei 20 zeichen sind das eben bissel über 20ms kann eh keiner so schnell lesen ^^ beim LCD clear ratterste eben 2-3x durch die states durch bis wieder was passieren darf aber wenn man das so macht blockiert nix ... dann brauchste vlt 5-10% der 1ms für arbeit .. der rest könnte sogar noch andere sachen machen .. zB alle 100ms( alle 100 aufrufe ..) für tasterabfragen oder so .. ist eine prima entprellung ... ohne delays oder son quark ist also vielfältig ohne das etwas blockiert
>Das eigentliche Problem ist jetzt aber, dass ich einen möglichst >schnellen Programm-Durchlauf (< 10us) brauche, und dies auch erreiche. Schon mal ausgerechnet wie viel Zeit für anderes bleibt? >Könnte man zwischen LCD und Main-Prozessor noch einen weiteren Prozessor >schalten, welcher die Control-Pins auf den externen Interrupteingängen >hat? Machen kann man viel. Ob es Sinn macht ist eine andere Frage. >Dann eine parallele 4-Bit Kommunikation aufbauen, welche zum Ziel hat, >den Main-Prozessor soweit zu entlasten, dass dort keine unnötigen >verzögerungen stattfinden. Der Zusatzprozessor müsste nur einen String >buffern und falls komplett ihn nur ausgeben. Wozu buffern? Wenn der Text konstant ist musst du ihn nicht übertragen. Schick einfach eine Textnummer und evtl. Werte in Form von ein paar Bytes. Das könnte man z.B. über SPI oder Uart machen. Wenn man dann noch die Trägheit eines LCDs nimmt dann macht es kaum Sinn mehr als 5 Screens pro Sekunde anzuzeigen. Selbst das kann man nicht mehr vernünftig ablesen.
Und vor allen Dingen: Keine Clear Screens, konstante Texte nur einmal ausgeben. Nur Werte ausgeben, die sich auch tatsächlich geändert haben. Das hat 2 Effekte: Zum einen spart es Zeit zum anderen minimiert es das Flackern Auch sehr beliebt: Programmintern einen Screenbuffer einrichten, der 1:1 dem Display entspricht. Das Programm gibt lediglich in diesen Buffer aus (tut so, als ob das das LCD wäre). Nebenbei gibt es einen Timer, in dessen regelmässigem Interrupt ein Zeichen nach dem anderen aus dem Screenbuffer an das LCD übertragen wird. Bei jedem ISR Aufruf nur 1 Zeichen, selbstverständlich. Oder auch nur bei jedem 2.ten, dann muss man überhaupt nicht warten. Bei allen geraden Aufrufen wird das Zeichen ausgegeben und Enable hoch. Bei allen ungeradem kommt dann der Enable wieder auf low.
Testotuxl schrieb: > In der Schleife lässt du einfach zwei Variablen abfragen: 1. ob von der > Schnittstelle neue Daten anliegen & 2. ob das Display sein Busy-Flag > gelöscht hat. ?? Welches Busy-Flag? block schrieb: > aber bei 20 zeichen sind das eben bissel über 20ms > kann eh keiner so schnell lesen beim erwähnten 20x4 Display würde das aber etwas bei ~80ms betragen, und dies ist schon sichtbar. holger schrieb: >>Das eigentliche Problem ist jetzt aber, dass ich einen möglichst >>schnellen Programm-Durchlauf (< 10us) brauche, und dies auch erreiche. > > Schon mal ausgerechnet wie viel Zeit für anderes bleibt? Da bleibt reichlich Zeit, da ich parallel immerhin ca 4k Byte in 8ms engegennehme, verarbeite und buffere. Dazu kommen LED's, DA-Wandler und sonstien krimskrams. holger schrieb: > Wenn man dann noch die Trägheit eines LCDs nimmt dann macht es kaum Sinn > mehr als 5 Screens pro Sekunde anzuzeigen. Selbst das kann man nicht > mehr > vernünftig ablesen. Wäre auch nicht nötig. Ich habe bis jetzt alles so Aufgebaut, dass das LCD nur neu beschrieben wird, falls sich auch wirklich etwas geändert hat, was am lCD angezeigt wird. Somit existiert kein Flackern. Das beschreiben bremmst aber der ganze Rest vom Programm. Karl heinz Buchegger schrieb: > Keine Clear Screens ?? Ah, ok. An den Anfang des LCD springen und überschreiben. Ist aber gefährlich, da eventuell ein Zeichen überflüssigerweise stehen bleiben könnte. block schrieb: > warum die LCD nicht in eine zustandsmaschine packen Hatte ich mir auch schon gedacht, aber dann müsste ich sämmtliche Delays mit einem Timer verknüpfen. Erstmals danke nochmals für die vielen Antworten. Der LCD-Text basiert auf fixen Zuständen, die einfach ausgegeben werden (im Styl: Einheit blabla aktiv, Einheit xy inaktiv...). Daher habe ich mir auch schon überlegt, die ganze LCD-Ansteuerung auf einen anderen Prozessor zu verlagern und über ein Port die Zustände abfragen, und entsprechend ausgeben. MFG Patrick
Patrick B. schrieb: > Testotuxl schrieb: >> In der Schleife lässt du einfach zwei Variablen abfragen: 1. ob von der >> Schnittstelle neue Daten anliegen & 2. ob das Display sein Busy-Flag >> gelöscht hat. > > ?? Welches Busy-Flag? Das vom LCD. Ja, auch das LCD hat ein Busy Flag mit dem man das LCD fragen kann, ob es beschäftigt ist. > beim erwähnten 20x4 Display würde das aber etwas bei ~80ms betragen, und > dies ist schon sichtbar. Nö. Mit Sicherheit nicht. Wenn du auf dem LCD noch was lesen kannst, wenn du 5 Updates in der Sekunde machst, bist du schon gut. * die Dinger leuchten nach wie Sau * du musst die Information als Mensch ja auch aufnehmen können > Erstmals danke nochmals für die vielen Antworten. > Der LCD-Text basiert auf fixen Zuständen, die einfach ausgegeben werden > (im Styl: Einheit blabla aktiv, Einheit xy inaktiv...). Daher habe ich > mir auch schon überlegt, die ganze LCD-Ansteuerung auf einen anderen > Prozessor zu verlagern und über ein Port die Zustände abfragen, und > entsprechend ausgeben. Die Kommuniktion kriegst du auch nicht gratis. Der Ansatz wird zwar gerne verfolgt, ist aber auch gerne einfach nur Mumpiotz. Die Dinge werden meistens nicht einfacher je mehr Prozessoren man einsetzt. Schlechtes Zeitmanagement kann man auch mit vielen Prozessoren nicht in den Griff kriegen. Gerade ein LCD ist ja von der Sorte: Ist alles nicht zeitkritisch, länger ist immer erlaubt. Abarbeiten in einer ISR im Hintergrund ist kein Problem.
Patrick B. schrieb: > Erstmals danke nochmals für die vielen Antworten. > Der LCD-Text basiert auf fixen Zuständen, die einfach ausgegeben werden > (im Styl: Einheit blabla aktiv, Einheit xy inaktiv...). Daher habe ich > mir auch schon überlegt, die ganze LCD-Ansteuerung auf einen anderen > Prozessor zu verlagern und über ein Port die Zustände abfragen, und > entsprechend ausgeben. dann machs über einen anderen Prozessor aber da must du auch die daten wegschaufeln .. sei es über TWI oder SPI .. überall ist das selbe prinzip ... zb: UART , TWI , SPI daten ins register ; while ( warten bis weg ) ; // <-- hauptproblem oder dein LCD : daten an port while( !busy() ); das ist quasi das selbe hauptproblem ... wichtiger wäre herrauszubekommen warum der LCD kram überhaupt stören kann ... wenn man zeitkritische sachen macht .. bitte in eine ISR werfen ... und LCD kram in die main .. da kann es delayen wie es mag ...
Leg ein Feld mit 4 x 20 Zeichen an. Eine Ausgaberoutine alle 100 µs gibt das nächste Zeichen aus (0-19) bei Überlauf neue Displayadresse (SetCursor). Die 100 µs reichen dem Display locker und ein kpl. Screen braucht 8,4 ms. Die 100 µs kannst du aber locker hochsetzen, z.B. auf 500. Diese Ausgabe läuft grundsätzlich! Deine Ausgaben schreibst du in dieses Array. avr
block schrieb: > wenn man zeitkritische sachen macht .. bitte in eine ISR werfen ... > und LCD kram in die main .. da kann es delayen wie es mag ... eine ISR im Bereich von 1 bis 10us!!!! Das wird nie und nimmer funktionieren. Der Prozessor muss jedesmal auch noch zuerst alles zwischenspeichern, bevor er in die ISR springt. -> Noch mehr Zeitverluste. genau aus diesem Grund habe ich sämmtliche Funktionen auf dem State-Machine-Prinzip aufgebaut. So habe ich keine unnötigen Wartezeiten. Karl heinz Buchegger schrieb: > Wenn du auf dem LCD noch was lesen kannst, wenn du 5 Updates in der > Sekunde machst, bist du schon gut. Ich mache auch nicht 5 Updates pro Sekunde. Nach wie vor wird das LCD normalerweise alle 5 Sekunden neu beschrieben. Aber alle 5 Sekunden generiert mir die LCD-Funktion eine verzögerung von ~5ms, welche ich nicht gebrauchen kann. Karl heinz Buchegger schrieb: > Das vom LCD. > Ja, auch das LCD hat ein Busy Flag mit dem man das LCD fragen kann, ob > es beschäftigt ist. Ok, jetzt weiss ich definitiv nicht wie ich das auslesen kann. Es gibt ja noch eine Read-Funktion, aber die habe ich noch nie genutzt. MFG Patrick
@ Patrick B. (p51d) >eine ISR im Bereich von 1 bis 10us!!!! Das wird nie und nimmer >funktionieren. Der Prozessor muss jedesmal auch noch zuerst alles >zwischenspeichern, bevor er in die ISR springt. -> Noch mehr >Zeitverluste. Schon klar. Aber was willst du denn eigentlich machen? 10us als Schleifenzeit ist VERDAMMT schnell. Sag was du eigentlich machen willst, dann kann man dir schnell helfen, ohne endloses, sinnloses, nervtötendes, pseudophiloisopisches Gelaber. Siehe Netiquette. MFG Falk
>Aber alle 5 Sekunden >generiert mir die LCD-Funktion eine verzögerung von ~5ms, welche ich >nicht gebrauchen kann. Wie lang darf es denn sein? 5ms, da kann man aber schon einige Zeichen ausgeben. Der Trick ist einfach eben nicht alles am Stück zu schreiben, und erst einmal im RAM zu puffern. Delay Zeiten die das LCD braucht mit sinnvolleren Aktionen zu füllen. ClearScreen meiden wie der Teufel das Weihwasser. Kann man alles mit überschreiben machen. Es ist eigentlich nur eine Frage der Organisation. Mit den Standard LCD Libs kommt man da allerdings nicht weit. >> Ja, auch das LCD hat ein Busy Flag mit dem man das LCD fragen kann, ob >> es beschäftigt ist. >Ok, jetzt weiss ich definitiv nicht wie ich das auslesen kann. Es gibt >ja noch eine Read-Funktion, aber die habe ich noch nie genutzt. Vergiss es. Busy Flag, was ist das? Braucht kein Mensch.
Falk Brunner schrieb: > Schon klar. Aber was willst du denn eigentlich machen? 10us als > Schleifenzeit ist VERDAMMT schnell. ok, es scheint als hätte ich mich unklar ausgedrückt, und ich entschuldige mich dafür. Ich möchte eine möglichst rasche Loop-Zeit im main beibehalten <=10us. Das habe ich auch (der Prozi läuft mit 120MHz), da das eventuelle Auslesen des RX-Buffers des FT245 sowie das eventuelle Beschreiben des TX-Buffer (Jeweils max 1 Zeichen pro Durchlauf) sowie DA-Wandler ansteuern und LEDs setzen in diesem Zeitrahem passiert. Alles wird einfach ausgeführt, falls eine Änderung des Zustandes eintritt. Dazu kommt jetzt ein LCD, welche gewisse Informationen ausgeben soll. Dies geschiet ebenfalls im 0.2Hz Takt. Aber das Beschreiben des LCD's mit einem ganzen String kostet mich in der While-Schlaufe des lcd_write() schon 4.4ms für alle Zeichen + 2ms zum löschen. Das macht eine Verzögerung von >6ms für die LCD-Ausgabe welche alle 5 Sekunden erneuert wird. Die Durchlaufszeit des Programms darf aber nicht unbedingt viel grösser als 10-12us sein. Wie beschreibe ich das Programm am besten... Multithreading triffts wohl am besten. Parallel werden mehrere Sachen erledigt (die aktualisierung der DA-Wandler wird mit ~30kHz vorenommen. Da eine ISR dafür ebenfalls nicht geeignet ist, müssen die gestreamten Daten vom PC engegengenommen werden und entsprechend dann die DA-Wandler setzen). Ich werde mahl versuchen die ganzen Delays weg zu bringen, und statt-dessen auf einen Timer abfragen und aus einer Buffer-Array die entsprechenden Daten für das LCD herauslesen. MFG Patrick
deswegen keine while zum scxhreiben sondern ein buffer der bei jedem durchlauf weiter geleert wird dein durchlauf von 10ns bleibt erhalten da hier nur 1 zeichen ausgegeben wird .. auch beim lcd clear wird eine zyklenanzahl gewartet anstelle einer while zum warten es kann so einfach sein ..
block schrieb: > deswegen keine while zum scxhreiben > > sondern ein buffer der bei jedem durchlauf weiter geleert wird > dein durchlauf von 10ns bleibt erhalten da hier nur 1 zeichen ausgegeben > wird .. > auch beim lcd clear wird eine zyklenanzahl gewartet anstelle einer while > zum warten > > es kann so einfach sein .. ok, aber ich müsste es wohl noch etwas auftrennen. Pro durchgang max 1 Nibble senden, da zwischen den Nibbles wiederum etwa 30us Delay ist. Und dann immer schön auf einen Timer abfragen um die Zeiten ungefähr einhalten zu können. Tja, der Witz ist ja, dass ich das schon so bei der ganzen FTDI-Ansteuerung mache... Aber danke nochmals für die Antworten... MFG Patrick
Handle Dein LCD doch einfach exakt genauso wie Deinen FT245, insbesondere dessen TX Buffer. Wenn es was auszugeben gibt screibst Du in jedem Durchlauf genau 1 Zeichen aufs LCD und machst weiter. Beim nächsten Durchlauf dann das nächste Zeichen. Wenn Dein LCD da nicht mitkommt, dann halt nicht bei jedem Durchlauf, sondern nur bei jedem 5.,10.,20.,was auch immer, je nachdem wie langsam Dein LCD halt ist. etwas so z.B.:
1 | extern lcd_out_char(uint8_t zeile, uint8_t spalte, char c); |
2 | |
3 | {
|
4 | char lcd_buffer[4][20]; |
5 | uint8_t zeile = 0; |
6 | uint8_t spalte = 0; |
7 | int intervall = 0; |
8 | |
9 | memset(lcd_buffer, 0, 4*20); // clear screen :) |
10 | |
11 | while(1) |
12 | {
|
13 | i++; |
14 | // tu was
|
15 | memset(&lcd_buffer[0], 0, 20); // clear line :) |
16 | sprintf(&lcd_buffer[0], "foo%d", intervall); |
17 | // tu mehr
|
18 | memset(&lcd_buffer[1], 0, 20); // clear line :) |
19 | strcpy(&lcd_buffer[1], "bar"); |
20 | |
21 | // tu noch mehr
|
22 | |
23 | if(intervall) |
24 | {
|
25 | intervall-- |
26 | }
|
27 | else
|
28 | {
|
29 | char c = lcd_buffer[zeile][spalte]; |
30 | lcd_out_char(zeile, spalte, c ? : ' '); |
31 | spalte++; |
32 | if(spalte >= 20) |
33 | {
|
34 | zeile++; |
35 | spalte = 0; |
36 | if(zeile >= 4) |
37 | {
|
38 | zeile = 0; |
39 | }
|
40 | }
|
41 | intervall = 100; |
42 | }
|
43 | }
|
44 | }
|
Haben aber schon etliche Leute hier vorgeschlagen.
Patrick B. schrieb: > ok, aber ich müsste es wohl noch etwas auftrennen. Pro durchgang max 1 > Nibble senden, da zwischen den Nibbles wiederum etwa 30us Delay ist. > Und dann immer schön auf einen Timer abfragen um die Zeiten ungefähr > einhalten zu können. Timer abfragen brauchst du nicht wenn du vorher weißt das dein durchlauf 10us dauert .. schreibst du jedesmal erst beim 3ten durchlauf wieder weiter ... wenn ein lcd clear komm eben erst nach 200 durchläufen wenn du konstante texte hast legst du diese brav ab und machst dir ein array mit den zeigern mit enums schicke namen geben ... und in deiner anwendung übergibst du deiner lcd write nur den zeiger deine lcd write schnappt sich den und pinselt zB im 50us takt drauf los
@Patrick B. (p51d) >Ich möchte eine möglichst rasche Loop-Zeit im main beibehalten <=10us. >Das habe ich auch (der Prozi läuft mit 120MHz), Hoppla, das ist aber flott!!! Was wird das denn? >Wie beschreibe ich das Programm am besten... Multithreading triffts wohl >am besten. Siehe Multitasking. >statt-dessen auf einen Timer abfragen und aus einer Buffer-Array die >entsprechenden Daten für das LCD herauslesen. Wozu Timer? Wenn deine Schleife mehr oder weniger fest 10us hat, kannst du das vollkommen strukturiert in deine State Machine einbauen, wie schon mehrfach gesagt. Allerding scheint mir deine CPU schon ARG ausgelastet, vor allem weil du schon strake Echtzeitforderungen hast. Was wird das denn am Ende. Möglicherweise machst zu zu viel per CPU. Die meisten 120 MHz CPUs haben DMA, der sollte man das Datenschaufeln überlassen. MFG Falk
Falk Brunner schrieb: > Hoppla, das ist aber flott!!! > Was wird das denn? Die DA-Wandler steuern Farbkanäle und Glavos. Und die Galvos geben dann auch ihre aktualisierung vor. 30kHz. Falk Brunner schrieb: > Die > meisten 120 MHz CPUs haben DMA, der sollte man das Datenschaufeln > überlassen. Nein, leider hat dieser (ds30F6012A) keinen DMA-Kanal. Er wird auch nur per interner PLL auf 120MHz gebracht. Extern ist ein 15MHz Quarz angeschlossen. Falk Brunner schrieb: > Allerding scheint mir deine CPU schon ARG > ausgelastet Das war auch meine Begründung zum Ursprungsgedanke mit einem anderen Prozessor: Der Main-Prozessor gibt an das Port einfach ein Wert, welcher dann vom anderen ausgewertet wird und schliesslich dementsprechen nur noch das LCD-Angesteuert wird. MFG Patrick
@ Patrick B. (p51d) >Prozessor: Der Main-Prozessor gibt an das Port einfach ein Wert, welcher >dann vom anderen ausgewertet wird und schliesslich dementsprechen nur >noch das LCD-Angesteuert wird. Klingt in diesem Fall vernünftig. Eine Softwarelösung wird sehr krampfig. MfG Falk
Macht am Ende kaum einen Unterschied. Ob man alle paar Schleifendurchläufe ein Byte aufs LCD schiebt oder über irgendeine andere Schnittstelle ist eigentlich Jacke wie Hose. Mit einem zweite Prozessor wird das Ganze nur wesentlich komplexer und man muß sich auch noch um deren Synchronisation kümmern. Der zweite Prozessor kann halt auch nicht schneller aufs LCD zugreifen.
@ ... (Gast) >Macht am Ende kaum einen Unterschied. Ob man alle paar >Schleifendurchläufe ein Byte aufs LCD schiebt oder über irgendeine >andere Schnittstelle ist eigentlich Jacke wie Hose. Nö. Einen Messwert schreibt man auf einen Port und fertig.
Das scheint mir kein Fall von "Der Prozessor schaffts nicht" als vielmehr von "Der Programmierer kanns nicht" zu sein...
Was mir spontan noch einfällt, wie hast du das LCD angeschlossen? Natürlich weiß ich nicht, wie viele IOs du noch frei hast. Probiere bei deiner Anwendung doch einfach mal, das LCD mit 8 Bit anzuschließen. Dann entfällt schonmal die Wartezeit zwischen zwei Nibbles. Das komplette Display musst du nur beim Programmstart einmalig beschriften. Wenn sich später ein Messwert ändert, springst du einfach zu der Stelle und schreibst die 1-2 Zeichen einfach über die alten, ohne löschen o.ä. Hast du Messwerte mit mehreren Stellen, füllst du bei schwankender Zahlenlänge (durch Rundung z.B.) einfach mit "0" oder " " auf, um alte Stellen sicher zu überschreiben. Bis jetzt hatte ich nur mit Atmegas <20 MHz zu tun, deswegen fehlt mir die Erfahrung in deinem Einsatzbereich. Trotzdem würde ich behaupten, dass du die Statusausgabe in deiner Statemachine noch unterbringen kannst. Und irgendwie habe ich das Gefühl, das mindestens 20 Leute meine "Ideen" schon vor mir hatten ;)
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.