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

die TTL Logik wäre ja schon was für unsere VHDL Gemeinde

Hallo,

mit VHDL habe ich erstmal nichts am Hut, werde aber bestimmt keinen
hindern. ;)

Ein Bekannter nimmt das gerade als Einarbeitungsobjekt für das
Pollin-CPLD-Board. Als Übungsaufgabe, weniger als Anwendung.

Ich habe gestern erstmal angefangen, einen Adapter für den
Mega644-Sockel zu löten, der einen Mega88 (war gerade da ;-) und 2x
74LS164 trägt.

Werde ich hoffentlich heute noch fertig machen und dann die Firmware
erstmal darauf umstellen. Der Mega644 mit 1,5% Flash-Nutzung stören mich
eben...

Gruß aus berlin
Michael

Hallo schönes Projekt wann wird der Sourcecode Veröffentlicht?
Und wie machst du die > 10MHz (100ns) der Timebase, per PWM ?

Wenn ich jetzt einen 16MHz Quarz nehme kann ich doch max. 8MHz als
Timebase nehmen.

Hallo,

Avr Nix schrieb:
> Hallo schönes Projekt wann wird der Sourcecode Veröffentlicht?
Vielleicht noch heute, dann für meine (vorerst) endgültige Version mit
Mega48/88.

> Und wie machst du die > 10MHz (100ns) der Timebase, per PWM ?

Siehe Schaltbild, mit getrennten Quarz-Oszillatoren.
Der AVR wird mittlerweile dann vom 20MHz Oszillator getaktet.

> Wenn ich jetzt einen 16MHz Quarz nehme kann ich doch max. 8MHz als
> Timebase nehmen.

Solange Du den Takt nur intern erzeugst ja.

Für 16MHz müssen dann die Tabellen angepasst werden und eine Abstufung
1:2:5 ist dann natürlich auch nicht möglich.
Müßte dann eben auf 8, 4, 2, 1 oder ähnlich gestuft werden.
Da müßte dann natürlich auch die VB-Software angepasst werden.
Werde ich nicht machen, VB6-Sourcen kann ich aber gern rausgeben.

Das Problem mit den Sampleraten ist folgendes: mehr als ca. 1/10 der
Samplerate ist als Signal nicht mehr sinnvoll auswertbar.
Wenn ich Timing-Differenzen zwischen 2 Signalen erkennen will, muß auch
oft genug abgetastet werden. 8MHz lassen eben nur 125ns Zeutraster zu.
Ein mit 16MHz getakteter AVR kann da aber schon 2x ein Portpin ändern
und der LA bekommt davon nichts mit.

Ich halte die 50MHz als Minimum, wenn ich damit in üblichen
AVR-Basteleien noch was erkennen will.
Für UART/I2C usw. reichen aber durchaus auch 8MHz noch aus.

Gruß aus Berlin
Michael

Wäre auch gut wenn du die VB Source veröffentlichen würdest.
Dann warte ich mal bis heute Abend auf die Veröffentlichung der Quellen.

Hallo,

so, nachdem der Neubau soweit erstmal läuft, habe ich die Webseite noch
schnell erweitert.

Es läuft soweit alles, 16k Samplespeicher zur Zeit, für 32k muß ich das
VB-Programm erstmal etwas auf- und umräumen.
Der Buffer von MSComm ist nicht der Meinung mit 32k klarzukommen...
Übertragungsrate ist jetzt 500kBaud, sollte eigentlich stabil gehen, im
Auto-Mode gab es allerdings sporadisch Übertragungsfehler, das muß ich
mir wohl noch genauer ansehen.

http://www.avr.roehres-home.de/logikanalyzer/index.html

Gruß aus Berlin
Michael

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,- €.

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

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

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

Stefan Salewski schrieb:
> Hast Du dir eigentlich schon mal meine digitale Eingangsstufe angesehen?
Wo findet man die?

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

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

respeckt!

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,

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

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,

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

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

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

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

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

@Harri,
Berichtigung von mir. Das eine Design wurde mit Quartus gemacht.
siehe FPGA Abteilung.

Hallo,

@Michael K.:
Danke für die Info.

Gruß aus Berlin
Michael

Hallo,

erst mal finde ich dein Project super, habe schon vor einem halben Jahr
mal nach LA Schaltungen auf AVR Basis gesucht, welche alle nicht der
Brüller waren.
Als ich gestern hier in Forum über dein Project gestolpert bin habe ich
mich direkt verliebt...

Hier nun meine Frage: ich habe noch ein paar alte 2,3,486 Boards im
Keller rumfliegen... Du verwendest die Chips von den RAM-Riegeln? Wenn
ja woran erkenne ich ob die Teile die passenden Timings haben?

Gruß
Patrick

nö, die Cache IC´s. Nich die IC´s von den Dimm Modulen.
Gesucht sind die einzelnen "langen" IC´s.
zB. W24257. Aber Vorsicht, auf 2 und 386érn sind die "normalen" DRAM
auch manchmal noch einzelne IC´s ! Aber die sind kürzer.
Die "richtigen" haben 28 Pins bei 7,25 mm Abstand zwischen den Pinreihen
!!

zB. hier 386ér bei Cache

http://stason.org/TULARC/pc/motherboards/C/CORE-PA...

oder 486ér

http://stason.org/TULARC/pc/motherboards/S/SOYO-CO...

Es gibt immer noch schnelle SRAMs, guck mal bei CSD, der hat welche mit
12ns.

@Stephan

Danke, werde gleich mal im Keller suchen gehen...

@Michael U.

Habe deine LAs mal im Wiki eingepflegt und würde dich bitten mal auf
Korrektheit drüber zu schauen oder zu löschen wenn's dir nicht passt

http://www.mikrocontroller.net/articles/Logic_Analyzer

Hallo,

Danke für die Blumen. :-)

Nein, nicht die von den Ram-Riegeln.
Externer Cache in passender Version war auf den letzten 486er
(486DX2..DX4) und den AMD K5/K6 usw. drauf.
Sind DIL28 üblicherweise zu 8 Stück + 1x TAG-Ram der nicht immer
bestückt war. Ist eben auch bei mir schon ziemlich lange her mit diesen
Boards...

