Forum: Mikrocontroller und Digitale Elektronik LCD verliert Zeichen


von Danny (Gast)



Lesenswert?

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 😬.

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

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.

Würden paar Foliekondis helfen? Wie sind eure Erfahrungen so dazu, ich 
mit langen Leitungen?

Danke an alle.

von MaWin (Gast)


Lesenswert?

Danny schrieb:
> Auf welcher Leitung würdet ihr anfangen zu suchen

Alle.

Flachbandleitung impedanzrichtig abgeschlossen mit je einer Masseleitung 
zwischen den Signalleitungen und mehreren VCC Leitungen am Rand, 
abgeschirmt.

Übertragungsgeschwindigkeit reduzieren.

von Jens G. (jensig)


Lesenswert?

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).

: Bearbeitet durch User
von m.n. (Gast)


Lesenswert?

Danny schrieb:
> Würden paar Foliekondis helfen? Wie sind eure Erfahrungen so dazu, ich
> mit langen Leitungen?

Keine Kondensatoren. Nimm Abschlusswiderstände gegen GNG oder VCC und 
verlangsame die Ansteuerung.

von Stefan F. (Gast)


Lesenswert?

Was genau heißt "verliert die Zeichen"?

von m.n. (Gast)


Lesenswert?

Stefan ⛄ F. schrieb:
> Was genau heißt "verliert die Zeichen"?

Die fallen vorne aus dem Glas raus. Meistens sind es Ziffern,

von H.Joachim S. (crazyhorse)


Lesenswert?

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.

von Gerald K. (geku)


Lesenswert?

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.

von Wolfgang (Gast)


Lesenswert?

Gerald K. schrieb:
> Ich würde die Steuerleitungen über Port IO per SW emulieren. Notfalls
> könnte man die Leitungen mit Optokoppler potentialtrennen.

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.

von Danny (Gast)


Lesenswert?

Grüße an alle und vielen Dank für die zahlreichen Hinweise.

Da es ja ohne Umrichter läuft sollte die Ansteuerung ja passen… über 
einen Taster am Lenkrad kann ich das Display umschalten, das es eine 
andere „Seite“ mit Werten anzeigt. Das geht auch alles und deshalb ist 
der Rundleiter eigentlich m.M. nicht die Ursache…

Der Motor wird vermutlich durch die Bürsten und den Strom (im 
Fahrbetrieb bis zu 70 A kurzzeitig) sowie der partiellen Nähe zum Kabel 
die Ursache sein. Ich werde noch mal das Kabel umverlegen, um zu sehen, 
ob es dann geht und melde mich noch mal.

Danke.

von Danny (Gast)


Lesenswert?

Die Schnittstelle vom designed Controllerboard ist leider gegeben, damit 
ist mit I2C etc. nichts drin

Max. eben ein paar „Lastwiderstände“ auf der LCD Seite…

von Falk B. (falk)


Angehängte Dateien:

Lesenswert?

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.

von m.n. (Gast)


Lesenswert?

Gerald K. schrieb:
> Das Display direkt über den MC Bus über diese Distanz anzusteuern ist zu
> schnell.

MC Bus? Was soll das sein?

Falk B. schrieb:
> Die Übertragungsgeschwindigkeit zu reduzieren bringt wenig bis nichts,
> denn die ist ja schon niedrig.

Noch einer mit Glaskugel.

von Falk B. (falk)


Lesenswert?

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.

von HildeK (Gast)


Lesenswert?

Was mir bei solchen Problemen als erstes einfällt:
- Leitungen schirmen
- quellseitig alle Signale mit z.B. 33Ω serienterminieren.

Gerne dann noch das RC-Glied am Ende der Leitung.

von Falk B. (falk)


Lesenswert?

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

Ja. Aber den Schirm beidseitig kurz mit GND verbinden.

von Sascha W. (sascha-w)


Lesenswert?

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

von m.n. (Gast)


Lesenswert?

HildeK schrieb:
> - Leitungen schirmen
> - quellseitig alle Signale mit z.B. 33Ω serienterminieren.

Die HD44780 werden  mit µs-Signalen angesteuert. Da bringen 33 Ohm 
nichts.
Aber ein Schirm ist Pflicht.

