[S] Leute die einen Logic Analyzer (MiniLA) bauen wollen

Wenn man die nett fragt, bekommt man doch bestimmt auch schon für 140 
Euro (20 Leute?) was bestellt, meint ihr nicht?

Hallo!

Laut Datenblatt müsste es passen. Der Zusatz SB heißt Flow-Through-Typ?
Wie gehts eigentlich weiter. Gibt es bereits einen Lieferanten?
Wie ist sonst der Status der Bestellung? War lang nicht mehr hier, 
deshalb die Frage...

MfG Matthias Eder

Ich (myscha) habe mich jetzt mal angemeldet.

@ Eder Matthias
Die xxxxx25 stehen für flow-through. Auf der Seite, die ich oben 
verlinkt habe, gibt es rechts einen "part number decoder". Laut diesem 
steht 25 für "3.3V, LVTTL, SB-FT WIDE", wobei das SB-FT IMO für Sync 
Burst-Flow Through stehen müsste. In folgendem PDF auf Seite 5 wird der 
Samsung-Typ als Ersatz für den Alliance FT-Typ aufgeführt: 
http://www.semiconductorresource.com/pdf/all%20alliance%20x-refs.pdf

Von daher denke ich schon, dass das passt. Ich habe trotzdem mal an 
Samsung geschrieben, aber bisher keine Antwort erhalten.

Ich warte jetzt nicht länger auf Antwort von Samsung - morgen wird das
SRAM bestellt. Falls noch jemand einen Einwand bzw. Bedenken bzgl. des
SRAMs hat, hat er heut abend noch Zeit... ;)

Hallo!

Hast du eigentlich den Rest schon? Also den CPLD usw.
Nicht das es da auch Lieferschwierigkeiten gibt...

MfG Hias

Hi Norbert,
das ist ein verlockendes Angebot, aber leider brauchen wir mittlerweile 
21 St. Und ich möchte nach Möglichkeit vermeiden, dass wir am Ende 
zweierlei Versionen haben...

Eine Platine kannst du aber gerne haben - musst halt die kleinen 
Reparaturen durchführen, die ich weiter oben beschrieben habe. Falls du 
eine (oder mehrere) haben willst, schreib mir eine Email.

So jetzt mal wieder ein aktueller Status:
- SRAMs sind bestellt und werden per Nachnahme verschickt, sollten also 
die nächsten Tage eintreffen.
- Digikey hat sich leider etwas verzögert, weil es Probleme mit der 
Kreditkarten-Zahlung gab. Ist jetzt aber auch unterwegs mit UPS Express, 
sollte also auch die nächsten Tage eintreffen.

Ich habe noch nicht alle Adressen von den "Mitmachern", also bitte noch 
zuschicken, falls noch nicht geschehen...

Das sind doch erfreuliche Nachrichten ! ;)

Die Digikey-Sachen sind in Köln und ich muss da am Montag wegen Zoll und 
EUSt. anrufen. Heute war niemand mehr zu erreichen als ich Feierabend 
hatte.

Die SRAMs sollen laut dem Lieferanten am Montag bei mir ankommen.

Und ich habe mich heute um etwas ESD-gerechte Verpackung gekümmert...

Ich hoffe, dass die Reichelt-Warenkörbe noch aktuell sind - habe meine 
Teile schon danach bestellt... ;)

Im Ernst: ich habe diesen kompletten ("Mainboard" inkl. USB & 
Programmer) hier 
http://www.reichelt.de/?ACTION=20;AWKID=45440;PROVID=2084 eben nochmal 
kontrolliert und der passt. Mit dem habe ich auch meine Teile bestellt. 
Und der baut auf den anderen "einzelnen" auf, daher sollten die auch 
stimmen.

Da ist aber noch kein Material für irgendwelche Tastköpfe dabei.

Und ich habe heute doch tatsächlich jemanden bei UPS erwischt: die 
Digikey-Sachen werden auch am Montag zugestellt...

Anbei der Schaltplan für die Tastköpfe. Die Stecker sind RM2,54, die 
Widerstände und Kondensatoren alle 0805 und für den Treiber kommt der 
Sockel dazu. Die Werte der Widerstände müsst ihr euch selber überlegen - 
die im Schaltplan dienen nur als Platzhalter.

@ Martinß,
Ne Platine und vielleicht SRAM kannst du noch haben, um den Rest 
müsstest du dich selber kümmern. Schreib mir ne Email falls du trotzdem 
Interesse hast.

SRAMs sind eben mit UPS angekommen, die Digikey-Sachen nicht. Die werden 
dann wohl leider erst morgen kommen...

So jetzt ist alles da! Endlich!!!

Hab schon mal angefangen um zu packen und zu "portionieren".

Ein paar Teile (z.B. SRAM) sind/haben MSL. Spielt das in unserem Fall 
eine Rolle - also wenn die von Hand gelötet werden? Oder ist nur beim 
Reflow-Löten interessant? Ich kenn mich damit zu wenig aus...

soweit ich das weiß sollte das nur beim reflow-löten ein problem 
darstellen.

denn bei uns wird ja nur das beinchen warm ;-)

PS: für alle die nicht wissen was MSL ist:
Moisture Sensitive Level - empfindlichkeit von elektronischen bauteilen 
im bezug auf feuchtigkeit.
Wenn zu feucht kann es beim reflow löten passieren das dein bauteil 
"explodiert" (Popcorn)

Hallo!

Ich habe ein Layout des Programmers mit bedrahteten Bauelementen.
Ich habe dabei einfach den Schaltplan von Xilinx verwandt. Allerdings 
kann ich das Layout erst heute Abend reinstellen, weil ich es auf meinem 
Laptop nicht finde ;)

MfG Hias

@ Hias
Evtl. wäre es sinnvoll, den 6pol. Stecker so auszuwählen und zu 
platzieren, dass man das Ganze direkt am MiniLA einstecken kann.

@ all
Was ist euch lieber/wichtiger:
- dass ihr die Sachen so schnell wie möglich bekommt, oder
- dass ich möglichst auf den MSL achte?

Bei ersterem würden die Päckchen (wahrscheinlich) am Freitag und Samstag 
rausgehen und so etwa am Dienstag bei euch sein. Bei letzterem würden 
die Sachen komplett am Dienstag rausgehen und wären entsprechend später 
bei euch.

