mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik VNC1L FIFO-Mode Grundsatzfragen


Autor: Matthias Hüsch (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Gemeinde!

Ich wollte zwar nicht direkt mit der Tür ins Haus fallen, der richtige
Account kommt noch, aber es eilt mir ein wenig ;)

Ich habe folgende Problematik:
An einem LPC2214 habe ich einen VNC1L USB-Host per parallelem
Businterface und ein wenig Logik (HCT139) an den externen Speicherbus
angeschlossen.

RXF# und TXE# gehen direkt an Portpins des Contollers.
Jedoch kämpfe ich seit Tagen vergeblich mit dem Programmiermodell des 
VNC1L (VDAP Firmware).
Die Statusreports (device connected) habe ich durch den
Firmware-Customizer deaktiviert, damit der Controller selbst nicht
unvorhergesehen "dazwischenquatscht".

Es geht schon damit los, das der USB-Controller recht eigenwillig auf
Kommandos reagiert. Selbst wenn TXE# aktiv ist, und damit eigentlich
Signalisiert, das neue Daten/Kommandos angenommen werden könnten, gibt 
es
Teils recht unwirsche Reaktionen, wenn ich das dann auch versuche.
Mit einigen Zeitschleifen geht es meistens. Zumindestens für die
Initialisierung und für Query-Device, das ich inkrementell pro
adressierbarem Device alle zig hundert Millisekunden absetze um meine
eigene Device-List up to date zu halten.
Jedoch zeigt schon Query-Device, das der USB-Host ziemlich unberechenbar
reagiert, wenn man ihm kurz nach anstecken des Geräts trotz aktivem
TXE#-Signal und inaktivem RXF# Signal mit diesem Befehl "in die quere"
kommt.

Manchmal fängt er sich dann wieder und nach einem Flush (solange lesen
bis RXF# inaktiv) und einem Sync ( 'e' senden dann auf 'e'
als Antwort warten) ist alles wieder in bester Ordnung.
Aber eben eher meistens nicht. Befehle wie DRD führen meist zum Exitus
oder werfen wild mit Daten um sich, die sie vorher selbst garnicht 
angekündigt haben.
Wenn das Zieldevice auchnoch hinter einem Hub liegt, ist DSD und DRD 
allen Anscheins nach völlig machtlos und ich erhalte garkeine Daten.

-
Gehe ich irgendwie völlig falsch vor, wenn ich so wie derzeit,
ein Modell verwende bei dem ich einen Befehl sende, wenn der Chip
behauptet bereit zu  sein und anschließend eine Antwort erwarte?

Wie müsste ich programmiertechnisch an den IC herangehen um zuverlässige
Resultate zu erhalten?

Hat evtl. auch jemand Beispiel-Code in C oder gut kommentiertem 
Assembler?
(die Zielarchitektur wäre mir ziemlich egal)

Welchen Zweck verfolgen die FIFO-Steuerleitungen, wenn man anhand derer
nicht tatsächlich feststellen kann,
ob es nun genehm ist das man schreibt oder liest?
-

In FTDI's Beispielcode fragt man den Chip alle hundert Millisekunden an,
ob es irgendwelche Nachrichten gibt.
Jedoch bin ich kaum gewillt, nur alle Ewigkeiten einmal einen Befehl
absetzen zu können. Das drückt die Performance dann doch gar zu weit
in den Keller und fernab dessen was ich gerne erreichen würde.
Ich wäre wirklich um jeden Hinweis dankbar.


Viele Grüße!
 Matthias

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.