Hallo Forumsteilnehmer, ich möchte Euch um Mithilfe zur Lösung meines Problems bitten. Ich habe ein E-Kart für meinen Sohn mit einem PIC18F4580 gebaut. Der Code läuft mehr oder weniger 95% und wurde mit dem alten MPLAB IDE erstellt. Das LCD läuft zu jeder Zeit einwandfrei! Da das alte IDE out of date ist bin ich zum neueren MPLAX X mit Codeconfigurator gewechselt und habe mir wie vorher schon, eine LCD Libary organisiert und mich an Beispielen orientiert. Mit der neuen Libary ist das Timing des LCD ein anderes und das LCD schmiert ab, sobald Sohnemann das Gas betätigt und Strom fließt. Von der Art und Weise meine ich dasselbe wie vorher zu machen. Ich zerlege die Zahlen und sende diese dann im 45K80 er Programm wie folgt LCDGoto(0,0); LCDdata1[0] = (Speed % 1000) / 100 + '0'; // 100 Position LCDdata1[1] = (Speed % 100) / 10 + '0'; // 10 Position LCDdata1[2] = '.'; LCDdata1[3] = Speed % 10 + '0'; // 1 Position LCDdata1[4] = ' '; LCDdata1[5] = 'k'; LCDdata1[6] = 'm'; LCDdata1[7] = '/'; LCDdata1[8] = 'h'; usw. LCDPutStr(LCDdata1); Das Schreiben dauert 100 ms ca. Im alten Program des IDE ist der Ablauf so: strcpypgm2ram(LCDdata1," "); LCDdata1[0] = (Speed % 1000) / 100 + '0'; // 100 Position LCDdata1[1] = (Speed % 100) / 10 + '0'; // 10 Position LCDdata1[2] = '.'; LCDdata1[3] = Speed % 10 + '0'; // 1 Position LCDdata1[4] = ' '; LCDdata1[5] = 'k'; LCDdata1[6] = 'm'; LCDdata1[7] = '/'; LCDdata1[8] = 'h'; usw. SetDDRamAddr((unsigned char) 0); // 1. row in display putsXLCD( LCDdata1); SetDDRamAddr((unsigned char) 40); // 2. row in display putrsXLCD(( char*)"Das ist seite 2 unten"); Es müsste also beim 45K80 Code das „LCDPutStr“ irgendwie geändert werden, wie beim „putsXLCD“ des 4580 code. Ist das korrekt. Ich möchte noch mitteilen, dass die LCD Leitung nicht gerade mit 1,4 m die kürzeste ist, aber die Hardware und der Takt (auch H-Brücke 5 khz) sind bei beiden Anwendungen PIC´s gleich. Ich tausche nur den Controller auf der PCB aus ! Somit möchte ich bitte nicht beim Thema EMV und Störungen hier anfangen, sondern ausschließlich bitte den Code betrachten. Ich habe mal das LCD Timing angehangen und die beiden LCD libarys. Beim 45K80 wird R/S nicht bedient, da ja ausschließlich auf das LCD geschrieben wird. Das Enable zwischen beiden Codes unterscheidet sich stark nach den Oszibildern und das Einfügen von ein paar NOP(); im Code für eine längeres E-Signal hat fast nichts gebracht. Es wäre schön, wenn Ihr mir bitte beim LCD Code helfen könntet, denn da steh ich bissl im dunklen Wald. Sollten was fehlen, bitte einfach hier schreiben, ich lade es dann hoch. Danke.
Guten Morgen, Mahlzeit, herrscht hier etwa auch Fachkräftemangel ? 😉 War Spaß, nur um das Thema nicht ganz abrutschen zu lassen. Danke.
Warum bleibst Du nicht bei der alten Bibliothek? Die sollte auch auf der K-Variante noch laufen. Du musst nur das erste Include ändern. Aus <p18cxxx.h> wird <xc.h>. fchk
Frank K. schrieb: > Warum bleibst Du nicht bei der alten Bibliothek? Die sollte auch > auf der K-Variante noch laufen. Du musst nur das erste Include ändern. > Aus <p18cxxx.h> wird <xc.h>. > fchk Es gab leider etliche Fehlermeldungen vom Compiler 😬, da gibts auch etliche Unterschiede zum älteren. Deshalb… Reicht wirklich nur das include ändern ? Ich könnte das ja da nochmal probieren. Danke.
Frank K. schrieb: > Warum bleibst Du nicht bei der alten Bibliothek? Die sollte auch > auf der K-Variante noch laufen. Du musst nur das erste Include ändern. > Aus <p18cxxx.h> wird <xc.h>. > fchk Wäre das viel Aufwand (und was), den Code im Timing an die alte Library anzupassen? Die neue Libary hat eine .c und eine .h Datei nur. Danke.
Daniel schrieb: > Frank K. schrieb: >> Warum bleibst Du nicht bei der alten Bibliothek? Die sollte auch >> auf der K-Variante noch laufen. Du musst nur das erste Include ändern. >> Aus <p18cxxx.h> wird <xc.h>. >> fchk > > Wäre das viel Aufwand (und was), den Code im Timing an die alte Library > anzupassen? Die neue Libary hat eine .c und eine .h Datei nur. Sag mal, hast Du ein wirkliches Verständnis davon, was Dein Code macht? Warum welche Zeile da warum steht. Ich denke, DU solltest dringend an deinen C-Kenntnissen und Deinen allgemeinen Programmierkenntnissen arbeiten. In C kannst bist Du relativ frei, ob Du Deine Funktionen alle in eigene Dateien oder alles in eine Datei schreibst. Das ist dann nachher zwar beim Linken ein kleiner Unterschied, aber erstmal egal. Aus meiner Sicht ist es einfacher, den alten Code zum Laufen zu bringen. Eventuell wird der Compiler über die dort verwendete Delay-Funktion stolpern - die ersetzt DU dann durch die delay-Funktion, die in der neuen Bibliothek verwendet wird und passt den Delay-Wert so an, dass es passt. Ich habe jetzt keine Zeit und keine Muße, Deine Arbeit für Dich zu übernehmen. Das wirst Du selber machen. Dann lernst Du vielleicht noch was dabei. fchk
Daniel schrieb: > Somit möchte ich bitte nicht beim Thema EMV und Störungen hier anfangen Wenn ich mir die Oszibilder samt oft unleserlicher Zeitbasis so anschaue, dann sollte man das Thema aber nicht so weit weg werfen. > Ich habe mal das LCD Timing angehangen Was sieht man da wo? Du hast doch ein 2-Kanal-Oszi, warum verwendest du nur 1 Kanal? Dir ist schon klar, dass die Datenleitungen besonders im zeitlichen Bezug zum Enable interessant sind? Wenn nicht, dann sieh dir das Timing-Diagramm im Datenblatt des LCD an. Daniel schrieb: > Mit der neuen Libary ist das Timing des LCD ein anderes Dann musst du halt mal schauen, wo das Timing eingestellt wird und dafür sorgen, dass das alte Timing verwendet wird. Daniel schrieb: > Wäre das viel Aufwand (und was), den Code im Timing an die alte Library > anzupassen? Die neue Libary hat eine .c und eine .h Datei nur. Nein, man muss sich eben in seine Hardware einarbeiten. Diesen Prozess nennt man "Lernen". Das ist das Los jedes Entwicklers. Du musst den Schritt vom "Kopieren" zum "Kapieren" schaffen. Wenn man das nicht machen will, dann sollte man das Hobby wechseln. Daniel schrieb: > Es gab leider etliche Fehlermeldungen vom Compiler 😬 Ja, dann musst du nachschauen, woher die kommen und dafür sorgen, dass die nicht mehr kommen. > Reicht wirklich nur das include ändern ? Ich könnte das ja da nochmal > probieren. Mit "Probieren" hat das am allerwenigsten zu tun. Insgesamt hat Frank K. grundsätzlich Recht. Daniel schrieb: > herrscht hier etwa auch Fachkräftemangel ? Ist das ein Stellenangebot? Was zahlst?
:
Bearbeitet durch Moderator
Daniel schrieb: > Reicht wirklich nur das include ändern ? Ich könnte das ja da nochmal > probieren. Wenn nich eh schon, dann mal auf C90 umstellen. Global und im Linker.
Daniel schrieb: > Da das alte IDE out of date ist bin ich zum neueren MPLAX X mit > Codeconfigurator gewechselt und habe mir wie vorher schon, eine LCD > Libary organisiert und mich an Beispielen orientiert. Ah ja. Du hast dir eine Library organisiert. Du hast also für deinen Buben ein Elektro-Spielauto gebaut, das läßt auf handwrkliches Geschick schließen. Dazu hast du offenbar eine Art Tacho mit einem PIC18 und einem LC-Textdisplay gebaut. Das läßt auch auf elektronisches Geschick schließen. Ist ja vermutlich eine selbstgestaltete Leiterplatte mit selbstgestalteter Schaltung. Oder ist das auch bloß "organisiert"? Nun meine Frage dazu: Wie kommst du auf die Idee, daß eine "organisierte" Library zu deiner Schaltung paßt? Wäre es nicht sinnvoller, die Ansteuerung eines LCD selbst und passend zu deiner Schaltung zu machen? Versuche zunächst, das (hoffentlich existierende) Manual zum Display zu verstehen. Das alles ist nicht schwer, also tu das zu allererst. Dann schau dir deine "organisierte" Library an und überprüfe, ob die diversen Schalter (die dort für diverse #ifdef's gebraucht werden) richtig gesetzt sind. Ebenso überprüfe, ob die vom LCD benötigten Signale an die richtigen Portpins gehen. Alternativ wirf die gesamte "organisierte" Quelle weg und schreibe dir deinen eigenen Treiber passend zu deiner Schaltung. Ist auch nicht schwer. W.S.
Grüße an alle, vielen Dank fürs Feedback. Viele der Fragen und Hinweise wie * deinen C-Kenntnissen und Deinen allgemeinen Programmierkenntnissen arbeiten. * Diesen Prozess nennt man "Lernen". Das ist das Los jedes Entwicklers. Du musst den Schritt vom "Kopieren" zum "Kapieren" schaffen *Du hast also für deinen Buben ein Elektro-Spielauto gebaut, das läßt auf handwrkliches Geschick schließen. müssen leider mit "Ja" beantwortet werden. Ich habe es mir auch leider etwas zu einfach mit der Programmierung vorgestellt. Ist halt so... Im Moment hab ich die alte libary eingefügt und Probleme mit dem #define PARAM_SCLASS auto #define MEM_MODEL near /* Change this to far near for small memory model */ void OpenXLCD(PARAM_SCLASS unsigned char); Hab gegoogelt und andere hatten das Problem auch, hab aber keine Lösung dazu gefunden. In den Posts war auch immer die Rede von "try" to remove "PARAM_SCLASS". Ich benutze XC8 V2.10. Hat jemand eine Idee/ Empfehlung dazu? Vielen Dank schon mal.
Daniel schrieb: > Hat jemand eine Idee/ Empfehlung dazu? Meine Ideen dazu hab ich schon geschrieben. Anbei eine Firmware für ein anderes Projekt (von mir), wo eine Ausgabe an ein Text-LCD im 4 Bit Modus mit dabei ist. Ist aber in Assembler. Und für einen PIC16F716. Und nicht für Microchips Toolchain. Allerdings kannst du da sehen, daß eine Textausgabe an ein derartiges LCD keine große Sache ist. Wie man sehen kann, sind dafür einschließlich Initialisierung nur ein paar recht kurze Stücke Programm nötig. Vielleicht kannst du daran etwas dazulernen. W.S.
Daniel schrieb: > Im Moment hab ich die alte libary eingefügt und Probleme mit dem > > #define PARAM_SCLASS auto > #define MEM_MODEL near /* Change this to far near for small memory model > */ #define PARAM_SCLASS #define MEM_MODEL Damit entfernt der Präprozessor diese beiden Worte überall im Quelltext. Weißt Du überhaupt, was ein Präprozessor ist, was der macht und wozu der da ist? Wenn nicht, dann wäre es JETZT der Zeitpunkt, um das nachzulesen. fchk
Wenn Du Lust hast, auch zu verstehen, was Du da machst, dann schau Dir mal diese einfache Lib an. Im Gegensatz zu vielen anderen Codebeispielen macht diese die korrekte Initsequenz. Für eine Anpassung an den PIC muß man nur die Pindefinitionen und die Delayfunktion anpassen. Und beim PIC sind wohl die Richtungsbits verkehrt rum (0 = Ausgang) zu setzen. Der Rest ist standard C. https://www.avrfreaks.net/forum/tutc-lcd-tutorial-1001 In Deinen Zeilen fehlt, daß Du für den Ausgabetext ein genügend großes Array anlegst. Vermutlich stürzt es deshalb ab.
Angehängte Dateien:
Daniel schrieb: > das LCD schmiert ab, sobald Sohnemann > das Gas betätigt und Strom fließt. Da würde ich mich mal eher auf die Hardware, insbesondere die Signalqualität konzentrieren. Es kann gut sein, dass es vorher nur mit Glück funktionierte. Gerade wenn Leute wie du mit vielen Ausrufezeichen darauf beharren, dass dort alles in Ordnung ist, werde ich sehr skeptisch. Solche Fälle hatten wir hier schon oft. Messen ist besser, also gut dass du das gemacht hast. Ich sehe auf deinen Bildern außergewöhnlich viel "Schmutz" sowohl auf dem HIGH Pegel als auch auf dem LOW Pegel. Das geht besser. Besonders interessant fände ich Takt (Enable) und Daten in einem zusammenhängenden Bild. Mache das mal. Stelle dabei die horizontale Achse so ein, dass man die Form der ansteigenden und fallenden Flanken erkennen kann. Mindestens so wie im angehängten Bild, gerne noch mehr in die Breite gezogen. Ich will sehen wie sauber und schnell die Signale von LOW nach HIGH (und zurück) wechseln. Ich will auch sehen, wie viel Abstand zwischen Daten und Takt-Impuls eingehalten wird. Wenn die Signale wirklich OK sind, dann macht es Sinn, die Kommunikation mit einem Logic Analyzer weiter zu untersuchen. Der wird dann zeigen, ob die Software überhaupt richtig kommuniziert. Wenn nicht, schauen wir uns den Quelltext an.
Peter D. schrieb: > Und beim PIC sind wohl die Richtungsbits verkehrt rum (0 = Ausgang) zu > setzen. Eselsbrücke: 0 = O/o = Output - Ausgang 1 = I/i = Input - Eingang Eigentlich logischer, wenn auch unüblich. fchk
Läuft das LCD denn stabil, wenn man es mit einem kürzeren Kabel anschließt? Soft- und Hardwareprobleme gehen nicht selten Hand in Hand. Nur weil das Display quasi out of spec in Umgebung A gerade noch irgendwie läuft, kannst du nicht dem Code die alleinige Schuld geben, das es im Fall B nicht funzt. Wenn schon das Kabel länger sein muß, dann verwende das Display über I2C. 2 Meter über ein Stück LAN-Kabel waren bei mir kein Problem. Es gibt für die Displays Huckepack-Platinen mit PCF irgendwas. Dein PIC sollte ebenfalls eine I2C Schnittstelle haben.
Gerald B. schrieb: > Läuft das LCD denn stabil, wenn man es mit einem kürzeren Kabel > anschließt? Soft- und Hardwareprobleme gehen nicht selten Hand in Hand. Dieses Thema hatten wir vor einigen Monaten schon durch. Ich habe ihm einen Satz 26LS31/32 oder 26LV31/32 Quad-RS422-Transmitter/Receiver empfohlen gehabt, wodurch die Übertragung differentiell und damit störsicher realisiert worden wäre. Damit wären dann auch 5 oder 10m Kabelstrecke kein Problem gewesen. Leider erwies sich der Fragesteller auch als beratungsrenitent. Ok, muss er halt selber wissen. fchk
Gerald B. schrieb: > Läuft das LCD denn stabil, wenn man es mit einem kürzeren Kabel > anschließt? ja, als kürzeres Kabel mit Flachband anstatt Rundleiter schon, Störungen sind bestimmt vorhanden, Kabeltyp hat ja auch hierauf Einfluss auf die Einkopplungen > Wenn schon das Kabel länger sein muß, dann verwende das Display über > I2C. 2 Meter über ein Stück LAN-Kabel waren bei mir kein Problem. > Es gibt für die Displays Huckepack-Platinen mit PCF irgendwas. > Dein PIC sollte ebenfalls eine I2C Schnittstelle haben. Controller Layout ist fertig, geht leider nicht mehr ohne hohen Aufwand.. Danke
Frank K. schrieb: > Gerald B. schrieb: >> Läuft das LCD denn stabil, wenn man es mit einem kürzeren Kabel >> anschließt? Soft- und Hardwareprobleme gehen nicht selten Hand in Hand. > > Dieses Thema hatten wir vor einigen Monaten schon durch. Ich habe ihm > einen Satz 26LS31/32 oder 26LV31/32 Quad-RS422-Transmitter/Receiver > empfohlen gehabt, wodurch die Übertragung differentiell und damit > störsicher realisiert worden wäre. Damit wären dann auch 5 oder 10m > Kabelstrecke kein Problem gewesen. Leider erwies sich der Fragesteller > auch als beratungsrenitent. Ok, muss er halt selber wissen. > > fchk Hallo, beratungsresistent nicht ganz gleich... Es muss auch die Frage und Ursachenklärung gestattet werden, warum der eine Code läuft und der andere nicht. Dazu hat sich hier leider noch keiner platziert und das vermutlich unterschiedliche Timing unter die Lupe genommen. Das war ja mein Hauptansinnen mit dem Post. Auch wenn es Störungen gibt, welche einen Einflus haben "könnten" wäre es doch einfacher hier anzusetzen, als immer mehr Hardware/ Wandler hinzu zufügen oder? Danke für die Hinweise und Anmerkungen.
Frank K. schrieb: > Dieses Thema hatten wir vor einigen Monaten schon durch Kannst Du das bitte verlinken? Dann ist es für alle leichter ...
Daniel E. schrieb: > Es muss auch die Frage > und Ursachenklärung gestattet werden, warum der eine Code läuft und der > andere nicht. Dazu hat sich hier leider noch keiner platziert Doch, das habe ich. > und das vermutlich unterschiedliche Timing unter die Lupe > genommen. Das war ja mein Hauptansinnen mit dem Post. Ich habe dir gesagt, welche Details ich sehen will, damit ich was dazu sagen kann. Aber wenn du nicht lieferst, dann wird das nichts.
Halleluja an alle, also, hab etwas Hirnschmalz gelassen und Stand ist
folgender:
Alter Code macht das bei writedata
#ifdef UPPER // Upper nibble interface
DATA_PORT &= 0x0f;
DATA_PORT |= ((data<<4)&0xf0);
#else // Lower nibble interface
DATA_PORT &= 0xf0;
DATA_PORT |= (data&0x0f);
#endif
DelayFor18TCY();
E_PIN = 1; // Clock nibble into LCD
DelayFor18TCY();
E_PIN = 0;
die 18TCY sind meiner Meinung das wichtige nach der Übertragung von
DATA_PORT |= (data&0x0f);
Das Display braucht etwas Zeit danach, genauso wie das Enable in der
Routine nach dem E_PIN = 1 etwas Zeit brauch
also 1 und 1 kombiniert und im nicht funktionierenden Code hier:
// move the nibble onto LCD_PORT
LCD_PORT = (LCD_PORT | ch);
__delay_us(5); //Reu
// set data/instr bit to 0 = insructions; 1 = data
LCD_RS = rs;
// RW - set write mode
LCD_RW = 0;
// set up enable before writing nibble
LCD_EN = 1;
__delay_us(5); //Reu
// turn off enable after write of nibble
LCD_EN = 0;
2x je 5 µs delay eingepflanzt, compilliert, Laptop in der Hand in der
kalten Garage in Shorts den Code geladen :-) Gas gedrückt und das Kart
mit allen Kräften festgehalten und siehe da, Display zeigt immer noch
alle Zeichen an :-) :-) :-)
Ich mach mir erstmal ein Bier auf, stimmt mich etwas optimistisch und
etwas verstanden habe ich scheinbar auch was der Code macht oder ?
Danke und Grüße
Daniel E. schrieb: > 2x je 5 µs delay eingepflanzt... (läuft) Genau darauf zielte meine Rückfrage zu den Oszilloskop-Bildern ab. Stefan ⛄ F. schrieb: > Ich will auch sehen, wie viel Abstand zwischen Daten und > Takt-Impuls eingehalten wird.
Stefan ⛄ F. schrieb: > Genau darauf zielte meine Rückfrage zu den Oszilloskop-Bildern ab. Und meine Rückfrage auch. Bei der Inbetriebnahme von Hardware zählt auf unterster Ebene die Physik, also das, was im Datenblatt mit den Pegeln und den zeitlichen Abhängigkeiten als anforderung vorgegeben ist. Und das kann man messen. Daniel E. schrieb: > Das Display braucht etwas Zeit danach, genauso wie das Enable Wie ich schrieb: > dass die Datenleitungen besonders im zeitlichen Bezug zum Enable > interessant sind? Hatte ich schon erwähnt, dass man das messen kann und messen sollte? Daniel E. schrieb: > etwas verstanden habe ich scheinbar auch was der Code macht oder ? Ja, offensichtlich. Und jetzt würde ich (und solltest du) mal nachmessen, wieviel Reserve du im Timing hast und wie gut das zum Datenblatt passt.
Angehängte Dateien:
-
IMG_0943.jpg
240 KB -
IMG_0944.jpg
240 KB -
IMG_0945.jpg
240 KB -
IMG_0946.jpg
230 KB
Grüße an alle, hab mal gemessen mit den __delay_us(5) Zeiten. CH1 Datenbus DB4 CH2 Enable (Pin 6) Dachte auf dem DB4 ist mehr los ?? Sind die Signale plausibel und was meint ihr zum Timing, da hab da leider keinerlei Ahnung. Display ist das hier: https://datasheet.octopart.com/BTHQ21608VSS-SRE-Batron-datasheet-565724.pdf Danke an alle.
Beitrag #6941703 wurde von einem Moderator gelöscht.
Angehängte Dateien:
Daniel E. schrieb: > hab mal gemessen Du hast das genau an den Pins des Displays gemessen? Denn es geht ja darum, was das Display an seinen Pins sieht. > was meint ihr zum Timing Das ist keine Frage der Meinung, sondern schlicht ein Vergleichen mit den Anforderungen. > da hab da leider keinerlei Ahnung. Du sollst es mit den Werten im Datenblatt vergleichen. Was ist so schwer daran? An deinen Messungen kannst du die "E cycle time" (= 17µs) ablesen, die "E pulse time" (=5µs), die "Data setup time" (= 7µs) und die "Data hold time" (= 4µs). Bei diesen 4 Zeiten kannst du einen grünen Haken ins Datenblatt machen, weil die "min" Anforderungen locker erfüllt sind (man könnte das Display sogar gut 20x schneller ansteuern). Und jetzt musst du noch die "E fall time" und die "E rise time" messen und diese Flanken genau auf Stetigkeit anschauen. Da muss dann irgendwas mit 20ns/div als Zeitbasis im Oszi eingestellt sein und die Flanken dürfen keine "Zacken" haben. Und dann sind noch die Störungen auf der jeweils anderen Leitung spannend. Das können kapazitive Kopplungen sein, oder auch nur ein schlichter Messfehler wegen ungünstig angeschlossener Masseklemme. > Dachte auf dem DB4 ist mehr los ?? Warum sollte da mehr los sein? Das Signal darauf darf sich ja höchstens 1x pro enable-Zyklus ändern. Da ist sogar unnötig viel los, der kleine Low-Zacken im Bild 945 wäre nicht nötig.
Lothar M. schrieb: > Und dann sind noch die Störungen auf der jeweils anderen Leitung > spannend. Ja, wenn die wirklich so hohe Pegel haben wie das Oszilloskop zeigt, dann funktioniert dieses Display nur mit viel Glück. Es könnte jeden Moment ausfallen. Ich muss mal ein Lob aussprechen: Die Fotos sind gut. Man bekommt hier leider viel zu oft Fotos von Oszilloskopen zu sehen, auf denen man wichtige Infos nicht oder nur sehr mühsam erkennen kann, weil das Licht ungünstig war oder die Kamera zu schräg gehalten wurde.
Angehängte Dateien:
-
unleserlich.PNG
750 KB
Stefan ⛄ F. schrieb: > Man bekommt hier leider viel zu oft Fotos von Oszilloskopen zu sehen, > auf denen man wichtige Infos nicht oder nur sehr mühsam erkennen kann, > weil das Licht ungünstig war oder die Kamera zu schräg gehalten wurde. Und zudem der Bildschirm völlig verstaubt war. Oder weil etwas aufgenommen wurde, was für sich allein völlig uninteressant ist. Das war hier im Thread anfangs durchaus auch der Fall (siehe das angehängte Bild). Insofern ist da auch was voran gegangen... ;-)
Stefan ⛄ F. schrieb: > Ich muss mal ein Lob aussprechen: Die Fotos sind gut. Man bekommt hier > leider viel zu oft Fotos von Oszilloskopen zu sehen, auf denen man > wichtige Infos nicht oder nur sehr mühsam erkennen kann, weil das Licht > ungünstig war oder die Kamera zu schräg gehalten wurde. Wobei die Zeiten, als Bildschirminhalte noch abfotografiert werden mussten (teils mit speziellen Abdeckhauben und Halter für die Polaroid-Kamera) jetzt so langsam auch vorbei sein sollten. So ziemlich jedes digitale Oszi ist in der Lage, seine Daten über HPIB, RS232 oder LAN an den Rechner zu senden - auch das offensichtlich hier verwendete Tek 210 oder 220 (ich hatte mal selber eines, wo ich sogar einen Thermodrucker angeschlossen hatte). fchk
> ... > als Bildschirminhalte noch abfotografiert werden mussten > (teils mit speziellen Abdeckhauben und Halter für die Polaroid-Kamera) > ... Sowas hatte man als Bastler eher nicht. Butterbrotpapier und blauer Buntstift halfen. Gruss
Hallo an alle und vielen Dank für die Hinweise und den Support. Ich habe die Zeiten schrittweise reduziert und bin bei 1us Pause hängen geblieben. Zusätzlich hatte ich vor Codeänderung noch links und rechts der Drei Steuerleitungen 4 freie GND Leitungen gelegt. Mein Sohnemann ist heute knapp 5 km rum gecruised ohne einen Ausfall oder Problem am LCD. Soweit so fein 🤗. Sicherlich könnte man hier noch tiefer einsteigen und bis aufs letzte Timing ausreizen… Das Programm im Ablauf erfordert dies aber m. M. nicht. An der Stelle nochmal vielen Dank für die Geduld und Hilfe an alle 👍.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.