Was ich befürchte, daß Elektronik und Display jeweils Massekontakt zum 
Metallrahmen haben. Das wäre für Störungen das gefundene Fressen.

@TO:
Welchen µC verwendest Du und mit welchen Leitungen steuerst Du das LCD 
an?
Ich vermute einen AVR mit seinen Portleitungen.
Kannst Du das Timing der LCD-Ansteuerung verändern oder gibt es nur eine 
fertige LIB?

von MaNi (Gast)


Lesenswert?

Man könnte sich auch überlegen die Signale differentiell zu übertragen. 
Kostet halt ein paar Differential Line Driver/Receiver und fast doppelt 
so viele Leitungen.
Leitungen paarweise verdrillt mit Schirm.

von Harry (Gast)


Lesenswert?

Sascha W. schrieb:
> 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.
Hab ich bis 2.5m in Motorrädern im Einsatz (über USB-Kabel) und hatte 
noch nie Probleme.

von -gb- (Gast)


Lesenswert?

Da es sich um ein Fahrzeug handelt sollte der CAN Bus verwendet werden. 
Differentiell und störsicher. Da kann man dann auch UART drüber 
sprechen.

von HildeK (Gast)


Lesenswert?

m.n. schrieb:
> Die HD44780 werden  mit µs-Signalen angesteuert. Da bringen 33 Ohm
> nichts.

Was hat das mit µs-Signalen zu tun?
Weiter unten vermutest du ja eine Ansteuerung mit einem AVR und da sind 
die Flanken mit Sicherheit im Bereich von deutlich weniger als 20ns für 
Rise- und Falltime unterwegs. Das ist dann längst relevant für Leitungen 
mit ca. 1.5m.

von Danny (Gast)


Lesenswert?

Ein Pic18f4580 ist in Betrieb

Masse gibt es nicht am Rahmen oder so und der Motor ist „isoliert“, also 
auch kein Massebezug wegen vorwärts und Rückwärts

von Stefan F. (Gast)


Lesenswert?

Danny schrieb:
> Da es ja ohne Umrichter läuft sollte die Ansteuerung ja passen…

So gerade eben mit Glück. Das sagt nichts darüber aus, dass die 
Schaltung stabil läuft.

Löse dich von der Einstellung "ich habe ja alles richtig gemacht", denn 
das verleitet zu schlampigem Arbeiten der Art: Alls was ich "ja richtig" 
gemacht habe, brauche ich nicht zu kontrollieren.

Dabei würde ein Oszilloskop den Fehler sofort zeigen, da bin ich absolut 
sicher.

von Danny (Gast)


Angehängte Dateien:

Lesenswert?

Grüße zurück,

ich hatte mal Zeit zum messen..

Als erstes hab ich 47µ Elko und 33µF Folie an PIN 1+2 der Versorgung 
nachgerüstet. Das komische war, dass unmittelbar nach der Init und 1 s 
Anzeige vom Text das Display grün (Eingangthread) wurde und die Zeichen 
"verloren" hatte. Kondis raus, LCD läuft über lange Zeit ....

Dann hab ich am 60 cm Flachband die Signale und dann am 150 cm 
Rund-Flachkabel am Display ohne Umrichter ON gemessen wie anliegend. 
Latsch ich aufs Gas, ohne angeschlossenen Motor, zählt Duty cycle im 
Display hoch. So far so good..

Die Signale würde ich als nicht zu schlecht in der Qualität einschätzen. 
Was denkt Ihr dazu? Ich update aller 100 ms das Display..

Wo liegt der Hase -an welcher Leitung- begraben, dass das Display 
plötzlich "grün" wird? Möglicherweise ist die Übertragung ja (grad noch) 
so möglich..

Danke an alle

von Danny (Gast)


Angehängte Dateien:

Lesenswert?

Hier noch ein Bild :-) von den Kondis

von Stefan F. (Gast)


Lesenswert?

Beantworte doch erstmal die bereits gestellten Fragen, sonst drehen wir 
uns im Kreis.

