LCD verliert Zeichen

Die HD44780-Datenleitungen sind nun überhaupt nicht für längere 
Entfernungen gedacht. Denn da gibt's ja schon reichlich Übersprechen zw. 
den Strippen. Also ist davon auszugehen, daß alle Strippen ihren Teil 
beitragen.
Da das also vermutlich eingekoppelte Störungen auf den Datenleitungen 
sind, würde ich ganz einfach jede Datenleitung auf Anzeigenseite mit 
einem 1k (oder so) gegen Masse abschließen (solange der µC auf 
Senderseite diese Extralast noch sauber verkraftet). Falls der µC dabei 
auch was vom Display lesen muß (je nach Ansteuermodus), dann daselbe 
auch auf µC-Seite.
Und dann sollte noch gecheckt werden, ob die Betriebspannung des HD44780 
einigermaßen sauber abgeblockt ist (die µC-Seite natürlich auch).

Die üblichen Massnahmen wurden ja genannt, aber 1,5m in solch einer 
Umgebung ist sportlich, kann man aber hinkriegen.
Schneller wirst du fertig, wenn du direkt ans Display einen weiteren 
Controller packst und diesen mit einer robusten Datenverbindung 
fütterst. Setzt natürlich voraus dass du Zugriff auf die Software im 
steuernden Rechner hast.

Das Display direkt über den MC Bus über diese Distanz anzusteuern ist zu 
schnell.
Ich würde die Steuerleitungen über Port IO per SW emulieren. Notfalls 
könnte man die Leitungen mit Optokoppler potentialtrennen.

Danny schrieb:
> Grüße in die Runde,
>
> Mein LCD Display -vorher angeschlossen an 0,75 m Flachbandleitung zum
> Testen - verliert jetzt mit 1,5 m Rundflachbandleitung die Zeichen und
> wird grün, sobald ich das Gaspedal am Kart trete und die MOSFET
> schalten. Vorher ging alles 😬.

Ja, bei Sonnenschein und Windstille auf dem Basteltisch. In einer SEHR 
rauhen Umgebung, wie sie in einem Go Kart nunmal herscht, muss man dem 
EMV-Gott ein Opfer bringen.

> Von Arbeit her weiß ich, dass wir bei manchen Sachen von Rund- auf
> Flachkabel gewechselt haben weil es zu Einkopplungen von
> Nachbarleitungen kam.

Das kann man so allgemein nicht sagen. Man kann mit beiden Kabeltypen 
stabile Übertragungen erreichen oder auch das Gegenteil!

> Auf welcher Leitung würdet ihr anfangen zu suchen beim HD44780 Display ?
> Bleibt ja eigentlich nur RS, RW oder Enable oder ? R/W eigentlich auch
> nicht, da ich nur schreibe und RW auf GND ist.

Eigentlich alle, denn gestörte Datenleitungen spucken dir ebenso in die 
Suppe.

Nein, 1k Widerstände an den Leitungen gegen GND am LCD lösen das Problem 
nicht, die fressen nur Strom (5mA/Leitung bei 5V = 25mW! Klimawandel und 
so! ;-)

Die Übertragungsgeschwindigkeit zu reduzieren bringt wenig bis nichts, 
denn die ist ja schon niedrig. Und die eingekoppelten Störungen können 
dir auch bei deutlich langsamer Ansteuerung in die Suppe spucken.

Ich würde RC-Tiefpässe und Schmitt-Trigger empfehlen. Zumindest für die 
beiden kritischen Signale E und R/S. Siehe Anhang. Das Ganze muss recht 
kompakt aufgebaut werden und so nah wie möglich an dein LCD, am Besten 
hinten dran. Nur so kann man eine maximale Filterwirkung erzielen, ohne 
sich neue Störungen zwischen Filter und LCD einzufangen. Die 
Kondensatoren müssen sehr nah an die IC-Pins bzw. LCD-Pins. 20mm 
maximal, eher weniger. Aber das kriegt man auf Lochraster auch hin. Die 
Masseführung ist wichtig. Wenn du 8-Bit Ansteuerung nutzt, dann muss man 
logischerweise auch D0-D3 entsprechend filtern.

