Welches Oszilloskop für Anfänger ?

Vielleicht hat es bei mir schlicht mit den Augen zu tun, dass ich mich ohne Lupe gar nicht mehr traue, bei dem heutigen SMD-Gedöns nen Tastkopf auf ne Leiterbahn zu setzen. Darum baue ich einiges an Software um optische Kontrollen (LEDs) und Diagnosetelegramme herum.
Man braucht ja nicht für jede Funktion eine eigene LED, das kann man dann auch mal softwareseitig umstellen.

Zitat:

---

.. baue ich einiges an Software um optische Kontrollen (LEDs) und Diagnosetelegramme herum. Man braucht ja nicht für jede Funktion eine eigene LED ..

---

Ganz meine Praxis. Auf den Servoplatinen für meinen archie hatte ich u.a. zwei LEDs, HeartB und Tst, an einer markanten Stelle. Die grüne Heartbeat ist ein Blinkie mit 0,5 Hz (1 sec an, 1 sec aus) und ein gutes Instrument um Ausfälle oder Störungen zu erkennen (ne Heartbeat existiert auf fast allen meinen Platinen - Ausnahmen die minimal bestückten..). Daneben die rote Tst ist für Tests, Debugging und so. Nur eine, dafür ganz isoliert an einem einzigen Pin der wirklich nur für allfällige Diagnosen benutzt wird - auch nicht für ne Taste oder sonstiges Zeug.

Zitat:

---

Zitat von oberallgeier

Ganz meine Praxis. Auf den Servoplatinen für meinen archie hatte ich u.a. zwei LEDs, HeartB und Tst, an einer markanten Stelle. Die grüne Heartbeat ist ein Blinkie mit 0,5 Hz (1 sec an, 1 sec aus) und ein gutes Instrument um Ausfälle oder Störungen zu erkennen (ne Heartbeat existiert auf fast allen meinen Platinen - Ausnahmen die minimal bestückten..). Daneben die rote Tst ist für Tests, Debugging und so. Nur eine, dafür ganz isoliert an einem einzigen Pin der wirklich nur für allfällige Diagnosen benutzt wird - auch nicht für ne Taste oder sonstiges Zeug.

---

so mache ich es auch, zusätzlich auch Display-Anzeigen, wo relevante Werte zu Kontrollzwecken angezeigt werden (und manchmal auch zusätzlich noch Soundsignale), aber das sind ja eher Methoden für Monitoring und Debuggen und hat nichts mit dem Thema "Oszi für Anfänger" zu tun.

Zitat:

---

Zitat von HaWe

hat nichts mit dem Thema "Oszi für Anfänger" zu tun.

---

Doch, schon. Es stellt nämlich die Frage, lohnt sich ein Scope überhaupt, wenn ich nicht gerade analoge HW entwickle. Sollte man das verfügbare Geld nicht eher für etwas anderes ausgeben? Trotz aller genannten Debughilfen mit LEDs und serieller (die einem das Timing typisch komplett kaput macht), ist es dir z.B bisher nicht gelungen, die Ursache für die merkwürdigen Zeichen auf der seriellen zu finden (aus einem anderen Thread)

Zitat:

---

Zitat von HaWe

Restart, neuer output:

Code:

---

initializing...
starting UART loop...
§message from Arduino: 0gno: 618;
§message fr��message from Arduino: 615;
§message from Arduino: 616;
§message from Arduino: 617;
§message from Arduino: 618;
§message fr

---

dann bleibt es wieder stehen...

---

Mit einem 10$ LA wäre ich der Sache längst auf der Spur.

Einen belastbaren Ratschlag, welches man kaufen sollte, kann man eigentlich nicht geben. Braucht man besser mehr Kanäle, eine höhere Bandbreite, eine höhere Abtastrate oder eine größere Speichertiefe? Bei einem limitierten Budget muß man eines gegen das andere aufwiegen. Nur der Benutzer selber weiß, wozu er es einsetzt und vor allem einsetzen wird. Um die Arbeit, die Manuals zu lesen und die Features zu vergleichen, wird man nicht herumkommen. Da könnte auch rauskommen, daß man abwartet und anspart oder nach einem gebrauchten sucht.

Abraten würde ich von den DSO nano. Und das einfach aus praktischen Gründen. Display und vor allem Tasten sind sehr klein. Man braucht schon gute Augen und eine ruhige Hand um es vernünftig benutzen zu können. Anderenfalls liegt es auch meist im Schrank. Auch nur einen Kanal halte ich für zu wenig, ein externer Triggereingang wäre da nötig.

MfG Klebwax

Zitat:

---

Zitat von Klebwax

...und serieller (die einem das Timing typisch komplett kaput macht), ...

---

Wo macht einem die UART das Timing kaputt?

Zitat:

---

Zitat von Klebwax

Doch, schon. Es stellt nämlich die Frage, lohnt sich ein Scope überhaupt, wenn ich nicht gerade analoge HW entwickle. Sollte man das verfügbare Geld nicht eher für etwas anderes ausgeben? Trotz aller genannten Debughilfen mit LEDs und serieller (die einem das Timing typisch komplett kaput macht), ist es dir z.B bisher nicht gelungen, die Ursache für die merkwürdigen Zeichen auf der seriellen zu finden (aus einem anderen Thread)

---

ich bin da übrigens auch ein ganzens Stück weiter inzwischen, und es liegt mit großer Wahrscheinlichkeit am Raspi, nicht am Arduino
Ich aber glaube kaum, dass ich das Poblem mit einem Oszi eingrenzen könnte, denn dass es früher oder später mal hängt, ist klar, nur ob der Raspi nicht senden oder der Arduino nicht empfangen kann oder umgekehrt, kriege ich auch sicher mit einem Oszi nicht raus - allerdings bisher auch nicht mit anderen Mitteln https://www.roboternetz.de/community...l=1#post652616 ) .

Zitat:

---

Zitat von Holomino

Wo macht einem die UART das Timing kaputt?

---

Weil die serielle Ausgabe eigentlich immer zu lange dauert. Sie blockiert damit entweder die CPU oder erzeugt zusätzliche Interrupts. Beides bringt einem das Timing gründlich durcheinander. Aber das ist das kleine Einmaleins vom Entwickeln im hardwarenahen Bereich. Debug-Code darf das Timing nicht beinflussen, sonst verdeckt er Fehler oder erzeugt neue.

Ausnahmen bestätigen natürlich die Regel. Und mit einem Scope kann man dann nachweisen, daß die erzeugten Signale trotz serieller Debugausgabe immer noch ok sind.

Zitat:

---

Zitat von HaWe

Ich aber glaube kaum, dass ich das Poblem mit einem Oszi eingrenzen könnte, denn dass es früher oder später mal hängt, ist klar, nur ob der Raspi nicht senden oder der Arduino nicht empfangen kann oder umgekehrt, kriege ich auch sicher mit einem Oszi nicht raus

---

Weswegen ich bei Schnittstellen, wie geschrieben, lieber den LA nehme. Aber was als letztes wirklich auf der seriellen passiert, bevor es hängt, kann man mit außreichend Pretrigger auch auf einem (digitalen) Scope sehen. Und wenn man bei einem UART-Error ein Port-Bit setzt und damit triggert, bekommt man auch eine Ahnung, wie und warum die Daten kaput gehen. Aus beiden Informationen kann man vermutlich schließen, was wirklich schief geht und die Ursache finden und beseitigen.

Zitat:

---

ich bin da übrigens auch ein ganzens Stück weiter inzwischen, und es liegt mit großer Wahrscheinlichkeit am Raspi, nicht am Arduino

---

Das klingt erstmal plausibel. Zwischen deinem Programm und der seriellen hängt beim Raspi die Laufzeitlibrarie und der Linux Kernel, und beide drehen so ihr eigenes Ding. Gerade da wäre es wichtig, wie die Zeitbeziehung zwischen deinem Programm (GPIO-Bit direkt setzen) und der wirklichen seriellen ist.

MfG Klebwax

Zitat:

---

Zitat von Klebwax

Weil die serielle Ausgabe eigentlich immer zu lange dauert. Sie blockiert damit entweder die CPU oder erzeugt zusätzliche Interrupts. Beides bringt einem das Timing gründlich durcheinander. Aber das ist das kleine Einmaleins vom Entwickeln im hardwarenahen Bereich. Debug-Code darf das Timing nicht beinflussen, sonst verdeckt er Fehler oder erzeugt neue.

