Announcement: there is an English version of this forum on 
Hallo, keine Ahnung, wo es reinpasst oder ob es jemand wissen will... ;-)) Ich habe meinen Logic-Analyzer incl. Software zumindest soweit fertig, daß es vielleicht jemanden interessieren könnte. Der ganz Kram liegt auf meiner Homepage: http://www.avr.roehres-home.de/logikanalyzer/index.html Typischer Restbau von mir: Kosten wohl 30 Euro, wenn man alles kauft, Lochrasteraufbau, noch nicht ganz fertig. Würde mich freuen, wenn es jemanden interessiert. Gruß aus Berlin Michael
Angehängte Dateien:
-
minilog_4.jpg
84 KB
Ist ja ein geiles Projekt! :) Werde ich sicher demnächst mal nachbauen! In was ist denn die Desktop-Software geschrieben? Vielleicht kann ich da ein wenig entwicklerisch unterstützen. Gruß! Sven
Hallo, gutes altes VisualBasic v6... Unter konsequenter Nutzung aller ptogrammiertechnischen Nachteile, die man da einbauen kann. ;-)) Ich brauchte einfach schnell was funktionsfähiges, bei dem ich vollen Zugriff auf AVR- und PC-Teil habe. Es liegt auch schon ein erweiterter Schaltplan hier, der 32k Speicher unterstützt, externen Trigger- und Sampletakteingang hat und einen Mega48 benutzt. Mal schauen, wann ich den zusammenlöte... Gruß aus Berlin Michael
Prima Projekt, sehr schoen ausgefuehrt! Freut mich auch zu sehen, dass es sehr anfaengerfreundlich aufgebaut ist (alles in DIP). Ich selber habe schon einen netten 8-Kanal-LA (das Saleae-Geraet) aber ich bin mir sicher, Du findest genug Nachbauer. Ausreichend Sampletiefe ist sehr wuenschenswert (immerhin moechte man ja einige Samples pro Datenbit), eventuell kannst Du ja Hardware und vor allem auch Software so flexibel auslegen, dass sich jeder nach Bedarf den Speicher erweitern kann. Engstelle wird allerdings irgendwann die serielle Schnittstelle, mit 115 kbaud dauern 32 KB schon ein paar Sekunden, ist aber noch vertretbar. Was ausserdem nett waere - die Moeglichkeit auf eine Flanke zu triggern. Z.B. fuer SPI ist es besser, auf die fallende Flanke der /CS-Leitung zu triggern, als auf "/CS Low". Wolfgang
Hallo, Übertragung werde ich noch auf 230400 setzen, der Fehler bleibt da bei 20MHz AVR-Takt der gleiche. Prinzipiell gehen natürlich auch höhere Raten, 500kBaud unterstützt aber die virtuelle COM des FTDI wohl nicht. Die Grenze liegt hier ja bei FTDI/PC und dem AVR-Takt. Echte Flanke ist ein Problem. Bei SPI dürfte aber z.B. die Kombination /CS Low und SCK High (oder Low, je nach SPI-Mode) erstmal helfen. Das Bild auf der Homepage ist vom RFM12 meiner Sensorgeschichte, getriggert auf /CS Low und SCK H. Da ich weiß, das je nur ein Takt kommt, wenn der Master sendet, geht das auch gut. Ich versuche mich jetzt mal an ein paar Analyse-Geschichten. SPI, UART und I2C erstmal, weil ich das in Benutzung habe, LIN wohl, weil mein Bekannter damit rumbastelt. Zumindest läuft im Moment Hard- und Software erstmal stabil, er triggert hier im Automode auf die Signale meiner Sensoren (6 Stück, ca. 1x pro Minute). Auch nach über 700 Ereignisse läuft noch alles. :-) Gruß aus Berlin Michael
So eine einfache Protokollanalyse in der Software fuer RS-232, SPI und I2C, also Anzeige der gesendeten oder empfangenen Datenbytes im Klartext, waere tatseaechlich eine grosse Hilfe. Das ist fuer mich einer der Hauptunterschiede zwischen Oszilloskop und Logikanalysator, und spart unheimlich Zeit bei der praktischen Arbeit mit dem Geraet! Wenn die Harware endgueltig fertig ist, planst Du eigentlichn eine "richtige" Leiterplatte? Ich bin mir sicher es gibt etliche Interessenten an sowas, besonders als Kit zum Selberbau, und in Kleinserie (ab ca. 50 Stueck) ist die Leiterplattenfertigung extrem billig (so ca. 5 Euro/Stueck bei PCBCart).
Ich melde auch schon mal Interesse an einer Platine an, wenn ich Zeit finde, kann ich evtl. auch eine erstellen. Was noch schön wäre, wenn man mindestens zwei analog Kanäle hätte, so wie hier: Beitrag "Oszi- & Logikanalyser mit LCD"
Hallo, ich fange mal hinten an... Analoge Kanäle wären 2 Probleme: schnelle A/D-Wandler (Flash-Wandler aus der Video-Ecke mit 2MS/s als Beispiel). Problem 1: kaum noch in DIL zu beschaffen Problem 2: bei 2 (oder mehr Kanälen) müßte im Zeitmultiplex jeweils ein Datenbyte von jedem Wandler in den Ram geschrieben werden. Also vor dem ADC schneller Analog-Mux und dahinter schnelle Tri-State-Buffer und ein MAX, der vom Adresszähler mitgesteuert wird. Da ein paar Gatter für die Umschaltlogik. Machbar, in TTL auch kostengünstig als Drahtverhau. Würde dann heißen: bei einem Kanal max. 50MS/s in maximaler Sampletiefe (wenn es der ADC kann), bei 2 Kanäle halbe Sampletiefe und halbe Samplerate usw. In der Software wäre die Anpassung gering. Von meiner Seite: im Moment keine Aktion. Wenn jemand da löten will, uch helfe gern. Kann man an eine spielende Version ja sozusagen "dranknoten". Randbedingung: ich muß den Umbau auf Mega48 erledigen, sonst sind keine Portpins frei. Das passiert aber ohnehin im Laufe der kommenden Woche. SPI-Decode bin ich gerade dran, bin über die Darstellung noch etwas im unklaren. Bei ausreichendem Zoom will ich es direkt in das Sample reinschreiben, alternativ nur Byte-Marken setzen und eine Textliste. Mal schauen... Leiterplatten: von mir direkt mit Sicherheit nicht. Wenn jemand routen will gern. Kritisch dürften die Datenleitungen zwischen Eingangsbuffer, AVR, Ram und den OR-Gattern der Triggerlogik sein. Danach evtl. die Adressen des Ram. Alles dahinter ist AVR-typisch lahm und unkritisch. Meine Größe ist im Moment vom vorhandenen Gehäuse gegeben, dieses Exemplar bleibt auch so. Ein Umbau bei mir bekommt entweder ein etwa größeres Gehäuse oder 2 Leiterplatten im Huckpack. AVR, Triggerlogik, Takt mit MUX könnten auf eine, Ram, Zähler, Eingangsbuffer und was uns noch einfällt, auf die andere. Kritische Verbindung zwischen beiden wären dann die 8 Datenleitungen und der Zählertakt sowie das /WE-Signal. Ist mir zumindest eine Überlegung wert. Es gibt eine Anfrage zum Thema Leiterplatten und Bausatz, darüber denke ich zumindest nach. Gruß aus Berlin Michael
Michael U. schrieb: > Analoge Kanäle wären 2 Probleme: > schnelle A/D-Wandler (Flash-Wandler aus der Video-Ecke mit 2MS/s als > Beispiel). > Problem 1: kaum noch in DIL zu beschaffen Finde ich eher positiv, da ich meistens geätzte Platinen verwende und das ohne Löcher bohren unproblematischer geht. Für Schaltungsentwicklung á la Lochraster natürlich eher hinderlich. > Problem 2: bei 2 (oder mehr Kanälen) müßte im Zeitmultiplex jeweils ein > Datenbyte von jedem Wandler in den Ram geschrieben werden. > Also vor dem ADC schneller Analog-Mux und dahinter schnelle > Tri-State-Buffer und ein MAX, der vom Adresszähler mitgesteuert wird. > Da ein paar Gatter für die Umschaltlogik. > Machbar, in TTL auch kostengünstig als Drahtverhau. Stimmt, das macht die Sache schon recht aufwendig. Mit 50MHz hatte ich bis jetzt auch noch nichts am Hut. Kann sein, dass da unvorhergesehene Probleme auftauchen.
Hallo,
gast schrieb:
> was ich gerade vermisse oder nicht gefunden habe ist die AVR-Software.
was daran liebt, daß die noch nicht daliegt... ;-)
Falls Du so schnell im Löten bist, daß Du sie brauchst, schick mir eine
Mail.
Ich will eigentlich erst noch auf den Mega48 umbauen, der Mega644 war
letztlich nur eine Notlösung und ist Verschwendung an dieser Stelle.
Passiert in den nächsten Tagen...
Ich habe das jetzt mal auf versuchsweise 2 Huckepack-Leiterplatten
aufgeteilt, das sieht soweit gut aus und sollte dann noch in das gleiche
Gehäuse passen.
Gruß aus Berlin
Michael
Also ich persoenlich denke, lieber keine Analogkanaele dazubauen. Das macht das Ding bloss komplexer, und das heisst fuer viele uninteressanter. Ein Drittel der Leute will es dann mit Analogteil, ein Drittel ohne, und ein Drittel mit Analogteil aber mit hoeherer Bandbreite :-) Was aber nett waere: Einfach das Triggersignal extern zugaenglich machen, dann kann sich jeder Sein Oszi dazubauen oder ein existierende Oszi damit triggern. Das sollte im wesentlich ein 2-pin-Jumper sein. Wenn jemand ein einfaches (1 MS/sec Samplerate, 400 kHz Bandbreite) Zweikanal-Oszi dazubauen will, ich habe ein Design im Internet, das aehnlich anfaengerfreundlich ist - kannst Du gerne als Basis verwenden: http://www.pdamusician.com/lcscope/ Den Picaxe-Mikrocontroller kann man dann bei Bedarf mit dem schon existierenden AVR ersetzen, oder man verwendet ihn einfach als "Slave", der seine Daten zum AVR schickt (das waere viel weniger extra Softwareaufwand). Ich arbeite auch gerade an einem dsPIC-basierten Zweikanal-Oszi, das 1 MS/sec single-shot und 10 MS/sec in Equivalent-Time-Sampling schafft und bloss aus etwa 5 Chips und zugehoerigen diskreten Elementen besteht. Das koennte auch gut dazupassen - Harware is billig und einfach. Der Digitalteil arbeitet schon prima, den Analogteil werde ich wohl vom obigen Oszi uebernehmen (eventuell mit etwas verbesserter Bandbreite). Wolfgang
Hallo, von meiner Seite gibt es absehbar sowieso nichts analoges eingebaut. Speichertakt in beiden Phasenlagen estern ist kein Problem, gibt ja schließlich noch kein Layout. Beim Umbau auf den Mega48 werden die Triggerdaten seriell in 2 kaskadierte 74xx164 geschoben. Da ist ein Ausgang von Clk und Q8 des zweiten auch angedacht. Damit kann man Einstellwerte dann zu externen Erweiterungen durchschieben. Ist erstmal für den Schwellwert einer externen aktiven Probe gedacht, da ist mein Bekannter am sondieren. Mit dem Takt zusammen kann man dann natürlich auch einen Flash-ADC sammt Bereichsumschaltung erledigen. Allerdings sollte der ADC selbst da nicht programmierbar sein, sonst müsste man noch eine I2C/SPI rausführen und dann werden wieder die Pins am Mega48 knapp. ;-) Hier liegt noch ein ADC1175 rum der kann 20MHz... Gruß aus Berlin Michael
Hallo, mit VHDL habe ich erstmal nichts am Hut, werde aber bestimmt keinen hindern. ;) Ein Bekannter nimmt das gerade als Einarbeitungsobjekt für das Pollin-CPLD-Board. Als Übungsaufgabe, weniger als Anwendung. Ich habe gestern erstmal angefangen, einen Adapter für den Mega644-Sockel zu löten, der einen Mega88 (war gerade da ;-) und 2x 74LS164 trägt. Werde ich hoffentlich heute noch fertig machen und dann die Firmware erstmal darauf umstellen. Der Mega644 mit 1,5% Flash-Nutzung stören mich eben... Gruß aus berlin Michael
Hallo schönes Projekt wann wird der Sourcecode Veröffentlicht? Und wie machst du die > 10MHz (100ns) der Timebase, per PWM ? Wenn ich jetzt einen 16MHz Quarz nehme kann ich doch max. 8MHz als Timebase nehmen.
Hallo, Avr Nix schrieb: > Hallo schönes Projekt wann wird der Sourcecode Veröffentlicht? Vielleicht noch heute, dann für meine (vorerst) endgültige Version mit Mega48/88. > Und wie machst du die > 10MHz (100ns) der Timebase, per PWM ? Siehe Schaltbild, mit getrennten Quarz-Oszillatoren. Der AVR wird mittlerweile dann vom 20MHz Oszillator getaktet. > Wenn ich jetzt einen 16MHz Quarz nehme kann ich doch max. 8MHz als > Timebase nehmen. Solange Du den Takt nur intern erzeugst ja. Für 16MHz müssen dann die Tabellen angepasst werden und eine Abstufung 1:2:5 ist dann natürlich auch nicht möglich. Müßte dann eben auf 8, 4, 2, 1 oder ähnlich gestuft werden. Da müßte dann natürlich auch die VB-Software angepasst werden. Werde ich nicht machen, VB6-Sourcen kann ich aber gern rausgeben. Das Problem mit den Sampleraten ist folgendes: mehr als ca. 1/10 der Samplerate ist als Signal nicht mehr sinnvoll auswertbar. Wenn ich Timing-Differenzen zwischen 2 Signalen erkennen will, muß auch oft genug abgetastet werden. 8MHz lassen eben nur 125ns Zeutraster zu. Ein mit 16MHz getakteter AVR kann da aber schon 2x ein Portpin ändern und der LA bekommt davon nichts mit. Ich halte die 50MHz als Minimum, wenn ich damit in üblichen AVR-Basteleien noch was erkennen will. Für UART/I2C usw. reichen aber durchaus auch 8MHz noch aus. Gruß aus Berlin Michael
Wäre auch gut wenn du die VB Source veröffentlichen würdest. Dann warte ich mal bis heute Abend auf die Veröffentlichung der Quellen.
Hallo, so, nachdem der Neubau soweit erstmal läuft, habe ich die Webseite noch schnell erweitert. Es läuft soweit alles, 16k Samplespeicher zur Zeit, für 32k muß ich das VB-Programm erstmal etwas auf- und umräumen. Der Buffer von MSComm ist nicht der Meinung mit 32k klarzukommen... Übertragungsrate ist jetzt 500kBaud, sollte eigentlich stabil gehen, im Auto-Mode gab es allerdings sporadisch Übertragungsfehler, das muß ich mir wohl noch genauer ansehen. http://www.avr.roehres-home.de/logikanalyzer/index.html Gruß aus Berlin Michael
Cooles Projekt. Endlich mal ein Projekt, bei dem Der AVR sinvoll zum Auslesen des RAMs und nicht zum samplen eingesetzt wird. Kommt man mit einer schön gerouteten Platine sogar auf 80-100MHz, oder sond die TTLs zu langsam?
Hallo, 80MHz sind im Test schonmal gelaufen. Der Drahtverhau ist (seltsamerweise?) recht unkritisch. 100 an allen ICs, Spannungsversorgung mit 0,5er Draht als eine Art Maschennetz, der Rest frei mit Wrapdraht. Sowas verdrahte ich eigentlich immer hmmm... nach HF-Gefühl... ;-) Problem ist einmal der Cache-Ram und einmal das Tastverhältnis des Quarzoszillators. Das sollte nahe an 50% sein, ist es aber wohl praktisch nicht immer. Jedenfalls laufen nicht alle, die ich habe da richtig. Der Adresszähler kommt eigentlich weit über 100MHz, der Rest der Logik ist recht unkritisch. Ich werde irgendwann mir das reale Timing mal mit passender Meßtechnik anschauen, muß mal schauen, was meinem Bekannten dazu einfällt. Gruß aus Berlin Michael
Also falls einer vor hat, eine Leiterplatte für die neue Version zu entwickeln, würde ich mich auch schon mal anmelden dafür. Würde mich ja auch selbst hinsetzen, allerdings dauert so etwas bei mir im allgemeinen mehrere Wochen und dann nur mit sprint-Layout (mit eagle komme ich nicht klar). Auch hätte ich bei diesen Frequenzen bei meinen Entwürfen Bedenken, da ich leider kein "HF-Gefühl" besitze ;-). Gruß Sven
Hi! Gratulation! Ausgezeichnetes Projekt, das auch der Anfänger leicht nachbauen kann. Mich bringt es auf eine Idee, was ich mit den Stangen von Cache-SRAMs anfangen könnte, die aus den Tagen der 386..586er noch bei mir herum fliegen. Da sind etliche 12ns bis 8ns RAMs in einer Kiste. Wenn man jetzt noch über ein CPLD die Sachen auf mehrere SRAMs verteilt, dann sollten auch ein paar 100 Megasamples möglich sein. Nein, ist nur Spaß, das Layout wäre deutlich komplizierter und das Synchronisieren von Sampler und CPU wäre ein Horror für ein Bastelprojekt. Aber ich habe auch noch ein paar AT90USB1286/7er herum fliegen, was den USB-Adapter überflüssig macht. Also weiter so, Deine Ideen sind gut. Aber mach kein Scope draus, das ist wieder am Thema vorbei und Eierlegendewollmilchsäue werde nie fertig. Wenn man noch was verbessern will, dann könnte man über eine Verlängerung des Eingangs nachdenken. Also eine kleine Dose mit Wandlern um die Eingänge auf Differentiell umzusetzen und am anderen Ende des 60..120cm langen Kabels dann eine Rückwandlung von Differentiell auf Unipolar. Gruß, Ulrich
Hallo, Ulrich P. schrieb: > Hi! > > Gratulation! Ausgezeichnetes Projekt, das auch der Anfänger leicht > nachbauen kann. Danke. :-) > Mich bringt es auf eine Idee, was ich mit den Stangen von Cache-SRAMs > anfangen könnte, die aus den Tagen der 386..586er noch bei mir herum > fliegen. Da sind etliche 12ns bis 8ns RAMs in einer Kiste. Rate mal, wo meine her sind... Mein schnellster ist leider nur ein 8kx8 in 12ns, ein 32kx8 in 15ns (der steckt auf dem aktuellen), der Rest ist nur 20ns. Die Cache-Rams sind da günstig, weil in DIL und weil deren Cyclus-Verhalten diese Art der Steuerung zuläßt. > Wenn man jetzt noch über ein CPLD die Sachen auf mehrere SRAMs verteilt, > dann sollten auch ein paar 100 Megasamples möglich sein. Nein, ist nur > Spaß, das Layout wäre deutlich komplizierter und das Synchronisieren von > Sampler und CPU wäre ein Horror für ein Bastelprojekt. Aber ich habe > auch noch ein paar AT90USB1286/7er herum fliegen, was den USB-Adapter > überflüssig macht. > Also weiter so, Deine Ideen sind gut. Aber mach kein Scope draus, das > ist wieder am Thema vorbei und Eierlegendewollmilchsäue werde nie > fertig. Hatte ich doch schonmal angefangen. ;-) Alle Signale für einen extern ansteckbaren Flash-Wandler stehen allerdings zur Verfügung... Ich werde das sicher irgendwann auch mal probieren. > Wenn man noch was verbessern will, dann könnte man über eine > Verlängerung des Eingangs nachdenken. Also eine kleine Dose mit Wandlern > um die Eingänge auf Differentiell umzusetzen und am anderen Ende des > 60..120cm langen Kabels dann eine Rückwandlung von Differentiell auf > Unipolar. Hatte mein Bekannter auch überlegt, erstmal aber ganz nach hinten geschoben. Einfach, weil man die relativ kleine Schachtel dicht genug an den Kram ran befördern kann. Gruß aus Berlin Michael
Wo bekommt man denn die SRAMs her, wenn man keine mehr herumfliegen hat? Leider habe ich solch alte PC-Technik inzwischen entsorgt. Bei Angelika gibt es auch nur welche mit 70ns und beim C kosten die Dinger ca. 6,- €.
>Wenn man jetzt noch über ein CPLD die Sachen auf mehrere SRAMs verteilt, >dann sollten auch ein paar 100 Megasamples möglich sein. Nein, ist nur >Spaß, das Layout wäre deutlich komplizierter und das Synchronisieren von >Sampler und CPU wäre ein Horror für ein Bastelprojekt. Aber ich habe Das soll wohl ein Scherz sein? Mit einem €20,- Fpga kann man mit wenig Aufwand locker ein 50 kanaliges 500Ms/s Oszi nach diesem Prinzip bauen. Zusätzlich könnte man noch 4 unterschiedliche Spannungshübe definieren. Damit wären auch ADC's überflüssig.
Hallo, @Bishop (Gast): kann man, machen ja auch einige, teilweise schon seit Jahren und nur wenig teurer als ein fertig gekaufter und einige Projekte haben sogar schon etwas Software... Sorry, das mußte jetzt mal sein. Sowohl mein Bekannter als auch ich haben ein wenig im Web gegrast und das war das Resultat dabei. Scheint also zwischen "kann man" und "mit wenig Aufwand" eine gewisse Diskrepanz zu bestehen. :-) Meine Absichten (und Grenzen) sind da relativ einfach: Zeug für ein paar Cent aus der Kramkiste, Spaß am entwickeln und bauen der Logik, Freude, weil es auch noch funktionert. Entwicklungszeit bis heute waren wohl so 6 Wochen. Einige Zeit wird wohl noch am Aufräumen der Software vergehen, einiges werde ich wohl auch noch reinbauen (Hard- als auch Software). Die Änderungen werden nur kleine Erweiterungen sein, die man ranlöten kann, aber nicht muß. @Sven Stefan (stepp64): einige Rams habe ich noch da, muß ich erstmal testen. Mein Bekannter sprach auch noch von einer Stange 32k 15ns. Da wir alle eher schon "alte Herren Club" tendieren, werfen wir wohl nicht so schnell weg. ;-)) Es müssen (ziemlich sicher) Cache-Rams sein, das Zugriffstiming normaler Rams ist teilweise merklich anders (Vorhaltezeiten usw.). Gruß aus berlin Michael
Michael U. schrieb: > > @Sven Stefan (stepp64): einige Rams habe ich noch da, muß ich erstmal > testen. > Mein Bekannter sprach auch noch von einer Stange 32k 15ns. > Da wir alle eher schon "alte Herren Club" tendieren, werfen wir wohl > nicht so schnell weg. ;-)) > > Es müssen (ziemlich sicher) Cache-Rams sein, das Zugriffstiming normaler > Rams ist teilweise merklich anders (Vorhaltezeiten usw.). > > Gruß aus berlin > Michael Naja, zu den jüngsten zähle ich mich mit 45 ja nun auch nicht mehr... Neu hatte ich solche Chips leider nie. Irgendwann habe ich mal den Boden aufgeräumt und alles was älter Pentium3 war weggehauen. Na egal. Würden denn diese hier gehen http://www.conrad.de/goto.php?artikel=167193 ? Gruß Sven
>kann man, machen ja auch einige, teilweise schon seit Jahren und nur >wenig teurer als ein fertig gekaufter und einige Projekte haben sogar >schon etwas Software... >Sorry, das mußte jetzt mal sein. Sowohl mein Bekannter als auch ich >haben ein wenig im Web gegrast und das war das Resultat dabei. Ich weiss jetzt nicht auf was du hinaus willst? Was soll fertig gekauft heissen? Welcher Preis? >Scheint also zwischen "kann man" und "mit wenig Aufwand" eine gewisse >Diskrepanz zu bestehen. :-) Ich bin verblüfft! Ich arbeite schon seit 15 Jahren mit FPGA's und weiss sehr gut, wie hoch der Zeitaufwand in der Entwicklung ist. Für einen Fortgeschrittenen kaum grösser als eine Schaltung aufgebaut mit diskreter Logik (und mehr wie den Fpga brauchst du nicht). Schick doch bitte mal die Links, die du "abgegrast" haben willst.
Hallo, Bishop schrieb: > Ich weiss jetzt nicht auf was du hinaus willst? Was soll fertig gekauft > heissen? Welcher Preis? Die billigsten USB-LA bekommst ab der 80 Euro-Grenze. Ist hier ja schon oft diskutiert worden. Wenn ich sowas unbedingt brauchen würde, hötte ich da vermutlich was gekauft. >>Scheint also zwischen "kann man" und "mit wenig Aufwand" eine gewisse >>Diskrepanz zu bestehen. :-) > Ich bin verblüfft! Ich arbeite schon seit 15 Jahren mit FPGA's und weiss > sehr gut, wie hoch der Zeitaufwand in der Entwicklung ist. Für einen > Fortgeschrittenen kaum grösser als eine Schaltung aufgebaut mit > diskreter Logik (und mehr wie den Fpga brauchst du nicht). Schick doch > bitte mal die Links, die du "abgegrast" haben willst. Fang doch hier im Forum an: http://www.mikrocontroller.net/articles/Logic_Analyzer Schau, was da geworden oder auch nicht gworden ist und wie da die Kosten sind. Beitrag "[S] Leute die einen Logic Analyzer (MiniLA) bauen wollen" überzeugt auch nur teilweise. Ich bin durchaus auch der Meinung, daß es mit einem FPGA prinzipiell kein Problem ist. Ich habe mich selbst aber damit noch nicht befastt und werde es zur Zeit auch nicht machen. Das nächste Problem dabei ist zwangsläufig die Software. Meine Vorstellungen müssen nicht die der Allgemeinheit sein, ich kann sie aber so verwirklichen. Es ist kein irgendwie professionelles Umfeld, ich will damit für meine Zwecke zurechtkommen. Wenn es anderen auch gefällt oder nutzt, umso besser. Ich zitiere hier noch aus Deinem ersten Posting: >Das soll wohl ein Scherz sein? Mit einem €20,- Fpga kann man mit wenig >Aufwand locker ein 50 kanaliges 500Ms/s Oszi nach diesem Prinzip bauen. >Zusätzlich könnte man noch 4 unterschiedliche Spannungshübe definieren. >Damit wären auch ADC's überflüssig. Sollte ich den im Netz übersehen haben, würde mich ein Hinweis freuen. Löte ich dann sicher zusammen, selbst, wenn ich da noch eine Leiterplatte fertigen lassen muß. Gruß aus Berlin Michael
Hallo, Sven Stefan schrieb: > Neu hatte ich solche Chips leider nie. Irgendwann habe ich mal den Boden > aufgeräumt und alles was älter Pentium3 war weggehauen. Na egal. Würden > denn diese hier gehen http://www.conrad.de/goto.php?artikel=167193 ? Sieht brauchbar aus, müßte ich mal das Datenblatt suchen. Schreib mir mal eine Mail. Eine Briefmarke finde ich sicher auch noch und schicke Dir dann mal 2-3 Stück. Gruß aus Berlin Michael
>Ich zitiere hier noch aus Deinem ersten Posting: >>Das soll wohl ein Scherz sein? Mit einem €20,- Fpga kann man mit wenig >>Aufwand locker ein 50 kanaliges 500Ms/s Oszi nach diesem Prinzip bauen. >>Zusätzlich könnte man noch 4 unterschiedliche Spannungshübe definieren. >>Damit wären auch ADC's überflüssig. >Sollte ich den im Netz übersehen haben, würde mich ein Hinweis freuen. >Löte ich dann sicher zusammen, selbst, wenn ich da noch eine Ich kenne den Preis für das (als Beispiel) MiniLa nicht aber geschätzte €100 für 10 Stück als Selbstlöter sind doch wohl sehr akzeptabel. Wenn du den verschmähst, dann kann ich mir kaum vorstellen, dass du €100 in eine 500 MS/s Version investiert hättest. >Leiterplatte fertigen lassen muß. Das teuerste ist imho die Platine und um die selbst zu ätzen oder anfertigen zu lassen wirst auch du nicht drumherum kommen. Eine aktzeptable Groundplane ist bei hohen Frequenzen (>20Mhz) unabdingbar. Sonst hast du ganz schnell mit Effekten zu tun (z.B. Doppelechos oder Zustandsverluste) die dich viel, sehr, sehr viel Analysezeit im Nachhinein kosten werden.
Hallo, Bishop schrieb: > Ich kenne den Preis für das (als Beispiel) MiniLa nicht aber geschätzte > €100 für 10 Stück als Selbstlöter sind doch wohl sehr akzeptabel. Wenn > du den verschmähst, dann kann ich mir kaum vorstellen, dass du €100 in > eine 500 MS/s Version investiert hättest. Die 100 Euro bei 10 Stück sind wohl beim MinLA auch der letzte Stand. Das sind beim MiniLA 100MS/sm warum sollte ich also nicht für gleiches Geld 500MS/s nehmen, nur wo? ;-) MiniLA kenne ich den letzten Stand /habe einfach nicht mehr alles gelesen. Probleme mit USB, Rams schwer beschaffbar (sind alte Cache-Rams aber auch), Stand der Software unklar, der ursprüngliche Programmierer hat wohl die Lust verloren, den Stand der anderen weiß ich jetzt nicht genau. 32 Kanäle und 128MB Samplespeicher sind sicher ok, brauche ich aber nicht zwingend. Ist doch eigentlich auch garkein Problem. Ich würde mir eher zutrauen, mit den nächsten TTL-ICs im interleaved Mode auf 2 Rams die 100MS/s auf Lochraster in Gang zu bekommen, als mich mit einem FPGA und fremden Sourcen rumzuplagen, wenn das Ding nicht macht, was es soll. Einfach, weil ich es nicht wirklich brauche. Nichtmal den selbstgebauten hier brauche ich wirklich. Ist einfach ein reizvolles Projekt, für RGB-LED-Fading und 32 PWM-Kanäle fehlt mir wohl einfach ein Nerv. ;-)) Gruß aus Berlin Michael
Einfach phantastisch. Genau sowas brauche ich und 8 Kanäle sind denke ich mal ausreichend. Damit kann man die gebräuchlichsten Schnittstellen erfassen (i2c, SPI, RS232) und für ein LCD reichts auch noch. Super. Mach weiter so.
Michael U. wrote: >Ich würde mir eher zutrauen, mit den nächsten TTL-ICs im interleaved >Mode auf 2 Rams die 100MS/s auf Lochraster in Gang zu bekommen, Hast Du dir eigentlich schon mal meine digitale Eingangsstufe angesehen? Die Idee einen Line-Receiver zu nehmen kam von Bernd G., aber der hat hier ja auch schon lange nichts mehr geschrieben...
Stefan Salewski schrieb:
> Hast Du dir eigentlich schon mal meine digitale Eingangsstufe angesehen?
Wo findet man die?
Halloe. Also ich finde die hier gezeigte Idee supi. Auch ich habe noch ein paar ungenutzte 486er's und ein paar Atmegas im Keller liegen und hier wird eine einfache Methode gezeigt sich einen durchaus für's Hobby geeigneten Analyzer daraus noch selbst zu bauen. Also vielen Dank, das Du deine Ideen mit uns teilst. Was mich wohl interesieren würde, wäre ein passendes PCB- Layout. Möglichst eines das einseitig bleibt und sich damit leicht im Hobbykeller noch selbst ätzen lassen würde. Ob sowas hier wohl überhaupt noch machbar wäre, oder geht das wegen der hochen Frequenzen einfach nicht mehr ? Ich würde für so ein Bastelprojekt ungern auf einen Platinenhersteller ausweichen müssen, weil der dann gleich richtig viel Geld von mir haben möchte. Einzelstücke machen zu lassen wird immer sehr teuer. Auch habe Ich noch nie mit der Fädeltechnik gearbeitet und glaube kaum, das ich den Drahtverhau so einfach hinbekommen würde. Freundliche Grüße Frank
Hallo, @Stefan Salewski (Gast): Gut möglich, wenn sie irgendwo im Netz liegt. Line-Receiver war bei mir auf schon mal auf dem Plan, liegt auch noch einges rum, was in Frage käme. @Frank (Gast): Einfach gesagt: von mir wird es mit 99% Wahrscheinlichkeit kein Layout geben, ich werde aber bestimmt keinen dran hindern und, wenn möglich, auch gern helfen. Ich habe die Teile mal im Eagle-Layout etwas rumgeschoben in Anlehnung meiner Anordnung. Ziemliche Probleme, die Leitungen zu sortieren... Wirklich kritisch dürfte der Datenbus des Rams wegen möglicher Störungen sein, die Adressen könnten bestenfalls etwas problematisch sein, die Zeitreserve ist da recht hoch. Ich rechne alelrdings auch bei den Daten nicht mit wirklichen Problemen, der 541 treibt da ja recht kräftig und wenn ein Pegelwechsel auf einer Datenleitung wirklich später als auf einer anderen am Ram ankommt, dann ist das 1 Zyklus Ungenauigkeit, das ist ohnehin unter der nutzbaren Auflösung der ganzen Geschichte (der Jitter durch den asyncronen Takt gegenüber den Eingangssignalen ist ja prinzipiell auch da). Man müßte jetzt erstmal den Kram entflechten, Daten und Adressen am Ram können ja beliebig angeschlossen werden, die Verteilung des Gatter bei der Triggerlogik kann in Grenzen auch umsortiert werden, prinzipiell sogar fast beliebig, wenn man notfalls im AVR eine LockUp-Table über die Bitzuordnungen von Maske und Wert ablegt. Der wird sowieso nie voll. Ich werde das aber nicht machen, das kostet mich einfach zuviel Zeit. Da müßte mindestens 1 Prototyp geätzt, bestückt und getestet werden, vielleicht auch mehr als einer, wenn es Probleme gibt... Da habe ich einfach schneller sowas auf Lochraster verdrahtet. ;-) Gruß aus Berlin Michael
Vielen Dank für deine Antwort. Die Idee, die Adress- und Datenleitungen bei bedarf umzulegen könnte wirklich helfen das geflecht zu entwirren. Daran hätte ich sicher beim Layouten nicht gedacht. Ich werde mich da mal ran machen und versuchen eine Platine zu Layouten. Wenn ich das ganze ans laufen bekomme, meld ich mich mal. Das kann aber etwas dauern, habe im moment ne menge anderer Sachen noch erstmal zu erledigen. Ich hab hier ein paar 64KB Cache Chips rumfliegen, die werde ich mal versuchen mit in das PCB Layout zu intregieren. Grüße Frank
Hi! Also beim Layouten kann ich ggf. auch mal helfen. Man müsste vielleicht zuerst abwarten, welche RAM Typen sich da durchsetzen. Andererseits war damals schon die JEDEC aktiv. Man konnte ja auch schon 8/16/32k große RAMs in ein und den selben Sockel stecken, musste halt immer Linksbündig sein. Hin und wieder kamen noch ein paar Jumper dazu. Für das Layout ist es bei den Datenleitungen absolut egal, welcher Kanal auf welchem Bit liegt, das muss nur nachher in der Anzeige-Software wieder aufgedröselt werden. Aber, es ist auch egal, an welcher Adresse ein Byte liegt. So lange sich entweder die Adressvertauschungen durch simple Mechanismen wieder korrigieren lassen oder der AVR mit den gleichen vertauschten Adressen die Daten ausliest, ist das egal. Gruß, Ulrich
Hallo, der AVR erzeugt zum Auslesen ja nur den Takt, die Adressfolge ist damit identisch. Günstig wäre es, wenn die Zuordnung der Datenbits zwischen AVR, Eingang und der Triggerlogik übereinstimmend ist, der Ram selbst ist egal, weil ja da die Daten so ruaskommen, wie sie reinkamen. Prinzipiell kann man auch die Bits beim Vergleicher usw. untereinander variieren. Da AVR ist si leer, daß man dort ohne Probleme jeweils eine 256 Byte LockUp-Table für Triggerbyte und Triggermaske hinterlegen kann. Bei den Daten am AVR könnte man es prinzipiell auch machen. Die 3 Tabellen wären ein 3/4 kB des Flash, zur Zeit ist 1k Flash belegt... Gruß aus Berlin Michael
Hallo, ich habe meine erste Version mal gering modifiziert: jetzt mit Mega16 bestückt und 80MS/s stabil. Änderungen liegen auf meiner Webseite: http://www.avr.roehres-home.de/logikanalyzer/index.html An dieser Variante wird sich außer kleinen Software-Korrekturen nichts mehr ändern. Die PC-Software wird noch zusammengeführt, so daß automatisch erkannt wird, welche Version dransteckt. Gruß aus Berlin Michael
Könnte man denn A12 vom RAM mit an einen µC Pin hängen? In der Windowssoftware könnte man dann zwei Seiten einbauen um z.Bsp. zwei getrennte Messungen miteinander zu vergleichen. Wäre das ohne größere Aufwände denkbar oder überschau ich da was noch nicht? Ansonsten müsste A12 doch sicher an GND, oder? Gruß Sven
wie ich sehe hast du 74ACT161 von fairchild genommen. Die gehen so 100 bis 160 mhz, nimm die von ST, die gehen bis knapp 300 mhz, sollte helfen bei der 80mhz version.
Hallo, Sven Stefan schrieb: > Könnte man denn A12 vom RAM mit an einen µC Pin hängen? In der > Windowssoftware könnte man dann zwei Seiten einbauen um z.Bsp. zwei > getrennte Messungen miteinander zu vergleichen. Wäre das ohne größere > Aufwände denkbar oder überschau ich da was noch nicht? Ansonsten müsste > A12 doch sicher an GND, oder? Könnte man machen. Werde ich nicht machen, weil kein Pin in der Mega16 Version mehr frei und in der Mega48 Version sind sowieso 4 Zähler und damit max. 64k Ram nutzbar. Eine solche Vergleichsfunktion könnte man aber in die Windows-Software einbauen, merk ich mir mal, der Gedanke gefällt mir. GND oder Vcc ist egal, wird eben die andere Ramhälfte benutzt. Thomas R schrieb: > wie ich sehe hast du 74ACT161 von fairchild genommen. Die gehen so 100 > bis 160 mhz, nimm die von ST, die gehen bis knapp 300 mhz, sollte helfen > bei der 80mhz version. Danke für den Hinweis, werde ich mal vermerken für evtl. Nachbauer. Ich vermute mal, daß ich an dieser Version erstmal nicht weiter an der Hardware ändern werde. Es kann aber sein, daß ich die Mega48 Version auch mit 80MHz laufen lasse, wenn die das mitmacht. Gruß aus Berlin Michael
Hallo, das Limit dürfte nicht alleine bei den Zählern liegen. Bei 80MHz hat man 12,5ns Zykluszeit, wenn der Takt schön symmetrisch aus dem Oszillator kommt sind das 6,25ns für das WE-Signal zum RAM. Laut Datenblatt brauchen die 12ns Cache-RAMs aber 8ns. Man braucht also ein gutes RAM oder einen Oszillator mit passendem (leicht unsymmetrischen) Tastverhältnis. Durch die unterschiedlichen Versionen ist das ganze ein schön flexibel nachbaubares Projekt: - kleiner ATMega mit Schieberegistern - großer ATMega - 16 und 20MHz CPU-Takt - 4 bis 16k RAM Da sollte die Software ebenso flexibel sein ;-) Es wäre doch schade, wenn man auf einer alten Version bleiben muss, weil man die V2 mit 20MHz CPU gebaut hat und die neueste Software eben die Zeiten für die 16MHz CPU drin hat. Falls ich mal eine Art Wunschliste schreiben darf: - Einstellung der Taktfrequenzen/Zykluszeiten in einer ini-Datei/Registry Das erlaubt den Einsatz verschieden getakteter CPUs und auch verschiedener Quarze. Wenn jemand nur bis 50MHz gehen will, weil nur ein langsames Cache-RAM rumliegt und ihm das ausreicht - kein Problem. - Einstellung der seriellen Schnittstelle incl. Baudrate statt fester Einstellung auf 500000. Es gibt doch diese netten USB-Implementationen in einem AVR, die hab ich bisher nur mit max. 384000 gefunden. Da könnte man einen Tiny2313 mit auf die Platine setzen und bekommt so die USB-Schnittstelle auch aus der Restekiste. - Einstellung der verwendeten RAM-Größe Ansonsten: weiter so! mfg Harri
Hallo, Harri schrieb: > das Limit dürfte nicht alleine bei den Zählern liegen. Bei 80MHz hat man > 12,5ns Zykluszeit, wenn der Takt schön symmetrisch aus dem Oszillator > kommt sind das 6,25ns für das WE-Signal zum RAM. Laut Datenblatt > brauchen die 12ns Cache-RAMs aber 8ns. Man braucht also ein gutes RAM > oder einen Oszillator mit passendem (leicht unsymmetrischen) > Tastverhältnis. Alles richtig, die beiden 8Kx8, die ich gerade zur Hand hatte, sind -12 und -15. Interessanterweise spielen beide bei den 80MHz ohne Probleme, Aussetzer oder falsche Bits wären gerade bei den Samples mit den Zählerausgängen an unsymmetrischen Signalen gut zu sehen. > Durch die unterschiedlichen Versionen ist das ganze ein schön flexibel > nachbaubares Projekt: > - kleiner ATMega mit Schieberegistern > - großer ATMega > - 16 und 20MHz CPU-Takt > - 4 bis 16k RAM 4-32k Ram, eigentlich bis 64k, übliche Cache-Rams waren aber ohnehin meist 8kx8 oder 8kx32. > > Da sollte die Software ebenso flexibel sein ;-) Soll sie. Es wird auf PC-Seite nur eine Version geben, zum Test war es nur einfacher, eine Kopie unter eigenem Namen zu benutzen. > Es wäre doch schade, wenn man auf einer alten Version bleiben muss, weil > man die V2 mit 20MHz CPU gebaut hat und die neueste Software eben die > Zeiten für die 16MHz CPU drin hat. Der Hardwaretyp wird ohnehin beim Softreset der Hardware abgefragt, auch Ramgröße, Firmware-Version und Hardware-Version werden mitgeteilt. Muß die Abfragen nur noch in die eigentlich Version einbauen und die internen Tabellen anpassen. > > Falls ich mal eine Art Wunschliste schreiben darf: > - Einstellung der Taktfrequenzen/Zykluszeiten in einer > ini-Datei/Registry Gibt es, alle Systemparameter werden abgelegt, bis jetzt eben nur die Com... ;-) > Das erlaubt den Einsatz verschieden getakteter CPUs und auch > verschiedener Quarze. Wenn jemand nur bis 50MHz gehen will, weil nur ein > langsames Cache-RAM rumliegt und ihm das ausreicht - kein Problem. So soll es sein. > - Einstellung der seriellen Schnittstelle incl. Baudrate statt fester > Einstellung auf 500000. Es gibt doch diese netten USB-Implementationen > in einem AVR, die hab ich bisher nur mit max. 384000 gefunden. Da könnte > man einen Tiny2313 mit auf die Platine setzen und bekommt so die > USB-Schnittstelle auch aus der Restekiste. Baudrate kommt noch, ich werde später mit 38400 initialisieren und dann zwischen AVR und PC-Software klären, wie schnell es gehen kann. Bleibt natürlich das Risiko, daß man den Kram vom USB trennen muß (bzw. AVR zurücksetzen), wenn man die beiden verheddert hat. ;) Auto-Baud im AVR wäre kein Problem, Platz ist genug, keine Lust dazu im Moment. ;) > - Einstellung der verwendeten RAM-Größe Wird wie gesagt von der Hardware mitgeteilt. Beim AVR wird es auch nur eine Software-Source geben, Unterschiede sind nut per defines bei assemblieren festzulegen. Geplant: Ram-Größe, Init seriell, Shift-Register oder nicht usw. Das mache ich so nach und nach. Da beide HW-Versionen so erstmal laufen, kann ja einer , der Lust zum Löten hat, entsprechend seinen Beständen schon anfangen. :) > Ansonsten: weiter so! Danke! Gruß aus Berlin Michael
@ Michael U. wäre es nicht sinnvoll, anstatt des 541 Buffers ein Latch zu benutzen (flanken- oder pegelgetriggert), dann wären die Daten für die gesamte Sampleperiode zum Ram als auch zur Triggerlogik stabil ? Gruss Frank
Hallo, möglich, müßte man aber das komplette Timing das Drahtverhaus in diesem Bereich erstmal genau analysieren oder einfach ein passendes suchen und raufstecken und das Signal passend vom /WE abgreifen oder so. Ganz praktisch sehe ich es nicht als wirkliches Problem an. Es tritt bisher ja nur im Grenzbereich auf, wo die Auflösung und der Jitter eine sinnvolle Auswertung schon fragwürdig sein lassen. Ich werde mich dafür vermutlich erst interessieren, wenn es mir im praktischen Betrieb mal auf die Nerven gehen sollte. ;-) Es fällt auch sofort auf, es werden ja keine falschen Signale angezeigt, nur die Triggerbedingung ist an der Markierung nicht erfüllt. Ich könnte das auch einfach in der PC-Software abfangen, und einen Fehler melden. Gruß aus Berlin Michael
Hallo > wäre es nicht sinnvoll, anstatt des 541 Buffers ein Latch zu benutzen > (flanken- oder pegelgetriggert), dann wären die Daten für die gesamte > Sampleperiode zum Ram als auch zur Triggerlogik stabil ? Ich löte schon an der Version 2 rum und hab dort ein 74ac574 Latch an Stelle des 74ac541 eingeplant. Die Durchlaufzeit des Latch liegt mit 5-8,5ns nur geringfügig über der des Buffers. Es latcht mit der steigenden Flanke vom RAM_WE. Diese Lösung müsste eigentlich bis knapp über 50MHz mitmachen. Für 80Mhz wären die 8,5ns im Worst Case schon zu lang, dann sind die Daten nicht am RAM wenn der WE-Puls kommt. Im Gegensatz dazu ist das Timing bei einem reinem Buffer absolut unkritisch, es werden ja einfach alle Signale gleich verzögert. Vermutlich sollte ich meinen Plan nochmal überdenken... So ein Cache RAM latcht laut Datenblatt ja auch: steigende Flanke WE, mit 9ns setup-Time und 0ns hold-Time. Das Latch würde nur diese Zeitspanne auf 2-3ns verkürzen. mfg Harri
Hallo, fein, daß Du schon lötest. :-) Das ist ja ds schöne an den Cache-Rams. Sonst würde das wohl garnicht so klappen. Falls Du das Latch drauf lötest denke dran, daß Du es irgendwie in TriState bekommen mußt, wenn der AVR-Reset auf L ist. Sonst kannst Du den nicht in der Schaltung programmieren, MISO und SCk hängen an D0/D1. Die könnte man allerdings inzwischen mit PB2/PB3 tauschen, nach dem letzten aufräumen in der AVR-Software wäre es ja nur statt des swap 2x lsr. Mache ich vielleicht sogar, dann kann Ram /CS fest auf L und /OE des Eingangsbuffers bekommt wieder einen PullUp. Was der Ram beim Programmieren macht ist egal, der AVR und der Buffer sind dann im TriState. Gruß aus Berlin Michael
Hi Michael, als ich das eben getippt habe fiel meine Entscheidung gegen das Latch :-) Die Tristate-Sache hatte ich beachtet. Nur deswegen musste ich neben einem CPLD für die ganze Logik noch zwei TTLs ('00 und '32) einplanen. Mir hatten am vorhandenen Lattice M4A5 ein paar Pins dazu gefehlt. Wird PB3 (MOSI) nicht auch zum flashen benötigt? Wenn das durch einen einfachen Pin-Tausch so funzt wie du schreibt, dann entfallen beide oben erwähnten TTL-Käfer. Das wäre echt super. Kannst du für die beiden Datenbits nicht auch PB0/PB1 oder PC0/PC1 nehmen? Dann muss gar nichts geshiftet werden, einfach die gelesenen Portbits zusammenführen. Wo die Schieberegister dran kommen düfte doch ziemlich Wurscht sein, oder? Meine Lötfortschritte wären noch weit genug am Anfang für eine derartige Änderung, hab erstmal nur die Chips platziert und die Versorgungsspannungen dran geführt. mfg Harri
Angehängte Dateien:
-
MiniLog1.png
42 KB
Hallo, PB1 wird für den Taktausgang des Timers gebraucht, da bringt Umsortieren eigentlich auch nicht viel. Am einfachsten ist ein Tausch mit PC0/PC1 aus. Hab das hier mal scshnell reingezeichnet. Gruß aus berlin Michael
Angehängte Dateien:
-
MiniLog2.png
25 KB
Hallo, die 2. Hälfte... Das Gatter IC9A könnte auch noch ersatzlos raus, müßte ich nur das IN_SELECT immer passend setzen, wäre auch kein Problem. Kannst ja mal rüberschauen... Gruß aus Berlin Michael
Mahlzeit, sieht prima aus. Wenn der AVR sicherstellt, dass nie RAM_Read und IN_Select gleichzeitig aktiv sind, dann kann IC9A durchaus entfallen. Bei flashen bzw. wenn Reset low ist schaltet der AVR alle Ausgänge auf Tristate, richtig? Dann müsste ich nur ein paar Pullups an die Ouput-Enables verteilen und kann einen weiteren TTL-Käfer rauswerfen. Der oben erwähnte '00 hätte dann nämlich nur noch diese Aufgabe. Gleichzeitig wird es durch entfernen von IC9A nachbaufreundlicher, man kann auch Input-Buffer mit nur einem Enable aus der Grabbelkiste nutzen. Ich hab noch einen ganzen Stapel '245er rumliegen :-) mfg Harri
Harri schrieb: > Bei flashen bzw. wenn Reset low ist schaltet der AVR alle Ausgänge auf > Tristate, richtig? Dann müsste ich nur ein paar Pullups an die So behauptet es zumindest das Datenblatt ;)
Hallo, ok. Ich ändere das mal heute Abend auf meinem Board und passe die Software an. Ansonsten auch richtig, PullUps wo nötig und ok. Genaugenommen auch nur dort, wo es stören könnte weil ein Ausgang gegen einen anderen kämpfen könnte. Ansonsten kann ja die Logik eigentlich machen, was sie will, wenn programmiert wird. Ist zwar etwas unfair gegen die ICs mit dann offenen Eingängen, aber was sind sie auch Logikgatter geworden.... ;-) @ Läubi .. (laeubi): meine AVr scheinen bisher auch ihr Datenblatt gelesen zu haben. ;-))) Gruß aus Berlin Michael
Ich habe den Logiktester jetzt verdrahtet und durchgetestet. << Vielen Dank nocheinmal an Michael U. (amiga) für dieses geniale und gleichzeitig einfach aufzubauende Konzept >> Der FTDI wird vom System erkannt - in der Software kommt aber nur "Hardware nicht erkannt". Liegt das an den Fuses? Speziell der Resetfuse. Muss ich diese verändern -. weil ja RAM_CS auch darauf läuft? Dass der Mega8 sich wegen der geteilten ISP nur extern programmieren läßt, wurde ja heute schon angesprochen und behoben. Hat sonst schon jemand den Logiktester am Laufen?
Hallo, Hardware nicht erkannt sagt erstmal nur, daß die gewünschte COM geöffnet werden konnte, vom AVR aber keine (sinnvolle) Antwort kam. Fuses auf externen Crystal, Rest bleibt unverändert, ich schau nachher nochmal genau rein und schreib sie dazu. Der AVR sollte sich in jedem Fall in der Scahltung von der Webseite auf dem Board programmieren lassen. Der Ram wird per Resetsignal des AVR beim Programmieren über IC9C TriState gesetzt, der Eingangsbuffer über IC9A/G2. Hast Du einen Mega48 oder Mega88 drauf? Das .hex ist vom Mega88, hatte keinen Mega48 zur Hand. Ich mache sonst nachher mal ein paar Debug-Ausgaben in die PC-Software rein. Die Meldung kann beides heißen: es kam garkeine Antwort oder es kam Unsinn (falsche Daten, falsche Baudrate). Fällt mir gerade nochwas ein: wenn Du die COM im Systemmenü auf Deine geändert hast, da speichern, PC-Programm beenden und wieder aufmachen. Da ist in der Fehlerbehandlng nochwas unklar. Gruß aus Berlin Michael
aha! Ich habe ein mega8 drauf- also muss ich mal meinen assembler-compiler anschmeissen. Gibt es eine Möglichkeit die VB-Sources auf Linux laufen zu lassen bzw. machst Du diese öffentlich? Würde versuchen sie unter Mono laufen zu lassen. Mein Windows will ich eigentlich gar nicht mehr anschmeissen.
Hallo, der Mega8 läuft offizell nicht mit 20MHz und außerdem sind die Timer und UART-Register beim Mega8 im normalen I/O-Bereich, also mit in und out statt lsd/sts anzusprechen. Schnellst Version: mega8 statt mega88 in Lola.asm eintragen und Build. Namen der USART-Register anpassen und gleich die sts/lds-Zugriffe in in/out ändern. Dann in der m8def.inc vorübergehend alle Timer1-Registernamen auskommentieren (die stimmen wohl mit dem Mega88 überein) und Build. Alle Fehlerstellen wieder lds/sts durch in/out ersetzen. Kommentare der Namen wieder raus und Build sollte durchlaufen. Zum Testen könnte man ihn mit 16MHz (8MHz gehen zur Not auch) takten (F_CPU in definition,inc anpassen). Dann sollte er sich zumindest melden. Die Timings und die Darstellung stimmt dann aber nicht. Einfacher ist es vermutlich, einen Mega48 oder Mega88 zu nehmen... Die VB-Sourcen rücke ich erst raus, wenn halbwegs Ordnung drin ist... Das kann noch ein paar Tage dauern. Das Protokoll ist simple: dem AVR der Reihe nach Mode (in den Tabellen der AVR-Source ist die Bedeutung gut zu erkennen) Triggerbyte (zu ignorierende Bits auf H) Triggermaske ((zu ignorierende Bits auf H) Timerintervall (0...14, Belegung siehe AVR-Source Tabelle) Pre-Trigger (1...8, 8 Trigger sofort, 1 87,5&, 7 12,5%) Dann startet die Suche nach dem Triggerbyte. Wenn die Daten komplett sind, schickt der AVR kommentarlos den kompletten Raminhalt. Jedes beliebige Zeichen, daß während der Warte-/Samplephase zum AVR heschickt wird, bricht den Vorgang ab, der AVR schickt trotzdem den Raminhalt. Man kann also sicher auch eine andere Software basteln oder nutzen. Gruß aus berlin Michael
Hallo, Frage in die Runde: wer lötet oder routet denn schon alles an der Mega48/88-Version? Wäre es ein Problem, die Änderungen, die sich ab Posting von 07.07.2009 12:19 ergeben haben, einzubauen und die bisherige Version von meiner Webseite zu nehmen? Es betrifft wie angegeben den Tausch von D0/D1 gegen SHIFT_CLOCK/SHIFT_DATA, dem damit zusammenhängenden Wegfall von IC9A und IC9C sowie der Leitung zum AVR-Reset. G1 vom 74AC541 kann dann entweder an G2 oder fest an Vcc. G1 bekommt noch einen PullUp (10k). CS vom Ram geht fast an GND. /OE vom Ram braucht dann auch noch einen 10k PullUp. Ich teste die Änderungen mal an meinem Muster und kontrolliere, ob die AVR-Firmware da passt. Eigentlich müßte da auch jetzt schon der 74AC541 nur freigegeben werden, wenn gesampelt werden soll. Es ist auch günstiger (wie bei der 80MHz-Version) ENP der 74ACT161 fest auf Vcc stann an ENT zu legen, falls man auch hier sein Glück mit 80MHz versuchen will. Zu den Zählern gab es noch einen Hinweis von Thomas R. (tinman): wenn möglich 74ACT161 von ST zu benutzen, sollen merklich schneller als die Fairchild sein. Gruß aus Berlin Michael
@Harri > Die Tristate-Sache hatte ich beachtet. Nur deswegen musste ich neben > einem CPLD für die ganze Logik noch zwei TTLs ('00 und '32) einplanen. > Mir hatten am vorhandenen Lattice M4A5 ein paar Pins dazu gefehlt. Du hast mit nem CPLD angefangen ?? Das habe ich auch vor. Bzw. ich habe schon angefangen. siehe Tread im FPGA Forum.... Beitrag "wie groß muß das CPLD ungefähr sein ?" Bin allerdings noch nicht wesentlich weiter. Nach groben Schätzungen sollte ein 9574 ausreichen.(Xillinx). Allerdings hatte ich in meiner Idee schon einen Oszillator mit X Mhz drin. (80 angepeilt) mit unterschiedlichen Abstufungen. Jetzt hat Micha das auch schon drin. Ein Design mit Abel gibt es ja schon. Ist jetzt aber schon wieder "veraltet". Vielleicht können wir zusammen etwas tun...(habe momentan wenig "Freizeit" ) Gruß
Hallo Micha, ich versuche mich ja noch immer am CPLD. Aber ich denke die meißten machen einen "Single Shot", ähnlich wie Du. Nur ist Deiner flexibel (Lochraster). Ich denke alles was das Design besser macht ist erlaubt. Ist doch Dein Projekt. Ergo Deine Entscheidung.... Die Cache RAMS gabs aber auch mit 8ns. Ich habe noch welche. 256 KBit 486er...Kleinstmengen !!
Hallo, ich habe die Flexibilität meines Lochrasters mal genutzt und die oben erwähnten Änderungen eingebaut. Läuft ohne Probleme. Pläne und Software lege ich morgen auf die Homepage. 2 der freien Gatter werden wohl bei mir als Takttreiber herhalten und die beiden gegenphasigen Takte nach außen legen. Für evtl. Erweiterungen zum Anstecken. Flash-Wandler z.B. ;-) Ich habe ja auch noch einen 14-pin-Sockel frei drauf für den externen Triggereingang. Außerdem sind noch 2 AVR-Pins frei... Wenn uns nicht noch kurzfristig geniale Verbesserungen einfallen, bleibt der Zustand auch dieser Hardware damit erstmal als endgültig und ich mache die Software weiter. Stephan Henning (stephan-): ich habe Tread im FPGA Forum mal überflogen. Hmmmm, ich halte mich da mal vornehm zurück..... ;-))) Gruß aus Berlin Michael
Hallo zusammen! Stephan Henning schrieb: > Du hast mit nem CPLD angefangen ?? Das habe ich auch vor. Ja, ich hab mal meine Planungen angehängt. Den CPLD fülle ich per Abel Quellcode, damit (sowie mit Lattice-PLDs) hatte ich vor langer Zeit schonmal was gemacht. Ob das so wie im Anhang dargestellt überhaupt funzt kann ich allerdings noch nicht sagen ;-) Vermutlich gibt es auch viel elegantere Lösungen. Das Bild zeigt meine Platine, bisher sind nur die Versorgungsspannungen gelegt und nachgemessen. Der Rest fehlt noch. Kurze Beschrebung wegen unscharf: Links oben 80MHz Oszillator und ein Teiler mit 74F74 Flipflop, ich gehe dann mit schön symmetrischen 40MHz zum CPLD. Darunter ein 74F245 Input-Puffer, kein Latch mehr. Mitte oben CPLD Lattice M4A5-64/32, dann das RAM 32k mit 15ns, unten ein ATMega 8/16. Die beiden Sockel rechts bleiben nach der heutigen Änderung frei, die löte ich wieder runter. Rechts ist derzeit noch ein 16MHz Oszillator für den AVR-Clock. Der wird später auch im CPLD von den 80MHz abgeleitet, das Pin dazu ist reserviert (und gleichzeitig das letzte freie ;-) Externen Takt sehe ich vor, externen Trigger nicht - war mal drin als die beiden TTL-Chips rechts noch benötigt wurden. Schaltplan ist im Anhang. Die 40Mhz Maximaltakt hatte ich gewählt weil der 80er Oszillator rumliegt (hoffentlich funzt er auch) und ich nur Cache-RAMS mit 15ns habe. Ob 50 oder 66 auch funktionieren kann ich dann ja mal mittels externem Takt probieren. Wo gab es denn das PLD-Design in Abel? @Micha: schön, dass du heute auch gleich die Änderungen für den ATMega8 beschrieben hast. In diese Falle wäre ich nämlich am nächsten Wochenende reingetappt :-) mfg Harri
>MiniLA kenne ich den letzten Stand /habe einfach nicht mehr alles >gelesen. >Probleme mit USB, Nicht mehr. Das lag am Multiplexer. >Rams schwer beschaffbar (sind alte Cache-Rams aber auch), Leider nach wie vor problematisch. >Stand der Software unklar, der ursprüngliche Programmierer hat wohl die >Lust verloren, Es tut sich nicht mehr viel, das ist richtig. Sie funktioniert aber ganz gut, so dass man auf jeden Fall damit arbeiten kann.
Hallo, @Michael K.: Danke für die Info. Gruß aus Berlin Michael
Hallo, erst mal finde ich dein Project super, habe schon vor einem halben Jahr mal nach LA Schaltungen auf AVR Basis gesucht, welche alle nicht der Brüller waren. Als ich gestern hier in Forum über dein Project gestolpert bin habe ich mich direkt verliebt... Hier nun meine Frage: ich habe noch ein paar alte 2,3,486 Boards im Keller rumfliegen... Du verwendest die Chips von den RAM-Riegeln? Wenn ja woran erkenne ich ob die Teile die passenden Timings haben? Gruß Patrick
nö, die Cache IC´s. Nich die IC´s von den Dimm Modulen. Gesucht sind die einzelnen "langen" IC´s. zB. W24257. Aber Vorsicht, auf 2 und 386érn sind die "normalen" DRAM auch manchmal noch einzelne IC´s ! Aber die sind kürzer. Die "richtigen" haben 28 Pins bei 7,25 mm Abstand zwischen den Pinreihen !!
zB. hier 386ér bei Cache http://stason.org/TULARC/pc/motherboards/C/CORE-PACIFIC-ELECTRONICS-INC-386-386-MAINBOARD.html oder 486ér http://stason.org/TULARC/pc/motherboards/S/SOYO-COMPUTER-CO-LTD-486-486-MAINBOARD.html
Es gibt immer noch schnelle SRAMs, guck mal bei CSD, der hat welche mit 12ns.
@Stephan Danke, werde gleich mal im Keller suchen gehen... @Michael U. Habe deine LAs mal im Wiki eingepflegt und würde dich bitten mal auf Korrektheit drüber zu schauen oder zu löschen wenn's dir nicht passt http://www.mikrocontroller.net/articles/Logic_Analyzer
Hallo, Danke für die Blumen. :-) Nein, nicht die von den Ram-Riegeln. Externer Cache in passender Version war auf den letzten 486er (486DX2..DX4) und den AMD K5/K6 usw. drauf. Sind DIL28 üblicherweise zu 8 Stück + 1x TAG-Ram der nicht immer bestückt war. Ist eben auch bei mir schon ziemlich lange her mit diesen Boards... Bezeichnungen enden oft mit xx64-yy oder xx65-yy oder xx256-yy und xx257-yy xx Hersteller eigene Bezeichnung, 64/65 sind 8kx8, 256/257 32kx8. Hinter dem Strich dann die Zugriffszeit. Üblich -12/-15/-20/-25. Sind jeweils Nanosekunden. 25ns ist vermutlich zu langsam bei 50MHz, für die 80Mhz sollten es 12ns sein, 15ns läuft hier aber auch noch. Ich sortiere demnächt mal meine Vorräte, ein Bekannter hat auch noch was aufgehoben. Falls dann jemand keine findet, läßt sich da auch was machen. Irgendwo oben hatte jemand einen Link zum großen C gepostet, die sollten gehen. Allerdings stört mich da, dsß laut Typenbezeichnung -20 gelich -12 sein sollen und in den Daten an der Seite dann 15ns steht..... Gruß aus Berlin Michael
Bei CSD-electronics gibt es das IS61C256AL-12JLI für 2.15 EUR.
kann ich auch sram wie 62256 nehmen? ( z.b. K6R1008C1D-JC10 ist 128Kx8 10ns ) oder muss es asynchrones cache sram sein ?
grundsätzlich würde der 62256 "funktionieren".... ABER
Der ist viiiiiiel zu lahm. 70 ns oder langsamer.
Außerdem hat der 15 mm Pinreihenabstand.
> K6R1008C1D-JC10
Ich denke der sollte gehen.
Bei Mercateo gibt es auch noch 32kx8 12ns von Lyontek http://www.mercateo.com/p/live~s.0*115-648331/LY61256DL_12_DIL28_SRAM_High_Speed_32k_x_8.html Die sollten doch auch gehen, oder?
Hallo, hab jetzt auf ner alten Soundblaster nen KM416C256BJ-7 gefunden Laut Datasheetsuche: KM416C256D=256K x 16Bit CMOS Dynamic RAM with Fast Page Mode Würde der gehen? Alternativ habe ich 8Stk Alliance AS7C256-20PC gefunden?!
Hi Patrick
Patrick Weggler schrieb:
> Alternativ habe ich 8Stk Alliance AS7C256-20PC gefunden?!
Die würden gehen, vermutlich bis 40Mhz, mit Glück bis 50MHz
Kleiner Tip: unbekannte Bauteile bei www.alldatasheet.com eingeben
Dort finde ich meistens ein Datenblatt oder einen Hinweis auf das Teil.
Für diesen LA wird "High Performance SRAM" benötigt. DRAM oder normales
SRAM mit 70ns ist ungeeignet.
mfg
Harri
Die speicher geschwindigkeit beschreibung ist etwas 'unglücklich'. Bei normallen srams ist die bezeichnung -10, -12, -15 , -20 eher ein 100, 120, 150 oder sogar 200ns - vor allem beim älteren modellen. Bei "cache" sram jedoch bedeutet -12 genau 12ns. Ich habe hier aber auch "normalles" srams die mit 10ns gehen, also immer datenblatt suchen und gucken was da drin steht.
Hallo, so, ich habe jetzt mal meine Kiste mit Rams durchgekramt. Dabei ergab sich noch eine Erkenntnis: Kritisch ist das Timing der Adresszähler im Zusammenhang mit der Betriebsspannung. An meinem alten Thinkpad mit passiven USB-Hub dazwischen gibt es Aussetzer bei 80MHz. Es zählen manchmal nicht alle ACT161 mit. Am USB des großen Rechners gibt es das Problem nicht, Betriebsspannung vom USB ist da auch nahe 4,8V, am Laptop nur rund 4,6V. Ich werde mir wohl doch mal ACT161 von ST besorgen und testen. Grundsätzlich: 12ns bei 80MHz sind mehr oder weniger Pflicht, 15ns geht wohl nur Exemplarabhängig, 20ns geht mit 50MHZ, 25ns mit 40MHz. Das Verhältnis zu den Zyklszeiten der Rams passt also sehr genau und quer durch alle Hersteller, die ich hier habe. Bei anderen statischen Rams wird wohl nur ein Versuch entscheiden, das Zyklus-Timing der Cache-Rams ist anders als das üblicher statischer Rams. Ich habe bei der 80MHz-Version noch so umgelötet, daß beide Versionen sich nur noch im Prozessor und den 74LS164 und dem Takt unterscheiden. Es spricht nichts dagegen, die Version mit dem 40-Pin AVR mit 50 und 20MHz Oszillatoren ohne den 74ACT74 zu bestücken oder umgekehrt. Wenn man 80MHz und Teiler draufhat und der Ram oder der Aufbau ungünstig ist un nicht mit 80MHz will, kann man das eben einfach ignorieren und hat max. 40MHz oder man ersetzt den Takt durcuh die andere Version und hat max. 50MHz. Die AVR-Quellen führe ich als nächtes zusammen, die jeweilige Version ist dann leicht einzustellen und neu zu assemblieren, von den Versionen, die ich hier selbst zumindest getestet habe, lege auch die Hex-Files ins Archiv. Ich kann auch noch ein paar Rams, allerdings im Moment nur 20ns, abgeben, falls jemand nichts auftreibt. Ob ich noch schnellere bekomme entscheidet sich erst am Wochenende. Schaltpläne kommen noch heute auf die Webseite, AVR-Files vermutlich morgen. PC-Programm ist noch getrennt und nur für meine beiden Versionen, das wird aber auch noch zusammengeklebt. ;-) Gruß aus Berlin Michael
Angehängte Dateien:
-
Interferenz.jpg
110 KB
Hallo, lustiger Nebeneffekt: Samplerate 80MHz, Signale von einem mit einem anderen 80MHz Quarzoszillator mit einem 74HCT4040 runtergeteilt. Kanal 0 ist der 40MHz Takt, links sieht man die Interferenz zwischen Sampletakt und Daten, wenn sie fast phasengleich sind. Die Durchgänge erfolgen etwa alle 15s, wer Lust hat, kann jetzt die relative Frequenzdifferenz zwischen den beiden Oszillatoren ausrechnen. ;-) Die Unregelmäßigkeiten in Kanal 3 und 5 sind nur Skalierungsfehler, dort sind die Signale vollig ok, ich habe aber extra nicht gezoomt. Gruß aus Berlin Michael
Hallo, hab jetzt mal bei Farnell 2 Gefunden (leider TSOP-2) http://de.farnell.com/gsi-technology/gs71108agp-12/1mb-asynch-sram-128k-x-8-12ns-smd/dp/1447513 http://de.farnell.com/gsi-technology/gs71108agp-10/1mb-asynch-sram-128k-x-8-10ns-smd/dp/1447510 Der 2te wäre sogar 10ns Version Gruß Patrick
Hallo, wer ein Ram im SDIP sucht, kann auch den CY7C199C-15 (32kx8) nehmen, den U. Radig http://www.ulrichradig.de/ in seinem AVR-DSO eingesetzt hat. (Kostet in seinem Shop ~5€)
Falls wer den oben genannten RAM benötigt. Ich habe noch 5 unbenutzte Exemplare. 3.3€ + Versand. Bei Interesse: PM
Halloe. Bei der 2. Schaltung von Dir ist mir noch eine Ungereimtheit im 2. Schemabild aufgefallen. Dort wird die Adressleitung A14 zusammen mit OE am SRAM über das Signal "RAM_READ" gesteuert. Das würde je bedeuten, das man beim wechsel von Schreiben auf Lesen auf die jeweils andere Hälfte des Rams umschalten würde. Ich denke mal, du wolltest die Addressleitung nicht an RAM_READ anschließen, sonden auf einen definierten Pegel (GND/VCC?) bringen ? Grüße Frank
Hallo, danke für den Hinweis, da legen doch falsche Pläne oben...... Der fehler ist reingekommen, weil cih z.Z. ja noch mit 16k arbeite, zum Wochenende werde ich aber die PC-Software da auch angepasst haben, dann gehen auch die vollen 32k und der jetzige Plan stimmt dann auch. PS: warum muß ich bei Firefox erst den cache löschen, damit er mir den richtigen Inhalt der Seite anzeigt??? Ein erzwungener Reload sollte doch eigentlich reichen? Gruß aus Berlin Michael
Ich habe mal alle Hardware versucht in ein CPLD Design zu stopfen: Beitrag "Re: wie groß muß das CPLD ungefähr sein ?" Dabei habe ich mir allerdings eine Frage gestellt: Wie syncronisierst du das ganze? Die Zähler werden ja nirgends zurückgesezt, und ne Art Feedback 'TimerOverflow' oder so konnte ich auch nirgends entdecken. Machst du das in SW?
Das habe ich mich auch schon gefragt. Irgendwie muss das ganze doch zumindest auf einen gemeinsamen Start synchronisiert werden? Sven
also ich nehme an das die Zähler sich alleine nullen beim Einschalten, und dann läuft alles genau 1 Mal durch und steht dann bei 0. Mal sehen was Micha dazu sagt..
Naja das Problem ist bei 80Mhz "Haupttakt" muß der AVR auch rechtzeitig wieder stoppen um nicht die ersten Ergebnisse wieder zu überschreiben... Ansonsten ist der StartWert des zählers (relativ) egal.
Hallo, genau, der Startwert ist eagl und auch nicht bekannt. Takt freigeben und sampeln bis in alle Ewigkeit als Ringbuffer. Der AVR weiß, wieviel % als Pretrigger gewünscht sind und damit, wieviel Ram vor dem Triggerpunkt und wieviel dahinter liegen sollen. Im AVR wird dieser Anteil als Teil der Speichergröße und abhängig vom Sampletakt und der konstanten Laufzeit der Warteschleife im AVR in ein Register geladen. Dann wird nur abgefragt, ob der Trigger aktiv wurde. Ab da wartet der Atmel in besagter Schleife die nötige Taktanzahl ab, bis das relative Ende im Ram erreicht sein müßte und stoppt den Sampletakt. Bei Raten, die langsamer als die Laufzeit im AVR sind, zeigt der Zähler dann auf den relativen Ramanfang. Der Raminhalt wird ab da in voller Länge zum PC gschickt, der weiß ja auch, wo er den Triggermarker hinmalen muß. Problematisch sind alle schnelleren Sampleraten. Hier ist eine Ungenauigkeit in Länge eines Schleifendurchlaufs * Samplerate/AVR-Takt drin. Die PC-Software sucht jetzt einfach im Bereich -xxx bis +xxx so die Triggerbedingung genau aufgetreten ist und setzt da den Marker. Bei vollem Bereich wird wird etwas anders verfahren, damit er nicht in eine mögliche Überlappung mit dem Ende reingerät. Es werden deshalb auch nur 4000 bzw. 16000 Sample dargestellt, der Rest zu 4096 bzw. 16384 ist meine stille Reserve für solche Fälle. Die grundsätzliche Idee dazu stammt aus den LoLa-Sourcen, allerdings hatte er das Problem nicht, weil er die Triggerbedingung per Software auswertete und die Steuerung komplett der AVR machte (nur recht geringe Sampleraten). Gruß aus Berlin Michael
@ Michael U.: weil du mal über den virtuellen COM-Port Treiber spekuliert hast, ich hab hier nen ATMega128L @ 8MHz mit nem FTDI232RL mit 500.000 Baud verbunden. Geht absolut ohne Probleme, zumindestens mit "Terminal v1.9b" als Kommunikator ;-) Wollte auch eigentlich 1M Baud einstellen, hab ich bis jetzt aber leider noch nicht zum laufen bekommen. Ich denke aber das das FTDI und AVR@8MHz eigentlich können sollten... @ All: Hat irgendjemand schonmal mehr als 500.000 Baud über die serielle gefeuert?
Ja, 3MBaud mit dem XMega128-A1 und dem FT232RL. Mit einem auf 24MHz übertakteten Mega644 oder ähnlichen Typen sollte das im DoubleSpeed-UART-Modus auch gehen. Der PC ging dabei allerdings leicht in die Knie und ich mußte Hardware-Handshaking benutzen, damit nichts verloren geht.
@ Travel Rec.: Hast du zur Kommunikation auf die 'virtual'-COM-Port Treiber zugegriffen oder direkt Routinen aus der FTD2XX.DLL verwendet?
VCP. Geht wunderbar.
Habe den Logicanalyzer soweit fertiggestellt- nun mit einem mega88 (jetzt kenne ich endlich den Unterschied zum Mega8). Nur die minilog Installation unter Windoof bringt mich zur Verzweiflung. Die VB_bootsstrap setup.exe meckert zu alte *.dlls an (obwohl ich zuvor die VB6.0 runtime installiert habe). Während der minilog-Installation können die dlls nicht aktualisiert werden, weil diese in Benutzung sind (klar). Also die dlls aus der MiniLog extrahiert und (unter Linux) in \w\system32 kopiert, was mich aber auch nicht weiterbringt. Jetzt wird eine "invalid line" in der setup.lst angemeckert, nämlich diese: "@UART.mlp,$(AppPath),,,6.20.09 10:51:41 AM,97,0.0.0.0". Ist wahrscheinlich die Schnittstelle zur UART? Die extrahierte miniLog_application alleine kann ich zwar aufrufen, sie kann aber nicht mit der Hardware kommunizieren -> "keine hardware gefunden". Wie gehe ich weiter vor? Wer hat Minilog schon unter XP installiert. Wie kann man es nach Linux portieren? z.B. unter Mono?
min schrieb: > Habe den Logicanalyzer soweit fertiggestellt- nun mit einem mega88 > (jetzt kenne ich endlich den Unterschied zum Mega8). Nur die minilog > Installation unter Windoof bringt mich zur Verzweiflung. nicht win sonder meistens userdoof ... >Die > VB_bootsstrap setup.exe meckert zu alte *.dlls an (obwohl ich zuvor die > VB6.0 runtime installiert habe). Während der minilog-Installation können > die dlls nicht aktualisiert werden, weil diese in Benutzung sind (klar). > Also die dlls aus der MiniLog extrahiert und (unter Linux) in > \w\system32 kopiert, was mich aber auch nicht weiterbringt. Jetzt wird > eine "invalid line" in der setup.lst angemeckert, nämlich diese: > "@UART.mlp,$(AppPath),,,6.20.09 10:51:41 AM,97,0.0.0.0". > Ist wahrscheinlich die Schnittstelle zur UART? lol ... falls du vb6 runtimes schon drauf hast, dann brauchst nix ausser der minilog.exe - einfach aus der cab entpacken und benutzen > Die extrahierte miniLog_application alleine kann ich zwar aufrufen, sie > kann aber nicht mit der Hardware kommunizieren -> "keine hardware > gefunden". com ist richtig ? hardware richtig ? app richtig ? Daws hat nix mit dem setup zu tun. > > Wie gehe ich weiter vor? Wer hat Minilog schon unter XP installiert. > Wie kann man es nach Linux portieren? z.B. unter Mono? war mono nicht .net ? VB6 hat mit .net nix zu tun. Und zu deiner frage, portieren ? Zum portieren brauchst du sources - die es noch nicht gibt - also du mienst 'starten' unter linux ? Ich würde sagen frag google,andereseits linux ist linux, windows ist windows - wenn etwas nciht geht wirst du halben tag suchen nach den fehlern. Da du anscheinend XP da hast starte doch da - und warte bis die sources verfügbar sind - dann kannst du es portieren für alle die ohne umwege unter linux benutzen möchten.
Wozu ist die UART.mlp, RFM12 (funkmodul??) und stdole2 gut, die müssen doch mitinstalliert werden? [Setup1 Files] File1=@UART.mlp,$(AppPath),,,6.20.09 10:51:41 AM,97,0.0.0.0 File2=@RFM12.mlp,$(AppPath),,,6.20.09 10:50:50 AM,108,0.0.0.0 File3=@MiniLog.ini,$(AppPath),,,6.20.09 11:08:03 AM,3,0.0.0.0 File4=@comdlg32.ocx,$(WinSysPath),$(DLLSelfRegister),$(Shared),12.1.08 1:00:00 AM,152848,6.1.97.82 File5=@MSCOMM32.OCX,$(WinSysPath),$(DLLSelfRegister),$(Shared),3.17.05 2:12:46 PM,103744,6.0.81.69 File6=@MiniLog.exe,$(AppPath),,,6.20.09 7:47:04 PM,114688,1.0.0.0 ? Nachwievor - die SETUP routine hängt: "setup cannot install system files or update shared files if they are in use". Com5 ist mein FTDI232 USB Port und der ist eingestellt auf 115200 baud. Der loop test funktioniert. Die fuses Osc. ist auf extern gestellt und den Teiler /8 habe ich rausgenommen. Das Programm ist natürlich im mega88. Die Hardware habe ich zweimal mit dem Durchgangsprüfer geprüft. Wähle ich nun in der minilog.exe den COM5 aus, wird keine HW erkannt.
ehm, woher hast du die setup ? Also auf der site http://www.avr.roehres-home.de/logikanalyzer/index.html unter software gibts nur zwei "PC Software" versionen. Die beinhalten: - vb bootstrap - notwengid falls nicht vorhanden - mscomm32.ocx - com port api - comdlg32.ocx - common dialogs api - und die app selber MiniLog80.exe oder MiniLog.exe je nach dem welche verison du nimmst. So sag mir jetzt welche software du nimmst, und woher, das du da auch 'andere' sachen drin hast.
Naja - die Software habe ich auch von dieser Seite. Vielleicht habe ich eine ältere Version erwischt. Die UART.mlp und RFM12.mlp scheinen Steuer-Daten von einer Messungen zu sein. Habe mir nocheinmal die neuen Programme gezogen und probiers nochmal. Die mscomm32.ocx und comdlg32.ocx Module fehlen mir. Müssen die nach \windows\system32\ ?
min schrieb: > Naja - die Software habe ich auch von dieser Seite. Vielleicht habe ich > eine ältere Version erwischt. > Die UART.mlp und RFM12.mlp scheinen Steuer-Daten von einer Messungen zu > sein. > Habe mir nocheinmal die neuen Programme gezogen und probiers nochmal. > Die mscomm32.ocx und comdlg32.ocx Module fehlen mir. Müssen die nach > \windows\system32\ ? so grob erklärt , aus der setup.lst : [Setup1 Files] File1=@comdlg32.ocx,$(WinSysPath),$(DLLSelfRegister),$(Shared),12/1/08 1:00:00 AM,152848,6.1.97.82 "WinSysPath" ist %system32%, sprich die system32 der windows installation. "DLLSelfRegister" ist anweisung um die ocx zu registrieren, das macht der setup, du kannst unter windows es auch machen mit regsvr32 "Shared" ist anweisung zum shared dll's registrierung, die version/datum die danach kommen sind für versionskontrolle.
Hallo, wenn er die Hardware nicht erkennt ist die Installation erstmal ok, sonst kommt er nicht soweit. Fuses vom Mega88 auch richtig gesetzt, so daß er mit dem Quarz-Takt läuft? Richtige COM ausgewählt? An dieser Stelle habe ich eigentlich nichts geändert, allerdings sollten die Files von AVR und das VB-Programm am gleichen Tag von der Wegseite gezogen worden sein sonst kann es Probleme geben. Heute ist es zu spät, ichte teste mirgen hier nochmal gegen und lege den aktuellen Stand von allem auf die Homepage. Die VB-Software gibt es dann nur noch in einer Version, sie erkennt die Hardware alleine. An der Hardware-Version mit dem Mega48/88 mit 50/20MHz Oszillatoren hat sich zwar was verändert, allerdings nichts, was die aktuekken Funktionen betrifft. Für eventuelle Erweiterungen wäre es aber sinnvoll, das nachzuvollziehen, wenn es nicht auf einer Leiterplatte wohnt. Ich fass dann auch die Änderungen nochmal als Text zusammen. Ich mache auch mal eine Debug-Version der Software zurecht mit ein paar mehr Meldungen, das wird aber erst Sonntag was. Zusatzmodule vom VB kommen im Moment nicht rein, wenn das Programm sich meldet ist die MSComm installiert und registriert, dann braucht nur die .exe ersetzt werden. Ich werde auch die noch einzeln dazulegen. Das Problem mit den angeblich falschen DLLs hatte ich auf einem Rechner auch, habe nicht ergründet, woran es lag, das Programm selbst lief. Muß ich mal nachschauen, woran das liegt. Gruß aus Berlin Michael
Hallo Michael, mit der aktuellen Softwareversion muss ich auch die Änderungen bezüglich PB2 PB3 umlöten. Werden diese Pins dann frei bzw. bleiben nur noch mit der ISP verbunden? Kann ich mit der Geschwindigkeit der Abtastrate zum Testen einfach mal auf etwa 30 MHz heruntergehen, indem ich nur die Definitionen.inc ändere und einen entsprechenden Quarz oder Teilerbaustein einbaue. Gibt es Interferenzeffekte, wenn ich den AVR auf 20MHz und den Rest auf 40Mhz laufen lasse. Ich habe nämlich nicht alle Bausteine in der 74AC Version und habe sie deswegen mit 74HCxx gemischt. Auch ein 74F wurde verbaut. HC32 habe ich bei Dir auch gesehen. Wie kritsch ist das in der 50 MHz-Version? 74HC kann soweit ich weiss nur bis 40 MHz. Wo bekommt man 74ACTxxx? Warum ist die UART auf 500000 und nicht auf 460800 baud? Ich nehme an die PC-Software regelt sich da automatisch ein. Brauche ich dafür noch einen speziellen Treiber von FTDI. Bei mir in der Systemsteuerung steht nämlich COM5 auf 115200 baud. kleiner Fehler : die .equ CPU_TYP = 28 muss in der aktuellen m88 software-version fürs assemblieren auf 88 geändert werden. Aber da kommt man zwangsläufig selber drauf. Zwingt einen nämlich sich mit der Materie auseinander zusetzen. An diesem Project lerne ich endlich, wie assembler funktioniert, bisher habe ich mich nur mit C beschäftigt. Vielen Dank.
Hallo, ich habe jetzt mal angefangen, auf der Webseite etwas zu sortieren. Es liegen nur noch die aktuellen Versionen der Pläne und Software da, außerdem habe ich einen Button News reingebaut, da liegen ein paar Hinweise und Erklärungen um das von mir verursachten Chaos wieder etwas in den Griff zu bekommen... Sorry deshalb, wenn man die Freizeit vorrangig nutzt, um an 2 Versionen rumzubauen, leidet die Dokumentation und der Überblick. Es wäre gut, auf den aktuellen Stand der Schaltpläne umzubauen, wenn das nicht geht (Leiterplatte z.B.), bitte den Schaltplan, nachdem aufgebaut wurde, per Mail an mich schicken, ich sende dann ein passendes Hex-File, das zur aktuellen PC-Software paßt. min (Gast): PB2 und PB3 sind nur noch vom SPI genutzt und für ebtl. Erweiterungen frei. Der AVR muß wegen des UART mit seinem Solltakt laufen, ob sonst da ein anderer Quarzoszillator drauf ist, ist erstmal egal. Dann geht nur dieser Bereich falsch oder garnicht, es muß aber sonst alles spielen. Es muß prinzipiell erstmal alles überhaupt spielen. Adresszähler und Ram würden nur dafür sorgen, daß man keine sinnvollen Signale zu sehen bekommt, zu langsame Triggerlogik würde nur den Triggerpunkt nicht erkennen, ohne Triggerbedingung (alles auf X) muß es trotzdem laufen. Die virtuelle COM des FTDI kann 500kBaud, wird in der PC-Einstellung aber nicht angezeigt. Die Parameter werden sowieso vom Programm gesetzt. 460kBaud haben einen merklichen Fehler bei 20 oder 16MHz AVR-Takt, Baudratenquarz würde die Timing-Berechnungen auf dem AVR für die Samplezeiten fast unmöglich machen. CPU_TYP... da ist offenbar eine Testversion von mir raufgeraten, sollte sonst aber laufen. ASM und C: bei eigentlich nur ASM, inzwischen auch C ohne wirklich unlösbare Probleme. Ich hätte das auch in C schreiben können, allerdings sind eben ein paar Sachen Zyklusgenau nötig (bzw. viel einfacher) und die Experimente mit inline-asm oder ständigem blättern im .lss File wollte ich mir sparen. Auch in ASM sind 80% der Source recycling aus vorhandenen Projekten. ;-) Ich bin heute noch bis zum Nachmittag greifbar, sonst eben morgen oder so. Mal schauen, ich werde mal Debug in die PC-Software einbauen, muß ich nur mal ein paar Fehlerzustände erzeugen, um den Sinn zu testen. Gruß aus Berlin Michael
So schlimm ist das Chaos doch gar nicht ;-) So ist man halt noch nah dran am entwickeln und lernt zudem noch viel.
Hallo, :-)) im Anhang oben mal ein Zwischenstand: im Menü Syten Debug anhaken und dann Test -> Reset Hartware. Jetzt sollten ein paar Messageboxen auftauchen, in der letzten steht ein Teil des Kennungstextes der vermutlich falsch gesendet wurde. Bei den aktuellen Firmware-Versionen muß der mit "MiniLog 50MHz Hardware" anfangen, Rest steht auf der Webseite. Gruß aus Berlin Michael
Habe immer noch Probleme: bekomme die Fehlermeldung "time out - keine gültige Antwort von Hardware" oder "Übertragungsfehler 6" beim Hardwarereset. Muss die Adressleitung 14 des RAMs (pin1) nun auf GND oder an den Zähler? Mein mega88 läßt sich nur Programmieren, wenn ich die 74HC164 rausnehme oder den Takt auf 1/8 stelle?
Hallo, Die Timeout-Meldung gibt kommt vom Controltimer der VB-Software, dann wurde innerhalb von 500ms garnichts (oder genauer weniger als 30 Zeichen, weil die alte Firmware weniger Zeichen als die aktuelle mit 54 Zeichen sendete) empfangen. Ram-Adresse 14 an GND, ich werte nur 16kB zur Zeit aus. Hat aber auf die Funktion selbst keinerlei Auswirkung, die weiß davon nichts. Ich weiß jetzt nicht, womit Du prgrammierst, aber weniger als 1/4 muß es ohnehin sein und bei hohem Taktfrequenzen kann die Last der 164er schon stören, ist ja zusätzliche Last. Ich programmiere hier meist nur mit 1MHz, auch bei den hohen Takten. Wenn Du gesocklet hast: Du kannst alles, was am AVR hängt, rausziehen. Der AVR mit dem FTDI dran muß sich in jedem Fall in der PC-Software melden. Gruß aus Berlin Michael
Hallo, ich habe mich mal durch die komplette Seite gearbeitet: Ist es richtig das die Version ATmega88/48 eine 50MHz Version ist? Was bedeuten würde die 80MHz gibt es nur mit 4kb RAM an statt wie bei der 50er Version mit 16? Gruß Patrick
Hallo, das ist z.Z. der Stand der Dinge. Es ist kein prinzipeilles Problem, die Mega88-Version mit 80MHz zu bauen, in der AVR-Software müssen nur 2 Tabellen angepasst werden. Mein 32k-Ram mit 15ns oder die Adresszähler oder der Aufbau waren aber nicht bereit, mit 80MHz zu laufen. Betriebsspannung spielt da auch chon eine große Rolle, vom USB kommen eben keine 5V sondern je nach Rechner weniger. Zum Testen genügt es eigentlich, den 50MHz Oszillator durch einen 80MHz zu ersetzen und ohne Änderungen zu testen. Dann wird zwar der Ram teilweise wieder überschrieben und Trigger usw. sind falsch, es muß aber gesampelt werden und die Daten den Eingangssignalen entsprechen. Ich nehme da immer einen 74HC4040 mit Quarzoszillator dran und die Ausgänge dann gesamplet. Da sieht man dann schnell, ob es überhaupt geht. Das Ganze ist mehr Anregung zum Experimentieren als fertige Bauanleitung, 50MHz gingen mit 20ns Rams bisher immer zuverlässig. In der AVR-Software für den Mega88 sind demnächst die Tabellen für 50 und 80MHz drin, per .def auswählbar. Da sind aber nicht immer alle Kombinationen wirklich von mir getestet! Ich hoffe, die aktuellen Versionen noch am Wochenende auf die Homepage zu legen. Gruß aus Berlin Michael
Hallo, ich wollte mir das Gerät nachbauen und scheitere warscheinlich am SRam. Ich habe noch welche des Typs W2464AK-20 und AS7C256-20PC gefunden. Könnten die evtl. auch laufen ? Danke !!!
Hallo, der W dürfte ein Winbond sein, sollte gehen, den AS7C256 kenne ich zwar nicht, nach Datenblatt sollte der auch passen. Wenn der Ram zu langsam ist, passiert auch nichts, es wird dann eben in den zu schnellen Bereichen nichts (sinnvolles) mehr gesampelt. Anderen Ram kann man immernoch raufstecken, die in Frage kommenden 8kx8, 16kx8 (selten) und 32kx8 sind pinkompatibel, die Änderungen der AVR-Software minimal, die PC-Software erkennt es dann alleine. Ich bekomme vermutlich morgen noch einige (etliche???) Winbond 32kx8 15ns, die sind sicher bis 50MHz, 80MHz habe ich nur mit dem einzigen 8kx8 12ns zum Laufen bekommen. Neue PC-Software gibt es erst demnächst, ist voriges Wochenende nichts geworden. Ich habe da intern noch etwas umgebaut und schreibe im Moment noch ein paar Hardwaretest-Sachen rein, die Nachbauern (und mir...) das Leben leichter machen. Gruß aus Berlin Michael
Ein paar fragen habe ich noch. Ich wollte die 80Mhz variannte mit dem Mega16 aufbauen, als Speicher habe ich doch noch ein W24129AK-12 (16KX8 12ns) aufgetrieben. Kann ich das Hex-File aus der Minilog40.rar direkt brennen ? Ist das PC-Programm damit kompatiebel ? Danke !!!
Hallo, ja, kannst Du direkt brennen. Es werden dann aber nur 4k Ram genutzt, die verbleibenden Ram-Adressen dann eben fest auf L oder H legen. Prinzipiell kann auch die andere Version mit 80MHz (Takterzeugung dann eben wie bei der Mega16 Version). Man kann auch einen Adresszähler mehr auf die Mega16 Version bauen und 16k nutzen, die Änderungen an der AVR-Software sind minimal. Wenn ich es schaffe, gibt an diesem Wochenende die aufgeräumten Versionen der Software. Da kann per define festgelegt werden, wieviel Ram genutzt werden und welcher Takt genutzt wird. Ich habe natürlich nicht alle Varianten selbst getestet, etwas Experimentierspaß muß also schon da sein. ;-) Gruß aus Berlin Michael
Also sollte mann schon besser die Mega88 version nehmen, passt auch besser zu meinem Ram.
Hallo, jetzt mal eine ganz banale Frage: Die Messklammern auf deinen Bildern - wie heißen die und woher bekomme ich selbig zu vernünftigen Preisen? Gruß Patrick
Sieht nach Hirschmann aus... z.B. bei Bürklin (http://www.buerklin.com): "Miniatur-Klemmprüfspitzen Typ Hirschmann T & M KLEPS 3 ST" Bestellnummer 35F2243
Ach ja... Katalog Seite 20/21 http://www.sks-kontakt.de/download/pdf/katalog/Katalog_TuM_20080902.pdf
Hi, glaube die waren von Pollin, meine mal was gelesen zu haben! http://www.pollin.de/shop/shop.php?cf=produkt.php&ts=0&p=Mzk4OTI5 Gruß, Michel
Kann ich denn statt des Mega16 auch einen Mega32 benutzen? Habe hier nämlich noch den alten von meinem AVR-NET-IO herum kullern (der hat einen 644 bekommen) und bräuchte mir dann keinen neuen kaufen. Nach den Strippen wollte ich dich auch noch fragen. Haben die von Pollin eigentlich nur einen Haken vorne oder ist da so eine 3fingrige Klemme vorne dran? Gruß Sven
Hallo, ja, Du kannst auch einen Mega32 oder Mega644 nehmen, CPU-Definition solltest Du aber anpassen und neu assemblieren. @Gast (Gast): ich werde zwar Änderungen in der Software auch in der Mega16-Verion anpassen, für nögliche Erweiterungen ist aber die Mega88 (Mega48 reicht auch) Version. Man kann natürlich auch bei der Mega16 Version einen 74ACT161 mehr reinlöten und 32k Ram nutzen, die Anpassungen in der AVR-Software sind minimal, der PC-Software ist es egal. Die will nur den maximalen Takt und die Speichergröße vom AVR mitgeteilt bekommen. Es ist keine vollständige Nachbauanleitung und wird auch es auch nie werden, die gezeigten Varianten laufen hier, Taktversionen und Speichergrößen sind aber prinzipiell austauschabr, nur eben nicht von mir getestet. Man sollte dann aber ein wenig AVR-Assembler können, um da anzupassen zu können. Ich helfe da gern, werde aber sicher nicht diverse Kombinationen aus AVR-Typ/Speichertakt/Speichergröße assemblieren und kann die auch nicht hier testen. AVR-Takt ist 16MHz oder 20MHz nötig, bis zur halben Taktfrequnz (also 8MHz oder 10MHzerzeugt der AVR den Speichertakt, die häheren sind prinzipiell egal, allerdings müssen dann die Tabellen angepasst werden. Die Messklemmen habe ich mal geschenkt bekommen, die sind sicher schon 20 Jahre alt...... In die Leitungen ist nahe am Klemmenende jeweils ein 68 Ohm in die Leitungen gelötet, eigentlich, weil ich einen Fehler durch Reflexionen vermutet hatte, der sich nicht bestätigt hat, sie sind aber dringeblieben. Der 74ACT541, den ich im Eingang habe, kommt auch mit 3,3V-Logik bei meinen Sensormodulen ohne Probleme klar. Gruß aus Berlin Michael Gruß aus Berlin Michael
Hallo allerseits, finde das Projekt auch klasse! Super Arbeit Michael. Da ich das ganze nachbauen will, aber gerne in SMD, hab ich mir mal die 80MHz-Version mit Mega16 vorgenommen und das ganze ein wenig geändert und versucht es zu optimieren. Dabei konnte ich die Anzahl der IC's um 3 verringern bei gleicher Funktionalität. Der FT232RL ist auch gleich mit drauf. Der Adresszähler kann jetzt maximal 32kB RAM adressieren. Per Lötjumper können die 3 höchstwertigen Adressleitungen auf GND gelegt werden. Der neue Schaltplan ist im Anhang. Wäre nett wenn Ihr euch (auch du Michael?) das mal anschauen könntet. Geplant ist eine Leiterplatte, einseitig bestückt 100x50mm. Wenn alles fertig ist, werde ich auch den Schaltplan + Board als Eagle-Dateien veröffentlichen. So, bin gespannt auf eure Meinung. Herzliche Grüsse, Jan68
Hi Jan Jan68 schrieb: > Da ich das ganze nachbauen will, aber gerne in SMD, hab ich mir mal die > 80MHz-Version mit Mega16 vorgenommen und das ganze ein wenig geändert > und versucht es zu optimieren. > Dabei konnte ich die Anzahl der IC's um 3 verringern bei gleicher > Funktionalität. Der FT232RL ist auch gleich mit drauf. Hmm, die Funktionalität ist leider nicht gleich geblieben. Du hast keinen sychronen Zähler genommen wie im Original, sondern asynchrone Zähler. Die haben eine Verzögerung von einem zum nächsten Pin (der vhc4040 liegt bei 1,6ns, der hc393 bei 5ns) Das bedeutet dein A0 zählt los und das A14, was zur gleichen Zeit zählen sollte, zählt erst ca. 40ns später. Bei 80MHz ist A0 dann schon einige Adressen weiter. Vermutlich wird deine Version bis 20 oder 25MHz mitmachen und dann falsche Daten speichern. An den synchronen Zählern geht dummerweise kein Weg vorbei - es sein denn du packst das ganze (ebenfalls syncron) in programmierbare Logik. Meine Version hat noch den AVR, das RAM, den Bustreiber und ein 7474 Flipflop drauf. Ach ja, da sitzt noch einen CPLD Lattice M4A5. mfg Harri
Hallo, das Entscheidende hat Harald schon genannt, kann ich nur noch zustimmen. Die Adresszähler sind aus genannten Günden kritisch, dann kommt die Zykluszeit des Rams. Genaugenommen spielt auch noch die Laufzeiten der Triggerlogik eine Rolle, aber das ist relativ. Wenn der Karm dort zu langsam ist, wird ein kurzer Spike nicht mehr erkannt. Aber das ist praktisch egal, weil er vom Ram mit gro0er Wahrscheinlichkeit auch nicht gelesen wird... Bei 80MHz Sampletakt ist es ohnehin nicht sehr sinnvoll, Impulsfolge auswerten zu wollen, die 10-15MHz sind. Das dargestellt Bild kann dann zwangsweise schon stark vom Samplezeitpunkt abhängen, der ja asyncron zur Änderung der Eingangspegel abtastet. Es gibt inzwischen noch einen Nachbau der 80MHz Version, die auch schon ziemlich komplett spielt. Gruß aus Berlin Michael
Hallo,
zunächst mal Danke an Harry und Michael.
Tja, da hab ich mir ja ein schönes Eigentor geschossen, egal, da muss
ich jetzt durch! ;-)
Zum Zähler, da habt Ihr Recht, hab ich leider nicht bedacht.
Die 80MHz sind für mich nicht zwingend, hab dieses Layout als Basis
gewählt, da hier durch den Mega16 schon mal 2 IC's weniger waren.
10-20 MHz würden mir auch reichen. Ggf. könnte man einen 100MHz
Oszillator verwenden und dann erst nach dem 1. oder 2. Teiler
(50MHz/25MHz) abgreifen.
Zum hc393 als Teiler für den Takt:
hier sollte ja das Delay keine rolle spielen, da ja immer nur ein
Ausgang des Teilers verwendet wird. Ab 40MHz müsste dann auch das
Taktsignal absolut symmetrisch sein (50/50%)
Zum vhc4040:
Ich hab noch mal gesucht, aber keinen syncronen Zähler mit >4Bit und
>50MHz gefunden :-(
Gibt es da wirklich nichts anderes mit wenigstens 8Bit ?
@Harry, gibt es deine Implementierung irgendwo zu sehen ?
Gruß Jan68
Hallo, ich noch mal, wie sieht es mit dem 74F549 aus ? Viele Grüße Jan68
Hallo, Jan68 schrieb: > Die 80MHz sind für mich nicht zwingend, hab dieses Layout als Basis > gewählt, da hier durch den Mega16 schon mal 2 IC's weniger waren. > 10-20 MHz würden mir auch reichen. Ggf. könnte man einen 100MHz > Oszillator verwenden und dann erst nach dem 1. oder 2. Teiler > (50MHz/25MHz) abgreifen. 10MHz bekommst Du mit der Takterzeugung durch den AVR wenn er mit 20MHz getaktet ist (F_CPU/2 ist das Maximum, was mit einem Timer geht). Mein Mega16 wollte in der Schaltung keine 20MHz mit Quarz, ein Mega644 macht es auch offiziell, war bei mir dann erstmal drauf. 100MHz TT:Oszillatoren sind selten, teuer und schwer beschaffbar, 80MHz lag in meiner Kiste... > Zum hc393 als Teiler für den Takt: > hier sollte ja das Delay keine rolle spielen, da ja immer nur ein > Ausgang des Teilers verwendet wird. Ab 40MHz müsste dann auch das > Taktsignal absolut symmetrisch sein (50/50%) Delay ist da egal, er muß nur teilen. Die Oszillatoren lagen bisher alle so nahe an 50/50, daü der Ram keine Probleme hatte. > Zum vhc4040: > Ich hab noch mal gesucht, aber keinen syncronen Zähler mit >4Bit und >>50MHz gefunden :-( > Gibt es da wirklich nichts anderes mit wenigstens 8Bit ? Ich habe zumindest nichts gefunden. Allerdings war mir bei der ganzen Geschichte auch wichtiger, irgendwas billiges und vorhandenes/leicht beschaffbares zu nehmen. Da war dann der 74ACT161 die ganze Auswahl... ;-) PS: ich habe für mich der Version mit Mega48/88 und den Schieberegistern den Vorzug gegeben. Einfach, weil man außen noch Schieberegister ranhängen kann, falls man doch z.B. einen ADC ranhängen will. Ich habe neu keine Lust zu längeren Tests gehabt, sonst hätte ich den 12ns 8k ja mal auf das Board stecken können und schauen, was bei 80MHz passiert. Der 32k -15 war jedenfalls einfach lustlos. Da ja prinzipiell nichts anders ist, spricht eigentlich auch da nichts gegen 80MHz. Es gibt in der Hardware der Mega48/88-Version allerdings noch eine Änderung: PB2 ist nicht mehr frei, er steuert jetzt Pin 1 (/G) vom 74HC688. Sonst gibt es Probleme mit der Triggerauswertung bei H-Pegel. Ich schaue, daß ich diese Woche endlich diese Änderungen noch auf die Webseite lege incl. intern etwas veränderter Software für PC und AVR... Gruß aus Berlin Michael
Jan68 schrieb:
> @Harry, gibt es deine Implementierung irgendwo zu sehen ?
Im Anhang.
Enthalten ist der Schaltplan, noch mit ATMega8-16 statt ATMega88-20.
Die letzte Änderung am PLD (der letzte Abschnitt mit dem Signal
t_enable) habe ich aber noch nicht getestet. Bildchen ist auch dabei,
der Oszillator und die beiden Sockel rechts entfallen wenn der Mega88
drauf ist.
Und ohne Gehäuse und Messleitungen sieht er sowieso nackt aus :-)
mfg
Harri
Hallo Harri, herzlichen Dank. Geiles Teil! Da kann ich meinen Ansatz je in die Tonne kloppen. Minimalistischer geht es wohl nicht mehr, eigentlich genau das was ich gesucht habe. Wie wäre es denn das als Leiterplatte in SMD zu routen, würde ich mich gerne dran versuchen. Grun Jan68
Hallo, na mal schauen, wann Harald seine Teile hat und er die Grenzen auslotet. Ich hoffe ja, er bekommt den 74F74 noch eingespart... ;-)) Gruß aus Berlin Michael
Hallo, @ Harald S.: ich habe gerade mal in das CPLD-File geschaut, ohne Ahnung zu haben. Hätte schlimmeres erwartet. ;-) Bin mal Deinen Kommentaren gefolgt und behaupte mal ganz kühn, daß da noch Reserven sind. Beispiel: " die RAM-Adresse darf sich erst ändern wenn ram_we wieder inaktiv ist! " Daher muss ram_we mit clk_del etwas verzögert werden Die Datenblätter der Winbond-Cacherams geben nur eine Haltezeit für die Adressen vor der steigenden Flanke von /WE an. Die Adressen dürfen sich also zeitgleich mit /WE inaktiv ämdern, genaugenommen sogar schon davor. Die Adresse darf auch zeitgleich mit der fallenden Flanke gesetzt werden, TAS ist 0ns. Die Teile sind mir ja deshalb so sympatisch für die Geschichte. Gruß aus Berlin Michael
Hallo Michael, der folgende RAM AS7C256A-12JIN (12ns) sollte hoffentlich genau so funktionieren, wenn ich das Datenblatt richtig deute : http://www.farnell.com/datasheets/32792.pdf Vorteil : aktuell bei Farnell für < 3 Euro beschaffbar Nachteil : SMD PS: Oszillatoren 80/100MHz gibt es leider bei Angelika nicht, bei Farnell kosten die 80 und 100MHz-Typen gleich viel. Gruß Jan68
Hallo, >> Nachteil : SMD > Dafür gibts Adapterplatinen. war ja auch kein Nachteil für mich ;-) Eher für die "Lochrasterfraktion" (ist nicht böse gemeint!)
Mahlzeit! Michael U. schrieb: > " die RAM-Adresse darf sich erst ändern wenn ram_we wieder inaktiv ist! > " Daher muss ram_we mit clk_del etwas verzögert werden Die Timing Reports von ispLever sagen folgendes: - clk -> adresse 13ns - clk -> we ohne verzögerung 10ns - clk -> we mit verzögerung 18ns Bei maximaler Taktfreuenz liegt die Länge des WE-Impulses nahe am Minimum des RAMs (10ns/50MHz). Die Adresse würde sich ohne die Verzögerung also ändern während WE aktiv ist, ca. 7ns vor der steigenden Flanke. Das dürfte einem 12/15ns RAM zu kurz sein: Taw = 10/13ns Mit der Verzögerung liegt die Adressänderung im High-Bereich des WE-Signales. Zumindest denke ich mal, dass das so ist. Ich bin definitiv nicht der CPLD-Profi und nutze das Teil ja eigentlich nur als großes ispGAL. Zum Thema "74F74 einsparen": das ginge vielleicht sogar. Der Synchrone 14 Bit Zähler im CPLD begrenzt die Taktfrequenz auf 76MHz, daher hab ich gar nciht erst versucht die 80MHz direkt rein zu geben. Bei einem 8 Bit Zähler könnte das Teil bis zu 125MHz! Man könnte den Taktteiler aber vielleicht doch mit ins CPLD legen, er wird zwar nicht mit 80MHz zählen aber um ein schön symmetrisches 40MHz Signal zu bauen reicht es wohl. Das Triggerflipflop müsste auch irgendwie passen. Muss ich nochmal gucken. Ach ja, etws Offtopic: ich wollte mir einen ansteckbaren AD-Wandler vor dem LA klemmen. Da fehlt mir noch eine gute Idee für einen möglichst einfach gebauten Vorverstärker. Hat einer ne Idee? Ansonsten muss ich mal ein Topic in der analog-Sektion aufmachen. mfg Harri
@ Jan68: 80 Mhz gibt es bei Reichelt: +OSZI 80,000000 Quarzoszillator, 80,00 MHz 0,95 Euro gerade gekauft...
Hi Michael, danke dass du so schön auf die steigende WE-Flanke hingewiesen hast. Mit der Verzögerung hab ich einen schönen Bock geschossen :-) > Die Timing Reports von ispLever sagen folgendes: > - steigender clk -> Adresse 13ns > - fallender clk -> /WE ohne Verzögerung 10ns > - fallender clk -> /WE mit Verzögerung 18ns Ich zeichne mal das Timing auf, dabei steht ein Zeichen für 2ns. clk -> adr = 14ns, nach der steigende Flanke clk -> we (ohne delay) 10ns clk -> we (mit delay) 18ns 50MHz / 20ns = 10 Zeichen __-----_____-----_____-----_____-----_____-- clk --------XX--------XX--------XX--------XX---- adr ------------_____-----_____-----_____-----__ we ----------------_____-----_____-----_____--- we-delay Gerade durch die Verzögerung ändert sich die Adresse also immer kurz vor der steigenden WE-Flanke. Ohne Delay passt es besser, das bau ich also wieder aus. mfg Harri
Hallo, da ich die Leiterplatte eh schon angefangen hatte, anbei eine abgespeckte Version. Diese kann jetzt nur noch den internen Takt des AVR verwenden und geht somit mit Mega644 bis max. 10MHz Samplerate. Dafür sollte der 74VHC4040 reichen. Im Zip ist der Schaltplan als PDF und die Eagle-Dateien der fertig gerouteten Leiterplatte. Gruß Jan68
Hallo, ich habe mal angefangen die 50MHz ATMega88 Version zu routen. Anbei mein Ergebnis der ersten Platine. Habe am Schaltplan noch ein paar Sachen geändert und ergänzt: - Quarz an FT232 - EEPROM an FT232 - Spannungsregler integriert - Umschaltung BUS <-> Self Powered an JP5 - leider musste ich ein paar Portpins umlegen Ist alles so gemacht das nicht benötigte Teile einfach weggelassen werden können. Da ich leider folgende Pins umlegen musste: MUX_A -> PD3 MUX_B -> PD4 AVR_PB2 + PB3 weggelassen da ich keine Funktion finden konnte RAM_READ -> PD6 IN_SELECT -> PD7 DATEN 0 -> PC0 1 -> PC1 2 -> ADC7 3 -> ADC6 4 -> PC2 5 -> PC3 6 -> PC4 7 -> PC5 würde ich jemanden bitten mir das Programm anzupassen, da ich kein Assembler beherrsche. Die zweite Platine folgt die Tage... Sollten sich irgendwelche Fehler ergeben haben bitte meldet euch! Die Teile sind so ausgewählt, dass man alle bei Reichelt bekommen kann. Gruß Patrick PS.: IC4 der 74HC688N ist auf der TOP Seite bestückt!!!!!!
Hallo, @Patrick Weggler (pw-sys): sicher gut gemeint, aber: gibt es einen Grund, den FTDI232BL statt eines RL zu benutzen? Welchen Zweck hat bei einem USB-Gerat ein zusätzliches Netzteil, wenn der USB es kann? Hinter einen 7805 legt man keinen 470µ Elko, wenn schon Elko, dann höchstens 10-22µ. ADC6+7 sind meines Wissens keine I/O, sondern nur ADC, geht dann so nicht. Ansonsten geht die Zuordnung der Daten vermutlich nicht, weil die Taktzyklen zum Umsortieren fehlen dürften. Die Routine hat nur noch einen zusätzlichen Takt übrig... AVCC und AGND sind nicht angeschlossen, Es gibt noch eine notwendige Korrektur meinerseits: Pin1 (/G) des HC688 muß an PB2 des ATMega. Die geänderte Schaltung liegt noch nicht auf meiner Homepage! Gruß aus Berlin Michael
Patrick Weggler schrieb: > - Quarz an FT232 > - EEPROM an FT232 Damit man diese nicht mehr extern dranhängen muß, hat der FT232R beides bereits integriert. Es macht also keinen wirklichen Sinn, die Bauteile doch wieder extern dranzuhängen.
Hallo, werde versuchen die Ports doch original zu verwenden Das Netzteil hat den mehrere Gründe: 1) Der USB Port hat nicht immer volle 5V was zur folge hat das die ICs nicht mit maximaler Frequenz arbeiten können 2) Da ich nur einen non-Host powered USB Hub am Messplatz hab aber im Gehäuse, in welches der Minilog soll, bereits 9V habe diese Lösung Beim FTDI232 habe ich noch einen BL in der Kiste. Zudem ist er 15ct günstiger ;-) Christian H. schrieb: > Patrick Weggler schrieb: >> - Quarz an FT232 >> - EEPROM an FT232 > Damit man diese nicht mehr extern dranhängen muß, hat der FT232R > beides bereits integriert. Es macht also keinen wirklichen Sinn, die > Bauteile doch wieder extern dranzuhängen. Der externe EEPROM ist für die Seriennummer, wenn man mehr wie einen FT232 an einem Rechner hat laut Datenblatt immer noch vorgesehen nur kann man nun auch nun auch die 56 und 66 Typen verwenden. Der Quarz ist optional bietet aber eine geringere Störanfälligkeit wie der interne RC-Oszilator. Beides ist jedoch optional und kann einfach samt der passiven Bauteile außen herum weggelassen werden. Gruß Patrick PS.: Änderungen kommen hoffentlich nachher
Hallo, ich habe gerade mal die Webseite auf den aktuellen Stand gebracht. PC-Software liegt die neue Minilog.exe im Install-Archiv, falls man schon installiert hat oder die Komponenten von VB schon da sind, diese nur ersetzen und starten. Die alte MiniLog.ini löschen, es wird eine neue angelegt. In der 2. Zeile der .ini steht jetzt die Baudrate, die kann dort per Editor geändert werden (für die, die mit MAX232 an einer COM experimetieren). Da die AVR-Baudrate dann auch angepasst werden muß (steht weiter auf 500kBaud), macht eine Einstellung innerhalb der PC-Software wenig Sinn. Ram wird jetzt mit vollen 32k genutzt. Kennung und Kommandostruktur haben sich etwas verändert, es muß also neu geflasht werden... Wer sich für den AVR eine veränderte Version gebastelt haben sollte, wird wissen, was er verändert hat, sonst eben erstmal bei der alten PC-Software bleiben. PS: wer sich bei den Ram-Anschlüssen verwirrt fühlt: die Datenleitungen des Ram können beliebig vertauscht sein, die Adressen untereinander auch. Es gibt keinen wahlfreien Zugriff, nur serielle Lesen/Schreiben als Ringbuffer. Da spielt es keine Rolle, wo die Bits im Ram landen. Gruß aus Berlin Michael
Patrick Weggler schrieb: > Der externe EEPROM ist für die Seriennummer, wenn man mehr wie einen > FT232 an einem Rechner hat laut Datenblatt immer noch vorgesehen nur > kann man nun auch nun auch die 56 und 66 Typen verwenden. Ist aber nur notwendig, wenn Du hier eigenen Daten speichern möchtest. Die Seriennummer kann man auch im internen EEProm ändern (habe ich selber schon gemacht).
Patrick Weggler schrieb: > 1) Der USB Port hat nicht immer volle 5V was zur folge hat das die ICs > nicht mit maximaler Frequenz arbeiten können interessant, was sind deine erfahrungen, 4,8V ? oder 4.9V ? Wie viel Mhz langsammer arbeiten die ICs dann ?
Hallo, meine ganz praktische Erfahrung auf meinem Drahtverhau: 74ACT161 Fairchild mit ca. 4,7V (altes Thinkpad USB) bei 80MHz nur noch willkürliches Zählen, keine Zählfehler sonder bei jedem 2. oder 3. Sampeln zählten einfach nur die ersten 2-3 Zähler oder garkeiner. Bei 4,9V keine Probleme mit 80MHz Takt. Gruß aus Berlin Michael
Angehängte Dateien:
-
74ac151.JPG
75 KB
Hallo, anbei eine Tabelle aus dem Datenblatt. Natürlich sind die Unterschiede nicht so gewaltig... Das schlechteste Ergebnis an einem USB Port waren 4,3Volt an einem Laptop (führte dazu dass nicht jeder USB-Stick lesbar war). Keine Ahnung was passiert wenn so ein ungünstiger POrt noch mit einem billig nicht gepowerten HUB zusammenkommt. Gruß Patrick
Hallo, anbei die geänderte Version. Signale liegen jetzt alle so wie beim Original PB2 liegt jetzt an Pin1 (G) des 688 Gruß Patrick
Hallo, ich sitze grad am zweiten Teil des Layouts und frage mich ob ich S1 noch benötige und wenn ja wozu? Gruß Patrick
Hallo, noch eine Frage; So weit ich die Schaltung verstanden habe kann ich die Adressleitungen zwischen den 161ern und dem RAM lustig vertauschen?
Patrick Weggler schrieb: > Hallo, > > ich sitze grad am zweiten Teil des Layouts und frage mich ob ich S1 noch > benötige und wenn ja wozu? Wenn kein 8kx8 bestückt werden soll, kann er ganz weg. Beim 8kx8 ist auf dem Pin ein zusätzlicher H-aktiver Chipselect. Kann man natürlich auch eine Lötbrücke oder 0-Ohm Widerstand nehmen. >So weit ich die Schaltung verstanden habe kann ich die Adressleitungen >zwischen den 161ern und dem RAM lustig vertauschen? Ja, kannst Du. Die Daten vom Ram selbst kannst Du auch anschließen, wie Du willst. Die Zuordnung ist nur zwischen Eingang und AVR wichtig, damit die Kanalzuordnung stimmt und die Triggerdaten/Triggermaske und AVR müssen natürlich bitweise auch stimmen. Welche Gatterpins da landen und an welchem Eingangspärchen des 688 die landen, ist ja auch egal. Gruß aus Berlin Michael
Da muß ich mal meinen laienhaften Respekt bezollen. Sehr schönes Projekt, sehr gut beschrieben. Das wird wohl eins meiner nächsten Projekte sein. Oder eher eines der ersten. Sowas kann man ja immer gut gebrauchen. Also 10 Daumen für dieses schöne Projekt. Könnte man das nicht als Artikel hier einstellen, oder gibt es das schon und ich hab's überlesen?
Hallo, erst einmal danke für die Antworten... ich würde gerne 32kx8 verwenden. Wozu dient der nicht angeschlossene PB3? Gruß Patrick
Hallo, Shift_Data Shift_Clock von der SPI werden eigentlich auch nicht benötigt? Oder habe ich die 3 Signale irgendwo verlohren? Gruß Patrick
Hallo, "habe fertisch" Anbei das Ergebnis; alle Sachen diesmal der besseren Lesbarkeit wegen als PDFs. Wie auch beim letzten mal würde ich euch bitten mal drüber zu sehen ob sich Fehler eingeschlichen haben (gerade die fehlenden 3 Signale) Am Part 1 habe ich nichts mehr geändert. Ist jetzt auf 16kx8 bzw. 32kx8 ausgelegt, wie auch beim Part 1 sind alle Teile bei Angelika zu bekommen. Part 1: 160x100mm Part 2: 100x100mm, so das beim Stecken der Eingang nach vorne schaut. geplant habe ich das beides zusammen + Netzteil in das TEKO KL12 passt. @Michael U. (amiga): Wenn du willst kannst du das Ding auf deine Homepage draufpacken, um anderen u.U. die Arbeit zu ersparen. Gruß Patrick
Hallo, Patrick Weggler schrieb: > Shift_Data Shift_Clock von der SPI werden eigentlich auch nicht > benötigt? > Oder habe ich die 3 Signale irgendwo verlohren? Nein, hast Du nicht verloren. Data und Clock von den Schieberregistern sind nur rausgeführt für evtl. Erweiterungen, genauso der freie PB3. Bei mir (Lochraster) sind sie bis jetzt nur auf dem Steckverbinder zum Teil 2. Dort ist ja der Anscshluß nach draußen (Eingänge) und da sind eben noch ein paar Stifte mehr angedacht, um z.B. extern einen ADC oder aktive Probes oder was-auch-immer anzustecken. Da gibt es schlicht noch nichts und da ich ja auf Lochraster den noch verbliebenen Platz auch einfach noch nutzen kann, ist auch noch unklar, ob oder was da passiert. Externer Trigger und externer Takt ist auch angedacht usw. Sicher ist nur, daß ich für mich am Teil mit dem AVR nichts mehr verändern werde. Naja, fast nichts??? Wenn ich noch einen 32kx8 in 12 oder 10ns finde, werde ich vermutlich den 50MHz Quarzoszillator durch einen 80MHz ersetzen und den 20MHz durch einen 74ACT74 wie bei der Version mit dem Mega16 und schauen, ob 80MHz auch da stabil gehen. Gruß aus Berlin Michael
Hallo, war wohl doch zu spät... Anbei die Dateien Gruß Patrick
Hallöchen! Michael U. schrieb: > Wenn ich noch einen 32kx8 in 12 oder 10ns finde, werde ich vermutlich > den 50MHz Quarzoszillator durch einen 80MHz ersetzen und den 20MHz durch > einen 74ACT74 wie bei der Version mit dem Mega16 und schauen, ob 80MHz > auch da stabil gehen. Nur mal so zur Info: Ich hab hier ein altes Acer-Mainboard aus dem Schrott gezogen (Chipsatz Ali 1531, für Pentium MMX, hat noch 'normale' Spannungsregler mit fetten Kühlkörpern drauf). Das sitzt doch tatsächlich ein Tag-RAM mit 10ns und 5V Betriebsspannung drauf. Hab gar nicht gewusst, dass es diese Kombination gibt/gab. Vielleicht brauchten die Chipsätze von Ali und evtl. auch Via etwas flottere Tag-RAMs als die Intel Chipsätze und diese Mainboards sind damit eine gute Quelle für socleh Bauteile. Mein Asus T2P4 mit Intel Chipsatz (passend für die gleichen CPUs) hat nur ein 15ns Tag-RAM. Man muss allerdings den SMD-Chip vom Board ablöten :-) mfg Harri
Patrick Weggler schrieb: > Hallo, > > war wohl doch zu spät... > > Anbei die Dateien > > Gruß > Patrick Hallo Patrick, super Arbeit! Würdest Du auch die Eagle Files zur Verfügung stellen? Für die Leute (wie ich) die eventuell noch etwas verfeinern oder ergänzen möchten. 1000 Dank Patrick! 1000 Dank auch dem Threadstarter Michael für dieses einmalige Projekt!! Hut ab!
Hallo, wenn wir genügend Leute zusammenbekommen würden könnte man die Platinen anfertigen lassen... Bei Interesse bitte melden! Habe noch nie eine Platine anfertigen lassen, daher: wo gut und günstig? Gruß Patrick
Hallo @Patrick Weggler Hast du schon einen funktionsfähigen Prototypen von deinem Layout erstellt? Gruß
Hallo, Guten Morgen schrieb: > Hallo > > @Patrick Weggler > > Hast du schon einen funktionsfähigen Prototypen von deinem Layout > erstellt? Es kann mir zwar relativ egal sein, aber das würde ich auch dringend vorschlagen. Mir sind zur Zeit bekannt: meine Version mit Mega16 und 80Mhz, die spielt. ein Nachbaau mit Mega16 und 80MHz, der noch ein Probleme hat. meine Version mit Mega88 und 50MHz, die spielt. die Version mit dem CPLD von Haral S., die prinzipiell spielt, aber noch nicht ganz fertig ist. Mit 50MHz erwarte ich eigentlich keine Probleme, weil die Timings gerade noch so in den Grenzen liegen. Bei 80MHz dürfte wohl generell etwas Glück bzw. Bauteilauswahl nötig sein. Gruß aus Berlin Michael
Wahnsinns Projekt, BRAVO! Eine Frage, welcher Lattice wird zum Einsparen der Logik-Steine verwendet? Gruss Kay
Hi! > Eine Frage, welcher Lattice wird zum Einsparen der Logik-Steine > verwendet? Ich habe einen M4A5 64/32-10 im PLCC-Gehäuse genommen weil man den so schön in einen Sockel stecken kann. Für SMD-Löten bin ich zu zittrig ;-) Steht auch etwas weiter oben im Thread, zusamen mit der PLD-Logik. mfg Harri
Danke Harry, der Tread ist halt schon etwas länger, da fehlte mir die Übersicht, zumal ich nur die alten Lattice_isp's kenne.
Hallo zusammen! Michael U. schrieb: > die Version mit dem CPLD von Haral S., die prinzipiell spielt, aber noch > nicht ganz fertig ist. Ich bin mittlerweile einen Schritt weiter gekommen. Es sitzt jetzt ein Mega88-20 statt eines Mega8-16 drauf, womit ich die orginal-Firmware minilog28 ohne große Anpassungen nutzen kann. Dann hab ich jetzt auch Grabberchen dran und von 40 auf 50MHz getunt. Ach ja, der 74F74 ist auch weggefallen. Damit sitzen jetzt nur noch 4 ICs und 2 Oszillatoren auf meiner Platine :-) Der FTDI232 liegt noch rum und wartet dass ich eine Platine ätze. Deshalb hab ich erstmal nur einen MAX232 dran und lasse das ganze mit 115200bps laufen. Funzt mit der aktuellen Software prima. Falls es interessiert - Schaltplan, aktuelle CPLD-Sourcen und Bildchen anbei. Der Screenshot zeigt einen mit 25MHz getakteten HCT4040, Kanal0 zeigt die 25MHz vom Eingang des Zählers. mfg Harri
Hallo, fein. :-)) Ich habe gerade mal meine 74ACT161 nach dem Datenblatt auf Lookahead Carry umverdrahtet. Irgendwie fehlte diese Passage in meinem ursprünglichen Datenblatt. Der Hinweis stammt aus Beitrag "Bitte einmal über DSO Schaltplan schauen" Bis jetzt nur kurzer Test (mit 50MHz 74HC4040 :-)), war wohl das Tüpfelchen auf dem I. Sowohl mit Winbond als auch mit UMC 32kx8 15ns stabil! Ich werde das noch etwas testen und dann die Änderung auf die Webseute stellen. Nun ist allerdings in meiner Version der 4. Mux-Eingang belegt, der sollte eigentlich extern Clock werden... Naja, ein Pin hat mein Mega88 ja noch frei. Gruß aus Berlin Michael
Hallo, sobald Michael den Schaltplan mit den Änderungen online stellt werde ich das Layout anpassen. Ich werde sobald die Änderung eingepflegt ist bei Reichelt die noch fehlenden Teil bestellen und das Layout mal zu Kupfer bringen... Gruß Patrick
Hi, kurze Zwischenfrage: Sehe ich das richtig, dass man durch Verwenden eines 74245 (bidirektionaler Bustreiber) statt des 74541 - plus zusätzliche Steuerleitung für Richtungsauswahl - die Hardware auch als Pattern-Generator verwenden könnte? Gruß Andreas
Hallo, niemand hindert Dich, das ao zu machen... Im AVR-Source wäre nur eine neue Funktion einzubinden. Wenn die Pattern frei vom PC kommen sollen, kann man da ein ein einfaches Transferprogramm schreiben. Gruß aus Berlin Michael
Angehängte Dateien:
-
hcanalyzer.jpg
270 KB
Hab' mir nun auch einen gebaut :-) Variation: - 16 Kanäle a 32k Samples - Software-USB von obdev.at, da ein FTDI-Chip das mit Abstand teuerste Bauteil gewesen wäre - ausschließlich externer Trigger - atmega8515, da im PLCC-44-Sockel sehr platzsparend auf Lochraster Ein paar Erkenntnisse: - Software-USB schafft bei mir 8kB/s; Bei 64kB Samplespeicher sehr grenzwertig... Komprimierte Übertragung steht also als nächstes auf meiner TODO-Liste - Mit 74HC aufgebaut schafft mein Analyzer nur 33 MHz :-/ Bei 40 MHz kommen nur noch Zufallsdaten aus den Adresszählern. Einzige Möglichkeit, mit den HC-chips Michaels ursprüngliche 50MS/s zu schaffen, wäre wohl Interleaving einzusetzen. - Bin ursprünglich auch in die Falle mit 'nem Asynchronzähler getappt. Das Ergebnis waren maximal 4 MHz. Hab' dann improvisiert, und die 4040-Sockel als Buchse für die einkliche 161-Zählerplatine verwendet. Die rechnerseitige Software besteht im Moment nur aus Shell-Skripten: Mit dem "usbtool" von obdev.at werden "Register" (z.B. Clock-Source) im Analyzer gesetzt, und der Speicher dann als Binärdumps ausgelesen. Ein Perl-Skript macht daraus .vcd-Dateien, die man z.B. mit gtkwave betrachten kann. Gruß Andreas
Angehängte Dateien:
-
gtkwave.png
84 KB
Hi nochmal, ein kleines Update: Ich hab' nun in AC-Zaehler investiert; der Rest meines Nachbaus ist immernoch in HC. Nun laufen 66 MHz stabil. Bei 80 springen die Zaehler nicht mehr an... Vermutlich ist nun das MUX am Ende, da - wenn meine Rechnung stimmt - bei 66MHz bereits nur noch ein Saegezahn mit 2,5 Vpp rauskommt :-) Anbei als Appetitanreger fuer eventuelle Nachbauer noch ein Bildschirmfoto von gtkwave beim Untersuchen aller 12 Ausgaenge eines mit 66.667 MHz betriebenen 74HC4040. Das asynchrone Verhalten sieht man bei den 66MS/s sehr schoen... Danke an der Stelle an Michael fuer die Grundlagenforschung und gute Dokumentierung. Ich hab' leider nicht so vorbildlich dokumentiert... Einzige Innovation ist ja auch nur das Software-USB, welches ich in der Variante mit Zener-Dioden an den Datenleitungen verbaut habe (Details siehe <http://vusb.wikidot.com/hardware>;). Gruß Andreas
Welchen Hersteller verwendet ihr? Philips spricht im Datenblatt 79MHz für HCT und 90 MHz für HC Fairchild hingegen von garantierten 30 MHz und max 50 MHz Es noch einen einen 74HC4060 ist ein 14 Bit Zähler dann könnte man noch mehr Speicher verwenden und wenn man die Bausteine mit etwas höherer Spannung laufen läßt bringt das auch noch einige nSek extra bei den Verzögerungen
Thomas O. (kosmos) writes: > Welchen Hersteller verwendet ihr? > Philips spricht im Datenblatt 79MHz für HCT und 90 MHz für HC > Fairchild hingegen von garantierten 30 MHz und max 50 MHz Reichelt lieferte mir fast alle Chips von SGS-Thompson, welche zwischen 50 und 63 MHz spezifiziert waren. Die Zähler kamen leider von TI, die nur 35 MHz garantieren, und bei 40 MHz nicht mehr korrekt zählten. Ich hab' dann meinen ganzen Mut zusammengenommen, und bei Farnell 74AC161 von Fairchild bestellt (125MHz typ.). > Es noch einen einen 74HC4060 ist ein 14 Bit Zähler dann könnte man > noch mehr Speicher verwenden Vorsicht: Es sind hier aber nur die höchstwertigsten 12 Bit auf Pins ausgeführt. Des weiteren ist es ein Asynchronzähler: Mit HC4040 von Philips als Adresszähler für die SRAMs bin ich nur auf 4MHz gekommen. Darüber wurden unschuldige Adressen überschrieben, weil das asynchrone Weiterzählen länger dauerte, als die Periodendauer des Sampletaktes... > und wenn man die Bausteine mit etwas höherer Spannung laufen läßt > bringt das auch noch einige nSek extra bei den Verzögerungen Stimmt, jedoch bräuchte man dann eine externe Stromversorgung, und gerade die Versorung über USB macht das Projekt IMHO so elegant. Ich hab' auch mit dem Gedanken gespielt, 24 statt 16 Kanäle zu verbauen, da am atmega8515 noch ein Port frei war, aber da jeder Cache-Chip ein ganzes Watt schluckt, und USB nur 2,5W hergibt, hab' ich die Idee verworfen. Michaels Idee, die Samplerate durch Interleaving zu verdoppeln, hört sich da schon interessanter an, als 5% durch Betrieb mit 6V herauszuschlagen. Gruß Andreas
Hallo, ansel schrieb: > ein kleines Update: Ich hab' nun in AC-Zaehler investiert; der Rest > meines Nachbaus ist immernoch in HC. Nun laufen 66 MHz stabil. Bei > 80 springen die Zaehler nicht mehr an... Vermutlich ist nun das MUX am > Ende, da - wenn meine Rechnung stimmt - bei 66MHz bereits nur noch ein > Saegezahn mit 2,5 Vpp rauskommt :-) Hast Du die AC161 mit lookahead carry beschaltet? Das Beispiel ist nicht in allen Datenblättern angegeben... http://www.fairchildsemi.com/ds/74%2F74AC161.pdf > Anbei als Appetitanreger fuer eventuelle Nachbauer noch ein > Bildschirmfoto von gtkwave beim Untersuchen aller 12 Ausgaenge eines > mit 66.667 MHz betriebenen 74HC4040. Das asynchrone Verhalten sieht > man bei den 66MS/s sehr schoen... > Danke an der Stelle an Michael fuer die Grundlagenforschung und gute > Dokumentierung. Ich hab' leider nicht so vorbildlich > dokumentiert... Einzige Innovation ist ja auch nur das Software-USB, > welches ich in der Variante mit Zener-Dioden an den Datenleitungen > verbaut habe (Details siehe <http://vusb.wikidot.com/hardware>;). Naja, ein FTDI-Adapter liegt bei mir eigentlich immer rum und die 500kBaud sind ja ganz brauchbar. ;) Freut mich jedenfalls, daß das Konzept doch relativ beherrschbar ist. Sieht man eben wieder, was man so alles als "Drahtverhau" machen kann. Ich habe es leider noch nicht geschafft, die geänderte Schaltung auf die Webseite zu stellen... Gruß aus Berlin Michael
> Hast Du die AC161 mit lookahead carry beschaltet? > Das Beispiel ist nicht in allen Datenblättern angegeben... > http://www.fairchildsemi.com/ds/74%2F74AC161.pdf Ja, die Adapterplatine von 2*4040 auf 4*161 hab' ich gleich mit lookahead carry verdrahtet. Gruß Andreas
Angehängte Dateien:
-
minilog40_s.png
45 KB
versuche grad die Triggerlogik des Logicanalyzer zu verstehen, aber irgendwie kapier ich den effektiven Nutzen dieser Schaltung noch nicht ganz, kann mir da jemand helfen. durch das Maskenbyte und die ODER-Verknüpfungen kann ich also quasi einzelne Bits der Daten ignorieren, ok das ganze wird dann mit dem Triggerbyte verglichen und wenns passt dann-----> <<<zeichne auf>>>>>...... kann es sein, dass das Masken und Triggerbyte invers angegeben werden müssen und dann auch nur ein wechsel von "0" auf "1" eines bestimmten Bits erkannt wird. ich möchte jetzt z.b. durch meine Triggerlogik erreichen das die Aufzeichnung startet, sobald Bit 1 "0" wird, egal was die anderen 7 Bits grad treiben. Wie müsste ich dann Triggerbyte und Maskenbyte konfigurieren? An sonsten echt tolles Projekt muss ich sagen! Wenn ich das mit der Triggerung kapiert hab, werd ich mich wohl auch mal an den Nachbau wagen :) Gruß
Hallo Jan, die Triggerlogik funktioniert mit High oder Low-Pegeln. Eine Erkennung nach Flanken high ->low oder low->high findet gar nicht statt. In deinem Beispiel stellst du also Bits 2-8 auf X. Diese Bits werden dann vom AVR in Maske und Triggerbyte auf high gesetzt, sind am HC688 also immer passend. Das Bit 1 setzt du in der Software auf low. Der AVR setzt dann Maskenbit 1 auf low, also kommt beim oder-Gattter das hinten raus was am Datenbus anliegt. Das Triggerbit 1 wird auch low, wenn jetzt das Datenbit 1 ebenfalls low ist, dann startet die Aufzechnung. Was hier nicht geht ist z.B. folgendes: gemessen wird an einem Computersystem, Triggersignal soll die steigende Reset-Flanke sein. Also alles anderen ignorieren und beim Reset-Bit eine 1 rein. Ergebnis: die Messung startet sofort, ich hab gar nicht genug Zeit noch fix auf Reset zu drücken. Neuer Versuch: Reset-Bit auf 0 triggern. Ergebnis: Messung schon startet beim Beginn des Resets und zeichnet eine inaktive CPU auf. Mit einer Erkennung der steigenden Flanke wäre diese Aufgabe gelöst. Wenn du alleine die Pegel betrachtest und die Flanken (sobald Bit 1 "0" wird) ignorierst, dann verstehst du die Triggerlogik besser. mfg Harri
Mahlzeit! Hat schonmal jemand versucht die minilog.exe unter dem Windows 7 RC1 64 Bit zum laufen zu bringen? Das Setup läuft nicht durch und die minilog.exe beschwert sich über eine fehlende comdlg32.ocx. Irgendeine Idee wie ich die fehlenden Dateien auf mein Win7 bringe? mfg Harri
Hallo, keine Ahnung, was Windows 7 davon hält, ich kann mal einen Bekannten fragen. Ansonsten: die CAB-Datei entpacken (oder das .ocx im Netz suchen), kann prinzipiell auch im Minilog-Ordner bleiben, Dann zu Fuß registrieren. unter XP waäre das regsvr32 <Pfad\>comdlg32.ocx Hab hier gerade was im Netz gefunden: http://gbatemp.net/lofiversion/index.php/t147412.html Gruß aus Berlin Michael
Hi Michael Michael U. schrieb: > Ansonsten: die CAB-Datei entpacken (oder das .ocx im Netz suchen), kann > prinzipiell auch im Minilog-Ordner bleiben, Dann zu Fuß registrieren. Das hat nach der Anleitung in deinem Link geklappt. Zusätzlich musste ich auch die mscomm32.ocx aus deinem cabfile registrieren. Ich hatte es zuvor schon so probiert, dabei aber die Dos-Box nicht als Admin geöffnet. Der explorer fragt in so einem Fall nach Erlaubnis, die Dos-Box nicht :-) mfg Harri
Wollte noch mal DANKE an Harald S. sagen für die ausführliche Erklären der Triggerlogik, habs jetzt verstanden...:)
>50Ms/s AVR Logic-Analyzer .... bei 20MHz AVR-Takt
Irgendwie kapiere ich nicht, wie die Samplerate höher sein kann, als der
Prozessor- oder Mikrocontrollertakt. Werden da mehrere Samples parallel
übertragen und verarbeitet?
>> 50Ms/s AVR Logic-Analyzer .... bei 20MHz AVR-Takt > Irgendwie kapiere ich nicht, wie die Samplerate höher sein kann, als der > Prozessor- oder Mikrocontrollertakt. Werden da mehrere Samples parallel > übertragen und verarbeitet? Das Aufnehmen der Samples besteht aus dem Hochzählen der Adresse für die SRAMs und dem Erzeugen des "write enable" Signals. Beides wird komplett in Hardware von den diskreten Logikbausteinen erledigt. Im Gegensatz zum AVR machen 74ACxxxx z.B. bis über 100MHz. Zum Auslesen wird der Adresszähler vom AVR dann im Schneckentempo getaktet. Details siehe Schaltplan :-) Gruß Andreas
Noch mal in eigenen Worten:_ Es werden externe AD-Wandler verwendet, die rasendschnell selbstständig wandeln und die Sampleergebnisse ebenso schnelll intern speichern, um sie dann irgendwann mal gemütlich dem Controller zu übergeben?
es werden keine AD-Wandler benutzt da es sich um einen Logic-Analyzer handelt und nicht um eine Oszilloskop.
ansel schrieb: > Ein > Perl-Skript macht daraus .vcd-Dateien, die man z.B. mit gtkwave > betrachten kann. Hi, sag mal, ist es möglich, dass ich dieses Perl Script bekommen könnte? Ich versuche grade aus nem großen Logic Analyzer, den wir beim CCC stehen haben Daten rauszubekommen. Sobald ich das geschafft habe, wollte ich die ein wenig verwursten, um mir sie in GTKWave anschauen zu können. Da könnte ich mir ein bischen was bei dem Teil abgucken. Grüße, Andreas
Anbei das gewünschte Perlscript... usage: perl ./memdump2vcd.pl < foo.bin > foo.vcd Die Zeitbasis kann mit der Umgebungsvariablen XDIV in Nanosekunden angegeben werden. Nebenbei: Das VCD-Format ist in IEEE Std 1364-2001 standardisiert. Gruß Andreas
Wenn man vor dem Logik-Analysator so ein RS485-Chip setzen würde, könnte man dann nicht USB-Signale bis 12Mbit/s mitloggen ?
Angehängte Dateien:
-
lospeed-usb.png
21 KB
Cubi writes: > Wenn man vor dem Logik-Analysator so ein RS485-Chip setzen würde, > könnte man dann nicht USB-Signale bis 12Mbit/s mitloggen ? Hmm, die Paketenden werden bei USB mit einer single-ended Null markiert. Was tut in dem Fall der RS485? Also wenn ich meinen Analyzer mit dem 74HC541 direkt an seinen eigenen USB-Port (low-speed/1,5MHz) klemme, sieht der Mitschnitt einwandfrei aus (Anhang). Ich könnte mir aber vorstellen, daß das bei höheren Frequenzen problematisch wird. Aber vielleicht genügt es ja, die Bustreiber in der Version mit TTL-kompatiblen Logikleveln zu bestücken (HCT/ACT). Die sollten für 3,3V besser geeignet sein, oder? Gruß Andreas
Das war von mir nur ein Schuß ins Blaue. Mit RS485 habe ich noch nie etwas gemacht. Die single-ended Null von USB kann man in dem Screetshot ja sehr schön sehen.
Hallo, ansel schrieb: > Also wenn ich meinen Analyzer mit dem 74HC541 direkt an seinen eigenen > USB-Port (low-speed/1,5MHz) klemme, sieht der Mitschnitt einwandfrei aus > (Anhang). Ich könnte mir aber vorstellen, daß das bei höheren Frequenzen > problematisch wird. Aber vielleicht genügt es ja, die Bustreiber in der > Version mit TTL-kompatiblen Logikleveln zu bestücken (HCT/ACT). Die > sollten für 3,3V besser geeignet sein, oder? Mein 74ACT541 hat zumindest mit 3,3V Logiksugnalen keinerlei Probleme. Die TTL-kompatiblen erkennen H ab ca. 1,6V, damit ist da eigentlich genug Reserve. PS: würdest Du mir Deinen Schaltplan schicken oder hier reinstellen? Mein Bekannter will auch 16 Kanäle aufbauen, allerdings mit meiner Triggerlogik für die unteren 8 Kanäle. Hast Du die AVR-Firmware neu geschrieben oder nur meine umgebaut? Müßte ich dann sowieso entweder meine VB-Software anpassen oder er benutzt Deine Scripte, das muß er selber wissen. Noch ist er beim Löten... Ich hoffe, demnächst endlich wieder etwas mehr Zeit zu finden, die VB-Software will ich ja sowieso noch erweitern. Gruß aus Berlin Michael
amiga writes: > PS: würdest Du mir Deinen Schaltplan schicken oder hier reinstellen? > Mein Bekannter will auch 16 Kanäle aufbauen, allerdings mit meiner > Triggerlogik für die unteren 8 Kanäle. Mein Schaltplan besteht leider nur aus 'ner Verdrahtungstabelle für den AVR:
1 | | atmega3515 | dir | | |
2 | |------------+-------+---------------| |
3 | | A0..7 | inout | bus#0 D0..7 | |
4 | | B0 (oc0) | out | MUX softclock | |
5 | | B1 | out | WE-NAND | |
6 | | B2 | out | MUX addr | |
7 | | B3 | out | MUX addr | |
8 | | B4 | out | MUX addr | |
9 | | B5 (mosi) | in | ISP-1 | |
10 | | B6 (miso) | out | ISP-9 | |
11 | | B7 (sck) | in | ISP-7 | |
12 | | C0..7 | inout | bus#1 D0..7 | |
13 | | D0 (RxD) | in | ISP-3 | |
14 | | D1 (TxD) | out | ISP-4 | |
15 | | D2 (int0) | inout | USB D+ | |
16 | | D3 (int1) | in | ext. trigger | |
17 | | D4 | inout | USB D- | |
18 | | D5 | out | SRAM OE | |
19 | | D6 | out | GATE OE | |
20 | | D7 | out | LED red | |
21 | | E0 (int2) | in | XO/1024 | |
22 | | E1 | out | LED yellow | |
23 | | E2 | out | LED green | |
24 | | RESET | in | ISP-5 | |
Die SRAMs wurden - bis auf den Datenbus natürlich - parallel geschaltet. Der Rest wurde naheliegend nach Datenblättern bzw. Deinen Plänen verdrahtet. > Hast Du die AVR-Firmware neu geschrieben oder nur meine umgebaut? Die Firmware hab' ich in C geschrieben. Ähnlichkeiten mit dem USB-Besipielprojekt von obdev.at zum Schalten von LEDs[1] sind natürlich rein zufällig :-). Ich hänge sie mal an... Hier ein paar Beispiel-Shellbefehle. Die verwendeten magischen Zahlen finden sich im Code in den enum{}s.
1 | # clockmux einstellen: |
2 | usbtool -P "Logic Analyzer*" control out vendor endpoint 0 7 0 |
3 | |
4 | # "Aufnahmetaste" drücken: |
5 | usbtool -P "Logic Analyzer*" control out vendor endpoint 6 0 0 |
6 | |
7 | # Daten in 4kB-Häppchen abholen, da usbtool nicht mehr macht |
8 | for ((i=0; i<16; i++)); do |
9 | usbtool -b -n 4096 -P "Logic Analyzer*" control in vendor endpoint 4 0 0; |
10 | done > data.bin |
11 | |
12 | # "Live capture" in Terminal ausgeben |
13 | while : ; do echo -ne '\r' $(usbtool -P "Logic Analyzer*" control in vendor endpoint 9 0 0) ; done |
HTH Andreas Footnotes: [1] http://www.obdev.at/products/vusb/prjdetail.php?pid=0
Thread beobachten
Seitenaufteilung abschalten