Bezeichnungen enden oft mit xx64-yy oder xx65-yy oder xx256-yy und
xx257-yy

xx Hersteller eigene Bezeichnung, 64/65 sind 8kx8, 256/257 32kx8.
Hinter dem Strich dann die Zugriffszeit. Üblich -12/-15/-20/-25.
Sind jeweils Nanosekunden. 25ns ist vermutlich zu langsam bei 50MHz, für
die 80Mhz sollten es 12ns sein, 15ns läuft hier aber auch noch.

Ich sortiere demnächt mal meine Vorräte, ein Bekannter hat auch noch was
aufgehoben. Falls dann jemand keine findet, läßt sich da auch was
machen.

Irgendwo oben hatte jemand einen Link zum großen C gepostet, die sollten
gehen. Allerdings stört mich da, dsß laut Typenbezeichnung -20 gelich
-12 sein sollen und in den Daten an der Seite dann 15ns steht.....

Gruß aus Berlin
Michael

Bei CSD-electronics gibt es das IS61C256AL-12JLI für 2.15 EUR.

grundsätzlich würde der 62256 "funktionieren".... ABER
Der ist viiiiiiel zu lahm. 70 ns oder langsamer.
Außerdem hat der 15 mm Pinreihenabstand.

> K6R1008C1D-JC10

Ich denke der sollte gehen.

Bei Mercateo gibt es auch noch 32kx8 12ns von Lyontek
http://www.mercateo.com/p/live~s.0*115-648331/LY61...

Die sollten doch auch gehen, oder?

Hallo,

hab jetzt auf ner alten Soundblaster nen KM416C256BJ-7 gefunden
Laut Datasheetsuche: KM416C256D=256K x 16Bit CMOS Dynamic RAM with Fast
Page Mode
Würde der gehen?
Alternativ habe ich 8Stk Alliance AS7C256-20PC gefunden?!

Hi Patrick

Patrick Weggler schrieb:
> Alternativ habe ich 8Stk Alliance AS7C256-20PC gefunden?!

Die würden gehen, vermutlich bis 40Mhz, mit Glück bis 50MHz

Kleiner Tip: unbekannte Bauteile bei www.alldatasheet.com eingeben
Dort finde ich meistens ein Datenblatt oder einen Hinweis auf das Teil.
Für diesen LA wird "High Performance SRAM" benötigt. DRAM oder normales
SRAM mit 70ns ist ungeeignet.

mfg
Harri

Die speicher geschwindigkeit beschreibung ist etwas 'unglücklich'.

Bei normallen srams ist die bezeichnung -10, -12, -15 , -20 eher ein
100, 120, 150 oder sogar 200ns - vor allem beim älteren modellen.

Bei "cache" sram jedoch bedeutet -12 genau 12ns.

Ich habe hier aber auch "normalles" srams die mit 10ns gehen, also immer
datenblatt suchen und gucken was da drin steht.

Hallo,

so, ich habe jetzt mal meine Kiste mit Rams durchgekramt.
Dabei ergab sich noch eine Erkenntnis:
Kritisch ist das Timing der Adresszähler im Zusammenhang mit der
Betriebsspannung. An meinem alten Thinkpad mit passiven USB-Hub
dazwischen gibt es Aussetzer bei 80MHz. Es zählen manchmal nicht alle
ACT161 mit.
Am USB des großen Rechners gibt es das Problem nicht, Betriebsspannung
vom USB ist da auch nahe 4,8V, am Laptop nur rund 4,6V.
Ich werde mir wohl doch mal ACT161 von ST besorgen und testen.

Grundsätzlich: 12ns bei 80MHz sind mehr oder weniger Pflicht, 15ns geht
wohl nur Exemplarabhängig, 20ns geht mit 50MHZ, 25ns mit 40MHz.

Das Verhältnis zu den Zyklszeiten der Rams passt also sehr genau und
quer durch alle Hersteller, die ich hier habe.

Bei anderen statischen Rams wird wohl nur ein Versuch entscheiden, das
Zyklus-Timing der Cache-Rams ist anders als das üblicher statischer
Rams.

Ich habe bei der 80MHz-Version noch so umgelötet, daß beide Versionen
sich nur noch im Prozessor und den 74LS164 und dem Takt unterscheiden.

Es spricht nichts dagegen, die Version mit dem 40-Pin AVR mit 50 und
20MHz Oszillatoren ohne den 74ACT74 zu bestücken oder umgekehrt.

Wenn man 80MHz und Teiler draufhat und der Ram oder der Aufbau ungünstig
ist un nicht mit 80MHz will, kann man das eben einfach ignorieren und
hat max. 40MHz oder man ersetzt den Takt durcuh die andere Version und
hat max. 50MHz.

Die AVR-Quellen führe ich als nächtes zusammen, die jeweilige Version
ist dann leicht einzustellen und neu zu assemblieren, von den Versionen,
die ich hier selbst zumindest getestet habe, lege auch die Hex-Files ins
Archiv.

Ich kann auch noch ein paar Rams, allerdings im Moment nur 20ns,
abgeben, falls jemand nichts auftreibt.
Ob ich noch schnellere bekomme entscheidet sich erst am Wochenende.

Schaltpläne kommen noch heute auf die Webseite, AVR-Files vermutlich
morgen.

PC-Programm ist noch getrennt und nur für meine beiden Versionen, das
wird aber auch noch zusammengeklebt. ;-)

Gruß aus Berlin
Michael

Hallo,

lustiger Nebeneffekt: Samplerate 80MHz, Signale von einem mit einem
anderen 80MHz Quarzoszillator mit einem 74HCT4040 runtergeteilt.

Kanal 0 ist der 40MHz Takt, links sieht man die Interferenz zwischen
Sampletakt und Daten, wenn sie fast phasengleich sind.

Die Durchgänge erfolgen etwa alle 15s, wer Lust hat, kann jetzt die
relative Frequenzdifferenz zwischen den beiden Oszillatoren ausrechnen.
;-)

