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
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
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...
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
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
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,
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
!!
@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
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.
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
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,
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€)
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?
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.
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
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
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
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,
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
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
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
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,
"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
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,
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
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
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
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
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
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
>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?
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
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
Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.
Wichtige Regeln - erst lesen, dann posten!
Groß- und Kleinschreibung verwenden
Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang