mikrocontroller.net

Forum: Compiler & IDEs LCD zu langsam für Main-Prozessor


Autor: Patrick B. (p51d)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Grrrr (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Testotuxl (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: block (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: holger (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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.

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Patrick B. (p51d)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: block (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 ...

Autor: avr (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Patrick B. (p51d)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@  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

Autor: holger (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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.

Autor: Patrick B. (p51d)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: block (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 ..

Autor: Patrick B. (p51d)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: ... (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.:

extern lcd_out_char(uint8_t zeile, uint8_t spalte, char c);

{
  char lcd_buffer[4][20];
  uint8_t zeile = 0;
  uint8_t spalte = 0;
  int intervall = 0;

  memset(lcd_buffer, 0, 4*20);    // clear screen :)

  while(1)
  {
    i++;
    // tu was
    memset(&lcd_buffer[0], 0, 20);    // clear line :)
    sprintf(&lcd_buffer[0], "foo%d", intervall);
    // tu mehr
    memset(&lcd_buffer[1], 0, 20);    // clear line :)
    strcpy(&lcd_buffer[1], "bar");

    // tu noch mehr

    if(intervall)
    {
      intervall--
    }
    else
    {
      char c = lcd_buffer[zeile][spalte];
      lcd_out_char(zeile, spalte, c ? : ' ');
      spalte++;
      if(spalte >= 20)
      {
        zeile++;
        spalte = 0;
        if(zeile >= 4)
        {
          zeile = 0;
        }
      }
      intervall = 100;
    }
  }
}

Haben aber schon etliche Leute hier vorgeschlagen.

Autor: block (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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

Autor: Patrick B. (p51d)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@  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

Autor: ... (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@  ... (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.

Autor: Nana (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das scheint mir kein Fall von "Der Prozessor schaffts nicht" als 
vielmehr von "Der Programmierer kanns nicht" zu sein...

Autor: Leo-andres H. (leoloewe)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 ;)

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.