Leider werden die Päckchen beim hiesigen Hermes-Shop um die Mittagszeit 
geholt. D.h. ich muss das Ganze verpacken und am nächsten Tag abends 
abgeben und am übernächsten geht's dann los...

Mir ist der MSL egal, da ich von Hand löte.

Hallo!

Ich hab ein Entwicklungsboard von Xilinx überlassen bekommen. Da is 
ebenfalls dieser 6-polige Wannenstecker drauf. Aufgrund dessen hab ich 
das so bei dem Layout gewählt.
An was hättest du gedacht? 6 polige (einreihige) gewinkelte 
Buchsenleiste?


Ich löte von auch von Hand und würd es deshalb lieber früher bekommen, 
als MSL -gerecht.

Hias

Hi,

Mir ist der MSL egal, da ich von Hand löte.

Gruß Rene

Hallo nochmal,

Ich hab das Layout mal überarbeitet.

Ich hab die Xilinx-Standard-Belegung benutzt. Laut Schaltplan müssen 
dazu beim miniLA folgende Verbindungen gelötet werden.

E1-E7
E2-E5
E3-E6
E4-E8

Der Xilinx-Standard ist:

1 = VCC
2 = GND
3 = TCK
4 = TDO
5 = TDI
6 = TMS

Ich hoff des passt jetzt so!?

Hias

@ Hias
Ich dachte an ne 6-pol. 1-reihige Buchsenleiste, richtig!

Mir ist der Xilinx-Standard relativ, da ich das Dingens nur für den 
MiniLA verwenden werde. Deswegen war mein Gedanke eine Buchsenleiste zu 
verbauen und die Pinanordnung so zu gestalten, dass ich das 
"Programmiergerät" direkt einstecken kann. Da man zwischen E_ und E_ 
aber sowieso strippen ziehen muss, ist man dort entsprechend flexibel 
und die Pinbelegung des Steckers ist nicht so wichtig.

So wie in deinem letzten Post müsste es stimmen, ja.


Wegen MSL:
da ihr euch ja ziemlich einig seid, verschicke ich die Sachen asap, 
benachrichtige euch dann und gebe die Sendungsnummer durch. Beim CPLD 
steht leider keine "MSL-Zeit" drauf, bei Bedarf kann ich euch aber 
sagen, wann ich die Teile geöffnet habe.

@ Hias
Hab mir dein Layout eben nochmal angeschaut: ich glaube du hast dich 
beim D-Sub vertan. Es sollte die männliche Version sein, soweit ich 
weiß, nicht die weibliche.

Anbei noch ein Layout mit SMD-Widerständen und -Kondensatoren. Das passt 
aber NICHT zum Reichelt-Warenkorb für den Programmer. Leider kann ich 
mit FreePCB und meinem Gerber-Viewer nicht drucken, deswegen gibt's die 
Daten nur so...

Hallo!

Sollte doch egal sein, ob ich eine männliche Version des Steckers 
auflöte, oder eine weibliche?

Hias

Hallo!

Hier nochmal das Layout mit der männlichen Version.
Achtung auch dieses Layout ist ungetestet!

Hias

Hi,

auch mein Paket ist angekommen!
Danke, myscha!

Da ich dieses Projekt teilweise aus den Augen verloren habe,
könnte ich jetzt eine Zusammenfassung/Manual sehr gut gebrauchen.... :-(

Mal sehen, wann ich Zeit finde den miniLA aufzubauen.

Gruss
Stefan

Achso: gebt beim Auspacken ein bisschen acht - ich habe zu den Grabbern, 
falls vorhanden, immer die beiden bedrahteten Elkos, den Tantal und die 
Induktivität gepackt. Nicht, dass ihr das überseht und wegwerft. Auf den 
entsprechenden Päckchen müsste auch ein ! sein...

meiner ist auch gestern angekommen.
Vielen Dank.

lol - hab eben ne Antwort von Samsung bekommen. Lieber spät als nie...

Ich hatte ja gefragt, ob das FT für Flow-Through steht (siehe 
Beitrag "Re: [S] Leute die einen Logic Analyzer (MiniLA) bauen wollen").

Antwort: "yes, FT means Flow Through"

Mein Päckchen ist auch gestern schon angekommen. Heute oder morgen 
müssten auch die Reichelt-Sachen kommen. Mal sehen, ob das Ding bis zum 
Wochenende läuft..

Vielen Dank an Michi schonmal für die ganze Arbeit mit der 
Sammelbestellung!

Hallo!

Meins ist auch da!
SRAM und CPLD sind schon aufgelötet. :)
Ich hoffe ich kann spätestens morgen erste Ergebnisse präsentieren.

VIELEN DANK auch von mir, Michael!

MfG
Hias

Hallo!

Ich habe auch gerade den LA programmiert.
Mit oben vorgestelltem Programmer hatte ich keine Probleme.
Als nächstes hab ich das Eeprom des FTDI-Chips beschrieben-> ebenfalls 
alles i.O..

Jedoch meldet die miniLA-Software beim Starten, dass das USB Interface 
nicht initialisiert werden kann.

@Alex:
Hast du ebenfalls das USB-Interface am laufen?
Wenn ja was hab ich vergessen? :D

MfG
Hias

Moin moin,
meine Teile sind gestern auch angekommen.
Allerdings brauche ich noch einige Tage, bevor ich Zeit zum Bestücken 
finde.
Mfg Jens

Hallo,

Das EEprom hast du aber schon mit dem *.ept File von der minila-Seite 
beschrieben?

Ich mach für heute auch Schluss.

Hias

Hallo!

Erstmal das erfreuliche:
Mit dem LPT Port funktioniert der miniLA einwandfrei.

Mit dem USB Interface allerdings hab ich noch leichte Probleme:

Das erste auffällige:
Wenn ich die Jumper auf LPT-Mode stecke habe ich einen Stromverbrauch 
von ca 340mA. Im USB Modus sind das ca 470mA obwohl der FTDI-Chip 
buspowered ist.
Das ist definitiv nicht normal.