Es wurde bereits gesagt, dass besonders die Stromversorgung und das 
Enable-Signal relevant sind.

Außerdem hatte ich gefragt was "Buchstaben fallen heraus" bedeutet. 
jetzt ergänze ich, dass "wird grün" ebenso wenig aussagekräftig ist.

Heutzutage fotografieren Leute jeden Scheiß detailliert, aber da wo es 
wirklich sinnvoll wäre kommen sie selbst nach wiederholten Rückfragen 
nicht drauf. Tsss.

von Gerhard O. (gerhard_)


Lesenswert?

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.

von H. H. (Gast)


Lesenswert?

Danny schrieb:
> 33µF Folie

Völlig übertrieben, sogar kontraproduktiv.

von Danny (Gast)


Angehängte Dateien:

Lesenswert?

Sorry.....

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

Versorgung müsste ich nochmal messen....

anbei das "grün" werden, guckst Du bitte hier:
https://drive.google.com/file/d/1EFB-KY4dkZYYcNPmKd-x30GTAdUAkmsF/view?usp=sharing

So wird das grün, auch mit Kondensatoren direkt an den Pins sofort

Danke.

von Stefan F. (Gast)


Lesenswert?

Danny schrieb:
> anbei Enable Oszi shot mit langem Kabel.

Ich sehe das kein vernünftiges Signal. Nur zufällige Peaks und einen 
Ruhepegel um 0.8V, was auf keinen Fall Sinn ergibt weil das weder HIGH 
noch LOW ist.

Im Video scheint der Text-Inhalt des Display plötzlich gelöscht zu 
werden. Das kann die Folge eine Kommunikationsstörung sein, aber auch 
ein Aussetzer in der Stromversorgung. Vielleicht ganz banal ein 
Wackelkontakt?

Abgesehen von dem Fehler fällt mir auf, dass das Display ununterbrochen 
flimmert. Kann es sein, dass es fortlaufend gelöscht und neu beschrieben 
wird?

Mache das anders: Richte dir einen Puffer im RAM ein (2 mal 16 char), 
den du beliebig oft beschreibst aber nur alle 300ms an das Display 
sendest ohne das "Bild" vorher zu löschen. Dann flimmert es nicht mehr 
und der Kontrast wird besser.

von Frank K. (fchk)


Lesenswert?

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

von Danny (Gast)


Lesenswert?

Ja, du hast recht…..  Hab das mit R/W verwechselt, was auf GND gelegt 
werden kann. Ich Prüf noch mal die PINs, irgendwie scheint da was im 
Argen zu liegen

von Falk B. (falk)


Lesenswert?

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 . . . ;-)

von Teo D. (teoderix)


Lesenswert?

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.

von Falk B. (falk)


Lesenswert?

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.

von Stefan F. (Gast)


Lesenswert?

Danny schrieb:
> Ja, du hast recht…..  Hab das mit R/W verwechselt, was auf GND gelegt
> werden kann.

Nicht kann, sondern muss. 0.8V (mit Peaks) sind kein gültiger Pegel. Das 
ist weder HIGH noch LOW.

von Falk B. (falk)


Lesenswert?

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?

von Falk B. (falk)


Lesenswert?

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

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

von Danny (Gast)


Angehängte Dateien:

Lesenswert?

Hallo zusammen,

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...

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

Danke.

von Gerhard O. (gerhard_)


Lesenswert?

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.

: Bearbeitet durch User
von Falk B. (falk)


Lesenswert?

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

ODER NICHT! Schau dir einen Screenshot mal an!

von Falk B. (falk)


Lesenswert?

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.

von Falk B. (falk)


Lesenswert?

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.

von Danny (Gast)


Lesenswert?

Grüße, Naja, ich habe den Code von einem Lehrprojekt partiell übernommen 
und angepasst.

Sorry... wenn ich Programmierer oder Vollblut Elektroniker wäre, würde 
ich dies beruflich machen und nicht auf diesem Level.. Darum bitte ich 
Euch, mich nicht mit ein paar Krümeln Brot im Wald stehen zu lassen.

Vielen Dank für euer hoffentliches Verständnis.

von Danny (Gast)


Lesenswert?

