Hallo zusammen, ich habe mal eine Frage an die Hobby-Entwickler da draußen. Wofür brauche ich als Hobbyist(!) einen Logic-Analyzer, der jenseites der 50MHz oder auch jenseits der mittlerweile üblichen 24MHz arbeitet? Wer hat so ein Ding und ist als Hobbyist an seine Grenzen gestoßen? Was hab ich da übersehen? Kann ich mir da getrost so einen Billigheimer zulegen, denn die bringen ja meist schon Decoder/Analyzer für UART/SPI/I2C mit und sind preislich wirklich extrem interessant. Ich hab mal kurz gelistet was man so an gängigen Bussen und Busgeschwindigkeiten da draußen findet: - CAN max 1MBit - Profibus max 12MBit (aber 1,5MBit üblich) - UART max. 3MBit üblich - SPI zwar mehrere MHz möglich, aber meist nicht über 4MHz - I2S (48Khz) 3MHz - I2C, meist 400kHZ, max 1MHz bis 3,4MHz - 1Wire bis 1MHz - LIN bis 20kHz - IO-Link 230kHz - Interbus 500kHz - USB 1,5Mhz, 12MHz, 480MHz - EIB / KNX 9,6kHz - Hi-Speed-IOs am STM32F1xx max. 18MHz mit CPU@72MHz Was kann ich mit so einem "Billigheimer"-LA denn nicht machen, was mich aber als Hobbyist tatsächlich mal interessieren könnte? Und wann braucht es mal mehr als 8 Datenleitungen? Einzig was mich momentan stören könnte wäre USB. Bei Ethernet interessiert mich die Kommunikation ZUM Baustein, aber nicht was auf der Ethernetleitung selbst abgeht, wie beim Net-IO der ENC28J60. Und vielleicht auch Speicherinterface, z.B. bei FPGA-Programmierung oder so. Wenn ich jetzt aber auf USB/Ethernet/Memory verzichte, fahre ich doch mit einem 24MHz USBee/Saleae/PoScope oder sonstwie doch gar nicht so schlecht? Ich meine damit nicht die Pegelwandler zum LA, die galvanische Trennung oder sonstwas. Dass ich die evtl. brauche ist mit klar. Mir geht es vor allem um die Bandbreitenbeschränkung. Schließlich würde ein 4MBit-Bus, der mindestens mit 8MHz abgetastet werden muss, bei 24MHz immer noch 3-fach überabgetastet werden.
Um etwas über den Signalcharakter aussagen zu können und die Verzögerungen paralleler Leitungen untereinander, solltest du mindestens um den Faktor 5, besser 10 bei der Abtatsung drüber liegen. Mit einem 24M Analyzer solltest du unter diesen Gesichtspunkten maximal 2Mbaud-Signale untersuchen. Wenn es für dich langt und du vor der direkten Verbindung zwischen Gerät und Analyzer/PC nicht zurückschreckst...
>Schließlich würde >ein 4MBit-Bus, der mindestens mit 8MHz abgetastet werden muss, bei 24MHz >immer noch 3-fach überabgetastet werden. Hatten wir doch gerade Beitrag "Warum "dreht" Quarzoszillator Duty-Cycle?" Da hat sich einer gewundert das sein Clocksignal unsymmetrisch ist. Mit einem Osci hätte er gesehen das es nicht so ist. Mit einem 240MHz LA hätte er das Problem nicht gehabt.
Fragender schrieb: > Was > hab ich da übersehen? Z.B. die Glitch-Erfassung. Dafür kann die Abtastfrequenz garnicht hoch genug sein. Übrigens liegen viele heutige Logik-IOs unter 1 ns Schaltzeit, um z.B. Setup/Hold-Bedingungen zu erfassen, sind da Gigaherze wünschenswert. Das heisst im Wesentlichen, für Softwarefehler reichen langsame LAs, für Hardwarefehler-Suche aber nicht. Gruss Reinhard
Wenn Du wirklich nur Busprotokolle untersuchen willst, fällt ein Logic-Analyzer wahrscheinlich in die Kategorie: Kanonen und Spatzen. Ein Oszilloskop oder ein Billigheimer mit ordentlicher Speichertiefe ist hier wohl angebrachter. Wichtig wäre allerdings einer mit einer ordentlichen Protokollauswertung. Es gibt übrigens für viele Protokolle angepasste und vor allem handliche Prüfgeräte. Beispiele hierfür z.B. Netzwerk-, CAN- oder die guten alten seriellen Prüfgeräte. Willst/musst Du aber Pegel, Kollisionen und Reflektionen per Handschlag begrüßen, so hilft nur gutes - sprich schnelles - Equipment. Hast Du gleich mehrere Signale im Auge, so muss meist ein großes Geschütz her.
Falls man mit FPGAs bastelt, sind mehr als 8 Kanäle und mehr als 24MS/s, d.h. USB2.0 Bandbreite durchaus nützlich
Ich hab den Open Bench Logic Sniffer (http://gadgetfactory.net/logicsniffer/), der ist zwar mit ~50 EUR auch theoretisch ein "Billigheimer" aber ich nutz den ganz gut bis an seine Grenzen. Der Sniffer kann 16 Bit mit 200 Msp/s oder 32 Bit mit 100 Msp/s. In der letzten Zeit hab ich den viel benutzt um die Schnittstelle zwischen einem 16 Bit RGB Display und einem STM32F4Discovery Board zu debuggen. (Relevanter Thread mit Screenshots: Beitrag "STM32F4 mit ILI9325 funktioniert nicht" ) Dafür brauch ich 20 Bit und eigentlich bräuchte ich 200 Msp/s. Die Frequenz des FSMC geht schon stark an die Auflösungsgrenzen bei 100 Msp/s. Auch in anderen Bereichen gibts bei den größeren ARM Cortex-M Chips Situationen wo 100 Msp/s oder mehr Sinn machen.
amateur schrieb: > Willst/musst Du aber Pegel, Kollisionen und Reflektionen per Handschlag > begrüßen, so hilft nur gutes - sprich schnelles - Equipment. Pegel und Reflektionen sind bestimmt nicht die Domäne von LAs, um die es hier geht.
Reinhard Kern schrieb: > Z.B. die Glitch-Erfassung. Dafür kann die Abtastfrequenz garnicht hoch > genug sein. Eine Glitch-Erfassung macht ein LA aber normalerweise nicht durch Oversampling, sondern durch Flipflops, die per Flankenwechsel gesetzt werden und so auch einen Glitch zwischen 2 Abtastungen erfassen können. Sowas einzubauen kostet aber auch zusätzlich Geld und Gehirnschmalz... ;-) holger schrieb: > Mit einem Osci Schreb doch bitte "Oszi" (von Oszilloskop). Oder, wenns schon unbedingt neudeutsch sein soll, dann so, wie die Angelsachsen sagen: "Scope".
Hallo, vielen Dank für die Rückmeldungen und vor allem für deren guter Qualität. Ich hatte schon bedenken, dass das mal wieder in eine China-Schrott Diskussion und Rumgeprahle mit Equipment wird, was die Leute nur in der Firma haben und ein Einfamilienhaus kostet. Vielleicht sollte ich öfters mal nachts posten, wo nur der "harte Kern" übrig ist und nicht mittags, wenn frustriert vom Arbeitgeber-PC in der Mittagspause rumgemosert und gepöbelt wird... :-) Daher hier auch mal ne ordentliche Rückmeldung meinerseits: >Wenn es für dich langt und du vor der direkten Verbindung zwischen Gerät >und Analyzer/PC nicht zurückschreckst... Galvanisch getrennt macht vielleicht später Sinn, aktuell werden bei mir schon uC-Kits aus dem PC heraus versorgt. Für ein stand-alone Gerät hab ich eigentlich keinen Platz. Daher kann ich mit der USB-Masseverbindung erstmal leben. >Mit einem 24M Analyzer solltest du unter diesen Gesichtspunkten maximal >2Mbaud-Signale untersuchen. Ja, aktuell kommt mir nichts über 2MBit in den Sinn. I2C geht noch mit dem 2Ch-Oszi aber wirklich auf die Suche nach einem LA hab ich mich gemacht, weil mir aktuell eine SW-SPI kopfzerbrechen bereitet. Außerdem nehme ich das Oszi ganz oft nur zur Beobachtung eines Toggle-Pins bei schnellem ISR-Debugging. Da sollte mir der PC-LA vor allem viel Platz und rumhantieren ersparen. >Hatten wir doch gerade >Beitrag "Warum "dreht" Quarzoszillator Duty-Cycle?" >Mit einem 240MHz LA hätte er das Problem nicht gehabt. Da wurde versucht die Flankenqualität und duty-cycle eines 8MHz Quarzes mit einem 24MHz-LA zu beurteilen -> Das war nicht meine Frage... Nyquist-Shannon ist mir ein Begriff und für so ein Vorhaben würde ich dann schon mein Oszi nehmen. >Z.B. die Glitch-Erfassung. >um z.B. Setup/Hold-Bedingungen zu erfassen, sind da GHz wünschenswert. >Das heisst im Wesentlichen, für Softwarefehler >reichen langsame LAs, für Hardwarefehler-Suche aber nicht. Ok, ich bin ja meist auf der Suche nach SW-Fehlern, wenn mir dann was komisch vorkommt, kann ich ja immer noch mein Oszi nehmen (50Mhz/2Ch, war schon teuer genug) >Oszilloskop oder ein Billigheimer mit ordentlicher Speichertiefe ist >hier wohl angebrachter. Wichtig wäre allerdings einer mit einer >ordentlichen Protokollauswertung. Ok, das wäre mit dem OpenBench LS oder einem Cypress FX2 basierten Gerät und sigrok doch drin? >Es gibt .. angepasste .. Prüfgeräte >Willst/musst Du aber Pegel, Kollisionen und Reflektionen .. so hilft nur >gutes - sprich schnelles - Equipment. Hast Du gleich mehrere Signale im >Auge, so muss meist ein großes Geschütz her. Spezielle Prüfgeräte, teures Profi-Equip -> kollidiert mit Hobbyist/Budget. Falls ich da mal draufschaue, dann muss es mein Oszi richten. Wenn ich dann an die Grenzen meines Oszis stoße, hab ich halt Pech gehabt. Aber damit kann ich wahrscheinlich leben. >Falls man mit FPGAs bastelt, sind mehr als 8 Kanäle und mehr als 24MS/s, >d.h. USB2.0 Bandbreite durchaus nützlich Bitte mal oben ordentlich durchlesen. Zu der Erkenntnis kam ich auch. Ist aber für meine Anwendungen erstmal egal (steht auch oben). >Ich hab den Open Bench Logic Sniffer >Der Sniffer kann 16 Bit mit 200 Msp/s oder 32 Bit mit 100 Msp/s. Der OpenBench LS sieht wirklich gut aus. Ich würde ihn wohl wegen der Prokolollvielfalt mit sigrok nutzen (kann dann aber nur 100MHz). Allerdings macht micht die Speichertiefe ein wenig stuzig. Während die Cypress FX2-basierten bei sigrok mit mehr oder weniger beliebig langer Zeit auf den Bus schauen können, hat der OpenBench LS eine begrenzte Speichertiefe. >Beitrag "STM32F4 mit ILI9325 funktioniert nicht" >Die Frequenz des FSMC geht schon stark an die Auflösungsgrenzen bei 100 >Msp/s. Auch in anderen Bereichen gibts bei den größeren ARM Cortex-M >Chips Situationen wo 100 Msp/s oder mehr Sinn machen. Ja das Speicherinterface für ein RGB-Display und die ARMs sind doch wirklich mal ein Anwendungsfall für mich. Den Kommentaren von Lothar und profi pflichte ich für meine Anwendung erstmal bei. Ist nicht meine primäre Anwendung. Fazit für mich: Als Software sieht sigrok für mich Momentan wegen der Protokollvielfalt am besten aus. Zusammen mit dem OpenBench LS hätte ich eine nette Lösung aus OpenSource und OpenHardware. Allerdings haben die Cypress-Clones eine immense Speichertiefe um mal Daten am Bus mitzuschreiben. Um nochmal auf die galvanische Trennung zu kommen: Es gibt die USB-Isolatoren nur bis max. 12MBit (ich hab keine anderen gefunden, nur Leute die auch keine schnelleren gefunden haben). Bei den Cypress-Clones wird das dann wohl nicht funktionieren(24MHz*8=192MHz, das kriegt man nicht auf einen 12MBit-USB komprimiert) OpenBench LS arbeitet über die Emulation einer seriellen Schnittstelle und sollte mit einem 12MBit-Isolator auskommen ? Hat das schonmal jemand gemacht ?
Rein prinzipiell muss ein per USB angebundener LA die galvanische Trennung nicht ausgerechnet an der USB-Schnittstelle durchführen. Das kann man auch an anderen Teilen machen, beispielsweise an der Schnittstelle zwischen USB-Controller und dem datenerfassenden FPGA. Bei Deinen Geschwindigkeitsbetrachtungen übersiehst Du, daß der LA lokalen Speicher hat, und daß dessen Übertragung an den PC prinzipiell beliebig langsam erfolgen kann, ohne die Samplerate zu beeinflussen. Allerdings ist in so einem Fall die Anzahl der erfassbaren Samples von der Größe des lokalen Speichers abhängig.
Fragender schrieb: > Und wann braucht > es mal mehr als 8 Datenleitungen? Das brauche ich häufig. Nimm ein Setup mit beispielsweise zwei Funk-Transceivern (bei mir meist IEEE 802.15.4, aber prinzipiell unterscheidet sich das nicht von bspw. einem RFM12 hier). Da hast du als erstes die Standard-SPI-Interfaceleitungen, 4 Stück an der Zahl (MISO, MOSI, SCK, /SS). Dann hast du typisch noch mindestens IRQ und /RESET für den Transceiver, oft noch ein, zwei Signale mehr (bei mir bspw. SLP_TR). Damit wäre man bei 7 Leitungn, aber pro Seite. Wenn ich jetzt aber was debuggen will, dann geb' ich gern noch auf einem freien 8-Bit-Port des Controllers eine Art Statusbyte aus, welches mir das Tracen der Software gestattet. bei jedem Funktionsein- und -austritt wird da einfach ein Byte ausgegeben. Das verändert praktisch das Echtzeitverhalten nicht, aber ich kann hinterher in der LA-Aufzeichnung nachvollziehen, an welcher Stelle die Software gerade hantiert hat. Damit sind wir aber schon mal bei 32 bit als Minimalforderung. Speichertiefe kann man sowieso nie genug haben ;-), je mehr man hat, um so weniger Aufwand muss man in die Triggerbedingung investieren. Meist haben die Billigheimer ohnehin nicht so viel Möglichkeiten für die Triggerung. Was mir beim Verfolgen von nur sporadisch auftretenden Software- problemen stets sehr von Nutzen war, ist eine ordentliche Aufzeichnung der Signale ausschließlich bei einer Zustandsänderung. Damit kann man ein Setup stundenlang herumdümpeln lassen, solange sich nichts tut, wird auch kein Speicher verbraucht. Im Extremfall braucht man dann gar keine Triggerbedingung mehr, sondern drückt nach dem Auftreten des Problems einfach die Stop-Taste und analysiert die Daten. Allerdings habe ich eine brauchbare Aufzeichnung dieser Art bislang nur bei den wirklich teuren LAs gesehen; selbst der Zeroplus ist da nur Spaß. Die haben offenbar nur ein Byte für die Zeitdifferenz vorgesehen, sodass nach je 255 Samples (bei 10 ns Abtastung also nach 2,55 µs) dann doch der nächste Speicherplatz belegt wird. Schicke Protokollauswertungen sind ein nettes Gimmick, aber die kann man immer dadurch ersetzen, dass man die Daten exportiert und anschließend selbst mit einer Scriptsprache oder dergleichen anlysiert. Das hat den zusätzlichen Vorteil, dass ich mir die Auswertung auf meine tatsächlich benutzte Hardware maßschneidern kann, d. h. ich muss nicht (um beim obigen Beispiel zu bleiben) auf der Ebene "SPI" stehenbleiben, sondern kann gleich auf Ebene von Registerlese- und -schreioperationen etc. abstrahieren. Sowas kann naturgemäß eine im LA eingebaute Analyse nicht leisten.
Um die Schnittstelle zwischen dem FPGA und dem USB-Controller zu trennen, müsste ich bei dem OpenBench einen üblen Hardwareeingriff vornehmen (UART trennen, Stromversorgung 1,8, 2,5 und 3,3V trennen). Dann doch lieber einen fertigen USB-Isolator, sofern der eben geht. Bei den Cypress-Clones ist das wohl nur am Pufferbaustein möglich, da sitzt kein FPGA drin und der 12MBit-Isolator ist zu langsam. Nein, soweit ich das verstanden habe, hab ich bei der Geschwindigkeitsbetrachtung das o.g. nicht übersehen. Deshalb ist die Speichertiefe des OpenBench LS ja beschränkt, weil er die 100MS intern wegschreibt und dann über 115k seriell wieder rausschiebt. Irgendwann ist der Speicher voll, da sich die Daten deutlich schneller anhäufen, als sie weggeschrieben werden. Die Cypress-Clones übertragen direkt per USB die 24MHz Rohdaten und sind von der Speichertiefe nur so beschränkt wie der PC dahinter.
@Jörg Ok, anzufangen jeden IO am Controller+Peripherie zu Überwachen ist ja nicht mein Ziel. 8 Leitungen zu sprengen krieg ich noch hin, aber mehr als 16 kommen bei mir erstmal nicht zusammen, es sei denn ich will mich an den FSMC hängen. Mal eben schnell eigene Skripte schreiben um Protokolle auszuweten? So ein Freak, der da mal eben für einen Export einen Dreizeiler tippt um sowas zu analysieren bin ich auch nicht. Da bleib ich erstmal bei OpenBench LS und sigrok.
Fragender schrieb: > Ok, anzufangen jeden IO am Controller+Peripherie zu Überwachen ist ja > nicht mein Ziel. Es ging nicht darum, jeden Pin zu "überwachen", sondern parallel zu den eigentlichen Daten noch ein Statusbyte mitzumeißeln, damit man die Software besser verfolgen kann. Bei einer Echtzeitkommuni- kation kannst du ja nicht einfach mal mit dem Debugger anhalten um zu sehen, wo du gerade in der Software "durchrutschst", weil dann das Timing im Eimer ist. Das schnelle Ausgeben eines zusätzlichen Bytes hin und wieder über einen Parallelport ist dagegen keine ernsthafte Einschränkung. Wenn man nur 4 Bits hat, geht das sicher auch. Wenn man das dann eben zweimal hat (für zwei Kommunikationspartner, die man untersuchen möchte), dann läppert sich das. > Mal eben schnell eigene Skripte schreiben um Protokolle auszuweten? So > ein Freak, der da mal eben für einen Export einen Dreizeiler tippt um > sowas zu analysieren bin ich auch nicht. Kenntnis wenigstens einer Scriptsprache hat einem Softwareentwickler noch nie geschadet. ;-) Nicht jedes Problem lässt sich durch Excel lösen (mit dem ich, nebenbei gesagt, überhaupt nicht klar komme).
Fragender schrieb: > Wofür > brauche ich als Hobbyist(!) einen Logic-Analyzer Ja, das frage ich mich auch. Wozu meinst Du denn, ihn zu benötigen? Daß es Busse gibt, die man benutzen will, ist noch lange kein Grund, einen LA kaufen zu müssen. Fragender schrieb: > weil mir aktuell eine SW-SPI kopfzerbrechen bereitet. Ach komm, dazu braucht man doch keinen LA. Starte einfach den Simulator und steppe durch die 8 Bits durch. Und ob Du irgendwelche Hardwareprobleme (gegeneinander kämpfende Ausgänge) hast, siehst Du viel besser mit dem Oszi. Ich geb zu, das hier würde mich schon reizen: http://tmi.yokogawa.com/de/products/oscilloscopes/digital-und-mixed-signal-oszilloskope/dlm4000-mso-series/ 8 Kanäle, wow. Aber fürs Hobby würde ich mir auf keinen Fall einen LA zulegen. Da hat man doch Zeit und kann in Ruhe überlegen, wo man den Fehler im Programm gemacht hat. Nen LA zu nehmen, ist wie beim Sudoku auf die Lösungsseite zu gehen. Wo bleibt die Herausforderung. Und der Stolz, es selbst geschafft zu haben. Auch gibt es viele Fehler, die man nur durch Überlegen finden kann. Z.B. eine fehlende atomare Kapselung, die nur alle paar Stunden den Interrupt zur falschen Zeit zerrammelt. Da nützt der LA garnichts. Peter
>Wieso sollte das so wenig sein? Weil der OpenBench LS so konzipiert wurde. Ich werd jetzt nicht am VHDL-Code rumfummeln. Bitte erstmal nachschaun, bevor man dazu was postet. >Kenntnis wenigstens einer Scriptsprache hat einem Softwareentwickler >noch nie geschadet. ;-) Nein, aber man kann sichs auch unnötig schwer machen. >Nen LA zu nehmen, ist wie beim Sudoku auf die Lösungsseite zu gehen. Wo >bleibt die Herausforderung. Und der Stolz, es selbst geschafft zu haben. Wie gesagt, man kann es sich auch unnötig schwer machen. >Starte einfach den Simulator und steppe durch die 8 Bits durch. Welchen Simulator? Ich hol mir doch nicht für jeden Controller ein JTAG oder den Emulator/Simulator. Die Wahl ist getroffen: Ich besorg mir den OpenBench LS. Das Ding ist nebenbei noch ein hübsches FPGA-Board, vielleicht kram ich ja tatsächlich mal meine VHDL-Kenntnisse wieder raus. Als Software ist SUMP wohl etwas schwach, aber sigrok und OLS/LogicSniffer scheinen brauchbar.
Nochmals Danke an die aufmerksamen Leser mit den brauchbaren und themenbezogenen Posts :-)
Ich habe vor langer Zeit mal einen recht langen Kommentar zu diesem "Welcher Oszi ist für mich der Beste" geschrieben, aber ich finde ihn nicht mehr. Das Fazit ist aber 1:1 auf den LA anzuwenden. Man muss sich ansehen, was man mit dem Gerät "höchst selbst" tun möchte und was man sich vorstellen kann, in nächster Zeit auch noch zu machen. Es ist völlig egal, was andere damit machen, oder machen könnten. Es ist auch egal, was Du selbst damit in 5 Jahren machen können möchtest. Es bringt auch nichts, wenn Du Dir überlegst, welche Signale es am Markt gibt, die ein uC liefert, denn ich zeige Dir einen uC, der noch mehr liefert und das noch viel schneller. a) Schaue in Deinen Geldbeutel b) Gehe in Dich und überlege, was Du machen möchtest und halbiere das, denn Dir wird für so viel die Zeit nicht bleiben. Kaufe Dir das Beste was aus diesem Kompromiss übrig bleibt. c) Weine nicht, wenn es übermorgen einen LA mit 4x Auflösung für den gleichen Preis gibt, das ist immer so. Freue Dich, dass wenn Du in 2..4 Jahren tatsächlich zu einem noch schnelleren uC mit noch mehr Bussen kommst, Du Dir auch einen neuen noch schnelleren LA leisten kannst. d) verabschiede Dich dann in x Jahren von Deinem ersten LA mit dem Wissen, dass er Dir gut gedient hat. Ach ja: Kleiner Nachtrag: ein LA ist kein Oszi und wenn man beides hat, sollte man nicht von dem einen die Fähigkeiten des anderen erwarten. Also wenn man Glitches und Timing Probleme sucht, dann reichen i.d.R. auch zwei Probes an einem Oszi, mit denen man dann sequenziell die Flanken zwischen z.B. CLK und Data[n] untersucht. Dass man alles parallel auf dem Schirm haben muss ist ein Irrglaube und oft erzeugt das geballte Geklipse von 60 Probes auf eine Folie mit 120 Leiterbahnen in 4mil mehr Probleme als man damit finden kann. Und es kostet 5x so viel Zeit wie das nacheinander Kontaktieren mit einer Probe. Hat man die Signalqualität mit dem Oszi überprüft und hat logische Probleme, dann kommt der LA zum Einsatz. Gruß, Ulrich
Fragender schrieb: >>Wieso sollte das so wenig sein? > Weil der OpenBench LS so konzipiert wurde. Ich werd jetzt nicht am > VHDL-Code rumfummeln. Bitte erstmal nachschaun, bevor man dazu was > postet. Ich bin mir nicht sicher, ob das in den Specs irgendwo steht, aber zumindest mit den Jawis Client erlaubt der Sniffer bis zu 921 600 bps, nicht viel besser, aber immerhin.
>Eine Glitch-Erfassung macht ein LA aber normalerweise nicht durch >Oversampling... Doch, z.B haben Tektronix und Agilent dafür sep Zoom-Modes, während dem die Abtast-f vielfach erhöht ist. (einige GS/s). Denn auf einen Glitch zu triggern ist in Realität fast unmöglich. Man muss sich den Verlauf ansehen, dafür braucht man die höhere S/s.
René B. schrieb: > Um etwas über den Signalcharakter aussagen zu können und die > > Verzögerungen paralleler Leitungen untereinander, solltest du mindestens > > um den Faktor 5, besser 10 bei der Abtatsung drüber liegen. Wenn das mal reicht! Messen heisst innerhalb der Toleranz und das ist bei digitalen Signalen der Jitter. Der ist im Bereich von <1%. Einen 50 MHz Takt musst Du also mit 5 GHz genau vermessen. Das war es dann schon. Die Datenleitungen brauchst Du natürlich nur im Bezug zum Takt und musst deren ungefähre Reserve sehen. Dazu reicht in der Takt Faktor 5. Aber: Heutige Digitalschaltungen laufen intern kaum noch unter 100MHz, siehe DSPs, MCUs etc, also landen wir doch wieder beim 500 MSPS - Analyzer.
>Wenn ich jetzt aber auf USB/Ethernet/Memory verzichte Hierfür gibts auch günstige Geräte um 100,- Euro. >musst Du also mit 5 GHz genau vermessen Mag ja sein, aber wenn ich den ersten Post so lese, gehts Ihm eher um die Bus-Analyse. Und da braucht man sicher keine 5 GHz Abtastrate.
Fragender schrieb: > ich habe mal eine Frage an die Hobby-Entwickler da draußen. Wofür > brauche ich als Hobbyist(!) einen Logic-Analyzer, der jenseites... Ich würde die Frage ganz anders stellen: Braucht man als Hobbyist überhaupt einen Logikanalysator? oder Was für ein Hobby müßte es sein, wofür man einen Logikanalysator braucht? Mir fällt selbst bei heftigstem Nachdenken kein Fall ein, wo man als Bastler wirklich einen LA braucht. Wenn man einen LA hat, dann ist das ja ganz nett und man findet dann auch eine Gelegenheit, ihn auszuprobieren, aber BRAUCHEN ist was Anderes. Als Hobbyist sollte man sein Geld lieber in ein Oszilloskop investieren. Das ist die nützlichere Variante. W.S.
W.S. schrieb: > Als Hobbyist sollte man sein Geld lieber in ein Oszilloskop investieren. > Das ist die nützlichere Variante. Würd ich so nicht sagen. Nen Oszilloskop wär toll, aber ich habs bisher noch nicht wirklich gebraucht. Aber gerade bei den größeren ARMs kann ein Logic Analyzer schon sehr hilfreich sein, ob die Komponenten auch wirklich das machen, was man denkt. Wenn ich über den FSMC, DCMI, I2C oder ähnliches was anschließe und es nicht funktioniert, weiss ich erstmal nicht woran das liegt. Da kann es schon sehr hilfreich sein, sich den Bus mal direkt anschauen zu können. Natürlich kann man das auch durch viel Nachlesen, Ausprobieren, Fragen und Beten hinkriegen, aber mit einem LA geht das oft doch etwas schneller. Ich würde sagen ob LA oder Scope hängt sehr stark davon ab, was man macht und wie man arbeitet. Was man wirklich braucht findet man am einfachsten raus, indem man sich merkt was einem am häufigsten fehlt.
Verwirrter Anfänger schrieb: > Aber gerade bei den größeren ARMs kann ein Logic Analyzer schon sehr > hilfreich sein Wiebitte? Ich befürchte, du hast noch nie sowas programmiert. Zumeist ist es nämlich so, daß man bei nem Programmierfehler garnix an den beiteiligten Pins sieht. Da hilft dir auch der beste LA nix. Und den LA an den Systembus anzuschließen (der oftmals garnicht herausgeführt ist) ist ein Witz bei Controllern, die mal eben 30 Millionen Operationen pro Sekunde ausführen. Da ist es sehr viel besser, das User-Manual zum Chip gründlich zu studieren und das Nachdenken an die Stelle von Probieren und Gucken zu setzen. Abgesehen davon frag ich dich mal, wie du das anstellen willst bei TQFP-Gehäusen mit 0.5er Pitch oder gar im BGA. Selbst für Bastler ist die Zeit von DIL-Gehäusen ein bissel vorbei. W.S.
Vielleicht liegt hier ja ein Missverständnis vor. mit größeren ARMs mein ich die ARM Cortex-M4 Klasse, nicht ARM Cortex-A15 oder ähnliches. W.S. schrieb: > Ich befürchte, du hast noch nie sowas programmiert. Ich hab noch nicht viel gemacht mit den größeren Chips das stimmt, ich beschäftige mich erst seit ca. 2 Jahren mit den 32 Bittern von STM und NXP. Allerdings hab ich schon Displays, Cameras, externes RAM und diversen Kleinkram angeschlossen und zum laufen gebracht. W.S. schrieb: > Zumeist ist es > nämlich so, daß man bei nem Programmierfehler garnix an den beiteiligten > Pins sieht. Ausser wenn zum Beispiel der I2C Bus zwar funktioniert, aber man beim Auslesen von Daten ein STOP zuviel sendet. Oder wenn man kontrollieren will, was den von der angeschlossenenen Komponente zurückkommt, da es nicht richtig empfangen wird. Gerade als Hobbyentwickler hat man nicht unbedingt immer Zugriff auf die besten Datenblätter. W.S. schrieb: > Da ist es sehr viel besser, das User-Manual zum Chip gründlich zu > studieren und das Nachdenken an die Stelle von Probieren und Gucken zu > setzen. Hängt davon ab. Es ist zwar intellektuell befriedigender, wenn man nach einer Stunde Datenblatt-Durchlesen verstanden hat wie die verschiedenen RAM Access Modi mit den Timing Settings zusammenspielen. Aber meine Frustlevel sinken stark, wenn ich die wahrscheinlich korrekten Settings einfach schnell überprüfen kann. W.S. schrieb: > Abgesehen davon frag ich dich mal, wie du das anstellen willst bei > TQFP-Gehäusen mit 0.5er Pitch oder gar im BGA. Selbst für Bastler ist > die Zeit von DIL-Gehäusen ein bissel vorbei. Mein normaler Entwicklungsprozess sieht so aus, dass ich neue Komponenten erstmal als Prototyp ausprobiere, bevor ich ein fertiges Board in Auftrag gebe. Und dabei seh ich durchaus Möglichkeiten vor an die Signale dranzukommen. Sei es über Debug Pads, oder über Adapter. Gerade beim Prototypen mit Development Boards sind die verschiedenen Komponenten oft über 2,54mm Stecker verbunden, da kann man ideal Adapter dazwischen schieben um das Signal abzugreifen.
Verwirrter Anfänger schrieb: > Ausser wenn zum Beispiel der I2C Bus zwar funktioniert, aber man beim > Auslesen von Daten ein STOP zuviel sendet. Ein STOP zuviel wirst Du mit dem LA nicht sehen, da der Chip nicht mehr Master ist. Nur ein Master darf STOP auf den Bus legen. Du kannst also nur mit Simulator oder Debugger feststellen, daß Du es zweimal aufrufst. Der I2C ist außerdem besser mit dem 2-kanal Oszi zu beobachten. Da kann man auch sehen, welcher Teilnehmer auf low zieht, wenn man 100 Ohm Widerstände in die Leitungen legt (Low ist 0V oder bissel drüber). Damit sieht man auch gut den schweren Multimaster-Bug der ATmega. Das ist wirklich ne Qual, wenn man mit Timerinterrupt und Pinchange-Interrupt den I2C überwachen muß und dann wieder neu aufsetzen. Wir haben in der Firma einen Hameg Oszi, der auch als LA benutzt werden kann. Das geschieht aber nur sehr selten. Deshalb bin ich der Meinung, fürs Hobby lohnt sich kein LA. Für den ARM Cortex lohnt sich viel eher ein JTAG bzw. anderes serielles Debuginterface. An die internen Busse kommst Du eh nicht ran. Peter
Peter Dannegger schrieb: > Ein STOP zuviel wirst Du mit dem LA nicht sehen, da der Chip nicht mehr > Master ist. Nur ein Master darf STOP auf den Bus legen. > Du kannst also nur mit Simulator oder Debugger feststellen, daß Du es > zweimal aufrufst. Ich bin mir nicht mehr ganz sicher wie die Abfolge war, aber in dem Fall ging es darum, dass beim Auslesen von eines I2C EEPROM das Setzen der Adresse und das Auslesen der Daten als zwei getrennte Kommunikationen geschickt wurden, dadurch wurde in der Mitte ein STOP gesand, wo nur ein ACK stehen durfte. Ich erinner mich grob, dass es da in der ST Standardlibrary für I2C ein paar Probleme gab, allerdings ist das jetzt schon über ein Jahr her. Ich stimm dir voll zu, ein Debug Interface ist auf jeden Fall wichtiger als ein LA oder ein Scope, und für die meisten Fälle würde ein einfacher Bus Sniffer wahrscheinlich auch ausreichen, aber für mich persönlich war der LA das zweitnützlichste Gerät vor dem Scope. Ich könnte mir vorstellen, das wir hier auch von ganz verschiedenen Zielgruppen sprechen. Hobbyist kann alles beinhalten, den Ingenieur, der seit 40 Jahren für Siemens SPS entwickelt und in seiner Freizeit mit Elektronik rumspielt oder den Soziologiestudent, der vor 2 Jahren mit einem Arduino angefangen hat und sich nur in der Freizeit mit Elektronik beschäftigen kann. Natürlich habe diese beiden Gruppen ganz andere Anforderungen, Probleme und Möglichkeiten. Der eine Student sucht das sinnvollste Werkezug um entspannt zu entwickeln und hat ein Budget von ca. 100 EUR, der Ingenieur hat jahrelange Erfahrung und ein Budget von 500+ EUR. Sollen sich jetzt beide das gleiche Scope kaufen?
Laut Datenblatt erfolgt beim EEPROM das Umschalten auf Lesen mit einem Repeat-Start nach dem Schreiben der Adresse. Diese Methode ist aber nur bei einem Multi-Master I2C wirklich nötig, damit kein anderer Master dazwischen funkt. Ein Single-Master kann das aber auch problemlos in 2 getrennten Paketen machen. Peter
Jörg Wunsch schrieb: > Schicke Protokollauswertungen sind ein nettes Gimmick, aber die kann > man immer dadurch ersetzen, dass man die Daten exportiert und > anschließend selbst mit einer Scriptsprache oder dergleichen > anlysiert. Das hat den zusätzlichen Vorteil, dass ich mir die > Auswertung auf meine tatsächlich benutzte Hardware maßschneidern kann, > d. h. ich muss nicht (um beim obigen Beispiel zu bleiben) auf der > Ebene "SPI" stehenbleiben, sondern kann gleich auf Ebene von > Registerlese- und -schreioperationen etc. abstrahieren. Sowas kann > naturgemäß eine im LA eingebaute Analyse nicht leisten. Du meinst in der Hardware eingebaut oder in der LA PC-Software? Ich kann jetzt nur für sigrok sprechen, aber da sind die Protocol Decoder (alle in Python geschrieben) PC-seitig "stapelbar", d.h. man kommt durchaus auch mit den Decodern auf höhere Protokollebenen, z.B. haben wir derzeit u.a. - spi -> mx25lxx05d (SPI basierter NOR flash chip) - uart -> pan1321 (UART-basierter Bluetooth Chip) - i2c -> rtc8564 (I2C basierte RTC) - und diverse andere (vorhanden oder in Arbeit) Die Schachtelung geht auch beliebig tief, also auch z.B. folgendes ist denkbar: - onewire_link -> onewire_network -> maxim_ds28ea00 (1-Wire protokoll layers + chip) Langfristig sind auch ausgefallenere Setups denkbar, z.B. Ausgabe von zwei verschiedenen Decodern auf unterster Ebene in einem dritten High-Level Decoder einlesen und daraus ein weiteres "Protokoll" dekodieren. Gerade die "Non-standard" Protokolle (abseits der üblichen UART, SPI, I2C die die meisten Billig-LA Softwarepakete können) und höherlevelligen Protokolle für bestimmte Chips, Sensoren und "custom" Protokolle sind mir persönlich ein großes Anliegen, und ich verbringe einiges an Zeit damit nach und nach mehr davon in sigrok zu unterstützen. Das ist ein Feature das ich bei vielen kommerziellen LAs vermisse und eines das ich auch selbst für den eigenen Einsatz als sehr praktisch erachte. Wenn ich z.B. den MX25L1605D Traffic mitlese interessiert mich in der Tat nicht (nur) das SPI selbst, sondern v.a. die spezifischen Chip-Befehle wie RDID, SE, PP, WREN, usw. Uwe.
Uwe Hermann schrieb: > Gerade die "Non-standard" Protokolle (abseits der üblichen UART, SPI, > I2C die die meisten Billig-LA Softwarepakete können) und höherlevelligen > Protokolle für bestimmte Chips, Sensoren und "custom" Protokolle sind > mir persönlich ein großes Anliegen, und ich verbringe einiges an Zeit > damit nach und nach mehr davon in sigrok zu unterstützen. Das ehrt dich, aber trotzdem gibt es davon so viele, dass es in vielen Fällen der "Endkunde" selbst machen können (und wollen) muss, damit das Sinn hat. Ja, im Prinzip meine ich derartige Dinge. Auf welcher Hardware die un konkret ablaufen (dedizierter Computer für den Analyser oder Host-PC), ist dabei eher nebensächlich.
Jörg Wunsch schrieb: > Auf welcher Hardware die > un konkret ablaufen (dedizierter Computer für den Analyser oder > Host-PC), ist dabei eher nebensächlich. Wenn du die Daten erst nachträglich auswertest, musst du eben alles speichern, das kann schnell alle Grenzen überschreiten. Der Trick am LA ist eben keineswegs so viel wie möglich aufzuzeichnen, sondern mit möglichst genauer Triggerdefinition so wenig wie möglich. Deswegen bringt es auch nichts, z.B. einen Glitch, der bloss einmal pro Stunde auftritt, in einem 100 MHz-System mit dem Oszi zu suchen. Den kann man bloss finden mit einem Gerät, dass auf den Glitch selbst reagieren kann - was zugebenermassen ein anspruchsvolle Aufgabe ist, aber im wesentlichen alternativlos wie das heute so schön heisst. Gruss Reinhard
Jörg Wunsch schrieb: > Uwe Hermann schrieb: >> Gerade die "Non-standard" Protokolle (abseits der üblichen UART, SPI, >> I2C die die meisten Billig-LA Softwarepakete können) und höherlevelligen >> Protokolle für bestimmte Chips, Sensoren und "custom" Protokolle sind >> mir persönlich ein großes Anliegen, und ich verbringe einiges an Zeit >> damit nach und nach mehr davon in sigrok zu unterstützen. > > Das ehrt dich, aber trotzdem gibt es davon so viele, dass es in vielen > Fällen der "Endkunde" selbst machen können (und wollen) muss, damit > das Sinn hat. Das ist schon richtig, es gibt natürlich beliebig viele von diesen Protokollen. Das einzige was wir hier machen (können) auf sigrok Seite ist 1. Die Protokoll-Dekoder in einer weit verbreiteten Skriptsprache (Python) zu implementieren (statt C/C++ oder selbstgebastelten Mini-Skriptsprachen). Das führt dazu, dass die Dekoder relativ einfach zu schreiben und zu verstehen sind, und man kann einige nette Python Libs benutzten, und viele nette eingebaute Python-Features (Listen, Tupel, Dicts, uvm). Das alles in C/C++ zu schreiben wäre um einiges aufwändiger und schlechter lesbar am Schluss. 2. Auf neue Protokolldekoder von Usern hoffen, wie bei jedem Open-Source Projekt (was durch Punkt 1 hoffentlich erleichtert und gefördert wird). Uwe.
Reinhard Kern schrieb: > Wenn du die Daten erst nachträglich auswertest, musst du eben alles > speichern, das kann schnell alle Grenzen überschreiten. Im Zeitalter von Terabyte-Festplatten ist das auf dem Host ja kein Problem. > Der Trick am LA > ist eben keineswegs so viel wie möglich aufzuzeichnen, sondern mit > möglichst genauer Triggerdefinition so wenig wie möglich. Naja, s. o. Wenn mein LA genügend Speichertiefe hat, dann kann ich mit der Triggerbedingung auch lax werden. Schließlich kostet es auch Aufwand, diese zu formulieren. Gut, was natürlich ein Vorteil einer Protokollanalyse auf dem LA selbst (statt auf einem Host) ist ist, dass man die Triggerbedingung auf höherer Protokollebene formulieren kann.
>Oszilloskop oder ein Billigheimer mit ordentlicher Speichertiefe ist >hier wohl angebrachter. Wichtig wäre allerdings einer mit einer >ordentlichen Protokollauswertung. Was soll das sein: ordentliche Protokollauswertung? Wenn ich bei I2C neun Bits sehe und das Letzte ist auf High-Pegel muss ich schon selber wissen, dass das ein NACK ist. Wenn's mir jemand sagen muss, dann hilft mir das auch nichts, weil ich dann nämlich keine Ahnung hab, von dem was ich grade programmiere.
> Was soll das sein: ordentliche Protokollauswertung?
Bei meinem HMO2022 sind das z.b die uebersichtliche Darstellung und die
Verwendung verschiedener Farben. Da kuckst du nur einmal drauf und
weisst nach 1s wo du nochmal naeher drueber nachdenken solltest.
Olaf
>Bei meinem HMO2022 sind das z.b die uebersichtliche Darstellung und die >Verwendung verschiedener Farben. Das sollte selbstverständlich sein. 8 Kanäle in eiem Diagramm übereinander und dunkelgraue Signale auf schwarzem Hintergrund wird keine Software liefern.
Knut schrieb: > 8 Kanäle in eiem Diagramm > übereinander und dunkelgraue Signale auf schwarzem Hintergrund wird > keine Software liefern. Sei Dir da mal nicht so sicher: http://www.saleae.com/Resources/Images/Logic/LogicSoftware_03.jpg
Thread beobachten
Seitenaufteilung abschalten
Bitte 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.