Zweitens:
Die Initialisierung des MPSSE-Modus vom FTDI 2232 funktioniert nicht 
immer.
Ich habe im Quellcode die Stelle mit der Fehlermeldung. USB Init failed 
gesucht und musste feststellen dass die Synconisation mit der 
MPSSE-Einheit fehlschlägt. Infos dazu gibts unter 
http://www.ftdichip.com/Projects/MPSSE.htm
Dort findet man auch ein Test-Programm, dass exakt die selbe 
Initialisierung wie das miniLA Programm verwendet. Auch hier ist der 
Fehler der Initialisierung reproduzierbar.

Drittens:
Manchmal gelingt diese Initialisierung, jedoch findet die Software den 
miniLA trotzdem nicht.

Ich suche momentan nach Hardwarefehlern, weil mich der enorme 
Stromverbrauch doch etwas stuzig macht.

Hat jemand von euch ähnlches beobachtet?

MfG
Hias

Hat jemand ne Wärmebild-kammera? 100mA sollte man "sehen" können ;)

Hi!

Das ist wohl ein Wink mit dem Zaunpfahl. Nein es wird nichts heiß, außer 
der CPLD. Den hohen Stromverbrauch kann ich aber nachvollziehen. Bei 
100Mhz braucht der CPLD ca 400mA. Ein Teil davon geht mit Sicherheit in 
Wärme verloren, deshalb der heiße CPLD. Von dem her streicht das mit dem 
Stromverbrauch. Das scheint normal zu sein.

Ich hab die Schaltung überprüft, aber nichts ungewöhnliches gefunden. 
Nur der Multplexer ist mir noch ein wenig supekt. Welche Funktion hat 
der Baustein?

Wie schauts mit den anderen aus? Schon irgendwelche (USB)-Erfolge?

MfG Hias

Das Paket ist auch bei mir angekommen.
Danke für die Organisierung der Sammelbestellung.

Hallo!

Kannst du mal ein Bild der bestückten Platine einstellen (Vorder und 
Rückseite). So könnte man eventuell Bestückungsfehler erkennen. Wer 
kennt das nicht: Man sieht den Wald vor lauter Bäumen nicht mehr :D

MfG Hias

Hallo!

Man kann es schlecht erkennen aber es schaut so aus als ob PIN 1 vom 
100MHz Osszilator Kontakt zu dessem Metallgehäuse hat...
Ansonsten kann ich nix auffälliges erkennen.

Hias

Gehäusedeckel vom Ozillator liegt normal auf Masse.
Welchen Widerstand kannst du zwischen Masse und VCC messen?

Hias

Schaut mir nach eine Lötbrücke bei den beiden großen IC's aus.
Grade beim SRAM liegen viele GND-VCC Pins direkt nebeneinander.
Auch beim CPLD gibts drei solche stellen (36/37, 72/73, 108/109).
Wenn du die Platine von der Seite und unter der Lupe anschaust, kann man 
solche Brücken eigentlich gut erkennen. Viel Glück :)

btw. Hat schon jemand Erfolg mit der USB-Verbindung?
Kann jemand btte mal die Signale vom Quarz (6MHz) am Oszi anschauen.
Von den Atmel µC her meine ich dass beide Signale gleich sein sollten.
Das ist bei mir nicht der Fall....

MfG Hias

Neue Ergebnisse:

Ich hab mir die Signale auf dem EPP Datenbus angesehen.
Wenn endlich mal die Initialisierung funktioniert ist Datenverkehr zu 
verzeichnen. Was genau kann ich leider mit meinem Oszi nicht 
herrausfinden.

Es scheint also, dass beim Datenaustausch etwas nicht funktioniert. Weil 
das ganze konstant erscheint.
Ich hab deshalb mit Hilfe des Testprogramms von FTDI aus der 
Codesammlung (HOSTemul) und des Communicaton-Protokoll einfach mal einen 
Sampling gestartet, und siehe da eine der LED's geht an. Es scheint 
also, dass das Ding läuft. Aber und jetzt kommt das ungewöhnliche: Das 
Lesen funktioniert nicht.
Ich bekomm immer 0xFF zurück.

Jemand ne Idee an was das liegen könnte?
Ich bin weiter auf der Suche nach der Ursache.
Auch was die Initialisierungsprobleme angeht.

Hias

Hallo!

Der CPLD wird zumindest bei mir auch ziemlich heiß.
Im Datenblatt wrd eine Stromaufnahme von ca 400mA bei 100Mhz angegeben.
Ein ziemlich großer Teil wird dabei in Wärme umgesetzt.
Was bei dir jetzt heß ist weiß ich nicht. Verbrennen tue ich mir de 
Finger nicht, aber unangenehm ist es schon wenn ich auf den CPLD fasse.

MfG Hias

Ich würd ja mit der Entlötlitze drüber gehen ;)
Mir reichts für heute...

Hias

Hallo!

Kann jemand btte mal die Signale vom Quarz (6MHz) am Oszi anschauen.
Von den Atmel µC her meine ich dass beide Signale gleich sein sollten.
Das ist bei mir nicht der Fall. Beide Schwingen zwar, aber die Amplitude 
ist nicht gleich.

MfG Hias

Das mit der unterschiedlichen Amplitude sollte aber so passen (ohne das 
am Oszi gesehen zu haben; müsste aber auch bei AVR's so sein).

Hallo!

Ich hab so ca 550KOhm. Aber das sollte so passen.
Hast du das USB Interface schon mal ausprobiert?
Langsam aber sicher fehlt mir ein Anhaltspunkt wo der Fehler liegt.
Ich bekomm einfach keine Daten vom CPLD zurück.

MfG Hias

Hallo!

Hmm hab gerade noch auf LPT umgesteckt.
Ich bekomm zwar die Firmware_Infos. Aber wenn ich einen Samplingvorgang 
mit einem definierten Signal starte, dann bekomm ich nur Müll.
Ich denke also, dass der Fehler eher beim CPLD zu suchen ist.
Mein erster Tip war der Oszilattor, aber den kann ich nicht überprüfen, 
weil mein Oszi nur 20Mhz schafft :)
Entweder ist dieser defekt. Oder die Firmware funktioniert nicht 
richtig.

