-         
+ Antworten
Seite 4 von 5 ErsteErste ... 2345 LetzteLetzte
Ergebnis 31 bis 40 von 41

Thema: Welches Oszilloskop für Anfänger ?

  1. #31
    Erfahrener Benutzer Begeisterter Techniker
    Registriert seit
    07.04.2015
    Beiträge
    394
    Anzeige

    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.

  2. #32
    Erfahrener Benutzer Robotik Visionär Avatar von oberallgeier
    Registriert seit
    01.09.2007
    Ort
    Oberallgäu
    Beiträge
    7.934
    .. 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.
    Ciao sagt der JoeamBerg

  3. #33
    Erfahrener Benutzer Robotik Einstein
    Registriert seit
    09.10.2014
    Beiträge
    4.232
    Zitat Zitat von oberallgeier Beitrag anzeigen
    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.
    ·±≠≡≈³αγελΔΣΩ∞ Schachroboter:www.youtube.com/watch?v=Cv-yzuebC7E Rasenmäher-Robot:www.youtube.com/watch?v=z7mqnaU_9A8

  4. #34
    Erfahrener Benutzer Robotik Einstein
    Registriert seit
    07.03.2011
    Beiträge
    1.635
    Zitat Zitat von HaWe Beitrag anzeigen
    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 Beitrag anzeigen
    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
    Strom fließt auch durch krumme Drähte !

  5. #35
    Erfahrener Benutzer Begeisterter Techniker
    Registriert seit
    07.04.2015
    Beiträge
    394
    Zitat Zitat von Klebwax Beitrag anzeigen
    ...und serieller (die einem das Timing typisch komplett kaput macht), ...
    Wo macht einem die UART das Timing kaputt?

  6. #36
    Erfahrener Benutzer Robotik Einstein
    Registriert seit
    09.10.2014
    Beiträge
    4.232
    Zitat Zitat von Klebwax Beitrag anzeigen
    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 ) .
    Geändert von HaWe (12.06.2019 um 12:20 Uhr)
    ·±≠≡≈³αγελΔΣΩ∞ Schachroboter:www.youtube.com/watch?v=Cv-yzuebC7E Rasenmäher-Robot:www.youtube.com/watch?v=z7mqnaU_9A8

  7. #37
    Erfahrener Benutzer Robotik Einstein
    Registriert seit
    07.03.2011
    Beiträge
    1.635
    Zitat Zitat von Holomino Beitrag anzeigen
    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 Beitrag anzeigen
    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.

    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
    Strom fließt auch durch krumme Drähte !

  8. #38
    Erfahrener Benutzer Robotik Einstein
    Registriert seit
    09.10.2014
    Beiträge
    4.232
    Zitat Zitat von Klebwax Beitrag anzeigen
    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!
    Geändert von HaWe (12.06.2019 um 18:11 Uhr)
    ·±≠≡≈³αγελΔΣΩ∞ Schachroboter:www.youtube.com/watch?v=Cv-yzuebC7E Rasenmäher-Robot:www.youtube.com/watch?v=z7mqnaU_9A8

  9. #39
    Erfahrener Benutzer Begeisterter Techniker
    Registriert seit
    07.04.2015
    Beiträge
    394
    Zitat Zitat von Klebwax Beitrag anzeigen
    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.
    Geändert von Holomino (13.06.2019 um 13:40 Uhr)

  10. #40
    Erfahrener Benutzer Robotik Einstein
    Registriert seit
    07.03.2011
    Beiträge
    1.635
    Zitat Zitat von Holomino Beitrag anzeigen
    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
    Strom fließt auch durch krumme Drähte !

+ Antworten
Seite 4 von 5 ErsteErste ... 2345 LetzteLetzte

Ähnliche Themen

  1. Verkaufe Verkaufe ein Oszilloskop VOLTCRAFT® 610/2 Analoges 1-Kanal Oszilloskop
    Von funkheld im Forum Kaufen, Verkaufen, Tauschen, Suchen
    Antworten: 0
    Letzter Beitrag: 28.11.2012, 18:56
  2. [ERLEDIGT] Günstiges Anfänger-Oszilloskop Hameg HM312
    Von BASTIUniversal im Forum Kaufen, Verkaufen, Tauschen, Suchen
    Antworten: 1
    Letzter Beitrag: 01.04.2012, 04:06
  3. Welches Modell ist am besten für anfänger
    Von zunami6 im Forum C-Control II
    Antworten: 0
    Letzter Beitrag: 19.04.2006, 13:53
  4. Anfänger - welches Buch?
    Von claire im Forum Buchempfehlungen
    Antworten: 2
    Letzter Beitrag: 17.04.2006, 13:14
  5. Anfänger: welches modul sollte man als anfänger nehmen???
    Von patti16 im Forum AVR Hardwarethemen
    Antworten: 5
    Letzter Beitrag: 04.01.2005, 08:44

Berechtigungen

  • Neue Themen erstellen: Ja
  • Themen beantworten: Ja
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •