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
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!
Wo in dieser Reihenfolge ist denn der zweite Durchgang? Wird ohne ! aus dem c ein a? Gruss Udo
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.
Also Du versuchst: Init ... ... open write close open write close open ... ... und der zweite write funktioniert nicht?
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?
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
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.
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
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)
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
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
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?
Hab soeben gesehen, dass ich mehr Probleme habe, wenn ich den Stick zwischendurch wieder entferne. Bleibt er immer gesteckt, kann ich mehrmals hintereinander schreiben.
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
@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
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.
>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
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
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.
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?
@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.
@ 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
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
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.
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.
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.
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.
@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ß.
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!)
@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...
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.
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!
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.
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...
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
Würde mich auch brennend interessieren. Hat sonst noch niemand dieses Problem gehabt und gelöst?
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...
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...
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
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
Thread beobachten
Seitenaufteilung abschaltenBitte 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.