Ausnahmen bestätigen natürlich die Regel. Und mit einem Scope kann man dann nachweisen, daß die erzeugten Signale trotz serieller Debugausgabe immer noch ok sind.

Weswegen ich bei Schnittstellen, wie geschrieben, lieber den LA nehme. Aber was als letztes wirklich auf der seriellen passiert, bevor es hängt, kann man mit außreichend Pretrigger auch auf einem (digitalen) Scope sehen. Und wenn man bei einem UART-Error ein Port-Bit setzt und damit triggert, bekommt man auch eine Ahnung, wie und warum die Daten kaput gehen. Aus beiden Informationen kann man vermutlich schließen, was wirklich schief geht und die Ursache finden und beseitigen.

Das klingt erstmal plausibel. Zwischen deinem Programm und der seriellen hängt beim Raspi die Laufzeitlibrarie und der Linux Kernel, und beide drehen so ihr eigenes Ding. Gerade da wäre es wichtig, wie die Zeitbeziehung zwischen deinem Programm (GPIO-Bit direkt setzen) und der wirklichen seriellen ist.

MfG Klebwax

---

Sorry, verstehe kein Wort.
der Mega sendet und empfängt per UART/USB, und der Raspi empfängt und sendet per UART/USB, und so soll es auch bleiben. Inwiefern mir da ein Oszi helfen könnte, verstehe ich nicht - aber du kannst es ja mal austesten!

PS
update, offtopic, nur zur Ergänzung:
ich vermute, ich habe das UART Problem gelöst!
Ich habe die UART-Kommunikation in einen extra pthread mit prio 60 ausgelagert, jetzt läuft es seit knapp 1 1/2 Stunden stabil ohne Unterbrechungen! 8)

Zitat:

---

Zitat von Klebwax

Weil die serielle Ausgabe eigentlich immer zu lange dauert. Sie blockiert damit entweder die CPU oder erzeugt zusätzliche Interrupts. Beides bringt einem das Timing gründlich durcheinander. Aber das ist das kleine Einmaleins vom Entwickeln im hardwarenahen Bereich. Debug-Code darf das Timing nicht beinflussen, sonst verdeckt er Fehler oder erzeugt neue.

---

Hmm, kann ich nicht nachvollziehen.
Der Ablauf der UART-ISRs liegt bei mir auf'm 8MHz AVR im einstelligen µs-Bereich, das Kopieren einer Telegrammstruktur in den Sende-Fifo dauert vielleicht mal 20µs. Das Lesen des Empfangs-Fifo mache ich zyklisch aus nem Timer oder aus der main() als ASAP (as soon as possible). Bei einer 115kBaud-UART kommt man so nicht höher als 20..30% Auslastung für eine UART unter Volllast (Teufel, was soll das für eine Mörderapplikation sein, die aus nem Controller wirklich kontinuierlich 10kB/s sinnige Daten erzeugt?!).

Ich wüsste nicht, was das kaputt machen sollte. Wenn es vom Timing her so kritisch ist, muss man für die anderen Funktionen halt mal die Peripheriemodule (InputCapture/PWM/ADC/...) konsequent nutzen.

Zitat:

---

Zitat von Holomino

Hmm, kann ich nicht nachvollziehen.
Der Ablauf der UART-ISRs liegt bei mir auf'm 8MHz AVR im einstelligen µs-Bereich, das Kopieren einer Telegrammstruktur in den Sende-Fifo dauert vielleicht mal 20µs. Das Lesen des Empfangs-Fifo mache ich zyklisch aus nem Timer oder aus der main() als ASAP (as soon as possible). Bei einer 115kBaud-UART kommt man so nicht höher als 20..30% Auslastung für eine UART unter Volllast (Teufel, was soll das für eine Mörderapplikation sein, die aus nem Controller wirklich kontinuierlich 10kB/s sinnige Daten erzeugt?!).

Ich wüsste nicht, was das kaputt machen sollte. Wenn es vom Timing her so kritisch ist, muss man für die anderen Funktionen halt mal die Peripheriemodule (InputCapture/PWM/ADC/...) konsequent nutzen.

---

Na dann hast du ja alles im Griff und brauchst weder Scope noch LA.

MfG Klebwax