Forum: Mikrocontroller und Digitale Elektronik Logic Analyzer bauen


von Thomas O. (Gast)


Lesenswert?

Hallo,

mein nächstet Projekt wird warscheinlich ein Logicanalyzer sein, ich
wollte mal kurz horen was mit einfachen Mitteln für einen Wiederholrate
möglich ist. Ich würd einen 20 MHz AVR Typ nehmen der immer wiederholt 1
Port einliest und die Daten in ein RAM schreiben, da ich hierzu keine
Sachen wie A/D-Wandler. EEPROM usw nutze sollte doch eine Übertaktung
möglich sein.

Falls man das RAM wie einen 28er EEPROM ansprechen kann sollte ich es
mit sehr wenigen Takten hinbekommen die Daten ins RAM zu legen. Wenns
dann voll ist müsste ichs in den Rechner schaufeln um es dann in Excel
oder womit man das grafisch macht anzuzeigen. Dazu würde ich am
liebsten ein Taktsignal verwenden um keinen größen
(PC-)Programmieraufwand betreiben zu müssen.

Hat dazu jemand Vorschläge damit ich mir mal die Möglichkeiten durch
den Kopf gehen lasse. Welches größere RAM's käme in Frage welches wäre
besonderst schnell. Evtl. eine Programmierbare Logic benutzen, da die ja
um einiges schneller sind und man dann z.b. 20nSek Rams voll ausnutzen
kann was dann etwa 50 MHz entsprechen würde. Wobei mir eine Auflösung
von 8 oder 16MHz voll reichen würde und man dann etwas änger aufzeichen
kann.

von Simon Küppers (Gast)


Lesenswert?

Vergiss den/die Trigger-Leitungen nicht ! Außerdem brauchst du ne
TimeBase wenn du nur auf den Triggern reagierst.

von Thomas O. (Gast)


Angehängte Dateien:

Lesenswert?

Hallo,

also ne Triggerung bräuchte ich nur für den Start damit der Ram nicht
schon volläuft bevor ein Signal anliegt. Also entweder über Interrupt
oder ich vergleiche die Signale auf 0 um das erste Signal zu erkennen
und lass dann erst das ganze loslaufen. Die RAM-Adresse zähle ich mit
dem µC hoch und die Befehle erhalt das RAM auch vom µC so kann ich die
Geschwindigkeit an den abzuhörenden Baustein anpassen.

Die Speichertiefe ist halt jetzt die Frage was gibt es da für Bausteine
die kein Refresh benötigen.

von Neutron (Gast)


Lesenswert?

Ich würde das mit einem schnellen CPLD oder FPGA realisieren. Für die
Kommunikation mit dem PC kannst du einen Atmel verwenden.

Schau dir mal die ispMach4000 CPLDs von Lattice an. Die können
problemlos 100MHz.

von Benedikt (Gast)


Lesenswert?

Besser als eine Anfangstriggerung ist eine kontinuierliche Aufzeichnung
und eine Unterbrechung der Aufzeichnung kurz nach der Triggerung.
So kann man sich auch die Daten vor der Triggerung anschauen.

von Dirk (Gast)


Lesenswert?

Hi,

immer wieder gibt es hier so ein Thread und jedesmal geht er leider in
die Versenkung unter.

Der ISPMACH4000 CPLD Baustein sieht sehr interessant aus.
Ich bin gerade dabei die ersten Gehversuche mit externen RAM an einem
AVR µC zumachen, deshalb haette ich diesbezueglich ein paar Fragen.

Der CPLD liesst die Daten auf den Portpins ein und gibt diese an einen
schnellen Speicherbaustein(FIFO?) weiter. Der AVR ist wiederrum mit
diesem Speicherbaustein verbunden und holt sich die Daten aus dem
Speicher und gibt diese an den UARt weiter?

Ist diese Ueberlegung richtig?

Welche Speicherbausteine sollte man nutzen ? Ich habe bis jetzt auch
nur FIFO Speicher mit mind. 10ns gesehen , somit wuerde auch ein CPLD
der 10ns braucht reichen? Oder muss der CPLD um Faktor X schneller sein
als das RAM?

Ich wuerde mich freuen , wenn mir jemand diese Fragen beantworten
koennte.

Gruß,
Dirk

von R2D2 (Gast)


Lesenswert?

Elektor hatte mal nen Artikel dazu. Die haben das mit AVR, FIFOs und
eigen Logic-Bausteienn erledigt. Ging bis 40Mhz. Der erste Teil war in
2/2003, nen monat später wurde es abgeschlossen.

von Dirk (Gast)


Lesenswert?

Hi,

ich besitze diesen Logik Analyzer. Wirklich zufrieden war ich damit
nie. Die Softwaere laeuft nur auf Win98.

von Jens (Gast)


Lesenswert?

Bitte nicht die Software auf PC-Seite vergessen. Signale aufzeichnen ist
eine Sache, nur die wollen auch komfortabel ausgewertet werden. Genau
das war wohl auch das Problem bei der Software vom Elektor-Projekt, die
lief entweder garnicht oder sehr instabil.

von dave (Gast)


Lesenswert?

Für nen 8bit-Analyser musst du bei nem AVR ja schon Takt/3 rechnen, d.h.
max. 7MHz, denn: IN (1) + ST X+ (2) = 3 Takte / Sample.

Steig wirklich gleich auf nen CPLD um.

von Jens (Gast)


Lesenswert?

Wie oft müßte man eigentlich ein digitales Signal abtasten, um sicher
alle Impulse in einem bestimmten Zeitraum zu erfassen?

von Simon Küppers (Gast)


Lesenswert?

Kommt aufs Digitale Signal an. Bei Triggerung auf den einzelnen Impulsen
reicht theoretisch ein 100Mhz LA, wenn das Signal auch ein 100Mhz
rechteck ist.
Bei laufender Abtastung gilt das Oszi-Abtast-Theorem

von Harry (Gast)


Lesenswert?

wie wärs damit:

XILINX Spartan 3 Starter-Kit kaufen (99 $), Expansion-Header
als Inputs, Speicher 2 x 256k x 16 (10ns, onboard) als
Ringbuffer verwenden,
Firmware vom PC aus laden, Steuerung und Lesen der Daten
via Rs232 oder mit vorgeschaltetem USB-RS232 Konverter,
Darstellung der Daten am PC z.B. mit TeeChart Grafik

Problem:
einer muss das FPGA-Design machen und einer die Windows-SW
schreiben, aber da sollte sich hier doch jemand finden ?!

von Jörn (Gast)


Lesenswert?

Eine beta für ein FPGA Design kann ich beisteuern. Ist aber noch etwas
buggie.

Stand der Dinge:

8 Kanäle
2k Speicher pro Kanal, werden im internen Blockram abgelegt.
Triggerung auf Pegel, steigende/fallende Flanke oder gemischt.
Datentransfer über RS232 @ 115,2 kBaud.

Gruß Jörn

von Dirk (Gast)


Lesenswert?

Hi,

ich wuerde das rooten der PCB uebernehmen, wenn interesse besteht und
mir jemand ein bischen bei der Schematic helfen wuerde.

Gruß,

Dirk

von Dirk (Gast)


Lesenswert?

Ups,

sollte natuerlich routen heissen.

Dirk

von Harald (Gast)


Lesenswert?

Was mir dazu einfällt...
...so du ein Oszi hast, müsstest du eigentlich das auch als ausgabe
nutzen können. Müsstest ein entsprechendes Triggersiganl erzeugen, und
die unterschiedlichen Kanäle kannst du dann trennen, indem jeder Kanal
durch eine externe Beschaltung eine andere Offsetspannung mitbekommt.
Ungefähr müsste dann die maximale Frequenz = Oszibandbreite/Kanalzahl
sein. Wenn du kein Osti hast... ...vielleicht mal bei Google gucken,
was ein Analogoszi (Ist billiger) mit großer Bandbreite gebraucht so
kostet.

Nur so ´ne Idee...

Gruß,
Harald

von Thomas O. (Gast)


Lesenswert?

Hallo,

@Jörn: hast du nen Schaltplan würde mich mal interessieren wie das mit
einem FPGA aussieht.

Das Hauptproblem ist bei mir die PC-Software. Digitrace gefällt mir von
der Aufmachung ganz gut aber da bin ich voll überfordert sowas zu
proggen.

Hat jemand mal ein paar RAM Bezeichnungen die in Frage kämen? Denke
Reichelt da sowas nicht oder?

von Thomas O. (Gast)


Lesenswert?

Hallo,

wie nennen sich eigentlich diese Zählbausteine, die einfach pro Impuls
den binären Ausgang um eins erhöhen?

von Rolf Magnus (Gast)


Lesenswert?

Die Programmierung der PC-Seite könnte ich machen. Allerdings
programmiere ich hier normalerweise nur für Linux und nicht für
Windows. Mit Qt4 könnte man das Programm aber plattformunabhängig
schreiben, so daß es sich ohne Modifikation unter Linux, Windows und
MacOS compilieren lässt.

von R2D2 (Gast)


Lesenswert?

Thomas: Counter

Alle: Warum nicht die Idee mit dem FIFOs von Elektor aufgreifen. Sollte
den Aufwand deutlich reduzieren.

von Thomas O. (Gast)


Lesenswert?

Hallo,

kannste das mal erklären? Oder kann man das irgendwo nachlesen?

von Jörn (Gast)


Angehängte Dateien:

Lesenswert?

@Thomas:

Die Schaltung ist in VHDL geschrieben und die Schaltpläne ist das
Ergebnis der Synthese der ISE.

von ope (Gast)


Lesenswert?

Hi,

was mir von dem 40MHz LA der Elektor im Kopf hängen geblieben ist:
- nur Win98 (kam schon), häufig Abstürze
- auf der Web Seite kein Projekt mehr erreichbar
- Einsatz von FIFOs, Stck > 25Euro
- 40MHz bei dem PCB Design -> fraglich, evtl. hat er nur das timing der
FIFOs heran gezogen.

Mit dem FPGA klingt toll, imo gibt's die Dinger aber nur im BGA
Gehäuse  und da ist das löten naturgemäß problematisch, d.h. home made
ist fast unmöglich. Bleibt also nur CPLD im QFP. BTW, xilinx hat mal
ein Appnote dazu: http://www.xilinx.com/bvdocs/appnotes/xapp368.pdf
Das mit den Komparatoren löst das Problem mit den verschiedenen
Logi-Pegeln elegant.

Viele Grüße
Olaf

von Benedikt (Gast)


Lesenswert?

FIFOs sind zwar die einfachste Möglichkeit, aber einfach nur
Scheißteuer.
Mein 16 Kanal 40MS Logikanalyser besteht aus zwei 128kBx8 VRAMs,
gesteuert von einem AVR.
Die Takterzeugung der Samplerate und die Triggerung macht ein kleiner
CPLD.

2kB RAM klingen zwar ganz gut, würden mir aber nicht reichen.
Die 128kB nutze ich oftmals voll aus, wenn ich z.B. den Datentransfer
zwischen einem uC und einem LCD betrachte. Meist wird hier am Anfang
das LCD zuerst komplett gelöscht, und erst die Daten dahinter sind
interessant.

Was spricht gegen die Verwendung von schnellen Cache SRAMs aus
Mainboards, oder gegen synchrone Cache SRAMs ?
In fast jedem etwas neueren P1 Mainboard (oder auf P2/P3s) findet man 2
synchrone SRAMs mit 32kx32 oder sogar 64kx32

8bit reichen für einen Logikanalyser selten, spätestens wenn man sich
einen parallel Datenbus anschauen möchte, benötigt man 8 Daten und
einige weitere Steuerleitungen.

Die 32bit des synchronen SRAMs wären dafür optimal: 8 oder 16bit Daten,
bis zu 20 Adressen, Steuerleitungen usw.
Und das ganze kompakt in einem IC und bis 66MHz brauchbar.

von Jörn (Gast)


Lesenswert?

@ope:
FPGAs von Xilinx oder Altera sind auch noch im TQPF 144 oder 208 zu
bekommen.

@Benedikt:

Die 2k pro Kanal waren nur für Testzwecke gedacht. Maximal habe ich 1
MByte Speicher (bis 100 Mhz) zur Verfügung, also z.B. 256kSamples a 32
Bit. Das müßte schon ne Weile reichen.

Was für einen CPLD benutzt du?

Gruß Jörn

von Benedikt (Gast)


Lesenswert?

Ich verwende einen XC9536, da die Triggerung (ein einfaches D Latch mit
davorgeschaltetem 1 aus 16 Multiplexer) und die Samplerateauswahl
(Teiler und Auswahl der Frequenz) keine großen Anforderungen stellen.

Was ich vielleicht noch integrieren werde ist eine bessere Triggerung
auf bestimmte Werte, da ich den Logikanalyser mit einem ADC auch als
Oszillopskop verwende. Bisher kann ich leider nur auf >128, >192, <128
und <64 Triggern.

Was kostet eigentlich ein geeigneter FPGA für so ein Projekt ?
Bisher hat mich eigentlich immer der Preis davon abgehalten,
irgendwelche Projekte damit zu planen.
Wenn man einen 5€ CPLD abschießt, ist das zwar dumm, aber nicht weiter
schlimm. Bei einem FPGA für >20-40€ wird das ein teurer Spaß.

von Harry (Gast)


Lesenswert?

also ich denke nach wie vor, ein Dev-KIT vom FPGA-
Hersteller ist die preiswerteste Möglichkeit.
Wenn man so ein Board selbst machen will, spart man
am Ende nichts. Für hohe Taktfrequenzen und Bitbreiten
muss man doch sicher mind. eine 4-Lagen-Platine machen,
da ist nicht mehr viel mit selber ätzen,
die SRAMs müssen vom Pegel her mit den I/Os des FPGAs
zusammenspielen, alle Spannungen müssen ordentlich
geblockt sein, mehrere Betriebsspannungen sind nötig
(3,3V / 1.5...2.5 V ...??) und dann noch das PQ208
mit der Hand löten? Geht alles, aber wie lange soll das
dauern?
Habe mal so ein Projekt mit einem "alten" Spartan I im PLCC84
und ein paar Cache-RAMs aus'm PC angefangen, die Platine
liegt jetzt noch unfertig rum, die Zeit hat nie gereicht,
um das mal fertigzumachen.

von Benedikt (Gast)


Lesenswert?

4 Lagen ist doch schon etwas übertrieben...
Selbst viel (vor Pentium) Mainboards kamen mit 2 Lagen aus.

Mein 40MS Logikanalyser ist einseitig auf einer Lochrasterplatine
aufgebaut, und ich hatte damit bsiher eigentlich keine größeren
Probleme, (zumindest seitdem ich wirklich unter jedes IC einen 100nF
Kondensator gehängt und die Betriebsspannung ordentlich verlegt
hatte.)
Am Anfang hatte sich die Schaltung so etwa alle 10-20s aufgehängt, weil
der CPLD einen Reset gemacht hat, und der uC auf das Ready Signal vom
CPLD gewartet hat, das allerdings nie kam...

von Jörn (Gast)


Lesenswert?

@ Benedikt:
Die Triggerungsmöglichkeit sind bei dir etwa beschränkt, aber reichen
natürlich.

Mein Design paßt ohne weiteres in einen 3S50 rein:
Preise:
XC3S50-4TQ144C 12,30 USD
XC3S50-4VQ100C 10,10 USD
XC3S50-4PQ208C 13,90 USD

XC3S200-4TQ144C 15,10 USD

wenn man direkt bei Xilinx bestellt.

Wenn ich ein FPGA Baord bauen müßte, würde ich aber zu einem Cyclone
greifen. Wie Harry erwähnt hat, brauchen die FPGA mehrere
Versorgungsspannungen. Der Altera (Cyclone) brauch nur zwei während der
von Xilinx (Spartan3) drei braucht.

Wobei ich denke, dass man das Board noch zwei lagig hinbekommen könnte.


@ Harry:
Preislich und vom Zeitaufwand her wirst du recht haben, dass es sich
fast nicht lohnt ein eigenes Board zu machen. Das Starter Kit kostet so
um die 100€.

von Harry (Gast)


Lesenswert?

Also wenns ein ALTERA-FPGA werden soll, wäre ich
bereit, ein vorh. funktionierendes Design auf den
ALTERA zu portieren (falls nötig) und zu compilieren/
simulieren. Habe die Quartus II Software Vollversion
V5.0 + Modelsim-ALTERA 6.0 laufen.
Dev.-Board mit Cyclone habe ich aber nicht, dafür Stratix II :-)

von Dirk (Gast)


Lesenswert?

Hi,

ich denke das HW Design sollte man locker auf eine doppelseitige 80x100
Platine bekommen. Ich waere wirklich bereit dazu eine Platine zu routen
und in Auftrag zugeben.

Erstmal muesste aber der FPGA / CPLD geklaert werden. Harry und Joern
koennten die Programmierung des FPGA / CPLD vornehmen. Es wuerde nur
ein Programmierer fuer die PC Seite fehlen.

Wuerde interesse bestehen so ein Gemeinschaftsprojekt zustarten?

Gruß

Dirk

von Hans (Gast)


Lesenswert?

welche sprache und welches os ?? ;)

ich kann derzeit so ziemlich alles was in frage kommt soweit, dass ich
was basteln könnte... ich favorisiere c/c++ und irgend ein widgetset...
mfc ist meine hauptspielwiese dank firma aber gtk der wxWidget dürfte
brauchbarer sein...

ich bin zwar derzeit etwas vollgedeckt.. aber innerhalb der nächsten
1-2 wochen würde da sicher eine beta rausschaun...

soll das komplett in einem cpld sein oder kommt da noch ein uC dazu???

im prinzip bräuchte ja nur die trigger,zähler und ram-verwalt logik in
den cpld rein...

dann noch das ganze z.b an nem avr ran und per ext-mem-interface daten
schaufeln...

aber da lass ich euch mal machen ;)

73

von Jens (Gast)


Lesenswert?

Habt ihr jetzt mal klar abgesteckt, wie es werden soll? Also CPLD oder
FPGA? Bei FPGA könnte man ja dessen RAM benutzen, ist zwar nicht sehr
groß dürfte aber reichen. Teure Geräte haben nicht unbedingt mehr
Speicher. Bei CPLD wäre man auf externen (schnellen) Speicher
angewiesen.

Wieviele Kanäle? 8 ist zu wenig, 16 eigentlich auch wenn man IDE
aufzeichnen will. 32 Kanäle wären nett und sollten meiner Meinung nach
unbeding anvisiert werden. Ansonsten macht man später die ganze Arbeit
nochmal. Bei 32 Kanälen wirds dann allerdings wieder eng mit internem
Speicher, weiß allerdings auch nicht, was da derzei so Stand der
Technik ist. Vielleicht sollte man bei Xilinx recherchiert werden.

Wie kommen die Daten in den PC? Es sollte eine zunkunftsorientierte
Schnittstelle benutzt werden, also fällt RS232 schonmal weg. USB wäre
hier sinnvoll, welcher Controller wird dann verwendet?

Außerdem sollte man Bauteile wählen, die gut erhältlich sind. Ein FPGA,
der nur in VPEs zu 96 Stück bestellt werden kann und sonst extrem teuer
ist, bringt nichts.

Die Sofware auf PC-Seite könnte in JAVA geschrieben werden. Dadurch
ließe sie sich leichter auf verschiedenen Plattformen einsetzen.

Also ich wäre an einem Gemeinschaftsprojekt auch sehr interessiert.
Vielleicht sollte aber vorher mal eine Art Pflichtenheft erstellt
werden denn sonst wirds chaotisch und es kommt immer wieder was hinzu
und zum Schluß blickt keiner mehr durch und alles verläuft im Sand wie
die ganzen anderen Analyzer-Projekte auch.

Gruß
Jens

von ope (Gast)


Lesenswert?

@Jörn:
"FPGAs von Xilinx oder Altera sind auch noch im TQPF 144 oder 208 zu
bekommen."