Die Unregelmäßigkeiten in Kanal 3 und 5 sind nur Skalierungsfehler, dort
sind die Signale vollig ok, ich habe aber extra nicht gezoomt.

Gruß aus Berlin
Michael

Hallo,

hab jetzt mal bei Farnell 2 Gefunden (leider TSOP-2)
http://de.farnell.com/gsi-technology/gs71108agp-12...

http://de.farnell.com/gsi-technology/gs71108agp-10...

Der 2te wäre sogar 10ns Version

Gruß
Patrick

Falls wer den oben genannten RAM benötigt. Ich habe noch 5 unbenutzte
Exemplare. 3.3€ + Versand. Bei Interesse: PM

Hallo,

danke für den Hinweis, da legen doch falsche Pläne oben......
Der fehler ist reingekommen, weil cih z.Z. ja noch mit 16k arbeite, zum
Wochenende werde ich aber die PC-Software da auch angepasst haben, dann
gehen auch die vollen 32k und der jetzige Plan stimmt dann auch.

PS: warum muß ich bei Firefox erst den cache löschen, damit er mir den
richtigen Inhalt der Seite anzeigt???

Ein erzwungener Reload sollte doch eigentlich reichen?

Gruß aus Berlin
Michael

Ich habe mal alle Hardware versucht in ein CPLD Design zu stopfen:
Beitrag "Re: wie groß muß das CPLD ungefähr sein ?"

Dabei habe ich mir allerdings eine Frage gestellt:
Wie syncronisierst du das ganze?
Die Zähler werden ja nirgends zurückgesezt, und ne Art Feedback
'TimerOverflow' oder so konnte ich auch nirgends entdecken. Machst du
das in SW?

Das habe ich mich auch schon gefragt. Irgendwie muss das ganze doch
zumindest auf einen gemeinsamen Start synchronisiert werden?

Sven

also ich nehme an das die Zähler sich alleine nullen beim Einschalten,
und dann läuft alles genau 1 Mal durch und steht dann bei 0.
Mal sehen was Micha dazu sagt..

Naja das Problem ist bei 80Mhz "Haupttakt" muß der AVR auch rechtzeitig
wieder stoppen um nicht die ersten Ergebnisse wieder zu überschreiben...
Ansonsten ist der StartWert des zählers (relativ) egal.

Hallo,

genau, der Startwert ist eagl und auch nicht bekannt.
Takt freigeben und sampeln bis in alle Ewigkeit als Ringbuffer.
Der AVR weiß, wieviel % als Pretrigger gewünscht sind und damit, wieviel
Ram vor dem Triggerpunkt und wieviel dahinter liegen sollen.

Im AVR wird dieser Anteil als Teil der Speichergröße und abhängig vom
Sampletakt und der konstanten Laufzeit der Warteschleife im AVR in ein
Register geladen.
Dann wird nur abgefragt, ob der Trigger aktiv wurde.
Ab da wartet der Atmel in besagter Schleife die nötige Taktanzahl ab,
bis das relative Ende im Ram erreicht sein müßte und stoppt den
Sampletakt.

Bei Raten, die langsamer als die Laufzeit im AVR sind, zeigt der Zähler
dann auf den relativen Ramanfang.

Der Raminhalt wird ab da in voller Länge zum PC gschickt, der weiß ja
auch, wo er den Triggermarker hinmalen muß.

Problematisch sind alle schnelleren Sampleraten. Hier ist eine
Ungenauigkeit in Länge eines Schleifendurchlaufs * Samplerate/AVR-Takt
drin.

Die PC-Software sucht jetzt einfach im Bereich -xxx bis +xxx so die
Triggerbedingung genau aufgetreten ist und setzt da den Marker.

Bei vollem Bereich wird wird etwas anders verfahren, damit er nicht in
eine mögliche Überlappung mit dem Ende reingerät.

Es werden deshalb auch nur 4000 bzw. 16000 Sample dargestellt, der Rest
zu 4096 bzw. 16384 ist meine stille Reserve für solche Fälle.

Die grundsätzliche Idee dazu stammt aus den LoLa-Sourcen, allerdings
hatte er das Problem nicht, weil er die Triggerbedingung per Software
auswertete und die Steuerung komplett der AVR machte (nur recht geringe
Sampleraten).

Gruß aus Berlin
Michael

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.

VCP. Geht wunderbar.

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.

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.

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,

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

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,

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

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

Hi,

glaube die waren von Pollin, meine mal was gelesen zu haben!

http://www.pollin.de/shop/shop.php?cf=produkt.php&...


Gruß,
Michel

Kann ich denn statt des Mega16 auch einen Mega32 benutzen? Habe hier
nämlich noch den alten von meinem AVR-NET-IO herum kullern (der hat
einen 644 bekommen) und bräuchte mir dann keinen neuen kaufen.

Nach den Strippen wollte ich dich auch noch fragen. Haben die von Pollin
eigentlich nur einen Haken vorne oder ist da so eine 3fingrige Klemme
vorne dran?

Gruß Sven

Hallo,

ja, Du kannst auch einen Mega32 oder Mega644 nehmen, CPU-Definition
solltest Du aber anpassen und neu assemblieren.

@Gast (Gast): ich werde zwar Änderungen in der Software auch in der
Mega16-Verion anpassen, für nögliche Erweiterungen ist aber die Mega88
(Mega48 reicht auch) Version.

Man kann natürlich auch bei der Mega16 Version einen 74ACT161 mehr
reinlöten und 32k Ram nutzen, die Anpassungen in der AVR-Software sind
minimal, der PC-Software ist es egal. Die will nur den maximalen Takt
und die Speichergröße vom AVR mitgeteilt bekommen.

Es ist keine vollständige Nachbauanleitung und wird auch es auch nie
werden, die gezeigten Varianten laufen hier, Taktversionen und
Speichergrößen sind aber prinzipiell austauschabr, nur eben nicht von
mir getestet.
Man sollte dann aber ein wenig AVR-Assembler können, um da anzupassen zu
können.

Ich helfe da gern, werde aber sicher nicht diverse Kombinationen aus
AVR-Typ/Speichertakt/Speichergröße assemblieren und kann die auch nicht
hier testen.