Eine serielle Ansteuerung per UART oder I2C geht auch, muss dann aber 
auch ähnlich filtern. Bei I2C bringt es wenig bis nichts, die Pull-Up 
Widerstände tierisch klein zu machen. Statt dessen schaltet man 
100-470pF an jedes der beiden Signale (SDA, SCL) NAH am Empfänger, in 
dem Fall am I2C-Adapter am LCD.

m.n. schrieb:
> Falk B. schrieb:
>> Die Übertragungsgeschwindigkeit zu reduzieren bringt wenig bis nichts,
>> denn die ist ja schon niedrig.
>
> Noch einer mit Glaskugel.

Nö, jemand mit Sachkenntnis bezüglich EMV. Aber Ok, meine Aussage ist 
unvollständig.

Die Übertragungsgeschwindigkeit **allein** zu reduzieren bringt wenig 
bis nichts,

Mit einem passenden Filter bringt das natürlich was.

HildeK schrieb:
> Was mir bei solchen Problemen als erstes einfällt:
> - Leitungen schirmen

Ja. Aber den Schirm beidseitig kurz mit GND verbinden.

Wolfgang schrieb:
> Dann kann man bei der Gelegenheit auch gleich die Anzahl der Leitungen
> deutlich reduzieren und das Ding über I2C anknoten. I2C-Adapter, die
> direkt ans Display passen, gibts vom freundlichen Chinesen.
Da I2C eigentlich auch nur als "in Geräte Verbindung" konzipiert ist 
dürfte man bei der Länge und Umgebung auch nur vom Regen in die Traufe 
kommen.

Sascha

Ich würde alle LCD Steuerleitungen mit RC filtern und den E-STROBE Puls 
verlängern und mit Oszi verifizieren. Der E-Puls ist das einzig wichtige 
Steuersignal. Solange die Setup Time Vorgaben der restlichen Signale 
eingehalten wurden müssen die Daten dann korrekt eingelesen werden.

Also, erst einmal das HD44780 Datenblatt nach den Timing Limits 
recherchieren. Die angegeben Datenvorgabezeiten müssen um die 
Funktionalität des HD44780 zu garantieren akribisch eingehalten werden. 
Nur weil es manchmal funktioniert bedeutet nicht, daß es immer geht. 
Auch sind die Kontroller verschieden.

Ganz sicher geht man nur wenn man sich immer an die Herstellervorgaben 
hält und Marken LCD kauft. Andernfalls spielt man auf eine Van-banque 
Art. Bei billigen Import LCDs weiß man übrigens nie was da an 
Controllern eingebaut wurde und inwieweit die generischen HD44780 Timing 
Vorgaben auch dort noch gültig sind. Da gibt es beachtliche Unterschiede 
bei nicht authentischen HD44780 Controllern.

Die Geschwindigkeit der Datenausgabe muß dem Kabel und RC Filter so 
angepaßt werden, daß bei allen Datenleitungen stabile H/L Verhältnisse 
herrschen bevor das E-Signal aktiv wird. Das E-Signal darf also erst die 
Daten einlesen lassen wenn alles statisch ist.

In diesen Fall muß man mit dem Oszi verifizieren wie schlimm die 
Störungen sind und das RC Filter entsprechend anpassen. Möglicherweise 
war es auch hauptsächlich nur die Timing des E-Strobe Signals. Es 
empfiehlt sich auch speziell das E-Signal mit einem Tiny-Gate 
Schmitt-Trigger zu regenerieren. Die Geschwindigkeit der Datenausgabe 
muß auch sorgfältig diesen Verhältnissen angepaßt werden. Bei Charakter 
LCDs kann man sich wegen der verhältnismäßig wenigen Datenmengen auch 
langsamere Ausgabe leisten.

Also, ohne etwas Fleiß geht es bei solchen Problemen nicht. Da muß man 
alles denken und mit Fakten arbeiten. Annehmen, dies und jenes paßt 
schon, kann gehörig in die Hose gehen.

Mein Vorschlag: Nimm Treiberbausteine.

Direkt am Controllerboard setzt Du zwei 26LS31 ein:
https://www.ti.com/lit/ds/symlink/am26ls31.pdf

In jedem Baustein sind 4 differentielle Treiber drin, die je ein 
Eingangssignal in zwei gegenläufige Ausgangssignale umsetzen.