Dies betrifft (nach einem kurzen Wühlen) nur die Spartan-I und
Spartan-II Family, alles darüber BGA. Das xilinx für jede ihrer Package
wieder einen eigenen Namen hat ist zum Kotzen...
(http://www.xilinx.com/products/design_resources/packaging_resource_page/Xilinx_Package_Code_Glossary.htm)
Nun ja, sollten/sind eben diese nicht abgekündigt werden/worden?

@Benedikt:
"Mein 40MS Logikanalyser ist einseitig auf einer Lochrasterplatine
aufgebaut, und ich hatte damit bsiher eigentlich keine größeren
Probleme..."

Was macht Dich so sicher, dass Du bei diesem Aufbau und 40MHz noch die
Pegel der zu untersuchenden Schaltung analysierst? Vcc blocken ist ja
nur eins - ground bounce das Nächste, Übersprechen das Weitere, EMI und
und und ... Es handelt sich ja nicht gerade um eine kleine
Oszillatorschaltung, wo alles noch recht übersichtlich ist.

BTW, ein Self-Test wäre nicht schlecht, nur so als Idee.

Rein aus Interesse, ab wann (MHz) nimmt man eigentlich LVDS?

Viele Grüße
Olaf

von Rufus T. Firefly (Gast)


Lesenswert?

.

  "4 Lagen ist doch schon etwas übertrieben...
  Selbst viel (vor Pentium) Mainboards kamen mit 2 Lagen aus."

Ja, der Apple II. Und der Atari ST. Auch PCs mit 8088, aber bereits
einen AT (286er) mit zweilagigem Mainboard habe ich nie gesehen.
Und der wurde mit lächerlichen Taktfrequenzen von anfänglich gerade mal
6 MHz betrieben.

von Andreas S. (andreas) (Admin) Benutzerseite


Lesenswert?

Wenn das CPLD/FPGA gross genug ist koennte man sich evtl. den AVR sparen
und den USB-Chip (z.B. FT245) direkt ansteuern.

PC-seitig waere eine Java-Software das beste; ich finde es immer wieder
schade wenn jemand viel Muehe und Zeit in ein Programm investiert, das
dann nur auf einer oder wenigen Plattformen zufriedenstellend laeuft.

von ope (Gast)


Lesenswert?

Hi,

man ist das ein Tempo hier - das wird sicher wieder ein Monster Thread
wie mit dem Labor Netzeil :) Ich hoffe nur, mit einem positiven Ende.

@Jens:
"Bei CPLD wäre man auf externen (schnellen) Speicher
angewiesen."

Du kannst RAM Bänke pagen - musst den Bus entsprechend buffern.

Tja, ich sehe, man kann sich mal wieder nicht über die
Programmiersprache des GUI einigen :) Noch keiner Asm vorgeschlagen ;-)
Immerhin kam noch kein CAN Bus als Interface. Leute, macht es so einfach
wie möglich für den ersten Wurf. Manchmal ist es billiger mehr Geld
hinein zu stecken, als hinterher Monate wegen Kleinkram und damit noch
mehr Geld (und hier vor allem Lust) zu verlieren (Thema: FPGA Ev-Kit).

Viele Grüße
Olaf

von Andreas S. (andreas) (Admin) Benutzerseite


Lesenswert?

Erstellt doch mal eine Wiki-Seite dafuer und schreibt eine genaue (und
moeglichst einfache, wie Olaf schon geschrieben hat!) Spezifikation;
ansonsten wird das wie das Netzteil-Projekt totdiskutiert.

von Hans (Gast)


Lesenswert?

gegen java lege ich mich strikt quer...
dann lieber etwas wirklich nettes...

python coden kann ich zwar noch nicht so wirklich gut aber jeder muss
einmal richtig anfangen :)

dann ist wieder alles 100% portable...

usb wäre zwar nett aber dann hat man wieder das treiber problem.. es
sei denn man hängt an so einem usb->serial wandler ala ft... wobei von
dem hab ich schon horrorgeschichten gehört wenns um viel daten und
dauernd und generell...
rs232 ist industrie standart.. usb nicht und wenn die was anderes wie
rs232 fahren dann can und wenn das denen nicht passt dann nehmen die
lan... also lasst uns doch auch lan nehmen G

spass bei seite.. das interface zwischen pc und analyzer ist einfach
umzustellen wenn man schön oop macht.. und am avr kannst bis 2Mbit das
serielle interface hochdrehen.. die frage ist da nur ob der pc mitkommt
mit seinen 16byte fifo und 10ms microshit-raster...

am besten jeder sagt mit welchen uCs er gut umgehn kann und dann wird
der genommen der am günstigesen (für die aufgabe) erscheint...

und im übrigen wäre auch ein windows programm, bei dem darauf geachtet
wird, dass es unter wine läuft auch kein all zu großes probelm...

gegen java hab ich was.. das ist böse und langsam...
eigentlich ist jede sprache bei der ich nicht der gott meiner cpu(s)
bin böse... ;)

und nebenbei soll das ganze doch recht fix laufen..darum würde ich c++
und ein portables widgetset bevorzugen.. das ist einfach das
schnellste...

gut jetzt stell ich mal auf was ich gerne hätte ;)

GUI                 : C++ und portables widgetset.. uU. python oä.
uC                  : AVR bin mit dem gut vertraut
Target => Messdings : 3V/5V inputs reichen
Messdings => uC     : übers speicherinterface
uC => PC            : im prinzip wurscht... bevorzugt rs232 da einfach
;) alternativ usb und ft...


73

von Andreas S. (andreas) (Admin) Benutzerseite


Lesenswert?

> gegen java hab ich was.. das ist böse und langsam...

Java langsam, und dann schlaegst du Python vor? Man kann gegen Java
sagen was man will (zu viel Einfluss von C++, hoher Speicherverbrauch),
aber langsam ist es nicht. Benchmarks darfst du dir selber suchen.

von Hans (Gast)


Lesenswert?

es mag schon sein, dass java für "0815-anwendungen" (also programme
die nicht auf die hardware zugreifen dürfen) schnell genug ist...

aber im prinzip verliert java alle vorzüge damit,dass wir hier auf
irgend ein interface zugreifen müssen...
und java guis gefallen mir einfach nicht...

so jetzt genug meinung kund getan ;)hier ein kleines benchmark ergebnis
;)
http://www.twistedmatrix.com/~glyph/rant/python-vs-java.html

man beachte die python version..

noch mehr zu dem thema findet sich hier..
http://python.fyxm.net/doc/Comparisons.html#java

alles in allem ists wurscht was man nimmt...  ;)

daran solls nicht scheitern...

73

von Jörn (Gast)


Lesenswert?

@ope:

Den Spartan 3 gibt es auch als nicht BGA Versionen. Schau mal weiter
oben nach, dort habe ich sie aufgeführt mit Preisen.

Preisanfrage an Reichelt schick ich heute noch raus.

Gruß Jörn

von Jörn (Gast)


Lesenswert?

@ope:
Schau mal hier: http://www.xilinx.com/bvdocs/publications/ds099-1.pdf
auf Seite 4. Dort sind die verfügbaren Packages aufgeführt.

von Andreas S. (andreas) (Admin) Benutzerseite


Lesenswert?


von PeterF (Gast)


Lesenswert?

@Hans
>http://www.twistedmatrix.com/~glyph/rant/python-vs-java.html
>
>man beachte die python version..

man sollte aber auch die getestete Java Version beachten: JDK 1.1.7B!

Meine Meinung zum Thema Programmiersprache: Jede hat Vorzüge und auch
Nachteile. Die perfekte Lösung gibt es nie - man muss immer den Weg des
geringsten Übels nehmen.

Peter

von Rolf Magnus (Gast)


Lesenswert?

Jeder schlägt hier was anderes für die PC-seitige Software vor, aber ist
denn auch einer bereit, diese in der von ihm vorgeschlagenen Sprache zu
schreiben?
Man kann viel vorschlagen, aber wenn's nachher nicht umgesetzt wird,
bringt das nix.

von Hans (Gast)


Lesenswert?

@andreas

lassen wirs gut sein.. ich mag java nicht besonders und aus ;) sonnst
wird das hier noch off topic....

@jörn,ope,...

könntet ihr die freundlichkeit haben und einen cpld/fpga nehmen den in
at zu bestellen gibt??? ;) z.b bei rs oder farnell oder wen auch
immer.. reichelt hat mich das letzte mal seeeeeehr unfreundlich
abgefertigt..

73

von PeterF (Gast)


Lesenswert?

Ich wollte jetzt nicht sagen, dass Java genommen werden soll. Man sollte
die Programmiersprache nach den Anforderungen aussuchen. Z. B.:
Soll die Messung in Echtzeit am PC dargestellt werden? Dann ist Basic
sicher nicht die besste wahl. Sollen die Messergebnisse aber nur
dargestellt werden, ist die Geschwindigkeit der GUI allemal
ausreichend.

>Jeder schlägt hier was anderes für die PC-seitige Software vor, aber
ist
>denn auch einer bereit, diese in der von ihm vorgeschlagenen Sprache
zu
>schreiben?
Wenn ich nicht gerade mitten im Hausbau stecken würde wäre ich gern
dabei.

Peter

von Hans (Gast)


Lesenswert?

das geringere übel sieht bei mir so aus, dass ich etwas nehme mit dem
ich leicht auf schnittstellen zugreifen kann.. wenn geht möglichst nah
am os...

also würde ich c++ hernehmen...

portabilität ist sowieso (fast) wurscht... es sei denn der analyzer
bekommt lan... ;)

drum c++ und portables widgetset...

73

von Jörn (Gast)


Lesenswert?

@Hans:

Reichelt war jetzt nur ein Vorschlag. Mal abwarten, ob die die Dinger
überhaupt besorgen können.

von Thomas O. (Gast)


Lesenswert?

Hallo,

ich denke das die Software auf dem PC nicht so wichtig ist. Da ja alles
wegen der Geschwindigkeit in RAM's, FIFO's oder was auch immer
abgelegt werden soll. Den PC bräuchte man dann nur um die Daten
Grafisch darzustellen, deswegen wird es auch nicht so diegroße Rolle
spielen welche Übertragungsart. Besser wäre es evtl. mit externen
Taktsignal so das auch keine Baudraten generiert werden müssen, dann
kann auch jeder ziemlch einfach sein eigenes PC-Prog schreiben um die
Daten zu empfangen.

Ich finde das Übertragungsprotokol sollte möglichst einfach sei z.b.
eine Reizleitung damit die Daten z.b. in 8Bit Paketen an die
Parallelschnittstelle gelangen. Vielleicht lassen sich ja 2 Protokolle
integrieren so das man z.b. per Jumper eine Serielle oder parallele
Übertragungsart wählen kann.  Besser wäre es evtl. mit externen
Taktsignal(bei serieller Übertragung) so das auch keine Baudraten
generiert werden müssen, dann kann auch jeder ziemlch einfach sein
eigenes PC-Prog schreiben um die Daten zu empfangen.

Ich würde für dieses Projekt auch was spenden oder bezhalen damit die
Hauptentwickler dafür etwas entschädigt werden und evtl. die Platinen
bestellt werden können usw.

Man müsste mal ein WIKI-Beitrag aufmachen um rauszufinden wie so die
Anforderungen sind. Mehr wie 8bit wäre natürlich nicht schlecht. Man
könnte da ja auch einfach 2 8bit Speicherbausteine nehmen also fürs Low
und fürs High Byte.

Kanalanzahl:
 8 ||||| |||
16 ||||| ||||
.....

Max. Abtastfrequenz:
10 MHz ||||
20 MHz ||||| |||
40 MHz |||

von Harry (Gast)


Lesenswert?

Sorry, aber ich bin nach wie vor der Meinung, dass das
mit einzelnen FPGAs, von Reichelt oder egal woher nix
wird. Wer aus'm Forum hat denn schon z.B. TQ144er
per Hand aufgelötet? Beim TQ144 beträgt der Pin-Abstand
0,5 mm - mit Lochrasterplatten ist da lange nix mehr ;-)
Mir hat letztens schon ein SSOP28 mit 0,65 mm gereicht
(AD9851).
Dazu kommen noch haufenweise Stütz-Cs, evt.
ext. RAMs, Spannungsregler, LEDs, FT232/245 oder MAX232...
Mal ganz provokant: Jemand der Familie, Haus, Job oder
gar alles drei hat kann das vergessen.

Also m.E. muss ein kostengünstiges, fertiges Board herzu,
und dann wie schon von anderen bemerkt ein ordentliches
Konzept, Programmiersprache ist erstmal egal, wichtig
sind die Interfaces zu definieren.

von Dirk (Gast)


Lesenswert?

Hallo,

>Wer aus'm Forum hat denn schon z.B. TQ144er per Hand aufgelötet?

Ich und werde es wohl auch jeden Tag weiter machen muessen. Sehe
deshalb weniger ein Problem so ein FPGA zuverloeten.

> Also m.E. muss ein kostengünstiges, fertiges Board herzu,
> und dann wie schon von anderen bemerkt ein ordentliches
> Konzept, Programmiersprache ist erstmal egal, wichtig
> sind die Interfaces zu definieren.

Ein kostenguenstiges Board koennte man bauen wie ich es schon Angeboten
habe.

Aber dazu sollte Wirklich ein Lastenheft geschrieben werden.

Zum Thema USB o. RS232 bin ich eher dafuer RS232 zunehmen. Wer USB
haben moechte kann sich ein Wandler kaufen fuer 10 Euro. Das ist immer
noch billiger als selber ein FTDI Chip zuverbauen.


> Sorry, aber ich bin nach wie vor der Meinung, dass das mit
> einzelnen FPGAs, von Reichelt oder egal woher nix wird.

Sobald man sich auf eine Type festgelegt hat koennte man auch die
Verfuegbarkreit pruefen.

Wurde schon ein Wiki Artikel eroeffnet?

Link?

gruß,

Dirk

von Hans (Gast)


Lesenswert?

vielleicht wäre es ja eine gute idee den controller per spi
dranzumachen..

das bräuchte wenig pins und wäre schnell genug...

bei open cores gäbe es da auch einige implementierungen nur weiß ich
nicht ob die was taugen da ich keine ahnung vom cpld spielen hab...

dem cpld sag ich per spi er soll gefälligst anfangen zu tun und dann
warte ich z.b bis der busy pin wieder low wird... alternativ wäre das
auch per spi abfragbar.. oder start per pin... was einfacher ist...

im übrigen bin ich für die am einfachsten zu realisierende lösung ;)

73

von ope (Gast)


Lesenswert?

Hi,

hier erstmal was zum lesen, was ich so im Laufe der Zeit zu diesem
Thema gesammelt habe:

- XYZs of Logic Analyzers:
http://web.mit.edu/6.111/www/s2005/HANDOUTS/LA.pdf
- Handheld Pocket Logic Analyzer (XApp368)
http://www.xilinx.com/bvdocs/appnotes/xapp368.pdf
- Handheld 1553 Bus Data Analyzer (XApp369)
http://www.xilinx.com/bvdocs/appnotes/xapp369.pdf
- PC-basierter 32-Kanal-Logik-Analysator
http://www.amateurfunkbasteln.de/pcla/pcla.html
- eebit.com...home of the FPGA-based Logic Analyzer
http://www.freepcb.com/eebit/
Die Idee mit dem PC/104 ist nicht schlecht, ich war schon bei einem VIA
EPIA wegen Platz und Schreibtisch..., aber erstmal sollte man kleine
Brötchen backen
- bitscope http://www.bitscope.com hat auch einen LA

Nun mein Senf zu RS232 oder USB:
Mein Mother Board hat noch RS232, wenn ich wohl in 3 Jahren ein neues
kaufe, werde ich wohl keine mehr haben. Also kann ich mir dann für 15
Euro eine Schnittstellenkarte (wird dann wohl PCIe sein müssen) kaufen.
Wer heute die 10€ für einen FTDI ausgeben möchte, kann das ja machen -
evtl. musst Du es ja morgen selber machen (und jetzt denk mal 3 Jahre
wieder zurück, was Du damals gemacht hattest und vor allem warum - und
vor allem, wo sind die verfluchten Unterlagen dazu ...) Will sagen:
Entweder/oder auf dem PCB bestücken oder per Jumper RS232 bzw. USB
scharf machen. Dies war übrigens auch ein Streitpunkt bei dem Netzteil
Thread.

Noch mehr Senf zum GUI:
Der, der es programmiert, sollte das wählen, was er am besten kann -
denn er macht die Arbeit und hat die Probleme am Hals und alle anderen
profitieren anschließend davon. Ich persöhnlich wäre von allem anderen
außer C++/Qt/WxWindows nicht angetan, aber ich hätte (als Nutzer) ein
(hoffentlich gut) funktionierendes GUI und wenn ich Lust && Laune habe,
kann ich ja mein Eigenes meinetwegen in APL/Algol/Cobol/Fortran ...
schreiben und habe eine funktionierende Vorlage (im Source unter GPL
idealer Weise)!

Aus meiner Projekterfahrung mit C++/Opensource:
Ich habe über 2 Jahre gebraucht, um es dahin zu bekommen, wo es hin
sollte. Jetzt, wo es dort ist und ich die Erfahrung habe es neu und
besser zu schreiben, habe ich etwas die Lust/Interesse verloren. Hier
wird es nicht anders werden - gerade wenn man sieht, wie auf
sourceforge die high scores für DVD Rip && Crunsh in die Höhe schiessen
und man selber froh ist unter die Top 1000 zu kommen.

@Dirk:
0.5mm TQ144 löten: Hat es beim ersten Mal sofort geklappt bzw. wieviele
haben es nicht überlebt? Ich schätze mit dem Verfahren Lötkolben,
Lötzinn auf Beinchen streichen und Brücken mit Litze beseitigen, oder?
Bei einem toten CPLD ist es schmerzlich aber zu verkraften, bei einem
FPGA für > 35€ (farnell) hat man  vom reinbeißen bald keine Tischkanten
mehr.

@Jörn:
Spartan III hätte also kein BGA, aber ich schätze, um externen Speicher
kommt man nicht 'drum'rum (mit dem erwähnten Interleave). Dies zeigt
auch Bennedikts Erfahrung beim Protokoll loggen. In diesem Fall wäre im
FPGA nur die Address- und Triggerlogik, imo würde dann auch ein CPLD
reichen, womit viele glücklicher wären. Auch könnte man dann von
Benndikts Erfahrung profitieren. Aber dies muss erstmal verifiziert
werden, d.h. einer muss einen kleinen Entwurf in VHDL (oder will jemand
Verilog?) machen.

Thema CPLD und Speicher Interleave:
Der CPLD müßte die Adressen generieren und den Datenbus für jeden zB.
SDRAM buffern.
Kurze Rechnung:
14 Bit Addressbus -> 16k Speichertiefe
8 Bit             -> 8 Channel
----
22 Pins
+ Chip Select
+ R/W_
----
24 Pins * 4 Bänke = 96 Pins

Damit kann der LA mit 60MHz und 70ns SDRAM los heizen (sofern der
Überschlag stimmt). Mit 8 Pins für den Input sind's schon 104 Pins,
hinzu kommt serielle Kommunikation. Nun gut, die XC9500 kommen bis zu
192 I/O, da kann evtl. noch eine 5te/6te Bank genommen werden und 100ns
(pauschal) SDRAM verlötet werden oder eben mehr MHz. Wie dem auch sei,
es würde heissen je 8 Channel einen CPLD... Jeder könnte selbst soviel
zahlen/löten wie er will.

Thema FPGA/CPLD und uC:
pAVR opencore.org. Macht einen AVR im FPGA, allerdings soll er nur die
Kernfunktionalität haben. Sofern keiner damit praktische Erfahrung hat,
würde ich empfehlen einen MegaXX einzulöten, zumal imo viele dann
austeigen werden (relevant für nächsten Topic). Mit diesem kann mittels
DAC die Triggerschwelle eingestellt werden und die Kommunikation der
ggf. mehreren CPLD übernehmen. Keep it simple: i2c 4-8 Channel DAC für
1,80€ - no PWM (ground bounce, EMI etc.)

Thema 4 layer PCB:
Auf http://www.soudez.be/Page_Projet2.php ist ein DSO zu sehen, dass
mit 100MHz arbeitet. Leider habe ich keinen Hinweis auf das realisierte
PCB gesehen, ich habe aber auch keine Lust momentan mich durch
http://www.edaboard.com/viewtopic.php?t=41841&highlight=dso zu wälzen
ob er ein multi layer hat. Worauf ich hinaus möchte: je mehr sich
finden, desto preiswerter wird's für den Einzelnen (sofern Einigung
wenigstens in der Hardware besteht)

Thema Self test und Safety:
Bei keinem LA von oben habe ich Anregungen bekommen wegen
Eingangsschutz oder Self Tests. Gesetzt dem Fall ich bekomme Reuma und
habe ein Schafsfell auf dem Stuhl, ich bin nervös und rutsche nervös
mit dem Hintern in meiner sportlichen Synthetik Trainingshose drauf rum
und greife auf die Eingangsklemmen - wieviel kV werden da wohl entstehen
(bitte keine jetzt keine erstgemeinten Rechnungen, da ansonsten u.a.
Annahmen über die Schubbelgeschwindigkeit getroffen werden müßten :)
Auch kommt man manchmal in die Verlegenheit, dem LA zu misstrauen!!

Last but not least: Die Probleme kommen von da, wo man sie am wenigsten
erwartet. Ich selber kann ein Lied davon singen, je mehr man in's
Detail gehen muss, desto mehr muss man feststellen, was man alles nicht
weiss oder dann doch nicht berücksichtigt hat. Ebenfalls uch aus meiner
Projekterfahrung: Planung ist gut, aber letzlich gelingt es meist doch
erst bei dem 2 Entwurf, gerade wenn alles neu ist und man sooo gut
alles durchdacht hat. Es ist halt kein 0-8-15 Teil, was man da machen
möchte.

Viele Grüße
Olaf

von Thomas O. (Gast)


Lesenswert?

Hallo,

hier ein Wiki Beitrag
http://www.mikrocontroller.net/articles/Logic_Analyzer
hoffe das ich es richtig abgelegt habe.

von Thomas O. (Gast)


Lesenswert?