AVR-Takt ist 16MHz oder 20MHz nötig, bis zur halben Taktfrequnz (also
8MHz oder 10MHzerzeugt der AVR den Speichertakt, die häheren sind
prinzipiell egal, allerdings müssen dann die Tabellen angepasst werden.

Die Messklemmen habe ich mal geschenkt bekommen, die sind sicher schon
20 Jahre alt......

In die Leitungen ist nahe am Klemmenende jeweils ein 68 Ohm in die
Leitungen gelötet, eigentlich, weil ich einen Fehler durch Reflexionen
vermutet hatte, der sich nicht bestätigt hat, sie sind aber
dringeblieben.

Der 74ACT541, den ich im Eingang habe, kommt auch mit 3,3V-Logik bei
meinen Sensormodulen ohne Probleme klar.

Gruß aus Berlin
Michael

Gruß aus Berlin
Michael

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,

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,

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

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,

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

Hallo,

anbei die geänderte Version.

Signale liegen jetzt alle so wie beim Original PB2 liegt jetzt an Pin1
(G) des 688

Gruß
Patrick

Hallo,

ich sitze grad am zweiten Teil des Layouts und frage mich ob ich S1 noch
benötige und wenn ja wozu?

Gruß
Patrick

Hallo,

noch eine Frage;

So weit ich die Schaltung verstanden habe kann ich die Adressleitungen
zwischen den 161ern und dem RAM lustig vertauschen?

Patrick Weggler schrieb:
> Hallo,
>
> ich sitze grad am zweiten Teil des Layouts und frage mich ob ich S1 noch
> benötige und wenn ja wozu?

Wenn kein 8kx8 bestückt werden soll, kann er ganz weg.
Beim 8kx8 ist auf dem Pin ein zusätzlicher H-aktiver Chipselect.
Kann man natürlich auch eine Lötbrücke oder 0-Ohm Widerstand nehmen.

>So weit ich die Schaltung verstanden habe kann ich die Adressleitungen
>zwischen den 161ern und dem RAM lustig vertauschen?

Ja, kannst Du.
Die Daten vom Ram selbst kannst Du auch anschließen, wie Du willst.
Die Zuordnung ist nur zwischen Eingang und AVR wichtig, damit die
Kanalzuordnung stimmt und die Triggerdaten/Triggermaske und AVR müssen
natürlich bitweise auch stimmen. Welche Gatterpins da landen und an
welchem Eingangspärchen des 688 die landen, ist ja auch egal.

Gruß aus Berlin
Michael

Da muß ich mal meinen laienhaften Respekt bezollen.

Sehr schönes Projekt, sehr gut beschrieben. Das wird wohl eins meiner
nächsten Projekte sein. Oder eher eines der ersten. Sowas kann man ja
immer gut gebrauchen.

Also 10 Daumen für dieses schöne Projekt. Könnte man das nicht als
Artikel hier einstellen, oder gibt es das schon und ich hab's überlesen?

Hallo,

erst einmal danke für die Antworten...
ich würde gerne 32kx8 verwenden.

Wozu dient der nicht angeschlossene PB3?

Gruß
Patrick

Hallo,

Shift_Data Shift_Clock von der SPI werden eigentlich auch nicht
benötigt?
Oder habe ich die 3 Signale irgendwo verlohren?

Gruß
Patrick

Hallo,

"habe fertisch"

Anbei das Ergebnis; alle Sachen diesmal der besseren Lesbarkeit wegen
als PDFs.

Wie auch beim letzten mal würde ich euch bitten mal drüber zu sehen ob
sich Fehler eingeschlichen haben (gerade die fehlenden 3 Signale)

Am Part 1 habe ich nichts mehr geändert.

Ist jetzt auf 16kx8 bzw. 32kx8 ausgelegt, wie auch beim Part 1 sind alle
Teile bei Angelika zu bekommen.

Part 1: 160x100mm
Part 2: 100x100mm, so das beim Stecken der Eingang nach vorne schaut.
geplant habe ich das beides zusammen + Netzteil in das TEKO KL12 passt.

@Michael U. (amiga):
Wenn du willst kannst du das Ding auf deine Homepage draufpacken, um
anderen u.U. die Arbeit zu ersparen.

Gruß
Patrick

Wo sind den die PDF s?

Hallo,

Patrick Weggler schrieb:

> Shift_Data Shift_Clock von der SPI werden eigentlich auch nicht
> benötigt?
> Oder habe ich die 3 Signale irgendwo verlohren?

Nein, hast Du nicht verloren.
Data und Clock von den Schieberregistern sind nur rausgeführt für evtl.
Erweiterungen, genauso der freie PB3.
Bei mir (Lochraster) sind sie bis jetzt nur auf dem Steckverbinder zum
Teil 2.

Dort ist ja der Anscshluß nach draußen (Eingänge) und da sind eben noch
ein paar Stifte mehr angedacht, um z.B. extern einen ADC oder aktive
Probes oder was-auch-immer anzustecken.

Da gibt es schlicht noch nichts und da ich ja auf Lochraster den noch
verbliebenen Platz auch einfach noch nutzen kann, ist auch noch unklar,
ob oder was da passiert.

Externer Trigger und externer Takt ist auch angedacht usw.

Sicher ist nur, daß ich für mich am Teil mit dem AVR nichts mehr
verändern werde.
Naja, fast nichts???
Wenn ich noch einen 32kx8 in 12 oder 10ns finde, werde ich vermutlich
den 50MHz Quarzoszillator durch einen 80MHz ersetzen und den 20MHz durch
einen 74ACT74 wie bei der Version mit dem Mega16 und schauen, ob 80MHz
auch da stabil gehen.

Gruß aus Berlin
Michael

Hallo,

war wohl doch zu spät...

Anbei die Dateien

Gruß
Patrick

Hallöchen!

Michael U. schrieb:
> Wenn ich noch einen 32kx8 in 12 oder 10ns finde, werde ich vermutlich
> den 50MHz Quarzoszillator durch einen 80MHz ersetzen und den 20MHz durch
> einen 74ACT74 wie bei der Version mit dem Mega16 und schauen, ob 80MHz
> auch da stabil gehen.

Nur mal so zur Info:
Ich hab hier ein altes Acer-Mainboard aus dem Schrott gezogen (Chipsatz
Ali 1531, für Pentium MMX, hat noch 'normale' Spannungsregler mit fetten
Kühlkörpern drauf). Das sitzt doch tatsächlich ein Tag-RAM mit 10ns und
5V Betriebsspannung drauf. Hab gar nicht gewusst, dass es diese
Kombination gibt/gab.

Vielleicht brauchten die Chipsätze von Ali und evtl. auch Via etwas
flottere Tag-RAMs als die Intel Chipsätze und diese Mainboards sind
damit eine gute Quelle für socleh Bauteile.
Mein Asus T2P4 mit Intel Chipsatz (passend für die gleichen CPUs) hat
nur ein 15ns Tag-RAM.

Man muss allerdings den SMD-Chip vom Board ablöten :-)