Hat von euch jemand schon irgendwelche Erfolge?

MfG Hias

Leider bin ich noch nicht zum aufbauen gekommen, da reichelt noch nicht 
geliefert hat:-(

Gibts schon neues? :)
Ich hab leider zwischenzeitlich nicht mehr viel Zeit für den miniLA 
gehabt.

MfG Hias

Und wie sieht's bei euch aus - gibt's schon irgendwelche 
Erfolgserlebnisse? Ich bestücke meinen so nach und nach. Ein bisschen 
wird's bei mir also noch dauern.

An die, die beim Auslesen nur Mist empfangen:
habt ihr dran gedacht die zusätzliche Adressleitung anzuschließen?

Adressleitung? :)
Du meinst vom SRAM?

Ja, vom SRAM. Pin 43 muss z.B. auf GND oder Vcc gelegt oder mit Pin 42 
gebrückt werden.

Möchte egtl. jemand die zugehörigen Daten, sprich das Layout haben? 
Falls ja: Email an mich...


Für alle, die das Teil noch nachbauen wollen: ich habe noch ein paar 
"defekte" Platinen...

was bedeutet "defekt"?

Wenn es nur die normale Überproduktion ist hätte ich noch interresse an 
eine Platine.

Gruß Marco

Das sind die ersten PCB's, die ich gekriegt habe. Die Defekte habe ich 
irgendwo weiter oben beschrieben (mit Bild). Es müssen halt 2-3 Brücken 
gezogen werden.

Hallo!

Ich hab gerade die Brücke gelötet, jedoch keine Änderung.
Per USB keine Verbindung und per LTP nur Müll beim Auslesen.
Hat schon jemand einen Erfolg zu melden?

MfG
Hias

Michael K. wrote:
> Ja, vom SRAM. Pin 43 muss z.B. auf GND oder Vcc gelegt oder mit Pin 42
> gebrückt werden.

Egal :)

Das ist ein Adresspin. Im ursprünglichen Design wurde ein 128X32 SRAM 
verwendet. Wir haben die doppelte Größe. Somit auch einen Adresspin 
mehr.
Diesen kannst du jetzt auf Masse legen (unterer Adressraum) oder auf VCC 
(oberer Adressraum) oder einfach mit dem nebenliegenden Adresspin 
brücken.
Nur unkontaktiert solltest du ihn nicht lassen.

Hias

Komisch. Bei jedem das gleiche USB-Problem.....
Irgendwas stimmt da bei der Anpassung an das EPP-Protokoll nicht.
Wenn ich nur ein besseres (Speicher)-Oszi hätte...

ich hab eins (bzw. die firma) - komme vermutlich aber erst am montag 
dazu
mal zu schaun.
Zudem will ich erstmal sehen ob ich das gleiche Problem mit den Werten 
hab.
Erstmal das und dann usb ;)

Hi,

bin leider mit dem Bestücken noch nicht ganz fertig. Aber morgen wird es 
wohl dann werden. Haben eigentlich alle Leute die Prob's mit USB haben 
den FT2232L drauf oder auch jemand den C ?

Gruß Rene

Ich hab den FT2232L.

@Daniel: Wie ist die Blinksequenz der Testfirmware bei dir?

Sehr gut! Das selbe bei mir auch. Ein kleiner Lichtbilck, der Takt ist 
ok.

Ich kann das bestätigigen.
Das ist ja interessant. Ist mir so nicht nicht aufgefallen.

Werd das bei gelegenheit mal genauer anschauen.