Hallo,

und wenn man die Schnittstelle möglichst vielseitig macht dann kann da
jeder seine Software machen wie er will. Ich sehe es für mich am
leichtesten wenn z.B. 8 bits an den Parallelport gelegt werden und dann
ein Taktsignal folgt damit der PC weis jetzt Port abfragen. Oder aber 2
Sendeleitungen für ein Serielles Signal also Signalleitung low oder
high  und dann auch wieder ein Taktsignal damit der PC weiß jetzt Bit
einlesen. Dadruch spart man sich schonmal die Baudratengenerierung das
start und Stopbit was schonmal über 20% bringt und es wäre sehr leicht
zu implantieren. Einfach Bit einlesen in ein Register schieben und nach
dem 8ten von neu anfangen.

von Dirk (Gast)


Lesenswert?

Hallo,

>@Dirk:
>0.5mm TQ144 löten: Hat es beim ersten Mal sofort geklappt bzw.
>wieviele haben es nicht überlebt? Ich schätze mit dem Verfahren
>Lötkolben, Lötzinn auf Beinchen streichen und Brücken mit Litze
>beseitigen, oder? Bei einem toten CPLD ist es schmerzlich aber zu
>verkraften, bei einem FPGA für > 35€ (farnell) hat man  vom
>reinbeißen bald keine >Tischkanten mehr.

das verloeten ist nicht das Problem (ohne Loetbruecke) das schlimmste
ist nur das richtige Positionieren.
Jeder macht mal Fehler und somit kann mal einer sterben, aber
eigentlich hab ich bis jetzt noch keinen gekillt.
Industrieflussmittel ist der beste Freund bei solchen Sachen.

>Damit kann der LA mit 60MHz und 70ns SDRAM los heizen (sofern der
>Überschlag stimmt). Mit 8 Pins für den Input sind's schon 104 Pins,
>hinzu kommt serielle Kommunikation. Nun gut, die XC9500 kommen bis zu
>192 I/O, da kann evtl. noch eine 5te/6te Bank genommen werden und
>100ns (pauschal) SDRAM verlötet werden oder eben mehr MHz. Wie dem
>auch sei, es würde heissen je 8 Channel einen CPLD... Jeder könnte
>selbst soviel zahlen/löten wie er will.

Diesen Vorschlag finde ich extrem gut. Mir wuerde naemlich schon ein 8
Kanal Geraet reichen mit 8kbit Speichertiefe.

Der ANT8 liegt bei ca. 250 Euro und duerfte die billigste Konkurrenz
sein.

Gruß,
Dirk

von ape (Gast)


Lesenswert?

Nur um auch mal meinen Senf zur Schnittstellen-Thematik dazuzugeben:
Wenn ich überlege wie glücklich ich bin einen seriellen
Programmieradapter zu haben weil das ganze Parallelport-Geraffel nie
richtig funktioniert hat, bin ich der Meinung das der Parallelport die
denkbar schlechteste Alternative wäre. Außerdem stirbt dieser Port bei
den modernen Mainboards genauso aus, wie RS232 und ein
USB-Parallel-Wandler hab ich auch noch nirgends gesehen (allerdings hab
ich auch noch nicht nach gesucht)

Um das LAN nochmal aufzugreifen (ich weiß gar nich obs überhaupt
ernstgemeint war): Möglich wärs wohl mit nem RTL8019 o.ä. oder sogar
ohne Controller alá Igor UDP, aber die Übertragungsrate wäre wohl alles
andere als zufriedenstellend.

RS232 oder USB wären also wahrscheinlich schon das sinnvollste. Wobei
ich zu einem FT... tendieren würde, da man so wohl die höchste
Geschwindigkeit rausbekommen würde, wenn man den Umweg über RS232 + USB
Adapter geht hätte man den MAX232 als Flaschenhals (garantierte
Geschwindigkeit laut Datenblatt nur 120 - 200kbps, je nach Typ)

von Rufus T. Firefly (Gast)


Lesenswert?

Oh, USB-Parallelwandler gibt es, sogar welche mit erweitertem
Funktionsumfang zum selberbauen:
http://www-user.tu-chemnitz.de/%7Eheha/bastelecke/Rund%20um%20den%20PC/USB2LPT/index.html

Wenn doch FTDI-Chips verwendet werden, dann doch wenigstens den FT245,
der der LA-Hardware gegenüber ein deutlich schnelleres paralleles
Interface aufweist ...

RS232 ist zwar immer noch besser als von Hand abmalen, aber bei einer
maximal erzielbaren Datenrate von 10 kByte/sec (115200 Baud, schneller
wird die serielle Schnittstelle, wie sie noch in üblichen PCs zu finden
ist, nun mal nicht).

von Dirk (Gast)


Lesenswert?

Hi,

wenn man den Platinenplatz nicht beruecksichtigt und ein AVR schon auf
dem Board vorhanden ist koennte man noch ein RTL8019s dazubauen.

Die billigste aber auch die langsamste Moeglichkeit duerfte RS232 sein.

von Hans (Gast)


Lesenswert?

ich bin zwar kein 8051-freund aber gibts da nicht welche mit usb ???

cypress hat doch so dinger oder??? das würde eingentlich schon viel
erschlagen...

neben der uc problematik auch gleich das usb zeugs...

ich hab da bei rs mal AN2131QC bzw AN2131SC gefunden...cypress meint
aber dazu not recomended for new designs... aber im prinzip.. und
14/12e bei rs.. kostet also das was ein ft kostet und bietet die
möglichkeit beides(rs232 und usb) fahren zu können...

ethernet wäre wirklich eine lösung aber nur in verbindung mit einem
netten arm und linux...sonst seh ich da zuviel code, der nie wirklich
rennen wird...

73

von Thomas O. (Gast)


Lesenswert?

Hallo,

also wenn man eh nur 64 kBytes Speichertiefe hat kann sich ja jeder
ausrechnen "wie lange" das mit RS232 dauert. Also ich könnte da mit 6
Sekunden Übertragungsdauer zum PC leben. Aber gut USB ist natürlich der
Standart der die nächsten Jahre überleben wird.

von ope (Gast)


Lesenswert?

Hi,

etwas konkreter weiter gesponnen - ich habe mal bei Farnell wegen den
SRAM geschaut - bei Reichelt gab's Zeropower SRAM Dil-28 32Kx8 70ns
und Zeropower SRAM Dil-28 32Kx8 70ns - we soll das denn kaufen? Zurück
zu Farnell:
Der AS7C3256A-15TCN 32K x 8 / 15ns TSOP mit 3.3V
http://de.farnell.com/jsp/endecaSearch/partDetail.jsp?SKU=7772955&N=401
bzw http://www.farnell.com/datasheets/54444.pdf für 2,84 Euro klingt
schon mal gut. Da waren meine 70ns etwas großzügig bemessen. Es reichen
für >50MHz auch 2 Bänke. Allerdings TSOP mit 0.5mm. In SOJ gibt's die
aber auch im Datasheet. Wie Dirk schreibt, ist das Positionieren nichts
für Grobmotoriker - aber was ist das schon in der Elektronik :)

Die 3.3V habe ich bewußt ausgesucht, um die Störpegel gering zu halten.
Auch für den CPLD.

Ein XC9536XL-5VQ64C
http://de.farnell.com/jsp/endecaSearch/partDetail.jsp?SKU=3849030&N=401
bzw http://www.farnell.com/datasheets/28287.pdf kostet 5,90€ (Farnell)
mit 5ns und 36 I/O, damit sind 178MHz machbar, na wer will immer noch
bei den Möglichkeiten Lochraster nehmen :)

Falls die I/O knapp werden: XC9572XL-10TQ100C
http://de.farnell.com/jsp/endecaSearch/partDetail.jsp?SKU=3849090&N=401
bzw http://www.farnell.com/datasheets/28289.pdf mit 10ns, 72 I/O und 178
MHz max für 10,10€.

Mal kurz rechnen:

15 Adressleitungen -> 32k
8  Datenbus
3 Steuerleitungen
---
26 I/O per SRAM

bei 2 Bänke (52 I/O) und 8 Inputs sind noch 12 I/O für Kommunikation
o.a. frei. Offenbar liegen hier die Grenzen und ist ein XC9572 zwingend
- oder man macht Abstriche und nimmt eine Bank. Immerhin bekommt man für
~15Euro 8x 133 MHz Channels, ohne Input Stage.

Thema Taktgenerierung:
VCO per uC programmierbar, damit kann man dann echt die Grenzen
austesten. Die Chips dazu gibt's bei Maxim/AD und den anderen üblichen
Verdächtigen. Aber danach zu suchen ist mir heute zu spät. Wichtig
dürfte geringer Jitter sein, also PLL - wie gesagt ... schon was
gefunden?

Thema xxx MHz:
Wenn ich mir die Möglichkeiten so ansehe, wird wohl ein Multilayer
notwendig sein, ansonsten sind's Perlen für die Säue... Was mir etwas
Sorgen bereitet sind die Langen Leitungen von der Messstelle zum CPLD.
Einige LA (Tek/Agilent) scheinen eine Box zu haben, wo die ca 5 cm
langen Messtrippen rauskommen und dann ein Twisted Flachband von ca.
30cm ... wohl aus gutem Grund. Ich vermute mal, in der Box sind die
Level Trigger und eine Art Bus Treiber zum eigentlichen Gerät - wer
weiss mehr?

Thema Input Stage:
siehe zuvor. Schnelle Komperatoren gibts bei den üblichen Verdächtigen,
aber heute zu spät schon ... Nur die Schutzmaßnahmen am Eingang... Das
Elko schlägt Transis anstelle von Dioden vor (Ableitung auf
Betriebsspg./Erde) aber wie sieht das aus der HF Technik aus?

Thema Cache aus Motherboard:
Dann müssten alle bei ebay das gleiche Motherboard kaufen was
unverhältnismäßig die Preise in die Höhe treibt ... Auch schafft dies
keine allgemein zugängliche Lösung. BTW, bei den SRAM preisen würde
sich das auch nicht lohnen.

Thema prinzipieller Natur:
Alles hier beruht auf der Annahme, das es mit einem CPLD machbar ist.
Proof of Concept fehlt also, evtl. nicht ganz -> Bennedikt.
Es wird auch nichts für Beginner werden, alleine schon das Löten gibt
Anlass zur Freude :-)

Thema organisatorischer Natur:
gibt's morgen, ich sehe schon Eagle <-> Protel <-> ....

Viele Grüße und gute Nacht
Olaf

PS: Man, schon wieder soviel geschrieben, dabei bin ich ein ganz
stiller Typ :)

von Thomas O. (Gast)


Lesenswert?

Hallo,

wenns sich genug Leute finden würden, wäre das bestücken lassen
warscheinlich auch kein Problem oder? Hat schomal jemand so ne kleine
Serie Platinen inkl Bestückung fertigen lassen? Mit welchen Preisen ist
da zu rechnen?

von Hans (Gast)


Lesenswert?

ich greif dem morgen gleich mal vor und schmeiss das thema geda ein ;)

hat damit schon mal wer gearbeitet?? wenn wie vernünftig ist das
teil???

nachdem mir mein raid jetzt offiziell tot ist muss ich mir jetzt keine
gedanken mehr um windows machen => komplettumstieg auf linux => geda
wird interessant...

zum thema clock.. CY22393,CY22394,CY22395

CY22393 liesse 6 unterschiedliche clocks zu...wäre doch geil ;) 6
module mit unterschiedlichen zeitbasen G die frage ist nur..wozu G

dummerweise gibt nur den 5er bei rs und bei farnell überhaupt
keinen...


73

von JME (Gast)


Lesenswert?

Ich stimme der Meinung zu, das die parallele Schnittstelle nicht
die erste Wahl ist. Wir haben auf der Arbeit 2 Personal Logic
Analyzer von Agilent und immer wenn wir die Teile an einen neuen
PC haengen gibts Probleme mit den Schnittstellen. Das Teil braucht
ganz bestimmte Schnittstellenmodi und mit manchen Rechnern will
es auch gar nicht spielen.
Ich wuerde die Variante RS232 mit einer Bestueckungsoption fuer
den FTDI... vorziehen. Auch den Vorschlag, das ganze aus Modulen
mit je einer 8-Bit- oder meinetwegen auch 16-Bit-Capture-Unit
mit eigenem Speicher aufzubauen finde ich gut. So kann jeder
selbst bestimmen wie viele Kanaele er implementiert. Das Problem
oder besser die Herausforderung ist dabei halt die Verbindung
der Module untereinander und mit dem Controller (gemeinsamer
Takt, Triggersignale, Daten auslesen). Das wuerde auch gleich
die Frage nach dem Steuerbaustein beantworten, ich denke da
passt ein PLD pro Modul am besten.
Das ganze wuerde dann schon recht nahe an meine bisherigen
Vorstellungen fuer einen modularen LA herankommen. Hier mal
kurz einige der bisherigen Gedanken:

Das Controllermodul enthaellt die Schnittstelle zum PC, den
Addresszaehler fuer alle Module und die Takterzeugung fuer alle
Module. Hier koennte man auch so Sachen wie Pre-/Posttrigger,
Sampletakt, Speichertiefe konfigurieren. Die Capture-Module
enthalten je einen PLD und den Speicher. Der PLD integriert
die Triggerlogik und die Steuerung der Transfers zum und
vom Speicher (evtl. verschachtelte Zugriffe auf 2 Speicher).
Auf allen Modulen lassen sich Triggerbedingungen konfigurieren
(Pegel, Flanke) und die entsprechenden Ausgangssignale werden
auf dem Controllermodul im PLD ausgewertet. Noch voellig offen
und nicht minder wichtig sind aber so Sachen wie Anpassung der
Triggerlevel und Eingangsschutzbeschaltung.

Da haetten wir also eine weitere Variante im grossen Ringen
um die perfekte Loesung. Wie waere es wenn einfach mal einer
derjenigen,die schon angefangenen Code haben diesen etwas
genauer vorstellen und ausgehend davon entschieden wird wie
es weitergeht. Ideen gibt es sicher genug, aber wenn schon
etwas brauchbares da ist waere es doch schlecht das zu
ignorieren.

Nochwas, koennen wir die Wahl der Softwareumgebung erstmal
ausklammern? Das wird erst interessant sobald ein Stueck
funktionierende Hardware vorliegt. Der Weg bis dahin ist
variantenreich genug.

Jens


PS: Falls noch ueber verschiedene Parameter abgestimmt wird,
hier ist meine Wunschliste:

Speichertiefe: >=8k
Sampletakt: >=32MHz
Kanaele: 32

von Hans (Gast)


Lesenswert?

hmmm dann bekommt jeder cpld (der captured) einen cs-pin dazu... der
schaltet den spi auf threestate... also hängen alle module am spi bus..
immer eins wird ausgewähl und wird konfiguriert..

alternativ könnte man auch i2c nehmen...
aber ich bezweifle, dass es dann spass macht grössere speicher zu
kopieren...

und am besten sieht man alte isa stecker am "mainboard" vor wo der
controller drauf ist und steckt dann dort die module rein... wenn
damals 16mhz gingen.. und pci immerhin auch als 66Mhz version verfügbar
ist düfte damit das clk-verteilen kein problem mehr sein...

bleibt noch die frage nach einem geeigneten controller.. ich bin für
"am schnellsten" und "am meisten ram"... da würde z.b ein LPC2106
ganz gut passen...  der bekommt dann noch die gzip-lib rein und macht
immmer 16kb blöcke die er komprimiert überträgt.. sollte doch ganz gut
gehn und dadurch dürfte auch rs232 schnell genug werden ;)


gut also was haben wir jetzt alles auf der wishlist...

möglichst billig
modular modular
möglichst simpl

was hätten wir an vorschlägen was bauteile betrifft...

XC9536XL oder XC9572XL =>cpld
AS7C3256A =>sram
avr/arm =>controller
CY22393/CY22394/CY22395 =>clockgen

interfaces

cpld=>controller : spi,i2c
controller=>pc : rs232(,usb,ethernet)

von Thomas O. (Gast)


Lesenswert?

Hallo,

ich denke mal mit Porttreiber gibt keine Probleme unter XP auf die
parallele Schnittstelle zuzugreifen. Auf jedenfall ist es mit einem
Basic-Interpreter sehr einfach darauf zuzugreifen und die Daten in eine
Datei abzulegen. Ich würde mir zur Datenübertragung an den PC eine AVR
wünschen so kann jeder das ganze auf seine Zwecke anpassen nen LPD kann
warshceinich nicht jeder programmieren.

So stel ich mir das inzwischen vor. Die einzelnes Bytes (16bit) z.b.
auf je einen Speicherbaustein geben. Mit der Logic werden die Adressen
an die RAMS übertragen und die Schreibbefehle gesendet bis diese voll
sind. Und um das ganze dan auszulesen kann man sich z.b. eines AVR's
mit einpaar Latches bedienen, so kann jeder sein gewünschtes Protokoll
verwenden.

Gut fände ich wenn man die Samplerrate per Dipschalter vorgeben kann,
auch könnte man durch z.b. einen 4bit Code(Dipschalter) dem PLD
mitteilen wie groß die Speicherbausteine sind damit man vorwählt wie
weit der PLD hochzählt bis er stopt, so kann jeder die gewünschte /
finanzierbare Speichergröße verbauen.

von Thomas O. (Gast)


Angehängte Dateien:

Lesenswert?

Hallo,

Habe meine Gedanken auch mal in einen Schaltplan gefasst. Was haltet
ihr davon? Auflösung ist etwas hoch gewählt. Ich stelle es mir so vor:
Von oben rechts kommen die Signale rein die dann direkt an den I/O's
des Speichers anliegen. Links gehen die Leitungen weiter zum PLD für
die Triggerung. Über die Dipschalter kann man jetzt den Kanal zum
triggern auswahlen, die Triggerart einstellen, die Größe der
Speicherbausteine und wie schnell der PLD die Adressen hochzählt und
die Schreibbefehle übermittelt. Das würde jetzt alles komplett
selbständig ablaufen. Wenn der PLD seine Adressen komplett durchgezählt
schaltet er die Adressleitungen wieder auf 0 und schaltet eine Leitung
des AVRs auf High so das dieser weiß er kann jetzt mit der
Datenübertragung beginnen. Er gibt jetzt über die 2te Leitung einen
Takt zum PLD so das dieser jedesmal die Adresse höher stellt, der AVR
steuert die Befehle zum lesen so das die Daten an 2 Ports anliegen die
er dan einlesen kann. Und ja nach Protokoll was dann jeder selbst
schreiben kann gibt der AVR die Daten an den PC aus.

von Benedikt (Gast)


Lesenswert?

Ich bin auf jedenfall auch ein Gegener der Idee den Parallelport zur
Datenübertragung zu verwenden.

Zu DOS Zeiten ging das noch ganz gut, aber mittlerweile blockiert mein
Druckertreiber den Port (bzw. verändert anscheinend einfach mal so
zwischendurch ein paar Pins, um den Status des Druckers abzufragen.)
Früher habe ich viel mit dem LPT gemacht, aber seitdem ich diesen
Laserdrucker habe, mache ich alles nur noch über RS232.
Das umfasst sowohl echtes RS232 als auch den FT232 mit immerhin
75kByte/s.

Außerdem hat der LPT keine Zukunft. RS232 wird es dank FT232 und uC
noch in vielen Jahrzehnten geben.

Die Datenübertragung von meinem Logikanalyser (mit 256kByte Speicher)
läuft noch mit 115,2kBaud, dauert bei 256kB also ziemlich lange.
Wenn man aber bedenkt, wie lange es dauert bis man die Daten
durchgesehen hat, dann ist das noch eine akzeptable Zeit.

Für eine schnelle Darstellung reduziere ich einfach die Datenmenge,
indem ich nur 1kB der Daten übertrage. Das passt genau auf eine
Bilschirmseite und man erkennt ob der geünschte Datenstrom über das
Gerät läuft, so dass man die eigentliche Aufzeichnung starten kann.

Ich würde das ganze auch mit CPLD (als synchroner Adresszähler, evtl.
mit Interleaving und als Triggerung) machen.
Man könnte entweder einen Globalen Adresszähler einbauen, und für jedes
Modul einen weiteren CPLD für die Triggerung verwenden, oder für jedes
Modul einen eigenen CPLD der den Adresszähler und die Triggerung
beinhaltet.
Die Module arbeiten dann im Pronzipt nur als FIFO:
Schnell einlesen, langsam ausgeben.

Die Daten würde ich dann zu einem AVR schicken, indem dieser die
Adresszhähler resettet und der Reihe nach alle Bytes ausliest, ehe er
zum nächten Word springt. Die Daten eventuell komprimieren (z.B. nur
Änderungen speichert), das funktioniert eigentlich ziemlich gut. Bei
vielen Signalen kann ich so die 256kByte auf wenige kByte reduzieren.
Nur wenn ich sehr viele Änderungen habe (z.B. Datenbus eines uP) dann
geht die Datenmenge in den MB Bereich.

von FPGA-User (Gast)


Lesenswert?