mfg
Harri

Patrick Weggler schrieb:
> Hallo,
>
> war wohl doch zu spät...
>
> Anbei die Dateien
>
> Gruß
> Patrick

Hallo Patrick,

super Arbeit!
Würdest Du auch die Eagle Files zur Verfügung stellen?
Für die Leute (wie ich) die eventuell noch etwas verfeinern oder
ergänzen möchten.

1000 Dank Patrick!
1000 Dank auch dem Threadstarter Michael für dieses einmalige Projekt!!
Hut ab!

Hallo,

anbei die Files

Gruß
Patrick

Genial!
Vielen Dank

Gruß
Thomas

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

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

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

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

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?

Noch mal in eigenen Worten:_
Es werden externe AD-Wandler verwendet, die rasendschnell selbstständig
wandeln und die Sampleergebnisse ebenso schnelll intern speichern, um
sie dann irgendwann mal gemütlich dem Controller zu übergeben?

es werden keine AD-Wandler benutzt da es sich um einen Logic-Analyzer
handelt und nicht um eine Oszilloskop.

ansel schrieb:
> Ein
> Perl-Skript macht daraus  .vcd-Dateien, die man z.B. mit gtkwave
> betrachten kann.

Hi,
sag mal, ist es möglich, dass ich dieses Perl Script bekommen könnte?
Ich versuche grade aus nem großen Logic Analyzer, den wir beim CCC
stehen haben Daten rauszubekommen. Sobald ich das geschafft habe, wollte
ich die ein wenig verwursten, um mir sie in GTKWave anschauen zu können.
Da könnte ich mir ein bischen was bei dem Teil abgucken.

Grüße,
Andreas

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

Hallo Michael,

ich habe den LA auch nachgebaut, allerdings mit etwas geänderter HW:

- ATmega48 @20MHz
- RAM Takt 50MHz
- 32Kb Cache RAM, 17ns (ja so was gibt's auch !)
- alle Logik in einem Xilinx XC9572 PC44 CPLD
- MAX232 mit 38400 Baud (bei mehr ist die Kommunikation nicht stabil)

Läuft auch soweit schon, nur wird bei 50MHz nur etwa das letzte Viertel
des RAMs beschrieben, der Reset ist 0xFF. Die angezeigten Daten in
besagtem letzen Viertel sind plausibel und das RAM ist ja auch schnell
genug. Bei 20MHz funktioniert alles ohne Probleme.
Es scheint mir, als ob der Atmega das Sampling zu früh beendet.

1.) Kann ich für oben genannte Kombination die vorhandenen Tabellen in
avrstudio_minilog28.zip (akutelle Version auf Deiner Website) verwenden
oder sind Anpassungen notwendig ?

2.) Wie sind die Tabellen aufgebaut ?
- Timer-Reload-Wert zur Erzeugung von Frequenzen kleiner 20MHz
- Rest-RAM Größe ?
- Wartezeit ?

Was haben die beiden letzten Werte für eine Bedeutung ?
Wie hängen diese Werte mit der Frequenz und der Speichergröße zusammen?

Gruß Bernd

Bernd Geyer schrieb:
> Hallo Michael,
>
> ich habe den LA auch nachgebaut, allerdings mit etwas geänderter HW:
>
> - ATmega48 @20MHz
> - RAM Takt 50MHz
> - 32Kb Cache RAM, 17ns (ja so was gibt's auch !)
> - alle Logik in einem Xilinx XC9572 PC44 CPLD

Kannst du evtl. das CPLD-Design zur Verfügung stellen?

Viele Grüße,
Alex

Hallo,

Bernd Geyer schrieb:
> ich habe den LA auch nachgebaut, allerdings mit etwas geänderter HW:
>
> - ATmega48 @20MHz
> - RAM Takt 50MHz
> - 32Kb Cache RAM, 17ns (ja so was gibt's auch !)
> - alle Logik in einem Xilinx XC9572 PC44 CPLD
> - MAX232 mit 38400 Baud (bei mehr ist die Kommunikation nicht stabil)
ok, da sollte es keine unlösbaren Probleme geben.
Ein MAX, der keine 115200 stabil macht? Ist zumindest mir noch nicht
passiert...

> Läuft auch soweit schon, nur wird bei 50MHz nur etwa das letzte Viertel
> des RAMs beschrieben, der Reset ist 0xFF. Die angezeigten Daten in
> besagtem letzen Viertel sind plausibel und das RAM ist ja auch schnell
> genug. Bei 20MHz funktioniert alles ohne Probleme.
Deute darauf hin das, der Adresszähler irgendwelche Probleme hat und die
oberen Stufen nicht mitzählern. War zumindest bei den 74ACT161 dann das
gleiche Fehlerbild.
> Es scheint mir, als ob der Atmega das Sampling zu früh beendet.
Glaube ich weniger, das wäre schon aufgefallen.
Der AVR macht die schnellen Raten nur mit einer (taktgenauen)
Warteschleife, nachdem Trigger erkannt wurde bzw. ab sofort, wenn kein
Trigger gesetzt ist.
Der Pre-Samplewert legt ja nur fest, wie lange nach Start bzw.
Triggerbedingung gewartet wird.
Bei kein Trigger und 0% Pretrigger dauert die Zeit also immer solange,
wie zum samplen bei 50MHz gebraucht wird, maximal kann es ein paar
Sample Fehler geben, weil die Auflösung des AVr ja kleiner ist ist als
die 20 oder 50MHz Sampletakt.
>
> 1.) Kann ich für oben genannte Kombination die vorhandenen Tabellen in
> avrstudio_minilog28.zip (akutelle Version auf Deiner Website) verwenden
> oder sind Anpassungen notwendig ?

50MHz bei 20MHz AVR-Takt ist meine ursprüngliche Version und die stimmte
(mit an Sicherheit grenzender Wahrscheinlichkeit ;-)), das hätte sonst
schon bemerkt.

