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.
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.
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
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.
Stefan ⛄ F. schrieb: > Was genau heißt "verliert die Zeichen"? Die fallen vorne aus dem Glas raus. Meistens sind es Ziffern,
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.
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.
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.
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…
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.
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.
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.
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.
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
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?
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.
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.
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.
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.
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
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.
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
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.
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.
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.
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.
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
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
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: > 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.
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.
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.
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
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.
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.
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?
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.
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.
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.
MaWin hat gleich in der ersten Antwort genau das richtige gesagt. Datenübertragung beginnt am Anfang vom Kabel.
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.
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
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
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.
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.
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 !!
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.
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.
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 👍
Oder muss es unbedingt die void DelayFor18TCY( void ) Schleife sein ? Danke !
Danny schrieb: > Oder muss es unbedingt die > > void DelayFor18TCY( void ) > > Schleife sein ? Danke ! Du willst die Laufzeit dieser Funktion messen. Also tu es!
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
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.
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 ;-)
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 !
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 !
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?
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
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.