Bem.: zur Schaltung
wenn die Inputs direkt an die Daten-Pins des SRAM(Typ?)
gehen, dann gibt es ein Problem in dem Moment, wenn
der AVR die Daten lesen will (Kollision auf dem Bus)
also entweder muss noch ganz vorn am Eingang ein Bustreiber
rein, den man auf Tristate schalten kann oder man muss
jedesmal abstecken, bevor man die Daten lesen kann.

Bei 256kBytes Adressraum wird schon ein 18bit Adresscounter
benötigt, damit sind die Hälfte aller Macrozellen im XC9536
weg, halte es für schwierig, die restliche Logik (Triggerung...)
noch mit reinzuquetschen, ein XC9572 scheint mir das Minimum
zu sein.

von Thomas O. (Gast)


Lesenswert?

Hallo,

ja ne Bustrennung wäre bestimmt nicht verkehrt, damit beim Lesen keine
Eingangssignale auf den Bus gelangen. Evtl. 2 8Bit-Latch(573) nehmen
diese kann man ja Tristate schalten.

von Tim (Gast)


Lesenswert?

100 Eier, daß das Projekt nicht zum Ziel führt...

von Jens (Gast)


Lesenswert?

@Tim

Sehe ich auch so.

@FPGA-User

>Bei 256kBytes Adressraum wird schon ein 18bit Adresscounter
>benötigt, damit sind die Hälfte aller Macrozellen im XC9536
>weg, halte es für schwierig, die restliche Logik (Triggerung...)
>noch mit reinzuquetschen, ein XC9572 scheint mir das Minimum
>zu sein

Besser wäre es, 2 oder 3 XC9536 einzusetzen. Schließlich wird dieses
Bauteil für EUR 1,50 bei eBay angeboten.

von Patric (Gast)


Lesenswert?

Ich würde bei einem solchen Projekt auf einen grösseren FPGA setzen.

Ein XC3S400 hat z.B. 288k dual-ported Blockram und 4 DCMs mit denen
sich ein vernünftiges Clocksignal erzeugen lässt. Als Schnittstelle ein
FT245BM , der sich relativ leicht vom FPGA aus ansteuern lässt. Durch
die PC-seitigen Treiber von FTDI gibt's auch keine Problem beim
Software-Interface auf dem PC.
Den XC3S400 gibt es als TQFP144 oder PQFP208. Ich würde aber trotzdem
die Lösung mit einem fertigen Eval-Board favorisieren. Da gibt's ja
eine ganz nette Auswahl.

von Hans (Gast)


Lesenswert?

also ich würde das interface zwischen controller und cpld über spi
machen...

weil der avr kann nur 16bit adressieren...
ports einzeln umsetzen finde ich insofern nicht gut weils einfach
langsam ist...
spi kann er schnell und da gibts doch burst read wenn ich das richtig
sehe... => pfuscherei wenn mans übers speicherinterface einbindet

2Mbit/sec über SPI dürften doch reichen.. sind immerhin 256kb/sec
wobei ich hier immer noch 1-2sec/auslesen (also capturen => anzeige)
anpeilen möchte...

zum thema avr: ich würd einen arm nehmen der viel ram hat... ist zum
komprimieren notwendig..  und die 64k die der lpc2106 hat sind auch
schon eng....so um 1MB wär gerade richtig.. dann kann man die ganzen
daten auf einem rutsch holen, komprimieren und weiterschicken...

prinzipiell würde aber ein avr reichen... für die kompression müsste
das halt blockweise machen... oder weglassen...

ich bin auf jeden fall für die modularisierung sprich:
- im besten fall einen clock-gen am mainboard der für jedes modul eine
unterschiedliche timebase machen könnte
- jedes modul hat seinen eigenen counter,trigger,speicher

die module zu syncronisieren sollte eigentlich kein problem sein, da
der clock-gen eh die clocks aus der gleichen referenz herunterteilt...
=> wenn man sie gleich vorgeladen werden sollten sie auch nicht
großartig verschoben sein...

wenn man mehrere serielle interfaces auf einem uc-board hat kann man
dann ohne probleme überall ein modul ranmachen und braucht nicht
dauernd umstecken udgl..

dafür bekommt dann der cpld auch noch einen ext-trigger damit man auch
alle gelichzeitig an einem signal arbeiten lassen kann...

@patrik: und was kostet da so ein eval board???

ich bin wie gesagt stark für die variante mit dem wenigsten aufwand ;)
und kein uc der scheisse baun kann ist in meinen augen VIEL weniger
aufwand ...

meine ideen sind damit zwar alle hinfällig.. der preis sollte
eigentlich durch die 1fpga+1ft245-lösung auch nicht so tragisch sein..


sonnst kommen ja noch ram,uc, schittstellentreiber udgl dazu...

73

von ope (Gast)


Lesenswert?

... und ich dachte gestern, ich wäre spät dran :-)

@Tim
Sehe ich auch so. Aber evtl. kommt wenigstens ein tragfähiges Konzept
raus, wenn die Software und Schnittstellenwünsche außen vor bleiben.

@JME
Das mit dem Clock und Trigger Event Distibution bereitet mir wegen der
Laufzeit/hohen Frequenzen auch etwas Kopfzerbrechen, immerhin müssen
die einzelnen CPLD untereinander kommunizieren, der uC ist zu langsam
dafür; dh. Trigger Logik/Clock unabhängig vom uC! Immerhin kann ein
8bit Channel zB. den Bus abhorchen, während mit dem 2ten 8Bit Channel
das Trigger Signal rausgefischt wird (CS, RW etc). Insofern sind 16Bit
Breite Minimum.

@Thomas O.
Dipschalter: wozu, wenn doch ein uC vorhanden ist. Wichtiger wäre
vielmehr ein Hardware Code Feld, wo Anzahl Channel, PCB Revision etc.
vermerkt sind, damit die Firmware weiss, was sie unter sich hat.
Schaltplan: Mal abgesehen vom Tristate Problem hat der uC ein Timing
Problem (e.g. >50MHz vs. 16MHz) und muß zudem den Interleave wieder
zusammenflicken.

Sinnvoller wäre es, die Daten über den CPLD auszulesen, d.h. von den 12
verbleibenden I/O fallen 8 (daten) + 2 (cs, rd/wr_) = 10 wieder weg. Es
wird also eng. Mit diesem Mini-8bit-Bus kann man aber recht einfach
kommunizieren (CPLD <-> uC). Es müssen (sampled) Daten gelesen und
Konfig/Trigger Daten (wenn auch wenige) geschrieben werden. Evtl. kann
man ja mit den verbleibenden 2 I/O einen 4-Mode Adress Select
generieren (Mode1: uC liest Daten, Mode2: uC schreibt Trigger Daten,
....) Falls die I/O bei konkreter Betrachtung nicht reicht, müssen eben
Nibbles (4Byte) übertragen werden.

@FPGA-User
Wieso 18Bit Counter? 2^18 = 256k Evtl. wäre es für einen Delay Timer
sinnvoller/notwendig? aber nicht für die SRAMs.

Die Lösung mit den SRAM Bänken geht davon aus, das im CPLD das Latch
realisiert wird, daher auch der höhe I/O Verbrauch. Wenn externe Buffer
wieder verwendet werden (müssen), geht der kompakte/einfache Aufbau
wieder verloren und man sollte eine FPGA Lösung favorisieren.

Wo ich jetzt wieder hänge: 2x SRAM (2x 32kx8) + CPLD, passt das nicht
in ein FPGA? Hintergrund: Das Timing innerhalb des FPGA ist
berechenbar, bei einem PCB kommen mehrere Faktoren zusammen und löten
muss man bei beiden Lösungen 0.5mm Beinchen ... Also, passt dies dort
ein FPGA rein? Eine Lösung nun mit 2-3 CPLD zu realisieren kann nicht
gut sein, da mit der Anzahl der zu verlötenden BE auch die
Fehlerwahrscheinlichkit steigt -> FPGA Lösung.

Offenbar bereitet die Wahl der Schnittstelle, technisch gesehen, die
geringsten Probleme - evtl. sollte man diese wie auch die
Softwarerealisierung ertmal ausklammern.

Viele Grüße
Olaf

von Patric (Gast)


Lesenswert?

@Hans

Ich hab das Altium Board. Hat mich 120.- inkl. Versand gekostet.
Allerdings bin ich mir nicht sicher ob es das Board von Altium noch
gibt. Das wäre aber kein Problem, Xilinx hat eine Reihe Eval-Boards
gelistet, die in Frage kommen und sich in einem ähnlichen Preisrahmen
bewegen. Zudem hätte ein solches Board noch den Vorteil, dass man es
auch für andere Projekte nutzen kann.

von FPGA-User (Gast)


Lesenswert?

@ope

ganz meiner Meinung, das wird Brühe mit mehreren CPLDs,
wenn man eine 32-Kanal-Version haben will, lötet man
tagelang rum um am Ende festzustellen, dass nichts geht,
weil man irgendwo eine Brücke reingelötet hat und dadurch
evt. noch ein Bauteil kaputt gegangen ist -> von vorn anfangen.

Mit einem FPGA hätte man auf Anhieb die Mögl. für 32 Kanäle,
interne Block-RAMs reichen für eine Alpha-Version sicher
(z.B. 3S200 : 200 kBit Block-RAMs ergibt ca. 6k x 32 Kanäle.)
Da man sowieso immer den PC dran hat, bräuchte man nichtmal
ein Config-PROM und die Taktaufbereitung mit DCMs oder PLLs
wäre wesentlich eleganter als beim CPLD.
Synchronisation zwischen CPLDs entfällt.

Eine FPGA-Version würde m.E. den uC überflüssig machen ->
wieder 1 Bauteil und 1 Software weniger !

von Thomas O. (Gast)


Lesenswert?

Hallo,

@Olaf: In meinem Vorschlag hat der AVR nur die Funktion die Daten zum
PC zu übertragen nachdem sie schon im RAM liegen, so kann jeder sein
gewünschtes Protokoll integrieren und da gibts dann auch keine
Timingprobleme weil der halt einfach langsamer auslesen kann und die
Daten gemütlich zum PC überträgt.

Zur Speicherung der Daten wird alles durch ein FPGA bzw. CLPD gemacht
weil nur dieser die Geschwindigkeit aufbringt.

Ok das mit den Dipschaltern ist nicht so gut, man könnte es aber vom PC
an ein Schieberegister schicken so das man dann dem FPGA 255 Befehle für
die Triggerart, Startverzögerung, Samplegeschwindigkeit usw zusenden
kann, falls das Projekt später ja mal zuwachs bekommt.

von Patric (Gast)


Lesenswert?

@Thomas O.

Man kann sich die ganze Synchronisiererei zwischen CPLD, AVR und
Speicher sparen, wenn man alles in einem FPGA hat. Die Spartan3 haben
alle dual-ported RAM was die Zugriffe von zwei getrennten Prozessen
(Daten Speichern und Daten übertragen) erheblich vereinfacht. Wenn man
einen FPGA verwendet ist der AVR im meine Augen überflüssig und bringt
eigentlich nur zusätzliche Probleme.

von Andreas S. (andreas) (Admin) Benutzerseite


Lesenswert?

Mein Vorschlag: fangt erst mal klein an, sprich 8 oder sogar 4 Kanaele
(meistens hat man es sowieso mit seriellen Verbindungen zu tun) und
wenige MHz Samplerate. Das sollte sich mit einem kleinen CPLD + SRAM
realisieren lassen. Wenn ihr gleich mit 32 Kanaelen, zig MHz, 4-lagiger
Platine, Spartan-3 und 256 kB anfangen wollt kann ich euch garantieren
dass das Projekt einschlaeft.

von Andreas S. (andreas) (Admin) Benutzerseite


Lesenswert?

Noch was: vergesst "Modularitaet".

von Hans (Gast)


Lesenswert?

ich habe gerade etwas im inet gestöbert und was nettes gefunden..
auf http://shop.trenz-electronic.de/

Spartan-3 200k Mikromodul 79.00EUR (91.64EUR inkl. MWSt)
Spartan-3 400K Mikromodul 119.00EUR (138.04EUR inkl. MWSt)

oder
Xilinx Spartan-3 Starter Kit DO-SPAR3-DK  99.00EUR(114.84EUR inkl.
MWSt)

die preise finde ich eigentlich garnicht soo schlimm...
wobei letztes hätte keinen usb2 transceiver...

73

von Jens (Gast)


Lesenswert?

Zum Thema klein anfangen: man nehme einen schnellen µC, lege die Signale
an einen Port, tastet diesen ab und speichere die Daten im internen RAM.

von Andreas S. (andreas) (Admin) Benutzerseite


Lesenswert?

Na gut, das ist dann aber wirklich "klein". Mehr als 1 MHz ist da
nicht drin.

von FPGA-User (Gast)


Lesenswert?

Idee für die Kommunikation (Version 0.alpha) :

das FPGA bekommt einen UART-Core und extern einen MAX 232 o.ä.,
Es gibt Register Schreib/Lesebefehle vom PC, Acknowledge vom FPGA
und Daten vom FPGA.

Ein Register-Schreibbefehl geht meinetwegen mit 0x55 los,
dann kommt z.B. die Adresse des Registers im FPGA, dass man
beschreiben möchte und dann die Daten(Bytes)
Am Schluss ein Prüfbyte, FPGA checkt das und sendet ein
Ack zurück, meinetwegen 0x66 für OK und 0x77 für Fehler.
Wenn der PC 0x66 zurückbekommt -> OK, 0x77 -> Fehlerausgabe
an User oder Befehl wiederholen (3 mal, dann Error).

Register Lesen : beginnt meinetwegen mit 0x88, dann die Register-
adresse die gelesen werden soll, FPGA sendet daraufhin x Bytes
mit dem Inhalt des Registers + Prüfbyte.

Spezialbefehl Datenblock Lesen:
FPGA sendet auf diesen Befehl hin den kompletten RAM-Block byteweise

Version Beta:
FPGA sendet Daten komprimiert, d.h. nur Änderungen werden übertragen

Ein Register könnte z.B. den Triggertyp beinhalten, ein weiteres
ein Trigger-BitMuster, dann eine Triggermaske usw.
Wenn die Registermap bekannt ist, kann jeder seine eigene Software
schreiben

von Thomas O. (Gast)


Lesenswert?

Hallo,

nagut also FPGA jetzt bin ich vollends auf euch angewiesen. Hat mal
jemand eie Bezugquelle und eine Bezeichnung für ein geeignetes SRAM für
mich, möchte mir mal ein Datenblatt zu anschauen. Ich habe hier ein
IS61C64A-20 SRAM finde aber nur ein Datenblatt des IS61C64B Typen. Wie
groß sind eigentlich diese Blockram Dinger

von Jens (Gast)


Lesenswert?

@Andreas

> Mehr als 1 MHz ist da nicht drin.

Habe das mal mit einem dsPIC gemacht (30MHz), dank seiner nützlichen
Adressierungarten dauerte ein Abtasten und Speichern nur 2 Takte (ohne
Delays).

mov $100, W1    ; (1) Startadresse des Buffers
do  2048, loop  ; (2) 2048 mal abtasten
mov PORTB, W0   ; (1)
loop:
mov W0, [W1++]  ; (1)
...

Habs jetzt mal aus dem Kopf hingeschrieben, ich hoffe es stimmt alles.
Es ist somit viel mehr als 1MHz möglich.

von Andreas S. (andreas) (Admin) Benutzerseite


Lesenswert?

Und der IO-Port macht 15 MHz mit? Dann waere das allerdings eine
interessante Alternative.

von FPGA-User (Gast)


Lesenswert?

Abtasten und speichern ist das eine, aber wenn nebenbei
noch die Triggerung gemacht werden soll, dann wird der
uC doch wieder langsam - oder ?
Oder soll die Triggerung jetzt entfallen ?

von Jens (Gast)


Lesenswert?

Auf 15MHz wirds nicht kommen, da man ja auch langsam abtasten möchte.
Daher müßte innerhalb des Schleifenkörpers noch ein delay rein:

mov $100, W1    ; (1) Startadresse des Buffers
do  2048, loop  ; (2) 2048 mal abtasten
mov PORTB, W0   ; (1)
repeat "val"    ; (1) 0 <= val < 16384 (min. 1 Takt, max. 16384
Takte)
nop             ; (1)
loop:
mov W0, [W1++]  ; (1)
...

So wären wir bei mindestens 4 Takten, also max. 7.5MHz und min. 1.8kHz.

von Jens (Gast)


Lesenswert?

@FPGA-User

Natürlich ist klar, daß das ganze auf Kosten der Triggerung geht. Ich
wollte damals einfach nur einen seriellen Bitstrom untersuchen und
wartete einfach in einer Schleife auf die fallende Flanke des Signals
und fing dann mit der Aufzeichnung an.

von Hagen (Gast)


Lesenswert?

Ich weis nicht so recht. Der Schritt von einem CPLD zu einem FPGA ist
nicht nur ein Schritt von unterschiedlicher Hardware und
unterschiedlichen Möglichkeiten.

1.) ein reiner FPGA Analyser hat nichts mehr mit diesem Forum zu tun
2.) auch wenn FPGA's intern schneller getaktet werden können so sind
sie denoch bei weitem langsammer als CPLD's.
3.) die Signale innerhalb FPGA's jitterfrei zu bekommen ist viel
komplizierter als beim CPLD

Ich würde es so machen:

Gemeinsammer Datenbus, angeschlossen der AVR, SRAM und CPLD. Der CPLD
ist deaktiviert = HighZ und der AVR übernimmt den Datenbus. Vor einer
Messung trennt sich der AVR vom Datenbus = HighZ und startet das CPLD.
Dieser legt über Bustreiber die Messignale auf den Datenbus und erhöht
mit vorgebenen Takt einfach den Addresszähler. Das macht der CPLD so
lange wie der AVR ihn über ein zusätzliches Signal arbeiten lassen
möchte. SRAM's gibts asynchrone statische mit 15ns. Das Auslesen des
SRAM's durch den AVR kann nun auf zwei Wegen erfolgen:
1.) der AVR ist ein ATMega162 oder 128 mit XMEM Interface und kann so
direkt das SRAM auslesen
2.) der CPLD wird doppelt benutzt. Er enthält ja einen Addresszähler
zum Schreiben des SRAM's. Dieser kann aber auch zu Lesen des SRAM's
benutzt werden. Der SRAM wird immer sequentiell geschrieben und
gelesen. Der AVR, ein ATMega8 zb. muß einen 8 Bit Port freimachen und
diesen auf den Datenbus legen. Der CPLD taktet nun gesteuert vom AVR
die Addresse langsam hoch. Der ATMega8 liest daraufhin seinen 8 Bit
Port ein. Das ist pro Byte mit 3 Takten erledigt. Vorteil ist dabei das
man nun auch zb. 512Kb statische SRAM's benutzen kann ohne das der
ATMega8 oder CPLD ein kompliziertes Memory Banking benutzen müssen.

Mit einem AVR + kleinen CPLD + SRAM + Bustreiber + Komparatoren ist ein
Mini-Analyser mit bis zu 32Mhz Samplerate möglich.
Bei dieser einfachen Version liegen im Grunde nur der SRAM Addressbus
komplett am CPLD, also 16-19 Leitungen. Dann noch OE,WR,CS
Steuerleitung des SRAMs, der Clock Eingang und eine Steuerleitung für
den AVR. Der AVR selber benötigt einen 8Bit Port zum Lesen des
Datenbusses. Dann noch zwei Steuerleitungen eine für den CPLD und eine
zum Aktivieren der Bustreiber. Der Bustreiber liegt ebenfalls parallel
zum AVR am Datenbus. Der CPLD stellt nur einen variabel getakteten
18Bit Zähler dar, mehr nicht. Der AVR bestimmt nun mit welchem Takt der
CPLD hochzählt, kann also auch manuel Step by Step getaktet werden.

Gruß Hagen

von Andreas S. (andreas) (Admin) Benutzerseite


Lesenswert?

So habe ich mir das auch gedacht (Moeglichkeit 2).

von Thomas O. (Gast)


Lesenswert?

Hallo,

ja das ist im großen und ganzen so wie ichs gemeint habe. Denke das ist
die einfachste Möglichkeit es sei denn es gibt einen Baustein wo alles
integriert ist.

von Dirk (Gast)


Lesenswert?

Hallo,

falls doch die Entscheidung auf ein Spartan3 FPGA fallen sollte und
einem das Loeten nicht liegt. Ein TQ144 Sockel koennte man kaufen,
somit ist der FPGA tauschbar.

>2.) auch wenn FPGA's intern schneller getaktet werden können so sind
>sie denoch bei weitem langsammer als CPLD's.

Wieviel waere den mit einem FPGA Moeglich?

Gruß,

Dirk

von ope (Gast)


Lesenswert?

@Hagen:
Das Memory Banking kam eigentlich wegen des langsamen (70ns) Speichers
der sich in der Grabbel Kiste tummelt. Bei zwei Bänken wird nur das LSB
des Adresszählers genibbelt und als Chip Select benutzt. Einige SRAM
haben ja (CS0, CS1_) so dass mit intelligenten Layout es recht einfach
wird. Das Problem ist ja das Timing des (langsamen) SRAM, da
Adressen/Daten für eine gewisse Zeit stabil anlegen müssen.

