Hallo Michael, ich habe den LA auch nachgebaut, allerdings mit etwas geänderter HW: - ATmega48 @20MHz - RAM Takt 50MHz - 32Kb Cache RAM, 17ns (ja so was gibt's auch !) - alle Logik in einem Xilinx XC9572 PC44 CPLD - MAX232 mit 38400 Baud (bei mehr ist die Kommunikation nicht stabil) Läuft auch soweit schon, nur wird bei 50MHz nur etwa das letzte Viertel des RAMs beschrieben, der Reset ist 0xFF. Die angezeigten Daten in besagtem letzen Viertel sind plausibel und das RAM ist ja auch schnell genug. Bei 20MHz funktioniert alles ohne Probleme. Es scheint mir, als ob der Atmega das Sampling zu früh beendet. 1.) Kann ich für oben genannte Kombination die vorhandenen Tabellen in avrstudio_minilog28.zip (akutelle Version auf Deiner Website) verwenden oder sind Anpassungen notwendig ? 2.) Wie sind die Tabellen aufgebaut ? - Timer-Reload-Wert zur Erzeugung von Frequenzen kleiner 20MHz - Rest-RAM Größe ? - Wartezeit ? Was haben die beiden letzten Werte für eine Bedeutung ? Wie hängen diese Werte mit der Frequenz und der Speichergröße zusammen? Gruß Bernd
Bernd Geyer schrieb: > Hallo Michael, > > ich habe den LA auch nachgebaut, allerdings mit etwas geänderter HW: > > - ATmega48 @20MHz > - RAM Takt 50MHz > - 32Kb Cache RAM, 17ns (ja so was gibt's auch !) > - alle Logik in einem Xilinx XC9572 PC44 CPLD Kannst du evtl. das CPLD-Design zur Verfügung stellen? Viele Grüße, Alex
Hallo, Bernd Geyer schrieb: > ich habe den LA auch nachgebaut, allerdings mit etwas geänderter HW: > > - ATmega48 @20MHz > - RAM Takt 50MHz > - 32Kb Cache RAM, 17ns (ja so was gibt's auch !) > - alle Logik in einem Xilinx XC9572 PC44 CPLD > - MAX232 mit 38400 Baud (bei mehr ist die Kommunikation nicht stabil) ok, da sollte es keine unlösbaren Probleme geben. Ein MAX, der keine 115200 stabil macht? Ist zumindest mir noch nicht passiert... > Läuft auch soweit schon, nur wird bei 50MHz nur etwa das letzte Viertel > des RAMs beschrieben, der Reset ist 0xFF. Die angezeigten Daten in > besagtem letzen Viertel sind plausibel und das RAM ist ja auch schnell > genug. Bei 20MHz funktioniert alles ohne Probleme. Deute darauf hin das, der Adresszähler irgendwelche Probleme hat und die oberen Stufen nicht mitzählern. War zumindest bei den 74ACT161 dann das gleiche Fehlerbild. > Es scheint mir, als ob der Atmega das Sampling zu früh beendet. Glaube ich weniger, das wäre schon aufgefallen. Der AVR macht die schnellen Raten nur mit einer (taktgenauen) Warteschleife, nachdem Trigger erkannt wurde bzw. ab sofort, wenn kein Trigger gesetzt ist. Der Pre-Samplewert legt ja nur fest, wie lange nach Start bzw. Triggerbedingung gewartet wird. Bei kein Trigger und 0% Pretrigger dauert die Zeit also immer solange, wie zum samplen bei 50MHz gebraucht wird, maximal kann es ein paar Sample Fehler geben, weil die Auflösung des AVr ja kleiner ist ist als die 20 oder 50MHz Sampletakt. > > 1.) Kann ich für oben genannte Kombination die vorhandenen Tabellen in > avrstudio_minilog28.zip (akutelle Version auf Deiner Website) verwenden > oder sind Anpassungen notwendig ? 50MHz bei 20MHz AVR-Takt ist meine ursprüngliche Version und die stimmte (mit an Sicherheit grenzender Wahrscheinlichkeit ;-)), das hätte sonst schon bemerkt. > 2.) Wie sind die Tabellen aufgebaut ? > - Timer-Reload-Wert zur Erzeugung von Frequenzen kleiner 20MHz > - Rest-RAM Größe ? > - Wartezeit ? Die Tabelle in definitionen mit den Taktwerten .equ CLK_20M = 0 ; -> 100ns .equ CLK_10M = 0 ; -> 100ns .equ CLK_5M = 1 ; -> 200ns sind direkt die Werte für den Counter des AVR, um im CTC-Mode den Takt zu erzeugen. Bei 20 und 50MHz werden die ignoriert. In der Tabelle werden gesetzt: .dw CLK_20M ; 1 20MHz -> 50ns .dw BUF_LEN_MAX / 10 ; Rest-Zähler für vollen Bereich .dw 1 ; Warteschleife, 20 Takte, -> 1MHz 1. Der Takt für den CTC-Mode > Was haben die beiden letzten Werte für eine Bedeutung ? > Wie hängen diese Werte mit der Frequenz und der Speichergröße zusammen? 2. Die "virtuelle" Anzahl Bytes, die in den Speicher passen. Virtuell deshalb, weil ein Durchlauf der AVR-Schleife für die Zählung 10 Takte benötigt, das sind 2MHz für die Zählroutine im AVR. Bei 20MHz externem Clock und 32768 Byte Ram ist der also nach 32768/10 (20MHz(ext)/2MHz(AVR) komplett voll. Ab da, wo der AVR es schafft, schnell genug mitzuzählen (also 2MHz und langsamer) gibt es keine Korrektur mehr. Der 3. Wert ist die Warteschleife zwischen 2 Samples bei kleineren vom AVR erzeugten Sampleraten. Ich zähle nicht die CTC-Takte, sondern warte einfach Taktgenau, ist ja syncron zueinander und ich brauchte nicht 2 Varianten für schnelle und langsame Sampleraten. Kontrolliere mal vorsichtshalber, ob die MUX_Tabelle .equ MUX_INT = 0b00000000 .equ MUX_20MHZ = 0b00000100 .equ MUX_50MHZ = 0b00001000 .equ MUX_EXT = 0b00001100 zu Deiner Beschaltung passt, ich hatte da so oft bei mir umgebaut, das ich da immer im Zweifel bin..... Wenn Du was da hast, kannst Du auch messen, wie lange die Samplefreigabe bzw. das Enable des Eingangsbuffers aktiv sind. Das muß zeitlich zu 50MHz und Ramgröße passen. Eigentlich sollte ja längst noch ein Update der Homepage passieren, allerdings ist meine Zeit etwas knapp und außerdem hat mein Bekannter seine Version inzwischen zusammengelötet (Mega88, 32k Ram, bis 80MHz Takt) und prompt noch ein paar Fehler gefunden, die ich in die Software beim Ändern eingebaut habe... Das muß ich erstmal korrigieren un dmit ihm testen. Das betrifft aber NICHT die Version von der Webseite, die läuft bei mir ohne bekannte Fehler mit diesen Tabellen bei 50MHz und 20MHz AVR-Takt. Gruß aus Berlin Michael
Hallo Michael, danke für die Erläuterung der Tabellenwerte und den Tipp mit dem Multiplexer! Das war's natürlich, die Select-Eingänge paßten nicht zu der vom ATmega gewünschten Sample-Frequenz! Da hätte ich auch selbst draufkommen können :-( Ein Timingproblem der Adressleitungen kann ich ausschließen, das CPLD ist schnell genug. Jetzt muß ich mir nur noch ein entsprechendes Cache-RAM besorgen und die 80MHz sind geknackt ;-) Zum Thema MAX232: Der hängt über einen RS232-USB Wandler am USB1.1 meines Notebooks. Ich habe zwei unterschiedliche Varianten von verschiedenen Herstellern, der eine rennt noch nicht mal mit 38400 Baud sauber, der andere macht nur bei höheren Baudraten Probleme und 'verschluckt' gerne die ersten oder letzten Zeichen der Übertragung. Wie dem auch sei, mein Nachbau funktioniert nun soweit und das reicht mir (erst einmal). Gruß und Danke Bernd
Hallo! Würde auch gerne eine "aktuelle Version" des LA nachbauen. Dabei interessiert mich vor allem die Version mit CPLD. Kann evtl. jemand mal eine kurze Stückliste nennen? Welchen CPLD sollte man idealerweise kaufen wenn man ihn eh nicht in der Grabbelkiste hat? Wie bekommt man den CPLD programmiert? Welche Latches? HCT, ACT? Hat jemand mal überlegt anstelle der 486/586 Cache-RAMs RAMs aus einem Pentium II Slot1-Modul zu nehmen? Die sind mit 4,4ns - 7ns nochmal schneller (und evtl. größer). Vielen Dank! Gruß Robert
Hallo Robert, meine Stückliste sieht z.Zt. so aus: - 80MHz Oszi - ATMega48 @ 20MHz (eigenes Quarz) - Cache-RAM 32k*8 (leider z.Zt. nur 17ns) - 74HC245 als Eingansbuffer - z.Zt. noch MAX232 als RS232 Treiber XC9572XL-10 CPLD (ja ich weiß, ist nur ein 3,3V Typ aber mit 5V tolleranten I/Os) Kostet z.B. beim großen R im plcc44 Gehäuse 3,40EUR. Die 3,3V sind unkritisch und man kann sie von den 5V mit 2 in Reihe geschalteten 1N4148 'erzeugen'. (Für die Kritiker: Nicht die feine englische Art, funktioniert aber! Ich hatte halt keinen 3,3V LDO Regler da. Und laut Datenblatt verkraftet das CPLD bis zu 4V absolutes max) Das CPLD ist zu ca. 60% belegt. Ich bin gerade dabei, die Trigger-Logik zu erweitern (Externer Trigger konfigurierbar auf High/Low Pegel, ect.) Außerdem spiele ich mit dem Gedanken, das Ganze auf 16 Kanäle zu erweitern (was 2 weitere 74hc245 + Cache-Ram bedeuten würde). Leider gehen mir die freien Pins am CPLD aus. Zum Programmieren des CPLDs bietet sich die freie Webpack-SW von Xilinx an. Ein Programmieradapter ist auch nicht aufwendig zu bauen (such' mal nach xilinx jtag cable) Natürlich kann man auch CPLDs von anderen Herstellern nehmen, man sollte aber vorher ausprobieren (mit der Entwicklungssoftware des Herstellers) ob alles reingeht. Cache RAMs aus 'neueren' Rechnern sind meistens SMD bzw. 16 oder 32 Bit breit. Aber prinzipiell kann man die schon nehmen. Das bedeutet natürlich auch einen breiteren Daten/Adressbus, wofür man wieder mehr Pins am CPLD benötigt. Wenn meine Umbauten und Erweiterungen fertig sind, kann ich hier ja mal Schaltplan/VHDL/µC-Software posten. Gruß Bernd
Hallo! Um mal die Idee des Pentium 2 Cache zu beleben: Habe heute einen Slot1 Pentium geopfert und ihm beide Cache-Chips per Heißluft entrissen. Die Bezeichnung lautet TC55V2377AFF-250. Leider finde ich nur das Datenblatt für den TC55V2325FF-100. Dieser hat 64k words x 32 bits und scheint auch Pinout-mäßig mit dem im Slot1-Modul verbauten Chip zu 99% identisch zu sein. Die Kapazität passt auch, der Pentium II ist mit 2 Cache-Chips mit 512 KB angegeben. Wenn das Bezeichnungsschema stimmt sollte der Speicher mit bis zu 250 MHz laufen. Zudem ist ein interner Burstmode verfügbar der die letzten 2 Bits inkrementieren kann. Gruß Robert
Bernd Geyer schrieb: > Wenn meine Umbauten und Erweiterungen fertig sind, kann ich hier ja mal > Schaltplan/VHDL/µC-Software posten. > das wäre nett :) Habe noch paar XC9572XL-5 die "benutzt werden möchten".
@Michael U, sind die Verbesserungen jetzt Online auf deiner HP verfügbar?
Hallo, wie angekündigt stelle ich hier meine Modifikationen bzw. den Umbau der Schaltung (80MHz Variante) auf ein XILINX XC9572 CPLD zur Verfügung. Die Zip-Datei enthält die (geänderten) Sorucen für's CPLD und den µC, Schaltplan und ein Readme. Die Original-PC-Software von Michael unterstützt die neuen Featrues leider (noch) nicht. Trotzdem kann man die PC-Soft mit der modifizierten HW benutzen (eben halt nicht alle Features). Der Schaltplan und die µC-Software sind schon auf 16 Kanäle vorbereitet, ich werde in den nächsten Tagen den Schaltplan für das Aufsteckboard (Erweiterung auf 16 Kanäle) hier bereitstellen. @Michael: Könntest Du mir Deine PC-Sourcen per PM schicken. Ich würde dann die notwendigen Erweiterungen einbauen. Gruß Bernd
Bernd, würdest Du ggf. die original Eagle Daten zur Verfügung stellen? Vielen Dank! Gruß Thomas
Hallo, anbei die Eagle-Dateien und der Schaltplan für die 16-Kanal-Erweiterung. Bisher gibt's noch keine SW-Unterstützung für die 16 Kanäle. Gruß Bernd
Bernd, vielleicht könntest du anstatt minila z.b. microla, superla, was auch immer, "minila" ist ein bekanntes LA, so ist namenswahl vielleicht etwas verwirrend. gruss Thomas
Hallo, Ich interessiere mich auch für einen Nachbau. Hat jemand schon ein Print in Auftrag gegeben und könnte ich mich da anschliessen? Gruss, Tefi
Hallo zusammen, hat jemand die 50MHz-Version mit 28-poligem AVR aufgebaut und den externem Takteingang zum laufen bekommen? Ich kann den externen Clock in der PC-Software gar nicht auswählen, obwohl er ja in der AVR-Firmware und im Schaltplan vorgesehen ist. Und Michael ist per Mail dummerweise nicht erreichbar :-( mfg Harri
Hallo, sorry das ich so schweigsam war, bin zur Zeit ein wenig mit Krankheit gestraft (nein, keine Schwein... ;-)). Ich schicke morgen die VB-Sourcen rau7s an die, die angefragt hatten. Außerdem baue ich den Extern-Clock schnell mal ein, der ist z.Z. einfach nicht da... Gruß aus Berlin Michael
Hi Michael, danke für's einbauen und gute Besserung. mfg Harri
Angehängte Dateien:
-
DSC05062s.jpg
360 KB
Hi Michael, Hi Michael, (Sorry in English) I have built your Minilog40 design. I made the following change to your design to save space: - I implemented the 7474 and 74161's in an FPGA (EPM7064) - added an extra 74161 (in the FPGA), to extent the RAM addressing range to 15 bits. (32kb) - change the SRAM to an 32kx8 type. - some changes in the firmware to make it all work. The USB-RS232 pcb at the right side of the PCB and the 20Mhz Xtal is underneath it. I would like to receive a copy of the VB source. I want to make a full english version and maybe add some enhancements which I will share with you. Many thanks ! Henk Netherlands
Angehängte Dateien:
-
ethernet.png
16 KB
To Henk: Yay, another protoboard artist. I'm really curious about the wiring... May we see a picture of the dark side as well? To everyone (translation below): I spend some thoughts on interleaving: The only way I see so far is using a second address counter running with the inverted clock. Does anyone see a more elegant way to achieve the phase shifted recording? Btw, I've really enjoyed using my analyzer since I built it half a year ago. Super convenient for reverse engineering USB devices to use them with free software. I've yet to come across a signal it doesn't digest nicely. E.g., attached is an ethernet frame on a 10Base2 wire (-2.5Vpeak), hooked up using nothing but a 100nF capacitor in front of the 74HCT541. I highly recomment building one if you haven't already. In german: Ich hab' mir ein paar Gedanken zum Interleaving gemacht: Die einzige Möglichkeit, die ich derzeit sehe, ist, einen zweiten Adresszähler mit invertiertem Takt zu betreiben. Sieht jemand vielleicht einen eleganteren Weg, die phasenverschobene Aufnahme zu erreichen? Nebenbei: Mein Analyzer hat sich im letzten halben Jahr als sehr nützlich erwiesen. Sehr praktisch zum reverse-engineeren von USB-Geräten zur Verwendung mit freier Software. Ich hab' bisher noch kein Signal gefunden, dass er nicht korrekt verarbeiten konnte. Im Anhang ist z.B. ein Ethernet-Frame von einer 10Base2-Leitung (-2.5Vspitze), einzig durch einen 100nF-Kondensator vom 74HCT541 getrennt. Ich kann den Nachbau nur empfehlen.
Angehängte Dateien:
-
interleaving.png
22 KB
Auf eine elegantere Lösung zum Interleaving bin ich noch gekommen: Man speichert die Adresse in zwei Latches zwischen (Anhang). Vielleicht lohnt es hier auch, die Datenbusse passend zu entkoppeln, um z.B. flexibel 8 Kanale @ 160MS/s und 16 Kanäle @ 80MS/s mit der gleichen Hardware zu unterstützen.
ansel schrieb: > Ich hab' mir ein paar Gedanken zum Interleaving gemacht: Die einzige > Möglichkeit, die ich derzeit sehe, ist, einen zweiten Adresszähler mit > invertiertem Takt zu betreiben. Sieht jemand vielleicht einen > eleganteren Weg, die phasenverschobene Aufnahme zu erreichen? Da zumindest mit den von mir benutzten Rams die Laufzeiten der Zähler schon an der Grenze sind und die Zykluszeit der Rams schon etwas außerhalb des Datenblattes, dürfte es die einzige Mglöichkeit sein. Die Idee ist reizvoll, der Mehraufwand von 1x Ram + 4x 74ACR161 würde das Teil auf 160 MHz Samplerate bringen... Hmmmm... Gruß aus Berlin Michael
Angehängte Dateien:
-
PCB_under.jpg
620 KB
Hi Ansel, See attached jpg. I use a sort of transformer wire. The isolation melts away at 300+ C while soldering. I works perfect and the result is nice. Regards Henk
snhstq writes: > I use a sort of transformer wire. > The isolation melts away at 300+ C while soldering. Elm-Chan is my idol as well[1], although I have to admit that your soldering job looks much better than mine[2]. Luckily, I can blame it on the lead-free solder :-). Michael U. writes: > Die Idee ist reizvoll, der Mehraufwand von 1x Ram + 4x 74ACR161 > würde das Teil auf 160 MHz Samplerate bringen... Hmmmm... Weitere Vorteile: - Selbst mit den "langsamen" 20ns-SRAMs sind 100 MS/s drin. - Verdopplung der Sampleanzahl pro Kanal. Probleme: - 16-Kanal ist über USB-Stromversorgung (2,5 Watt) nicht mehr machbar (1 Watt pro chip)[3] Noch eine Idee zur Implementierung: Die SRAMs sollte man über CS statt WE takten. Laut allen mir vorliegenden Datenblättern wird das unterstützt. Das hat dann folgende Vorteile: - Man benötigt keine externe NANDs mehr; es werden quasi die internen zwischen CS und WE/OE verwendet. Bei ausschließlich externem Trigger ist somit kein 7400 mehr erforderlich. - Für's Auslesen ist keine zusätzliche Steuerung nötig. Ich hätte leider frühestens ab April Zeit, mich an einem Prototypen zu versuchen. Würde ja zu gerne jetzt schon die Performancekrone an mich reissen :-). Gruß Andreas Footnotes: [1] http://elm-chan.org/docs/wire/wiring_e.html [2] http://www.mikrocontroller.net/attachment/56584/hcanalyzer.jpg [3] Ich muss zugeben, dass ich die 16 Kanaele meines Analyzers bisher nur zweimal benutzt habe: An einer HP-IB-Schnittstelle, und an meinem HM-205-3 (beidemale 8 Datenleitungen + Steuerleitungen). Aber auch bei seriellen Bussen sind die beiden Kanaele nuetzlich: Man kann sie mit unterschiedlichen Eingangstreibern bestücken (z.B. ACT und AC). Bei 8 Kanälen werde ich wohl einen der Pollin-Textool-Sockel dafür verbauen.
Hallo, ansel schrieb: > Probleme: > > - 16-Kanal ist über USB-Stromversorgung (2,5 Watt) nicht mehr > machbar (1 Watt pro chip)[3] Muß ich mal messen, ich habe 140mA in Erinnerung bei den 32kx8. > Noch eine Idee zur Implementierung: Die SRAMs sollte man über CS > statt WE takten. Laut allen mir vorliegenden Datenblättern wird das > unterstützt. Das hat dann folgende Vorteile: Nach meinen Datenblättern ist die Zugriffszeit über /CE fast doppelt so hoch wie über /WE, auch da muß ich genauer schauen. > - Man benötigt keine externe NANDs mehr; es werden quasi die > internen zwischen CS und WE/OE verwendet. Bei ausschließlich > externem Trigger ist somit kein 7400 mehr erforderlich. > - Für's Auslesen ist keine zusätzliche Steuerung nötig. Die würde mich am wenigsten stören. Das ist außer etwas höherer Last durch zusätzliche Bustreiber vom Timing her unkritisch. Der AVR kann da so langsam lesen, wie nötig. > Ich hätte leider frühestens ab April Zeit, mich an einem Prototypen > zu versuchen. Würde ja zu gerne jetzt schon die Performancekrone an > mich reissen :-). Naja, ich muß mir das mal ganz langsam auf der Zunge zergehen lassen und meine Bestände prüfen und passend ergänzen.... Gruß aus Berlin Michael
Michael U. schrieb: > Nach meinen Datenblättern ist die Zugriffszeit über /CE fast doppelt so > hoch wie über /WE, auch da muß ich genauer schauen. Hmm, das wäre natürlich tödlich... Ich hab' meine Datenblätter nochmal durchforstet, und da gibt es tatsächlich teilweise unterschiedliche Zeiten, die mir nicht aufgefallen sind. Interessanterweise ist auch ein Chip dabei, bei dem der CE-Puls kürzer als der WE-Puls sein darf. (hab' auch mal den Stromverbrauch abgetippt): | | CE pw [ns] | WE pw [ns] | I [mA] | |-----------------+------------+------------+--------| | mos 62256-20 | 15 | 12 | 200 | | mos 62256-15 | 10 | 12 | 200 | | asi mt5c2568-12 | 10 | 10 | 190 | | asi mt5c2568-15 | 12 | 12 | 180 | | asi mt5c2568-20 | 15 | 15 | 170 | | et 51256c-10 | 10 | 10 | 195 | | et 51256c-12 | 9 | 8 | 195 | | et 51256c-15 | 10 | 10 | 150 | Stromverbrauch jeweils bei f=MAX und "Outputs Open"
Hallo euch allen, ich finde das Projekt total klasse. Könnt Ihr mir sagen wo ich die neusten Unterlagen, wie Source, Software und Schaltplan finde? Kann ich mit dem Logic-Analyzer auch die Daten erkenn die auf einer Leitung versendet wurden? Natürlich muss ich das Signalformat Kennzeichnen. Danke Martin
Martin schrieb: > Könnt Ihr mir sagen wo ich die neusten Unterlagen, > wie Source, Software und Schaltplan finde? Das hängt davon ab, wie du "neusten" definierst: Wenn du ohne CPLD auskommen willst, ist wohl auf Michaels Homepage die umfangreichste Dokumentation. Andererseits wurden im Thread einige zip-Dateien gepostet, die komplette Lösungen mit CPLD enthalten. > Kann ich mit dem Logic-Analyzer auch die Daten erkenn die auf einer > Leitung versendet wurden? Natürlich muss ich das Signalformat > Kennzeichnen. Meinst du damit die Analyse von Protokollen durch die Software? Ist meines Wissens noch nicht implementiert, aber mit grundlegenden Programmierkenntnissen solle man das bei Bedarf leicht nachrüsten können...
Angehängte Dateien:
-
anal.png
8,1 KB
Anbei noch eine Idee zur Erzeugung der Adressen für Interleaving. Man verwendet linear rückgekoppelte Schieberegister[1], um eine Folge mit
Adressen zu erzeugen. Vorteil: Nur fünf dil-14 ICs. Nachteil: Man ist mit der Hardware auf 32k-SRAMs angewiesen. Zur Verwendung mit z.B. 8kB-SRAMs wäre eine andere Rückkopplung nötig. Footnotes: [1] http://en.wikipedia.org/wiki/LFSR
Angehängte Dateien:
-
160.png
21 KB -
bench.jpg
160 KB -
wiring.jpg
150 KB
Nach der ganzen Interleaving-Designarbeit konnte ich dem Fädelstift in der Schreibzeugtasse nicht länger widerstehen :-). Leistungsdaten: - stabile 160 MS/s bei 4.4V aus dem USB - 64k Samples pro Kanal - 8 Kanäle - ausschließlich externe Triggerung - Software-USB Anbei der obligatorische 74hc4040-Test. Diesmal sind Dank der Sampledauer im einstelligen Nanosekundenbereich sogar alle propagation delays zu sehen. Die Schaltung entspricht fast exakt meinen letzten Posts. Das zweite XOR zum Initialisieren des Adressgenerators hab' ich verschoben, um propagation delays zu minimieren. Damit sollte man dann Adressen mit der Maximalfrequenz der Schieberegister erzeugen können, und auch mit einem reinrassigen 74HC-Aufbau und "lahmen" 20ns SRAMs ansehnliche 100MS/s hinbekommen. Die Steuerung der SRAMs via Chip-Select funktioniert hier einwandfrei. Vor eventuellem Nachbauen der CS-Steuerung bitte auf alle Fälle in's Datenblatt der vorhandenen SRAM-Chips schauen; es scheint da bei manchen Chips Performanceunterschiede gegenüber der Steuerung via WE zu geben... Ich hab' diesmal etwas disziplinierter dokumentiert. Einige offensichtliche Details fehlen jedoch noch im angehängten Plan (Spannungsversorgung, USB-Beschaltung). Ich hab' wieder Software-USB verwendet, womit die Hardware wieder inkompatibel mit Michaels Software ist. Falls jemand einzelne Aspekte des Designs übernehmen will, hier noch ein paar firmwaretechnische Hinweise: - Das Interleaving ist einfach zu erschlagen: Man liest einfach nach jeder Flanke den Bus, statt nach jeder zweiten. - Der Schieberegister-Adressgenerator muss aus dem Nullzustand gebracht werden. Dazu klingelt der AVR einmalig über das zweite XOR eine eins rein. Danach erzeugen die Schieberegister durch die Rückkopplung zyklisch eine Folge von 32767 Adressen (alle ausser der Null).
@ansel : Könntest du den Schaltplan grösser einstellen man sieht kaum was. Klasse Arbeit!!
AVRnix schrieb: > Könntest du den Schaltplan grösser einstellen man sieht kaum > was. PDF abspeichern und reinzoomen. Das geht beim PNG natuerlich schief.
Hallo zusammen, ich hab mir auch mal ein paar Gedanken zu einer Lösung mit Interleave gemacht. Das ganze setzt einen CPLD mit 40-50 IOs und genug Makrozellen voraus. Der 44-polige M4A5 auf meinem jetzigen LA reicht schonmal nicht aus. Separat aufgebaut dürften es recht viele ICs werden. Das ganze ist noch nicht in Hardware gegossen und als Anregung zu sehen. Ziel wäre die beiden RAMs für Interleave mit 8 Kanälen und doppelter Abtastrate zunutzen und alternativ (per Software wählbar) auch 16 Kanäle bei einfacher Rate zu haben. Wenn man schon zwei RAMs verbaut hat, dann sollte man sie auch beliebig nutzen können. Datenbus 0 mit Bit 0-7 hängt am AVR, am RAM0 und dem CPLD. Datenbus 1 mit Bit 8-15 hängt am RAM1 und CPLD. Es gibt nur einen gemeinsamen Adressbus für beide RAMs. Die Cache-RAMs speichern mit der steigenden WE-Fanke, weder für Adressen noch für Daten ist eine hold-Time nötig, nur die setup-Times sind einzuhalten. Speicherbetrieb mit 16 Kanälen, einfacher Takt: - CPLD gibt das gleiche WE-Signal an beide RAMs - Trigger kann für alle 16Bit genutzt werden, es liegen eh alle Signale am CPLD an und ob der 8 oder 16 Bit vergleicht ist wurscht Speicherbetrieb mit 8 Kanälen, doppeltem Takt: - nur Datenbus 0 ist aktiv, der Eingangspuffer von Bus 1 ist abgeschaltet. Dazu wird das Signal IN_SELECT durch den CPLD geführt, statt direkt vom AVR zum Eingangspuffer. - Trigger ist nur für Bus0 aktiv - CPLD gibt das wieder gleiche WE-Signal an beide RAMs - CPLD latcht die Daten vom Bus0 mit der fallenden Flanke und gibt sie auf Bus1 aus. Das Timing sollte kontrollierbar sein, da alles innerhalb des CPLD abläuft. Auf diese Weise liegt das Signal, welches während der fallenden Taktflanke am Eingang lag während der steigenden Flanke immer noch am RAM1 an und wird darin gespeichert. Das Auslesen kann auf verschiedenen Wegen ablaufen: - Option 1: CPLD zählt die Adresse nur bei jedem zweiten Impuls hoch, erst wird D0-7 vom AVR direkt gelesen, danach verbindet der CPLD als Puffer die beiden Datenbusse und der AVR liest RAM1 aus. - Option 2: CPLD zählt die Adresse bei jedem Impuls hoch, nachdem RAM0 komplett gelesen wurde, verbindet er die Datenbusse und das RAM1 wird auch in einem Rutsch ausgelesen. Die Umschaltung zwischen den beiden Modi erfolgt über ein config-Byte, welches als drittes Schieberegister im CPLD sitzt. Auf diese Weise sind am AVR nur zwei Pins nötig um die 16 Bit Triggermaske und das Config-Byte in den CPLD zu laden. Der Grundgedanke ist also gar keinen zweiten Adressbus zu haben, sondern nur die 8 Bit Daten so lange zu speichern, bis sie von beiden RAMs gemeinsam gespeichert werden können. So, und jetzt sagt mir bitte wo ich den Denkfehler drin habe. Das ganze hört sich irgendwie zu einfach an ;-) mfg Harri
Harri schrieb: > Der Grundgedanke ist also gar keinen zweiten Adressbus zu haben, sondern > nur die 8 Bit Daten so lange zu speichern, bis sie von beiden RAMs > gemeinsam gespeichert werden können. > > So, und jetzt sagt mir bitte wo ich den Denkfehler drin habe. Das ganze > hört sich irgendwie zu einfach an ;-) Ich hatte da bei der 74xx-Lösung Angst, daß ich mir durch Samplen nur einer Periodenhälfte per Latch Asymmetrien einfange. Bei symmetrischem Aufbau durch mehrere Latches braucht man dann wieder mehr Platz als die 2*14 Pins, die der zweite Adressbus bei Verwendung von LFSRs kostet. Im CPLD sieht die Welt vielleicht anders aus, und das Problem stellt sich nicht (konfigurierbare timings), oder man kann es mit vertretbarem Aufwand lösen (Extralatches passen noch rein).
Angehängte Dateien:
-
TOP_LAYER.png
58 KB -
BOTTOM_LAYER.png
37 KB -
Bestueckung.png
32 KB
Hallo erstmal... ich habe mir den Logik Analyzer schon eine Weile angesehen aber nie nachgebaut, weil ich irgendwie um das Routing rumkommen wollte und auf einen Lochrasteraufbau .. naja.. keine Lust hatte. Das sieht immer so "bastelmässig" aus. Nachdem ich jetzt aber den wohl (für mich) am schwersten zu beschaffenden Baustein, den SRAM, von einer Platine gekratzt (nein ... ausgelötet) habe und in den Schaltplan integriert, habe ich für den Minilog mal ein Routing erstellt. Die Platine habe ich passend gemacht für ein altes 4-Kanal-Video-Telemetrie-Gehäuse (5x BNC und diverse andere Anschlüsse). Die Bauteile habe ich so ausgemessen, dass es exakt in das Gehäuse passt und ich keine Frontplatten ausschneiden muss :)) Achja: Als SRAM habe ich "nur" eine SMD Variante gefunden, einen Alliance AS7C256-15C. Ich hoffe, dass der Baustein auch geht. Leider bin ich noch nicht dazu gekommen, die Platine 2-seitig zu erstellen, da beim Versuch eine doppelschichtige Pollin-Schrott-Platine durch den Laminator zu quetschen dieser sein Silikon verlieren wollte :( Nunja, als erstes bastel ich einen verstellbaren "Laminatorumbau". Wer sich aber das Routing schon ansehen möchte und ggf. korrigieren, kann dies gern tun. Der ISP-Connector ist gleichzeitig mit auf den DB15-Stecker geführt, weil das Gehäuse den passenden Ausschnitt dafür hat. Auch eine 3er-LED habe ich von der Originalplatine ausgelötet und auf +5V gelegt (mit Widerstand), muss aber nicht sein. Die SMD-Komponenten sind gespiegelt, so dass man sie auf die Platinenunterseite löten kann ohne Adapterplatine für DIP zu basteln. Hmm... achja.. VIAs gibts keine, dafür müssen manche der IC's teilweise auf beiden Platinenseiten verlötet werden. Hoffe, das Projekt ist noch einigermaßen aktuell. Wenn das Ganze so funktioniert wie ich möchte, würde ich es ggf. mal für eine kleinere Platine routen, so dass man auch ein "gängiges" Gehäuse benutzen kann. Grüße, Andreas
hallo Ansel würdest Du deine AVR Firmware hier einstellen? Wie muss ich mir die visualisierung am PC vorstellen? Geht das automatisch oder konvertierst du jedesmal die Binärdatei durch manuellen programmaufruf in vcd und lädst diese dann wieder manuell ins GTKwave? Gruss Dave
> würdest Du deine AVR Firmware hier einstellen? Ich hab' den aktuellen Stand mal angehängt. Zum Übersetzen ist noch die V-USB-Library erforderlich[1]. > Wie muss ich mir die visualisierung am PC vorstellen? Geht das > automatisch oder konvertierst du jedesmal die Binärdatei durch manuellen > programmaufruf in vcd und lädst diese dann wieder manuell ins GTKwave? Im Makefile gibt es ein paar Targets, die Steuerung, Download, Konvertierung und GTKwave-Start automatisieren. Ich tippe z.B. make XO=1 DELAY=1 OCR=16 arm ein, um mit voller Oszillatorfrequenz zu samplen, und die Aufnahme 1 µs nach Triggerung zu stoppen. Die Variablen in der Kommandozeile entsprechen größtenteils irnkwelchen Bits in AVR-Registern. DELAY setzt den Vorteiler in TCCR und OCR ist das Register für den Delay-Timer. Nach Auslösen des Triggers - erkennbar an einer LED, die ich an die WE-Leitung geklemmt habe - wird durch "make foo.vcd" der Inhalt der Cache-Chips übertragen, und eine VCD-Datei erstellt. Tippt man stattdessen "make foo.v", wird gtkwave nach dem Download automatisch gestartet. Gruß Andreas Footnotes: [1] http://www.obdev.at/products/vusb/index.html
ansel besten Dank für die daten. Was verwendest du? winXP, MAc, ... Ist "anal.sch" ein eagle file? Mein Eagle 5.9.0 kann damit nicht umgehen. Gruss Dave
Dave schrieb: > Was verwendest du? winXP, MAc, ... Debian GNU/Linux 5.0. > Ist "anal.sch" ein eagle file? Mein Eagle 5.9.0 kann damit nicht > umgehen. Den Schaltplan hab' ich mit gschem gezeichnet. Siehe www.gpleda.org. Ein paar Beiträge weiter oben hab' ich ihn auch in PDF exportiert angehängt. Gruß Andreas
Angehängte Dateien:
-
minilog_2_1_s.png
42 KB -
minilog_2_2_s.png
25 KB
Hey Ho, ich hoffe das der Thread noch existiert ;) und hier mal jemand vorbei schaut. Leider antwortet Michael auf keine E-mails, deshalb versuche ich hier mal mein glück. Ich hab die Minilog 28 Varianten nachgebaut und hab da ein paar start schwierigkeiten. beim erstellen der Platine ist mir was im Schaltplan aufgefallen, ist das richtig das der 20Mhz Quarz mit VCC und GND an +5V hängt ? und Ext. clock sowie AVR PB3 und Ext. trigger haben keine Verbindung auf dem Board. Wenn ich das Modul an den PC anstecke, sagt er mir unter Info das kein Minilog modul erkannt wurde, der rechner selbst erkennt aber den ft232 Der AVR ist ein Mega8/Mega48 auf ext. clock gestellt, hab beide ausprobiert aber nichts geht. hx ist die von seiner seite. hab ich nen denkfehler oder muss ich noch was besonderes beachten ? schaltplan im anhang
Hi Tommy, Ext. Clock, Ext Trigger und AVR PB3 waren mal für Erweiterungen reserviert und können erstmal unbelegt bleiben. Einen extern zugeführten Clock einzubauen ist nebenbei nicht so trivial wie es anfangs mal ausgesehen hat, das wird wohl nie umgesetzt werden. Aber den 20MHz Oszillator solltest du schon mit den richtigen Versorgungsspannungen beliefern, das ist noch ein Fehlerchen im Schaltplan. Falls du es so wie im Plan gebaut hast, erklärt das warum er nicht gefunden wird. Hast du jetzt einen Mega8 oder einen Mega48 genommen? Die beiden sind nicht ganz code-kompatibel! Die Firmware auf der Webseite und hier im Thread funzt nur mit Mega48/88 aber nicht mit einem Mega8. Ich würde dir auch empfehlen erstmal eine kleine Testfirmware mit Bascom oder so zu bauen (z.B. nur das empfangene Byte seriell wieder zurück senden) und mit einem Terminalprogramm den korrekten Aufbau zu prüfen. Meistens ist irgendwo RXD/TXD verwechselt und man bekommt deshalb keine Antwort. mfg Harri
Da ist ja doch noch leben drin ;) das ist gut das sich jemand meinem Problem annimmt. Ich hab meine Platine mit dem geänderten Schaltplan konstruiert, also hab den Oszillator an VCC und GND gehangen. Ich habs wie gesagt mit beidem probiert. Zur zeit sitzt der Mega48 wieder drin -> Doch keine Regung. Ich kann nur C-Programmieren und brauchte den Minilog nur für ein anderes Projekt und dachte mir wenn die Firmware schon existiert dann brauch man ja kein großes Ding draus machen, aber anscheinend war des etwas voreilig:( Der Mega48 ist mit dem Mega88 kompatibel ? Ich denke doch das meine Schaltung stimmt hab ja nur den Oszillator anders angeklemmt, der rest ist original Schaltplan. kann es evtl. am RAM liegen ? Das Minilog funktioniert ohne RAM nicht also kann ichs so nicht testen. Mich mach ja stuzig das das Programm sagt das kein Modul gefunden wurde, obwohl der FT232 erkannt wurde am PC und die Software auch "grünes Licht gibt" Weiß einer was das grüne Licht bedeutet ? Sagt das nur "Richtiger COM-PORT" oder "es werden daten ausgetauscht". Vielen Dank Tommy ;)
Sry Doppelpost :( Ich hab die Firmware von seiner Seite drauf gebraten. Die sollte ja funktionieren :) Aber trotzdem Danke für den Tipp, ich probier einfach mal eine alte aus dem Thread hier aus. Tommy
Hi Tommy, wenn du C programmieren kannst, dann bau dir doch erstmal damit eine Testfirmware und probier die erfolgreiche Kommunikation mit einem Teminalprogramm aus. Vielleicht auch mal mit geringerer Baudrate und einem MAX232 als Pegelwandler dran. Du kannst auch mal eine LED (mit Vorwiderstand ;-) an einen Port des AVR hängen und per Testfirmware blinken lassen. Damit prüfst du vorab ob die Taktversorgung stimmt, die richtigen Fuses gesetzt sind, das flashen an sich geklappt hat und der AVR nicht kaputt ist. Dieses schrittweise Vorgehen hat mir damals sehr geholfen. Bitte beachten: ältere Minilog-Firmwares hier aus dem Thread brauchen auch eine dazu passende minilog.exe auf dem PC. Das fehlende RAM ist kein Problem, der Minilog muss sich auch ohne RAM am PC melden. Der Mega48 kann statt des Mega88 genutzt werden. Hast du schon passendes RAM im Zulauf oder suchst du noch was? mfg Harri
Alles klar, dann werde ich mich doch erstmal dem Minilog zuwenden bevor ich mein anderes Projekt weiter verfolge. Als RAM werde ich mir eins von Reichelt bestellen, aber die unterschiedlichen Zeiten, die Michael verwendet und welches das von Reichelt hat machen mich stutzig. Er spricht von 12 ns und Reichelt bietet 70ns. http://www.reichelt.de/?ACTION=3;GROUP=A34;GROUPID=2954;ARTICLE=2676;SID=29BMR8n6wQAR0AABFaCKc9400a113a7660a7ffe5d5db9dd28e409 Kurze Frage für die Verwendung des 20MHz Oszillators muss ich denn Mega48 auf Ext. Clock, also die CKSEL Fuse Bits im Pony Prog müssen alle "gesetzt" sein? ( PonyProg invertiert ja) Das wäre noch eine mögliche Fehlerquelle, denke aber das ich das richtig gemacht hab. Danke fü eure Hilfe Tommy
Mahlzeit! Die RAMs von Reichelt kannst du nicht nehmen, die sind viel zu langsam! Besorg dir ein 32kB Cache RAM von alten 486 Mainboards mit 15ns, die gehen gut. Die Fuses müssten so passen, mit einer kleinen Testfirmware und einer LED dran kannst du das recht einfach prüfen :-) mfg Harri
Jo hab grad nen externen Oszillator drangehangen also Fusebits sind ok. Puh wo bekomm ich denn jetz noch so ein Board her ?! ich frag mal google ;) Danke bis später ;) Tommy
Tommy schrieb: > Puh wo bekomm ich denn jetz noch so ein Board her Falls anderer Computerschrott rumliegt: Schnelle, asynchrone SRAMs (12-15ns) hab' ich auch schon auf 10MBit-Netzwerkkarten und in V.34-Modems gefunden.
Hallo ;) Ich hab mal ne anfrage bei Reichelt gestellt, mal sehen was die für so ein Teil haben wollen. gibts leider nichtmehr in THT nurnoch SMD :) Bei Ebay gibts noch alte Boards, mal sehen für wie viel die Dinger weg gehen. Hab auch schon altes Zeugs durchsucht :D SEGA, Videorecoder von Anno 1602 aber nix zu finden, zumindest nix mit der Geschwindigkeit. Morgen muss mal das große "Lager dran glauben. Ich meld mich wenns was neues gibt. @ ansel Hab gesehen das du den Minilog etwas modifiziert hast, sowohl Soft- als auch Hardware gibts dafür auch ne Doku ? Sonst kämpf ich mich durch deine Beiträge durch, wenn der Minilog dann endlich mal funktioniert :D Gruß Tommy
hätte mich auch gewundert wenn du in einem analogen Videorekorder überhaupt RAMs findest.
Müsste nicht dieser hier 313859 von http://www.csd-electronics.de/de/index.htm funktionieren? Kann leider nicht direkt linken, einfach nach der Artikelnummer suchen. Ist zwar leider SMD, aber dafür weiß man, wo man ihn herbekommt. Sebastian
Moin Moin :D Die Platinen lagen nunmal rum, also hab ich sie mit aufgezählt :). Ich hab hier -> http://www.darisus.de/Preise/Speicher.php? auch einige gefunden, werd mich mal dahinter klemmen. Irgendwo wird schon was zufinden sein :D so schnell geben wir doch nicht auf. Bis denne Gruß Tommy
Hi Tommy, wenn du mir deine Adresse zukommen lässt, stopf ich dir ein paar 32kB-RAMs mit 15 oder 20ns in einen Briefumschlag. mfg Harri
Hallo Ansel, ich versuche gerade deine LA Version nach zu bauen. Dazu habe ich den atmega8 mit 12mhz aufgebaut (im Makefile angepasst) und angeschlossen. Leider wird kein usb device erkannt. Die Leitungen d- d+ schweigen. Merkwürdig... fuses sind: C9/EF Irgendwie habe ich den verwendeten compiler/linker im Verdacht. Könntest du dein .hex file mal zur Verfügung stellen? Gruß Christian
LAbastler schrieb: > ich versuche gerade deine LA Version nach zu bauen. > Dazu habe ich den atmega8 mit 12mhz aufgebaut (im Makefile angepasst) > und angeschlossen. Leider wird kein usb device erkannt. Die Leitungen d- > d+ schweigen. Merkwürdig... Durch den Pullup an D- sollte das System unabhängig vom AVR ein Gerät erkennen. Falls die Firmware nicht anläuft, sollte in den Kernel-Logs die Meldung auftauchen, dass dem neuen Gerät keine Adresse zugeteilt werden konnte ("could not enumerate..."). Taucht beim Einstecken jedoch gar keine Meldung auf, vermute ich den Fehler in der USB-Verdrahtung. Wie bereits erwähnt fehlt diese in meinem Schaltplan. Ich hab' "Solution B" von http://vusb.wikidot.com/hardware verwendet. > Irgendwie habe ich den verwendeten compiler/linker im Verdacht. > Könntest du dein .hex file mal zur Verfügung stellen? Das Image von damals hab' ich leider nicht mehr, kann auf die Schnelle also nur ein neu übersetztes anbieten, völlig ungetestet und mit neuerem avr-gcc übersetzt (4.4.5). F_CPU hab' ich vor dem Übersetzen auf 12 MHz gesetzt. Gruß Andreas
Frohe Ostern Andreas! Danke für die Blitzantwort! Ich hab offensichtlich den 1.5k Pullup vergessen... wie blöd! Aber jetzt meldet sich ein "logic analyzer and Pattern Generator Thingy" :-) Sehr schön! jetzt muss ich nur noch den 4040 auftreiben und viele Drähte ziehen ... ächz. Hast du das Ding eigentlich ad acta gelegt, oder bastelst du noch daran herum? Gruß Christian
> Hast du das Ding eigentlich ad acta gelegt, oder bastelst du noch daran > herum? Also irgendeine Form von Datenkompression werde ich bei Gelegenheit noch reinbasteln. Vor allem, wenn man mehrere Anläufe braucht, um an gesuchte Bits zu kommen, sind die 8 kByte/s des Software-USB etwas grenzwertig. Dann war auch mal angedacht, einen bidirektionalen Bustreiber statt des 74541 zu verwenden, um die Hardware als Pattern-Generator verwenden zu können, aber irnkwie fehlte bis jetzt der Bedarf... Gruß Andreas
Hallo an euch, ich wollte gerade den MiniLog 80 MHz nachbauen. Tolles Projekt. Hat jemand vieleicht ein fertiges Layout bzw. die Eagledateien ? Gibts noch jemanden der mir einen passenden Ram schicken kann ?? Vielen Dank
Wenn ich mich recht erinner passt Artikelnummer 313859 von http://www.csd-electronics.de Der Shop erlaubt leider keine Deep-links, aber über die Artikelnummer sollte man ihn finden. Viele Grüße, Sebastian
Hallo. Ich werde mir wohl auch den LA nachbauen. Da ich die meisten Teile eh bestellen muss, stelle ich mal ganz salopp die Frage, welche Version ist die Stabilere und aktuelle? Sollten die Eagle Files der Homepage aktuell sein, werde ich mir wohl die Arbeit mache eine Platine zu routen. (Vll. baue ich aber auch auf Lochraster... hab ich auch schon ewig nicht mehr). Schöne Grüße aus Saarbrücken Denis
Wenn es dir darauf ankommt, einen LA zu haben und weniger das Basteln wichtig ist, würde ich vielleicht meinen verkaufen. Müsste aber noch nachschauen, welche Version ich genau habe. Wenn du interesse hast schreib mir mal ne PM. Ansonsten: Bei mir läuft die Hardware einwandfrei, nur die Software stürzt ab. Version schau ich bei gelegenheit nach. Grüße, Sebastian
Gerade noch nachgeschaut: Ich hab hier die 50MHz version mit 32kB RAM. Laut PC-Software Hardware v1.1. Denke, das bezieht sich auf die Firmware. Die Hardware läuft wie gesagt stabil bei mir. Ist alles auf Lochraster aufgebaut. Mit den anderen Hardware-versionen habe ich keine Erfahrung, aber soweit ich mich an den Thread erinnere machten die anderen Versionen auch keine Probleme. Lass dir aber gesagt sein, dass das Gerät hier ehr eine Spielerei ist als ernstzunehmendes Messwerkzeug. Das soll Michaels Leistung jetzt nicht schmälern, aber wer wirklich einen LA für seine Entwicklungen braucht sollte trotzdem über andere Geräte nachdenken. Viele Grüße, Sebastian
Angehängte Dateien:
-
MiniLog_1.cmp.png
8,4 KB -
MiniLog_1.sol.png
6 KB
Hallo Sebastian, ich habe bereits ein Layout und eine Platine. Momentan warte ich auf die Quarze. Soweit bin ich mal gespannt, ob das alles so Funktioniert. Falls jemand Interesse haben sollte an den Eagle Files, die gebe ich gern weiter. Die Schaltung ist soweit unverändert, jedoch das Layout ist Eigenleistung. Gruß
Angehängte Dateien:
-
DSC_5922.jpg
280 KB
Michael U. schrieb: > Hallo, > > keine Ahnung, wo es reinpasst oder ob es jemand wissen will... ;-)) ... > Würde mich freuen, wenn es jemanden interessiert. > > Gruß aus Berlin > Michael Bis 2013 bestand auf jeden Fall Interesse. Vielleicht freut es Dich auch heute noch, ich habe Deinen LA im Großen und Ganzen dank Deiner guten Dokumentation nachgebaut. Anstatt '161 sind '590 drin, die beiden Bytes für Maske und Trigger habe ich per '4094 an die '32 angelegt (man will ja keine 8-Bit Ports vom AVR vorzeitig verschwenden ;)), und das RAM ist ein BSI BS62LV4006 mit 512kB Speichertiefe. Am Eingang werkelt momentan noch ein '574, um die Signale zu latchen (mehr oder weniger gut, ok), ich möchte aber die Kiste sowieso als Patterngenerator verwenden und deshalb durch einen '245 ersetzen. Irgendwann ;( Den AVR habe ich mit einem Bootloader ausgestattet, er kann also jederzeit auf den "neuesten" Stand gebracht werden. Der sich natürlich auch an meiner Veteranen-Bastelkiste orientiert, aber nicht nur. Denn Dein Logikanalysator war damals und ist auch heute zwar "alte Technik", aber das Ding funktioniert im furchtbaren Lötraster-Kabelverhau-Zustand schon jetzt bis 50 MHz sehr ordentlich. Und nicht jeder Hobbybastler mag sich mit Spartan3 beschäftigen. Ich hatte kurze Zeit darauf verschwendet, einen STM32F429 per FMC zu ähnlichem zu animieren, mit 8 MB Speichertiefe, aber hatte die BSI und die anderen Sachen halt rumliegen. Und würde außerdem an dem Linkerscript zum STM verzweifeln. Vorerst g Die PC-Seite programmiere ich übrigens auch und noch immer in VB6, kann aber bisher nur das Mustersignal darstellen und die Trigger und Maskensignale übertragen. Aber das wird schon noch - das Schlimmste war, keine Fehler bei der Hardware zu machen (beim '590 RCO, CLKenable und 19 Adressleitungen war einiges Potential diesbezüglich vorhanden). Grüße vom ExBerliner
Hallo, das sieht ja interessant aus. Wird daraus eventuell ein Projekt mit Doku? Ich habe mir auch einen LA gebaut, jedoch läuft die Software alles andere als Stabil unter dem von der IT vernagelten Windows 7. Ich habe auch kurz versucht mir mit VB.net was zu bauen, jedoch mangels Zeit/Kenntnissen aufgegeben. Grüße aus Saarbrücken Denis
Hallo, vielleicht schaut ja nochmal jemand rein :-) Ich kann MiniLog im PC nicht installieren, weder XP noch WIN10. Der Fehler ist immer gleich (siehe Anlage). Hat jemand einen Tip?
Hallo Bruno, zum Logic Analyzer habe ich leider garnichts mehr außer der Hardware. In meiner aktuellen Win-Installation ist nicht mal mehr die Desktop-Software installiert... Bei mir lief die Software damals auf Windows 7. Soweit ich mich erinnere, braucht die Software die Visual Basic runtime. Ich meine, dass ich damals auch probleme mit der Installation hatte, bis ich die VB-runtime installiert hatte. Ansonsten kann ich mit dem log leider nicht viel anfangen. VG Sebastian
Hallo Sebastian, herzlichen Dank für die schnelle Reaktion (du hast dich nicht geändert!!) Dann will ich mal weiter probieren. Bruno
Sebastian .. schrieb: > > Soweit ich mich erinnere, braucht die Software die Visual Basic runtime. > Das war genau der richtige Tip!! Danke
Angehängte Dateien:
-
Sampling-1kHz.jpg
130 KB -
Sampling-20MHz.jpg
130 KB -
Testpattern.jpg
210 KB -
SRAM.jpg
130 KB
Hat jemand von Euch die MiniLog40 Variante erfolgreich aufgebaut? Mein Nachbau funktioniert zwar auf den ersten Blick, bei genauerem Hinsehen sind aber Aussetzer / Unstetigkeiten im Signalverlauf. Ich habe die Original Eagle-Schaltung von Michael U geroutet und hieraus eine Platine fertigen lassen. Sowohl beim Sampeln mit dem µC-internen langsamen Takt als auch bei Nutzung des externen schnelleren Takts das gleiche Fehlerbild. Gemessen wurden symmetrische Rechtecksignale, die von einem Quarzgenerator mit TTL Teilerstufen erzeugt werden. Die Signalverläufe sind weitgehend korrekt - auch die Zeit/Frequenzmessungen zwischen den Markern stimmen, aber es gibt immer wieder Aussetzer (auf allen Kanälen), siehe Screenshots. Als SRAM habe ich ein W24129AK-12 (16k x 8) benutzt. Das Problem tritt sowohl bei Bezug der 5V über den USB/RS323 Adapter vom PC als auch bei Nutzung eines externen 5V Netzteils auf. Mal abgesehen davon, dass in der Originalschaltung I/O5 & I/O6 am SRAM miteinander verbunden sind, ist mir in der Hardware kein weiterer Fehler aufgefallen. Hat jemand eine Idee was die Ursache sein könnte? - Thomas
Angehängte Dateien:
-
P1070936.jpg
240 KB
so, das Problem ist mittlerweile gelöst. Nach Austausch des SRAM gegen ein UM6164DK-12 (wie hier empfohlen) waren die Messungen mit dem µC internen Takt bis 125µs (8MHz) OK, aber die Messungen mit 20/40/80MHz (externe Taktung) waren immer noch völlig unbrauchbar. Die Ursache hierfür war ein Fehler in "avrstudio_minilog40.zip" von Michaels Homepage. Dort sind in "Definitionen.Inc" die Maskenbytes für 20/40/80MHz falsch zugeordnet. Nach deren Korrektur funktioniert es nun. Messungen mit 12,5ns sind zwar immer noch unsauber, aber da kommt wohl die Hardware an ihre Grenzen, 25ns (40MHz) sind stabil. Mit einem 50MHz Oszillator gibt es nun keine Probleme mehr. - Thomas
Thomas N. schrieb: > Dort sind in "Definitionen.Inc" die Maskenbytes für > 20/40/80MHz falsch zugeordnet. Nach deren Korrektur funktioniert es nun. Dann lade die Korrekturen doch hier hoch!
Hier die korrigierten Bitmasken aus Definitionen.inc für den MiniPro40
1 | .equ MUX_INT = 0b00000000 |
2 | .equ MUX_20MHZ = 0b01000000 ; !! |
3 | .equ MUX_40MHZ = 0b10000000 ; !! hier ändern !! |
4 | .equ MUX_80MHz = 0b11000000 ; !! |
5 | .equ MUX_MASKE = 0b00111111 |
Hallo, ich habe die Archivdatei auf meiner Webseite korrigiert... Die ganze Geschichte feiert ja schon den 10. Geburtstag, ich habe hier nur noch eine Version mit Mega88 im Einsatz, der Fehler ist also wohl schon ewig so oben gewesen. Freut mich trotzdem immer, wenn jemand da noch was nachbaut. :-) Gruß aus Berlin Michael
Angehängte Dateien:
-
50MHz-Login.jpg
130 KB -
Samplerates.jpg
120 KB
Hier gleich die nächste Frage an Michael: Mit der Umrüstung des Analyzers auf 50MHz ändern sich ja auch die Abtastraten. Die schnellsten 3 sind dann per Hardware zu 50MHz, 25MHz und 12,5MHz fest vorgegeben. Die weiteren, vom µC erzeugten kann ich je nach Wunsch in der Firmware abändern. Wenn ich mich nun mit der 50MHz Version bei Deiner PC Software anmelde, bekomme ich aber bei den oberen Abtastraten falsche Werte angeboten. 20ns (50MHz) ist OK, aber 50ns (20MHz) und 100ns (10MHz) werden von der Hardware gar nicht erzeugt. Muss ich da einen anderen Versions-String senden oder stimmt da was mit dem PC Programm nicht? Gruß aus Bremen - Thomas
Hallo, Thomas N. schrieb: > Muss ich da einen anderen Versions-String senden oder stimmt da was mit > dem PC Programm nicht? ich muß da mal zu sortieren versuchen: Die 50MHz-Version hat statt des 80MHz Quarzes einen 50MHz Oszillator gehabt, der direkt genutzt wurde. Dazu einen 20MHz Oszillator statt des IC2 (74ACT74), der auch den Takt für den AVR liefert. Die landen jeweils am MUX. Die 10MHz erzeugt der AVR an PB1 aus seinem 20MHz Takt und gibt sie auf den MUX. Dafür sollten die eingestellten Werte eigentlich stimmen. Ansonsten müßten wir schauen, welche Takte hast Du denn jetzt am MUX zum Umschalten? Gruß aus Berlin Michael
Hallo Michael, es handelt sich um die auf Deiner Homepage unter http://www.avr.roehres-home.de/logikanalyzer/archive/eagle_minilog40.zip vorzufindende Schaltung, zu der ich die weiter oben abgebildete Platine erstellt habe. Statt 80MHz Quarzgenerator 50MHz. Also bekomme ich unter Einbeziehung des 74ACT74 die Frequenzen 50MHz (20ns), 25MHz (40ns) und 12,5MHz (80ns) als feste Größen geliefert; die langsameren kann ich per Firmware variieren da sie vom ATmega16 erzeugt werden, die aus dem 50MHz Generator aber nicht. Ferner hatte ich ja noch einen Schaltungsfehler entdeckt, den ich auf der Platine nachträglich korrigieren musste. Dieser ist in der beigefügten PDF Datei gelb markiert. Gruß aus Bremen - Thomas
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.