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.
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?
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.
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.
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 EnableWie 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.
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.
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.
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 👍.