Kann der XC9572 nicht tristate (bzw HIGHZ) selber, so dass man den Bus
driver umgehen kann: " IOPin <= 'Z'; ?? Das erinnert mich alles so
an meine Z80 Zeiten und TTL Gräber ....

Viele Grüße
Olaf

von Jörn (Gast)


Angehängte Dateien:

Lesenswert?

Anbei mal mein Quellecode für den LA (Projekt für ISE 7.1).

@FPGA-User:
Ähnelt deiner Beschreibung...

Kommunikation über RS232. Befehle setzen sich aus zwei Bytes zusammen.

-erstes Byte : Adresse des zu schreibenden Registers
-zweies Byte : Wert.

Die gespeicherten Werte werden automatisch zum PC gesendet, wenn ein
Trigger gefunden wurde und der Speicher voll ist.

Gruß Jörn

von FPGA-User (Gast)


Lesenswert?

@Hagen
2) und 3) stimmen so nicht, ich kann im FPGA z.B. mit 500 MHz arbeiten
wenns denn sein muss, abhängig vom Speed-Grade des FPGAs.
3) was meinst Du mit jitterfrei bekommen?
Bei einem CPLD wird auch nur eine max. Tpd garantiert, die
Laufzeiten im CPLD sind auch von der Implementierung abhängig,
das Routing über eine Switch-Matrix hilft da nicht immer.
Bei einem synchronen FPGA-Design sehe ich keinerlei Probleme.

Das einfache hochzählen der Adressen wird übrigens nicht reichen,
ich nehme mal an, dass zumindest noch die /WE-Leitung bedient
werden muss, dann aber auf die Setup- und hold-Zeiten der
Adresse und min. WE-low-Time achten.

Und Achtung, wenn man den Adresscounter im CPLD einfach auf die Pins
rauslegt, kommt jedes Bit beim CPLD zu einem anderen Zeitpunkt
raus, die Diff. wird einige ns betragen, beim FPGA nehme ich
die Flip-Flops im IOB und hab damit alle Adressbits praktisch
gleichzeitig auf'm Bus.

von FPGA-User (Gast)


Lesenswert?

@Jörn

na, das ist doch schonmal was. Lässt sich zwar besch... lesen
(schlechte Formatierung) aber daraus könnte man was machen.

Also wenn man nich jahrelang rumbasteln will, sollte man ein
XILINX Starter-Kit kaufen, diesen VHDL-Code implementieren
und ne ordentliche Software dazu schreiben, das wars.

von Dirk (Gast)


Lesenswert?

Hi,

>Also wenn man nich jahrelang rumbasteln will, sollte man ein
>XILINX Starter-Kit kaufen, diesen VHDL-Code implementieren
>und ne ordentliche Software dazu schreiben, das wars.

ich habe mir dieses Starterkit angeschaut und werde es mir bestellen,
nachdem einige Leute mir vom Xess Board abgeraten haben.

Ich werde den weg wie FPGA-USER es beschrieben hat einschlagen. Um die
Daten etwas schneller an den PC zusenden werde ich noch den FT245 mit
anschliessen.


Gruß,

Dirk

von Patric (Gast)


Lesenswert?

@Dirk

Wenn du noch etwas warten kannst:

http://www.xilinx.com/products/spartan3e/s3eboards.htm

Leider erst ab Q3/05 verfügbar.

von Dirk (Gast)


Lesenswert?

Hi,

danke fuer den Hinweis. Werde aber nicht solange warten und ein grosser
Pluspunkt bei dem jetztigen Starterkit sind die 10ns SRAM auf dem
Board.

Gruß,

Dirk

von Konstantin Schmidt (Gast)


Lesenswert?

Also wirklich...
lese hier schon länger, aber was hier so abläuft ;-)?

Erst AVR... dann CPLD... dann mehrere CPLDs... dann FPGA... jetzt auch
das fertige Board...

Und noch eine Idee am Rande: falls ihr euch für Spartan 3 Kit
entscheidet, könnte ihr alles ohne Rechner machen - ausgabe über VGA.
Dank Microblaze und co ist alles kein Problem (nur so ;-))

Wenn es nur AVR und CPLD wären, würde ich mitmachen, so aber ist das zu
groß (nicht für mich ;-))

konstantin

p.s.: trotzdem ist alles ganz spannend :-)

von Hans (Gast)


Lesenswert?

wie wärs denn damit...

der cpld bekommt den ram exklusiv
daten wandern per spi zum uc.. natürlich im burst read ;)

dann noch z.b avr,max232 und ft232 vorsehen und fertig...

die triggerung reißt man auch noch aus dem cpld wenn das zu viel sein
sollte.. die sollte alle möglichkeiten abdecken.. also auch trigger auf
i2c start ;)

hier wäre noch eine gute idee gefragt... evtl fpga den man so läd wie
mans gerade braucht???

das dürfte dann die einfachste variante sein...

73

von FPGA-User (Gast)


Lesenswert?

das Problem bei der FPGA-Variante sind die 100 EUR für
das Dev-Kit, wenn ich das richtig verstehe?

mit der CPLD-Variante wirds aber auch mindestens 50 kosten,
oder will jeder sein Board selber ätzen ?

Zur Motivation:
Beim FPGA wären vermutlich mit den 512kBytes(?) SRAM 50 MHz drin,
32 bit parallel, ohne dass man irgendwelche Kopfstände machen müsste.
Bei Nutzung der internen Block-RAMs gehe ich von 100 MHz aus bei
verringerter Speichertiefe.
Die Triggerung könnte extrem komfortabel sein, also z.B.
"Triggern wenn Adresse = 0x0300 auf 0x500 folgt und dann warten
 bis /WE = 0 ist" oder so...

von Dirk (Gast)


Lesenswert?

Hi,

>Also wirklich...lese hier schon länger, aber was hier so abläuft ;-)?

@K. Schmidt

Erstmal muessen Ideen gesammelt werden um die Wunschtraeume
auszusortieren.

>Das Problem bei der FPGA-Variante sind die 100 EUR für
>das Dev-Kit, wenn ich das richtig verstehe?

Wenn es auf dem DEV Board laeuft kann man immer noch eine Platine
routen und in Auftrag geben und bei richtiger Abnahmemasse sollten die
Platinen auch nicht teuerer werden.

> mit der CPLD-Variante wirds aber auch mindestens 50 kosten, oder
> will jeder sein Board selber ätzen ?

Auch wenn die CPLD Platine billiger werden duerfte als die FPGA Platine
so ein grossen Unterschied sehe ich da nicht.
Ich sehe auch viel mehr den Zeitaufwand die CPLD Platine + AVR
zuverloeten.
Leider kenne ich mich in der CPLD+FPGA Welt nicht so aus, aber als
Anfaenger finde ich die FPGA Variante die einfachste.

>Beim FPGA wären vermutlich mit den 512kBytes(?) SRAM 50 MHz drin,
>32 bit parallel, ohne dass man irgendwelche Kopfstände machen müsste.
>Bei Nutzung der internen Block-RAMs gehe ich von 100 MHz aus bei
>verringerter Speichertiefe.

Die Geschwindigkeit des FPGA's macht mir weniger Kopfschmerzen,
sondern eher die Eingangsbeschaltung der LA Inputs. Normales
Datenbuskabel mit Abgreifklemmen duerfte bei der Geschwindigkeit
garnicht mehr funktionieren. Das Platinenlayout duerfte auch eine
entscheidene Rolle spielen.


Gruß,
Dirk

von Hans (Gast)


Lesenswert?

Ok soweit ich das derzeit beurteiln kann gibts hier jetzt 4 lager

1. viele ios, viel speed (~100mhz)
2. viele ios, speed nicht im vordergrund aber schon über 10-20Mhz
3. wenige ios, viel speed <= z.b highspeed i2c,spi,usb (?)
4. wenige ios, wenig speed <= z.b i2c anschaun udgl

dementsprechend glaube ich, dass es zweckmäßig sein könnt hier jetzt
einige sachen vorzuschlagen...

interface wenig speed : rs232
interface viel speed : usb

bei der wenig speed variante könnte ich mir sogar eine avr-only version
vorstellen... quasi extrem wenig speed...

bei wenig ios glaube ich, dass 8 ios schon genügen würden... vielleicht
noch 16 aber 32 wäre sicher overkill um sich z.b am memoryinterface
eines mega128 zu klemmen...es gibt ja immerhin 18bit srams.. warum
nicht so eins füllen...

soweit so gut.. ich sehe jetzt folgende lösung... man lässt die
fraktionen ihr eigenes süppchen kochen und schaut, dass die interfaces
irgendwie kompatibel bleiben => alle haben was davon, weil ein und die
selbe software mit allen capture einheiten läuft...

also ich oute mich mal als ein wenig io,wenig speed typ ;)

vielleicht sollte man mal im wiki dementsprechende artikel einführen
und wunschlisten aufstellen ...

aber zuerst wird gegessen g

73

von ope (Gast)


Lesenswert?

eben gefunden, ein weiterer Link:

http://sourceforge.net/projects/minila/

Leider meint der Kerl, das alle Tchechisch oder so können ... auch sind
keine genaueren Angaben/Schematics/Layouts etc da, lediglich sein
Kommunikations Protokoll. Nur einsam in ISE Files steht, das er einen
xc95288xl  verbaut hat. Kennt jemand genaueres über das Projekt?

@Dirk:
Tja, an den LA Inputs hänge ich auch, bisher kam dazu aber keine Ideen
(außer meine Schutzdioden). Immerhin scheint die Schnittstellen- und
Software Thematik endlich abgeklungen zu sein - und das ist gut so!

Je mehr ich über FPGA lese, desto mehr muss ich sagen, es wird sich für
viele zu einer 2ten Baustelle entwickeln, welche Kraft (und Geld)
kostet... (auch wenn ein FPGA Dev Kit sicher keine Fehlinvestion ist).

Viele Grüße
Olaf

von Benedikt (Gast)


Lesenswert?

Wenn es um wenig Speed geht, dann könnte ich demnächst eine einfache Low
Cost Schaltung mit AVR und 32kB SRAM entwerfen.
Bei meinem LCD Controller schiebt ein AVR mit 18,432MHz
durchschnittlich 2,4MByte/s übers SRAM.

Wenn ich mich nicht verrechnet habe, dann benötige ich für die Schleife
genau 7 Takte, macht also 2,6MHz Sampletakt.
Das sollte für eine Low Cost Version (AVR, 32kB SRAM, 2-3 HCMOS ICs)
reichen.

Eventuell könnte man die Windows Software von dem großen Logik Analyser
so anpassen, dass man auch diesen damit verwenden kann.

Somit wäre auch die Gruppe zu frieden, die für wenig Geld einen
einfachen Logikanalyser haben möchte.

von Hans (Gast)


Lesenswert?

die software bastle ich sowieso so hin,dass es wurscht ist ob der
analyzer jetzt 4,32 oder wenn wir lustig sind 128 input hat ;)

idee für die high-speed leute....

target=>(cmos/ttl->lvds wandler)=>scsi kabel(ultra-320)=>capture unit

nachdem  bei ulta 320 scsi immerhin 320MB/sec übertragen werden können
ergibt sich daraus, dass 160Mhz signal(16bit busbreite) bei 12(!)m
kabellänge eigentlich kein problem darstellen darf..

das sollte doch einige probleme lösen oder??? und wenn ein netter fpga
verwendung findet dann wirds eben ein typ mit lvds interface ;)

und ganz nebenbei so ein cmos/lvds interface kann nicht die welt
kosten.. drum rein in einen passenden stecker und mit einer
"scsi-verlängerung" gehts dann zur capture unit...

denk ich da jetzt verkehrt oder würde das nicht einige probleme lösen?

73

von Benedikt (Gast)


Lesenswert?

Das Kabel Problem sollte man nicht unterschätzen.
Auch die Eingangskapazität des Eingangsverstärkers sollte die zu
messende Schaltung nicht allzusehr belasten.

Bei meiner 40MHz Version verwende ich 74AHC245 als Eingangsbuffer.
Am Anfang hatte ich eind 10 adriges 30cm Flachbandkabel dran, und hatte
extremes übersprechen.
Die nächste Version hatte ein 16 poliges Kabel mit je einer Masse
zwischen 2 Signalen. Es war besser was das Übersprechen betrifft, aber
die Kapazität war zu hoch.
Jetzt habe ich direkt die Abgreifklemmen über 15cm Kabel dran.

von Hans (Gast)


Lesenswert?

es müsste doch mit den passenden lvds-treibern recht weit übertragbar
sein... wie gesagt müsste man testen...

zur weiteren inspiration:

http://alternatezone.com/electronics/pcla.htm
http://www.bitscope.com/

73

von Hans (Gast)


Lesenswert?

http://eebit.com/

hin und wieder wäre ein edit schön...

an dem teil könnte man sich schon orientieren...

73

von FPGA-User (Gast)


Lesenswert?

@Hans

nicht gleich mit der Keule losschlagen, lass mal LVDS außen vor,
da gibts noch paar andere Probleme vorher.
Klar wirds schwer, mit z.B. 50 MHz über ein Flachbandkabel
zu gehen, aber das kann man in einem 2ten Schritt angehen.
Bin eher ein Freund von stufenweisen Projekten, wenn erstmal
die Hardware was tut und die Software läuft ist schon viel
gewonnen.
Und eine hohe Abtastrate kann für viele Anwendungen interessant
sein, man könnte z.B. einen A/D-Wandler mit 50 MS/s anschliessen,
der Triggerwert wäre dann praktisch der Analogpegel.
Könnte das ein interessantes Feature sein?
Beim CPLD-Lowcost-Projekt wäre das recht schwierig nachzurüsten.
Für die Kabel zum Testobjekt findet sich bestimmt ein Spezialist
mit einer praktikablen Lösung.

von ope (Gast)


Lesenswert?

@FPGA-User:
"nicht gleich mit der Keule losschlagen, lass mal LVDS außen vor,
da gibts noch paar andere Probleme vorher."

Yep!

"Und eine hohe Abtastrate kann für viele Anwendungen interessant
sein, man könnte z.B. einen A/D-Wandler mit 50 MS/s anschliessen,
der Triggerwert wäre dann praktisch der Analogpegel.
Könnte das ein interessantes Feature sein?
Beim CPLD-Lowcost-Projekt wäre das recht schwierig nachzurüsten."

Bitscope ist so'n Projekt, solche Scope nennen sich auch Mixed-signal
Oscilloscopes MSO, zB Agilent
http://www.home.agilent.com/cgi-bin/pub/agilent/Product/cp_Product.jsp?NAV_ID=-14104.0.00&LANGUAGE_CODE=eng&COUNTRY_CODE=US&cmpid=93375.
Aber wie soll hier ein MSO geschweige DSO entstehen, wenn es keine
Einigkeit über den simplen LA gibt? -> s.o.

Ich selber hänge gerade im Eagle an einer fehlenden Bibliothek für den
XC9572PQ100. Hat jemand eine zufällig? Damit geht eine Baustelle schon
los, die an sich mit dem LA nichts zu tun hat.

Interessanter Weise bin ich mit meinen 2 interleaved SRAM (70ns) per
CPLD Lösung bei 2x 8Channel auf einen 3ten CPLD für Controlling
angekommen - die Beinchen eines reichen einfach nicht ... Immerhin
könnte ich dann ein 4MHz i2c (btw, AVR macht 400kHz max) zwischen den
CPLD etablieren zum Datenabtransport ... Beim detailierten Betrachten
explodiert plötzlich alles, Bustreiber für den SRAM möchte ich mir noch
nicht antun (den 8bit datenbus in ein latch, spart 8 Pins je CPLD).
Immerhin bietet dieses Design die Möglichkeit, das Problem mit den
langen Test Leitungen zu umgehen - 8 Kanäle per CPLD mit RAM für eine
(lokale) Probe, die per i2c/4MHz mit dem Master (CPLD, uC)
kommunizieren, die oben bereits von mir erwähnte Black Box. Indirekt
heisst dies, N Proben für N x 8 BitChannel; da i2c/4MHz im Ctrl CPLD,
sind selbst 128 BitChannel kein Problem mehr - auch die Synchronisation
wird einfacher (wieder mehr Trigger Leitungen zur Verfügung), und gemäß
Teile-und-Herrsche sollten die einzelnen Baugruppen auch einfacher zu
beherrschen sein. Später kann man ja sogar eine galvanische Trennung
per Probe bauen, später wie gesagt. Ich bin noch immer in der Konzept
Phase :(

Viele Grüße
Olaf

von FPGA-User (Gast)


Lesenswert?

@ope

poste doch maln Blockschaltbild, wie Du Dir das vorstellst.
Von I2C würde ich im CPLD abraten, 72 Macrozellen scheinen
mir zu knapp für die gesamte Logik, nimm doch einfach eine Clock-
und eine Datenleitung.

Schreib mal alle Funktionen zusammen, die ins CPLD sollen, dann
kann man grob abschätzen, ob das Konzept ne Chance hat.

von Dirk (Gast)


Lesenswert?

Hi,

ich habe gestern angefangen eine FPGA Platine mit SRAM und FTDI245 USB
Chip zurouten.

Ich habe gestern auch mein FPGA Starterkit bestellt.

Leider sehe ich immmer mehr das ich als Anfaenger alleine es niemals
fertig kriegen werde. Aus diesem Grund wollte ich Fragen wer mit mir
diesen Weg einschlagen wuerde?

Das Protokoll zum PC sollte dem entsprechen welches hier hoffentlich
entsteht.

Gruß,

Dirk

von FPGA-User (Gast)


Lesenswert?

@Dirk

aus Zeitmangel bin ich leider nicht in der Lage, komplette
FPGA-Designs for free zu erstellen, aber wenn Du einen Tipp
brauchst oder eine Frage zu FPGAs/CPLDs hast kannste mich
gern kontaktieren.

Die Frage sollte aber nicht lauten :
Wie programmiere ich einen LA in VHDL :-)))
- also Du weisst, was ich meine.

Ist Deine E-Mail Ok die da oben steht ?

von Hans (Gast)


Lesenswert?

und wie willst du dann einen trigger auf z.b eine 16bit adresse
setzen??? ;)

ich glaube, dass du auf jeden fall alle inputs in einen cpld/fpga
laufen lassen musst um allein mal den trigger zu machen...

aber ich lasse mich gerne eines besseren belehren...

73

von Hans (Gast)


Lesenswert?

post war auf ope bezogen.. man sollte nicht ewig ohne refresh
irgendwelche fenster offen haben ;)


@dirk protokoll kannst so machen wies dir spaß macht..

denn der software wird das egal sein woher die daten kommen.. ich bin
auch schon am überlegen ob es für die linuxer nicht vielleicht auch
interessant sein könnte direkt von der parallelen zu sampeln... also
insofern ists wurscht... ;)

73

von Dirk (Gast)


Lesenswert?

Hi,

@ FPGA-User

> Die Frage sollte aber nicht lauten : Wie programmiere ich einen LA >
in VHDL :-))) - also Du weisst, was ich meine.

Das ist schon klar. Danke fuer deine Unterstuetzung.

Meine richtige Email Adresse lautet fbl2000 AT gmx.net

Ich hoffe das die Lieferung des Starter Kits nicht zulange dauert.

Gruß,

Dirk

von ope (Gast)


Lesenswert?

Hier mein (aktuelles) Konzept auf Papier mit Bleistift. Ein paar Worte:

- billig, ich möchte nur ungern über 100Euro in ein FPGA DevKit
stecken, wenn das Ergebniss unbekannt ist, daher ist das ganze mehr ein
Proof-on-Concept. Vieles weitere wird sich erst dann ergeben. Hier hat
Benidikt die Nase mit seinen Erfahrungen vorn.
- Zwei Speicherbänke mit 70ns BS62LV1024 (gab's bei ebay 5Stck. 1,99)
um auch mal jenseits der 10MHz sampeln zu können. Damit wären so 25MHz
mit diesen Teilen machbar. Hieran kann man auch schon mal üben, wenn es
irgendwann 'mal an Transitional Timing analysis geht, d.h. es werden
Timestamps mit abgespeichert (spätestens hier wird der CPLD nicht mehr
reichen, der Timestamp braucht mind. 24Bit + 8 bit Daten =>32Bit SRAM)
- Die Adressierung entweder per LSB nibble (lt. FPGA-User reicht ja
einfaches herausführen der Adresse nicht), oder mittels 2 Odd/Even
Adresszähler oder Adresszähler mit 2 Latches (was braucht weniger?).
- OE_ ist immer auf Low, da ich kein Tristate hier brauche. Ich muss
mir aber das Datenblatt noch genauer ansehen, ob das alles so rechtens
ist.
- via i2c/4MHz wird mit dem Master kommuniziert, jeder POD hat seinen
eigenen i2c zum Master! Der Master sollte entsprechend schnell sein.
- Clock vom Master für Slaves. Evtl. kommen hier Probleme bei höheren
clock Raten => Treiber oder/und Diff.mode. Immerhin kann der Master so
verschiedene Slaves verschieden takten.
- JTAG frisst auch 4 I/O! Irgendwie müssen die Teile ja auch
programmiert und debuggt werden.
- 8 Eingänge, für mehr reicht es nicht. Der Eingang der Komperatoren
(und die Typen natürlich) sind noch nicht konkret. Viele hauen einfach
einen Pullup mit 100k in den Input...
- Trigger: Solange der Trigger bei einem Byte channel bleibt kann man
ja per Kombinatorik und/oder FSM die Triggerbedingungen finden, wenn
diese aber auf einem anderen liegen, so dachte ich mir mangels
Leitungen, muss eine Art Interupt Trigger Leitung - controlled by
Master - herhalten. Er weiss ja, wer wen triggern muss.
- Wegen Synchronität und Sparsamkeit/Geit ;-) wird der uC extern vom
Master mit getaktet.
- Parallel Interface Master - uC
- uC bekommt Daten von Master, Master vom Slave (ohne Interleave).
- Die treshhold level für die Komperatoren kommen per i2c und DAC (8bit
sollten reichen, keine Rechnung aber bisher dazu). Evtl. kann man das
genauer regeln, als einen 1%/0.5% Wdstd. o.ö. benutzen zu müssen. Ist
aber i.A. kein Problem (=>geregelte Stromquelle).

