Datum:
Ich habe in die Artikelsammlung einen Beitrag dazu eingestellt. http://www.mikrocontroller.net/articles/USB-Stick_... Dort steht auch der vollständige Quelltext zum Download bereit. Kurze Zusammenfassung: Eingesetzt wird ein USB-Hostcontroller, Typ VNC1L-1A von Vinculum/FTDI auf einem VDIP1-Modul. Firmware ist VDAP. Das Testprogramm ist in Ansi-C geschrieben, getestet einem auf 8051-System, sollte leicht auch auf andere Mikrocontrollerfamilen protierbar sein. Kommunikation erfolgt über SPI-Interface, damit behält man sich die wertvolle µC-UART für andere Anwendungen frei. Alle Funktionen können bei Bedarf auf einem LC-Display verfolgt werden. Die Software bietet alle Grundfunktionen, wie elementare SPI I/O-Routinen, Initialisierungen und das lesen & schreiben von Dateien auf den USB-Stick. Sicher gibt es noch Verbesserungsvorschläge, über die ich dankbar wäre.
Autor:
K. J.
(theborg0815)
Datum:
Hi haste ne Bezugsquelle für den Chip ? bei Reichelt kostet das teil 19eur :P Ansonsten saubere Arbeit.
Datum:
Können die den Controller nicht in DIL anbieten? Dieser SMD-Quatsch ist einfach nicht mit Lochraster kompatibel...
Datum:
@ Matthias K.
Wie lange dauert es etwa bis ein Befehl ("VF") ausgeführt wurde?
Da ich hin und wieder mp3-Files mit einer längeren Laufzeit (>45min)
habe, ist es natürlich recht umständlich in 5-Sekunden-Schritten bis zur
38. Minute zu "spulen" - deswegen die Frage.
Datum:
>Wie lange dauert es etwa bis ein Befehl ("VF") ausgeführt wurde? VF ist kein Kommando der VDAP-Firmware. Dazu müsste man auf dem VNC1L erstmal die VMSC Firmware flashen. Bisher habe ich mich nur mit VDAP beschäftigt. Es gibt aber auch fertige Module mit VMSC und MP3 Decoderchip, VMUSIC siehe hier: http://www.vinculum.com/prd_vmusic1.html
Datum:
> VF ist kein Kommando der VDAP-Firmware. Stimmt. Hatte ich nicht bedacht - sorry! > Es gibt aber auch fertige Module mit VMSC und MP3 Decoderchip Das weiß ich. Mich hätte nur vorab interessiert wie lange es dauert einen Befehl auszuführen. Ggf. kommt diese Lösung dann nämlich nicht für mich in Frage. Danke trotzdem!
Datum:
Hi, wie machst du das eigentlich mit der Initialisierung des VDIP1? So wie ich das verstanden habe, brauchst das Modul ja einige Zeit bis es den angesteckten USB Stick kennt(blinken der LED). Sendest du während des Erkennung des Sticks schon Daten?
Datum:
VDIP1 wrote: > wie machst du das eigentlich mit der Initialisierung des VDIP1? > So wie ich das verstanden habe, brauchst das Modul ja einige Zeit bis es > den angesteckten USB Stick kennt(blinken der LED). > Sendest du während des Erkennung des Sticks schon Daten? Nach dem Einschalten bzw. einem Hardware-RESET meldet sich das Mdoul mit der Firmware-Versions-Nr. und wartet auf das anstecken des Sticks oder falls er bereits angesteckt war, beginnt automatisch die Initialisierung. Wenn alles Ok, wird "Device Detect P2" gemeldet und das Prompt "D:\>" wird gesendet. Dieses Promt als Zeichekette mußt Du erwarten, dann ist das ganze System betriebsbereit. Siehe dazu das Video.
Datum:
Danke, alles klar. Ich hab bei meiner UART Routine nicht auf das Prompt nach dem Initialisieren gewartet, sondern sende gleich Befehle an das VDIP1 Modul. Ich glaub das könnte das Problem sein...
Datum:
Hallo, ich bin neu in der Mikrocontrollerprogrammierung und würde deine Schaltung gerne dazu benutzen um einen Datenlogger zu bauen. Das Board ist soweit fertig. Den Kern bildet ein Atmega16L, der über SPI mit dem VNC1L kommunizieren soll. Was sind denn die spezifischen Änderungen im Quelltext die vornehmen muss, damit erstmal dein Testprogramm laufen würde? Viele Grüße Andi
Datum:
SMD-Hasser schrieb: > Können die den Controller nicht in DIL anbieten? Dieser SMD-Quatsch ist > einfach nicht mit Lochraster kompatibel... Werde doch Bäcker!
Datum:
Hallo. Ich hab das Programm soweit auf meinem AT89C51RE2 laufen. Ich kann Dateien erstellen und Befehle senden usw, aber wenn ich was an eine vorhandene Datei anhängen will stürtzt das Ding ab. Ich hab schon versucht mit dem SEK-Befehl den Pointer von Hand an die richtige Position zu bringen, aber das war nciht erfolgreich. Laut Datenblatt reichts ja eigentlich wenn man den SEK-befehl ganz weglässt und so die letze Position im datei-pointer steht. Ich hab immo keine Ahnung mehr woran das liegen könnte.
Datum:
(Nicht SMD-Hasser...) Frank B. (frankman) schrieb: >SMD-Hasser schrieb: >> Können die den Controller nicht in DIL anbieten? Dieser SMD-Quatsch ist >> einfach nicht mit Lochraster kompatibel... >Werde doch Bäcker! Was hatn das damit zu tun? Er kritisiert einfach nur das die Hersteller nicht an die Bastler denken.
Autor:
Alex H.
(hoal)
Datum:
Bernd schrieb: > Was hatn das damit zu tun? > Er kritisiert einfach nur das die Hersteller nicht an die Bastler > denken. Ich glaube nicht, dass die Hersteller solcher Chips einen wesentlichen Umsatz mit Bastlern machen. Sieht man gerade daran, dass sie diesen Markt nicht bedienen. Insofern hat der Bastler nunmal das Los gezogen, sich den Bedingungen anzupassen. Wenn man dazu SMD löten muss, sollte man es halt lernen. Ansonsten gibt es auch fertige Adapter. Die sind dann wieder kompatibel mit Lochraster.
Datum:
>> Können die den Controller nicht in DIL anbieten? Dieser SMD-Quatsch ist >> einfach nicht mit Lochraster kompatibel... Nimm z.B. VDIP1 im DIL-Raster, ist sofort betriebsbereit, Bezug u.a. hier: http://www.watterott.com/VDIP1
Datum:
Christian M. schrieb in e-mail: >Ich habe deinen Quelltext benutzt, um einen Vdrive anzusteuern. Dabei >stellt sich das Problem,dass er zwar die Datei erstellt und füllt,wenn >ich aber nur Daten anhängen will bleibt er "hängen" und reagiert nicht >mehr. >Ich habe schon versucht nach dem erstellen einen neustart des Modules zu >machen, das hat aber zu keinem Erfolg geführt. >Vielleicht weisst du da was, denke es gibt da noch irgendwas, worauf man >achten muss, oder was man zusätzlich machen muss. Das Datenblatt ist da >recht ungenau. Im Troubleshootig schreiben sie dazu nur,dass die Länge >der Daten nicht stimmen würde, und er sich deshalb blockieren würde. Ich antworte mal hier. Das mit der exakten Anzahl der Byte beim schreiben ist ein Knackpunkt. Die Anzahl muss genau stimmen, sonst gibs Probleme. Timeout oder sowas kommt im Fehlerfall nicht. Probier doch mal, die Anzahl testweise als feste Zahl vorzugeben und nicht berechnen zu lassen. Mit VDRIVE habe ich es allerdings nicht probiert.
Datum:
Habe mir das APPEND-Problem nochmal angesehen und denke das Problem gefunden zu haben. Ohne den "SEK" Befehl wurde vergeblich auf das PROMPT gewartet. Probier es mal hiermit:
// *********************************************************************** // VNC1L - Erzeugen eines Text-Files auf dem USB-Stick // Übergabe: filename : Adresse des Filenamen // fileinhalt : Adresse des Textblockes // funktion : File 0=Neu oder 1=Inhalt anhängen // *********************************************************************** void vnc_wr_txtfile(byte *filename, byte *fileinhalt, byte funktion) { word vnc_i; word filelen, filecr; byte *fileptr; byte batch_wr = 0; // Byte-Anzahl berechnen fileptr = fileinhalt; filelen = 0; filecr = 0; while (*fileptr != 0xFF) { if (*fileptr) filelen++; else filecr++; fileptr++; } // 1. Promptzeichen liegt bereits vor do { switch (batch_wr) { // Batchprozess case 0: // File Öffnen bzw. Erstellen sprintf (&vnc.send_buffer[0],"OPW %s",filename); vnc_wr_cmd(vnc.send_buffer); break; case 1: // File Position bei Bedarf auf Anfang setzen if (!funktion) { vnc_wr_cmd("SEK 0"); break; } else batch_wr++; // Nun wird sofort auch noch case 2: ausgeführt case 2: // File Byteanzahl sprintf (&vnc.send_buffer[0],"WRF %d",filelen); vnc_wr_cmd(vnc.send_buffer); fileptr = fileinhalt; for(vnc_i = 0; vnc_i < (filelen + filecr); vnc_i++) { if (*fileptr) vnc_wr_byte(*fileptr); // NULL-Terminierung ausblenden fileptr++; } break; case 3: // File schließen sprintf (&vnc.send_buffer[0],"CLF %s",filename); vnc_wr_cmd(vnc.send_buffer); break; } // Switch delay_ms(500); // Pause batch_wr++; // nächster Schritt if (batch_wr == 4) return; // Fertig } while (vnc_rd_answer(PROMPT_UND_ERROR_CHECK) == PROMPT_OK); // Prüfung auf nächstes Promptzeichen > } // Aufruf zB. mit: vnc_wr_txtfile("VNCFILE1.TXT",file1[0],FILE_APPEND); // File Append |
Datum:
Ich nehme an, der ELV-Bausatz enthält ebenfalls den Vinculum: http://www.elv.de/output/controller.aspx?cid=74&de... USB-Stick-Interface STI 100, Komplettbausatz Artikel-Nr.: 68-759-50 37,95€
Datum:
>Ich nehme an, der ELV-Bausatz enthält ebenfalls den Vinculum: ja, VNC1L Schaltplan vom ELV_Modul konnte ich nicht finden. Sieht nach einem VDRIVE1 Nachbau aus: http://www.vinculum.com/prd_vdrive1.html (VDRIVE1 ist praktisch kaum noch zu bekommen, nur als OEM). Firmware dürfte auch VDAP sein. Bsp.-Software ist für UART-Nutzung geschrieben.
Datum:
Ja ich habe die ELV 5/07 und 6/07, da ist auch das Schaltbild. VNC1L, 3,3V- Spannungsregler (Typ HT-7533, kenne ich nicht), 12MHz-Quarz, PTC-Sicherung in der 5V-Leitung von der USB-Buchse, zwei 22µH-Drosseln in derselben Leitung, drei LEDs und einige R und C, das ist alles. Programmierjumper, Jumper UART/SPI und ein weiterer nicht näher genannter Jumper, der immer auf Vcc stehe sollte und gleichzeitig Pin 36 und 45 des Vinculum versorgt.
Datum:
Wenn man "Case 1" aus deinem Quelltext herauskommentiert, dann funkioniert das Anhängen. Haben es gerade ausprobiert.
Datum:
Hallo Ich hab mich auch mal an das Thema rangewagt. Aber bei mir funktioniert es nicht. Das Programm läuft nach einigen Versuchen jetzt soweit. Aber auf dem USB-Stick wird keine Datei geschrieben. Beim einschalten Blinken die beiden LED's auf dem VDIP1 Modul 2x abwechselnd. Und danach nie wieder. Sind das Date Sende und Empfangs "anzeigen" und kann ich davon ausgehen das dann keine Daten vom µC zum Modul gelangen? würde mich über Infos freuen. P.S. bei dem Musterprojekt würden die Original Pin's von der SPI Schnittelle genutzt. Das ist doch sicher nur Zufall. So wie ich den Code gelesen hab kann man die Kanäle jedem PIN zuordnen. Oder liege ich da falsch? mfg LPT
Datum:
Ach ja eine Frage hab ich noch! Wieso eigentlich eine Virtuelle SPI Schnittstelle. Kann man nicht eine (die) Normale Hardware- Schnittstelle nehmen? mfg LPT
Datum:
"Nicht vergessen, die Jumper J3 und J4 des VDIP1-Moduls auf SPI zu stecken!" Hast Du sicher gemacht? Welchen µC hast Du verwendet? Die SPI ist in Software realisiert, weil es ein spezielles Protokoll ist (13Bit), was mit den üblichen SPI-Verfahren nicht viel zu tun hat. Lässt sich nicht mit der Hardware-SPI realisieren, zumindest nicht beim AT89C51ED2. Die Pins kannst Du frei zuordnen.
Datum:
Danke für die schnelle antwort. Erst mal zu deiner Frage ich arbeite mit einem ATmega644. Und die Jumper sind gesteckt. Irgendwie war dein Programm bei mir nicht lauffähig. Hab des hab einiges ändern müssen, wie zB. die Zuweisung zu dem Kanälen. P1_1 geht bei mir nicht, bin jetzt bei #define R_SCLK PORTB &= ~(1<<PIN0) #define S_SCLK PORTB |= (1<<PIN0) und das für jeden Kanal. Mit deinen Funktionsnamen kann ich nicht zurecht also auch dort mal etwas ins Deutsche übersetzt und die Gliederung etwas angepasste. Klammern in neue Zeilen und so’n Zeug. Damit ich es besser verstehe. Das sollte aber eigentlich nicht das Problem sein. Aber es passiert nix müssen den die LED's Blinken beim beschreiben? Ich hab gerade mal mein Oszilloskop rangehalten. Die gute Nachricht ist der Reset funktioniert offenbar. Zumindest reagiert das VDIP auf mit einem Reset wenn ich an den Kanal komme. Aber ansonsten hab ich keine Impulse auf den Leitungen. Dafür aber 3V Gleichspannung. Der AVR arbeite noch mit 1MHz Internem Takt aber das ist ja auch kein Problem bei einer SPI. Mir gehen so einmählich die Ideen aus. Kann vielleicht etwas kaputt sein? Ich hatte erst die Kanäle 0-4 vom PortC verwendet. Aber bei der Fehlersuche hab ich festgestellt das die Kanäle 2-5 nicht mehr reagieren. Aber ich weiß nicht seit wann schon. Ich hoffen mal das da nix am VDIP kaputt gegangen ist. Vertaucht oder Verpolt hatte ich nix. Jetzt hängt das Modul am PortB. mfg LPT
Datum:
>Erst mal zu deiner Frage ich arbeite mit einem ATmega644. >Irgendwie war dein Programm bei mir nicht lauffähig. >Hab des hab einiges ändern müssen, wie zB. die Zuweisung zu dem Kanälen. >P1_1 geht bei mir nicht, bin jetzt bei >#define R_SCLK PORTB &= ~(1<<PIN0) >#define S_SCLK PORTB |= (1<<PIN0) Das C-Programm im Beitrag läuft auf einen 8051er. Der hat Bitbefehle, welcher der AVR nicht kennt. Musst es entsprechend anpassen, kein Problem, nur da kann ich Dir nicht gross helfen. >Aber ansonsten hab ich keine Impulse auf den Leitungen. Elementare Voraussetzung VDIP ist recht robust, geht so schnell nicht kaputt.
Datum:
Narbend Eine Frage hab ich noch. Diese sprintf Befehle sind doch sicher für das Display. Oder irre ich mich da. sprintf (&sende_buffer[0],"CLF %s",filename) Ich werde daraus nicht so ganz schlau. Einerseits sprintf was soweit ich weiß für Monitor Geschichten ist. Und andererseits der Befehl CLF der für das VDIP1 Modul ist. Vielleicht kannst Du mir das noch mal erklären? mfg LPT
Datum:
Das Projekt ist nicht als Einstieg geeignet. Du solltest erstmal mit den C-Grundlagen anfangen und Dir ein µC-Basiswissen aneignen. Hier findest schon sehr viel (AVR Tutorial): http://www.mikrocontroller.net/articles/Hauptseite >sprintf (&sende_buffer[0],"CLF %s",filename) Gibt nichts auf dem Display aus, sondern schreibt CLF und den Filenamen in den sende_buffer ab Position 0.
Datum:
Hallo ich bin es noch mal. Das mit dem C-Programmieren ist so eine Sache. Ich hab es damals auf der PC (DOS) Ebene kennensgelernt ist aber noch nicht solange her. Und meiner Meinung nach ist es auf der Objektorientierten Ebene etwas komplexer kommt mir zumindest so vor.. Aber Du hast recht und hätte ich mal im Buch nachgeschlagen und nicht auf mein alt"wissen" zurückgegriffen hätte ich auch rausgefunden. Das mit dem von vorne anfangen und langsam rantasten mache ich ja schon seit ein paar Monaten, allerdings muss mein Projekt vorankommen (da der Abgabetermin steht) und dafür brauch ich nun mal das Modul. Ich bin jetzt soweit das Datentransfer auf den Leitungen statt findet aber beim Verbindung Prüfen [vnc_rd_answer()] Bekomme ich als Rückgabewert im lese_buffer [vnc.rec_buffer[0] immer 0x00 übergeben. Und eine Fehlercode Tabelle finde ich im Datenblatt nicht. Kannst Du mir da noch mal einen Tipp geben wie ich jetzt weiter komme. Danke schon mal im Voraus. mfg LPT
Datum:
Zeigmal den Quellkode, möglichst komplett. >Bekomme ich als Rückgabewert im lese_buffer [vnc.rec_buffer[0] >immer 0x00 übergeben Die SPI Kommunikation dürfte noch nicht richtig funktionieren, Du liest vermutlich noch nichts ein, deshalb 0x00
Datum:
Angehängte Dateien:Hab jetzt mal etwas Zeit zum Googlen gehabt. Jetzt hab ich auch ein paar Kurzanleitungen auf Deutsch gefunden. Und viele Unser die Viele Probleme damit haben. Die Datei hab ich mal angehangen. Ich hab dir mal schnell etliche rauskommentierte Versuche und LED anzeigen gelöscht ich hoffe das dabei keine Klammer zuviel weg ist. Großen Dank schon mal für deine Hilfe. mfg LPT
Datum:
>#define SDO_VDIP PINB &= ( 1<<PIN4) Das dürfte so nicht funktionieren. Dein Programm ist außerdem für die Erstinbetriebnahme viel zu komplex. Versuch doch erstmal alles unwesentliche auszubauen und zunächst nur das was von VNC1L kommt zu empfangen. Der legt nach Reset sofort mit dem Senden von Statusinformationen los. Dieser Vorgang endet mit den Senden eines Prompt ('>') gefolgt von CR (0x0D). Erst danach kann die eigentliche Kommunikation beginnen. Also alle Byte empfangen und wenn ein > dabei ist, zB. eine LED anschalten. Besser wäre es allerdings, wenn Du ein LCD, zumindest testweise mal anschliessen könntest.
Datum:
Hier ist noch ein interessantes Video zur Verdeutlichung der VNC1L Funktionsweise: http://www.youtube.com/watch?v=r3fF48pI0Wo Läuft hier zwar mit einen Terminalprogramm über UART, per SPI ist die Endfunktion aber gleich.
Datum:
Matthias schrieb: >>#define SDO_VDIP PINB &= ( 1<<PIN4) > > Das dürfte so nicht funktionieren. Danke für den Tipp ich hätte schwören können dass das so funktioniert. Aber war auch das erste mal das ich über define auf Ein/Ausgänge zu greife. Ich hab es jetzt über eine Funktion realisiert. Jetzt hab ich auch Werte im Buffer. So wie ich es auf den LED's gesehen hab sind es immer die gleichen 5Byte die empfangen werden. Display wäre sicher schön aber ich muss (nee will es erst mal) so hinbekommen. Keine Zeit und kein Geld für zusätzliche Experimente. Aber vor allem halt keine Zeit. Morgen bzw. Mi werde ich mal weiter suchen wo es jetzt hängt. Weil eine Datei hab ich immer noch nicht auf dem Stick. Bis dahin heißt es BWL büffeln. mfg Und Danke noch mal LPT
Datum:
Hier ein absolutes Minimalprogramm zum testen der Kommunikation zwischen VNC1L und µC per SPI. Zur Signalisation reicht eine LED. Wenn diese etwa im Sekundentakt blinkt, ist alles ok. Details siehe im Programm.
//************************************************************************ // ATmega644 zu VDIP1 über SPI //************************************************************************ // Das Programm testet die Kommunikation zwischen dem MC und dem VNC1L // bzw. VDIP1-Modul per SPI-Schnittstelle. Dazu wird die Echo-Funktion // benutzt. Ein E + CR wird zum VNC1L gesendet. Dieser sendet das // E + CR als Echo unmittelbar zurück. // Zu Beginn wird die Bereitschaft des VNC1L abgewartet. Der sendet // nach dem Reset einige Statusinformation zur geladenen Firmware und // ob ein USB-Stick eingesteckt und erkannt wurde. Der Vorgang endet // mit dem Senden eines > (Prompt) gefolgt von CR. Danach ist der // VNC1L zur weiteren Kommunikation bereit. // Hinweis: Es muss ein USB-Stick angesteckt sein!!! // Wenn alles OK ist, sollte die LED nach ca. 5 Sekunden mit blinken, // etwa im Sekundentakt beginnen. #define F_CPU 1000000UL #include <avr/io.h> #include <string.h> #include <stdio.h> #include <stdlib.h> #include <util/delay.h> //************************************************************************ // Definebereich VDIP1 //************************************************************************ // Ports anpassen!!!! #define R_SCLK PORTB &= ~(1<<PIN6) /* P1_6 */ #define S_SCLK PORTB |= (1<<PIN6) #define R_SDI PORTB &= ~(1<<PIN7) /* P1_7 */ #define S_SDI PORTB |= (1<<PIN7) #define SDO_VNC (PINB & (1<<PIN5)) /* P1_5 zum einlesen */ #define R_CS_VNC PORTB &= ~(1<<PIN0) /* P1_0 */ #define S_CS_VNC PORTB |= (1<<PIN0) #define R_RE_VNC PORTB &= ~(1<<PIN1) /* P1_1 */ #define S_RE_VNC PORTB |= (1<<PIN1) #define R_LED_D1 PORTA &= ~(1<<PIN7) /* P0_7 */ #define S_LED_D1 PORTA |= (1<<PIN7) #define PORT_DEFS DDRA = 0xFF; DDRB = 0xDF /* Ports anpassen!!!! */ // Typendefinition typedef unsigned char byte; typedef unsigned int word; typedef unsigned long dword; // Variablenbereich byte read_e, read_cr; // *********************************************************************** // VNC1L - USB HOST CONTROLLER - SPI-MODE (MC: Master, VNC1L: SLAVE) // VDIP1: Jumper-Set: J3 - Pulldown / J4 - Pullup // VDAP Firmware muss installiert sein, mit Version 3.68 getestet // *********************************************************************** // *********************************************************************** // VNC1L - Intialisierung SPI-Interface und VNC1L // SPI Mode // *********************************************************************** void vnc_init(void) { R_CS_VNC; // SPI-Interface inaktiv R_SCLK; // Ruhezustand der SPI-Leitungen herstellen S_SDI; R_RE_VNC; // Hardware-Reset VNC1L _delay_ms(100); // Pause S_RE_VNC; // VNC1L starten } // *********************************************************************** // VNC1L - Senden eines Zeichens // SPI Mode // Übergabe: wr_byte : Auszugebendes Zeichen // Rückgabe: statusbit : 0=Accept (ok) 1=Reject (nicht ok) // *********************************************************************** byte vnc_wr_byte(byte wr_byte) { byte stelle, status; S_CS_VNC; // SPI-Interface aktiv S_SDI; // Startbit (immer 1) S_SCLK; R_SCLK; // L/H Flanke R_SDI; // RW-Bit (0=Write) S_SCLK; R_SCLK; // L/H Flanke R_SDI; // ADDR (0=Daten) S_SCLK; R_SCLK; // L/H Flanke // 8 Datenbits senden (MSB zuerst) for ( stelle = 0x80; stelle; stelle >>= 1 ) { if (wr_byte & stelle) S_SDI; else R_SDI; S_SCLK; R_SCLK; // L/H Flanke } // Statusbit einlesen status = SDO_VNC; // Statusbit (0=Accept, 1=Reject) // hier sollte jetzt Prüfung von status erfolgen!!! S_SCLK; R_SCLK; // L/H Flanke // End Sequenz R_CS_VNC;; // SPI-Interface inaktiv S_SCLK; R_SCLK; // L/H Flanke _delay_ms(100); // Pause nur zum Test return status; } // *********************************************************************** // VNC1L - Empfangen eines Zeichens // SPI Mode // Rückgabe: Datenbyte // *********************************************************************** byte vnc_rd_byte(void) { byte stelle, daten, status; daten = 0; S_CS_VNC; // SPI-Interface aktiv S_SDI; // Startbit (immer 1) S_SCLK; R_SCLK; // L/H Flanke S_SDI; // RW-Bit (1=Read) S_SCLK; R_SCLK; // L/H Flanke R_SDI; // ADDR (0=Daten, 1=SPI-Statusinformation) S_SCLK; R_SCLK; // L/H Flanke // 8 Datenbits empfangen (MSB zuerst) for ( stelle = 0x80; stelle; stelle >>= 1 ) { if (SDO_VNC) daten |= stelle; S_SCLK; R_SCLK; // L/H Flanke } // Statusbit einlesen status = SDO_VNC; // Statusbit (0=New Data, 1=Old Data) // hier sollte jetzt Prüfung von status erfolgen!!! S_SCLK; R_SCLK; // L/H Flanke // End Sequenz R_CS_VNC; // SPI-Interface inaktiv S_SCLK; R_SCLK; // L/H Flanke _delay_ms(100); // Pause nur zum Test return daten; } // ******************************************************************** // Hauptprogramm // ******************************************************************** int main (void) { PORT_DEFS; // Portdefinition vnc_init(); // VNC1L-Initialisierung // VNC1L Bereitschaft abwarten indem auf > und CR geprüft wird while(vnc_rd_byte() != '>'); vnc_rd_byte(); // CR nach dem > jetzt noch abholen // VNC1L hat Promptzeichen > gesendet und kann jetzt neue Kommandos annehmen while(1) { S_LED_D1; // LED aus vnc_wr_byte('E'); // Echo senden vnc_wr_byte(0x0D); // CR senden _delay_ms(500); // Pause read_e = vnc_rd_byte(); // Echo empfangen read_cr = vnc_rd_byte(); // CR empfangen if ((read_e == 'E') && (read_cr == 0x0D)) R_LED_D1; // LED ein wenn Echo empfangen wurde _delay_ms(1000); // Pause } } |
Datum:
So jetzt hab ich wieder etwas Zeit zum weiter probieren. Ich hab mit dem großem Programm weiter gearbeitet. Aber ich nehme jede Funktion einzeln in Betrieb. Die Gute Nachricht ist ein Echo bekomme ich. Ich kann Byte und Strings senden und das Daten empfangen und im Buffer ablegen funktioniert auch. Aber Ein Echo bekomme ich nur wenn ich vorher am VDIP Modul ein Reste durchführe. Und dann bekomme ich nur ein Echo ein mal zurück. Anschließend bekomme ich nur die Meldung Modul Bereit D:\> Das ist doch sicher nicht normal oder? mfg LPT
Datum:
Ist es möglich an diesem Versuchsaufbau/ diesr Schaltung noch eine SD Karte anzusprechen ? Würde gerne Datein auf der SD Karte mit denen auf dem USB Stick vergleichen. Bin noch Anfänger ^^. Habe mich schon belesen nur ist mein Problem das die SD Karte und der USB Controller ja beide zB. MISO und MOSI benötigen. Gibts nen Trick ? Danke im Vorraus
Datum:
>Aber Ein Echo bekomme ich nur wenn ich vorher am VDIP Modul ein Reste >durchführe. Und dann bekomme ich nur ein Echo ein mal zurück. E(cho) senden und empfangen muss immer gehen, wenn der VNC Online ist, also ein Prompt > gesendet hat. Dann kann er wieder neue Kommandos aufnehmen. Siehe Bsp. davor, da läuft das Echo senden und empfangen auch in einer Endlosschleife, ohne Reset dazwischen. Vermutlich stimmt Dein Timing oder die Sende-Empfangssequenzen noch nicht ganz.
Datum:
So ich hab jetzt noch mal ein Neues Projekt geöffnet und dein "Kurzprogramm" rein gespielt. I/O Ports angepasst und für den SDO eine Funktion geschrieben damit ich nicht wieder das selbe Problem hab wie am Anfang. Was soll ich sagen die LED Blinkt. Das Programm hab ich schon so hingerückt das die Optik mir wieder etwas vertrauter vor kommt. Und es funktioniert immer noch. :-) Jetzt werd ich mal die beiden Codes Parallel lesen. Der Fehler muss doch zu finden sein. Nochmals Danke für deine Geduld. mfg LPT
Datum:
>Habe mich schon belesen nur ist mein Problem das die SD Karte und der >USB Controller ja beide zB. MISO und MOSI benötigen. >Gibts nen Trick ? Ist kein Problem. Du kannst die Portpins für den VDIP1 auch auf andere µC-Pins legen. Die SPI-Funktionen werden ohnehin per Software nachgebildet. Damit hättest Du die Hardware-SPI frei für Deine SD-Card. 2. Variante: MISO/MOSI/SCK der SPI-Schnittstelle können auch an mehrere Teilnehmer parallel angeschlossen werden. Wichtig ist, dass dann immer nur ein Teilnehmer mit CS adressiert wird. Die anderen fühlen sich nicht angesprochen. Bedenke noch, dass SD-Card keine 5V verträgt. @lpt: >Was soll ich sagen die LED Blinkt. >Das Programm hab ich schon so hingerückt das die Optik mir wieder etwas >vertrauter vor kommt. Und es funktioniert immer noch. :-) >Jetzt werd ich mal die beiden Codes Parallel lesen. >Der Fehler muss doch zu finden sein. Dann kannste zumindest Hardwarefehler ausschliessen. >while(antw = 1) Kuck nochmal, ob Du dass schon in Deinem Ursprungsprogramm geändert hast, aus der Schleife kommst Du nie wieder raus! --> while(antw == 1)
Datum:
Jetzt hab ich es fast geschafft. Ich hab zwar keinen Fehler im Alten Code gefunden aber noch einigen Rückschlägen hab ich es geschafft aus dem keinem Programm was richtiges zu machen. und anscheint sogar Fehlerfrei. Bist Du dir Sicher mit dem While (antw = 1) Aus meiner Sicht wird der Variablen "antw" wenn man das so schreibt eine 1 zugewiesen und das erbebt dann eine Endlosschleife. mit dem antw == 1 funktioniert es auf jeden fall. mfg LPT
Datum:
>Bist Du dir Sicher mit dem >While (antw = 1) So gesehen ja. Das macht man dann besser so, ohne Variable zu opfern: While (1) { ...... } oder so wenn Abbruch irgendwann erforderlich ist: antw = 1; While (antw) { if (bedingung erfüllt) antw = 0; // dann wird Schleife beendet }
Datum:
Jetzt weiß ich erst was Du meinst. Da haben wir wohl etwas an einander vorbei geschrieben. Dabei meinten wir das gleiche. Es ist Richtig das man eine Abfrage mit == schreibt das mit dem „While (antw = 1)“ war wenn ich mich recht erinnere nur um besser die Signale mit dem Oszilloskop messen zu können. Irgendwie hattest Du schon recht das Programm ist nicht für Anfänger. Vom Prinzip her verstehe ich ja jede Zeile des Codes. Bloß die Feinheiten scheine ich meistens zu übersehen. Aber kaum hat man ein Problem gelöste tauchen 2 neue auf. Ich hab es jetzt soweit das Strings gesendet werden können. Die Funktion für Verbindung Prüfen ist OK hab’s sogar noch wegen der Echoprüfung erweitert. Es wird auch das VDIP1 Modul erkennt die Befehle kommen durch und es wird auch eine Datei auf dem Stick angelegt Allerdings werden keine Daten darin gespeichert. Und das obwohl der µC etwa 10s braucht um den Befehl Bin_Daten_Schreiben Abzuarbeiten. Ich dachte schon das ich die Zeiger falsch zuweise aber das müsste so stimmen. Muss ich vielleicht von IPA auf IPH umschalten bevor ich Binäre Dateien beschreibe? Aber so wie ich die Befehlsliste verstanden hab ist IPA und IPH für die Art der Befehls Sätze. Außerdem hab ich noch ein paar Grundlegende Fragen. Ich will eigentlich Zahlenwerte speichern und das ohne sie vorher in ASCII Zeichen zu wandeln. Dafür bietet sich ja der Binäre Modus gerade zu an. Aber die Datenmenge ändert sich je nach Laufzeit und Abtastrate. Beim anlegen der Bin-Datei muss man aber eine Datenlänge angeben. Ist das die Bytemenge der aktuellen Übertragung? Oder die Absolute Menge? Kann ich über "SEK x" an das Ende der Datei springen und jeder Zeit weitere Daten ranhängen. Jeder Sektor ist dann wahrscheinlich 1Byte groß, dann braucht man nur mitzählen wie viele Daten man schon gesendet hat und die Zahl dann übergibt. mfg LPT
Datum:
Hallo allerseits, vor einiger Zeit habe ich mir Routinen für den VDIP geschrieben, die allerdings via RS232 zugreifen. Die Entwicklung war mühsam, da nur sehr am Rande beschrieben wird, das die Angaben wie 115200 Baud und 12MHz SPI absolut nicht alltagstauglich sind. Im praktischen Betrieb macht der VDIP bei mehr als 19200 Baud dicht. Den Beitrag von Matthias vom 27.10. habe ich zum Anlass genommen, meine bislang nicht erfolgreichen Versuche, auf die SPI-Schnittstelle umzusteigen, noch einmal zu aktivieren. Zwei Dinge - an denen ich gescheitert bin - sind mir aus dem Beispiel von Matthias als wichtig klar geworden: 1.) Bei Programmstart alle Daten bis zu einem RETURN verwerfen (das sind die Einschaltmeldungen etc.) Und dann für die Angst noch einmal 1 Sekunde alles einlesen. Dann mit einem Synch die Bereitschaft testen. 2.) Nach dem Senden eines Kommandos lange Pausen eingelegt. Dadurch blieb im Misserfolg erspart. Denn ein Fehler steckt in den SPI-Routinen: das Status-Flag wird nicht ausgewertet. Werden Daten abgeholt - die aber noch nicht bereitstehen - dann ist Frust angesagt. Ich habe die spi_write() und spi_read() so aufgebaut, dass sie je nach Erfolg TRUE oder FALSE zurückliefern. Ein empfangenes Byte wird via globaler Variable übergeben. Die Senderoutine hat eine eigene Schleife, die den Sendeversuch bei Misserfolg wiederholt. Wenn man jetzt while (!(spi_read()); schreibt, hat man eine Warteschleife, die solange liest, bis wirklich Daten vom VDIP bereitgestellt sind. Überhaupt erscheint es mir im Moment sinnvoll, den Datenfluss erst einmal mit geringer Geschwindigkeit in den Griff zu bekommen. Bei mir gelingt es inzwischen, Verzeichnisse und Dateien anzulegen, zu löschen, Inhaltsverzeichnis bzw. Dateigröße auszulesen. Allerdings scheitere ich noch daran, in eine geöffnete Datei zu schreiben (obwohl das via RS232 immer funktionierte). Wenn ich die grundliegenden Funktionen fertig habe, werde ich den Code mal bereitstellen. Ziel meiner Übung ist es übrigens, einen Datenlogger auf der Basis eines M88 zu bauen, der die Daten via RS232 und TWI entgegenehmen kann, in einem Ringpuffer speichert und in 512Byte Blöcken auf den Stick schreibt. Michael S.
Datum:
So ich glaub ich geb es für heute auf. 10 Stunden sollten reichen. Und nix geschafft. Die Datei die noch von ein paar Stunden erzeugt wurde und ohne Inhalt war, hatte die Endung .BIN . Nach dem ich in der Funktion Verbindung Prüfen mit einer if abfrage rumgespielt habe hat die gleiche Datei plötzlich die Endung .BIS . Änderung wieder zurück und Datei wieder .BIN . Das ging dann ein paar mal hin und zurück weil ich die Funktion der Schleife irgendwie haben wollte. Jetzt verzichte ich auf die if Abfrage. Alles wieder original Aber die Datei hat jetzt auch bei jedem erzeugen die Endung .BIS . Ich glaub die der Controller hat was geben mich. Ich sollte vielleicht lieber bei der Elektronik bleiben und mich von der Software fernhalten. Auch wenn es jetzt dafür etwas zu spät ist. mfg LPT
Datum:
Ich kann es doch nicht lassen. Jetzt hab ich den Code Parel gelesen mit dem vom Backup das 4 Stunden älter ist einziger unterschied. In der Aktuellen Version ist ein delay länger, die Kommentare sind anders und die Funktion Test_file_schreiben gibt es noch nicht. Alte Datei getestet alles OK Aktuelle Datei getestet auch alles OK. Hab es jetzt 3 mal durchlaufen lassen jedes mal gibt es keine Fehler. Aber ich bekomme immer noch keine Daten in die Binäre Datei geschrieben. und mit dem Text schreiben scheint auch noch was nicht zu stimmen. @ Matthias Hat es eigentlich einen Grund warum Du bei der Funktion vnc_wr_txtfile um den Befehl "strlen" einen riesen Bogen machst. Und statt dessen mit filelen und filecr die Länge ermittelst? mfg LPT
Datum:
>Hat es eigentlich einen Grund warum Du bei der Funktion >vnc_wr_txtfile >um den Befehl "strlen" einen riesen Bogen machst. >Und statt dessen mit filelen und filecr die Länge ermittelst? C-Grundlagen! Bei den Textdaten handelt es sich um ein Zeigerfeld. Jede einzelne Zeichenkette (Zeile) endet mit einen 0x00. strlen würde nicht die Gesamtlänge aller Zeichen liefern, sondern nur bis zur ersten 0x00. Ich habe das Original-Programm vom 8051 nun auf einen ATmega laufen. Txtfile, Binärfile Schreiben und lesen klappt soweit. An paar Details arbeite ich noch. Ich lade es vielleicht schon morgen hoch.
Datum:
Den Beitrag in der Artikelsammlung habe ich überarbeitet und neue Software (siehe Projektarchiv bei Links/Download) hochgeladen. http://www.mikrocontroller.net/articles/USB-Stick_... Neu ist jetzt eine AVR/GCC-Version. Getestet mit einem ATmega644 (andere möglich), VDIP1 mit VDAP-Firmware 3.68. Zum Betrieb kann optional ein LCD angeschlossen werden (zur Inbetriebnahme sehr zu empfehlen). Die Software zeigt die grundlegende Kommunikation mit dem VNC1L per SPI, schreibt ein Text-File sowie ein Binär-File auf den USB-Stick und zeigt wie ein File vom USB-Stick eingelesen werden kann. Gegenüber der ursprünglichen Version (8051), sind in die AVR-Version einige Verbesserungen zur Stabilität und Erfahrungen aus der Diskussion eingeflossen. Die 8051er Version ist noch unverändert enthalten. Der Schaltplan befindet sich auch auf der Artikelseite. Weiterhin ist eine einfache Testsoftware für die Erstinbetriebnahme (AVR) enthalten. Dabei wird nur die elementare Kommunikation zwischen µC und VNC1L, durch E(cho)-Kommandos getestet. Das Programm sollte man zum Einstieg als Erstes verwenden. Danach kann man ziemlich sicher sein, dass der grundlegende Datenaustausch in Ordnung ist.
Datum:
Angehängte Dateien:Hallo allerseits, wie ich sehe, seid ihr noch nicht viel weitergekommen. Gestern hatte ich darauf hingewiesen, dass der VDIP krötenlangsam ist. Wenn ihr meint, dass nach dem Schreiben eines Kommandos die Antwort bereits vorliegt, dann irrt ihr gewaltig. Darum muss beim Lesen/Schreiben das Statusbit getestet werden. Natürlich kann man statt dessen auch eine 500ms Pause einlegen. Effizienter ist aber der andere Weg, nämlich zu prüfen, ob wirklich schon gültige Daten (beim Lesen) anliegen. Ich füge einmal meine geringfügig geänderte Routinen zum Lesen und Schreiben via SPI bei. Und die Initialisierung, in der man die Einschaltmeldung in einem Puffer zwischenspeichert und als Textstring ausgeben kann. Vielleicht hilft es ja weiter. Mir hat zumindest euer Beitrag geholfen, den Knoten im Hirn zu zerschlagen. Bei mir funktionieren jetzt alle Dateioperationen sowie Lesen und Schreiben von Daten. Noch die Frage: Warum differenziert ihr zwischen Textdaten und Binärdaten ? Ist doch für den VDIP egal, was er speichert. mfg Michael S.
Datum:
Hallo Matthias K. eben habe ich mir dein aktuelles Projektarchiv noch einmal angesehen. Weil mir nicht klar war, warum dein Code überhaupt funktionieren kann. Und was sehe ich da ? Überall _delay_ms(x). Also hast du das Problem durchaus erkannt - aber durch Zeitverzögerungen gelöst. Welche Datenübertragungsraten bleiben denn da am Ende übrig ? Wirf mal alle delays raus (naja fast alle, Endlosschleifen soll man ja auch verhindern dürfen). Statt dessen ändere deine SPI-Routine. Und du wirst erstaunt sein, wie einfach das Leben sein kann. mfg Michael S.
Datum:
>Gestern hatte ich darauf hingewiesen, dass der VDIP krötenlangsam ist. >Wenn ihr meint, dass nach dem Schreiben eines Kommandos die Antwort >bereits vorliegt, dann irrt ihr gewaltig. Das ist bekannt, betrifft aber im wesentlichen nur die Antwort auf gesendete Kommandos. Beim senden von Daten kann man ihn flott beschicken. Hohe Erwartungen an den Datendurchsatz darf man bei diesen Verfahren insgesamt nicht stellen. Im Gegenzug sind keine Kenntnisse von FAT usw. nötig. Für Datenlogger-Aufgaben, oder Parameterübergaben ist es jedoch ausreichend. >Überall _delay_ms(x). Nur bei Kommandos. Das eigentliche Datensenden geht wie schon gesagt (fast) ohne delays. Ich schau mir Deine Routinen noch genauer an und versuche sie einzubauen. Die Timerverwendung gefällt mit nicht besonders, um es kompatibel für andere µC zu halten. >Noch die Frage: Warum differenziert ihr zwischen Textdaten und >Binärdaten ? Ist doch für den VDIP egal, was er speichert. Dem VNC ist es egal. Es ist nur eine Handlingsache im Programm. Da gibt es sicher mehrere Lösungen. Meine ist nur ein Beispiel.
Datum:
Hallo Matthias K. deinen Programmcode habe ich mir noch ein weiters mal angesehen. Es sind mehrere _delay_ms(100) vorhanden. Die Verzögerungszeiten sind durch Ausprobieren entstanden. Es besteht keine Garantie, dass die Zeiten immer ausreichen. Als Ausgleich dafür werden sie in der Regel zu lang sein. Während man die delays noch als Geschmacksfrage sehen mag, ist das Fehlen einer Fehlerbehandlung beim Schreiben und Lesen via SPI schon bedenklich. Eine leuchtende LED kann ja wohl noch nicht alles sein. Im Manual wird empfohlen, die Statusbit zu prüfen und ggf. eine neues Senden/Schreiben zu initieren. Kann ich auch nur empfehlen. Dann kannst du deine delays ins Wochende schicken. Und Lese-Schreib-Fehler werden auch abgefangen. Aber du selbst wissen, was nach deiner Meinung der richtige Weg ist. Der jetzige erscheint mir allerdings suboptimal. Dennoch schönen Dank für deinen Beitrag, er hat mich weitergebracht. mfg Michael S.
Datum:
http://www.mikrocontroller.net/articles/USB-Stick_... Ich habe jetzt auf Grund der Hinweise von Michael S. praktisch alle Delays eliminiert und komplett auf Abfrage der Statuszustände des VNC1L umgestellt. Hat sich wirklich gelohnt. Läuft jetzt noch schneller und stabiler. Danke nochmal für die Hinweise. Projektarchiv ist hochgeladen. Details: "SPI Master Status Read Transaction" wird vor jedem Schreiben abgefragt und das RXF# Bit ausgewertet. Die Auswertung von TXE# hat nichts gebracht, hat offenbar gleiche Funktion, wie die Prüfung, dass der VNC1L neue Zeichen liefern kann. (Statusbit New/Old-Data) Die Funktion von RXF IRQEn und TXE IRQEn im Statusbyte erschliesst sich mir bisher nicht. Datasheet macht keine Aussage dazu. Alle Fehlerzustände werden jetzt von der untersten Ebene bis zum Hauptprogamm durchgereicht. Timeouts eingeführt, der Stick könnte ja jederzeit raus gezogen werden. Einige neue Funktionen, wie das warten auf bestimmte Meldungen sind neu.
Datum:
Man da hab ich ja was losgetreten. Aber ich sag schon mal Danke für die viele Mühe und Arbeit. Ich freu mich schon mir das Programm anzusehen und auch auszuprobieren aber das muss noch bis Mittwoch warten. mfg LPT
Datum:
Hallo Matthias K. ich habe dein neues Programmm mal kurz überflogen, das sieht doch gleich wesentlich besser aus - damit wirst du eher zu Ziel kommen. Was mir aufgefallen ist: du wertest das Status-BYTE aus. Ehrlichgesagt ist mir der rechte Nutzen dieses Bytes nicht klar geworden. Ich beschränke mich auf das Status-BIT in den Daten. Ist es gesetzt, dann war's ein Schuss in den Ofen. Also wird einfach wiederholt. Solange, bis eine '0' zurückgeliefert wird. Das spart das Einlesen eines Bytes (nämlich des Status-Bytes), das keine Daten transportiert. Ausserdem muss man keinen Parameter übergeben. Das spart Speicherplatz. Noch ein Tip. Es gibt einen SCS-Modus, in dem man den VDIP mit 'binären' Befehlen füttern kann. Auch die Antworten sind dann kompakter. Und dadurch leichter auszuwerten. Dass ich den VDIP neulich als "krötenlangsam" bezeichnet habe, möchte hier noch einmal relativieren. Die Antworten im SPI-Modus brauchen einige Zeit (die relativ länger scheint als im RS23-Modus). Wenn man sich die Bitfolgen am logic-analyser im RS232-Modus ansieht, dann kommt die Antwort sofort (aber wir reden hier von Bitzeiten von 100us). Im SPI-Modus (Bitzeiten um 1us) kommt nach einem Kommando lange Zeit nur fehlerhafte Daten rein. Und der Speicher des Analysers ist voll, bevor die gültige Anwort erscheint. Ich hatte immer angenommen, dass irgendetwas in der Kommunikation nicht funktioniert. Naja, nun habe ich es begriffen. Mein Logger funktioniert inzwischen auch - und ist via SPI 'gefühlt' schneller als via RS232. Übrigens hast du dein Testprogramm noch auf dem alten Stand. Das (bzw. der Inhalt) mag potentielle Leser irritieren. Zumal da noch ein kleines Missverständnis steckt: _delay_ms() und _delay_us() haben Beschränkungen. Im Manual zum WINAVR steht bei _delay_ms() : max 262ms / F_CPU (in MHz) _delay_us() : max 768us / F_CPU (in MHz) Bei 10 MHz kann man also maximal 26ms Verzögerung erreichen. _delay_ms(500) wird somit keine 500ms Wartezeit erreichen. Viel Erfolg bei deinem weiteren Projekt. Michael S.
Datum:
>Was mir aufgefallen ist: du wertest das Status-BYTE aus. Da sind 2 Bits zum VNC1L Status des FIFOs drin. Das Datenblatt ist dazu eine Katastrophe. Wenn RXF# = 1 ist, ist der FIFO des VNC voll und kann keine Daten mehr annehmen. Abfrage hat sich bewährt, ich habe hier zum probieren u.a. eine alte Stickgurke, die extrem langsam ist beim schreiben. Legt schon nach 20 Byte eine Gedenksekunde ein. Zusätzliche Abfrage des Statusbits, ob dann das Byte akzepiert wurde, ist eine weitere Sicherheitsstufe. Wenn TXE# = 1 liegt kein Byte zum abholen im FIFO bereit. Das glaube ich jetzt nach paar Tests verstanden zu haben. Ist noch nicht im Programm eingebaut, Funktion war mir lange unklar. Hier habe ich jedoch wenig bedenken, weil das Statusbit praktisch gleiche Info liefert (neues/altes Byte). Beim Abholen des Status-Bytes ist übrigens das Status-Bit am Ende der SPI-Sequenz immer 0, also es ist immer gültig. Die Abfrage geht offenbar nicht über den FIFO und wird sofort bedient. Ein knapper Hinweis findet sich im Datenblatt dazu beim Parallelmode, wo beide Signale auch hardwarmäßig zur Verfügung stehen. >Es gibt einen SCS-Modus, in dem man den VDIP mit 'binären' Befehlen Kenne ich, auch schon mal ausprobiert. >Zumal da noch ein kleines Missverständnis steckt: >_delay_ms() und _delay_us() haben Beschränkungen. >Im Manual zum WINAVR steht bei >_delay_ms() : max 262ms / F_CPU (in MHz) >_delay_us() : max 768us / F_CPU (in MHz) >Bei 10 MHz kann man also maximal 26ms Verzögerung erreichen. >_delay_ms(500) wird somit keine 500ms Wartezeit erreichen. Das war mal so: Ab der avr-libc Versionen ab 1.6 geht es länger: _delay_ms() 6553,5 ms _delay_us() dito. http://www.mikrocontroller.net/articles/AVR-GCC-Tu... >Viel Erfolg bei deinem weiteren Projekt. Ebenfalls
Datum:
> Wenn RXF# = 1 ist, ist der FIFO des VNC voll und kann keine Daten mehr > annehmen. Abfrage hat sich bewährt ... Hallo ich bin es noch mal. Mein bzw. Dein Programm geht bei mir immer noch nicht. Es entstehen wieder nur lehre Dateien auf dem USB-Stick. Anschein ist der status in der Funktion "char vnc_wr_spi" immer 1 und somit nicht OK selbst wenn ich aus den 15µs Wartezeit 150ms mache ist der Fehler da und es entsteht ein überlauf. Da ich Echos senden und Dateien anlegen kann muss das senden doch eigentlich richtig programmiert sein. Kann es am dem Modul liegen? Weiß einer woran es sonst noch liegen kann. Ich will jetzt erst mal das Modul Updaten. mfg LPT
Datum:
Hast Du Dir die letzte Version des Projektarchives runtergeladen?
Häng Dein gesamtes Projekt hier an, oder PM, dann lasse ich es bei mir
mal laufen.
>Ich will jetzt erst mal das Modul Updaten.
Das ist wichtig, mit alten VDAP Version geht nicht alles.
Datum:
Wenn man den Befehl RD file absetzt ist nach genau 'nem kByte Schluß, der Promp-Check versagt. Any hints? mfg
Datum:
Hi Korinthenkacker RD File absetzen??? Was meist Du mit absetzen?? RD ist doch der Befehl für Datei lesen aber das will ich ja nicht. Dann gibt es noch RDF aber das ist Dateilänge zurückgeben. Kannst Du mir das bitte noch mal erklären. Der Testfile der in die Datei geschreiben werden soll ist 80Byt groß. Also noch weit enfternt von dem kB Oder meinst Du alle Bits und Byts die ich sende (also auch die Befehle das Ping und das je mit 13Bit? @ Matthias ich hab dir mal ein Mail geschreiben. mfg LPT
Datum:
@lpt:
Meine e-mail steht unten im Beitrag!
>RD file ...
Lese-Buffergröße im Programm angepasst?
Datum:
Angehängte Dateien:Ich habe mir aus dem Vorhandenen selber was zusammengeschustert, mein Monitoring läuft über die serielle Schnittstelle, über die ich auch Befehle absetzen kann. Laufen tut's auf 'nem MEGA32 mit 14.7456MHz, die Baudrate beträtg 38400 Baud und die Error-LED ist bei mir dummerweise von PB0 nach Masse geschaltet (im File natürlich geändert). Hab's mal angehängt. mfg
Datum:
> VNC1L_AVR_C-Projekt_uart.zip
Läuft bei mir auf Mega644.
Baudrate auf 2400 runtergesetzt, habe gerade keinen Baudratenquarz dran.
So gehts auch mit den interen 1MHz.
Fehler wie Bad command werden noch nicht ausgewertet. Deshalb ist bei
falschen Befehlen erstmal Schluß.
Datum:
Hab's "langsam" auch mal probiert, selbes Ergebnis, bei exakt 1 kByte ist Sense. Wie wird denn eigentlich eine Fehlermeldung erfolgreich abgefangen? Wenn ich Mist schicke, nimmt der VDIP1 mir das sofort übel (zeigt keine Reaktion mehr). Egal, für heute ist Schluß! Gute N8
Datum:
@LPT: Da passt einiges nicht: >vdip1_init(); kannst Du nicht vor der PORT-Festlegung machen. Ansonsten habe ich mal die LCD an Dein Programm angebunden. Es wird was gesendet, auch Antworten kommen. Nur das Timing stimmt nicht. Nach ECS und IPA kommt kein prompt, erst irgendwann später dazwischen kommt dann mal ein promt durch. Aber inzwischen sendest Du immer weiter... Kannst Du nicht wenigstens mal die UART nutzen, um alles zu Monitoren? @Korinthenkacker >Wie wird denn eigentlich eine Fehlermeldung erfolgreich >abgefangen? Das müsste in dieser Routine geschehen: unsigned char vnc_rd_answer(unsigned char buffer_check) { als weiterer Case-Zweig Zur Zeit wird nur commad failed abgefangen. Kann auch auf bad command und andere erweitert werden. -->demnächst geplant
Datum:
Das mit dem anschissen von irgend einer Monitorring Gelegenheit wird schwierig. Es Existiert noch kein Bord. Im Augenblick ist der AVR auf dem STK500 und über fliegende Verdrahtung mit dem VDIP1 verbunden, der Provisorisch auf einer Lochrasterkarte stecket Ist es vielleicht leichter das VDIP1 Modul über ein UART Verbindung anzusprechen? Ich wollte sie mir eigentlich frei halten aber brauchen tue ich sie nicht. Ich muss nur so schnell wie möglich Daten senden/schreiben können. Bin so ein mählich nämlich etwas verzweifelt. Vor allem da dein Programm bei mir auch nicht läuft und irgendwo min 3 Fehler erkannt werden. Übersichtlich ist es für mich erst wenn ich denn Code auflockere um zu sehen wo was anfängt und endet und selbst dann finde ich zu meinem Programm keinen Unterschied. Das meiste ist eh nur kopiert. Jetzt ist erst mal WE da komme ich leider nicht zum weiter arbeiten also geht es nächste Wochen für mich weiter. Das Ding muss doch zu knacken sein. mfg LPT
Datum:
>Das mit dem anschissen von irgend einer Monitorring Gelegenheit wird >schwierig. Serielle Schnittstelle kann nicht das Problem sein. Und ein Monitorprogamm auf dem PC auch nicht. Du hättest Dir viel Abeit ersparen können. So ein Programm kann man praktisch nicht ohne Hilfmittel erstellen, dazu ist der VNC zu komplex. Dazu kommt, dass man in C schon ziemlich fit sein sollte. >Ist es vielleicht leichter das VDIP1 Modul über ein UART Verbindung >anzusprechen? Nicht wirklich. Die gesamte Datenauswertung, woran es bei Dir scheitert, bleibt gleich. Nur die Daten kommen auf andere Art und Weise in den Buffer. >Ich muss nur so schnell wie möglich Daten senden/schreiben können. Erwarte da nicht zu viel. Datenraten, wie auf den Stick, wenn er am PC hängt, sind nicht annährend nicht zu erwarten. Ein kleiner AVR8 kann auch garnicht so schnell die Daten liefern.
Datum:
Jetzt hab ich's:
... unsigned int rd_answer_versuche = 1000; // TIMEOUT bis Fehler/Abbruch ggf. ANPASSEN! while(rd_answer_versuche) { ... |
Naja, muß ich mal alles umfummeln. mfg
Datum:
Du solltest Dir mal die lezte Version des Projektarchives runterladen. Dort sind ua. die TIMEOUTS integriert. Ich bin gerade dabei, die Fehlermeldungen abzufangen. Lade es morgen hoch. Auch die USART-Funktionen als Monitoring sind dann drin.
Datum:
http://www.mikrocontroller.net/articles/USB-Stick_... Aktualisierte Version des Projektarchives ist hochgeladen. Details: Fehlerzustände werden jetzt weitgehend abgefangen.
// *********************************************************************** // Fehlermeldungen // *********************************************************************** // 1 = Kommando wurde vom VNC1L nicht akzeptiert // 2 = Command Failed // 3 = Bad Command // 4 = Disk Full // 5 = Filename Invalid // 6 = Read Only // 7 = File Open // 8 = Dir Not Empty // 9 = No Disk // 20 = kein VNC1L mit VDAP-Firmware vorhanden // 21 = kein USB-Stick angesteckt // 50 = Buffer zu klein zum Einlesen der Datei // 51 = Dateilänge > 64kByte // 99 = Timeout // *********************************************************************** |
Die Funktion endet zur Zeit erstmal in einer Fehlerroutine. Je nach Anwendungsfall muss entschieden werden, wie der Fehler zu behandeln ist (kehrt man zur Kommunikation zurück, oder doch lieber Reset durchführen?). Ob dies alle mögliche Fehlerzustände sind, wage ich nicht definitiv zu sagen. Sicher gibt es noch Zustände, die noch nicht erkannt werden. Auch konnte ich nicht alle provozieren. UART-Monitoring ist jetzt als Option eingebaut. Sollte für die Testung unbedingt genutzt werden. (Eine "Fernbedienung" per UART ist nicht vorgesehen. Wer die VNC1L-Funktionen nur mal testen will, sollte das VDIP1 erstmal ohne µC direkt per UART (RS232-Treiber nicht vergessen) am PC+Terminalprogramm betreiben.) Neue Routine: vnc_rd_dir(......) Liest die Filelänge einer bestimmten Datei ein. Die Längenangabe wird vorab gebraucht, wenn die Datei später mit RD oder RDF eingelesen werden soll. Weitere Änderungen zur Stabilitätsverbesserung.
Datum:
> Es wird was gesendet, auch Antworten kommen. Nur das Timing stimmt > nicht. Nach ECS und IPA kommt kein prompt, erst irgendwann später Danke für die mühe. Ich hab mich heut noch mal rangesetzt und nachgesehen. Daraufhin hab ich in main statt nach jedem Befehl 1s zu warten, mal eine Überprüfung auf Promt ('>') eingefügt und schon hab ich Daten im meiner Datei. Und schneller geht es auch noch. Allerdings in ASCII vorm und leider stimmen die nicht mit den Gesendeten Daten überein. Allerdings stimmt schon mal die Anzahl. Morgen geht es weiter N8 mfg LPT
Datum:
Warten/delays sind in den letzten Versionen nicht mehr nötig. Nimm möglichst die letzte Version von heute zur Orientierung. Läuft bei mir zumindest sehr stabil. Prompt-Prüfung ist ein zentraler Punkt bei der gesamten Ansteuerung des VNC1L.
Datum:
OK ich hab es soweit das die Daten auf dem USB abgelegt werden. Und offenbar sogar richtig bloß der Texteditor interpretiert es wahrscheinlich falsch. Die Zeichen 32 bis 126 aus der ASCII Tabelle (also alle Buchstaben die Zahlen und die gängigen Zeichen) werden richtig dargestellt. Ich hatte eigentlich gedacht das die Binären Daten vom PC auch als Hex vom USB_Stick gelesen werden. Aber anscheint hab ich mit dieser Annahme daneben gelegen. Wie wertet ihr die Daten aus? Auf eine Rechenintensive Wandlung von 8Bit auf ASCII Zahlen wollte ich mir eigentlich sparen um denn µC zu entlasten und so schneller Abtasten zu können. Oder gibt es ein Programm das aus denn USB die Daten in Hex ausliest? mfg LPT
Datum:
>Ich hatte eigentlich gedacht das die Binären Daten vom PC auch als Hex >vom USB_Stick gelesen werden. Der VNC schreibt die Daten 1:1, welche Du ihm anbietest. Unterschieden zwischen ASCII und Binär wird nicht. Das unterliegt der Interpretation Deiner Auswerte-Software. Jedes ASCII-Zeichen ist auch Binär oder als HEX anzeigbar. >Die Zeichen 32 bis 126 aus der ASCII Tabelle (also alle Buchstaben die >Zahlen und die gängigen Zeichen) werden richtig dargestellt. Jeder Texteditor kann nur die ASCII-Zeichen darstellen. Wenn Du die dazugehörigen Hex-Werte sehen willst, bieten einige Editoren zB. die Ansicht als HEX.
Hallo an alle ich hänge momentan auch an einem Datenlogger-Projekt mit dem VDIP1. Mein VDIP1 soll von einem NEC-V850 über SPI mit Daten versorgt werden, die dieser auf einen USB-Stick abspeichern soll. Nachdem am Anfang nichtmal der USB-Stick erkannt wurde (trotz FAT32 und 512 Byte Speichereinheiten) hab ich die Firmware von 3.66 auf 3.68 geupdatet. Jetzt erkennt er den USB-Stick. Über meine Oszi kann ich auch die Daten, die der VDIP1 zu Beginn schickt (Versions Nr. / USB-Device an P2 detected etc...) auslesen und scheint zu funktionieren. Mein Knackpunkt liegt aber beim Senden der Kommandos. Ich habe die Sende-Routine ( aus VDIP1 Datenblatt und auch aus dem VNC1L-Datenblatt) mit C nachgebildet und auf dem Oszi sieht sie auch -meiner Meinung nach- gut aus. Nur nimmt der VDIP1 die Kommandos nicht an (kein Blinken an LED 2, keine Prompt-Antworten bei '\n', DIR, FWV etc.) Das einzige mal blinkt die LED 2, wenn vom VDIP beim Initialisiern der Disk "No Upgrade" gemeldet wird. Danach leuchtet die LED nur durch und bei Lese-Versuchen kommt immer nur 0x0D und Statusbit auf High (alte Daten). Hat jemand eine Idee, woran es liegen könnte, dass meine Kommandos nicht angenommen werden? Meine Clock-Zeiten liegen über 1 us, also zu schnell dürfte ich auch nicht senden (VDIP nimmt ja angeblich 12 MHz CLK-Signale an...) Gesendet Wird in der Reihenfolge: "ECS" , "IPA" und dann "DIR", jeweils mit Lesezyklen dazwischen. Hier ist mein Sendecode (noch ohne Status Überwachung, das führe ich noch per Oszi durch):
void WriteData(unsigned char wr_byte) { unsigned char stelle, status; SPI_CLK_H; /* 1. Bit */ SPI_CLK_L; SPI_CS_H; SPI_MOSI_H; SPI_CLK_H; /* 2. Bit */ SPI_CLK_L; SPI_MOSI_L; SPI_CLK_H; /* 3. Bit */ SPI_CLK_L; SPI_CLK_H; /* 4. Bit */ SPI_CLK_L; for(stelle = 0x80 ; stelle ; stelle >>= 1) { /* 5. - 12. Bit */ if(wr_byte & stelle) { SPI_MOSI_H; } else { SPI_MOSI_L; } SPI_CLK_H; SPI_CLK_L; } SPI_MOSI_L; SPI_CLK_H; SPI_CLK_L; SPI_CS_L; SPI_CLK_H; /* 14. Bit halte CS Pegel low für 1 cycle */ SPI_CLK_L; } |
Im Anhang befindet sich ein Oszibild eines gesendeten 'E' (ASCII: 0x45) Zur Legende: Blau: MISO Gelb: Chip Select Rot: CLK Grün: MOSI Zeit Division: 10 us Danke schonmal für die Hilfe! Gruß Markus
Datum:
Edit: Ein Edit Button wäre cool... Ok, ich habe das Problem jetzt gefunden. Meine '\n' Zeichen nach den Einzel Commandos wurden falsch gesendet. Schickt dem VDIP1 lieber direkt eine '13', dann passt das auch mit dem Return Zeichen! So jetzt sitze ich gleich am nächsten Problem. Bei jedem Kommando (ECS, IPA bisher getestet) erhalte ich ein "Bad Command". Mal sehen was ich da noch so finde... Gruß
Datum:
>So jetzt sitze ich gleich am nächsten Problem. Bei jedem Kommando (ECS, >IPA bisher getestet) erhalte ich ein "Bad Command". Mal sehen was ich da >noch so finde... Nach jedem Kommando unbedingt auf die Bestätigung des VNC1L warten (D:\>), meist Prompt_Check genannt. Erst dann kann er weitere Kommandos annehmen. Sendest Du vorher schon weitere Kommandos, kommt irgendwann ein 'Bad command'.
Datum:
Hallo Matthias, danke für die schnelle Antwort. Mein Plan sieht augenblicklich so aus: Ich schicke dem VDIP1 ein Kommando und gebe ihm dann direkt im Anschluss (nach kurzer Delay-Zeit) mit Read-Zyklen solange Gelegenheit zu antworten, bis das Status-Bit "Alte Daten" anzeigt. Diese Antwort ist immer "Bad Command", obwohl weitere Kommandos erst danach übermittelt werden. Einzige Ausnahme: ein Echo scheint er zu erkennen. Das Echo beantwortet er mit: E "Return" und dann nur noch "Alte Daten", also auch ohne Prompt Zeichen. Kann es sein, dass ich zu kurz warte, bis ich mit den Read-Zyklen beginne? Gruß Markus
Datum:
>Ich schicke dem VDIP1 ein Kommando und gebe ihm dann direkt im Anschluss >(nach kurzer Delay-Zeit) mit Read-Zyklen solange Gelegenheit zu >antworten, bis das Status-Bit "Alte Daten" anzeigt. Er wird möglicherweise zunächst 'alte Zeichen' liefern, dann erst Neue. Lies doch einfach alle empfangenen 'neuen Zeichen' nach einem Kommando in einen Buffer ein und prüfen den Buffer auf "D:\>". Dann ist mit Sicherheit die Bestätigung der Kommandoannahme da. Allein auf die Abfrage alte/neue Zeichen würde ich mich nicht verlassen. Das passiert auch schon mal mitten in einer Antwort. Da würde Dir dann ein Teil zur Auswertung fehlen. >Kann es sein, dass ich zu kurz warte, bis ich mit den Read-Zyklen beginne? Du kannst ohne Delays sofort beginnen zu lesen. Nur Status-Bit und Status-Byte immer auswerten.
Datum:
Ok. Dann optimiere ich mal meinen Code auf Prompt-Abwarten, Status-Bit- und Status-Byte-Auswertung. Danke nochmals für deine Hilfe.
Hallo zusammen, ich versuche gerade den vdip1 in Betrieb zu nehmen und komme dabei nicht allzuweit. Ich habe ihn provisorisch verdrahtet und mich mit einem terminal programm mit ihm verbunden. soweit ich das verstehe, sollte ich nach dem einschalten ueber das terminal lesen koennen wer und was der controller ist und wenn er bereit ist, dann erscheint das D:\> Komischer weise passiert genau das nicht (siehe Screenshot) und ich habe nicht wirklich eine idee woran es liegt. Ich kann ihn flashen via usb, das habe ich schon probiert. Hab die Uart Uebertragungsgeschwindigkeit veraendert. Das es funktioniert mache ich daran fest, dass die Empfangene Nachricht (egal wie unsinnig mir erscheint) die gleiche ist bei 4800 und 9600 (ohne und mit rts/cts) hat vielleicht jemand eine idee woran es liegen koennte? Vielleicht ist das problem ja schon mal bei jemandem aufgetreten. ich bin nicth so super firm mit dem inbetriebnehmen solcher boards, somit koennte es halt auch ein voellig bescheuerter fehler sein :) Uwe
Datum:
Du hast foffentlich einen MAX232-Pegelwandler für TXD und RXD dazwischen geschaltet! Sonst dürfte das Teil kaputt sein. Ansonsten lt. Datenblatt: Baud rate (default =9600 baud), flow control settings (default = RTS/CTS), number of data bits (default=8), parity (default is no parity) and number of stop bits (default=1) are all configurable using the firmware command interface. Please refer to http://www.ftdichip.com (or latest version). RTS-CTS (PIN9-PIN10) muss direkt am VDIP1 verbunden sein. Die beiden Jumper hast Du sicher auf UART gesteckt?
Datum:
Hallo Uwe, bei der seriellen Übertragung (ohne Handshake) den Pin CTS auf Masse ziehen, Standardparameter 9600 Baud, keine Parität, 1 Stopbit. Vielleicht hilft auch die Beschreibung zum Bausatz STI100 (USB-Stick-Interface), hier ist der selbe Chip eingesetzt. Michael S.
Datum:
Jup! Ja der fehler lag natürlich im fehlenden max202. hab jetzt halt den schritt übersprungen und den vdip1 driekt mit meinem µC verbunden. Dann stimmen die Pegel. danke für die Hilfe.
Datum:
>Jup! Ja der fehler lag natürlich im fehlenden max202.
Und er lebt noch?
Datum:
Also, zumindest schickt er die nachrichten, die man erwartet. ich würde das als indiz sehen, dass es er noch funktioniert. Anfänger glück was :)
Datum:
Einen gewissen Schutz haben die Eingäne offenbar. Sie sind ja auch 5V-tolerant.
Datum:
Hallo, vielleicht ist das der passende Thread für mein Problem. Ich schreibe Daten auf das Interface, ohne Handshake. Das wird vom µC gesendet:
<\r> IPA<\r> <\r> OPW 666.txt<\r> WRF 140<\r> $GPRMC,000004.026,V,5122.9659,N,00656.9130,E,0.00,0.00,060180,,,N*70^^$GPGGA,000005.026,5122.9659,N,00656.9130,E,0,0,,102.5,M,47.5,M,,*4B#^<\n>CLF 666.txt<\r> <\r> OPW 666.txt<\r> WRF 140<\r> $GPRMC,000006.026,V,5122.9659,N,00656.9130,E,0.00,0.00,060180,,,N*72^^$GPGGA,000006.026,5122.9659,N,00656.9130,E,0,0,,102.5,M,47.5,M,,*48#^<\n>CLF 666.txt<\r> <\r> OPW 666.txt<\r> WRF 140<\r> $GPRMC,000007.026,V,5122.9659,N,00656.9130,E,0.00,0.00,060180,,,N*73^^$GPGGA,000007.026,5122.9659,N,00656.9130,E,0,0,,102.5,M,47.5,M,,*49#^<\n>CLF 666.txt<\r> <\r> OPW 666.txt<\r> WRF 140<\r> $GPRMC,000008.026,V,5122.9659,N,00656.9130,E,0.00,0.00,060180,,,N*7C^^$GPGGA,000008.026,5122.9659,N,00656.9130,E,0,0,,102.5,M,47.5,M,,*46#^<\n>CLF 666.txt<\r> <\r> OPW 666.txt<\r> WRF 140<\r> $GPRMC,000009.026,V,5122.9659,N,00656.9130,E,0.00,0.00,060180,,,N*7D^^$GPGGA,000009.026,5122.9659,N,00656.9130,E,0,0,,102.5,M,47.5,M,,*47#^<\n>CLF 666.txt<\r> <\r> OPW 666.txt<\r> WRF 140<\r> $GPRMC,000010.026,V,5122.9659,N,00656.9130,E,0.00,0.00,060180,,,N*75^^$GPGGA,000010.026,5122.9659,N,00656.9130,E,0,0,,102.5,M,47.5,M,,*4F#^<\n>CLF 666.txt<\r> <\r> OPW 666.txt<\r> WRF 140<\r> $GPRMC,000011.026,V,5122.9659,N,00656.9130,E,0.00,0.00,060180,,,N*74^^$GPGGA,000011.026,5122.9659,N,00656.9130,E,0,0,,102.5,M,47.5,M,,*4E#^<\n>CLF 666.txt<\r> <\r> OPW 666.txt<\r> WRF 140<\r> $GPRMC,000012.026,V,5122.9659,N,00656.9130,E,0.00,0.00,060180,,,N*77^^$GPGGA,000012.026,5122.9659,N,00656.9130,E,0,0,,102.5,M,47.5,M,,*4D#^<\n>CLF 666.txt<\r> <\r> OPW 666.txt<\r> WRF 140<\r> $GPRMC,000013.026,V,5122.9659,N,00656.9130,E,0.00,0.00,060180,,,N*76^^$GPGGA,000013.026,5122.9659,N,00656.9130,E,0,0,,102.5,M,47.5,M,,*4C#^<\n>CLF 666.txt<\r> <\r> OPW 666.txt<\r> WRF 140<\r> $GPRMC,000014.026,V,5122.9659,N,00656.9130,E,0.00,0.00,060180,,,N*71^^$GPGGA,000014.026,5122.9659,N,00656.9130,E,0,0,,102.5,M,47.5,M,,*4B#^<\n>CLF 666.txt<\r> <\0> |
Aber auf dem Stick landet folgendes:
$GPRMC,000004.026,V,5122.9659,N,00656.9130,E,0.00,0.00,06GA,000005.026,5122.9659,N,00656.9130,E,0,0,,102.5,M,47.5,M,,*4B#^ CLF 666.txt OPW $GPRMC,000006.026,V,5122.9659,N,00656.9130,E,0.00,0.00,060180,,,N*72^^$GPGGA,000006.026,5122.9659,N,00656.9130,E,0,0,,102.5,M,47.5,M,,*48#^ $GPRMC,000007.026,V,5122.9659,N,00656.9130,E,0.00,0.00,060180,,,N*73^^$GPGGA,000007.026,5122.9659,N,00656.9130,E,0,0,,102.5,M,47.5,M,,*49#^ $GPRMC,000008.026,V,5122.9659,N,00656.9130,E,0.00,0.00,060180,,,N*7C^^$GPGGA,000008.026,5122.9659,N,00656.9130,E,0,0,,102.5,M,47.5,M,,*46#^ $GPRMC,000009.026,V,5122.9659,N,00656.9130,E,0.00,0.00,060180,,,N*7D^^$GPGGA,000009.026,5122.9659,N,00656.9130,E,0,0,,102.5,M,47.5,M,,*47#^ $GPRMC,000010.026,V,5122.9659,N,00656.9130,E,0.00,0.00,060180,,,N*75^^$GPGGA,000010.026,5122.9659,N,00656.9130,E,0,0,,102.5,M,47.5,M,,*4F#^ $GPRMC,000011.026,V,5122.9659,N,00656.9130,E,0.00,0.00,060180,,,N*74^^$GPGGA,000011.026,5122.9659,N,00656.9130,E,0,0,,102.5,M,47.5,M,,*4E#^ $GPRMC,000012.026,V,5122.9659,N,00656.9130,E,0.00,0.00,060180,,,N*77^^$GPGGA,000012.026,5122.9659,N,00656.9130,E,0,0,,102.5,M,47.5,M,,*4D#^ |
Man sieht, dass der zu schreibende String nicht komplett ankommt und daher die folgenden Steuerbefehle als Teil vom Eingabestring angesehen werden. Dieser Fehler tritt immer wieder auf, dazwischen sind korrekt geschriebene Blocks. Betrieben wird das Ganze mit 9600 Baud. Jemand eine Idee was es sein kann?
Datum:
Ich habe es mir mal angesehen. Im ersten Datenblock fehlt mittendrin ein Stück. Konkret: es werden die ersten 57 Byte korrekt geschrieben, dann fehlen 17 Byte und dann folgt der Rest. Da der VNC1L aber auf exakt 140 Byte wartet, interpretiert er natürlich nun alle weiteren Bytes nicht als Kommando, sondern Nutzdaten, bis die 140 erreicht wird. Sieht nach einem Bufferüberlauf aus. Um das Problem einzugrenzen, erstmal versuchsweise nach jedem gesendeten Byte ein delay. Besser wäre gleich die Nutzung der Handshakesignale. RTS#/CTS# ist bei VDAP standardmäßig aktiviert. Möglicherweise tritt es auch nicht bei allen Sticks gleichermaßen auf. Aus Erfahrung mit dem SPI-Interface weiss ich inzwischen, dass durchaus auch hier der Buffer, besonderes beim schreiben, relativ schnell voll wird und ohne diesbezügliche Prüfungen kommt es da auch zu Fehlfunktionen.
Datum:
Danke für die Antwort! Die Daten werden mit etwa 1Hz an den STI gesendet, eigentlich ist es ja nicht besonders schnell. Ich benutze BASCOM, der Sendeteil sieht bei mir so aus:
' write given data to the usb device Sub Writeusb(mydata As String) Length = Len(mydata) Writestring = "WRF " + Str(length) Print #2 , Chr(&H0d); Print #2 , "OPW myFile.txt"; Print #2 , Chr(&H0d); Print #2 , Writestring; Print #2 , Chr(&H0d); Print #2 , Mydata; Print #2 , "CLF myFile.txt"; Print #2 , Chr(&H0d); End Sub |
Ich habe gelesen, dass man nach jedem Befehl auf den Prompt warten sollte - ist vielleicht hier der Fehler? Wie man hier sieht, sende ich den gesamten String auf einmal (Print #2 , Mydata;) und nicht Zeichen für Zeichen. Allerdings weiß ich auch nicht, wie Bascom das intern regelt. Fragen: - Ich sitze gerade nicht vor dem Aufbau, aber jetzt fällt mir auf, dass in der Schreibmethode meine Befehle ohne Delays hintereinander versendet werden. Ist evtl da schon der Fehler? - Soll ich den String tatsächlich lieber Zeichen für Zeichen in einer Schleife senden? - Wie hoch sollten die Delays zwischen den einzelnen Zeichen sein? - Wie genau funktioniert der Handshake? Habe damit noch nie gearbeitet. - Ich habe angenommen, dass 1Hz Schreibrate eigentlich recht unproblematisch ist, später sollte diese auf 5 oder 10Hz steigen. Wenn aber jetzt schon bei 1Hz Probleme auftreten, wird man dann überhaupt mit 5Hz auf den Stick schreiben können?
Datum:
>Ich habe gelesen, dass man nach jedem Befehl auf den Prompt warten >sollte - ist vielleicht hier der Fehler? Ja, nur so weist Du, dass der VNC wieder in der Lage ist neue Kommandos anzunehmen. Mit 1Hz meist Du wohl die Frequenz, mit der Du die Subroutine aufrufst(?) Das eigentliche senden darin dürfte wesentlich schneller gehen. Auf eine bestimmte Geschwindigkeit kannst Du Dich nicht verlassen. Jeder Stick erreicht bauartbedingt unterschiedliche Zeiten. Also, nach jedem Befehl auf das Prompt prüfen, noch einen Timeout einbauen usw., dann holst Du das maximale raus. Testweise erstmal jedes Byte einzeln senden und eine Pause ca. 1...10ms dazwischen. Bascom halte ich nicht besonderes dafür geeignet, schon wegen der Tatsache, dass man nicht weiß, was die vordefinierten Funktionen überhaupt genau machen. Handshake-Nutzung dürfte damit auch ein Problem werden. Hast Du RTS# und CTS# am VNC direkt miteinander verbunden?
Datum:
Matthias K. schrieb: > > Mit 1Hz meist Du wohl die Frequenz, mit der Du die Subroutine > aufrufst(?) Ja > Also, nach jedem Befehl auf das Prompt prüfen, noch einen Timeout > einbauen usw., dann holst Du das maximale raus. Gibt es Erfahrungen, mit welcher Frequenz man eine solche Schreibroutine zuverlässig aufrufen könnte? Eigentlich wollte ich darauf hinaus alle 250ms einen Datensatz von etwa 300 kb zu schreiben. > Testweise erstmal jedes Byte einzeln senden und eine Pause ca. 1...10ms > dazwischen. Ok, werde das heute testen. > Hast Du RTS# und CTS# am VNC direkt miteinander verbunden? Nein, ich habe es wie im Datenblatt zum STI angegeben gemacht: " Möchte man ohne Handshake auskommen oder ist ein Handshake nicht möglich, kann der /CTS-Pin mit Masse verbunden werden. " Sollten RTS und CTS miteinander verbunden werden?
Datum:
>Gibt es Erfahrungen, mit welcher Frequenz man eine solche Schreibroutine >zuverlässig aufrufen könnte? Eigentlich wollte ich darauf hinaus alle >250ms einen Datensatz von etwa 300 kb zu schreiben. Das wird auf keinen Fall was. Rechne doch mal nach: Bei 9600Baud (Bit/s) schaffst Du den Overhead mit eingerechnet ca. 0.9kbyte je Sekunde zu übertragen. Wieviele Minuten Deine 300kb brauchen kannst Du Dir ausrechnen. >Hast Du RTS# und CTS# am VNC direkt miteinander verbunden? >Nein, ich habe es wie im Datenblatt zum STI angegeben gemacht: Versuchsweise mal machen. Besser beide Signale mit Portpins verbinden und auswerten/setzen.
Datum:
Sorry - ich habe mich vertippt. Es sollte 300 Byte nicht nicht Kb heissen. Die Baudrate würde ich dann auf 115.200 hochsetzen, wobei auch 9600 für die Datenmenge ausreichen sollten. Werde heute abend also CTS und RTS miteinander verbinden. Den String Zeichen für Zeichen mit Delays senden. Zwei abschliessende Fragen noch: Ist die Auswertung der CTS / RTS Pins nicht äquivalent zum Warten auf den Prompt vom STI? Verstehe ich das richtig, dass CTS auf 1 geht, wenn das STI bereit zum Empfangen ist?
Datum:
>Ist die Auswertung der CTS / RTS Pins nicht äquivalent zum Warten auf >den Prompt vom STI? Nein, die RTS/CTS Auswertung ist einige Ebenen tiefer angesetzt und betrifft den internen Hardwarebuffer des VNC1L. Die Funktionensweise von RTS/CTS findest Du im Internet oder hier: http://www.mikrocontroller.net/articles/RS-232 beschrieben. Wahrscheinlich hält der VNC1L den RTS-Pin auf 0, wenn er weitere Daten annehmen kann. Das musst Du mit dem µC erfassen und wenn der RTS-Pin 1 wird entsprechend das Senden unterbrechen bis RTS wieder 0 wird. (PS: Es könnte auch 1/0 sein, habe jetzt keine Zeit das Datenblatt genauer zu lesen;-) ) Eventuell musst Du es ausprobieren.
Datum:
So, ich habe alles mögliche getestet: - Zuerst CTS und RTS direkt am STI miteinander verbunden --> kein Erfolg - Daten in einer Schleife mit timeouts nach jedem Zeichen gesender --> kein Erfolg - Nach jedem Befehl timeouts eingebaut --> kein Erfolg Mir ist jedoch etwas aufgefallen: Wenn ich meinen String, der geschrieben wird im Code statisch deklariere, tritt der Fehler nicht auf. Es gibt den Fehler nur, wenn der String vom UART0 kommt. Hier der gesamte Code. Habe ich dort irgendwo einen Fehler, den ich nicht sehe?
$regfile = "m644pdef.dat"
$crystal = 16000000
$hwstack = 128
$swstack = 512
$framesize = 128
$baud = 9600
$baud1 = 9600
Open "COM2:" For Binary As #2
Config Serialin = Buffered , Size = 100 , Bytematch = 13
Declare Sub Serial0charmatch()
Declare Sub Clearvars()
Declare Sub Initsti()
Declare Sub Buildgpsstring()
Declare Sub Writeusb()
Dim Incoming_data As String * 100
Dim Gps_string As String * 200
Dim Mc As String * 100
Dim Ga As String * 100
Dim Writestring As String * 200
Dim Length As Integer
Call Initsti()
Enable Interrupts
Mc = ""
Ga = ""
Do
If Mc <> "" And Ga <> "" Then
' write data to usb
Call Writeusb()
' tidy up
Call Clearvars()
End If
Loop
End
'Daten vom Buffer auslesen
Sub Serial0charmatch()
If Mc <> "" And Ga <> "" Then
Return
End If
Input Incoming_data Noecho
If Len(incoming_data) > 50 Then
If Mid(incoming_data , 2 , 6) = "$GPRMC" And Mc = "" Then
Mc = Incoming_data
End If
If Mid(incoming_data , 2 , 6) = "$GPGGA" And Ga = "" Then
Ga = Incoming_data
End If
End If
Return
End Sub
'STI Initialization
Sub Initsti()
Wait 10
Print #2 , Chr(&H0d);
Print #2 , "IPA";
Print #2 , Chr(&H0d);
Wait 10
End Sub
' variablen leeren
Sub Clearvars()
Mc = ""
Ga = ""
Incoming_data = ""
Gps_string = ""
Writestring = ""
End Sub
' create the cps writestring
Sub Buildgpsstring()
Gps_string = Mc + "^"
Gps_string = Gps_string + Ga
Gps_string = Gps_string + Chr(&H0a)
End Sub
' write given data to the usb device
Sub Writeusb()
' wenn man das einkommentiert, funktioniert es.
'Gps_string = "$GPRMC,000007.026,V,5122.9659,N,00656.9130,E,0.00,0.00,060180,,,N*73^^
$GPGGA,000007.026,5122.9659,N,00656.9130,E,0,0,,102.5,M,47.5,M,,*49#^"
Disable Interrupts
Length = 0
Length = Len(gps_string)
Writestring = "WRF " + Str(length)
Print #2 , "OPW 1.txt";
Print #2 , Chr(&H0d);
Print #2 , Writestring;
Print #2 , Chr(&H0d);
Print #2 , Gps_string;
Print #2 , "CLF 1.txt";
Print #2 , Chr(&H0d);
Enable Interrupts
End Sub
|
Datum:
>Wenn ich meinen String, der geschrieben wird im Code statisch >deklariere, tritt der Fehler nicht auf. Es gibt den Fehler nur, wenn der >String vom UART0 kommt. >Hier der gesamte Code. Habe ich dort irgendwo einen Fehler, den ich >nicht sehe? Das frag besser in einem Bascomforum. Ich verstehe zwar das Programm so ungefähr, aber Bascom hat zuviele unüberschaubare Funktionen, welche die Ursache sein könnten. Soweit ich es Überblicke, schreibst Du nach wie vor einfach auf den VNC1L los, ohne auf Rückmeldungen, wie das Prompt oder Fehlermeldungen zu detektieren. Das wird so nichts. Kuck Dir mal das Video an. Da siehest Du die Abläufe und die Antworten des VNC1L im Detail. http://www.youtube.com/watch?v=r3fF48pI0Wo
Datum:
Ich denke ich habe den Fehler gefunden. Verwende jetzt einen Handshake bzw. sende nur, wenn RTS vom STI auf 0 ist und das Problem ist nicht mehr aufgetreten. Mit der neuen Firmware fährt das Ding übrigens viel schneller hoch, da die Größe vom Stick nicht mehr ermittelt wird.
Datum:
Schön dass es jetzt funktioniert. RTS hat demnach die oben vermutete Polarität. Firmwareupdate sollte man unbedingt machen, meist haben die Module bei der Lieferung eine alte Version drauf.
Datum:
hi, ich habe mal eine Frage, die nicht unbedingt hiermit zu tun, die sich nur aus diesem Projekt ergeben hat. Es geht allgemein um C. Die Testnachricht wird ja in eine Zeigerfeld geschrieben
char *file1[] = { "USB-Stick am Mikrocontoller -\n\r", "Version: V1.24, Stand: 16.11.2009, Author: Matthias Kahnt\n\r", "Text-File 1 vom VNC1L/VDIP1 erzeugt!\n\n\r\a"}; // \a als File-Endekennung NEU |
wenn ich das richtig verstehe, könnte man das zeigerfeld auch so schreiben
char file[]; //norales Array erstellen *file[]=... //in das eben erstellte Array schreiben |
also, so, habe ich das bisher begriffen, ist ein zeigerfeld ein Array auf das gezeigt wird, oder? stehe gerade ein bischen aufn schlauch... mein Inhalt, der in der Textdatei stehen soll, den habe ich in einem normalen Array, ich weiß bekomme es aber echt nicht hin, diesen an file1[] zu übergeben, ich dachte es geht mit einer schleife bei der zeichen für zeichen übergeben wird, oder mit memcpy... viell bin ich hier ja auch ganz falsch, aber vielleicht hat ja auch jemand einen kleinen typ ür mich, wie ich mein array inhalt in das zeigerfeld, bzw in die datei bekomm, dankeschön
Datum:
So ähnlich ist die Binär-File-Variante organisiert. Diese kannst Du auch
für Textfiles nehmen.
>char file[]; //norales Array erstellen
char* myptr = file oder &file[0] liefert die Adresse des ersten
Elementes des Arrays
file[0] = 'T'; schreibt T an die erste Stelle usw.
char myvar = file[0]; dto. auslesen
Datum:
Hallo ich bin es mal wieder. Mein VDIP1 arbeitet je seit einigen Monaten schon. Und jetzt wo sich bei meinem Projekt dem Ende naht. Wollte ich anfangen die Prozessorgeschwindigkeit erhöhen. Atmel ON-Chip Takt mit 1MHz war ja zum Testen OK aber jetzt sollen es doch 12MHz sein. Allerdings wird die Kommunikation mit dem VDIP1 immer langsamer je hör die Taktrate ist. Bei 1MHz bekomme ich 14Datenpakete gesendet. Bei 8MHz sind es noch 12 Datenpakete Und bei 12MHz sind es nur noch 10Datenpakete. Das kann doch nicht normal sein. Und dann hab ich mal noch eine Frage zu denn Befehlen "CLS" und "SUD" Also Datei schließen und VDIP1 deaktivieren. Irgendwie will das bei mir nicht klappen, Das sind die einzigsten Befehle bei dennen ich eine Fehlermeldung bekomme. mfg LPT
Datum:
Nick Olaus schrieb: > Und dann hab ich mal noch eine Frage zu denn Befehlen "CLS" und "SUD" > Also Datei schließen und VDIP1 deaktivieren. Meinst Du "CLF <filename>"? "SUD" geht nur, wenn das File vorher geschlossen wurde. Was verstehst Du unter Datenpaketen konkret?
Datum:
Ja, sorry natürlich CLF <dateiname> Im Programm war es aber richtig geschrieben. Die Datei zu erweitern geht und das mit Datei schließen ist der gleiche Programmablauf aber das geht nicht. Datenpakete sind bei mir Messwerte die ich aufnehme und auf den USB-Stick schreibe. Die Datenpakete waren bei mir immer gleich lang aber je schneller der Controller arbeitet desto länger ist der Zeitabstand zwischen 2 Aufnahmephasen (in dieser Zeit wird der Stick beschrieben). mfg LPT
Datum:
Bei 12Mhz Taktrate des µC kommst Du langsam in den Grenzbereich. Im Datenlatt ist für VNC1L SPI-Übertragung max. 12Mhz (SCLK Periode 83ns) angegeben. Da wirkt sich jedes nicht ganz korrekte Timing ungünstig aus.
Datum:
Hallo Matthias Danke für die antwort. Aber bei mir ist es nicht nur bei 12MHz das er langsam wird. Selbst bei 8MHz ist er langsamer als bei 1MHz. mit welcher Frequenz betreibst Du denn deinen Prozessor? Und wie lange dauert bei dir eine Übertragung von sagen wir mal 17Byte mfg LPT
Datum:
Ich kann es erst bei Gelegenheit ausprobieren. Ich hatte mein aktuelles Testprogramm aber schon mit 18,432MHz laufen. All zu großen Datendurchsatz kannst Du grundsätzlich nicht von dem Gesamtystem erwarten. Kennst Du das Dokument: http://www.vinculum.com/documents/appnotes/AN_112_...
Datum:
Nein die Seite kannte ich noch nicht. Aber hab ich das richtig gelesen die SPI Schnittstelle ist am langsamsten? Mir war so als hätte ich irgendwo gelesen das die UART nicht besonders schnell ist und das es mit SPI besser bzw. schneller geht. Wie ist das eigentlich, das beschreiben dauert doch gar nicht solange aber das aufrufen der Befehle und das warten bis das VDIP1 Modul bereit ist frisst soviel zeit. Ist das richtig? Weil dann übertrage ich nicht nach jedem Messintervall die Daten sondern Horte die erst mal auf dem Controller. Und schieb dann stoßweise gleich ein paar 100Byt mit einmal rüber. mfg LPT
Datum:
SPI ist die langsamste Übertragungsvariante. Dafür bleibt die UART am µC für andere Dinge frei. Der Preis der einfachen Kommunikation über Befehle ist die Geschwindigkeit. Du könnstest den VNC1L als USB-Host auch selber programmieren, nur das ist ein gewaltiger Aufwand, allein die FAT-Implementierung. Blochweises schreiben ist auf jedem Fall eine günstige Variante.
Datum:
Da hab ich also damals was falsch verstanden. Aber Außer die Übertragungsgeschwindigkeit ist mein Hauptproblem eigentlich das ich denn Stick nicht sicher vom Gerät entfernen kann.
sprintf (&sende_buffer[0],"CLF %s",*Dateiname); // Datei schleißen if (vdip1_befehl_schreiben(sende_buffer)) { // Fehler Überlauf, Komando Stoerung = 1; // wurde nicht angenommen } if (vdip1_befehl_schreiben("SUD")) // VDIP1 Deaktivieren { Stoerung = 1; } if (vdip1_pruefen(vdip1_fehl) == vdip1_ok); // Prüfung auf VDIP1 Zustand { // Befehl empfangen ??? Stoerung = 1; // Störung setzen } if ( Stoerung == 1) { stoerung (Stoerung); // Störung auswerten } |
Das sollte eigentlich funktionieren. Bei Datei Anlegen oder Erweitern funktioniert es ja auch. mfg LPT
Datum:
Angehängte Dateien:Hallo Allerseits, ist ja schon ziemlich lang geworden, der Beitrag... Ich betreibe den ELV-Bausatz STI100 an einem UART des ATMEGA644, am anderen hängt das Touch-Panel Kit 320-8 von Electronic Assembly. Funktioniert eigentlich super, mit mehreren Einschränkungen: Da das Gerät mit einem Akku betrieben wird, wird es so gut wie nie ausgeschaltet. Deswegen passiert es hin und wieder, dass der USB-Stick erst dann initialisiert wird, wenn ich ihn eigentlich schon lesen möchte. Das ist nervig, weil jedesmal nach einem Firmwareupdate gesucht wird... Vielleicht weiß jemand, wie man das Suchen nach dem Update ausschalten kann. Das eigentliche Lesen ist auch nichts kompliziertes: Eine Textdatei mit einer Liste von Artikelnummern und zugewiesenen Spezifikationsdaten. Im Moment mache ich es ganz simpel: Den Befehl RD + Dateiname an das VNC1L senden. Dann aus den empfangenen Daten die rauspicken, die ich brauche. Funktioniert eigentlich ganz gut, wenn nicht jedesmal die gesamte Datei gesendet werden würde. Die ist zwar nur ca. 20 kB groß, aber bis sie komplett bei 9600 Baud gesendet wurde, vergeht eben doch einige Zeit. Und in dieser Zeit ist das VNC1L "lahmgelegt". Da die Daten zeilenweise, also pro Artikelnummer eine Zeile, in der Datei stehen, wäre es toll, wenn ich die Datei zeilenweise einlesen könnte. Wenn ich die richtige Zeile habe, okay...kein weiteres Lesen nötig. Hab aber leider noch nicht rausbekommen, wie das gehen könnte. Soweit ich das der ELV-Anleitung (Link unten) entnommen habe, gibt es noch den OPR in Verbindung mit RDF. Nur muß ich hier die Anzahl der zu lesenden Bytes angeben. Ich weiß nur leider vorher nicht, an welcher Stelle die gewünschte Artikelnummer steht... Möglicherweise könnte es mit SEK gehen. Also bspw. 50 Bytes lesen, mit SEK dann auf das 51. Byte einstellen und ggf. weiterlesen. Hat das vielleich schon jemand gemacht, oder eine andere Idee? Da das mein erstes größeres Programm ist, bin ich natürlich auch für jeden anderen Tipp dankbar!!! Viele Grüße Heiko http://www.elv-downloads.de/Assets/Produkte/8/857/...
Datum:
Hi, ich weiß der Thread ist ein wenig alt, brachte aber viele brauchbare Informationen zum vorschein. Ich habe mich heute auch mal am VDip versucht. Es klappt ansich auch alles recht gut. Ich habe allerdings ein paar Probleme bei der Auswertung der Daten bzw. Probleme beim Timing. Setup: Vdip <-> µC = Hardware Uart Cts Vdip = Gnd Rts Vdip = µC Programmiert habe ich mi Bascom. Hier mal der Testcode:
Declare Sub Usb_init
Declare Sub Usb_wait
Declare Sub Usb_dir
Declare Sub Usb_open_file
$regfile = "m16def.dat"
$crystal = 16000000
$hwstack = 32
$swstack = 20
$framesize = 40
$baud = 9600
Config Porta = Output
Config Portb = Output
Config Portc = Output
Config Portd = Output
Config Com1 = Dummy , Synchrone = 0 , Parity = None , Stopbits = 1 , Databits = 8 , Clockpol = 0
Open "COM1:" For Binary As #1
Open "comd.3:9600,8,n,1" For Output As #2
Config Pind.4 = Input
On Urxc Usbisr
Enable Urxc
Enable Interrupts
Dim I As Byte
Dim Daten As Byte
Dim Empfangen As String * 50
Dim Empf_array(15) As String * 50
Dim Empf_pointer As Byte
Dim Usb_found As Bit
Dim Usb_fin As Bit
Dim Eof_usb As Bit
Dim Command_set As String * 5
Dim Filename As String * 15
Dim Rts As Bit
Empfangen = ""
Command_set = ""
Usb_fin = 0
Filename = ""
Usb_found = 0
Empf_pointer = 0
Eof_usb = 0
Waitms 5000
Gosub Usb_init
Do
If Usb_found = 1 And Usb_fin = 0 Then
Gosub Usb_dir
Gosub Usb_open_file
Usb_fin = 1
End If
If Eof_usb = 1 Then
For I = 1 To 15
If Empf_array(i) <> "" Then
Print #2 , Empf_array(i)
End If
Empf_array(i) = ""
Next I
Eof_usb = 0
End If
Loop
End
'Empfangsroutine
Usbisr:
Daten = Udr
If Daten = 13 Or Daten = 10 Then 'CR oder LF empfangen ?
If Instr(empfangen , "Device Detected") <> 0 Then
Usb_found = 1
Usb_fin = 0
End If
If Instr(empfangen , "Device Removed") <> 0 Or Instr(empfangen , "No Device") <> 0 Then
Usb_found = 0
End If
If Empfangen <> "" Then
If Command_set = "DIR" Then
Filename = Trim(empfangen)
End If
If Command_set = "RD" Then
If Instr(empfangen , "[END]") = 0 Then
Incr Empf_pointer
Empf_array(empf_pointer) = Empfangen
Else
Empf_pointer = 0
Eof_usb = 1
End If
End If
End If
Empfangen = ""
Else
Empfangen = Empfangen + Chr(daten)
End If
Return
'Usb funstions
Usb_init:
Gosub Usb_wait
Command_set = "ECS"
Print "ECS" ; Chr(13);
Gosub Usb_wait
Return
Usb_dir:
Gosub Usb_wait
Command_set = "DIR"
Print "DIR" ; Chr(13);
Gosub Usb_wait
Return
Usb_open_file:
Gosub Usb_wait
Command_set = "RD"
Print "RD TEST.txt" ; Chr(13);
Gosub Usb_wait
Return
Usb_wait:
While Rts <> 0 'Solange warten bis Usb Host bereit zum arbeiten ist
Rts = Pind.4
Wend
Return
|
Allerdings funktioniert das Auswerten der Usb_wait nicht. Oder anders gesagt die Commands werden alle nacheinander gefeuert, ohne zu warten ob der Vnc mit dem Senden der Antworten auf das letzte Command auch fertig ist. Das hat ein wildes Zerhacken der Antworten zur Folge. Hat jemand eine Idee wie sich das auswerten lässt ?
Datum:
Hi, ich habe damals schlicht auf das ack des vnc gewartet. Er schickt am Ende immer 'D:>', werte also einfach den Empfangsstring aus. Ich habe sogar nur auf '>' gewartet. Besser ist natuerlich auf den gesamten String zu warten. Nach dessen Empfang kann weiter gearbeitet werden.
Datum:
@ VNC_tester, immer dann, wenn Du etwas an den VDIP sendest, verarbeitet der die Daten oder das Kommando und sendet anschließend eine Rückmeldung. Diese Rückmeldung musst du abwarten und analysieren. (Analysieren deswegen, weil ja auch Fehlermeldungen kommen könnten). Erst danach darfst Du die nächste Aktion starten. Übrigens gibt es einen Modus, der sich - sofern ich es rechig erinnere - SCS (Short Command Set) nennt. Hier sind die Dialoge wesentlich kompakter realisierbar (es müssen nur 2 Zeichen und nicht ellenlange Strings verglichen werden). mfg Michael S.
Datum:
Vielen Dank das auswerten funktioniert jetzt super wenn ich in der Usb_wait das "D:" als Acknowledge auswerte. Zwei kleinere Fragen kamen mir allerdings gerade noch auf. In welcher Reihenfolge werden dir Datein per "Dir" aufgelistet ? Wird dort alphabetisch soriert ? Zum was sendet der VNC1, wenn er gerade startet und kein Usb Stick angeschlossen ist ? Wird dann trotzdem ein "D:" gesendet ? Ich brauche noch irgendein Kriterium an dem ich festmachen kann, dass der Vnc mit seiner Initalisierung fertig ist um danach den entsprechenden select Command Mode Befehl senden zu können. Gruß und Dank :)
E-Mail-Benachrichtigung einschalten
Neu: Seitenaufteilung einschalten