Die schickst Du über Dein langes Kabel. GND nicht vergessen, das 
brauchst Du auch. Diese gegenläufigen ("differentiellen") Signale sind 
deutlich unempfindlicher gegenüber Störungen.

Geeignete Kabel dafür wären z.B. LAN-Kabel. Jedes Signalpaar bekommt ein 
verdrilltes Adernpaar.

Am anderen Ende setzt Du zwei 26LS32 ein:
https://www.ti.com/lit/ds/symlink/am26ls32a.pdf

Das sind die passenden Empfänger, die daraus wieder Signale machen, die 
das Display versteht.

Ja, das ist jetzt mit etwas Arbeit verbunden und mehr als nur ein 
Widerstand hier oder ein Kondensator dort. Aber es behebt die Ursache 
des Problems.

fchk

Danny schrieb:
> Hier noch ein Bild :-) von den Kondis

Du bist der Optimist vor dem Herrn! Mit DER Verkabelung in DEM 
EMV-Umfeld? Da braucht du Weihwasser, Weihrauch und ne Jungfrau im 10. 
Semester E-Technik . . . ;-)

H. H. schrieb:
> Danny schrieb:
>> 33µF Folie
>
> Völlig übertrieben, sogar kontraproduktiv.

Sind wohl eher auch 33nF.

Danny schrieb:
> Ich Prüf noch mal die PINs, irgendwie scheint da was im
> Argen zu liegen

Sieht wirklich so aus, als würden die Kondensatoren nur recht hochohmig 
geladen werden.

Gerhard O. schrieb:
> Ich würde alle LCD Steuerleitungen mit RC filtern und den E-STROBE Puls
> verlängern und mit Oszi verifizieren.

Ich auch.

Beitrag "Re: LCD verliert Zeichen"

> Der E-Puls ist das einzig wichtige
> Steuersignal. Solange die Setup Time Vorgaben der restlichen Signale
> eingehalten wurden müssen die Daten dann korrekt eingelesen werden.

NEIN! Wenn Störungen in die anderen Signale kopplen, kann und WIRD das 
auch zu falschen Buchstaben oder mehr Fehlfunktionen führen. Auch wenn 
die Datensignale VIELLEICHT mehr Störungen vertragen, sind sie NICHT 
unkritisch.

Danny schrieb:
> Sorry.....
>
> anbei Enable Oszi shot mit langem Kabel. Könnte ja auch auf GND gelegt
> werden, hängt aber am µC PIN gerade.

Was zum Geier soll man auf DEM Bild sinnvolles erkennen?

Frank K. schrieb:
> Mein Vorschlag: Nimm Treiberbausteine.

Das würde ich erst tun, wenn alle anderen Maßnahmen wirklich nicht 
reichen.

Falk B. schrieb:
> NEIN! Wenn Störungen in die anderen Signale koppeln, kann und WIRD das
> auch zu falschen Buchstaben oder mehr Fehlfunktionen führen. Auch wenn
> die Datensignale VIELLEICHT mehr Störungen vertragen, sind sie NICHT
> unkritisch.

Du hast natürlich recht. Ich bin aber von der Voraussetzung ausgegangen, 
daß durch die RC Filterung Zeitkonstante kurzzeitige Störimpulse das 
Signal nicht schnell genug verändern können und es deshalb 
zufriedenstellend funktionieren würde. Wenn dann noch mittels 
Framebuffer (wie von Stefan vorgeschlagen) das LCD regelmäßig 
aufgefrischt wird, könnte eine momentane Fehlanzeige für den Bruchteil 
einer Sekunde toleriert werden. Wenn das nicht akzeptabel ist, dann muß 
eben weiter ausgeholt werden.

Ich würde sowieso eine serielle Übertragung vorziehen. So aufwendig ist 
das nun auch wieder nicht. Mit RS485 oder CAN geht da in der Regel bei 
vernünftigen Baudraten wenig schief. Sonst muß man sowieso das Design 
des Fahrzeugs etwas in Frage ziehen und möglicherweise vorhandene 
Störverursacher bändigen. Ich Kfzs funktioniert ja der ganze 
Rattenschwanz an Modulen auch ausreichend zuverlässig.

Danny schrieb:
> die 100 ms müsste ja auch in den Oszis erkennbar sein oder nicht?

ODER NICHT! Schau dir einen Screenshot mal an!