Wie gesagt, es wird alles sehr eng und geht über die ursprüngliche Idee
(1x CPLD etc) hinaus. Aber ein 8bit-uC System würde ich schon gern
analysieren wollen. Mit diesem SRAM wären das für Timing Analyse ca.
8MHz ... Na ja, für den ersten Schuss ...

Eine Frage: JTAG kann man ja in der Chain betreiben, hat jemand
Erfahrung? Ich möchte nur ungern 3 JTAG pin header und einen für
avr/isp einbuddeln. Apropos, den JTAG habe ich beim Master vergessen
einzuzeichnen.

Vieel Grüße
Olaf

von ope (Gast)


Angehängte Dateien:

Lesenswert?

jetzt hat das boad mein Bild vergessen....

@Hans:
Durch die globale Triggerleitung sollte ein Word Trigger möglich sein.
Evtl. gibt es Timing Probleme, da aber alles Synchron läuft und man
auch die Vorgeschichte mitschneidet, sollte es gehen. Belehrt ;-) oder
bist Du jetzt wieder 'dran  ??

Viele Grüße
Olaf

von ope (Gast)


Lesenswert?

kurzer Überschlag für den Slave:
- 2x17 Macrocellen für Odd/Even Adresszähler, ich denke ein Latch
benötigt auch so viele.
- 10 MC für i2c
- 8 MC Input Latch

verbleiben 20 MC für Trigger, Config Register u.a. Liege ich richtig?

Viele Grüße
Olaf

von Hans (Gast)


Lesenswert?

ich meinte trigger bei denen sich die bedingung über mehrere module
hinwegzieht...

sprich an 2 modulen liegt die adresse und an 1nem der status.. jetzt
will ich über adresse und statusleitungen eine triggerbedingung
setzen...

hätte aber dafür schon eine lösung:

du schreibst in alle module eine triggerbedinung und wenn die erfüllt
ist stetzt du einen pin (trig-out) die trig-out pins legst du dann auf
deinen master der sie per und verknüpft (könnte auch ein hc(t) sein
oder so..) auf jeden fall geht der ausgang von diesem und wieder zurück
auf alle module über den pin trig-in.. wenn trig-in fangen alle an..

weitere idee... alle capturen immer.. nur der adress-counter wird per
trigger eingeschalten...

an adresse 0-sagenwir mal 15 liegen nicht im ram sondern sind
eigentlich im cpld als fifo... den counter lässt man auf adresse 16
losstarten und fertig...

vor trigger: daten wandern in den fifo...
bei trigger counter lässt die daten in den ram wandern..

0-15 sind praktisch vor trigger und der rest nach trigger..

damit sollte man den delay der triggerschaltung eleminieren können...

am we werd ich mich mal in die möglichkeiten eines cplds einlesen...
weil mir scheint ein fifo und dann herumcodieren ist doch etwas
aufwendig...

btw kann man nichst den jtag als spi port misbrauchsen wie bei den
avrs??? das würde dir doch ein paar pins sparen.. nur mit debug ist
dann nix...

73

von Benedikt (Gast)


Lesenswert?

Ich würde auch zu einer ähnlichen Lösung wie ope tendieren, aber mit ein
paar Änderungen:

Wieso 70ns RAM, wenn man problemlos 15ns RAMs bekommt ?
Damit sind ohne Interleaving bereits 66MHz möglich, was eigentlich für
die meisten Sachen reichen sollte. Bei 66MHz kommt man auch noch mit
"normalen" ICs aus (also AHCMOS und Co.)

Wiso I2C ? Das ist
a) langsam
b) schwierig auf einem CPLD zu realisieren.
SPI ist schneller, sehr einfach und weniger störanfällig (man muss
keine Adressen vergeben usw.)

Ich würde das ganze so relisieren:
Ein CPLD dient als dummer (Interleaved) Adresszähler für die SRAMs.
Dieser hat als Eingänge nur Enable, Takt, Reset und liefert eventuell
ein fertig Signal wenn der Speicher voll ist.

Ein weiterer CPLD wird mit den Eingängen und den Datenleitungen des/der
SRAM(s) verbunden. Die Daten werden per SPI oder parallel oder sonst wie
aus den SRAMs gelesen und an den uC gesendet.
Zusätzlich macht der CPLD die komplette Triggerung.

Da die Daten und Adressen von getrennten CPLDs verarbeitet werden, und
auch so mechanisch getrennt sind, hat man schonmal weniger Störungen.
Die XC95xx CPLDs erzeugen extrem steile Flanken und die Eingänge sind
scheiß empfindlich, die reagieren auf jeden Spike. Beim Bau meines
Logik Analysers hat sich die Schaltung jedesmal aufgehängt, sobald ich
mit der Tastkopfspitze ein der Adressleitungen berührt habe.

Von mir aus könnte es auch ein FPGA werden, aber kein Eva Board.
Die sind weder kompakt, noch optimal für sowas angepasst.
Ob man bei denen so ohne weiteres >100MHz bei 32bit über die Pinleisten
schieben kann ?

Für einen 100MHz 32bit LA wäre ich bereit bis etwa 100€ auszugeben.

von Hans (Gast)


Lesenswert?

dann teil den trigger noch auf wie ich das gedacht hab... (trig-in
trig-out) dann sparst du dir den zusatz cpld..

weil die cplds einzeln abfragen und konfigurieren kann ein uc auch..
und für die trigger generierung reicht ein "normales" nor.. und die
wirds doch schnell genug geben ;)

also ein 4fach nor+n*cpld +uc macht ein n*8bit logic analyzer...

sehe ich das richtig???

73

von ope (Gast)


Angehängte Dateien:

Lesenswert?

Noch eine Variante, die mit 2 PCLD auskommt, jedoch auf 16Bit beschränkt
bleibt. Dafür bleiben einige I/O übrig, falls bei konkreter Betrachtung
wieder einige I/O fehlen.

Der eine CPLD macht einen "Memory Hub"/Master und kommuniziert mit
dem uC. Der zweite macht allen möglichen Triggerkram und gibt ihn mit
Full Speed an den Master. Meine 70ns gab's wie gesagt sehr günstig bei
ebay - schnellere sind selbstverständlich willkommen (in Gedanken
verbaue ich die Teile schon :-).

i2c ist evtl. bei diesem Aufbau overkill, da ja die Adressaten bekannt
sind. SPI wäre also angebrachter.

Viele Grüße
Olaf

von ope (Gast)


Lesenswert?

Ich vergaß: bei diesem ist allerdings kein Interleave mehr möglich (PIN
Mangel)!

von Thomas O. (Gast)


Lesenswert?

Hallo,

bei Meilhaus gibts ein ANT 8 bzw 16 das kleine schafft 500 MHz! und das
große noch 100 MHz, womit haben die den das verwirklicht weil das Teil
ja super kompakt ist. Man kann dem Datenblatt nicht soviel entnehmen
zwecks Speicher usw. Low/High wird bei denen bei 0,5V unterschieden,
was warscheinlich auch hilfreich sein wird bei der hohen Samplingrate.
http://www.meilhaus.de/pdf/ant8u16.pdf

von ope (Gast)


Lesenswert?

500MHz über alle Kanäle oder multiplex? Da waren doch sicher wieder
diese Marketing Leute am Werk ... Genau genommen sind da für alle
Kanäle 32k Speicher drauf. Wir wollen aber höher hinaus :)

Olaf

von ope (Gast)


Lesenswert?

Hier http://www.nci-usa.com/default.htm was evtl. machbar wäre wenn
nicht .... Nun ja, die Videos und Doks sind sehr interessant.

Gefällt mir persöhnlich sehr gut, aber am Preis müssen wir noch etwas
arbeiten :)

Olaf

von Marcel (Gast)


Lesenswert?

noch ne kurze  Bem. zum SRAM BS62LV1024,

70ns Write Cycle Time (also 14,2 MHz) sind nur drin,
wenn man im CPLD mit 100 MHz arbeitet, damit man ein
10 ns Zeitraster hat. Die Adress-Setup-Time ist 70 ns,
/WE muss beim Adresswechsel '1' sein (und somit bei
jedem Schreibbefehl getoggelt werden) und mind. 50 ns
breit sein.

Nachdenklich stimmt mich die Setup-Zeit von 30ns bei den
Daten bezügl. steigender Flanke /WE.
d.h. wenn sich die Daten innerhalb dieser 30 ns ändern
ist nicht garantiert, ob 0 oder 1 gespeichert wird.
D.h. ein Datenbus bei dem sich alle 8 bit gleichzeitig
ändern sieht auf dem Bildschirm dann ganz anders aus.

Wenn man die Daten im CPLD/FPGA eintaktet verringert sich
diese Unsicherheit auf ca. 3ns, je nach Device!

von Dirk (Gast)


Lesenswert?

Hi,


>500MHz über alle Kanäle oder multiplex? Da waren doch sicher wieder
>diese Marketing Leute am Werk ... Genau genommen sind da für alle
>Kanäle 32k Speicher drauf. Wir wollen aber höher hinaus :)

>Olaf

Marketing pur. 500Mhz ueber solche Abgreifklemmen..... Naja man kann
viel schreiben, ob es nun stimmt.

Mfg
Dirk

von Jens (Gast)


Lesenswert?

Was wäre denn realistisch bei solchen Abgreifklemmen? Ähnliche habe ich
auch schon bei Geräten, die preislich bei mehreren 10k€ liegen,
gesehen.

von ope (Gast)


Lesenswert?

@Marcel:
>Wenn man die Daten im CPLD/FPGA eintaktet verringert sich
>diese Unsicherheit auf ca. 3ns, je nach Device!

Kannst Du das genauer erklären?

Das Timing hatte ich mir wie gesagt noch nicht angeschaut, da erstmal
prinzipielle Dinge zu lösen sind. Genau genommen ist der/die 17Bit
(256kx8) Adresszähler ja noch nicht alles. Es wird noch ein
"SRAM-Hold-State-Timer"-Counter (10ns Raster hast Du konkret ja
gesagt, 3bit -> 80ns) und noch mind. 2 Compare Register nebst logik
benötigt um meinen/den SRAM allg. ansteuern zu können. (Immerhin ist
man dann mit der Bestückung rel. flexibel). Na ja, die Zahl der freien
Macrozellen sinkt allerings stetig.

Evtl. muss man ja zu einem XC95108 PQ100 oder PQ160 mit 81 bzw. 108 I/O
greifen
http://www.xilinx.com/xlnx/xil_prodcat_product.jsp?title=xc9500_page,
bei Farnell scheint bei 9572 Schluss zu sein, bei R&S wird's teuer:
XC95108-10PQ100C für 38,75 und XC95108-7PQ160C  für 91,45 - damit fällt
diese Lösung flach. Himmel, was rechtfertigt diesen Preis-Sprung?, Pfui,
pfui, bäh :-/ Ist also auch kein (CPLD) Weg. Wie gesagt, ich scheue mich
>100 Euro für einen ungewissen Ausgang vom Haushaltsgeld abzuzweigen.

So langsam gehen mir die Ideen aus, oder man muss halt mit einer
kleinen CPLD Lösung leben für den ersten Wurf, kleiner als bereits
heruntergebrochen wurde...

@Thomas O.:
Wenn ich mal ganz heroisch vom bisherigen Entwurf rede:
-> 2048 Mbit Deep Memory            (2x 128k x8 [mit schnellen SRAM])
-> 800 MS/s                         (50MHz x 16 Bit-Channel)

Cool, damit kannst Du dann mit HP und Agilent (und wie sie alle heissen
mögen) tapfer mithalten :)

Thema CPLD und AVR:
Hat jemand konkrete Erfahrung mit dieser Kombo? 8bit Daten, eine Clock
Leitung, über Timerinterupt gesteuertes Auslesen? Der auszulesende CPLD
dürfte wohl intern ein 8bit-FIFO/Stack haben.

Evtl. sollte man den Thread hier nach "Programmierbare Logik"
verschieben, da er nun doch stark danach lastig geworden ist.

Viele Grüße
Olaf

von ope (Gast)


Lesenswert?

Kleine CPLD Lösung heisst, 10ns SRAM oder/und Adress/Datenbus für 2 SRAM
buffern, damit wieder ein I/O frei werden - wobei speziell beim
letzteren das PCB entsscheidend mit ist.

von JME (Gast)


Lesenswert?

Hallo Ope,

Schau mal nach

http://www.darisus.de/Elektonikshop/Framesets/Shopset1.php

unter Programmierbare Logik. Der Link ging mal vor einiger
Zeit durchs Progr. Logik-Forum, habe aber noch keine
Erfahrungen mit dem Laden.

Ansonsten bin ich im Moment auch eher ein Anhaenger der PLD-
Loesung. Fuer die Kommunikation mit den PLD's wuerde ich auch
SPI oder falls die Gates/Pin's es hergeben ein paralleles
Interface vorschlagen. Im folgenden gehe ich mal von einer
Loesung mit 1 PLD pro 8-Bit Daten aus. Da koennte jeder dieser
PLD's den Trigger ueber seine eigenen Eingaenge erzeugen und
zusaetzlich noch einen Eingang vom vorhergehenden PLD mit
auswerten. Da koennte man dann (je nach Laufzeit der Signale
zwischen den PLD's) eine Art Kette bilden, an deren Ende dann
das eigentliche Signal ueber alle Kanaele rauskommt.

Jens

von Marcel (Gast)


Lesenswert?

@ope
Erklärung Setup-Zeit:
Die Daten werden ja mit dem Takt des Analyzers eingelesen,
bin mal nicht davon ausgegangen, dass ein ext. Takt
verwendet wird, sondern das man höher als mit dem
Systemtakt des DeviceUnderTest abtastet.

Beim genannten SRAM erfolgt das Schreiben offenbar mit
der steigenden /WE-Flanke, 30ns vorher MÜSSEN die Daten
stabil sein, sonst ist nicht sicher, was man einschreibt.

Im CPLD/FPGA sind die Setup-Zeiten der Daten bezogen auf
die Clock-Flanke wesentlich geringer, hängt vom Typ ab,
also es kann reichen, wenn die Daten 3ns vor der Clockflanke
stabil sind, dann wird mit Sicherheit das richtige eingelesen.
Sollten sich die Datenleitungen gerade in diesen 3 ns ändern,
hat man natürlich dasselbe Problem, aber bezogen auf z.B. 100ns
sind hier die Unsicherheiten kleiner.

von Benedikt (Gast)


Lesenswert?

Was spricht gegen die schnellere 3,3V Version ?
Den XC95144XL-5TQ144C gibts bei Digikey für 16,85$

Der XC95108-7PQ100C kostet auch 36.70$, die 5V Version ist eben langsam
ein Auslaufmodel mit geringeren Stückzahlen und deshalb vermutlich
teurer.

von Markus (Gast)


Lesenswert?

@ope:
Preise bei Reichelt:
XC 95144-15TQ100  22,30 Euro
XC 95144XL TQ100 (10ns), 11,20 Euro

Wobei die XL-Varianten mit 3,3V laufen, aber 5V-kompatible I/O haben.

Markus

von ope (Gast)


Lesenswert?

@Marcel:
Jetzt habe ich geschnallt, was Du meintest - den RAM ins PLD verlegen
(wenn den genügend vorhanden wäre) wegen des Timings. Gegen die 30ms
hilft nur ein Latch, braucht dieses auch Macrozellen entsprechend der
Bitbreite?

@JME:
coole Preise! Danke!
XC95144XL10TQG14  144Macro, 117 I/O, 10ns, TQFP144 für 9,396. Jetzt
wird es mit dem CPLD wieder attraktiv. Mich irritieren nur die 1/10
Cent, was solls :) Anscheinend wollen die (xilinx/r&s) den Absatz
forcieren.
Den entsprechenden RAM gibt's dort auch, zB:
SM614016VHSA10T SRAM HS as 3,3V 256Kx16 10ns TSO für 3,271, allerdings

sieht es mit den Datenblatt mau aus ...
50 MHz Oszillatoren gibt's auch ...
Das Porto dort ist auch fair - über Lieferzeit schreiben sie erstmal
nichts (oder kann ich schlecht sehen?).

Ob das mit den 16bit klappt (2x 8-Bit-Channel) muss man erstmal auf dem
Papier durchprobieren (2-fach Interleave Variante).

@Benedikt:
Yep, da habe ich mich wohl zu früh in's Boxhorn jagen lassen, zumal
ich selbst ja schon die 3.3V Variante vorgeschlagen hatte, aber
meistens waren 3.3V Technologie teuer als 5V (wo ich geschaut hatte).


Viele Grüße
Olaf

von ope (Gast)


Lesenswert?

Das Teil (XC95144XL10TQG14 ) ist cool, kurze Rechnung:

2x SRAM 256k x 16:
  18 AD, 16 DB, 3 Ctrl = 2x 37 I/O = 74 I/O

2x 8-bit-Channel:
  16 I/O

uC parallel Port:
  8 DB, Ctrl (CS_ und R/W_) = 10 I/O

2x Clock (CPLD und uC externer Takt)
  2 I/O

JTAG
  4 I/O

Summe: 106 von 117 I/O

Da kann man fast versuchen, 2 CPLD zu synchronisieren, zumindest
entsprechend andenken für 32 Channel. Der Rest mit dem uC und DA
bleibt, der CPLD und die Komplexität war ja das Problem.

M.E. ein preiswertes und tragfähiges Konzept bis jetzt. Jetzt muss man
nur prüfen, inwiefern das alles da rein passt, also Anzahl der Macro
Zellen abschätzen ...

BTW, aufgrund der 2x 256k x 16 Bit eröffnet sich ja die Möglichkeit,
den Transitional Timing analysis mode zu realisieren, auch wenn die
16Bit den möglichen Adressbereich nicht ganz abdecken und der
Interleave mode zwangsläufig nicht mehr geht (kurz: Nur Änderungen
werden mit Timestamp gespeichert - ideal für langsame Busse). Oder
diesen nur für 8Bit möglich machen (24 Bit Adresse für Timestamp und 8
byte Bit-Pattern); na oder eben 18bit Adresse (256k) und 14Bit
Bit-Pattern. Aber erstmal kleine Brötchen .... :-)

Viele Grüße
Olaf

von Dirk (Gast)


Lesenswert?

Hi,

fuer die Eingangsbeschaltung sollte man schnelle Komperatoren nehmen
diese koennte man den per PWM (DAC) einstellen.

Mfg
Dirk

von Hans (Gast)


Lesenswert?

ich nerv na nur ungern.. aber wie zum teufel willst du diesen 8 bit port
ohne adressen vernünftig verwenden???

oder schickst du einmal command byte und einmal daten-byte???

mach doch gleich spi und spar dir die pins..

oder mach ein paar adress leitungen.. 2 würden ja schon reichen...

trigger-byte
config (start, trigger mode,reset adress couner,..)
daten (nach jedem read adress counter inkrementieren)
für die zukunft ;)

oder so... dann kann man das teil schöner ans ext-mem interface des
zukünfigen controllers hängen..

wie gesagt alternativ spi..

73

von ope (Gast)


Lesenswert?

Thema Clock Generation:
ADF4360-8 mit 3-wire serial interface ist evtl. etwas zu hoch gegriffen
(65-400 MHz) und gibt's weder bei R&S noch Farnell.
Die Teile von Maxim
http://para.maxim-ic.com/compare.asp?Fam=clockgenerators werden dort
auch nicht verkauft. Was ist denn so handels üblich dort? Bei Reichelt
traue ich mich erst gar nicht nach zuschauen (zu speziell).

