Hallo, im Rahmen meiner Bachelorarbeit muss ich 2 SPI Slaves auslesen, hierzu soll der FT4222H von FTDI mittels LabVIEW benutzt werden. Die Platine ist soweit gelötet, jedoch beim Einstecken des USB in den Laptop erkennt Windows das IC nicht. Ich hab schon mehrere Kabel und Rechner verwendet und steh ziemlich auf dem Schlauch. Den Schaltplan habe ich vom Entwicklungsboard UMFT4222EV übernommen, bekomme jedoch einfach keine Verbindung zu Windows 10. Hat jemand hier im Forum eventuell schonmal eine ähnliche Situation mit Chips von FTDI gehabt? Mit freundlichen Grüßen Nico
Also zuersteinmal solltest du beim nächsten mal schauen wie man Ports und Lables in Altium richtig benutzt, so nämlich nicht. Zum Problem: 1. Hast du überprüft ob das Quarz sauber anläuft und die gewünschte Frequenz hat? 2. Wie sind die ganzen Configurationspins (DCNF etc.). verbunden das ist auf dem Plan nicht ersichtlich. PS: Werte von Widerständen und Kapazitäten im Schaltplan sind idr. nicht optional und helfen bei der Fehlersuche.
:
Bearbeitet durch User
Danke für die Antwort. > Zum Problem: > 1. Hast du überprüft ob das Quarz sauber anläuft und die gewünschte > Frequenz hat? Das Quarz ist derzeit nicht eingelötet, da es in der USB-Powered Configuration nicht vorhanden ist. > 2. Wie sind die ganzen Configurationspins (DCNF etc.). verbunden das ist > auf dem Plan nicht ersichtlich. Die Configurationspins sind derzeit in MODE2 sprich die Widerstände R47 und R49 sind eingelötet. > PS: Werte von Widerständen und Kapazitäten im Schaltplan sind idr. nicht > optional und helfen bei der Fehlersuche. Sorry, die Widerstands- und Kondensatorwerte sind alle wie im Datenblatt gewählt.
:
Bearbeitet durch User
Ist FB1 gesetzte? Wenn nicht bekommt er keinen VBUS Detect und schaltet den Widerstand auf der D+ Leitung möglicherweise nicht, bin mir grade nicht mehr sicher ob er das zwingend braucht ist schon etwas her. Nico S. schrieb: > Das Quarz ist derzeit nicht eingelötet, da es in der USB-Powered > Configuration nicht vorhanden ist. Ich bin mir ziehmlich sicher das der ohne externe Clock nicht läuft.
:
Bearbeitet durch User
Der FB1 ist eingelötet, die Spannungsversorgung von 5V liegt auch am VCCIN an und auch am VBUS_DET liegen 5V an. Müsste sich das IC nicht reintheoretisch schon mit einer Spannungsversorgung und Verbindung der Datenleitungen zumindest beim Laptop melden? Nur wird mir im Gerätemanager so gar nichts angezeigt...
Nico S. schrieb: > Müsste sich das IC nicht reintheoretisch schon mit einer > Spannungsversorgung und Verbindung der Datenleitungen zumindest beim > Laptop melden? Nur wird mir im Gerätemanager so gar nichts angezeigt... Nein wenn keine Clock da ist macht das ding garnichts. Macht dein µC was ohne das eine Clock da ist? Und ja da ist ein interner RC Oszillator drin, aber wenn weder der noch eine externe Clock etwsa tut, tut der µC auch nichts. Aus interesse, hat Altium dir nicht massenhaft Fehler beim Kompilieren rausgeworfen, weil du die Ports so benutzt hast?
:
Bearbeitet durch User
> Aus interesse, hat Altium dir nicht massenhaft Fehler beim Kompilieren > rausgeworfen, weil du die Ports so benutzt hast? Kein einzigen Fehler :-)
> Nein wenn keine Clock da ist macht das ding garnichts. Macht dein µC was > ohne das eine Clock da ist? Und ja da ist ein interner RC Oszillator > drin, aber wenn weder der noch eine externe Clock etwsa tut, tut der µC > auch nichts. Ich werde mir mal ein Oszillator bestellen und rauflöten in der Hoffnung das es dann funktioniert. Danke für deine Hilfe!
Wer lesen kann ist klar im Vorteil :-( Fehlerquelle sollte somit gefunden sein, Danke!
Nico S. schrieb: > Die Platine ist soweit gelötet, jedoch beim Einstecken des USB in den > Laptop erkennt Windows das IC nicht. Musst du halt den passenden Treiber installieren. Mein Güte, auf diese Idee sollte wohl auch ein Bachelor schon kommen können...
c-hater schrieb: > Nico S. schrieb: > >> Die Platine ist soweit gelötet, jedoch beim Einstecken des USB in den >> Laptop erkennt Windows das IC nicht. > > Musst du halt den passenden Treiber installieren. Mein Güte, auf diese > Idee sollte wohl auch ein Bachelor schon kommen können... Wozu braucht Windows einen Treiber, um überhaupt ein Gerät erkennen zu können (abgesehen von den Basis-USB-Treibern)?
:
Bearbeitet durch User
Jens G. schrieb: > Wozu braucht Windows einen Treiber, um überhaupt ein Gerät erkennen zu > können (abgesehen von den Basis-USB-Treibern)? Braucht es nicht, weil das Problem das fehlenden Quarz ist,was bereits identifiziert wurde. C-hater pöbelt einfach mal wieder, wie er es gerne tut, da er offensichtlich nicht lesen kann/will.
Jens G. schrieb: > Wozu braucht Windows einen Treiber, um überhaupt ein Gerät erkennen zu > können (abgesehen von den Basis-USB-Treibern)? Weil es nunmal aus Gründen der Kausalität völlig unmöglich ist, für alle zum Zeitpunkt der Entstehung des OS noch NICHT existierenden Geräte passende Treiber vorzuhalten. Und weil das die Kausalität so vorgibt, ist das natürlich bei alternativen OS kein bissel anders. Kann man z.B. bei Linux sehr leicht sehen, wenn man einfach mal versucht, es auf einen topaktuellen Rechner zu installieren. Da fehlt i.d.R. einiges an Treibern. Gelegentlich sogar so viel, dass es sich nichtmal installieren läßt... Worauf du dich hier wohl beziehst, ist aber sehr wahrscheinlich die Situation fehlender Klassentreiber für USB-CDC-Devices. Dieses Problem ist natürlich seit der Existenz von Windows10 Geschichte, zumindest natürlich für Windows10-Installationen. Also seit nunmehr sechs Jahren...
c-hater schrieb: > Weil es nunmal aus Gründen der Kausalität völlig unmöglich ist, für alle > zum Zeitpunkt der Entstehung des OS noch NICHT existierenden Geräte > passende Treiber vorzuhalten. Muss man auch nicht, wenn der Treiber deines USB Controllers installiert ist, was er wohl sein muss, wenn man überhaupt den Rechner benutz, taucht ein gerät was sich mit einem Pull-Up auf der D+ Leitung meldet im Gerätemanager auf. Wenn für das Gerät kein Treiber vorhanden ist, eben mit entsprechender Fehlermeldung. Das kann man ganz leicht Testen, indem man z.B. ein Nucleo mit USB und internem Pull-Up an den Rechner anschließt, die USB-Peripherie initialisiert aber vor dem Aushandeln einen Brake Point setzt. Dann passiert nämlich genau das. Das System detektiert über den Pull-Up ein angeschlossenes Gerät bekommt aber keine Informationen. Dennoch taucht es im Geräte-Manager auf. Da das Problem des TO war das der FTDI GARNICHT auftaucht bzw. erkannt wird, ist es primär kein Treiberproblem.
c-hater schrieb: > Jens G. schrieb: > >> Wozu braucht Windows einen Treiber, um überhaupt ein Gerät erkennen zu >> können (abgesehen von den Basis-USB-Treibern)? > > Weil es nunmal aus Gründen der Kausalität völlig unmöglich ist, für alle > zum Zeitpunkt der Entstehung des OS noch NICHT existierenden Geräte > passende Treiber vorzuhalten. Deine Kausalität ist falsch. Denn es ging nicht um passende Treiber, sondern um das grundsätzliche Erkennen irgendeines USB-Gerätes. Und das klappt grundsätzlich ohne USB-Geräte-spezifische Treiber, wenn mit der physikalischen Verbindung und der Elektronik beider Seiten alles ok ist ...
Auch Windows kann USB geräte erkennen, auch wenn es dafür keine treiber hat. Zumindest der Teil der USB Enumeration und damit der übertragung von USB VID und PID erfolgt ohne Spezielle treiber allein vom USB Stack selber. Erst danach suchen die Betriebsysteme nach den dafür notwendigen treibern. Untert windows tauchen auch geräte ohne spezielle treiber im Gerätemanager auf.
Kevin M. schrieb: > Da das Problem des TO war das der FTDI GARNICHT auftaucht bzw. erkannt > wird, ist es primär kein Treiberproblem. Das ist korrekt. Da stimmt dann schon auf niedrigster Ebene der Erkennung was nicht. Was Windows üblicherweise mit einem unübersehbaren Hinweis auf dem GUI automatisch quittiert.
Jens G. schrieb: > Deine Kausalität ist falsch. Nein, ist sie nicht. Und zwar aus zwei Gründen: erstens ist es nicht meine, sondern die aus den Grundgesetzen der Logik geborene und zweitens ist sie halt korrekt, weil eben aus den Grundgesetzen der Logik resultierend. > Denn es ging nicht um passende Treiber, > sondern um das grundsätzliche Erkennen irgendeines USB-Gerätes. Das ist wohl so. Dann hättest du allerdings irgendwas sagen müssen wie: diese Kausalität ist hier irrelevant. DAS wäre die korrekte Erwiderung gewesen. Denn das würde erstens klarstellen, dass diese Kausalität tatsächlich besteht und zweitens halt im konkreten Fall unwichtig ist, weil die Sache schon gescheitert ist, bevor sie in's Spiel gelangen konnte...
Jens G. schrieb: > Deine Kausalität ist falsch. Nein, ist sie nicht. Und zwar aus zwei Gründen: erstens ist es nicht meine, sondern die aus den Grundgesetzen der Logik geborene und zweitens ist sie halt korrekt, weil eben aus den Grundgesetzen der Logik resultierend. > Denn es ging nicht um passende Treiber, > sondern um das grundsätzliche Erkennen irgendeines USB-Gerätes. Das ist wohl so. Dann hättest du allerdings irgendwas sagen müssen wie: diese Kausalität ist hier irrelevant. DAS wäre die korrekte Erwiderung gewesen. Denn das würde erstens klarstellen, dass diese Kausalität tatsächlich besteht und zweitens halt im konkreten Fall unwichtig ist, weil die Sache schon gescheitert ist, bevor sie in's Spiel gelangen konnte...
c-hater schrieb: > Das ist korrekt. Da stimmt dann schon auf niedrigster Ebene der > Erkennung was nicht. Was Windows üblicherweise mit einem unübersehbaren > Hinweis auf dem GUI automatisch quittiert. Nein denn ohne Takt tut der FTDI garnichts, also weiß Windows auch nicht das er da ist ;)
c-hater schrieb: > Jens G. schrieb: > >> Deine Kausalität ist falsch. > > Nein, ist sie nicht. Und zwar aus zwei Gründen: erstens ist es nicht > meine, sondern die aus den Grundgesetzen der Logik geborene und zweitens > ist sie halt korrekt, weil eben aus den Grundgesetzen der Logik > resultierend. Aha, und Du legst jetzt die Grundgesetze fest, nach denen wir uns zu richten haben? >> Denn es ging nicht um passende Treiber, >> sondern um das grundsätzliche Erkennen irgendeines USB-Gerätes. > > Das ist wohl so. Dann hättest du allerdings irgendwas sagen müssen wie: > > diese Kausalität ist hier irrelevant. > > DAS wäre die korrekte Erwiderung gewesen. Denn das würde erstens > klarstellen, dass diese Kausalität tatsächlich besteht und zweitens > halt im konkreten Fall unwichtig ist, weil die Sache schon gescheitert > ist, bevor sie in's Spiel gelangen konnte... Ich habe eher den Eindruck, daß es der c-hater nicht verträgt, bei Falschaussagen erwischt zu werden, und versucht unentwegt, doch noch ein Fünkchen Wahrheit in seinen Aussagen zu entdecken ...
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.