Gerhard O. schrieb:
> Du hast natürlich recht. Ich bin aber von der Voraussetzung ausgegangen,
> daß durch die RC Filterung Zeitkonstante kurzzeitige Störimpulse das
> Signal nicht schnell genug verändern können und es deshalb
> zufriedenstellend funktionieren würde.

Aber nur dann, wenn ein passender Filter an diesen Signalen 
vorgeschaltet ist.

> Ich würde sowieso eine serielle Übertragung vorziehen. So aufwendig ist
> das nun auch wieder nicht. Mit RS485 oder CAN geht da in der Regel bei
> vernünftigen Baudraten wenig schief. Sonst muß man sowieso das Design
> des Fahrzeugs etwas in Frage ziehen und möglicherweise vorhandene
> Störverursacher bändigen. Ich Kfzs funktioniert ja der ganze
> Rattenschwanz an Modulen auch ausreichend zuverlässig.

Kann man machen, ist vielleicht auch besser, aber im Moment hat der OP 
das nicht. Ich würde das als Plan B sehen, wenn die anderen Maßnahmen, 
gescheit umgesetzt(!), nicht greifen.

Danny schrieb:
> ich habe noch einmal alles durchgemssen und es angehangen. Ich bin nach
> wie vor der Meinung, das ich nur aller 100 ms ans LCD sende. Code müsste
> ich auf anderem PC öffnen...

OK, das sieht anders aus.

> die 100 ms müsste ja auch in den Oszis erkennbar sein oder nicht?

Ja. Aber man sieht auch, daß dein Schreibvorgang "ewig" dauert.
Dein E-Puls ist ca. 200us breit! Nett, aber der braucht nur 1us, hier 
mit ilter vielleicht 5us. So dauert ein Zeichen schreiben bei dir ca. 
400us! Das Display kann das in 1/10 der Zeit! Dein ganzes update dauert 
ca. 50ms, das sind 50% der CPU Zeit! Wenn deine CPU nix besseres zu tun 
hat, OK. Aber im Allgemeinen ist das zu langsam, erst recht für 
läppische 2x16 Zeichen.

Beherzige diese Hinweise.

Beitrag "Re: LCD verliert Zeichen"
Beitrag "Re: LCD verliert Zeichen"

Die 33 Ohm Serienterminierung kann man erstmal weglassen, aber die 
Schirmung sollte man BEIDSEITG KURZ an Masse anklemmen! Kurz heißt, max. 
50mm vom Kabel bis zum Masseanschluß am Controller bzw. LCD!
Die RC-Filter etc. packt man auf eine Lochrasterplatte und lötet die 
über eine Stiftleiste parallel hinter das LCD. Auch dort alles kurz 
halten! Dein Kondensator an VCC/GND war das NICHT!!!

So nicht!

https://www.mikrocontroller.net/attachment/533347/IMG_9927.jpg

Das kriegt man mit überschaubarem Aufwand hin. Könnte reichen. Alles 
andere ist deutlich aufwändiger, sowohl Hard- als auch Software.

Danny schrieb:
>> hat, OK. Aber im Allgemeinen ist das zu langsam, erst recht für
>> läppische 2x16 Zeichen.
>
> Müsste man Quasi beim Code weiter suchen, warum das Schreiben so lange
> dauert, korrekt?

Sicher. Dort sind die Pausen zwischen den Puls- und Datenausgaben 
schlicht zu lang. Oder dein Controller läuft mit dem falschen, zu 
niedrigen Takt. Beim AVR wird gern mal die DIV8 Fuse vergessen, dann 
läuft der Controller 8 mal langsamer.

Hier mal der Filter als Lochrasteraufbau. Die blauen Signale als 
Blankdraht auf der Unterseite, die roten als isolierte Drähte darüber, 
auch auf der Unterseite. Die Stiftleiste oben muss man vorher mit etwas 
Abstand einlöten, da man von unten löten muss, wenn man nur normale, 
einseitige Lochrasterplatinen nutzt.

Helge schrieb:
> MaWin hat gleich in der ersten Antwort genau das richtige gesagt.
> Datenübertragung beginnt am Anfang vom Kabel.