Thema DA:
Mh, PWM. 8Bit PWM auf die Ports knallen und OPV mit TP dahinter imo. Ob
ein einfaches RC ausreicht ist mir einfach zu "billig"??? Immerhin
sind das bei 5V 20mV Auflösung und der Trigger Level sollte stabil
sein. In Trampert/"AVR-RISC Mikrokontroller" ist ein Konzept, das mir
zumindest gefällt: Butterworth TP 2.Ordnung mit Mehrfachgegenkopplung.
Aufgrund des inversen Charakters des TP wird per PWM eine negative
Referenzspannung am inv. Eingang draufgeknallt. Er macht mit einem
TL084 und 74HC4053 einen 3Channel 10bit DAC ...
Evtl. nicht doch einen  AD5337 (8-BIT DAC 2WIRE I/F DUAL) für 2,53 bei
Farnell? Da weiß man was man hat :) Die gibt's auch als 10/12 bit
pinkompatibel (je nach Wunsch) und nehmen kaum mehr Platz ein als ein
RC.

Thema Comperatoren:
Jemand eine gute Idee? Ein Übersprechen im 4fach-OPV sollte hier kaum
relevant sein, ist ja keine Analogtechnik :) Die Teile müssen auch eine
kleine Hysterese haben/bekommen, ansonsten schwingt's

Thema Trigger Level Spannung an den Komperator bringen:
ich wollte 1% Widerstande jedem Eingang verpassen, mit (yep) 16-fach
Stromspiegel in diesem Fall. Alle Komp.eingänge zusammen an Uref
ranknippern würde ich aber auch nicht wollen. Na, evtl. fällt uns da ja
noch was gescheiteres ein :)

Thema Stromversorgung:
XC95144XL pauschal 150mA worst-case (lt. DB), Speicher?, AVR xyz ??
Ich denke 500mA sind ausreichend, lasse mich aber gerne eines besseren
belehren.
=> LM2574M-3.3 (Switching) für 1,83 solange Vorrat reicht (Farnell),
mmhh
=> LM2575S-3.3 (Switching) für 2,47 (Farnell), der sieht gut und
einfach in der Handhabung aus http://www.national.com/ds/LM/LM1575.pdf

Wie gesagt: preiswert und verfügbar. Ich übersehe aber nicht, inwiefern
SPS hier stören kann - evtl. linear Regler bei den Strömen oder entfernt
unterbringen.

Thema uC:
Alle für AVR heben die Hand :^)

Thema Schnittstelle PC:
Bitte noch nicht!

farnell ist nicht Pflicht, ist nur bequem :)

Viele Grüße
Olaf

von ope (Gast)


Lesenswert?

@Hans:
Nun ja, mit PLD <-> uC ist noch nicht ganz ausgegoren bei mir. Aber es
sind ja noch ein paar I/O frei - welch ein Glück. Die Frage ist ja
eher, paralleles oder serielles Auslesen.
Was wäre die maximale Rate, was der AVR (seriell) zum PC schaffen
würde? Da gibt's dann einen Hinweis. Bei seriell muss er ja 10bit (?
SPI) einlesen, ggf. behandeln (komprimieren), und zum PC durchprügeln.
Wenn er dann 10 Takte warten muss sinkt die Datenrate intern unnötig
ab, da er diese hätte besser verwenden können (oder war SPI transparent
mit eigenen Shift-Register und Interrupt? - hab noch nie damit
gearbeitet - endlich mal passend zum Forum Topic :)

Die Idee, den PLD als ext. memory zu verwalten klingt interessant. In
den AVR AN habe ich allerdings nichts dazu gefunden.

Viele Grüße
Olaf

von Hans (Gast)


Lesenswert?

ext.memory siehe z.b mega128 datenblatt ;)

zum pc über sie serielle wenns denn sein muss 1Mbaud bei 0% error
@16Mhz takt ;) lt mega128 datasheet... das soll der pc mal schlucken
;)

und den spi würd ich sowieso dann nur pollen..

sprich datenbyte anfordern und das vorhergehende zum versand fertig
machen und weg damit... dann vielleicht waren bis das byte da ist und
gleich das nächste holn...

spi-takt lt datenblatt kann bis zu fosc/2 sein => 8Mhz spi takt.. macht
1MB/sec ;) das sollte doch eigentlich reichen oder ;)


achja ich hab mal im wiki gefuhrwerkt... eine logic analyzer projekt
kategorie in die projekte kategorie.. dann noch einen software artikel
und alles noch zusammengelinkt...

auf der software-seite sollte man auch mal brainstormen... weil
zumindest ein konzept sollte da schon dahinter sein... obwohl software
design ala "klingonische softwareentwickler" hätte auch  mal was g

73

von Dirk (Gast)


Lesenswert?

Nabend,

>spi-takt lt datenblatt kann bis zu fosc/2 sein => 8Mhz spi takt..
>macht
>1MB/sec ;) das sollte doch eigentlich reichen oder ;)

Bei dieser Aussage muss ich leider wiedersprechen. Im SPI Master Mode
ist es moeglich fosc/2 , aber im Spi Slave Mode nur fosc/4. Datenblatt
Seite 168

Gruß,

Dirk

von Dirk (Gast)


Lesenswert?

Ups,

mist editfunktion der AVR laeuft im SPI Master Modus. Hatte es etwas
falsch verstanden.

von Rufus T. Firefly (Gast)


Lesenswert?

@Hans:

   "zum pc über sie serielle wenns denn sein muss 1Mbaud bei
   0% error @16Mhz takt ;) lt mega128 datasheet...
   das soll der pc mal schlucken ;)"

Das kann der PC nicht schlucken, da dessen serielle Schnittstellen
nicht mehr als 115200 Baud unterstützt.

Nur spezielle Schnittstellenkarte oder USB-Seriell-Konverter erlauben
höhere Baudraten.

von Hans (Gast)


Lesenswert?

naja rufus das hängt wieder vom im motherboard-chipset verbauten uart
ab...

ich hab mal geizhals gefragt und das gefunden ;)

Q-Tec 102P 2 Port Serial PCI Card
2 port serial interface card PCI
Fast 16550 serial port
Plug and Play in Windows.
Data transfer up to 921Kb/sec
Drivers for all Windows OS
NetMos nm9835CV chipset

was die chips on-board teile so können ist fraglich.. auf jeden fall
haben die das problem, dass sie normal nur 16byte fifo haben (so wie
der nm9835 lt datenblatt)... und da wirds eng..

aber müsste man ausprobieren... 115k sollten noch gehn.. über 230k
dürfts schon probleme geben unter win...

73

von ope (Gast)


Lesenswert?

na, da werde ich mal das Mega128 DB wälzen dürfen.

Irgend jemand schrieb hier (man findet nichts wieder), das er keine
Probleme hat, wenn er wegen der Datenmenge etwas auf dem Rechner warten
muss - ich widerspreche dem kategorisch! Jede Unterbrechung des
Gedankenflusses ist tötlich. Man will ja schnell eine Hypothese
überprüfen, wenn man/ich abgelenkt bin (auch durch warten - die
Gedanken streifen weiter) habe ich vergessen, was ich wollte. Bitte,
sagt jetzt nicht, ich habe Alzheimer, das wäre nicht fair ;-)

Ich denke, die Parallel und die SPI Variante verbrauchen die gleiche
Anzahl an Macro Zellen.

1 Mbaud = 125kByte/s, d.h. der komplette Speicher (256k x 16 =
512kByte) wäre in 4s im PC Speicher (worst-case). In der Zeit ist meine
Kaffee Tasse runter gefallen und ich habe die nächste wieder aufgefüllt,
effektiv kommt 20% Protokoll Overhead hinzu ... Was macht USB2.0
nochmal? Hinzu kommt die Zeit, die das Programm benötigt u.U. (je nach
Klingonen Stil :)

BTW, hat jemand ein Datenblatt für SM614016VHSA10T, ansonsten muss bei
farnell nach einer Alternative gesucht werden.

Mit SPI Interface hat man natürlich den Vorteil der Kaskadierung bzw.
verschiedener links, dh. 32,64...Kanäle etc. easy expanded. Dann ist
die Schnittstelle uC <-> PC wirklich der Engpass (=>100BaseT, na später
mal :). Apropos, passt das UART auch noch in den CPLD?, Xilinx hat eine
Reference App dazu (noch nicht angesehen), dann USB20 Anbindung an den
CPLD? Weiter gesponnen: der DAC Data kommt vom i2c des CPLD und der uC
wäre überflüssig. Dies setzt genug Macrocells vorraus!

Jemand eine Idee für die sinnvolle Verwendung der ggf. verbleibenden
I/O?

Thema Software:
Modell-View-Controller (Gamma et all) Pattern unbedingt! Nur so bekommt
man bei verschieden Ansichten der Daten diese auch konsistent
dargestellt. Aber dies ist imo noch zu früh zum diskutieren.

Any comments zu (s.o.)
- Clock
- DA
- Comperator
- Vcc
??

So, gute Nacht!
Olaf

von ope (Gast)


Lesenswert?

Ich war doch neugierig auf's wiki
http://www.mikrocontroller.net/articles/Logic_Analyzer_Software.

Allen ernstes SQLite?

C++ im Prinzip:

class Data {
  std::vector<uint32_t> la_data; // platz für 32bit LA version
  void notify();
}

class View {
public:
  void attach(...);
  void detach();
  const std::vector<uint8_t>& pod(uint8_t n);
};

Yep, Observer Pattern. Gott, ist mein C++ lange her.

Viele Grüße
Olaf

von Rufus T. Firefly (Gast)


Lesenswert?

@Hans:
Du zitierst eine PCI-Karte, und das ist keine Onboard-Schnittstelle.
Mit einer solchen Karte ist natürlich alles mögliche drin, aber wenn
man so etwas verwendet, dann ist der Vorzug der Portabilität durch
Verwendung einer Standardschnittstelle nicht mehr erkennbar.

Die Onboard-Schnittstelle von PCs ist mit einem 8250 bzw. dessen
Nachfolger 16550 aufgebaut, dessen Baudratengenerator mit 1.8432 MHz
Takt betrieben wird. Dieser wird durch 16 geteilt und kann dann mit
einem Baudratenteilerregister durch ganzzahlige Werte weiter geteilt
werden.
Der Wert 1 im Teilerregister ergibt 1.8432 / 16 = 115200 Baud.

von Hans (Gast)


Lesenswert?

hmmmm wie gesagt es gäbe da bei opencores usb implementierungen ;)

um ethernet nutzen zu können müsste man einen arm und uclinux laufen
haben.. derzeit zu teuer weil man einfach zuviel sram für die lpc22xx
brauchst... und einen arm7 der billig ist, mit dram kann und nicht ich
weis nicht was an perepherie braucht hab ich noch nicht gesehen...

alternativ könnte ich mir aber so einen lustigen usb/rs232 chip
vorstellen.. siehe wiki da hab ich eine nette type die gut beschaffbar
sein dürfte gepostet..

natürlich könnte auch irgend ein verrückter die pci-bridge von
opencores testen G

firewire gäbe es dann ja auch noch... aber ich glaube usb wirds
werden...

irgendwann am anfang hatte ich eh schon mal bemerkt, dass rs232
warscheinlich eh nur zum capturen von seriellen verbindungen geeignet
sein wird...

natürlich müsste man abchecken ob man nicht doch mit einem uc und
kompression die datenübertragung wieder in einen vernünftigen bereich
bringen könnte...

wie gesagt... es bräuchte mal testdaten ;)

ich werde mich morgen nachmittag mal hinsetzen und daten von einem
mega32 generieren lassen (rein in ein stk500, quick&dirty code.. und
dann die rs232 angucken)... aber ich kann mir gut vorstellen, dass sich
so ein durchschnitts-stream gut komprimieren lassen wird...

andere möglichkeit: der controller macht eine Transitional Timing
analysis ;) das wäre damit einfach zu implementieren...und sollte
eigentlich auch eine schöne reduktion mit sich bringen...

so gute nacht.. ich muss mal drüber schlafen g

73

von Hans (Gast)


Lesenswert?

ich darf nicht soo lange tippen.. da posten so viele leute in der
zwischenzeit ;)

@ope

warum nicht sqlite??
mein 1. hintergedanke :
----------------------------------
Beginning with version 2.6.3, SQLite should be able to read and write
database files regardless of byte order of the machine on which the
file was created.
----------------------------------

xml stell ich mir nicht allzu geeignet vor.... und am pc sind mir ein
paar kb an overhead wurscht... hauptsache ich als programmier hab kein
problem mehr mit portieren usw ;)

aber ich lass ja mit mir reden ;) ich hab den artikel ja gemacht damit
man solche "kleinigkeiten" diskutieren kann ;)

@rufus
schon klar... aber wenn ich um 15e mir 30e an cpld,.. sparen kann..
warum nicht..

wobei usb ehrlich gesagt um einiges interessanter wäre...

73 & n8

von Thomas O. (Gast)


Lesenswert?

Hallo,

wenn man per RS232 übertragt und eine 2te Leitung mit den Takt hat,
spart man sich die Übertragung des Start und Stopbits also ein
Geschwindigkeitsgewinn von 20%. 115200 / 8 = 14400 Bytes pro Sek.
Und parallel hätte man da schon 14,4kB x8 = 1 MB und beides wäre
programmiertechnisch sehr einfach zu bewerkstelligen.

von Steffen (Gast)


Lesenswert?

@ope

einen günstigen schnellen SRAM 256KB x 16 könnte der IC61LV25616 sein.
Den gibt es für 8ns, 10ns, 12ns. Kostet derzeit bei Glyn etwa 2,70 EUR.

von Marcel (Gast)


Lesenswert?

also wenn ich das hier so lese:
2 - 3 CPLDs, Mikrocontroller, dazu noch MAX232 oder FT245
oder noch was andres, Takt-Generator-IC, 1-2 SRAMs,
Stromversorgungs-ICs, dann noch irgendwelche DACs,
Komparatoren, alle ICs selbst auflöten, Massen von Block-Cs
dazu... und das alles für einen LA, der am Ende
8..16 bit mit vielleicht 10 MHz einliest, nee
das is nix für mich.
Sorry, die Zeiten, wo ich IC-Gräber zusammenlöten konnte
sind vorbei.
Ich schau in nem halben Jahr mal wieder rein, mal sehen, ob
dann schon ein Board fertig ist.

von ope (Gast)


Lesenswert?

@Hans:
> ich darf nicht soo lange tippen.. da posten so viele leute in
> der zwischenzeit
:)

Also SQLite nur wegen dem Endian? Da gibt's doch hton* und ntoh*
macros, die kommen aus der Netzwerk Programmierung, da die TCP/IP und
Netzwerkbitorder, Gott - wenn ich mich recht entsinne Big Endian war,
und Intel Little Endian hatte (oder war das umgekehrt?)
http://www.cs.vu.nl/pub/minix/2.0.0/wwwman/man3/hton.3.html

XML ist zum Speichern/Laden toll, man braucht keinen Parser zu
schreiben und die Tagnamen sind frei wählbar. Man muss ja nicht immer
die volle Power nutzen ;-)

Auf dem CPLD wird wohl kein Platz für IP/Opencore sein, daher UART mit
FTDI oder CP2102

@Steffen:
Danke! Die Preisekalkulieren und wo man obendrein möglichst alles
komplett bekommt, wird auch noch mal abendteuerlich.

Viele Grüße
Olaf

von Hans (Gast)


Lesenswert?

ich weis nicht... ich kann mir nicht vorstellen, dass man blobs einfach
in xml packen kann... da muss der parser ja schon verrückt werden wenn
er da aufeinmal 00-bytes findet udgl...

-----------
XML ist zum Speichern/Laden toll, man braucht keinen Parser zu
schreiben und die Tagnamen sind frei wählbar. Man muss ja nicht immer
die volle Power nutzen ;-)
-----------
türlich brauchst einen parser... und wennst den nicht selbst machst
musst dir halt eine lib orgen...

wo jetzt der große unterschied in beiden möglichkeiten ist sehe ich
nicht... bis auf den "vorteil", dass ich mich bei sqlite nicht um die
blobs kümmer muss ;)

in xml könnte man wiederum die daten strukturiert ablegen...

wir sollten diese und weitere diskussionen ins wiki oder in einen neuen
thread legen... sonnst köpfen uns glaub ich die hardware-bastler G


73

von OldBug (Gast)


Lesenswert?

>Evtl. sollte man den Thread hier nach "Programmierbare Logik"
>verschieben, da er nun doch stark danach lastig geworden ist.

Das sehe ich anders: momentan ist es sehr PLL (Programmierbare Logik
Lastig ;), aber das wird sich ändern, sobald mal entschieden wurde, was
verwendet werden soll. Dann kommen nämlich weider mehr die
Elektronikaspekte zum Vorschein: Eingangsbeschaltung,
Spannungsversorgung, Leiterplattendesign etc...

von Jens (Gast)


Lesenswert?

Ich hätte gerne Bluetooth, um die LA-Daten drahtlos an den PC zu senden.
Nee, ernsthaft jetzt. Man verliert langsam den Überblick, habt ihr euch
jetzt mal auf was geeinigt? Ich denke, die erste Version wird eh nicht
perfekt, ganz im Gegenteil!

von Hans (Gast)


Lesenswert?

eben..

man bastle mal eine proof-of-concept 8-bit capture engine..

aber bitte so, dass man sie möglichst schnell takten kann...

dann noch einen x-beliebigen uc dran (vorzugsweise wie mega16,32,...
kleiner hab ich sie nicht daheim ;) und dann schaun wir mal wo probleme
entstehen..

das sollte doch billig lösbar sein... und zum input-stage testen
reichts alle mal...

73

von Dirk (Gast)


Lesenswert?

Hi,

vielleicht solltet ihr ein USB AVR nehmen (48Mhz). Der interne USB
schafft 12Mbit.

Gruß,

Dirk

von ope (Gast)


Lesenswert?

@OldBug

Yep, das stimmt, evtl. sollten 3 Threads geöffnet werden in:
- µC & Elektronik
- Programmierbare Logik
- PC-Programmierung

Der Überblick wird dadurch allerdings nicht besser. Evtl. wäre ein
neues Forum Projekte besser geeignet. Immerhin scheint ja hier auch der
Digitaler Funktionsgenerator entstanden zu sein - wie lief es da ab?

Thema SQL:
Wegen eines BLOBs? D&D: "An SQL BLOB is a built-in type that stores a
Binary Large Object as a column value in a row of a database table. ",
also nur wegen der Binary Repräsentation? Für Messungen mußte ich mal
mehrere Tausend Datensätze in eine SQL schicken - ist schon cool, mit
dem select ... aber hier Overkill imo.

Thema Parser/XML:
Ein Parser ist so'n Teil das auf Grammatik und Semantik achtet, also
das yacc & lex Gespann und Abkömmlinge. Die Interpretation ist wieder
Anwender Sache. Schau mal auf http://libxmlplusplus.sourceforge.net/,
wie einfach es gehen kann. Die Möglichkeiten gehen aber über das hier
benötigte weit hinaus (serialization, object creation etc). Aber
unabhängig davon, halte ich die Repräsentation des "Speicherdumps"
des LA als Vector als am einfachsten - vieles wird sich erst bei
genauer Betrachtung ergeben. Es muss erstmal ein stabiler Software
Prototype her, dann kommt des Redesign - und so entwickelt sich
Software, u.a. auch Windows - sind wir nicht alle Beta Tester? :)

"in xml könnte man wiederum die daten strukturiert ablegen"
Trennung von Daten und deren Repräsentation - sonst gibt's schnell ein
heilloses Durcheinander!

Thema CPLD:
Tja, mit dem CPLD wäre also (hardwaremäßig) halbwegs geklärt. Die
andere Hälfte betrifft dessen Innerein, also: wer hat den Kern schon
mal geschrieben und bestätigt: er passt rein?

Ein wühlen brachte http://home.comcast.net/%7Emike_treseler/uart.vhd zu
Tage, passt er rein und kann man daran ein CP/FTDI 'ran stöpseln? BTW,
macht FTDI nur USB1.1?

@Marcel:
TTL Gräber sind out, ist schon richtig, aber ein Großteil ging hier ja
gerade darum, den Aufwand gering zu halten; daher ein CPLD. Der Dac
hat 8 Beine - entgegen der PWM Lösung, wo mit viel Aufwand eine GS
gemacht werden muss. Was spricht gegen
1 CPLD,
2 SRAM
1 uC,
1 DAC,
1 Spg.regler ggf.,
1 Port-IC (USB kann den LA mit versorgen),
4 Quad-Comperatoren oder 2x 74AHC245 oder 3x 74ACT14,
1 Quarzoszillator
um bei den aktiven zu bleiben??

Imo hat man mit wenigen BE das Maximum erreicht (PCB ist eine andere
Sache). Würdest Du sagen, SMD ist scheisse zu löten, muss ich Dir
allerdings recht geben :-)

Man kann aber auch nicht erwarten, das innerhalb einer Woche sofort ein
tragfähiges Konzept entstehen kann, zumal wir hier nicht an einem
gemeinsamen Tisch physisch sitzen und noch andere Verpflichtungen
haben!