> 2.) Wie sind die Tabellen aufgebaut ?
> - Timer-Reload-Wert zur Erzeugung von Frequenzen kleiner 20MHz
> - Rest-RAM Größe ?
> - Wartezeit ?
Die Tabelle in definitionen mit den Taktwerten
.equ  CLK_20M      = 0    ; -> 100ns
.equ  CLK_10M      = 0    ; -> 100ns
.equ  CLK_5M      = 1    ; -> 200ns
sind direkt die Werte für den Counter des AVR, um im CTC-Mode den Takt
zu erzeugen.
Bei 20 und 50MHz werden die ignoriert.

In der Tabelle werden gesetzt:
 .dw CLK_20M          ; 1    20MHz ->   50ns
 .dw BUF_LEN_MAX / 10 ; Rest-Zähler für vollen Bereich
 .dw 1                ; Warteschleife, 20 Takte, -> 1MHz

1. Der Takt für den CTC-Mode

> Was haben die beiden letzten Werte für eine Bedeutung ?
> Wie hängen diese Werte mit der Frequenz und der Speichergröße zusammen?

2. Die "virtuelle" Anzahl Bytes, die in den Speicher passen.
Virtuell deshalb, weil ein Durchlauf der AVR-Schleife für die Zählung 10
Takte benötigt, das sind 2MHz für die Zählroutine im AVR. Bei 20MHz
externem Clock und 32768 Byte Ram ist der also nach 32768/10
(20MHz(ext)/2MHz(AVR) komplett voll.
Ab da, wo der AVR es schafft, schnell genug mitzuzählen (also 2MHz und
langsamer) gibt es keine Korrektur mehr.

Der 3. Wert ist die Warteschleife zwischen 2 Samples bei kleineren vom
AVR erzeugten Sampleraten.
Ich zähle nicht die CTC-Takte, sondern warte einfach Taktgenau, ist ja
syncron zueinander und ich brauchte nicht 2 Varianten für schnelle und
langsame Sampleraten.

Kontrolliere mal vorsichtshalber, ob die MUX_Tabelle
.equ  MUX_INT      = 0b00000000
.equ  MUX_20MHZ    = 0b00000100
.equ  MUX_50MHZ    = 0b00001000
.equ  MUX_EXT      = 0b00001100
zu Deiner Beschaltung passt, ich hatte da so oft bei mir umgebaut, das
ich da immer im Zweifel bin.....

Wenn Du was da hast, kannst Du auch messen, wie lange die Samplefreigabe
bzw. das Enable des Eingangsbuffers aktiv sind. Das muß zeitlich zu
50MHz und Ramgröße passen.

Eigentlich sollte ja längst noch ein Update der Homepage passieren,
allerdings ist meine Zeit etwas knapp und außerdem hat mein Bekannter
seine Version inzwischen zusammengelötet (Mega88, 32k Ram, bis 80MHz
Takt) und prompt noch ein paar Fehler gefunden, die ich in die Software
beim Ändern eingebaut habe...

Das muß ich erstmal korrigieren un dmit ihm testen.

Das betrifft aber NICHT die Version von der Webseite, die läuft bei mir
ohne bekannte Fehler mit diesen Tabellen bei 50MHz und 20MHz AVR-Takt.

Gruß aus Berlin
Michael

Hallo Michael,

danke für die Erläuterung der Tabellenwerte und den Tipp mit dem
Multiplexer!
Das war's natürlich, die Select-Eingänge paßten nicht zu der vom ATmega
gewünschten Sample-Frequenz! Da hätte ich auch selbst draufkommen können
:-(

Ein Timingproblem der Adressleitungen kann ich ausschließen, das CPLD
ist schnell genug. Jetzt muß ich mir nur noch ein entsprechendes
Cache-RAM besorgen und die 80MHz sind geknackt ;-)

Zum Thema MAX232:
Der hängt über einen RS232-USB Wandler am USB1.1 meines Notebooks.
Ich habe zwei unterschiedliche Varianten von verschiedenen Herstellern,
der eine rennt noch nicht mal mit 38400 Baud sauber, der andere macht
nur bei höheren Baudraten Probleme und 'verschluckt' gerne die ersten
oder letzten Zeichen der Übertragung.

Wie dem auch sei, mein Nachbau funktioniert nun soweit und das reicht
mir (erst einmal).

Gruß und Danke
Bernd

Hallo!

Würde auch gerne eine "aktuelle Version" des LA nachbauen. Dabei
interessiert mich vor allem die Version mit CPLD. Kann evtl. jemand mal
eine kurze Stückliste nennen?

Welchen CPLD sollte man idealerweise kaufen wenn man ihn eh nicht in der
Grabbelkiste hat? Wie bekommt man den CPLD programmiert?

Welche Latches? HCT, ACT?

Hat jemand mal überlegt anstelle der 486/586 Cache-RAMs RAMs aus einem
Pentium II Slot1-Modul zu nehmen? Die sind mit 4,4ns - 7ns nochmal
schneller (und evtl. größer).

Vielen Dank!

Gruß
Robert

Hallo Robert,

meine Stückliste sieht z.Zt. so aus:

- 80MHz Oszi
- ATMega48 @ 20MHz (eigenes Quarz)
- Cache-RAM 32k*8  (leider z.Zt. nur 17ns)
- 74HC245          als Eingansbuffer
- z.Zt. noch MAX232 als RS232 Treiber

XC9572XL-10 CPLD (ja ich weiß, ist nur ein 3,3V Typ aber mit 5V
tolleranten I/Os)
Kostet z.B. beim großen R im plcc44 Gehäuse 3,40EUR.
Die 3,3V sind unkritisch und man kann sie von den 5V mit 2 in Reihe
geschalteten 1N4148 'erzeugen'. (Für die Kritiker: Nicht die feine
englische Art, funktioniert aber! Ich hatte halt keinen 3,3V LDO Regler
da. Und laut Datenblatt verkraftet das CPLD bis zu 4V absolutes max)

Das CPLD ist zu ca. 60% belegt. Ich bin gerade dabei, die Trigger-Logik
zu erweitern (Externer Trigger konfigurierbar auf High/Low Pegel, ect.)
Außerdem spiele ich mit dem Gedanken, das Ganze auf 16 Kanäle zu
erweitern (was 2 weitere 74hc245 + Cache-Ram bedeuten würde). Leider
gehen mir die freien Pins am CPLD aus.

Zum Programmieren des CPLDs bietet sich die freie Webpack-SW von Xilinx
an. Ein Programmieradapter ist auch nicht aufwendig zu bauen (such' mal
nach xilinx jtag cable)

Natürlich kann man auch CPLDs von anderen Herstellern nehmen, man sollte
aber vorher ausprobieren (mit der Entwicklungssoftware des Herstellers)
ob alles reingeht.

Cache RAMs aus 'neueren' Rechnern sind meistens SMD bzw. 16 oder 32 Bit
breit. Aber prinzipiell kann man die schon nehmen. Das bedeutet
natürlich auch einen breiteren Daten/Adressbus, wofür man wieder mehr
Pins am CPLD benötigt.

Wenn meine Umbauten und Erweiterungen fertig sind, kann ich hier ja mal
Schaltplan/VHDL/µC-Software posten.

Gruß Bernd

Hallo!

Um mal die Idee des Pentium 2 Cache zu beleben: Habe heute einen Slot1
Pentium geopfert und ihm beide Cache-Chips per Heißluft entrissen. Die
Bezeichnung lautet TC55V2377AFF-250.

Leider finde ich nur das Datenblatt für den TC55V2325FF-100. Dieser hat
64k words x 32 bits und scheint auch Pinout-mäßig mit dem im Slot1-Modul
verbauten Chip zu 99% identisch zu sein. Die Kapazität passt auch, der
Pentium II ist mit 2 Cache-Chips mit 512 KB angegeben.

Wenn das Bezeichnungsschema stimmt sollte der Speicher mit bis zu 250
MHz laufen. Zudem ist ein interner Burstmode verfügbar der die letzten 2
Bits inkrementieren kann.

Gruß
Robert

Bernd Geyer schrieb:

> Wenn meine Umbauten und Erweiterungen fertig sind, kann ich hier ja mal
> Schaltplan/VHDL/µC-Software posten.
>

das wäre nett :) Habe noch paar XC9572XL-5 die "benutzt werden möchten".