Habe jetzt endlich Zeit gefunden bei Reichelt zu
bestellen.
Werde mich am Wochenende an den Aufbau begeben
(das päckchen wird knapp ... naja :-( )

Was mir am Warenkorb auffiel:
SMD-0805 47,0
da sind 49 davon drin.
Aber 100 sind günstiger wegen dem Mengenrabatt.

Gruss
Stefan

Hallo!

Es gibt erfreuliches zu Berichten. Ich hab mich noch einmal mit den 
Einstellungen des LPT-Ports auseinander gesetzt. Wichtig ist, dass ihr 
im Bios die richtigen Einstellungen habt. Ich musste z.B. von einem 
Auto-Mode auf ECP+EPP umstellen (EPP alleine hat bei mir nicht 
funktioniert, hatte ich vorher) Als Version hab ich 1.7 eingestellt, 
weiß aber nicht ob es da merkliche Unterschiede gibt. Der LogikAnalyser 
funktioniert jetzt ohne Probleme. Die Signale entsprechen den 
Erwartungen. Ich habe testweiße das Signal 3er Leuchtdioden eines 
aktuellen Projekts von mir abgegriffen. Das Ergebnis findet ihr im 
Anhang. Bin echt begeistert!

Fehlt nur noch eine Lösung für das USB-Problem...

MfG Hias

Hi!

Ich mach grade das Layout für eine Pegelwandler-Platine.
Ich möchte eigentlich die 32 Kanäle auf 4 10polige Wannenstecker aus dem 
Gehäuse führen. Jeweils 8 Kanäle plus VCC und GND. Kann es da zu 
Problemen kommen? Auf der Platine sind ja jeweils eine Masseleitung 
dazwischen.

MfG Hias

Hallo
Im Schaltplan steht zwar, dass der Test-Pin nach GND verbunden werden 
muss, der Pin (47) ist aber schon mit Masse verbunden. 
(Durchkontaktierung unterm 6Mhz Quarz nach Masse.)

Hias

Hi,
ich bin zwar nicht im Projekt beteiligt, aber wenn Du den Delphi-Code 
als ZIP anhängst, kann ich mal drüber schauen.
Gruß
Frank

Hi,
nach kurzer oberflächlicher Analyse habe ich festgestellt, daß bei der 
Initialisierung der USB-Schnittstelle in beiden Anwendungen mit 
unterschiedlichen Latenzzeiten gearbeitet wird.

In der Anwendung von Sourceforge wird mit einer Latenzzeit von 100ms??

1

//=================================================================

2

function InitDev : boolean;

3

//=================================================================

4

var

5

  passed : boolean;

6

  res : FT_Result;

7

begin

8

   res := Set_USB_Device_LatencyTimer(100);

9

   res := Set_USB_Device_BitMode($00,$00);     // reset controller

10

   res := Set_USB_Device_BitMode($00,$08);     // enable Host Bus Emulation

11

   passed := Sync_To_MPSSE;

12

   InitDev := passed;

13

end;

und in der anderen Anwendung mit einer Latenzzeit von 16ms???

1

function InitDev : boolean;

2

var passed : boolean;

3

res : FT_Result;

4

begin

5

res := Set_USB_Device_LatencyTimer(16);

6

res := Set_USB_Device_BitMode($00,$00); // reset controller

7

res := Set_USB_Device_BitMode($00,$08); // enable Host Bus Emulation

8

passed := Sync_To_MPSSE;

9

InitDev := passed;

10

end;

gearbeitet.

Da die Anwendung mit den 16ms??? korrekt arbeitet, wäre dies mein erster 
Ansatz. Ich benötige aber noch mehr Hinweise, da ich die Anwendung 
mangels entsprechender USB-Devices nicht testen kann.

Neu compilieren schaffe ich erst am Wochenende, da ich erst eine 
entsprechende VM aufsetzen muss, damit ich den Code und die Bibliotheken 
nutzen kann. Meine aktuelle Delphiumgebung möchte ich nicht damit 
belasten.

Gruß
Frank

Hallo Daniel,
ich versuche am Wochenende ein kleines Kommunikationsprogramm 
zusammenzustellen, dass die Latenzzeiten anpassbar macht. Wir können 
damit versuchen die korrekten Latenzzeiten einzustellen.
Wobei mir noch nicht ganz klar ist, was mit dieser Latenzzeiz 
tatsächlich bewirkt wird.

Kannst Du mir den sagen, an welcher Stelle genau der Fehler auftritt 
bzw. welche Fehlermeldung ausgegeben wird?

Gruß
Frank

Hallo,
ich habe das Programm jetzt mal kompiliert.
Die Anwendung sucht zu Programmstart nach einem USB-Adapter mit dem 
Namen:

"miniLA USB Interface A"

wird dieser Adapter nicht gefunden, wird der entsprechende Fehler 
ausgeworfen.

Kann mir jemand den Namen geben, mit dem sich Euer USB-Treiber einträgt?

Desweiteren haben ich die Latenzzeit mal auf 16 eingestellt.
Im Anhang die entsprechende Applikation.

Gruß
Frank

Hallo!

Du musst das ept. File in das EEprom vom FTDI-Chip hochladen.
Dort wird der entsprechende Name eingetragen. Bei mir wird der Treiber 
mit
"miniLA USB Interface A" geladen.

Hab momentan leider keine Zeit das ganze bei mir zu testen.
Vielleicht finde ich morgen einen Moment.

MfG
Hias

Hallo zusammen,
bin jetzt auch endlich soweit, dass ich mich an der Fehlersuche 
beteiligen kann. Habe den miniLA über die parallele Schnittstelle zum 
Laufen bekommen.
Bei USB sieht es bei mir etwas anders aus. Ich bekomme keine Verbindung, 
allerdings auch keine Fehlermeldung. Wenn ich USB auswähle wird in der 
ComboBox auch "miniLA USB Interface A" angezeigt. Bei erneutem Aufruf 
der Konfiguration ist die Box jedoch leer. Wie gesagt - ohne 
Fehlermeldung.
Was mir aufgefallen ist, ist, dass die Kondensatoren am 6 MHz - Quarz 
22p statt 27p (Schaltplan) haben (zumindest laut Reichelt Warenkorb). 
Evtl. könnte es da einen Zusammenhang geben. Als Firmware habe ich die 
Timebase-Variante genommen.

Gruß, Thomas

Hallo Thomas,
es ist so, dass die Anwendung beim Starten die Combobox initialisiert. 
Wird anschließend der Setup-Dialog aufgerufen, wird keine weitere 
Initialisierung aufgerufen.

D.h. findet die Anwendung bei Programmstart den Adapter nicht, wird auch 
kein weiterer Versuch unternommen den Adapter zu finden.

In meinem vorherigen Posting habe ich die Anwendung angehangen 
allerdings mit anderen Timing-Einstellungen.

Ich werde versuchen am Wochenende ein Testprogamm zusammenzubauen, dass 
einen vereinfachten Test der Kommunikation erlaubt und einige 
Paramatrisierungen ermöglicht.

Zusätzlich werde ich die Quellen hinsichtlich weiterer Abweichungen 
gegenüber der Anwendung von der ftdi-Seite prüfen, da das Testprogramm 
anscheinend funktioniert.

Leider kann ich selber nicht Testen, da ich keine entsprechende Hardware 
zur Verfügung habe. Ich werde deshalb jede Variante der Software posten 
und dann auf ein Echo von Eurer Seite warten müssen.

Gruß
Frank

Hallo Daniel,
gut, mit dieser Fehlermeldung kann ich jetzt prüfen, was als nächstes 
schief geht. Ich melde mich heute Abend.

Wenn ich Zeit habe, werde ich die ganze Anwendung etwas anders 
strukturieren und aufbauen. Dann ist dieser Schönheitsfehler auch 
beseitigt.

Gruß
Frank

Hallo,
wieder ein Fehler gefunden, in der Routine OpenPort, fehlen 
entscheidende Zeilen Code. Ich passe das heute Abend an und prüfe den 
restlichen Code für die Kommunikation. Ich denke, dann wird es erstmal 
passen.

Gruß
Frank

Hallo,
hier eine neue Version der Anwendung.
Im Code habe ich noch ein paar Ungereimtheiten entdeckt.
Bitte einmal versuchen und Fehler melden.
Gruß
Frank

Guten Morgen Frank,

ich bekomme leider immer noch keine Verbindung. Allerdings ist in der 
Combobox jetzt Dauerhaft der Adapter auswählbar und verschwindet nicht 
immer wieder.

Gruß, Thomas

Guten Morgen Thomas,
das ist Schade, aber ich werde morgen ein kleines Kommunikationsprogramm 
zusammenstellen, mit dem erst einmal die Verbindung über den 
USB-Baustein getestet werden kann.

Daniel schrieb ja schon, dass er die Verbindung zum ftdi hinbekommen 
hat. Ihm fehlte jetzt noch die Verbindung von ftdi zu CPLD.

Hast Du eine Fehlermeldung bekommen? Wenn ja welche.

Gruß
Frank

Nein - habe keine Fehlermeldung bekommen. Ich werde es morgen mal mit 
der anderen Firmware testen. Wie hast Du die Software eigentlich 
kompiliert bekommen. Was muss mit der tScroll-Datei in Components 
gemacht werden. Hab noch nie mit Delphi gearbeitet. Ein Bekannter hat 
mir seinen Laptop mit Borland Delphi 2006 geliehen - bekomme aber immer 
ne Fehlermeldung TOwn... fehlt. Auch wenn ich von Delphi keine Ahnung 
hab - vielleicht fällt mir ja auch was im Quelltext auf...

Gruß, Thomas

Hallo Daniel,

hast Du es schonmal mit der Stateanalyses-Firmware getestet?

Gruß, Thomas

@Thomas,
die Scrollbar kann man als Komponente herunterladen. Such mal über 
Google.
Im Quellcode, musste ich dann noch ein paar Zeile auskommentieren, da 
die Version der Scrollbar einige Methoden nicht unterstützt.

Ich poste aber heute Abend gerne den vollständigen Code. Kann Dir aber 
nur abraten, daran zu arbeiten wenn Du keine Ahnung von Delphi hast. Die 
Sourcen sind echt schlimm (möchte den ursprünglichen Entwicklern nicht 
zu nahe treten).

Wenn Du bei der Initialisierung keine Fehlermeldung erhalten hast, kann 
es eigentlich nur bedeuten, dass die Einrichtung der Kommunikation 
fehlerfrei gelaufen ist. Natürlich vorausgesetzt, ich habe jetzt keinen 
Fehler eingebaut.

Ich werde mir heute Abende ein kleines Programm bauen, um ersteinmal 
sicherzustellen, dass eine Kommunikation über die USB-Schnittstelle mit 
diesen Sourcen funktioniert. Da ich einen USB-Programmer habe, kann ich 
mit meinem Testboard die Kommunikation über den ATMega Uart 
protokollieren.

Im zweiten Schritt, müsst Ihr prüfen, ob die Kommunikation auf Eurem 
Board an die nächste Stufe nach der USB-Schnittstelle weitergereicht 
wird.

Gruß
Frank

Hallo,

Ich hab die letzte Version der Software gerade etwas testen können.
Wähle ich "automatic detection" dann verbindet er problemlos mit dem 
FTDI.
Allerdings kommt der Initialisierungsfehler, wenn ich die manuelle 
Auswahl treffe. Bei mir steht auch nicht miniLA USB Interface A 
dauerhaft in der Combobox. Wenn ich in das Untermenu komme dann stehts 
drinnen, klicke ich allerdings auf den Dropdown-Pfeil dann verschwindet 
der Eintrag.

Ich habe bemerkt dass im Treiber der Name mit miniLA USB Interface (ohne 
A) angegeben ist. Vielleicht gibts damit Probleme.

Im "AutomatikModus" hab ich den Bus mit dem Oszi untersucht.
Was mir auffällt ist, dass kein extended read/write stattfindet. Der Pin 
usbadd8 wird für den Multiplexer verwendet. Dieser ist bei mir konstant 
Low.
Somit ist auch die Read/Write Leitung immer Low. Somit wäre auch klar 
dass der CPLD nichts auf den Bus legt, weil dieser immer im 
Empfangsmodus ist.
Leider hab ich in Delphi noch nie was gemacht, werd aber trotzdem nach 
Fehlern suchen.

Es wird immer über ein Testprogramm gesprochen.
Dies kennt ihr aber:
http://www.ftdichip.com/Projects/MPSSE/FT2232C-Proj04_HostEmul.zip

Das wars erstmal....

Hias

Hallo.

Ich werds mal versuchen.

Der EPP ist eigentlich recht einfach zu erlären.
Es gibt 8 (bidiretionale) Datenleitungen, DataStrobe, AdressStrobe und 
Read/Write. Außerdem noch ein paar weitere, die für uns uninteressant 
sind.

Betrachten wir mal den Read (vom PC aus gesehen).
Der PC sendet Informationen, nämlich die Adresse, von der er lesen will.
Dabei legt er die Address Strobe auf Low, Write ist High und an den 
Datenleitungen liegt die Adresse an.
Danach antwortetet das Device mit dem Inhalt des zu lesenden Registers.
wenn DataStrobe Low wird, Write ist wieder High und an den 
Datenleitungen liegt der gewünschte Registerinhalt an.

Die für uns wichtigen Leitungen sind also
DST (Datastrobe)
AST (Adressstrobe)
RD/WR (Read == Low)

DST und AST scheinen zu funktionieren.
Nur Read liegt bei mir immer auf Low, somit legt der CPLD nie Daten auf 
den Bus.

Der Multiplexer ist in meinen Augen da, um den Bus auf das EPP 
anzupassen.
Die Funktion ist leicht erklärt:
Es handelt sich um einen 3 fach Multiplexer der in Abhängigkeit von A 
entweder X0 oder X1 auf X legt. (bei B und C mit Y und Z genauso)

So long....
Hias

P.S.: Auch mit dem Testprogramm kann ich nichts aus dem CPLD rausziehen.

Ich hab das eben aus der Antwort rausgenommen, weil ich nicht sicher bin 
was da passiert.
Wenn du mit dem Host_Emul Programm verbindest, hast du dann auf 
irgendwelchen Pins ein Signal drauf (Ohne Datenübertragung)? Vorhin 
hatte ich ein Signal das durchwegs high war aber sobald ich die 
Verbindung aufbaue habe ich, in regelmäßigen Abständen, kurze 
Low-Spikes. Wie gesagt ich schaff das nicht mit meinem Oszi sauber 
darzustellen.
Kannst du das mal bitte testen?
Hias

EDIT: Du warst schneller :)