Also, wieder Forengerecht - Input:
Das Thema wurde in
http://www.progforum.com/showthread.php?t=4619&page=1&pp=15&highlight=logik
schon mal etwas durchgekaut - allerdings mit Logik IC. Evtl. sollte dazu
ein neuer Thread aufgemacht werden, um das Thema stärker konzentrieren
zu können. Netter Weise hat man bei
http://www.xilinx.com/bvdocs/appnotes/xapp368.pdf die konkrete
Eingangsbeschaltung vergessen.
Was evtl. problematisch ist, ist 3.3V für einen Komperator, da
wahrscheinlich dessen Slew Rate ins Bodenlose sinkt - sofern überhaupt
einer das mitmacht. Wer hat einen guten Draht zu Datenbüchern?

Viele Grüße
Olaf

von Jens (Gast)


Lesenswert?

Maxim hat sehr gute Komparatoren, schaut mal auf deren Homepage.

von ope (Gast)


Lesenswert?

@Dirk:
mit dem USB AVR (48Mhz) klingt gut, zumal damit wieder ein Chip
entfällt. Woher nehmen und wie teuer ist der? Gängig scheint ja die
ATmega Reihe zu sein.

BTW, der Trend scheint ja nun eindeutig in Richtung USB zu gehen,
aufgrund der Gegebenheiten.

Olaf

von Hans (Gast)


Lesenswert?

ich sehe beim usb-avr das problem.. wie macht man ein hid device ;) ich
kenn mich mit usb noch nüsse aus... in 2 wochen bin ich wieder weg von
der firma.. dann max. 1ne woche daheim.. dann 3wochen spanien.. also
muss die soft recht schnell stehn...

die idee hinter sql war, dass alle daten in einer file sind und
einfachst rausgeholt werden können..gut xml würds auch noch geben
..aber wie gesagt ich mach die software sowieso komplett modular über
plugins => die daten kommen von irgendwoher in ein schönes array ;)
dann noch einen member wie viele byte pro sample und fertig..

der ftdi macht usb1.1 .. der cp2102 macht full speed usb2 und gäbe es
bei farnell.. im gegensatz zum ftdi... oder war rs... hab ich weiter
oben gepostet..

der kann übrigends bis 1mbaud, einige 100byte an buffer und hat on-chip
3,3V spannungs-reg der 100mA liefern kann...

damit spart man sich wieder was...aja ab ich schon erwähnt, dass der
chip einen 48Mhz oszillator schon drauf hat?? ;)

das gehäuse sieht seltsam aus..aber bis auf gnd seh ich kein porblem
beim löten.. ich muss mir den mal bestellen... hier im forum gabs aber
einen thread wo dem teil nur gute eigenschaften bescheinigt wurden....

von ope (Gast)


Lesenswert?

Thema Comparator:
Wie wäre es mit einem Max964
http://pdfserv.maxim-ic.com/en/ds/MAX961-MAX999.pdf
- 4.5 Typ Prop. Delay (ns)
- Supply 2.7 to 5.5 Voltage (V)
- 8000 Max Supply Current per Comp. (µA) - also 8mA/C = 32mA/IC
worst-case
- VEE-0.10 to VCC+0.10 Input Voltage Range (V)
- 5.5$ Price @ 1k

allerdings nicht bei Farnell zu finden.

Layout Hinweise/Bsp gibt es. Eingänge sind gegenüber den Ausgängen,
diese alle auf einer Seite, damit wird das Layout auch einfacher.
Interessant ist der Shut Down Mode um den Strombedarf zu senken (wieder
ein Pin vom uC weg). Sorgen bereitet mir allerdings der Input Voltage
Range, da muss eine schnelle und begrenzende Eingangsbeschaltung her.
Gefallen tut mir auch der Preis nicht, da 2Stck für 8Bit benötigt
werden, also in der 16 Bit Variante 4 Stck ca. 20Euro. Die 128mA fallen
da gar nicht so groß auf :-) benötigen aber ein gutes Layout (ground
bounce).

BTW, Ob dieser Speed mit einem 10ns CPLD wirklich gefahren werden kann,
ist noch offen.


Viele Grüße
Olaf

von Jens (Gast)


Lesenswert?

Zum Thema HID-Device: nehmt einen PIC18F4550, HID-Firmware gibts gratis
von Microchip. Nutze die Firmware auch bei meinem 10 Kanal Datenlogger.

von Hans (Gast)


Lesenswert?

ich hab mal bei atmel reingeschaut.. auf der hp steht was von
registrieren dann bekommt man die software.. angeblich sogar ein wizard
der einem eine schöne firmware ausspuckt...


nur dürfte der gleich gut zu bekommen sein wie dein pic.... ;)

73

von ope (Gast)


Lesenswert?

@Hans:
wenn ich mir die Package des CPLD mit 0.5mm ansehe, schrecke ich vor
dem cp2102 auch nicht mehr zurück - zumal weniger Teile, schneller und
billiger. Mit dem Gnd hab' ich auch gelesen; seltsam, sein Masse unter
dem chip zu legen. Ich denke, es soll die EMV Konformität erzwingen
wegen der 48MHz (gerschirmtes Gehäuse).

Bietet Atmel nicht eigene Treiber für ihren USB Stuff an, wie es auch
FTDI und SILABS machen? HID ist ja Host/PC Seite.

Um ehrlich zu sein, wir können froh sein, wenn in diesem Monat ein
geroutetes Layout entstanden ist ;-) Yep, Ihr lest richtig :)
Kannst also ruhig nach Spanien fahren - im September bin ich für 3
Wochen weg.

Viele Grüße
Olaf

von Hans (Gast)


Lesenswert?

gut .. also pünktlich zum unibegin haben wir dann eine funktionierende
hardware/software lösung ;)

btw ich bin grad am überlegen ob ich der software nicht auch schon
grundlegenden support für die nutzung als digi-scope mitgeben soll..
wäre nur etwas geschicktere klassenstruktur nötig und schon müsste das
hinhaun....wär doch was.. einen freerunning adc drann.. dann den
trigger dazu.. und schon hätte man ein einfaches scope ;)

aja den pic bekommt man um 8e bei farnell....
der atmel kostet 6$ bei digikey..

und das teil kann lt. homepage 10mbit spi.. das klingt seeeeeehr gut
;)
und ganz nebenbei ein tqfp44 ;)

0,5mm pin abstand geht schon.. tqfp44 ist dagegen zwar was für
notorische grobmotoriker aber mit ein bisserl guten willen und halbwegs
vernünftigem flussmittel....


73

von Thomas O. (Gast)


Lesenswert?

Hallo,

ich finde man sollte sich erstmal auf einen Speicherbaustein festlegen,
der schnell genug ist oder von dem man notfalls 2 parallel nimmt und sie
abwechselnd beschreibt.

Was gibt es da z.b bei Reichelt was man verwenden könnte. bzw welche
Anforderungne gibt an die Speichertiefe? Evtl. in den LA-Artikel mit
einfügen. http://www.mikrocontroller.net/articles/Logic_Analyzer

von ope (Gast)


Lesenswert?

@Steffen/Speicherinterface:
Auf
http://www.icsi.com.tw/english/products/products-frame.asp?Title=Datasheet-Async%20SRAM&URL=http%3A//web.icsi.com.tw/English/Datasheets/ASYNCHRONOUSSTATICRAM.html
bzw.
http://web.icsi.com.tw/domino/packinfo.nsf/F384F466ECEF4C1F48256F320003B3E6/$FILE/ic61LV25616.pdf
ist er zu finden.

256K X 16 IC61LV25616 3.3V 8,10,12,15 [K, KG, T, TG, B]  MP

Was allerdings als Status Available MP bedeutet, verschließt sich mir.
Der Preis ist natürlich top.

Alternative Farnell: AS7C34098-12TCN (256K X 16; Zeit, Zugriff:12ns;)
für 13,17€ wäre das nahe liegenste, oder eben
AS7C31026B-12TCN (64k x 16, 12ns) für 4,99€.

Viele Grüße
Olaf

von ape (Gast)


Lesenswert?

> der ftdi macht usb1.1 .. der cp2102 macht full speed usb2 und gäbe es
> bei farnell.. im gegensatz zum ftdi... oder war rs... hab ich weiter
> oben gepostet..

Macht das einen Unterschied? Beides 12mBit.

und der cp2102 dürfte wesentlich schwerer zu löten sein, da nich nur
das GND unten drunter is sondern auch alle restlichen Pins... Sollte
aber auch nicht unmöglich sein, nur eben wesentlich schwerer als
normnales 0,5mm TQFP.
Die FTDI Chips gibs übrigens u.a. bei Segor.

von Jens (Gast)


Lesenswert?

Hab meinen CP2102 unten nicht verlötet, geht! Aber ist natürlich nicht
das gelbe vom Ei :)

von ope (Gast)


Lesenswert?

@Thomas O./Speicherinterface:
Reichelt habe ich am Anfang schon erodiert - gibt nichts vernünftiges
dort, leider.

Aktuell ist ein 16Bit SRAM. 16Bit, da der ausgesuchte CPLD
XC95144XL10TQG14 genug I/O hat um 2x 8bit-Channel zu sampeln. Er hat
sogar soviel I/O, dass man den Speicher im Interleave (odd/even
Adressen) betreiben kann. Mit den 16Bit in einem Chip sinkt auch die
Fehlerwahrscheinlichkeit, zB. da nur noch einer, anstelle von 2x 8Bit
ICs, verlötet werden muss. Letzlich ist es die Frage nach dem Timing
und Bittiefe eine Geld- und Anforderungsfrage. M.E. kann dieses noch in
letzter Sekunde entschieden werden, zB. werden dann weniger
Adressleitungen benutzt bzw. die maximale Samplerate wird stark von der
Zugriffszeit dominiert. Spätestens beim PCB Entwurf muss es aber
feststehen, klaro.

BTW, weiss eigentlich jemand was POD im Zusammenhang mit dem LA
bedeutet? Probe on Device?

Irgend welche Hinweise Inputstage?

Viele Grüße
Olaf

von Benedikt (Gast)


Lesenswert?

Was spricht eigentlich gegen synchrone SRAMs ?
Die sind doch für sowas optimal, oder ?
Die Adressen werden bei der Flanke gespeichert, ebenso die Daten.
Die Setup und Hold Zeiten gehen daher gegen Null...
Außerdem muss man WR\ nicht toggeln, was wertvolle Zeit kostet,
sondern es reicht den Sampletakt anzulegen.

von ope (Gast)


Lesenswert?

@Benedikt:
hast Du einen konkreten Vorschlag, bei Farnell kann ich nach
synchron/asynchron nicht direkt suchen und ich bin zu faul derzeit alle
Datenblätter durchzuwühlen - ich habe nicht mal einen Drucker hier :(
Deshalb auch keine genaueren Analysen/Datenblattstudien bisher. Wenn
ein Konzept steht, kann man es ja anhand der DB prüfen.

An sich klingt es toll, da es das Speicherinterface vereinfachen
würde.

@ALLE:
Ich habe meinen Schreibfluss mal auf's Wiki gerichtet. Dies
vereinfacht Quer- und Wiedereinsteigern hoffentlich die Diskussion, es
fehlt aber noch einiges.

Viele Grüße
Olaf

von Benedikt (Gast)


Lesenswert?

Ich dachte so an CY7C1325F oder CY7C1327F (256k*18).
Kosten <=10€, und gibt es bis 4ns = 250MHz

Was genau der Unterschied zwischen Piplined und Flow Trough ist, weiß
ich auch nicht, habe bisher noch nicht so wirklich viel damit gemacht.

von Thomas O. (Gast)


Lesenswert?

Hallo,

ich werd jetzt mal schauen was aufzubauen und würde was für zahlen wenn
mir jemand ein leichtgestriktes FPGA bzw. CLPD programmieren kann.
Meine Anforderunge sind ja nicht ganz so hoch wenn ich mal die Datem im
SRAM habe kann ich das auch mit nem AVR auslesen. Ich möchte dem FPGA
bzw. CLPD einen 2 externen Signale zuführen einmal den Sampletakt(evtl.
über VCO) und einmal das Triggersignal und dann soll er einfach die
Schreibbefehle für das SRAM senden, die Daten lege ich mit Latches oder
sonst irgendwelchen Treibern direkt auf die Dateneingänge des SRAMs.

Wo bekommt man eigentlich diese schnellen Vieher her?

von ope (Gast)


Lesenswert?

@Benedikt:
Klingt super, allerdings

Farnel: CY7C132-55PC wird nicht mehr hergestellt - Nicht mehr
lieferbar, Produkt abgekündigt 12,30 €

R&S: CY7C1327B-133AC TQFP100256Kx18 3,3 11,60 €

klingt gut, die 18Bit können wir auch verbraten, genug I/O haben wir ja
noch. Allerdings gibts zu der B Variante bei R&S kein Datenblatt - nur G
und F
(http://www.cypress.com/portal/server.pt?space=CommunityPage&control=SetCommunity&CommunityID=209&PageID=259&fid=39&rpn=CY7C1327F
bzw
http://www.cypress.com/portal/server.pt?space=CommunityPage&control=SetCommunity&CommunityID=209&PageID=259&fid=39&rpn=CY7C1327G)

Wer kennt sich aus?


Viele Grüße
Olaf


Viele Grüße
Olaf

von ope (Gast)


Lesenswert?

Wieso bekomme ich bei der Signatur im Wiki meine IP Adresse angezeigt -
ist das aus Datenrechtlicher Sicht zulässig? :)

von Steffen (Gast)


Angehängte Dateien:

Lesenswert?

@ope

zum Clock kann ich den ICS502 von ICS empfehlen. Das ist ein PLL Clock
Multiplier mit einer max. Ausgangsfrequenz von 160 MHz. Bei einen Quarz
von 20 MHz kann man 50MHz, 60MHz usw. erzeugen. Kostet etwa 0,90 EUR und
gibt es bei Memec Insight.
Einfach mal anschauen.

von Thomas O. (Gast)


Lesenswert?

Hallo,

oder ICS525 gibts auch bei Reichelt, dieser hat nen VCO eingebaut den
man über 9 Bit einstellen kann und dahinter ist noch ein 3bit Teiler
womit man dann nochmal die Frequenz von 1-8 Teilen kann.
http://www.icst.com/icscs/SiteSearch.aspx?q=ics525
http://www.icst.com/datasheets/ics5250102.pdf

von ope (Gast)


Lesenswert?

@Steffen
Leider habe ich den ICS502 auf
http://www.memec.com/?cmd=search&search=ICS502+&x=30&y=9 nicht
gefunden. Vom Datenblatt
http://www.mikrocontroller.net/attachment.php/207130/ics502.pdf her
sieht er gut aus, wenig Beine, Jitter +/-70ps und kommt bis 120/140MHz
- die wollen erstmal erreicht werden.

@Thomas O.
Dieser hat wiederum viele Beinchen
http://www.icst.com/datasheets/ics5250102.pdf, kann bis 100MHz (525-01)
bzw. 200MHz (525-02) bei 3.3V bei einem Jitter von +/- 85ps, allerdings
bei Reichelt 5,90€ (die haben dort keine Beschreibung - wissen die
nicht, was sie haben?)

Beim Anschauen der DB ist mir allerdings ein Henne-Ei Problem
aufgefallen. Mit dem PLL Clock Multiplier kann ich den Clock für den
AVR und LA generieren, der AVR soll aber mit einer festen Frequenz
unabhängig vom Mastertakt arbeiten, d.h. setze ich den Master Clock
hoch/runter, läuft auch der AVR schneller/langsamer. Den ICS502 und
ics525 kann ich per DIP konfigurieren, aber wie sage ich den CPLD/uC,
was eingestellt wurde - der ICS502 macht noch vom Tristate Eingang bei
siner Konfiguration Gebrauch? Der ics525 ist da einfacher (low oder
high). BTW, macht der AVR Tristate?

Viele Grüße
Olaf

von Hans (Gast)


Lesenswert?

dem avr einen eigenen quarz geben..dann die frequenz fest... wo ist das
problem ;)

ich mein warum sich unnötig probleme schaffen???

hat nebenbei den vorteil, dass ich an den clock-gen auch irgend einen
quarz-oszillator dranhängen kann mit z.b 40Mhz.. sprich man kann sich
dann die frequenz selbst aussuchen..einfach quarz oder eben einen quarz
oszillator im layout vorsehen und dann steckt rein was du willst...

73

von ope (Gast)


Lesenswert?

stimmt schon, ich fand es nur klever, alles an einem Quarz/Teiler zu
hängen, da es dann auch schön synchron alles ist.

Knippern wieder also wieder einen eigenen Quarz an den uC, sofern uns
nicht noch etwas einfacheres einfällt :-)

Viele Grüße
Olaf

von Steffen (Gast)


Lesenswert?

@ope

bei dem Multiplier wird der Quarzclock per REF durchgreicht. Bei einem
festen Quarz bleibt auch REF.
z.B. Quarz beim ICS502 16MHz = REF = 16MHz und Clock kann 32MHz, 48MHz
und 64MHz sein. Es ist also möglich den AVR mit dem Multiplier zu
versorgen.

von ope (Gast)


Lesenswert?

das Problem mit dem Masterclock/PLL/uC ist weitreichender als ich bisher
annahm:

Gesetz dem Fall, aufgrund verschiedener Gründe, was auch immer, macht
der LA bei einem 100MHz und bei einem anderen 25MHz, bei einem dritten
.... Das Binary im uC ist aber bei allen gleich - ansonsten müßte jeder
seinen Source speziell anpassen (nicht jeder setzt runde Quarze ein -
hier explodieren die Varianten) und compilieren (Bootloader Option wird
schwieriger für generic binaries).

Ein gleiches Binary für alle erleichtert vieles, auch von Seiten der
PC/Software her, da diese nur noch dem uC fragen muss: was kannste und
haste denn? Daher die eingangs erwähnte Idee mit dem hardcoden von PCB
Revision, Channel etc. an einem Port des uC (einfaches Config-Port
einlesen der 256 möglichen Configs reicht dann).

Wegen dem Quarz/Osz. kann man einfach bestimmen: 25MHz - friss oder
stirb. Das Problem mit dem unbekannten Multiplier, zB. per DIP Schalter
einzustellen, bleibt dennoch bestehen. Der ics502 hat 6 mögliche
Multiplier, das wären schon 3 Konfig Bits. Wer weiss, was noch so alles
kommt. Werden diese hard wired, kann wiederum ein Fehler auftreten, wenn
Konfig Bits != Multiplier am DIP des ics502.

Mit dem DIP (oder Lötklecks auf einem Pad) den Multiplier einstellen,
ist imo eine gute Sache, nur wie sag' ich es dem uC? Kann der AVR
einen offenen Eingang/TriState feststellen? Imo nein. Einen weiteren
Chip für solche Tests einsetzen wäre nicht gut. Der Tristate des DIP
ist das Problem bei der Erkennung des Mulitpliers! Dann kann er über
den Mulitplier-Port einlesen bekannt gemacht werden.

Bei dem ICS502 den REF Clock durchschleifen ist 'ne gute Idee. Bei
Verwendung von 25MHz als Standard kann ja der CPLD diesen durch 2
oder 3 teilen (Achtung: asynchrones Übertragen zum Computer notwendig,
Baudraten sind nicht mehr normgerecht - macht des dem USB Chips etwas?
imo nein, da intern asynch FIFO) und an den uC weiter reichen.

PS: Beim PCB sollte man auch worst-case rechnen, d.h. Multiplier = 1,
d.h. Ref-Clk per Lötbrücke/-pad an den CPLD!

Viele Grüße
Olaf

von Hans (Gast)


Lesenswert?

ähm bitte für was soll das config port gut sein????

dem uc kann es vollkommen egal sein wie schnell gesampelt wird.. das
muss nur die software am pc wissen um die zeit richtig anzeigen zu
können

aber im prinzip kann das dem uc vollkommen egal sein !!!!

anderseits kann der avr auch den multiplier einstelln !!!
weil ausgänge auf high-z schalten kann er...

73

von ope (Gast)


Lesenswert?

dem uC ja, aber der Desktop Software nicht, da ggf. ein "falsches
Timing" angezeigt wird, da zB. die SW von 100MHz ausgeht, der LA aber
nur mit 75MHz arbeiten kann bei Lola, 25MHz bei Rudi ....

Die Version u.ä. codieren deshalb, weil es evtl. ja eine neue Variante
irgendwann mal gibt - dann weiss die (weitsichtig programmierte)
Software, was sie bedient und muss nicht (vollkommen) neu geschrieben
werden. Also nur eine Art Serial/Config Number Auswertung.

Letzlich werden nur einige Port Pins auf GND geklebt, intern Pullup
scharf gemacht - also kein bemerkenswerter Aufwand für Weitsicht.

Wie kriegt man die AVR Ports in HighZ? Ich kenne nur low/high/Pullup
intern.

Viele Grüße
Olaf

von Benedikt (Gast)


Lesenswert?

HighZ=Port auf Eingang + Pullup aus

Es gibt doch taustende per I2C oder SPI programmierbaren
Taktgeneratoren, wieso also unbedingt diese parallelen ? Die sind nur
dafür gedacht, um eine Frequenz zu erzeugen (bzw. ein paar wenige, wie
auf einem Mainboard).

Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.