@Michael U, sind die Verbesserungen jetzt Online auf deiner HP
verfügbar?

Hallo,

wie angekündigt stelle ich hier meine Modifikationen bzw. den Umbau der
Schaltung (80MHz Variante) auf ein XILINX XC9572 CPLD zur Verfügung.

Die Zip-Datei enthält die (geänderten) Sorucen für's CPLD und den µC,
Schaltplan und ein Readme.

Die Original-PC-Software von Michael unterstützt die neuen Featrues
leider (noch) nicht. Trotzdem kann man die PC-Soft mit der modifizierten
HW benutzen (eben halt nicht alle Features).

Der Schaltplan und die µC-Software sind schon auf 16 Kanäle vorbereitet,
ich werde in den nächsten Tagen den Schaltplan für das Aufsteckboard
(Erweiterung auf 16 Kanäle) hier bereitstellen.

@Michael:
Könntest Du mir Deine PC-Sourcen per PM schicken. Ich würde dann die
notwendigen Erweiterungen einbauen.

Gruß Bernd

Bernd, würdest Du ggf. die original Eagle Daten zur Verfügung stellen?

Vielen Dank!
Gruß
Thomas

Hallo,

anbei die Eagle-Dateien und der Schaltplan für die 16-Kanal-Erweiterung.

Bisher gibt's noch keine SW-Unterstützung für die 16 Kanäle.

Gruß Bernd

Bernd,

vielleicht könntest du anstatt minila z.b. microla, superla, was auch
immer, "minila" ist ein bekanntes LA, so ist namenswahl vielleicht etwas
verwirrend.


gruss

Thomas

Hallo,

Ich interessiere mich auch für einen Nachbau. Hat jemand schon ein Print
in Auftrag gegeben und könnte ich mich da anschliessen?

Gruss, Tefi

Hallo zusammen,

hat jemand die 50MHz-Version mit 28-poligem AVR aufgebaut und den
externem Takteingang zum laufen bekommen?

Ich kann den externen Clock in der PC-Software gar nicht auswählen,
obwohl er ja in der AVR-Firmware und im Schaltplan vorgesehen ist.
Und Michael ist per Mail dummerweise nicht erreichbar :-(

mfg
Harri

Hallo,

sorry das ich so schweigsam war, bin zur Zeit ein wenig mit Krankheit
gestraft (nein, keine Schwein... ;-)).

Ich schicke morgen die VB-Sourcen rau7s an die, die angefragt hatten.
Außerdem baue ich den Extern-Clock schnell mal ein, der ist z.Z. einfach
nicht da...

Gruß aus Berlin
Michael

Hi Michael,

danke für's einbauen und gute Besserung.


mfg
Harri

Hi Michael,

Hi Michael,

(Sorry in English)

I have built your Minilog40 design.

I made the following change to your design to save space:
- I implemented the 7474 and 74161's in an FPGA (EPM7064)
- added an extra 74161 (in the FPGA), to extent the RAM
  addressing range to 15 bits. (32kb)