Naja. Laufzeiteffekte KÖNNEN ins E-Signal reinspucken, das sieht man 
auch immer wieder bei wilden, langen Flachbandkabeln oder wildem 
Klingeldraht. Zusätzliche Ausgangstreiber und Serienterminierung sind 
nicht nötig, schon gar nicht, wenn man RD-Filter an den LCD-Eingängen 
hat, denn deren Grenzfrequenz liegt um Größenordnungen unter unter dem 
Klingeln von möglichen Leitungsreflektionenen, sie schlagen somit 2 
Fliegen mit einer Klappe. Ein Eingangsfilter mit 100R + 1n, naja, kann 
man diskutieren. Ich würde eher mehr R und weniger C wählen, wie in 
meinem Vorschlag. C7 ist viel zu groß, das braucht kein Mensch! 100nF 
reich locker! Denn das ist schließlich kein 50Hz Pufferelko und der 
Strombedarf des LCD liegt unter 1mA (ohne Hintergrundbeleuchtung).

Stefan ⛄ F. schrieb:
> 0,8V sind immer noch kein gültiges Signal.

Wenn die Beschriftung stimmt, ist es das Kontrast-Signal. Das kann also 
OK sein.

Danny schrieb:
> Wäre super, wenn ihr auch über den Code mal schauen könntet um
> herauszufinden, wo der lange Schreibvorgang her kommt.

Naja, ich hab mir das Kunstwerk mal angeschaut. Ja, das kommt mal sicher 
von einem Lehrling oder sonstigen Programmieranfänger. Scheinbar ist der 
auch BASCOM geschädigt ;-) Tonnenweise Leerzeilen, schlechte 
Quelltextformatierung, und konzeptionell, naja. Egal.

Die Ansteuerung scheint im Wesentlichen schon OK zu sein. Für das 
Schreiben eines Bytes mit WriteDataXLCD() werden je 18 Takte vor und 
nach der steigenden Flanke von E pausiert. Zumindest, wenn die Funktion 
DelayFor18TCY() das auch tut. Deine sieht so aus.

1

void DelayFor18TCY( void )

2

{

3

 int i_18;

4

 for( i_18=0;i_18<36;i_18++ )

5

 {

6

   Nop();

7

 }

8

}

Ich glaube nicht, daß die Funktion nur 18 Takte dauert, vermutlich eher 
das Doppelte bis Dreifache, incl. Aufruf und Rücksprung. Aber das 
erklärt keine 200us breiten E-Pulse. Aber das kann man leicht testen. 
Verkürze die Schleife auf 9 Durchgänge und schau dir das E-Signal an. 
Wenn sich die Pulsbreite grob halbiert, dann ist die Funktion noch 
langsamer als erwartet.
Oder mach einen direkten Test. Schalte alle Interrupts aus und lass 
diese Schleife laufen.

1

while(1) {

2

  E-auf 1

3

  DelayFor18TCY();

4

  E-auf 0

5

  DelayFor18TCY();

6

}

Dann musst du ca. 4us breite Pulse messen.

Ein weiteres Problem ist die Verwendung de Abfrage des Busy-Bits. Das 
macht kaum einer, denn es bringt wenig. Das LCD braucht für einfache 
Kommandos zum Daten schreiben nur 40us, d.h. deine 2x20 Zeichen sind in 
ca. 1600us = 1,6ms geschrieben! Bei dir dauert das ca. 50ms, das ist das 
30fache! Selbst wenn dein LCD-Update 10ms dauern würde, wäre er immer 
noch schneller als jetzt.
Man kann die Abfrage des Busy-Bits entfernen und nach jedem 
Schreibzugriff einfach 40us Pause einlegen.

Auch wenn es mit deinem EMV-Problem nix zu tun hat, empfehle ich eine 
dringende Formatierung deines Quelltextes, vor allem der Einrückung. Das 
schafft Übersicht! Danach könnte man über eine sinnvolle 
Umstrukturierung nachdenken, vor allem durch Nutzung von sinnvollen 
Funktionen. Z.B. Die Ausgabe von Zahlen in Array wird mehrfach benutzt 
und immer wieder umständlich hingeschrieben, das SCHREIT nach einer 
Funktion. itoa() ist dein Freund.

Aber unabhängig von der Software sollten die Filtermaßnahmen auch so 
wirken, egal ob das Update des LCDs schnell oder langsam läuft.

Bist du sicher, daß deine CPU mit dem richtigen Takt läuft und nicht aus 
Versehen deutlich langsamer?