Versuch das ganze mal mit verbundenem FDTI. Nimm dazu mal das Programm 
aus dem Link oben, sodass kein Datentransfer stattfindet. Da müssten 
jetzt kleine Spikes erkennbar sein.

Ich hab eigentlich wieder Pin 1 und Pin 4 gemeint:).

Du musst extended read/write machen und bei der High Adresse 0x01 
eintragen.
Dann muss RD/WR high werden....

Hallo!

Sehr interessant das ganze.
Ob das Read hinhaut kann ich so nicht erkennen, da bräuchte ich noch DST 
und AST.

Die Störung hab ich auch beobachtet. Ob die einen Einfluss auf die 
Datenübertragung hat weiß ich nicht. Die noch größere Frage ist woher 
sie kommt... Auf alle Fälle ist der FT2232dran Schuld. Ich werd mal 
kucken ob ich dawas finde.

Hias

Danke dass du dir soviel Arbeit machst.
Ich nehme an der minila10.png is ein screenshoot beim Data_Write mit dem 
HOST_Emul Programm? Extended?

was ich ned versteh ist warum beim Lesen die RD/WR Leitung auf low geht? 
(D8)
Die müsste eigentlich auf High bleiben.
Das war den anderen Bespielen auch schon so.

Was mir allerdings auffällt ist, dass beim parallelen Anschluss. RD/WR 
auch während des DST auf low bleibt. Beim USB ist RD/WR nur dann LOW 
wenn AST low ist. Nicht aber bei DST.