Falk B. schrieb:
> 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.

Müsste man Quasi beim Code weiter suchen, warum das Schreiben so lange 
dauert, korrekt?

von Falk B. (falk)


Lesenswert?

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.

von Stefan F. (Gast)


Lesenswert?

Danny schrieb:
> ich habe noch einmal alles durchgemssen und es angehangen.

0,8V sind immer noch kein gültiges Signal.

> Ich bin nach wie vor der Meinung, das ich nur aller 100 ms
> ans LCD sende.

Kann gut sein. Wenn du dabei den "clear" Befehl benutzt, flackert das 
Display. Der Trick besteht darin, auf "clear" zu verzichten.

> Müsste man Quasi beim Code weiter suchen, warum das
> Schreiben so lange dauert, korrekt?

Ja, aber kümmere dich erstmal um die Fehlfunktionen.

von Falk B. (falk)


Angehängte Dateien:

Lesenswert?

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.

von Helge (Gast)


Angehängte Dateien:

Lesenswert?

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

von Falk B. (falk)


Lesenswert?

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).

von Dietrich L. (dietrichl)


Lesenswert?

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.

von Stefan F. (Gast)


Lesenswert?

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

Dietrich L. schrieb:
> Wenn die Beschriftung stimmt, ist es das Kontrast-Signal. Das kann also
> OK sein.

Ja, als Kontrastspannung ist das Bild plausibel.

Oh, ich dachte es sei immer noch das Enable bzw. R/S Signal, weil es wie 
im vorherigen Beitrag aussieht:

Danny schrieb:
> anbei Enable Oszi shot mit langem Kabel

Danny schrieb:
> Hab das mit R/W verwechselt

von Danny (Gast)


Angehängte Dateien:

Lesenswert?

Hallo und danke an alle für die zahlreiche technische Unterstützung.
Ich muss die Beiträge ersteinmal nochmal lesen und verdauen....

Mein PIC läuft mit 20 Mhz. Code und Plan ist anbei. Kann gut sein, dass 
Widerstände im S-Plan nicht richtig angegeben sind, aber in real passend 
bestückst sind. Beispiel Basisvorwiderstände der Transistoren oder bei 
den Hallsensoren nur einer Pulldown or Pullup bestückst sind. C ist 
nicht bestückt.. Sollte also nichts mit dem LCD Schreibvorgang zu tun 
haben.

Nutze noch das alte MPLAB IDE von vor 10 Jahren....
In der xlcd.h hab ich nur R/W - E - RS Ports angepasst. Ansonsten ist 
die main_14032021.c das Programm von mir.

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

Vielen Dank

von Falk B. (falk)


Lesenswert?

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.

von m.n. (Gast)


Lesenswert?

Falk B. schrieb:
> Man kann die Abfrage des Busy-Bits entfernen und nach jedem
> Schreibzugriff einfach 40us Pause einlegen.

Wofür soll das denn gut sein?
In der Art: mache den Motor aus und schiebe Dein Auto?
Sofern man BUSY testen kann (R/WR-Leitung angeschossen), sollte man es 
auch tun.

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

Wäre super, wenn Du mal irgendeine der vorgeschlagenen 
Hardwareänderungen probieren würdest, um herauszufinden, woher die 
Störungen kommen und wie man sie beseitigen kann.
Nach einer Woche Ratespiel wäre das doch schon eine Option.

von Danny (Gast)


Angehängte Dateien:

Lesenswert?

Falk B. 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? Demzufolge hab ich die 36 mal 
durch 27 ersetzt und die Zeit müsste die 3/4 sein, richtig ?

Hab während dem Schreiben hier grad realisiert, das die Zahl als "i_18" 
deklariert ist und daher nicht bei 18 los zählt, sondern bei 0, da es ja 
"=0" heißt.

Insofern macht die Funktion was sie soll. Gibt es hier noch was zu 
suchen/ verbessern mit dem langen Schreiben ?

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

Die Filterschaltung ist das nächste auf der To Do Liste, wird aber eine 
Weile dauern.

Vielen Dank erneut an alle !!

von Danny (Gast)


Lesenswert?

Grüße noch mal