- change the SRAM to an 32kx8 type.
- some changes in the firmware to make it all work.

The USB-RS232 pcb at the right side of the PCB
and the 20Mhz Xtal is underneath it.

I would like to receive a copy of the VB source.
I want to make a full english version and maybe add some enhancements
which I will share with you.

Many thanks !

Henk
Netherlands

ansel schrieb:

> Ich hab' mir ein paar Gedanken zum Interleaving gemacht: Die einzige
> Möglichkeit, die ich derzeit sehe, ist, einen zweiten Adresszähler mit
> invertiertem Takt zu betreiben.  Sieht jemand vielleicht einen
> eleganteren Weg, die phasenverschobene Aufnahme zu erreichen?

Da zumindest mit den von mir benutzten Rams die Laufzeiten der Zähler
schon an der Grenze sind und die Zykluszeit der Rams schon etwas
außerhalb des Datenblattes, dürfte es die einzige Mglöichkeit sein.
Die Idee ist reizvoll, der Mehraufwand von 1x Ram + 4x 74ACR161 würde
das Teil auf 160 MHz Samplerate bringen... Hmmmm...

Gruß aus Berlin
Michael

Hallo,

ansel schrieb:
> Probleme:
>
> - 16-Kanal ist über USB-Stromversorgung (2,5 Watt) nicht mehr
>   machbar (1 Watt pro chip)[3]
Muß ich mal messen, ich habe 140mA in Erinnerung bei den 32kx8.

> Noch eine Idee zur Implementierung: Die SRAMs sollte man über CS
> statt WE takten.  Laut allen mir vorliegenden Datenblättern wird das
> unterstützt.  Das hat dann folgende Vorteile:
Nach meinen Datenblättern ist die Zugriffszeit über /CE fast doppelt so
hoch wie über /WE, auch da muß ich genauer schauen.

> - Man benötigt keine externe NANDs mehr; es werden quasi die
>   internen zwischen CS und WE/OE verwendet.  Bei ausschließlich
>   externem Trigger ist somit kein 7400 mehr erforderlich.

> - Für's Auslesen ist keine zusätzliche Steuerung nötig.
Die würde mich am wenigsten stören. Das ist außer etwas höherer Last
durch zusätzliche Bustreiber vom Timing her unkritisch. Der AVR kann da
so langsam lesen, wie nötig.

> Ich hätte leider frühestens ab April Zeit, mich an einem Prototypen
> zu versuchen.  Würde ja zu gerne jetzt schon die Performancekrone an
> mich reissen :-).

Naja, ich muß mir das mal ganz langsam auf der Zunge zergehen lassen und
meine Bestände prüfen und passend ergänzen....

Gruß aus Berlin
Michael

Hallo erstmal...

ich habe mir den Logik Analyzer schon eine Weile angesehen aber nie
nachgebaut, weil ich irgendwie um das Routing rumkommen wollte und auf
einen Lochrasteraufbau .. naja.. keine Lust hatte. Das sieht immer so
"bastelmässig" aus.

Nachdem ich jetzt aber den wohl (für mich) am schwersten zu
beschaffenden Baustein, den SRAM, von einer Platine gekratzt (nein ...
ausgelötet) habe und in den Schaltplan integriert, habe ich für den
Minilog mal ein Routing erstellt.

Die Platine habe ich passend gemacht für ein altes
4-Kanal-Video-Telemetrie-Gehäuse (5x BNC und diverse andere Anschlüsse).
Die Bauteile habe ich so ausgemessen, dass es exakt in das Gehäuse passt
und ich keine Frontplatten ausschneiden muss :))

Achja: Als SRAM habe ich "nur" eine SMD Variante gefunden, einen
Alliance AS7C256-15C. Ich hoffe, dass der Baustein auch geht.

Leider bin ich noch nicht dazu gekommen, die Platine 2-seitig zu
erstellen, da beim Versuch eine doppelschichtige Pollin-Schrott-Platine
durch den Laminator zu quetschen dieser sein Silikon verlieren wollte :(
Nunja, als erstes bastel ich einen verstellbaren "Laminatorumbau".

Wer sich aber das Routing schon ansehen möchte und ggf. korrigieren,
kann dies gern tun.

Der ISP-Connector ist gleichzeitig mit auf den DB15-Stecker geführt,
weil das Gehäuse den passenden Ausschnitt dafür hat. Auch eine 3er-LED
habe ich von der Originalplatine ausgelötet und auf +5V gelegt (mit
Widerstand), muss aber nicht sein. Die SMD-Komponenten sind gespiegelt,
so dass man sie auf die Platinenunterseite löten kann ohne
Adapterplatine für DIP zu basteln.

Hmm... achja.. VIAs gibts keine, dafür müssen manche der IC's teilweise
auf beiden Platinenseiten verlötet werden.

Hoffe, das Projekt ist noch einigermaßen aktuell. Wenn das Ganze so
funktioniert wie ich möchte, würde ich es ggf. mal für eine kleinere
Platine routen, so dass man auch ein "gängiges" Gehäuse benutzen kann.


Grüße,

Andreas

Mahlzeit!

Die RAMs von Reichelt kannst du nicht nehmen, die sind viel zu langsam!
Besorg dir ein 32kB Cache RAM von alten 486 Mainboards mit 15ns, die
gehen gut.

Die Fuses müssten so passen, mit einer kleinen Testfirmware und einer
LED dran kannst du das recht einfach prüfen :-)

mfg
Harri

hätte mich auch gewundert wenn du in einem analogen Videorekorder
überhaupt RAMs findest.

Müsste nicht dieser hier 313859 von
http://www.csd-electronics.de/de/index.htm funktionieren? Kann leider
nicht direkt linken, einfach nach der Artikelnummer suchen.
Ist zwar leider SMD, aber dafür weiß man, wo man ihn herbekommt.

Sebastian

Hi Tommy,

wenn du mir deine Adresse zukommen lässt, stopf ich dir ein paar
32kB-RAMs mit 15 oder 20ns in einen Briefumschlag.

mfg
Harri