Eder Matthias wrote:
> Betrachten wir mal den Read (vom PC aus gesehen).
> Der PC sendet Informationen, nämlich die Adresse, von der er lesen will.
> Dabei legt er die Address Strobe auf Low, Write ist High und an den
> Datenleitungen liegt die Adresse an.
> Danach antwortetet das Device mit dem Inhalt des zu lesenden Registers.
> wenn DataStrobe Low wird, Write ist wieder High und an den
> Datenleitungen liegt der gewünschte Registerinhalt an.

Da hatte ich einen Denkfehler!

Richtig ist das hier:
Betrachten wir mal den Read (vom PC aus gesehen).
Der PC sendet Informationen, nämlich die Adresse, von der er lesen will.
Dabei legt er die Address Strobe auf Low, Write ist LOW und an den
Datenleitungen liegt die Adresse an. Der CPLD liest die Adresse.
Danach antwortetet das Device mit dem Inhalt des zu lesenden Registers.
wenn DataStrobe Low wird, Write ist wieder High (also für den PC 
READ)und an den Datenleitungen liegt der gewünschte Registerinhalt an.

@Daniel,
Du meinst also die Versionsnummer ist nicht korrekt, was bedeutet das 
genau? Was wäre die richtige Version bzw. wenn ich die Versionsprüfung 
abschalte, was kann passieren. Werden die Kommandos dann falsch 
interpetiert?

@hias,
arbeitest Du mit meiner letzten Programmversion oder hast Du eine eigene 
andere Software?

Gruß
Frank

Die ganze Kommunikation läuft anscheinend falsch -
die Versionsnummer wird an der entsprechenden Stelle nicht richtig
ausgelesen - und mit falscher Versionsnummer erkennt die
Software die Hardware nicht an. Das ist das erste Problem.
Umgeh ich das Problem, indem ich die Versionsabfrage auskommentiere
und der Variable einen festen (und richtigen) Wert gebe, dann
wird die HW erkannt und man kann drauf zu greifen.

Nur eben stimmen die Werte und alles andere vorne und hinten nicht!

Also:
Es scheint ein grundlegendes Problem in der Kommunikation zwischen
FTDI und CPLD zu sein. Diese Kommunikation wird ja aber von dem
Windows/Delphi Programm gesteuert.
Die letzten zwei Bilder zeigen eigentlich deutlich wie
sich USB und Parallel unterscheiden.

 lg Daniel

@Daniel,
was bedeutet "stimmen die Werte nicht"?

Gibt es eine Kommandostruktur?

Gruß
Frank

mit paralleler Software (keine pins angeschlossen) bekomm ich:
alle pins auf high (0xFF)
mit usb (keine Pins angeschlossen) bekomm ich:
teil der pins auf high (0xF9)

leg ich einen Pin auf Ground, dann ändert es sich auch beim parallelen 
Betrieb, Beim USB Betrieb bleibt es auf 0xF9.

http://minila.sourceforge.net/fw/communication_protocol_fw_1.7.html
Ansonst kann ich nur noch auf die zwei Bilder hinweisen. Mit dem obigen 
Link (und dem einen und einzigen Link da drin) sagt es aus, dass beim 
USB was nicht stimmen kann.
Die ganze AST/DST/RW Sache ist zwischen USB und Parallel 
unterschiedlich.

@Frank
Ich habe oben genannte Beobachtungen mit deiner letzten Software 
gemacht.

@Daniel
Wenn ich mit der Host-Emulsoftware einen Read von 0x0101 mache bekomm 
ich immer 0xff. Grundsätzlich 0xff egal welche Adresse. Du bekommst 
0xF9????

Ich hab gerade eine Beobachtung gemacht. Berühre ich mit dem Tastkopf 
einen der Pins, nachdem ich mit der miniLA Software von Frank eine 
Verbindung aufgebaut habe steht plötzlich eine Firmwarenummer drinnen.
Was sagt uns das? Es wird grundsätzlich was gelesen, jedoch gibt der 
CPLD nichts aus. Die Datenleitungen sind alle im Tristate, deshalb 
reicht der Pulldown des Tastkopfs aus um die Datenleitung auf 
Massepotentialzu ziehen.
Für mich haben wir es hier mit einem Timingproblem zu tun. Wo genau weiß 
ich noch nicht.

Daniel du sagst USB läuft um ein vielfaches schneller? Ich weiß nicht 
was die ganzen Angaben in deinen Logs bedeuten. Wie viel schneller.
Eventuell resultieren daraus unsere Probleme. Die USB Version nutzt das 
Wait-Signal nicht, und ist deshalb in meinen Augen sehr anfällig.

Gibt es im Treiber irgendeine Einstellung die die Transferrate 
beschränkt?

Ich benötige mal Eure Hilfe zum Thema Kommunikation:

Für USB - Read steht in der Software folgender Code:

1

    if last_access <> read then

2

    begin

3

        AddToBuffer($91);     // read extended

4

        AddToBuffer($1);      // Address high

5

    end else

