www.mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik Logic Analyzer bauen


Autor: Thomas O. (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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.

Autor: Simon Küppers (Gast)
Datum:

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

Autor: Thomas O. (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht 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.

Autor: Neutron (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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.

Autor: Benedikt (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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.

Autor: Dirk (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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

Autor: R2D2 (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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.

Autor: Dirk (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi,

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

Autor: Jens (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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.

Autor: dave (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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.

Autor: Jens (Gast)
Datum:

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

Autor: Simon Küppers (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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

Autor: Harry (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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 ?!

Autor: Jörn (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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

Autor: Dirk (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi,

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

Gruß,

Dirk

Autor: Dirk (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ups,

sollte natuerlich routen heissen.

Dirk

Autor: Harald (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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

Autor: Thomas O. (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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?

Autor: Thomas O. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

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

Autor: Rolf Magnus (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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.

Autor: R2D2 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Thomas: Counter

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

Autor: Thomas O. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

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

Autor: Jörn (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
@Thomas:

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

Autor: ope (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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

Autor: Benedikt (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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.

Autor: Jörn (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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

Autor: Benedikt (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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ß.

Autor: Harry (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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.

Autor: Benedikt (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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...

Autor: Jörn (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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€.

Autor: Harry (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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 :-)

Autor: Dirk (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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

Autor: Hans (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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

Autor: Jens (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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

Autor: ope (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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/pa...)
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

Autor: Rufus T. Firefly (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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.

Autor: Andreas Schwarz (andreas) (Admin) Benutzerseite Flattr this
Datum:

Bewertung
0 lesenswert
nicht 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.

Autor: ope (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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

Autor: Andreas Schwarz (andreas) (Admin) Benutzerseite Flattr this
Datum:

Bewertung
0 lesenswert
nicht 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.

Autor: Hans (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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

Autor: Andreas Schwarz (andreas) (Admin) Benutzerseite Flattr this
Datum:

Bewertung
0 lesenswert
nicht 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.

Autor: Hans (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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

Autor: Jörn (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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

Autor: Jörn (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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.

Autor: Andreas Schwarz (andreas) (Admin) Benutzerseite Flattr this
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hans: Dein Benchmark ist 5 Jahre alt.

http://shootout.alioth.debian.org/benchmark.php?te...

Autor: PeterF (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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

Autor: Rolf Magnus (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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.

Autor: Hans (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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

Autor: PeterF (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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

Autor: Hans (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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

Autor: Jörn (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Hans:

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

Autor: Thomas O. (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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 |||

Autor: Harry (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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.

Autor: Dirk (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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

Autor: Hans (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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

Autor: ope (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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&high... 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

Autor: Thomas O. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

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

Autor: Thomas O. (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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.

Autor: Dirk (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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

Autor: ape (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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)

Autor: Rufus T. Firefly (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Oh, USB-Parallelwandler gibt es, sogar welche mit erweitertem
Funktionsumfang zum selberbauen:
http://www-user.tu-chemnitz.de/%7Eheha/bastelecke/...

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).

Autor: Dirk (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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.

Autor: Hans (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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

Autor: Thomas O. (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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.

Autor: ope (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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....
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....
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....
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 :)

Autor: Thomas O. (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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?

Autor: Hans (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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

Autor: JME (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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

Autor: Hans (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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)

Autor: Thomas O. (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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.

Autor: Thomas O. (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht 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.

Autor: Benedikt (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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.

Autor: FPGA-User (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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.

Autor: Thomas O. (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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.

Autor: Tim (Gast)
Datum:

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

Autor: Jens (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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.

Autor: Patric (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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.

Autor: Hans (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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

Autor: ope (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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

Autor: Patric (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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.

Autor: FPGA-User (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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 !

Autor: Thomas O. (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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.

Autor: Patric (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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.

Autor: Andreas Schwarz (andreas) (Admin) Benutzerseite Flattr this
Datum:

Bewertung
0 lesenswert
nicht 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.

Autor: Andreas Schwarz (andreas) (Admin) Benutzerseite Flattr this
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Noch was: vergesst "Modularitaet".

Autor: Hans (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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

Autor: Jens (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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.

Autor: Andreas Schwarz (andreas) (Admin) Benutzerseite Flattr this
Datum:

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

Autor: FPGA-User (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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

Autor: Thomas O. (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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

Autor: Jens (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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.

Autor: Andreas Schwarz (andreas) (Admin) Benutzerseite Flattr this
Datum:

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

Autor: FPGA-User (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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 ?

Autor: Jens (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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.

Autor: Jens (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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.

Autor: Hagen (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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

Autor: Andreas Schwarz (andreas) (Admin) Benutzerseite Flattr this
Datum:

Bewertung
0 lesenswert
nicht lesenswert
So habe ich mir das auch gedacht (Moeglichkeit 2).

Autor: Thomas O. (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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.

Autor: Dirk (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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

Autor: ope (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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

Autor: Jörn (Gast)
Datum:
Angehängte Dateien:
  • la.zip (148 KB, 137 Downloads)

Bewertung
0 lesenswert
nicht 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

Autor: FPGA-User (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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.

Autor: FPGA-User (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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.

Autor: Dirk (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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

Autor: Patric (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Dirk

Wenn du noch etwas warten kannst:

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

Leider erst ab Q3/05 verfügbar.

Autor: Dirk (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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

Autor: Konstantin Schmidt (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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 :-)

Autor: Hans (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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

Autor: FPGA-User (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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...

Autor: Dirk (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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

Autor: Hans (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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

Autor: ope (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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

Autor: Benedikt (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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.

Autor: Hans (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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

Autor: Benedikt (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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.

Autor: Hans (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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

Autor: Hans (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
http://eebit.com/

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

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

73

Autor: FPGA-User (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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.

Autor: ope (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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/Pr....
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

Autor: FPGA-User (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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.

Autor: Dirk (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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

Autor: FPGA-User (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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 ?

Autor: Hans (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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

Autor: Hans (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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

Autor: Dirk (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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

Autor: ope (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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

Autor: ope (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht 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

Autor: ope (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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

Autor: Hans (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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

Autor: Benedikt (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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.

Autor: Hans (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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

Autor: ope (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht 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

Autor: ope (Gast)
Datum:

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

Autor: Thomas O. (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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

Autor: ope (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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

Autor: ope (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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

Autor: Marcel (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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!

Autor: Dirk (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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

Autor: Jens (Gast)
Datum:

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

Autor: ope (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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...,
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

Autor: ope (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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.

Autor: JME (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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

Autor: Marcel (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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.

Autor: Benedikt (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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.

Autor: Markus (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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

Autor: ope (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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

Autor: ope (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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

Autor: Dirk (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi,

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

Mfg
Dirk

Autor: Hans (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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

Autor: ope (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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

Autor: ope (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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

Autor: Hans (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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

Autor: Dirk (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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

Autor: Dirk (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ups,

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

Autor: Rufus T. Firefly (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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.

Autor: Hans (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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

Autor: ope (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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

Autor: ope (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich war doch neugierig auf's wiki
http://www.mikrocontroller.net/articles/Logic_Anal....

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

Autor: Rufus T. Firefly (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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.

Autor: Hans (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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

Autor: Hans (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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

Autor: Thomas O. (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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.

Autor: Steffen (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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.

Autor: Marcel (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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.

Autor: ope (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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

Autor: Hans (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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

Autor: OldBug (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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...

Autor: Jens (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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!

Autor: Hans (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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

Autor: Dirk (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi,

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

Gruß,

Dirk

Autor: ope (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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&pag...
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

Autor: Jens (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Maxim hat sehr gute Komparatoren, schaut mal auf deren Homepage.

Autor: ope (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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

Autor: Hans (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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....

Autor: ope (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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

Autor: Jens (Gast)
Datum:

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

Autor: Hans (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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

Autor: ope (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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

Autor: Hans (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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

Autor: Thomas O. (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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

Autor: ope (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Steffen/Speicherinterface:
Auf
http://www.icsi.com.tw/english/products/products-f...
bzw.
http://web.icsi.com.tw/domino/packinfo.nsf/F384F46...
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

Autor: ape (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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.

Autor: Jens (Gast)
Datum:

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

Autor: ope (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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

Autor: Benedikt (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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.

Autor: ope (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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

Autor: Benedikt (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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.

Autor: Thomas O. (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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?

Autor: ope (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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=Comm...
bzw
http://www.cypress.com/portal/server.pt?space=Comm...)

Wer kennt sich aus?


Viele Grüße
Olaf


Viele Grüße
Olaf

Autor: ope (Gast)
Datum:

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

Autor: Steffen (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht 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.

Autor: Thomas O. (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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

Autor: ope (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Steffen
Leider habe ich den ICS502 auf
http://www.memec.com/?cmd=search&search=ICS502+&x=... nicht
gefunden. Vom Datenblatt
http://www.mikrocontroller.net/attachment.php/2071... 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

Autor: Hans (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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

Autor: ope (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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

Autor: Steffen (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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.

Autor: ope (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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

Autor: Hans (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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

Autor: ope (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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

Autor: Benedikt (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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).

Autor: Clemens Helfmeier (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Guten Tag,

es wurde inzwischen die Generierung des Taktes und das verfahren der
Datenablage diskutiert (Wikiartikel). Vielleicht ist es sinnvoll den
CPLD vom Mikrocontroller aus programmierbar zu machen (ja, dann ist ein
externer Takt für den µC nötig). Dadurch könnte man aus Softwareupdates
einfach aufspielen und nicht jeder braucht einen CPLD-Programmierer.
Ein Atmel-ISP würde reichen.

Ich kann leider nichts zur Implementation der Software im µC sagen, da
ich nicht weiss, wie ein CPLD programmiert wird, doch ich denke, dass
sich das mit einer Hochsprache wie C in vertretbarem Aufwand lösen
lässt.

Ich habe nicht den gesamten Thread gelesen (das ist mir zu viel).
Schlagt mich bitte nicht, wenn dieses Thema schon diskutiert wurde.

Schöne Grüße und viel Erfolg (ich will auch einen haben!), Clemens

Autor: Hans (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ope:ich sehe dein problem nicht...

der user wird doch wissen was er da an hardware hat oder???

also sagst du das ist hardware xyz... die controller-soft muss sowieso
irgendwann eingespielt werden => dort die ref-clock hardcoded
rein..oder im eeprom speichern...

pc hardware holt sich einfach vorm capturen die ref-clock bzw die
möglichen sample rates an und der user sagt was er will.. fertig..

und falls sich beir der hardware was grobes ändert wird einfach ein
plugin geändert/neu gemacht und die software kann wieder richtig
umgehn..

ich hab mir das mit den input plugins (die eigentlich sowas wie ein
treiber sind) schon recht genau überlegt und ich bastle gerade am
plugin manager ;)

der data-manager wird wieder was ganz dummes.. der will vom input
plugin eigentlich nur ein byte-array haben und wissen wieviele
bytes/sample und wie hoch die sample rate ist...

die view plugins holen nun diese daten und zeigen sie an,....

sprich ich bastle da etwas möglichst modulares, das eigentlich sogar
von einem parallelport samplen könnte G

73

Autor: ope (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Clemens Helfmeier
Hier bist Du der Diskussion bereits vorraus :-) Ich hing da auch schon
mal - mit JTAG soll so etwas gehen - konkret habe ich aber (noch) keine
Ahnung. Der AVR soll ja auch ein JTAG Interface haben, allerdings sind
damit die gängigen Programmer dann überfordert - bitte korrigiert mich
hier, wenn ich falsch liege.

So wo Du es vorgeschlagen hast, sollte es letzlich auch sein - CPLD und
AVR per USB Firmware Updates. Über genauere Hinweise sind wir dankbar,
bitte mit Quellen/URLs.

Offenbar hat sich dann damit auch das Problem des uC Clocks/Quarz
erledigt: Der ATMega8L kann lt.DB nur bis 8MHz heizen, das würde bei
einem Masterclock von 25MHz einen Teiler von 3 bedeuten und somit
keinen 50/50 Cycle mehr und leichtes Übertakten - oder 4:1 Teiler mit
6.25MHz. Nehmen  wir also einfach einen 8MHz Quarz - einfacher wird's
nimmer.

@Hans:
Problem war: verschiedene Master Clocks bei verschiedenen Usern
aufgrund irgendwelcher Unwägbarkeiten bei gleicher Hardware + Firmware
und Desktop Software.

> der user wird doch wissen was er da an hardware hat oder???

Yep, aber alle haben verschiedene Sample rates letzlich, da der max.
Multiplier runter gesetzt werden musste.

> also sagst du das ist hardware xyz... die controller-soft muss
> sowieso irgendwann eingespielt werden => dort die ref-clock
> hardcoded rein..oder im eeprom speichern...

Im Prinzip ja, aber alle haben dann verschiedene Sample rates ->
verschiedene Firmware (auch wenn sie sich wohl nur in ein byte
unterscheidet).

> pc hardware holt sich einfach vorm capturen die ref-clock bzw die
> möglichen sample rates an und der user sagt was er will.. fertig..

Korrekt, so soll es sein.

Evtl. löst sich das Problem von ganz alleine. Wie Benedikt schon
vorschlug -> SPI/TWI. Das Problem entstand ja dadurch, dass ich
nachträglich dem uC sagen muss, was ich von Standard herändern musste,
aufgrund des Multiplier Coding Schemas des ICS502.

Man kann den Spies auch umdrehen: Dreh-Codierschalter (KDR10 bei
Reichelt  für 1,95) am Port des uC auslesen - per SPI gibt er dem
ClockChip den Multiply-Faktor und damit den Master Clock vor (der IC
ist ja dem uC bekannt mit seinen Multipliern). Damit kann bei der
Inbetriebnahme der maximal mögliche Multiplier festgelegt werden,
nicht mehr änderbar durch die Firmware, sprich ein "Anschlag". Dieser
kann durch die SW ausgelesen werden und ggf. verringert werden, aber
mehr als hardwaremäßig begrenzt geht eben nicht. Du darfst nicht
vergessen, der maximale Masterclock ist noch unbekannt (zu viele
unbekannte Faktoren) und wahrscheinlich auch von User zu User
verschieden. Nicht alle haben beim Löten auch ein goldenes Händchen :)

Also, wer kennt einen preiswerten, erhältlichen ClockChip per SPI
programmierbar, geringer Jitter und Temp.abhängigkeit mit Quelle und
Datenblatt?

Viele Grüße
Olaf

Autor: Hans (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ope

> > also sagst du das ist hardware xyz... die controller-soft muss
> > sowieso irgendwann eingespielt werden => dort die ref-clock
> > hardcoded rein..oder im eeprom speichern...

> Im Prinzip ja, aber alle haben dann verschiedene Sample rates ->
> verschiedene Firmware (auch wenn sie sich wohl nur in ein byte
> unterscheidet).

also wenn ich das im eeprom abspeicher .. wo liegt dein problem.. das
byte schiebst du gemütlich über ein kommando zum avr und der schreibs
in den eeprom...
und ganz hab ich das ganze refclock zeugs nicht begriffen...

der capture-cpld hat einen master clock.. den lassen wir vom avr über
den teiler einstellen.. gut und wo zum teufel liegt das
problem??????????

da schieb ich einfach das kommando "set-masterclk blah" zum avr und
der tut das dann ...

bzw ich frage ihn "get multiplicatorlist" und er schiebt mir die
möglichkeiten...

der muss ja nicht wissen wie schnell die clock ist.. und wenn man das
trotzdem am avr haben will sagst halt "set refclk blah" und der
schreibt das in seinen eeprom...

ähnlich beim flashen... irgendwo auf der platine ist ein jumper..den
setzt man .. schaltet ein und schiebt die firmware rüber.. jumper weg
und neu starten fertig..

irgendwas begreif ich glaub ich ned richtig ;)

@cpld firmware...
im arthernut-thread wurde das mal aufgegriffen und sofort wegen extrem
aufwengigen code wieder fallen gelassen...

73

Autor: Dirk (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi,

>ähnlich beim flashen... irgendwo auf der platine ist ein jumper..den
>setzt man .. schaltet ein und schiebt die firmware rüber.. jumper weg
>und neu starten fertig..

Jumper ist unnoetige Geldverschwendnung. Nach einsschalten wartet der
AVR auf ein Kommandozeichen nach der Auswertung des Zeichens geht er in
Bootloader Mode. Anonsten wird im Hauptprogramm weiter gemacht.

Mfg
Dirk

Autor: ope (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Hans
Yep, Du hast recht - irgendwie hatte ich eine lange Leitung - der max
Multiplier kann ja im EEPROM abgespeichert werden und wird per Firmware
Update i.A. nicht überschrieben. Mein PROM wäre der Dreh-Codierschalter
gewesen ... und wieder ein Teil (Drehschalter) weniger.

Nur im Konfigbereich des EEPROM darf keiner (auch keine irregelaufene
Firmware) wild rumschreiben. Was ich so über verloren Device ID (habe
Thread verloren) und veränderte Fuses gelesen habe, verschafft mir
allerdings nicht viel Vertrauen in diese Lösung.

Thema cpld firmware:
Schade, gibt's Alternativen? Ein CPLD Xilinx/JTAG Stecker ist nicht so
toll.

Thema Clocking:
Definieren wir mal:

Quarz Oszillator wird festgelegt auf 25MHz. Nennen wir ihn mal
MasterOszillator
  |
 \|/
  °
Clock Multiplier, Type ????, uC gibt Multiplier per SPI vor, es wird
der MasterClock bis zu ~100 MHz erzeugt.
  |
 \|/
  °
Damit wird der CPLD getaktet.
Der generiert die einzelnen Clocks für
- Adresszähler (noch namelos)
- uC,  oder auch nicht bei Quarz (MCUClock)
- CPLD Input-Port Sampling (SampleClock)

Viele Grüße
Olaf

Autor: Steffen (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ope

für den Clock ist der IDT5V9885 zwar etwas übern Ziel, aber man kann
den mit I2C programmieren. Kostet etwa $8,00 USD.
Der ICD2053B schaut auch nicht schlecht aus und man kann den mit SPI
programmieren. Einen Preis habe ich dafür leider nicht.

Autor: Stephan (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

für die Programmierung eines CPLD benötigt man ziemlich viel Speicher;
ein FPGA dagegen wird normalerweise über ein EEPROM nach dem Reset
programmiert. Das FPGA benötigt ungleich weniger Speicher für die
Konfiguration.

Stephan.

Autor: Harry (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
die ganze Clock-Problematik wäre gelöst, wenn man ein
FPGA verwenden würde. Auch wenn für CPLD und AVR Clocks
von einem Clock-IC kommen, heisst das noch lange nicht,
dass sie synchron sind.

Auch das laden der Firmware wäre beim FPGA kein Problem,
niemand bräuchte eine spezielle Programmer-Hardware, ein
Firmware-File im Programmverzeichnis der Software - das wärs.

Wann seht ihrs endlich ein, dass die Multi-IC-Multi-Layer-
Multi-Bastelstunden-Version einfach zu aufwändig ist und
zuviel Spielraum für Diskussionen lässt ?

Autor: FPGA-User (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Stephan

seit wann brauche ich zur Konfiguration einiger, simpler
Macrozellen im CPLD mehr Speicher als zum füllen der zig-tausend
Look-Up-Tables und der vielen MBits RAM im FPGA?

Also ich kenne FPGAs, die brauchen mehrere MBits an Config-Daten,
und auch das Laden wird oft mit einem Controller gemacht,
nicht nur mit Config-Proms !

Autor: Hans (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ope

wenn man den avr so behandelt wie man es sollte vergisst er nix und das
mit config neu rüberspieln ist alleinschon wegen versions und damit
struktur-änderung der im eeprom abgelegten daten sinnvoll..

btw mein plugin handler scheint zu funktionieren und sollte komplett
portabel sein dank wxWidgets ;)

falls es sich ausgeht werd ich morgen meine linux box anwerfen und dort
mal compilieren...

wenn sich das so weiterentwickelt hab ich den datamanager nächste woche
fertig und am nächsten we kommt dann mal eine einfache view dazu...

also auch auf der software seite tut sich schon was...

73

Autor: ope (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Hans: Wow! :)

Autor: Clemens Helfmeier (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo nochmal,

hier ist der Link zu Xlinix' Embedded Programming von
CPLDs/FPGAs/PROMs:

http://direct.xilinx.com/bvdocs/appnotes/xapp058.pdf

im folgenden Thread wurde darüber einiges diskutiert:

http://www.mikrocontroller.net/forum/read-1-138024...

Ich muss dazusagen, dass ich nicht alles gelesen habe, doch wenn man
(fast) unbegrenzt (Speicher-) Resourcen zur Verfügung hätte, dürfte es
laufen (meiner Einschätzung nach).

Einen schönen Abend, Clemens

Autor: Clemens Helfmeier (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Habe grad nochmal nachgeguggt:

für den 95144XL ist die benötigte XSVF-Datei etwa 80kByte groß. Also
entweder direkt vom USB in den CPLD oder externer speicher mit
memory-map.

Autor: Hans (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
oder aber der avr holt sich die daten vom usb und schickt sie weiter ;)

man muss aber mal wissen wie man die daten reinschieben muss...

73

Autor: ope (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Kurz zusammengefasst steht in der Introduction der XApp, das man über
JTAG den Xilinx per uC programmieren kann. Auf
ftp://ftp.xilinx.com/pub/swhelp/cpld/eisp_pc.zip kann man sich den
Xilinx code zur AN runterladen.

@Clemens: Ist das nicht der Teil, worüber Hans geschrieben hat:
"im ethernut-thread wurde das mal aufgegriffen und sofort wegen
extrem
aufwengigen code wieder fallen gelassen..." ??
Immerhin muss der AVR ja JTAG sprechen können, ein einfaches memcopy
wird wohl nicht ausreichen imo. An sich ist es ja bestechend.

Bei einem schnellen Überfliegen der AN und des sources ich bin ich mir
nicht ganz sicher, ob ich einen kompletten 8 Bit Port am uC frei machen
muss, oder ob die 4 JTAG Leitungen (wie in der AN Fig#1), also
PortNibbel ausreichen würde (src/port.c).

Immerhin scheint's loader binaries für alle gängigen OS zu geben.

Noch mehr On-Board Speicher für den XC zu verbraten wäre
kontraproduktiv.

Unabhängig vom Ausgang - wir haben > 4 I/O am CPLD übrig, so dass wir
uns einen Fall Back per Stiftleiste und Serial Prog. Cable problemlos
leisten können :)

Viele Grüße
Olaf

Autor: ope (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Harry
>die ganze Clock-Problematik wäre gelöst, wenn man ein
>FPGA verwenden würde. Auch wenn für CPLD und AVR Clocks
>von einem Clock-IC kommen, heisst das noch lange nicht,
>dass sie synchron sind.

Muss es denn zwingend synchron sein? TWI bietet imo eine asynchrone
Möglichkeit - alle zeitkritischen Teile sind im CPLD vereint.

Viele Grüße
Olaf

PS: Der Thread wird zum Fulltime Job :)

Autor: ope (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wiki *updated*

Autor: Clemens Helfmeier (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Guten Tag,

soweit ich die Sache mit dem CPLD-Programmieren überblicke, ist das
XSVF-Format nur eine Anweisungsansammlung. Also muss der
Mikrocontroller nur diese Anweisungen befolgen, die dort enthalten
sind.

Da nur 4 Leitungen für den JTAG gebraucht werden, denke ich, man könnte
das auch mit nur 4 von 8 Portleitungen realisieren (nur eine Frage der
Codegröße?).

Dass die Datei ganze 80kByte groß ist, dürfte weniger zum Problem
werden, da man sie ja in "echtzeit" in den µC spielen kann, der
braucht dann nur ein paar Byte Puffer.

Soweit ich die Sourcen überblicke, läuft es etwa so ab:
Für diesen speziellen Anwendungsfall muss die readByte() Funktion in
ports.c angepasst werden, um immer das nächste Byte zu lesen.
Die ports.h verlangt noch einige Funktionen zum Setzen/Löschen und
Lesen der Leitungen.

--------------------------------------------------------------------
Es kann sein, dass ich mit der obigen Annahme total falsch liege. Ich
habe noch keine C-Erfahrung (und schon garnicht mit µCn) und habe
(leider) auch noch keinen CPLD programmiert oder benutzt. Bitte
korrigiert mich, falls nötig!
--------------------------------------------------------------------

Schöne Grüße, Clemens

Autor: Hans (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
unter umständen wird einfach ein programmer-emulator geschrieben und
passt.. aber das muss ich mir noch durch den kopf gehn lassen und mich
genauer einlesen in das ganze...

in der 1. revision wäre es glaubich sinnvoll einfach einen jtag header
für den cpld noch vorzusehen und mit brücken eine verbindung auf ein
avr port zu legen...

jtag ist beim avr über den spi port möglich => da könnts probleme
geben.. also entweder umgehen wir das problem mit einer reihe jumper
mit denen man den avr mit dem jtag connector verbinden kann und den
rest vom spi abtrennt... oder wir nehmen einen größeren avr, der die
datenpins nicht am spi-port sondern woanders hat...

das problem ist übrigens nur beim 1. programmieren existent.. danach
kommen die daten einfach per boot-loader auf den chip...

da gibts also noch einige kleinigkeiten zu bedenken...

73

Autor: ope (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Hans:
> in der 1. revision wäre es glaubich sinnvoll einfach einen jtag
> header für den cpld noch vorzusehen und mit brücken eine
> verbindung auf ein >avr port zu legen...

Sehe ich auch so => Fall Back
So könnte man die sichere und die unbekannte Möglichkeit ausprobieren;
der 5er PinHeader des JTAG wird aber teuerer als ein Jumper :)

@Clemens:
> Da nur 4 Leitungen für den JTAG gebraucht werden, denke ich, man
> könnte das auch mit nur 4 von 8 Portleitungen realisieren (nur
> eine Frage der Codegröße?).

Ich hatte mir wie gesagt den Code von Xilinx noch nicht intensiv
angesehen, aber in ftp://ftp.xilinx.com/pub/swhelp/cpld/eisp_pc.zip
src/ports.c wird eine {in|out}PortUnion benutzt, die anscheinend alle 8
Bits verbrät (Konkret outPortUnion Bit0-Bit3, inPortUnion Bit4 haben
Namen)! Imo im Widerspruch zu JTAG mit einem Nibble (4Bit). Wenn ich
doch bloß einen Drucker hätte :(

BTW: Ich habe gestern einen Thread in
http://www.mikrocontroller.net/forum/read-9-207389.html#new aufgemacht,
Thema Programmierung CPLD über AVR.  Hagen hat dort über das
Speicherinterface philosophiert - das muss ich erstaml verdauen und
Kästchen malen :-) Interessanter Weise hat er die synchronen SRAM
stärker ins Feld geführt!

Viele Grüße
Olaf

Autor: Dirk (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi,

zum Thema DAC wuerde ich gerne einen anderen Vorschlagen. Der LTC1257
(12Bit , SPI Bus) ist bei Reichelt erhaeltlich. Leider ist der Preis
sehr hoch knapp 5 Euro.

Mfg
Dirk

Autor: Hans (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ich wäre stark für einen typen mit interner referenz.... => weniger
bauteile...
wegen ic werd ich nach der arbeit bzw in der pause schaun...

73

Autor: ope (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
was ich bei AD gefunden habe, war ja schon toll, aber entweder kein
Dual-DAC oder keine interne Reference. Imo sind 8-Bit ausreichend, dass
sind 32.25mV Auflösung bei 5V max. Schnelligkeit ist eher untergeordnet.
Immerhin sind die TWI/i2c über 8,10,12 Bit je nach Serie pinkompatibel
und was ich so gesehen habe, auch "Protokoll" kompatibel, da das LSB
mit Nullen entsprechend aufgefüllt wird.

Viele Grüße
Olaf

Autor: ope (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
BTW, der LTC1257 hat 4.75V to 15.75V und passt somit schlecht in das
3.3V Konzept.

Apropos, meist haben die internen Referenzen ja so 1V oder 2.5V - nicht
das wir doch noch 5V und/oder einen OPV mit Verstärkung 2 benutzen
müssen. Ich hoffe, das ich den Thread zum Eingangsteil noch heute
eröffnen kann.

Übrigens, den Thread in "Programmierbare Logik"/"CPLD und AVR Kombo
(Logic Analyzer)" hab ich doch schon erwähnt, oder?

Viele Grüße
Olaf

Autor: ope (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
WiKi updated.
Neues Highlight:  Datenblätter, Bezugsquellen und Preise

Autor: Hans (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ich hab da mal so einen lustigen dac gehabt den man auf der
ref-versorgung nur min 12V geben musste und den ref-out pin auf ref-in
legen musste(lagen nebeneinander ;)... problem : 16bit => teuer und
parallel  anzusteuern ;)

aber sowas sollte es doch auch günstig geben.. der war immerhin für
dds-anwendungen gedacht...

73

Autor: Mark De jong (mark_de_jong)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Alle,

Ich wollte schon immer einen Logic Analyzer bauen.

Wenn ihr einen FPGA benutzen wollt:

Xilinx Spartan XCS40XL-4

Ich habe 40 stück davon auf lager und bin bereit diese zu verfügung zu
stellen, nur die versandt kosten sollten bezahlt werden.

Grüße Mark de Jong,

Autor: Thorsten (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Mark
Welches Gehäuse haben deine Spartans?

Autor: FPGA-User (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
also wenns 'n FPGA wird wäre ich bereit, einen Teil
des Designs in VHDL zu machen, z.B. die Trigger-Logik
oder einen RS232-Core

Autor: Mark de Jong (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Torsten,

Der Spartan ist der XCS40XL-4 PQ208C, also 208 pins mit 0,5 mm
abstand.

Grüße Mark,

Autor: Thorsten (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Würdest du mir zwei Stück verkaufen, unabhängig vom LA-Projekt?

Autor: ope (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Mark de Jong (Mark_de_Jong)
Das wäre super!

Das Gehäuse ist wegen der I/O etwas größer als die CPLD Lösung, aber
wer sich den XC9500 im TQ144 Gewand zutraut, dem dürfe dies auch kein
Problem bereiten, siehe
http://www.xilinx.com/bvdocs/packages/pq208.pdf

Wie Du sicher gelesen hast, war ja der Preis ausschlaggebend für den
CPLD. Dies ist allerdings ein Angebot, das man nicht ablehnen kann.
Zumal es den VHDL Designern des Projektes einfacher gemacht wird, da
sie anscheinend an den geringen Macrozellen ihre Probleme haben.

An den bisherigen Gesamtkonzept würde sich imo ja nichts bzw. nichts
größeren ändern. Man könnte sogar über eine (optionale) 3./4.
Speicherbank nachdenken dank Hagens ausgebufften Speicheralgo.

Wie denken die anderen aktiven Teilnehmer darüber?

Viele Grüße
Olaf

Autor: Mark de Jong (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Thorsten:

Ich kann das nur machen wenn die nicht fürs LA projekt benutzt werden.
Die 40 Stücks sind schon reserviert, bis die entscheidung gefallen
ist.

Grüße Mark,

Autor: ope (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
muss ich mir, um mit den Spartan arbeiten zu können, den "ISE
Classics" neben mein ISE 7.1 installieren bzw. integriert sich das
Teil selber oder ist es besser das ISE WebPACK v. 3.3 - v. 6.1 zu
installieren? Auf
http://www.xilinx.com/webpack/classics/spartan_4k/index.htm steht
weiterhin, das ich bei "ISE Classics" auf 3rd Party Tools angewiesen
bin:

Synthesis can be accomplished by using Synopsys FPGA Compiler-II,
Synplicity Synplify, or Mentor Graphics LeonardoSpectrum™. The Spartan
and XC4000 series device families were never supported by Xilinx
Synthesis Technology.

Viele Grüße
Olaf

Autor: Thorsten (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Mark

Sollten am Ende doch zwei Spartans abfallen, kannst ja mal an mich
denken. Ich will die auch nicht geschenkt haben :)

Autor: Mark De jong (mark_de_jong)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Thorsten,

Kein Problem, aber frage bitte irgendwann mal wieder nach, vergesslich,
du weisst schon.

Grüße Mark,

Autor: ope (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Mark,

nochmals vielen Dank für Dein Angebot. Allerdings sind die FPGA
wirklich nur mit "Spezial" Software zu bearbeiten. Da der LA nun
recht breit getreten ist und auch ein breites Interesse herrscht (trotz
der Diskussionflaute derzeit) und nicht aus jedem Interessierten ein
Schwarzes Schaf werden soll (mal abgesehen von dem unterschiedlichen
"Organisiationstalent"), ist es besser zu verzichten - so reizvoll es
auch ist.

Derzeit wird an der Input Stage gegrübelt, aber auch das CPLD Konzept
ist wegen der erforderlichen Anzahl an Macrozellen (wieder) auf dem
Prüfstand, da anscheinend ein XC95144 nicht ausreicht und wohl ein
XC95288 her muss.

Viele Grüße
Olaf

Autor: Mark De jong (mark_de_jong)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Ope,

Was meinst Du mit "Spezial" software zum programieren?

Ich glaube das der Prozessor doch das programieren machen kann, oder
sehe ich das falsch?

Ich werde selbst ein modulares system aufbauen, ziel ist ein ersatzt
für mein HP 16500A system mit USB/Ethernet anbindung.
- digital 16-kanal LA module(n).
- digital 16-kanal logik generator module(n).
- analog 2-kanal DSO module.
- analog DA 1-kanal module(n)
- steuer module mit USB / Ethernet und grafik (640x400) LCD.

untergebracht in ein 19" module gehause.

Grüße Mark,

Autor: ope (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
mit Spezial Software meine ich Mentor Graphics LeonardoSpectrum
http://www.mentor.com/products/fpga_pld/synthesis/...
zB. oder die anderen FPGA Synthese Tools gegen Geld, worauf man dann
angewiesen ist. Sicher gibt es (schwarze) Wege, aber wenn ich mir schon
den eagle load error thread ansehe ... In einem Jahr kommen dann
Änderungen/Erweiterungen/BugRemovement und dann geht die Jagd ggf. nach
Flexlm licences wieder los etc.

Xilinx scheint für ihre Spartan I alles in fremde Hände gelegt zu
haben. Leider kam zu diesem Theme nicht viel Infos hier, nur kurz im
Parallelthread Prog.Logik. Aber ich hatte auch um chat kurz darüber
diskutiert.

Was meintest Du mit "Ich glaube das der Prozessor doch das
programieren machen kann, oder sehe ich das falsch?" konkret??

Mit dem obigen Projekt hast Du Dir viel vorgenommen. Ich versuche das
in kleineren Häppchen zu verarbeiten, da viele Probleme des
Elektronikers Tot sind. Irgendwann kommt ein fettes FPGA, das das alles
kann. Viele Fragen tauchen aber am Rande auf, die mit dem eigentlichen
LA nichts zu tun haben.

Viele Grüße
Olaf

Autor: ope (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi,

auf der leidigen Suche nach SRAM ist mir die Idee gekommen: Warum
kompliziert, wenn es auch einfach geht! :)

Soll heissen: Das bisherige Konzept sah ja 2x 16Bit breite SRAM Module
vor, welche im Interleave angesprochen werden und am gleichen Adressbus
liegen. Nach DB Studien einiger SRAM, insbesondere Pinbelegung TQ100,
und Angstanfällen vor künftiger Routerorgien - imo sind die Pins
beschissen (sorry) in einem Bus routebar - kam mir die Idee, warum
nicht gleich einen 32 Bit breiten SRAM benutzen. Die Ansteuerung im
Interleave bleibt davon ja im Prinzip unberührt. Es werden zwei 16bit
Samples zu 32bit "gepackt" und geschrieben/gelesen.

Kennt jemand Quelle/Preis/Verfügbarkeit von 128k/256k x 32/36Bit
synchrone (ggf. asynchrone) SRAM?

Tja, das wollte ich mal loswerden und damit auch von dem LA Projekt ein
Lebenzeichen geben ;-)

Viele Grüße
Olaf

Autor: ope (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
zB.

CY7C1327B-133AC TQFP100, 4M, 256Kx18, 3,3V, 4ns, 375mA, 0 bis 70
für sagenhafte 11,60 €

oder

CY7C1360A-150AJC TQFP100, 8M, 256Kx36, 3,3V, 3,5ns, 460mA, 0 bis 70
unglaubliche 21,65 €.

Any comments?

Viele Grüße
Olaf

Autor: János Naumann (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
hallo,

hab grad ein fehlendes datenblatt im wiki ergänzt:

CY7C1327B :
http://www.datasheetarchive.com/semiconductors/dow...

außerdem gefunden:
CY7C1360A-150AJC :
http://www.datasheetarchive.com/semiconductors/dow...

dort findet man sehr viele datenblätter:
http://www.datasheetarchive.com

gruß, jános naumann

Autor: ope (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Als Clock Chip eignet sich der Cy22150 anscheinend recht gut
(http://www.cypress.com/portal/server.pt?space=Comm...)
Ihn gibt es zumindest bei R&S für knapp 5€.

Er ist allerdings als i2c ausgeführt (im DB reden die immer von SPI und
meinen, er hat eine Adresse ... letzlich also doch i2c) und hat 6
Ausgänge, kann von einem Quarz oder ext. Reference getrieben werden.

Allerdings ist es nicht so einfach möglich, durch ihn auch den uC Takt
generieren zu lassen. Zum einen, da zB. 12MHz aufgrund des internen
Aufbaus inkompatibel zu den anderen Möglichen (konkret Samplefreq) ist.
Zum anderen (vorrangig), da im unprogrammierten (i.A. ausgelieferten)
Zustand alle internen Bits zu 0 gesetzt sind und die Clock Ausgänge
highZ haben - damit hat der uC keinen Clock und kann auch nicht per i2c
diesen einstellen. Zum Glück kostet der eine uC Quarz nicht die Welt,
allerdings wird es ggf. asynchron, was wieder durch Register
ausgeglichen werden muss. Man kann den Cy22150 auch programmieren per
JEDEC, aber das Gerät CY3672 dazu kostet ca. $300 (nicht gerade
erschwinglich für den einmaligen Gebrauch).

Daher mein Vorschlag, alle 6 clocks an den CPLD legen und intern per
MUX selectieren, per uC eine Grobauswahl treffen, da die Clocks auch
nur auf jeweilige verschiedene Freq.bereiche zu gebrauchen sind. Damit
kann man sich den CPLD internen Teiler schenken und hat wieder ein paar
MC für die Triggerlogik/SRAM übrig.

BTW, Cypress liefert ein Programm mit, Cyberclocks, da kann man schon
die Einstellungen probieren
(http://www.cypress.com/portal/server.pt?space=Comm...).

Viele Grüße
Olaf

Autor: ope (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ha, mit den 6 Ausgänge auf den CPLD knallen war quatsch. Der CPLD
XC95xxx hat ja drei Clock Eingänge GCL{0,1,2}. Damit stellt sich (die
nicht forengerechte Frage), wie diese dynamisch im CPLD verbunden
werden können....

Autor: Dirk (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi,

ich hab mir heute mal die neue Elektor angeschaut. Es wurden USB
Oszilloskope verglichen.

Recht positiv war das Ergebnis fuer das BitScope. Die Schematic's sind
frei, vielleicht kann man was fuer die Probe's da abschaun.

Gruß,

Dirk

Autor: Dirk (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Link vergessen www.bitscope.com

Autor: ope (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ich habe mir bitscope schon 'mal angesehen vor einiger Zeit, allerdings
bin ich mir über das Teil nicht so ganz schlüssig beim (nochmaligen
schnellen) übersehen, lasse mich aber gerne korrigieren.

Im Schaltbild bs-sch-03.zip/bs300-3.pdf wird ein D-Latch 74HC573 vom
POD (LA-Eingang) mit Samples "geladen". Mir kommt es vom Konzept her
vor, als ob es mehr ein extension Port ist, der hier als LA missbraucht
wird. Irritiert bin ich  zB. an Postion B7, da der Out1 des DAC TLC7524
an den Out des OP-072 geknippert ist u.a. ... Vielleicht soll man es ja
kaufen und nicht nachbauen ...

Viele Grüße
Olaf

Autor: Thomas O. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

habe hier noch ein fertiges Teil gefunden was ist davon zu halten?
http://www.pctestinstruments.com

Autor: Michael Böhmer (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

> habe hier noch ein fertiges Teil gefunden was ist davon zu halten?

wens interessiert, ich hab so ein Teil in Benutzung.
Kurz gesagt: sein Geld wert, definitiv die beste Alternative am Markt,
wenn man für kleines Geld schnell und viel messen will.

Wer fragen dazu hat, kann sich gerne bei mir melden.

Michael

Autor: Mathias (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
hab das gleiche.. ist auf jedenfall sein geld wert

Autor: Thomas O. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
und wo hab ihr das gekauft aus Amiland bestellt? Braucht man eine
Kreditkarte dazu, Vorabüberweisung oder wie hab ihr das gemacht?

Autor: Mathias (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
aus amiland bestellt über firma.. ka wie genau sry

Autor: Andreas (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo alle,

wie schaut es eigentlich mit diesem Projekt aus? Da ich großes
Interesse an so einem Gerät hätte, hoffe ich, daß es nicht nur bei
einem Planspiel bleibt.

Autor: ope (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi,

ja, das Projekt lebt noch und ist auch aktiv. Derzeitiger
Realisierungsstand:

- VHDL Design: notwendig, um einen konkreten CPLD fest zumachen. Auch
wurde in div. AN darauf hingewiesen, durch XST die I/O festzulegen,
damit der Speed optimal verlegt werden kann. Daher hat ein konkretes
PCB Design erst danach Sinn. Fertig ist zumindest ein bit pattern und
edge trigger mit Testbench und kleinere generic Components. An
komplexeren triggern arbeite ich gerade. Es dauert deswegen so lange,
da VHDL für mich total neu ist (entgegen C/C++) und so einige
"sprachliche" Barrieren überwunden werden müssen ;) Es fehlt der
konkrete SPI Slave (eine Umsetzung existiert Dank Jörn, aber noch nicht
eingebunden/verifiziert) zur Anbindung des AVR, Dirk macht einen neuen
Versuch für seine SRAM Ansteuerung :-)
- Das "Literaturstudium" ist soweit eigentlich abgehackt,
gelegentlich kommen kleine Infos halt hinzu, da es eben immer konkreter
wird.
- Die Eingangsstage ist ebenfalls bei Dirk in Arbeit; konkret habe ich
ein PCB in eagle mit MX864 entworfen, welches er aufbauen, testen und
seine Kommentare dazu geben wird - ich habe schlichtweg das
Testequipment nicht (ausser Scope ist nicht's da, dass sind meine
nächsten Projekte...).
- ansonsten wächst auch gedanklich das Konzept weiter,
http://www.mikrocontroller.net/articles/Logic_Anal...
ist nicht mehr ganz 100% aktuell, die updates stehen in diesem Thread.
- über den konkreten Stand der Software von Hans kann ich leider nichts
sagen. Aus diesen und dem Nachbarthread
http://www.mikrocontroller.net/forum/read-1-225498.html#new besteht da
aber auch von anderen Konzepten ein dringender Bedarf. Ich werde mich
da nicht aktiv einbringen, da ich sonst zu viele "Baustellen" habe.

Was fehlt sind sachdienliche, konkrete Hinweise zur Inputstage
Gestaltung, preiswertere Teile/Bezügsmögl., also da, wo eigentlich
wieder viele mitmachen könnten. Teilweise sind die Threads in einen
Monolog verfallen :-(
ZB. gefällt mir der CY22150 nicht so recht, da evtl. Overkill mit
seinen beiden 2 PLL-Bänken - oder gerade recht, da so neben dem Samples
vom LA auch ein PRBS Signal als Pattern Generator mit einer komplett
anderen Taktfreq. generiert werden kann. Dies hängt vom konkreten
Platzbedarf des LA im CPLD ab.

Leider fahre ich Mitte dieser Woche in den Urlaub, so dass es von
meiner Seite erst Ende September weiter gehen kann.

Realistisch geschätzt könnte zur Weinachtzeit der LA stehen - dann
steht aber auch die Frage, gleich einen Satz PCB fertigen zu lassen
oder eben nicht. Hintergrund: 2 seitiges PCB mit (möglichst
ununterbrochenen) Bottom Gnd Layer, welcher aber auch viele
Durchkontaktierungen zum Top Layer Gnd benötigt aufgrund des High Speed
Designs (teilweise hier schon diskutiert). Ein 4-Layer PCB wäre
sinnvoll, aber da kostet dieses wohl schon mehr als 100 Euro. Einen
Entwurf werde ich aber hier zur Diskussion rein stellen, um die
Entscheidung zu erleichtern.

Viele Grüße
Olaf

PS: Es freut mich zu lesen, dass trotz der anfänglichen Euphorie noch
immer Interesse besteht, auch wenn es so lange dauert und einige
ungeduldig sind! ;-)

Autor: Jörn Kaipf (joern)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ope:

Für wieviel Kanäle ist im Moment das LA Design ausgelegt?

Kannst du mir mal deine Emailadresse geben? oder eine kurze Email an
Joern@Joernline.de schicken. Ich hab noch was, das ich dir geben kann.

Gruß Jörn

Autor: Dirk (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

>- Die Eingangsstage ist ebenfalls bei Dirk in Arbeit; konkret habe
> ich ein PCB in eagle mit MX864 entworfen, welches er aufbauen,
> testen und seine Kommentare dazu geben wird - ich habe schlichtweg >
das Testequipment nicht (ausser Scope ist nicht's da, dass sind
> meine nächsten Projekte...).

Ich warte ihmo noch auf die als Sample bestellten Max864. Ich hoffe
diese kommen bald. Die Platine kann ich erst am Freitag aetzen und
hoffe das ich somit in der 36. KW die ersten Ergebnisse liefern kann.


Gruß,

Dirk

Autor: ope (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Für wieviel Kanäle ist im Moment das LA Design ausgelegt?

Derzeit versuche ich soviel wie es geht generic zu machen, aber 16-18
Channel sind geplant. Dieses kommt auch der Umfrage im Wiki am
nächsten. Der erwähnte bit/edge Trigger ist komplett generic.

Hintergrund: Ich versuche eine Transitional Timing Analysis
durchzuführen, d.h. das "Datum" wird mit Zeitstempel und Wert
abgespeichert.
Dies heisst indirekt, dass SRAM mit 36 Bit breiten DB (4 bit werden
normalwerweise für Parität verwendet) eingesetzt werden sollen/müssen.
Damit ist nur ein SRAM auf dem PCB, und es können zB. 18 Bit breite
Samples mit 262k Sample Timestamps gespeichert werden. Somit spielt es
auch keine Rolle mehr, wie schnell sich zB. der Bus ändert sondern nur
noch wie oft - einige Kommerzielle nennen das wohl Datenkompression ;-)
dabei hat das schon einen Namen...

Wesentlich mehr Kanäle wären nur mit einem 2tem SRAM möglich.

Eine Frage steht aber bei den 36Bit SRAM noch aus: kann ich über die
Paritätsbits des SRAM selber frei verfügen oder wird dieses im SRAM
selbst berechnet; oder ist dies wieder SRAM Typ abhängig? Ich habe mich
mit den 11,25 des CY7C1351F-100AC schon angefreundet :)

Viele Grüße
Olaf

Autor: Dirk (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi,

das SRAM Modul ist gestern abend fertig geworden. Ich habe dieses Modul
verifiziert mit der Timing Analyse. Alle Prozesse laufen wirklich
synchron. Eine Anbindung an ein synchrones SRAM waere nun vom Vorteil.
Eine Umwandlung auf Generic sollte weniger das Problem sein.

Ich frage mich nur wozu ich mir die Arbeit dafuer mache. Im Endeffekt
wolltest du (Ope) selbst nochmal die SRAM Anbindung schreiben. Aus
diesem Grund ueberlege ich seit gestern wozu ich die Inputstage bauen
soll und vermessen soll. Die Kosten / Zeitaufwand waeren somit umsonst,
weil anscheinend du das Projekt komplett im Solobetrieb meistern
moechtest. Theoretisch koennte ich mich nun zuruecklegen und auf ein
fertiges VHDL Prg warten.

Gruß,
Dirk

Autor: ope (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Dirk,

dass ich das Projekt nicht als Solo durchführen möchte, sollte aus den
vorhergehenden Beiträgen eigentlich klar hervorgekommen sein.

Mir geht es nur darum, aus zB zwei Entwürfen mit ihren
Aspekten/Erfahrungen, unabhängige Ideen zu sammeln, so dass letzlich
sich beide Entwürfe treffen und es eine bessere Merged-Version gibt. Du
darfst dabei auch nicht vergessen, dass wir beide als VHDL Anfänger
(zumindest ich) Sicherheit benötigen - diese lernt man nicht beim
Durchlesen, erst wenn man es selber schreiben/coden muss. Wenn ich am
SRAM schreibe, bin ich mir sicher, stosse ich auf die gleichen Probleme
wie Du - beim durchlesen Deines Sources werde ich nicht begreifen, warum
Du es genau so gelöst hast. Also, neben dem LA sehe ich auch einen imo
sehr wichtigen Lerneffekt dabei.

Viele Grüße
Olaf

Autor: Andreas (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Olaf, Dirk und alle anderen Aktiven hier,

schön zu lesen, daß es weiter geht. Leider kann ich mich nicht
beteiligen, bin zwar Berufselektroniker, aber das hier übersteigt dann
doch meine Fähigkeiten.
@Olaf: daß Du Urlaub machst, ist doch kein Hinderungsgrund, weiter zu
machen. Laptop mitnehmen! I-Net Anschluß findet sich schon irgendwo.

Nee, war Spaß. Schönen Urlaub,

Andreas

Autor: Dirk (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi,

vom Lerneffekt her hast du recht, aber vom nutzen her muss ich Dir
leider wiedersprechen. Das Projekt dauert somit laenger und feststellen
kann man vielleicht nur das einer effektivieren Vhdl Code schreibt. Mit
effektiver meine ich jetzt nur weniger Makrozellen. Ein richtiges
Gemeinschaftprojekt ist es normal so nicht. Wozu ein
Gemeinschaftprojekt wenn z.B. 20 People irren eigenen LA entwerfen?
Jede Person hat einen anderen Schwerpunkt z.B. Person 1 will 8 Mybte
Speichertiefe , Person 2 will 16 Eingaenge , Person 3 will 100 Mhz
Samplerate und schon kocht jeder seine eigene Suppe.

Gruß,
Dirk

Autor: Jörn Kaipf (joern)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Dirk:

Kannst du deine Code mal posten?

Gruß Jörn

Autor: Jens (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> und schon kocht jeder seine eigene Suppe.

Dann muß man sich halt einigen und dann geziehlt die Aufgaben je nach
Fähigkeiten vergeben.

Autor: ope (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>> und schon kocht jeder seine eigene Suppe.

davon kann eh keiner abgehalten werden, weder von uns beiden noch
andere.

>Dann muß man sich halt einigen und dann geziehlt die Aufgaben je nach
>Fähigkeiten vergeben.

Auf das einigen kommt es an! Bisher gab es auch keine Kollisionen oder
Überschneidungen ... !!

Sicher hat auch jeder andere Projekterfahrungen, bei beruflichen wie
auch privaten Projekten, als Projektleiter oder "Mitmacher".

Möchtest Du alles straff organisieren, kategorisieren, modularisieren,
... wirst sehr schnell feststellen, dass es ein Fulltime Job wird, die
Zeit dürften wir beide/andere nicht haben. Auch beim Festlegen von
Schnittstellen vergeht verdammt viel Zeit, teilweise wird dann doch
festgestellt: es passt dennoch nicht zusammen, da der Gesamtüberblick
fehlte.

Bei den allg. Softwareproj. zumindest sind imo keine an irgendwelchen
Gerangel gescheitert, schlimmstenfalls kam es zur Spaltung, samba e.g.


Konkret hier muss erstmal der Core stehen, um zu sehen, was mit einem
CPLD gemacht werden kann oder ob eben doch (letzlich auch aus
preislichen Gründen, bei  http://www.Darisus.de kostet der
XC2S50-5PQ208 ungefähr genauso viel wie ein XC95288XL) ein FPGA her
muss, der den AVR überflüssig machen würde und andere
Möglichkeiten/Lösungen offenbart/bedingt.

> kann man vielleicht nur das einer effektivieren Vhdl Code schreibt.
> Mit effektiver meine ich jetzt nur weniger Makrozellen. Ein

Optimierungen dauern lange ..., zB habe ich bei meinem Trigger 5 MC
dank einer (komplexen) logischen Verknüpfung mehr als erwartet - das
bleibt erst mal wie es ist und kommt (hoffentlich) später weg. Das ist
zumindest meine Strategie.

> richtiges Gemeinschaftprojekt ist es normal so nicht. Wozu ein
> Gemeinschaftprojekt wenn z.B. 20 People irren eigenen LA entwerfen?

Bisher müssen hauptsächlich wir beide uns nur einigen (evtl. gibt es ja
hier noch einige anonymous Ghostwriter). Evolutionen wird es geben mit
all ihren Konsequenzen.

Bzgl. der LA Lösung bzw. "Typ Bestimmung" (ja, genau da hängen wir
derzeit/noch immer!) bin ich Opportunist, wie es evtl. auch hier im
Forum schon 'rausgeschaut hat; egal ob FPGA und 2 USB Buchsen (nach
einem Hinweis von Jörn auf http://sus.ti.uni-mannheim.de/Uxibo/) oder
sonstiges, solange es eben zweckdienlich ist.

> Jede Person hat einen anderen Schwerpunkt z.B. Person 1 will 8 Mybte
> Speichertiefe , Person 2 will 16 Eingaenge , Person 3 will 100 Mhz
> Samplerate und schon kocht jeder seine eigene Suppe.

mit dem generic kann man schon viel machen (bis auf unconstrained
records anscheinend). Allerdings macht es ein gutes Programm aus,
anpassbar zu sein! Bisher ist es egal, ob 8,16,...64 Kanäle, 1 oder N
SRAM Speicher - die 100 Euro Marke und der Aufwand im PCB steht im
Raum. Über konkretes können wir uns nicht sinnvoll unterhalten, da der
Core nicht steht ....

Morgen ist der letze Tag in De, dann geht es zu den Minensuchern und
Bombenlegern nach Ägypten. Ich werde vorsichtshalber ;-) die bisherigen
Projektfiles forenfremd hier 'rein stellen - entweder noch heute Abend
oder morgen.

Viele Grüße
Olaf

Autor: ope (Gast)
Datum:
Angehängte Dateien:
  • LA.rar (174 KB, 837 Downloads)

Bewertung
0 lesenswert
nicht lesenswert
da sind sie, musste noch etwas aufräumen. Heute schaffe ich es wohl
nicht mehr, einen grossen Fortschritt zu erzielen. Ein Großteil der
Files ist auf "Vorrat" geschrieben, interessant ist das trigger.vhd
mit tb_trigger. Evtl. sollte dieser Core Teil wirklich in's andere
Forum verschoben werden, sonst gibt's Ärger.
Leider explodiert die Argumentliste so langsam, so dass ich sie in
einen record packen würde; leider ist das generic nicht möglich (so
einfach zumindest).

Viele Grüße
Olaf

PS: selbst wenn es X verschiedene Cores geben würde, Hauptsache sie
passen zur Hardware und sind im API für die PC Software (halbwegs)
kompatibel. Daher ist Board/Firmware Rev. Info gar nicht so verkehrt,
imo auch guter Stil.

Autor: Clemens Helfmeier (sum)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

wenn der CPLD vom AVR aus programmiert werden soll ->

http://www.mikrocontroller.net/forum/read-4-228557.html#new

schöne grüße, Clemens

Autor: ope (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi,

bin wieder (in ganzen Stück) aus Ägypten angekommen, es geht jetzt also
von meiner Seite wieder weiter.

Allerdings werde ich einen neuen Thread unter "Programmierbare Logik"
anlegen für den LA Core, da dieser Teil dann doch zu speziell für dieses
Forum ist; also Augen auch dorthin richten, wer es noch nicht tat.

Viele Grüße
Olaf

Autor: ope (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
wiki update

Autor: Andreas (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Kann es sein, daß Du inzwischen der einzig Aktive in diesem Projekt
bist?

Autor: ope (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
nach dem Monolog manchmal zu urteilen ja; dann würde ich aber Dirk -
shazter(at)web.de und Clemens Helfmeier (sum) Unrecht tun - wir treffen
uns des öfteren im chat room. Gelegentlich kommen dann auch von anderen
einige Hinweise oder Fragen.

Autor: Leenders (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Idee ist nicht schlecht  die Daten über die CPU Port´s einzulesen und
dann abzulegen... aber das dauert.
Andere Lösung
es gibt durchaus die Mgl die daten direkt in das Ram zu lesen

CPU legt nur die Adressen an das CMOSRAM   die Datenleitungen selbst
sind die Eingänge, mit einer Vorbeschaltung  Tristate Bustreiber und
so.

Dann erschließt sich der nanosekundenbereich.
Die ganze Datenbaggerei fällt weg.

Paul

Autor: Dirk (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi,

leider kann ich im moment nicht soviel Zeit investieren wie ich gerne
möchte, aber bis Sonntag sollten schon von meiner Seite aus ein paar
Sachen fertig sein.

Der Monolog tritt hier nur im Forum auf, weil Ope, Sum und ich
besser/schneller im IRC Chat Probleme diskutieren/lösen können.
Es wurde wieder die Hardware abgeaendert was natuerlich wieder ein
zeitlicher Rückschlag ist, aber persönlich bin ich mit dieser Lösung
zufriedener.

Das Projekt insgesamt schläft nicht, aber man sollte nicht vergessen
das dieses Projekt in der Freizeit gemacht wird und einige nebenbei
auch in der Freizeit was zutun hat. Bis zum Winter ist noch viel Zeit
und die Einschaetzung von Ope sollte einzuhalten sein.

>CPU legt nur die Adressen an das CMOSRAM   die Datenleitungen selbst
>sind die Eingänge, mit einer Vorbeschaltung  Tristate Bustreiber und
>so.

Die verschienden Triggermöglickeiten wuerden bei dieser Variante
entfallen und der CPLD schafft locker 100Mhz zu sampeln. Die
Nanosekundengrenze ist nicht wirklich das Problem eher die
Hardwareanforderungen am Platinenlayout.

Im grossen und ganzen kann ich von meiner persoenlichen Einschaetzung
hersagen das jeder ihmo was zutun hat an dem Projekt.

Gruß,
Dirk

Autor: ope (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
so, heute mal 'ne Frage wegen des sram und dem cpld. Wie Dirk sagte,
ist es mit dem Layout nicht so einfach.

Da der sram ja random access ist, sollte die konkrete Zuordnung der
Adressen, die aus dem CPLD kommen und an den SRAM gehen, willkürlich
sein bzw. einem guten PCB geschuldet sein. Das gleiche trifft ja auch
auf die Daten zu. Der SRAM ist ja assoziative - das was ich auf im CPLD
auf Adresse X ausgebe, auf Adresse Y im SRAM speichere, und da pcb
zeitinvariant, ja auch wieder auf CPLD Adresse C wieder einlese. Ich
muss lediglich per ucf sagen, wo ich den AB/DB/CB des SRAM am CPLD
angeknotet habe, oder?

Viele Grüße
Olaf