zu den Interrupts wie folgt:

if  (PIR1bits.TMR2IF)                          //Timer 2 Interrupt 5 kHz 
each 0,2 ms (200µs)

hier wird immer hochgezählt in der ISR und das Duty cycle in Schritten 
bis 100% erhöht falls Vollgas ist. Wird das Gaspedal los gelassen, wird 
der DC im selben Verhältnis zum Gas Wert runter gesetzt...

und dann noch ein Interrupt, wenn die PWM >0 (Gas getreten) ist wird am 
7 Takt Takt von einem festen DC an der steigenden flanke und am 15 Takt 
von einer fallenden Flanke mit dem ADC in der ISR der Strom gemessen

Interrupt on change gibts auch noch aber nur für die 4x Taster
Interrupt für Bremspedal und RPM Messung der Räder

Mit dem Kart bin ich selber gefahren, LCD mit 70 cm Flachband in der 
Hand und peak Ströme von bis zu 70 A und das LCD hat einwandfrei 
funktioniert...
Nur so als zusätzliche Info..

Danke.

von Falk B. (falk)


Lesenswert?

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?

von Falk B. (falk)


Lesenswert?

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.

von Danny (Gast)


Lesenswert?

Ich würde mal folgendes machen mit Interrupts AN in der main loop

LED EIN
LED AUS
LED EIN
18x NOP
LED AUS

Oszi Shot von der LED und dann das ganze mal mit allen Interrupts AUS. 
Wäre das okay ?

Dankeschön 👍

von Danny (Gast)


Lesenswert?

Oder muss es unbedingt die

void DelayFor18TCY( void )

Schleife sein ? Danke !

von Falk B. (falk)


Lesenswert?

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

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

von Danny (Gast)



Lesenswert?

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

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

Wie geht das, versteh ich grad irgendwie nicht …

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

Danke

von Falk B. (falk)


Lesenswert?

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.

von Falk B. (falk)


Angehängte Dateien:

Lesenswert?

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

von Pandur S. (jetztnicht)


Lesenswert?

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.

von m.n. (Gast)


Lesenswert?

Pandur S. schrieb:
> Ich verwende jeweils einen Display
> Buffer auf dem Controller, welcher per Timer Tick periodisch vollständig
> neu beschrieben wird.

Für jemanden, der seine Hardware nicht im Griff hat, scheint das die 
geniale Lösung zu sein ;-)

von Danny (Gast)


Angehängte Dateien:

Lesenswert?

Hallo an alle und besonders vielen Dank an Falk, der sich hier besonders 
engagiert hat und zur Lösung des Problems beigetragen hat !!

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, aber ich meine, dass es das 
Timing ist, sprich der Code.. oder was meint ihr anhand anliegender 
Videos hier??

https://drive.google.com/file/d/19TL2-xadUeb84s7ZHaSXH7csm2N8O-J0/view?usp=sharing

https://drive.google.com/file/d/15bGnWy_ca_-MoWw2dqMYBFp4xKwhWR7k/view?usp=sharing

https://drive.google.com/file/d/1bvnmhvjGWF5g0cwZz-XnoVMj938tHsZS/view?usp=sharing

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..

Das PIC KIT3 ist ja vorhanden und Debuggen geht damit auch...

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

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

Noch einmal vielen vielen Dank für die Unterstützung !

von Danny (Gast)


Lesenswert?

Vielen Dank !!

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

Vielen Dank !

von Falk B. (falk)


Lesenswert?

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.

von Falk B. (falk)


Lesenswert?

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?

von Danny (Gast)


Lesenswert?

Falk B. schrieb:
> Ein Bobbycar mit Motor ;-)
> Ich sehe keine Akkus?

Neben dem Motor rechts 2 Stück mit 12 V in Reihe geschalten

Ja, das mit dem Display stimmt. Es war einmal ein 2x20, was es im Code 
auch noch ist.

Solange es „nur“ die Software ist und erstmal fährt und was anzeigt ist 
es ein kleiner Fortschritt und der Winter kommt ja bald, da ist mehr 
Zeit für solche Aktivitäten.

Bitte 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
Noch kein Account? Hier anmelden.