www.mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik Vinculum Problem - VDrive und SPI Schnittstelle


Autor: Andy (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo zusammen

Bin dabei das Vinculum VDrive von FTDI zum Laufen zu bringen.
Das Modul wird über die SPI Schnittstelle mit einem PIC18F4620 
verbunden.
Neuste Firmware (3.66) ist aufgespielt.

Habe jetzt aber das Problem, dass in nur einmal auf den Stick schreiben 
kann. Beim 2. Schreibvorgang hängt sich das Moeul auf. Das heisst ich 
warte bei der Rückantwort immer auf neue Daten im Statusbit, welche nie 
kommen.

Die LED leuchtet dann dauernd.

Nach einem Power OFF/ON läuft das ganze wieder einmal korrekt durch.
Hier die Befehlsreihenfolge im SCS Mode (Short Command set)

Nachdem der Stick erkannt wurde:
File Open:  0x09 0x20 'h' 'e' 'l' 'l' 'o' '.' 't' 'x' 't' 0x0D
File Write: 0x08 0x20 0x00 0x00 0x00 0x0C 0x0D 'H' 'e' 'l' 'l' 'o' ' ' 
'W' 'o' 'r' 'l' 'd' '!' (weiss nicht, ob hier noch ein 0x0D nötig 
ist!!!)
File Close: 0x0A 0x20 'h' 'e' 'l' 'l' 'o' '.' 't' 'x' 't' 0x0D

Beim 2. Durchgang wird nur noch 'Hello World' (also ohne Ausrufezeichen) 
geschrieben. Danach 'hängt' sich das Modul auf. Das heisst, beim 
zurücklesen des Status Bits ist dies immer 1 gsetzt. (keine neuen Daten 
verfügbar)

Hat jemand die SPI Schnittstelle schon zum Laufen gebracht?
Bin für jeden Tip sehr dankbar, habe schon Stunden verbraten beim Suchen 
und googeln.


Gruss Andy

Autor: Andy (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hat wirklich niemand Erfahrung mit dem Vinculum- Chip in Zusammenhang 
mit der SPI Schnittstelle?

Komme einfach nicht mehr weiter und wäre für Hilfe sehr dankbar!

Autor: uCler (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wo in dieser Reihenfolge ist denn der zweite Durchgang?
Wird ohne ! aus dem c ein a?

Gruss Udo

Autor: Andy (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nein, es werden keine Zeichen vertauscht.

Beim 2. Versuch auf den Stick zu schreiben wird der Schreibbefehl >
File Write: 0x08 0x20 0x00 0x00 0x00 0x0C 0x0D 'H' 'e' 'l' 'l' 'o' ' '
'W' 'o' 'r' 'l' 'd' '!'
nicht mehr bis zu Ende ausgeführt.
Nach dem Schreiben des 'd' läuft meine Software in einer Endlosschlaufe, 
da das Status Bit der Rückantwort immer 1 gesetzt ist. Dies bedeutetnach 
Datenblatt: Write data was not accepted, retry the same write cycle.

Ich habe gelesen, dass die Anzahl zu übertragenen Bytes genau stimmen 
muss, da dies von der Frimware nicht geprüft wird. Das Längenbyte ist in 
meinem Fall 0x00, 0x00, 0x00, 0x0C (d12) da ich ja 12 Zeichen 'Hello 
World!' zu senden habe. Ich habe aber mit verschiedenen Längenangaben 
probiert und immer den selben Fehler bekommen.

Autor: uCler (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Also Du versuchst:

Init
...
...
open
write
close
open
write
close
open
...
...

und der zweite write funktioniert nicht?

Autor: Andy (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Korrekt!

Autor: Andy (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bin immer noch nicht weitergekommen und FTDI meldes sich auch seit 2 
Tagen nicht auf mein Mail.

Hab gelesen, dass die SPI Schnittstelle generell ein wenig zickt.
Bin ich etwa der einzige, der damit Probleme hat?

Autor: uCler (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Andy,

Nein - bist Du nicht. Ich habe auch (nicht nur) gelesen, dass der 
Vinculum im SPI-Mode aehm, sagen wir mal 'empirisch' behandelt werden 
muss.

Was heisst denn bei Dir Endlosschleife? Angefangen hatte ich mit timeout 
Zeiten im Bereich von Millisekunden, was immer wieder zu Fehlern führte.

Kann es sein, dass Du ihm nicht genug Zeit gibst?

Wenn der Vinculum intern etwas macht, ist er schon Mal ein (empirisches) 
Weilchen nicht ansprechbar.

Gruss Udo

Autor: Andy (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi Udo

Herzlichen Dank für Dein Feedback!

Ich verwende die Routinen aus dem FTDI Demoprojekt 'vmusic_V101'.

Dort wird solange ein Byte zum Vinculum gesendet, bis im Statusbit eine 
0 zurückgelesen wird. Dies bedeutet, dass die Daten gelesen und 
verarbeitet wuden. Ich habe nun das Problem, dass immer eine 1 
zurückgesendet wird. Das wiederum heisst, der Vinculum hat das Byte 
nicht akzeptiert (oder hat sich aufgehängt).
Evt. stimmt jrgend eine Längenangabe in meinen gesendeten Daten nicht. 
Dies wird laut Datenblatt nämlich nicht überprüft. Hab aber noch nicht 
rausgefunden, wo das Problem sein könnte.
Ich möchte auf die Timeout Sache verzichten, da die Antwortzeiten ja 
nicht genau definiert sind.

Autor: uCler (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Andy,

wirklich helfen kann ich Dir nicht. Ich habe immer solange 'rumprobiert' 
bis der Vinculum tat was er sollte. Es wäre auch einen Versuch Wert, mal 
eine ältere Firmware aufzuspielen (bei mir 2.6). Ich meine in einem 
anderen Forum mal was gelesen zu haben....

Gruss Udo

Autor: Andy (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Sind ja tolle Aussichten. Mit einer alten Firmware rumzuprobieren macht 
mich auch nicht gerade an. Hab übrigens auf einem Modul noch Ver. 2.6 
draufgehabt. Damit bin ich gar nicht so weit gekommen, dass ich den 
Stick erkannt habe.

Hast Du die Erfahrung gemacht, dass der Vinculum ein Problem hat, wenn 
Du ihm zu viele oder zu wenig Daten sendest. (Daten stimmen nicht mit 
den Längenangaben im Protokoll überein)

Autor: uCler (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Es ist schon ein paar Tage her und von der Priorität lief es zwischen 
Tagesschau und Kinder in's Bett bringen. Prinzipiell funktionierte alles 
was ich probieren wollte, aber nicht stabil. Ich meine, dass es mit dem 
weglassen der short commands besser geworden ist. Aber das kann 
Einbildung sein.

Bei den beobachteten Problemen bin ich nicht in die Tiefe gegangen. Da 
wo Du die Endlosschleife hast läuft bei mir ein timeout, in dem auch 
nicht fortlaufend (bei NAK) geschrieben wird, sondern zwischen den 
Versuchen etwas gewartet wird. Ich meine, ab da lief es dann ganz gut.

Mein abgegebenes Statement war: Geht - aber da muss noch Einiges getan 
werden.

Mmhh - jetzt wo ich das schreibe bin ich doch ein wenig unsicher 
geworden. Mitte Januar soll es laufen, und nicht humpeln. Ich glaube ich 
krame das nochmal hervor, und probiere ein wenig ernsthafter.

Schön wäre wenn sich hier jemand einklinken würde, der das schonmal 
gemacht hat. Wir werden ja wohl nicht die Einzigen sein die den Vinculum 
im SPI-Mode betreiben.

Gruss Udo

Autor: Flo (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Andy,

ich habe vor längeren mit dem Vinculum Modul gearbeitet. Ich habe 
anstelle der SPI- die serielle Schnittstelle verwendet. Auch das "Short 
Command Set" habe ich nicht verwendet. Jedoch habe ich ähnliche Fehler 
wie du gehabt.

Der Vinculum hat sich beim zweiten Schreiben aufgehängt. Das Problem 
war, wie du auch schon vermutet hast, dass die Angabe der zu 
schreibenden Bytes falsch war.

Was jetzt bei dir genau faul ist, kann ich leider nicht sagen.

Hast du schon mal probiert die Byte-Order (Little Endian <-> Big 
Endian), der zu schreibenden Bytes, zu ändern?!?

Ansonsten kann ich dir nochmal einen Auszug aus meinem Code zeigen. 
Vielleicht kannst du etwas damit anfangen.

-----------------------------------------------------------
Befehle nach dem Einschalten:

1. "IPA" (aktiviert IPA Modus)
2. "OPW MeineDatei.txt" (Öffne bzw. erstelle Datei)
3. "WRF 10" (Anzahl der Bytes die du schreiben möchtest)
4. "Hallo Welt" (Das was du schreiben willst)
5. "CLF MeineDatei.txt" (Geöffnete Datei schließen)

Jede Zeile, bis auf die 4., muss mit einem "Carriage Return"
abgeschlossen werden.
-----------------------------------------------------------

Viel Glück und Gruß

Flo

Autor: Andy (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Mann bin ich froh, dass sich noch jemand hier eingeklinkt hat!

Bin soeben ein wenig weitergekommen. Das heiss ich kann nun meine Daten 
3-4x hintereinander auf den Stick schreiben, bevor sich das Ding 
aufhängt.

Habe in der Schreibroutine das CR am Schluss weggelassen und nach der 
Längenangabe ein delay (10ms) eingefügt.

Das Modul scheint ein Promt zurückzumelden, obschon es intern noch gar 
nicht bereit ist für einen neuen Befehl. Kann das jemand bestätigen?

Autor: Andy (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hab soeben gesehen, dass ich mehr Probleme habe, wenn ich den Stick 
zwischendurch wieder entferne.
Bleibt er immer gesteckt, kann ich mehrmals hintereinander schreiben.

Autor: R. W. (quakeman)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Also ich habe mit dem Vinculum bisher noch nichts gemacht, aber 
interessanterweise ist gerade in der aktuellen Elektor 11/08 ein Artikel 
über genau diesen Chip drin.
Dort steht auch, daß der Vinculum generell nur CR und keine LF haben 
will.
Nach dem File write Kommando kommt auch kein CR mehr, weil der Befehl ja 
durch die Angabe der Zeichenlänge schon automatisch abgeschlossen wird.
In der aktuellen Elektor sind auch Bascom Beispiele für einen Atmega88 
per serieller Schnittstelle drin (RS232 nicht SPI).

Vielleicht hilft euch dieser Artikel ja etwas weiter. Einfach mal im 
Zeitschriftenladen eures Vertrauens durchlesen. ;)

Ciao,
     Rainer

Autor: Meister Eder (edson)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Andy, Udo, Flo

>Wir werden ja wohl nicht die Einzigen sein die den Vinculum
>im SPI-Mode betreiben.

Richtig. Da bin ich.

>Es wäre auch einen Versuch Wert, mal
>eine ältere Firmware aufzuspielen (bei mir 2.6)

Wird kaum was bringen. In den ReadMe-Texten von FTDI kannst du schon 
vorher feststellen, welche alten Fehler dann dein Projekt behindern 
werden.

>Hast du schon mal probiert die Byte-Order (Little Endian <-> Big
>Endian), der zu schreibenden Bytes, zu ändern?!?

Bringt in diesem Fall ebenfalls nichts, da die Reihenfolge (MSB first) 
so richtig ist. Einzige Ausnahme sind die USB-Parameter des SSU-Befehls.

>Hab soeben gesehen, dass ich mehr Probleme habe, wenn ich den Stick
>zwischendurch wieder entferne.
>Bleibt er immer gesteckt, kann ich mehrmals hintereinander schreiben.

Beim ansteuern des Vinculum ist man zwar SPI-Master, wird aber zum 
Sklaven (Slave) der Vinculum-Firmware ;)
Wenn du nach dem Prinzip 'Ich sende Befehle' -> 'Vinculum arbeitet und 
antwortet dann' vorgegengen bist, spuckt dir der Firmware-Monitor in die 
Suppe. Der meldet nämlich wenn es ihm passt, ob ein Gerät an- oder 
abgezogen wurde etc.
Die sicherste Methode (die bei mir gut funktioniert) ist das zyklische 
Abfragen des Monitors auf neue Daten. Nur wenn der VNC nichts zu sagen 
hat, bekommt er einen neuen Auftrag.

@quakeman

>Dort steht auch, daß der Vinculum generell nur CR und keine LF haben
>will.

Das kann man der Dokumentation auch eindeutig entnehmen. Gerade bei 
Verwendung des SCS dürfte klar sein warum. Ist hier leider nicht die 
Lösung.

Gruß,
Edson

Autor: Benedikt K. (benedikt) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Meister Eder wrote:

> Wenn du nach dem Prinzip 'Ich sende Befehle' -> 'Vinculum arbeitet und
> antwortet dann' vorgegengen bist, spuckt dir der Firmware-Monitor in die
> Suppe. Der meldet nämlich wenn es ihm passt, ob ein Gerät an- oder
> abgezogen wurde etc.

Ich verwende den Vinculum per UART, da Hardware SPI aufgrund des 
nicht-Vielfachen von 8bit nicht verwendbar ist.
Ich Lösche direkt vor jedem Befehl den Empfangsbuffer. Es gibt zwar 
immer noch die recht unwarscheinliche Möglichkeit, dass genau zu dem 
Zeitpunkt danach jemand einen Stick reinsteckt, aber bisher gabs noch 
keine Probleme.

Falls der Vinculum per UART/SPI geflashed wird, dann kann man dessen 
Firmeware mit einem Tool anpassen, dass er keine solchen Meldungen 
sendet.
Leider geht das beim Update via USB Stick nicht.

Autor: Meister Eder (edson)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Ich Lösche direkt vor jedem Befehl den Empfangsbuffer.

Genau, so meine ich das.

>Es gibt zwar
>immer noch die recht unwarscheinliche Möglichkeit, dass genau zu dem
>Zeitpunkt danach jemand einen Stick reinsteckt, aber bisher gabs noch
>keine Probleme.

Stimmt, in meiner Anwendung wird daher wie beim PC der Benutzer dazu 
angehalten den Stick vor dem Abziehen abzumelden.

Gruß,
Edson

Autor: Bit-Pfriemler (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Also wir verwenden den VNC1L-Chip direkt, also ohne Modul. Mit der 
seriellen Schnittstelle gibt es bei höheren Geschwindigkeiten mächtig 
Fehler. Kommentar von FTDI: langsamer arbeiten. Für richtig lange Reihen 
bedeutete dies bei uns 19.200 Baud. Etwas arg langsam!!

Auf SPI sind wir nicht gegangen, denn das Format ist derart idiotisch, 
dass ich annehme, dass die Jungs besoffen waren, als sie das konzipiert 
hatten.

Wir verwenden den VNC1L im 8-Bit-parallel-Modus. Aber auch hier hat das 
Ding gewaltige Macken und man darf sich nicht auf die Timings 
keinesfalls verlassen. Wir haben daten unseres Logicanalysers an FTDI 
geschickt. Antwort: wir müssen das prüfen. Machen die Jungs nun seit 9 
Monaten!

Einzige Möglichkeit bei uns: wir synchromisieren den Transfer nach jedem 
Write und Read immer wieder mit dem E. Dann läuft das ganze stabil. Wir 
haben jetzt schon über 3000 Stück im Einsatz.

Allerdings verwenden wir immer noch V3_62, weil ich keine Lust habe, 
hier ein Risiko einzugehen, weil die Herren von FTDI wieder Müll gebaut 
haben.

Bei uns antworten die Jungs von FTDI immer schnell, aber leider immer 
ohne wirklichen Nutzen für uns....schade

Autor: Benedikt K. (benedikt) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bit-Pfriemler wrote:
> Also wir verwenden den VNC1L-Chip direkt, also ohne Modul. Mit der
> seriellen Schnittstelle gibt es bei höheren Geschwindigkeiten mächtig
> Fehler. Kommentar von FTDI: langsamer arbeiten. Für richtig lange Reihen
> bedeutete dies bei uns 19.200 Baud. Etwas arg langsam!!

Könntest du dazu ein paar Details verraten? Ich verwende den Vinculum 
mit UART und 1,5MBaud, hatte aber bisher (abgesehen von den üblichen 
Macken) keine weiteren Probleme. Allerdings lese ich auch nur und 
schreibe nur selten Daten.

> Wir verwenden den VNC1L im 8-Bit-parallel-Modus. Aber auch hier hat das
> Ding gewaltige Macken und man darf sich nicht auf die Timings
> keinesfalls verlassen.

Meinst du die TXE/RXF Timings? Da ist mir auch schon aufgefallen, dass 
nach einem Zugriff die Pins länger brauchen um gültige Werte anzunehmen 
als im Datenblatt steht.

> Einzige Möglichkeit bei uns: wir synchromisieren den Transfer nach jedem
> Write und Read immer wieder mit dem E. Dann läuft das ganze stabil.

So ähnlich habe ich das am Ende auch gemacht: RXF zweistufig über 74HC74 
mit dem CPU Takt verzögert, so dass RXF nur gültig ist, wenn es 
mindestens 3 Takte lang aktiv war.

Autor: Dennis (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich frage mal in die Runde: Hat jemand schon fertige und getestete 
Software für den VNC1L, das er bereit ist hier zu veröffentlichen?

Autor: Bit-Pfriemler (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Dennis
Sorry, aber die Software darf ich nicht rausrücken

@Benedikt
Das mit dem VNC1L und UART ist schon ein bisschen her und es hatte mich 
damals gut eine Woche Zeit gekostet. Ich hatte dann in einem Anfall von 
Wut die Software mit UART weggeworfen. Ich wollte damit nichts mehr zu 
tun haben...

Ich muss aber vielleicht noch eine Info nennen: Ich verwende die Befehle 
SD und SW, weil ich das FAT32-Handling lieber selber mache.

Autor: Meister Eder (edson)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ Dennis

Da es eine Auftragsarbeit war, kann ich das derzeit leider nicht. 
Außerdem dürften hier die Wenigsten was mit dsPIC Assembler anfangen 
wollen.

>Auf SPI sind wir nicht gegangen, denn das Format ist derart idiotisch,
>dass ich annehme, dass die Jungs besoffen waren, als sie das konzipiert
>hatten.

Also so schlimme finde ich das nicht. Da man das zeitliche Verhalten des 
VNC ohnenhin nur erraten kann, hat man jede Menge Zeit für simples 
Bit-Banging.

>Einzige Möglichkeit bei uns: wir synchromisieren den Transfer nach jedem
>Write und Read immer wieder mit dem E. Dann läuft das ganze stabil. Wir
>haben jetzt schon über 3000 Stück im Einsatz.

Das mache ich nur nach längeren Pausen, in denen die USB-Ports nicht 
genutzt werden.

Gruß,
Edson

Autor: Andy (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Jungs.

Habs glaub ich geschafft!!!
Das Motto war 'Back to the roots'.
Hab mir noch einmal das 'vmusic_V101' Demo von FTDI ganauer angeschaut.
Hab beim zurücklesen der Quittungen die Funktion:

- resp = monPromt();

anstelle von

- resp = monResponse();

verwendet. Dies scheint der Grund zu sein, wesshalb sich das Modul
zwischendurch aufgehängt hat.

Also, peinlich ganau auf die Reihenfolge achten, mit der die Befehle
gesendet werden. Am besten alle Antworten auswerten, welche vom Modul 
kommen, damit Fehlabläufe (zBsp. Löschen einer nicht vorhandenen Datei 
...) gar nicht erst auftreten können.
Schauen, dass der Buffer im Modul nicht überlaufen kann und am besten 
die 'State machine' der Demo Software als Grundlage für
die eigene Software übernehmen.
Danke auch für den Tip mit der Synchronisation des Moduls im Laufenden 
Betrieb, werde ich sicher auch noch einfügen.

Nochmals allen ein herzliches Dankeschön für die Ratschläge!

Gruss Andy

Autor: Jadeclaw Dinosaur (jadeclaw)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jetzt wo das Problem gelöst ist, hänge ich mich mal mit einer generellen 
Frage dran:
Treiberfreie Speicherkartenlesegeräte, z.B. für SD-Karten, bzw. externe 
Festplatten, hat das schonmal jemand am Vinculum ausprobiert und 
funktioniert das? Die sollen sich angeblich wie ein USB-Stick als 
USB-Massenspeicher anmelden.

Gruß
Jadeclaw.

Autor: Benedikt K. (benedikt) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ja, geht. Allerdings nur reine SD oder sonst was Kartenleser. Welche die 
mehrere Laufwerke erzeugen funktionieren nicht (bzw. eventuell nur das 
erste LW?)
Ich hatte auch schon USB HDDs dran, die sind erstaunlicherweise 
schneller als USB Sticks, selbst alte <1GB Platten. Und das obwohl der 
VNC nur Datenraten von ein paar 100kbyte/s schafft und mein USB Stick am 
PC sehr viel schneller ist.

Autor: Jadeclaw Dinosaur (jadeclaw)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Alles klar, danke für die Info.

Gruß
Jadeclaw.

Autor: Bit-Pfriemler (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hm...also ich kann das leider nciht bestätigen. Bei uns sind USB-Platten 
immer langsamer als USB-Sticks, besonders, wenn der Plattencache leer 
ist und neu nachgelesen werden muss.

Autor: Benedikt K. (benedikt) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bit-Pfriemler wrote:
> Bei uns sind USB-Platten
> immer langsamer als USB-Sticks, besonders, wenn der Plattencache leer
> ist und neu nachgelesen werden muss.

Waren das viele kleine Dateien bzw. Dateien die Stück für Stück gelesen 
werden mussten? Bei kleinen Dateien kann ich mir gut vorstellen, dass 
ein USB Stick schneller ist, daher hat es mich auch gewundert, dass die 
Festplatte schneller ist.
Ich lese große Dateien (so 1-2MByte, die in einen Speicher geladen 
werden, und zwar so schnell wie möglich).
Was mir dabei aufgefallen ist: Lese ich die Daten in Blöcken (z.B. 
4kByte), dann wird die Wartezeit die der VNC benötigt ehe er mit dem 
Transfer anfängt zunehmend länger, je weiter hinten man in der Datei 
ist. Meine Vermutung: Er hangelt sich jedesmal neu durch die FAT 
Clusterchain. Anders kann ich mir das nicht erklären. Wenn ich 
stattdessen die Datei komplett anfordere, dann wird die mittlere 
Datenrate (gemessen über die Zeit pro gesamte Datei) mehr als doppelt so 
hoch, als mit der kleine Block Methode.

Autor: Bit-Pfriemler (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Benedikt
Wie schon geschrieben verwenden wir nur die Befehle SD und SW. Mit 
diesen Befehlen liest/schreibt man immer nur einen Block (512 Bytes) per 
direkter Adressierung. Dazu braucht der VNC1L keine Clusterchain.

Wenn Die Blöcke brav hintereinander auf der Festplatte liegen, ist eine 
Festplatte via VNC1L ungefähr so schnell wie ein USB-Stick. Wenn 
allerdings der Block an anderer Stelle auf der Festplatte liegt, muss 
die Festplatte ja erstmal den Kopf hinfahren...und da wird die 
Festplatte dann merklich langsamer. Aber da kann der VNC1L nichts dafür, 
das ist eben so.

Unsere Dateien sind übrigens so zwischen 4 und 10MB groß.

Autor: Benedikt K. (benedikt) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bit-Pfriemler wrote:
> Wenn
> allerdings der Block an anderer Stelle auf der Festplatte liegt, muss
> die Festplatte ja erstmal den Kopf hinfahren...und da wird die
> Festplatte dann merklich langsamer. Aber da kann der VNC1L nichts dafür,
> das ist eben so.

Bei mir wurden die Lücken beim Lesen mit zunehmender Dateiposition bei 
einem USB Stick größer -> das liegt defintiv am Vinculum, denn der USB 
Stick müsste sehr viel schneller bei Suchen sein, als das was der 
Vinculum an Wartezeit verursacht (es ging bis in die 100ms und das 
kontinuierlich!)

Autor: Bit-Pfriemler (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Benedikt
Nun, ich denke, die haben noch einige Bugs in Ihrer Software. Ansich der 
Hauptgrund, wieso wir die neuen Updates nicht aufspielen, sondern mit 
dem einmal laufenden Chip zufrieden sind. Ich will nicht über 3000 
Geräte nachrüsten müssen und vor allem den Ärger haben, wenn die neue 
Bugs eingebaut haben...

Autor: Benedikt K. (benedikt) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ja, die haben definitiv noch einige Bugs (und dass obwohl der VNC 
mittlerweile schon >2 Jahre alt ist). Ich habe zum Glück immer einen 
Testaufbau in dem ich die neue Software erstmal teste, ehe ich sie 
übernehme. Ich warte die ganze Zeit schon drauf, dass bei deren VDPS 
Firmeware (die sich wie ein FT232 am zweiten USB Port verhält) der 
Vinculum endlich mal erkennt, dass der Stecker gezogen wurde: Einmal mit 
dem PC verbunden, zeigt er für immer an, dass eine Verbindung da sei. 
Immerhin haben die den Fehler mittlerweile erkannt, aber noch nicht 
behoben.

An sich ist der VNC schon ein schönes IC, aber die Bugs sind halt doch 
sehr nervig. Ich glaube in der nächsten Anwendung wo es auf 
Geschwindigkeit ankommt, werde ich wieder eine SD Karte verwenden, die 
per SPI läuft: Die kann ich schön mit 15MHz ansteuern, da bekomme ich 
sehr viel bessere Datenraten hin, als mit dem VNC, selbst wenn ich das 
Dateisystem selbst machen muss. Dann bekommt der Kunde halt einen SD 
Kartenleser mit dazu.

Autor: Bit-Pfriemler (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ja, der VNC1L ist ansich schon ein nettes IC. Und zu deren Ehrenrettung 
muss man sagen, dass die Sache schon recht kompliziert ist.

Allerdings sollten sie schneller auf Kundenmeldungen reagieren und 
einige Kommandos sind nicht wirklich durchdacht. Wenn man mit SD einen 
Block liest und in diesem Moment der USB-Stick gezogen wird, bekommt man 
anstelle der 512 Bytes eine Fehlermeldung. Aber woher weiß ich, dass es 
eine Fehlermeldung ist und dieser Text nicht zufällig in diesem Block so 
steht? Woher weiß ich, dass nach der Fehlermeldung Schluss ist und ich 
nichts mehr geschickt bekomme (also keine 512 Bytes)? Kalr, ein Timeout, 
aber der kostet sinnlos Zeit.

Du müsste der VNC1L nur am Anfang ein Statusbyte schicken und schon 
wären diese Probleme behoben. Aber soweit denkt bei denen leider keiner. 
Irgendwie kein wirklich gut durchdachtes Konzept. Leider!

Autor: Benedikt K. (benedikt) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bit-Pfriemler wrote:
> Aber woher weiß ich, dass es
> eine Fehlermeldung ist und dieser Text nicht zufällig in diesem Block so
> steht? Woher weiß ich, dass nach der Fehlermeldung Schluss ist und ich
> nichts mehr geschickt bekomme (also keine 512 Bytes)?

Ja, das Problem ist mir bestens bekannt, darüber habe ich mich auch 
schon aufgeregt. Ich mag eigentlich keine Timeouts, aber beim VNC kommt 
man leider nicht drum herum. Zu >90% fange ich die Benutzerfehler ab, 
aber wenn jemand wirklich mal beim Lesen den Stick zieht, ist er selber 
schuld wenn die Software hängenbleibt, oder Mist ankommt.

Autor: Bit-Pfriemler (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Klar, sind die Kunden selber schuld, wenn sie ausgerechnet dann den 
Stick ziehen. Aber ich versuche sowas immer möglichst per Software zu 
regeln, denn es gibt auch Kunden, die sehen sowas einfach nicht ein.

Okay, Geschmackssache...aber von FTDI wäre das ganz einfach zu lösen, 
aber keiner denkt dran...

Autor: uCler (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Die Resetleitung ist zwar schon geplant, aber ich möchte dennoch fragen: 
Wenn man den Vinculum in den Wald geschickt hat (entweder so wie im 
Eröffnungspost, oder mittels EMV, Störung oder sonstwie), kann man ihn 
per SW zurückholen?

Angeschlossen sind z.Z. Plus, Masse, Miso, Mosi, CS und CLK. Ich habe 
schon mehrere Versuche mit E's und e's und CR's gemacht, aber - wenn weg 
dann weg.

Nun sollen E und e ja zur Synchronisation sein. Über mehr schweigt sich 
die Doku aus. Kann jemand von Euch da etwas zu sagen?

Gruss Udo

Autor: Andy (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Würde mich auch brennend interessieren.

Hat sonst noch niemand dieses Problem gehabt und gelöst?

Autor: Andy (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Würde gerne noch einmal darauf zurückkommen, ob jemand einen Trick 
gefunden hat, wie man das Vinculum Modul zuverlässig per SW Reseten kann 
wenn es nicht mehr auf Befehle antwortet.

Danke...

Autor: jonathanarcher (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,
sorry, dass ich diesen alten Thread noch mal ausgrabe, aber ich habe zur 
Zeit praktisch das identische Problem. Habe das VDIP1-Modul auch über 
SPI an meinem LPC-2148 hängen und verwende die gleiche Vorgehensweise 
(VMUSIC-Demo, Open, Write, Close) und jedesmal hängt sich der VNC1L 
während dem zweiten Schreibzyklus auf (mitten drin, immer nach dem 
gleichen Datenbyte).
Ich wollte daher nur noch mal fragen, ob Andy das Problem mittlerweile 
lösen konnte. Wenn ich von monPrompt() auf monResponse() wechsle, 
verbessert sich nämlich leider nichts...

Autor: Wolfy (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Andy,
ich bin im Moment auch beim Vinculum und ihm beizubringen etwas auf den 
Stick zu schreiben.  Man sollte jedenfalls bei der Forschung nicht den 
Fehler machen gleich über µPs in dem Ding etwas zu bewegen. Mir hat das 
Br@y-Terminal-Programm dabei sehr geholfen, denn man sieht dort auch, 
dass die Mimik nach 'jedem' Befehl ein Prompt zurückschickt (etwa D:\>) 
oder eine Fehlermeldung. Die muss man wohl später, egal ob man über 
RS232 oder SPI mit einem µP arbeitet dort abfangen. Der Befehl WRF mit 
CR und die nachfolgenden abgezählten Bytes zählt dabei als EIN Befehl 
und der Prompt kommt dann erst danach. Probleme, dass es beim erstenmal 
tat und später beim x-ten-mal nicht mehr, gab es bei mir nicht.
Ich benutze Ver 03.68VDPSF über UART (9600 baud, usw.).
Gruß, Wolfy

Autor: Stefan G. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi, dieser Beitrag hat mir super geholfen! DANKE!

Noch ein kleiner Tipp für alle die das gleiche Problem haben, auch wenn 
der Thread schon ein wenig älter ist. Bei mir war das Hinderniss, dass 
ich nicht regelmäßig und händisch den TX Buffer des VNC1L abgerufen hab. 
Dadurch, dass ich eine Firmware mit Device Connect/Disconnect Meldungen 
hatte, sammelte sich dieser und war irgendwann voll. (Nach ca. 3-4 USB 
Steck- & CMD_DIR Versuchen auf ein File)

Also lieber die Antworten mittels monResponse abrufen als nur die 
prompts zu checken. Da werden die asynchronen Nachrichten gleich 
mitgeliefert und ausgelesen. Aber das hat Andy auch oben schon geklärt!

Danke!

Gruss Stefan

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.