6

        AddToBuffer($90);      // read short

7

8

    AddToBuffer(Addr);       // Address low

9

    if immediate then

10

    begin

11

        AddToBuffer($87);     // Send Immediate

12

        SendBytes(OutIndex);    // send off the command

13

        result := GetData;

14

    end else

15

        result := 0;

16

   last_access := read;

für LPT der folgende Code:

1

      OutPort(lpt_control,$00);         // set direction OUT

2

      Delay;

3

      OutPort(lpt_control,$01);         // write do 0 (write)

4

      Delay;

5

      if Addr <> last_address then

6

       begin

7

   OutPort(lpt_base,Addr);  // set adr (data)

8

   Delay;

9

   OutPort(lpt_control,$09);  // adrstb to 0 (slct in)

10

   Delay;

11

   OutPort(lpt_control,$01);     // adrstb to 1 (slct in)

12

   Delay;

13

       end;

14

      OutPort(lpt_base,Val);       // set data (data)

15

      Delay;

16

      OutPort(lpt_control,$03);   // datastb to 0 (autofeed)

17

      Delay;

18

      OutPort(lpt_control,$01);    // datastb to 1 (autofeed)

19

      Delay;

20

      OutPort(lpt_control,$21);      // direction IN

21

      Delay;

Das sind erhebliche Kommando Unterschiede die meines erachtens so nicht 
sein können. Die gleichen Unterschiede habe ich auch bei USB - write.

Kann das so richtig sein, oder müßten nicht immer die gleichen Kommandos 
unabhängig von der Schnittstelle gesendet werden?

Gruß
Frank

Du musst bedenken, dass der extended read notwendig ist für den 
Multiplexer.
0x91 scheint das Kommando für den FTDI zu sein einen extended read zu 
sein gefolgt von der High-Adresse der Low-Adresse gefolgt von dem Befehl 
sofort zu senden. Scheint mir alles plausibel zu sein. (Ich kenne die 
Befehle vom Treiber allerdings nicht)

Hallo Leute,
ich habe die Quellen von MiniLa_win auf meinem Server zum Download 
bereitgestellt.

http://www.derplatinenshop.de/download/minila_win.zip

Im Unterverzeichnis Src befinden zwei Projekte

1. minila.dpr
2. package1.dpk

Im Package1 sind die benötigten Delphi-Componenten enthalten. Diese 
müssen zuerst installiert werden.

Anschließend kann dann das Projekt selber kompiliert werden.

Gruß
Frank

Hallo,
das Testprogramm von FT2232 -> HostEmul habe ich überarbeitet.

Mit diesem Programm könnt Ihr erst einmal die Kommunikation prüfen.
Es findet keine Prüfung einer Version statt.

Mit dieser Anwendung kann zum einen das vorhanden sein einer 
Schnittstelle geprüft werden sowie die Kommunikation mit der CPLD.

In der Zip-Datei sind die Sourcen und die Anwendung in komplilierter 
Form enthalten.

http://www.derplatinenshop.de/download/FT2232C.zip

Mit der Anwendung miniLa kann ich leider erst weitermachen, wenn 
sichergestellt ist, dass Euer Board funktioniert und keine 
Kommunikationsschwierigkeiten hat. Dann bin ich aber gerne bereit das 
ganze auf neue Füsse zustellen.

Was das Testprogramm angeht bitte alle Wünsche und Anpassungen posten.

Gruß
Frank

Hallo!

Danke Frank! Was hast du da geändert? Jetzt klappt jeder 
Verbindungsversuch.
Außerdem scheint das Schreiben zu funktionieren. Ihr könnt z.B.0x80 
senden.
Das bedeutet dass das Capturing gestartet wird. Erkennbar an der 
mittleren LED. 0x40 bedeutet Reset ->mittlere LED geht aus.
Das funtioniert einwandfrei.
Aber beim Lesen bekomm ich immer nur 0xff....
Ideen warum?

MfG Hias

Mein MiniLA liegt in der Firma, deswegen kann ich erst Montag was dazu 
sagen.
Zum Thema Timing, Geschwindigkeit:
Unten rechts auf den OSZIBildern sieht man die Timenbase. Einmal
sind es 50 us pro div, das andere mal 500ns pro div.
USB ist also grob gesagt (sehr grob!) um Faktor 100 schneller.

> Eder Matthias wrote:
> Jetzt klappt jeder Verbindungsversuch.

@hias
welche Anwendung hast Du verwendet. FT2232 habe ich nur aufgeräumt und 
lesbar gemacht.
An miniLa habe ich nichts verändert.

Könnt Ihr auf dem Bus messen, was zurückgegeben wird? Wenn ja, kann so 
festgestellt werden, ob es am Programm liegt oder an der Hardware, wenn 
nicht, müssen wir uns überlegen, wie ich die Rohdaten angezeigt bekomme, 
es kann ja auch an der Empfangsroutine liegen. Ich würde dann einen 
Monitorfunktion einbauen, die die Rohdaten die von USB geliefert werden, 
anzeigt bevor Sie aufbereitet werden.

Gruß
Frank

Hallo Leute,
ich habe mich im Internet ein wenig umgesehen und eine aktuellere 
Version von
FT2xx.dll gefunden. Vielleicht liegt eins der Probleme auch hier 
verborgen.

Bitte prüft das mal.

http://www.ftdichip.com/Drivers/D2XX.htm

Ich prüfe parallel, ob die Software mit dieser DLL funktioniert.
Gruß
Frank

Hallo!

@Daniel: Du hast beim miniLA10.png einen extended Read auf Addr. 0X0101 
gemacht?

Ich hab das Bild mal analysiert. Als Addresse kommt hier 0xF9 raus und 
als Data 0x87. Das ist reiner Müll.

Mich würde interessieren wie es bei einem Write ausschaut. Dieser 
funtioniert ja anscheinend mit dem Testprogramm.

Die neue *.dll hab ich auch schon getestet bringt auch nichts.

Ich benutze zum testen das Host-Emul Programm in deiner Version.
Da hab ich komischerweise kaum Probleme eine Verbindung aufzubauen.
Mit der Version von FTDI ist das nicht so. Irgendetwas musst du also 
geändert haben :)