Entwicklung digitaler Schaltungen im Khz- bzw. Mhz-Bereich

[Ralf Stöckmann (Gast)]

Guten Tag,

ich würde gerne mal µC-Projekte im Kiloherz-Bereich und später
auch mal im Megaherz-Bereich (alles zu seiner Zeit) in Angriff
nehmen und frage mich, wie man wohl am besten die Fehler debuggt,
die sich wohl bei jedem mal in einem Projekt einschleichen können.

Mein DCF77-Projekt hat mich schon ganz schön Nerven gekostet, da
ich alles selbst in Assembler programmiert habe und es doch eine
Weile gedauert hat, bis ich die verschiedenen Timings im Milli-
sekunden-Bereich bzw. die sichere Erkennung der Signaldauer und
der Pausen zwischen den Signalen ziverlässig in den Griff bekommen
habe.

Ein fiktives Beispiel:

Ein Mikrocontroller soll eine PS2-Tastatur durchschleifen: Dafür
benötigt man im Wesentlichen einen PIC, 4 Ports für die Tastatur
und weitere 4 Ports für den Anschluss am PC.
Falls die Schaltung nicht läuft, frage ich mich wie man dem Fehler
mit Hilfe eines Oszis auf die Schliche kommen kann? Ich lese dann
oft in diversen Foren "hab dann mit dem Oszi gesehen, dass da kein
CLK erzeugt wurde..." oder ähnlich. Ich frage mich dann immer,
wie man bei 16 Khz noch irgendwelche nicht periodischen Signale
debuggen kann (von den Möglichkeiten im IDE mal abgesehen)?

USB-Oszilloskope bzw. dessen Transientenrekorder messen - sofern
überhaupt einer vorhanden ist - im mS-Bereich pro Div, für eine
Analyse im Khz- oder gar im Mhz-Bereich meiner Meinung nach
kaum brauchbar. Jedenfalls habe ich nur eine Handvoll USB-
Oszilloskope gefunden und die waren Softwaretechnisch nicht
gerade der Hit.
Und bei digitalen Speicher-Oszilloskopen frage ich mich immer,
wie man jetzt genau den richtigen Abschnitt zu sehen bekommt,
an dem der Fehler auch auftritt? Schließlich haben die
bestimmt nicht die Möglichkeit, über einen längeren Zeitraum
(eine halbe Sekunde) Signale mit einer Auflösung im µS-Bereich
präzise darzustellen. Oder ist es im Hochfrequenten Bereich eher
so, dass man den Fehler nur noch mit Hilfe des im IDE vorhandenen
Stimulus-Controller in Verbindung mit Breakpoints entdecken kann? Wobei
ich mich dann immer Frage, ob ein sauber generiertes Rechteck
vom Stimulus wirklich mit den schmutzigen Wald- und Wiesen-Signalen
vergleichbar ist, die man von den in der Realität angeschlossenen
Geräten empfängt?

Viel Erfahrung habe ich mit digitalen Speicher-Oszilloskopen
leider nicht, aber wenn ich wüßte, mit welchem Equipment man wie welche
Probleme lösen kann, würde mir das bei meiner anstehenden
Kaufentscheidung helfen. Ich bin nämlich noch am Überlegen, ob
ich mir für meine zukünftigen digitalen Schaltungen eher ein
gutes gebrauchtes Digitales Oszi bei Ebay schieße oder mir doch
lieber ein Zweikanal-USB-Scope mit Software kaufe.

Ralf Stöckmann

[Winfried (Gast)]

Mit einem Speicheroszi solltest du grundsätzlich alles hinbekommen. Zwei
Kanäle und einen Triggereingang brauchst du. Dein Prozessor kann ja
passende Triggerimpulse senden, damit du auf das richtige Teilstück
deines Protokolls triggerst. Zwei Kanäle brauchst du, um Signale ins
Verhältnis zu setzen.

Bequemer sind noch Logikanalyzer, weil man da z.B. 16 Kanäle auf einmal
beobachten und in Beziehung setzen kann.

Auch mit einem normalen Oszi kann man schon einiges machen, wenn man
Triggerimpulse vom Controller aus rausschickt, mit dem man dann das
Oszi triggert.

Viele arbeiten auch nach der Methode: Ordentlich nachdenken, sauberes
Design, saubere Implementierung. Und wenn es nicht funktioniert, alles
nochmal durchdenken, bis der Groschen fällt. Ist etwa genauso wie in
der Anwendungsentwicklung: Ich kenne genügend professionelle
Softwareentwickler, die haben noch nie einen Debugger benutzt.
Nachdenken, beobachten, Debugausgaben, verändern führt auch zum Ziel.

[Michael (Gast)]

"Ich kenne genügend professionelle Softwareentwickler, die haben noch
nie einen Debugger benutzt. Nachdenken, beobachten, Debugausgaben,
verändern führt auch zum Ziel."

Endlich einmal jemand, der mir aus der Seele spricht :-)
Es kostet Geld, aber ich würde einen Speicheroskar mit tiefem Speicher
empfehlen (Megabytes). Wenn ich sehe, wie wenig ich meinen
Logikanalysator verwendet habe, würde ich eher ein Oszi mit vier
Kanälen bevorzugen: ist einfacher anzuschließen, ist flexibler und die
Darstellung bleibt übersichtlich. Die neueren Geräte unterstützen auch
sinnvolle Triggermodi, wie z.B. Vergleich auf Pulsbreite ...
Für 'Basteleien' sind diese Teile zu teuer; aber auch ein Profi muß
darauf achten, daß sich die Anschaffungskosten bezahlt machen.

[Fritz G. (fritzg)]

Ich arbeite grad mit einem Bitscope USB-Oszi mit 8-Kanal Logikanalyzer.
Wobei der Logikanalyzer hilfreicher ist, da bei einem 2-Kanal Oszi die
beiden Kanäle nicht gleichzeitig aufgezeichnet werden, d.h. bei
nichtperiodischen Signalen siehst du den 2. Kanal eine Triggerung
später, was manchmal unbrauchbar ist.

Das Ding kostet um die 300 Euronen, und es gibt die Software dazu auch
als Linuxversion.

Sonst arbeite ich auch fast nie mit debugger sondern mit printf auf die
serielle Schnittstelle.