Oder kann es sein, daß deine CPU mit Interrupts zugemüllt wird und 
deshalb effektiv nur sehr langsam den Code außerhalb des Interrupts 
bearbeiten kann?
Wie hoch sind denn die Interruptfrequenzen? Wieviel CPU-Last erzeugen 
die?
Lass den Test mit der Schleife oben laufen, diesmal MIT aktiven 
Interrupts.

Danny schrieb:
>> Die Ansteuerung scheint im Wesentlichen schon OK zu sein. Für das
>> Schreiben eines Bytes mit WriteDataXLCD() werden je 18 Takte vor und
>> nach der steigenden Flanke von E pausiert. Zumindest, wenn die Funktion
>> DelayFor18TCY() das auch tut. Deine sieht so aus.
>
> Grüße an alle Helfer, ich hab mich mal mit der for schleife
> beschäftigt..
>
> void DelayFor18TCY( void )
> {
>  int i_18;
>  for( i_18=0;i_18<36;i_18++ )
>  {
>    Nop();
>  }
> }
>
> 0 ist der Startwert, solange 0 <36 ist wird immer +1 erhöht bis 36
> erreicht und dann die Schleife verlassen?

Ja.

Demzufolge hab ich die 36 mal
> durch 27 ersetzt und die Zeit müsste die 3/4 sein, richtig ?

Das ist nicht die zentrale Frage. Sondern wie lange diese Funktion 
WIRKLICH dauert! Der Name sagt, sie soll 18 Takte dauern, wobei hier 
CPU-Zyklen und NICHT Oszillatorzyklen gemeint sind. Denn dein PIC hat 
zwar einen 20 MHz Quarztakt, der wird aber intern durch 4 geteilt. 4 
Quarztakte = 1 CPU-Takt. Deine CPU läuft also mit effektiv 5MHz. 18 
Takte dauern dann also  ca. 3,5us. Bei dir sehen wir aber ~200us für die 
Pulsbreite von E. Also dauert deine Funktion DEUTLICH länger! Der 
einfachste und genauest Ansatz ist, einfach eine handvoll nop() direkt 
hinzuschreiben, ohne Schleife.

1

void DelayFor18TCY( void )

2

  Nop(); Nop(); Nop(); Nop(); Nop(); 

3

  Nop(); Nop(); Nop(); Nop(); Nop(); 

4

}

Ja, das sind weniger als 18 Nop(), aber die Funktion braucht ja noch ein 
paar Takte zum Aufruf und Rücksprung. Probier mal.
Dein E-Signal sollte ca. 5us breit werden, das ist OK.

> Hab während dem Schreiben hier grad realisiert, das die Zahl als "i_18"
> deklariert ist

Ein sinnloser, irreführender Name. i reicht.

> Insofern macht die Funktion was sie soll.

Nö. Sie dauert garantiert länger als 18 Takte. Wie man das testet, 
schrieb ich bereits, aber du hast es entweder überlesen oder ignoriert.

"Oder mach einen direkten Test. Schalte alle Interrupts aus und lass
diese Schleife laufen."

> Gibt es hier noch was zu
> suchen/ verbessern mit dem langen Schreiben ?

ALLES! Du hast ja nix getestet und leider auch nix verstanden! Dein Test 
oben war nicht viel wert.

> Takt hab ich auch gemessen... Stimmt auch mit meiner 5 khz PWM und den
> anderen Berechnungen eigentlich überein.

Ok, dann liegt das Problem woanders, vermutlich bei deinen gefühlt 1000 
Interruptquellen! Ob das alles so funktioniert?

Danny schrieb:
> Grüße noch mal
>
> zu den Interrupts wie folgt:
>
> if  (PIR1bits.TMR2IF)                          //Timer 2 Interrupt 5 kHz
> each 0,2 ms (200µs)

Diese 200us sehen verdammt nach den 200us Pulsbreite bei deinem E-Signal 
aus. Irgendwas stimmt da nicht.

Danny schrieb:
> Oder muss es unbedingt die
>
> void DelayFor18TCY( void )
>
> Schleife sein ? Danke !

Du willst die Laufzeit dieser Funktion messen. Also tu es!

Danny schrieb:
> Wie folgt mit Interrupts AN durchgeführt, die Impulse sind nun circa 3
> us breit,

Das klingt plausibel, 10 Nop() + ca, 8 Takte für den call + return.

> Würde ja bedeuten der Inhalt der Schleife/ Funktion würde falsch
> abgearbeitet werden oder ???

Der Zähler muss ja auch noch verarbeitet werden. Je nach 
Compilereinstellung (Optimierung), kann das ziemlich viel Zusatzaufwand 
sein.

> Das Display zeigt jetzt nur Müll an auf der ersten Zeile wo alles
> durchläuft und die zweite Zeile bleibt leer.

Das ist schlecht. Dann musst du die Anzahl NOPs so lange hochdrehen, bis 
wieder eine Anzeige erscheint.

Auch wenn das jetzt nicht dein eigentliches Problem ist. ich hab mal 
deinen "Quältext" ein wenig aufgeräumt. Hier noch ein paar Hinweise.

- Saubere Formatierung des Quelltextes, vor allem Einrückung
- sinnlose Leerzeilen entfernt
- unständliche Umrechnung von Zahl in LCD Zeichen durch sprintf() 
ersetzt
- Fließkommarechnungen durch Festkommaarithmetik ersetzt
- ADC Zugriff weiter als Funktion gekapselt

Man könnte und müßte noch einiges aufräumen, aber das wäre deutlich 
zuviel für jetzt.

Strukturierte Programmierung auf Mikrocontrollern

http://www.amazon.de/Weniger-schlecht-programmieren-Kathrin-Passig/dp/3897215675/ref=sr_1_1?ie=UTF8&qid=1444238128&sr=8-1&keywords=weniger+schlecht+programmieren

Vor allem sollte man bei solchen Displays das Ready Signal vergessen und 
anstelle einen Delay verwenden. Ich verwende jeweils einen Display 
Buffer auf dem Controller, welcher per Timer Tick periodisch vollständig 
neu beschrieben wird. Heisst alle Zeichen werden geschrieben, auch die 
Blanks. In meinem Fall von üblicherweise 2x16 Displays ein Zeichen pro 
10ms.

Danny schrieb:
> ich werde mir den Code anschauen und hoffentlich begreifen, was besser
> geht und warum... Wie bereits gesagt, ich bin kein Vollprofi...

Sicher nicht, aber jeder hat Verbesserungspotential.

Danny schrieb:
> Ich habe 20x NOP eingefügt und das LCD zeigt nun halbwegs vernünftiges
> Zeug an bei 5µs Puls und das wichtigste bei allem, es "verliert" keine
> Zeichen. Auch dann nicht, wenn das Kart fährt :-)

> Wie gesagt, ein paar Problemchen hat die Anzeige noch so zum Bsp. beim
> Start, wo der Anfangstext teilweise fehlt,

In deinem Code wird das LCD als 2x20 behandelt, du hast aber nur 2x16 
verbaut. D.h. die letzten 4 Zeichen jeder Zeile verschwinden. Im 
ungünstigensten Fall überschreiben die jedes Mal die ersten 4 Zeichen 
der nächsten Zeile und führen zu Flimmern.

> aber ich meine, dass es das
> Timing ist, sprich der Code.. oder was meint ihr anhand anliegender
> Videos hier??

Hmm, vor allem das Video 9983 flimmert ziemlich. Ist das real auch so? 
Wenn ja, hast du immer noch ein Softwareproblem. Wenn nein, ist es eine 
Interferenz mit der Handykamera.

> Ich werde wohl doch noch zum neuen MPLAB wechseln und mich dort
> einarbeiten müssen, Da gab es auch Videos mit ADC und LCD Ausgabe..

Kann man machen, ist aber nicht das Entscheiende. Dann auch das neue 
MPLAB hat keine KI, welche dir eine gescheite Softwarestruktur erstellt.

> Ein Filter scheint damit erst einmal nicht nötig zu sein oder ?

Kann man so nicht sagen. Durch die deutlich kürzeren E-Pulse ist die 
Zeit, in welcher Störungen Unsinn machen können deutlich verkürzt, 
statistisch ist das gut. Im Einzelfall kann aber trotzdem noch eine 
Störung reinspucken.

> Hab mal ein paar Bilder angehangen, falls es jemanden näher
> interessiert.

Ein Bobbycar mit Motor ;-)
Ich sehe keine Akkus?