Ich verwende einen Vinculum in einem Gerät, das entweder per USB mit einem PC verbunden ist, oder Stanalone mit USB Stick arbeitet. Dazu frage ich mit dem QSS (Query Slave Status) den Zustand der Verbindung zum PC ab. Sobald ich das USB Kabel zum PC anstecke ist auch Bit 0 (connected) gesetzt und die USB Verbindung funktioniert. Wenn ich das USB Kabel aber abziehe, bleibt dieses Bit gesetzt, bis ich dem Vinculum kurz die Spannung wegnehme. Die neueste Firmeware habe ich schon drauf, daran liegt es also nicht. Hat schonmal jemand den Vinculum als Slave verwendet, und kann sagen ob das Problem an meiner Software liegt, oder ob die VDPS Firmeware an dieser Stelle einen Bug hat ?
Hallo, ich habe hier das gleiche Phänomen. Das scheint also ein Firmwarefehler zu sein (V3.66). Konntest du das Problem inzwischen lösen? Ist ja schon einige Monate her... Ich habe hier ausserdem noch folgendes Problem: Wenn der Vinculum im Kommandomodus ist und Daten vom PC aus gesendet werden, dann bleibt die PC-Software (Hyperterm) hängen. Hast du das gleiche Problem? Gruss, Markus
Tja, Der Vinculum... Habe hier mit der Firmware 3.66 das Problem, dass sich das angeschlossene Device (ein FT232RL) zwar meldet, aber dann steh ich auf dem Schlauch, ecs und ipa usw gehen zwar noch, aber ich wüßte halt auch gern, wie ich das überprüfen kann. Wenn ich wüßte, wie man das mit dem Oszilloskop anschaut, hätte ich's schon getan... Weiß einer von Euch Bescheid, wie man mit dem Vinculum am Hyperterminal agiert, daß man da was ordentliches rausbekommt?
Hallo! Das Thema ist zwar schon etwas älter, aber da ich sonst nichts gefunden habe, grabe ich ihn mal wieder aus, da das Thema noch ungelöst scheint. Hat schon jemand erfolgreiche eine Verbindung zwischen VDIP1 bzw. VNC1L und PC hergestellt und Zeichen an den PC senden können oder vom PC empfangen? Ich möchte einen Datenlogger bauen, der per PC gesteuert und mit Energie versorgt wird und die Daten auf einem USB Stick speichert. - VDIP auf VDPS (3.66) Firmware geflasht - VDIP_BD7 an einen Spannungsteiler wie im VNC1L Firmware Manual Seite 12 beschrieben angeschlossen (des war ein Gefummel, echt schade das der Pin nicht rausgeführt wurde) - USB Port1-Datenleitungen mit empfohlenen Kondensatoren versehen - Serielle Kommunikation mit ATMega644 (RX<->TX, TX->RX, VDIP_CTS an GND) - VDIP DSR# und DTR# an ATMega um Datenmodus einzuschalten und Bereitschaft des VDIP abzufragen - Commandmode arbeitet korrekt, USB Stick wird erkannt, gelesen geschrieben - PC Host an USB1 wird erkannt und auf PC virtueller COM-Port erzeugt - Im Gerätemanager als funktionsfähig angezeigt - QSS und SC S und QP1 funktionieren und zeigen PC an - Alles auf 9600Baud,1Start,1Stop,keine Parity eingestellt - Befehlsfolge und Signalfolge auf Seite 67 des Manuals benutzt - Hyperterminal zum Senden und Empfangen auf PC - Sende Zeichen vom ATMega im Datenmodus - auf PC kommt aber nichts an - Von PC ein bis zwei Zeichen senden, friert Hyperterminal ein, ATmega empfängt nichts - Testweise mal an ein MAX232 gehängt und Steuersignale manuell gesetzt - Befehle per Hyperterminal am PC eingegeben, gleiches Ergebnis - Auch den Device Send Data Befehl im Commandmode ausprobiert - Zeichen gesenden - am PC kommt nichts an Ich habe noch keinen Schaltplan, da ich erstmal zum Testen freifliegend verkabelt habe. ich bin jetzt etwas ratlos und frustriert. Habe extra die 30 Euro ausgegeben, damit ich keinen Stress mit Löten, PC und USB Anbindung habe und nun sitze ich schon ein paar Tage dran. :( Beste Grüße, Michael.
Die Kommunikation mit dem PC läuft bei mir wunderbar. So schalte ich auf den Slave Modus um, so dass sich der VNC wie ein FT232/FT245 verhält (Baudrate und Interfacetyp zum µC bleiben aber natürlich fest, d.h. die Baudrate die man am PC einstellt ist egal).
1 | vnc_putc(0x98); // Query Slave Status |
2 | vnc_putc(0x0D); |
3 | status=vnc_getchar(); |
4 | vnc_clearbuffer(); |
5 | if ((!(status&1))||(status&2)) // Not connected or suspended |
6 | return VNC_NODEVICE; |
7 | |
8 | vnc_clearbuffer(); |
9 | vnc_putc(0x86); // Use PC as active Drive |
10 | vnc_putc(0x20); |
11 | vnc_putc('S'); |
12 | vnc_putc(0x0D); |
13 | status=vnc_answer(); |
14 | if (status) |
15 | return status; |
16 | |
17 | VNC_DATAREQ=0; // activate FT232/245 mode |
18 | while (VNC_DATAACK); // wait for ready |
Hallo Benedikt, danke für deine Antwort. Mit dem Wissen das es gehen sollte, habe ich nochmal alles kontrolliert und 2 Fehler gefunden. Ich hatte DATAREQ# und DATAACK vertauscht (war wohl schon zu spät) und ich habe den PIN Toggle über PIND |= (1<<PD4) realisiert, was laut ATMEGA644 Datenblatt den passenden Ausgang invertieren soll, leider ändern sich (im Simulator) mehrere Bits von PORTD. Ist das ein BUG oder habe ich die Doku falsch verstanden? Jedenfalls jetzt geht es auch bei mir. :) Es haben sich fünf neuen Fragen ergeben, die sich mir nicht aus der Doku erschliessen: 1) Kann man den FT245 Modus des VNC1L irgendwie konfigurieren? Etwa mit "Set Data Characteristics (FSD)"? 2) Hängt die Baudrate des FT232 Modus mit der im Monitor zusammen bzw. wenn ich die Baudrate mit SBD setze, gilt das für Monitor und FT232 Modus? 3) Wie kann der PC dem VNC1L mitteilen, dass er Daten senden möchte? Beim Austesten habe ich festgestellt, dass 4 Zeichen vom PC angekommen, wenn ich sie per Terminal eingebe und dann im VCN1L auf den Datenmodus wechsle. Ist das Zufall das gerade 4 Bytes zwischengesspeichert werden? Oder ist das schon der übliche Weg? Der PC sendet bis zu 4 Bytes und der VNC1L fragt ständig mit QSS ab und schaltet in den Datamode, wenn das dritte Byte vom QSS-Befehl $01 liefert. Und dann kann der PC mehr Daten senden. 4) Muss ich noch irgendwas beachten, dass auch immer garantiert alle Bytes beim PC ankommen? Manchmal fehlt das letzte Zeichen das ich an den PC übertragen habe. 5) Woran kann man erkennen, welcher USB-Stick funktioniert und welcher nicht? Ich habe bisher 4 Sticks getestet, 2 funktionierten (Noname 1GB und EMTEC 2GB), 2 nicht (LG Drive USB 512MB, Cruzer Micro U3 8GB). Hier das Anschlussschema: ATMega644 <-> VDIP1 PD5 AD4 (DataAck Ausgang) PD4 AD5 (DataReq Eingang) PD1 (TXD) AD1 (RXD) PD0 (RXD) AD0 (TXD) AD3 (CTS Eingang) an GND Und mein Quelltext (AVR Studio 4.17 und WinAVR 20090313) in der momentanen Version:
1 | /// Ein Byte über den UART senden
|
2 | void putUARTByte(uint8_t val) |
3 | {
|
4 | /* Wait for empty transmit buffer */
|
5 | while ( !( UCSR0A & (1<<UDRE0)) ); |
6 | /* Put data into buffer, sends the data */
|
7 | UDR0 = val; |
8 | }
|
9 | /// Wartet bis das Zeichen über die UART-Schnittstelle gesendet wurde
|
10 | void waitUARTByteSent() |
11 | {
|
12 | /* Wait for empty transmit buffer */
|
13 | while ( !( UCSR0A & (1<<UDRE0)) ); |
14 | }
|
15 | /// bis zu 255 Bytes über UART senden
|
16 | void putUARTBytes(const uint8_t *buff, uint8_t size) |
17 | {
|
18 | for (uint8_t i=0; i<size; i++) { |
19 | uint8_t ch = buff[i]; |
20 | putUARTByte(ch); |
21 | }
|
22 | waitUARTByteSent(); |
23 | }
|
24 | // VDIP1 Kontrolle //////////////////////////////////
|
25 | #define VDIP_CTRL_PORT PORTD
|
26 | #define VDIP_CTRL_DIRECTION DDRD
|
27 | #define VDIP_CTRL_INPUT PIND
|
28 | #define VDIP_DATA_REQUEST_OUTPUT (1<<PD4)
|
29 | #define VDIP_DATA_DATA_SET_READY (1<<PD5)
|
30 | const uint8_t scs[] = {0x53, 0x43, 0x53,0x0D}; // SCS |
31 | const uint8_t ipa[] = {0x91, 0x0D}; // IPH |
32 | const uint8_t sc_s[] = {0x86, 0x20,0x53,0x0D}; // SC S |
33 | const uint8_t hello[] = {"Hallo PC!\x0DHier ist VDIP1(VDPS).\x0D\x00"}; |
34 | /// Länge einer nullterminierten Zeichenkette ermitteln
|
35 | uint8_t getLength(const uint8_t *buff) |
36 | {
|
37 | uint8_t len=0; |
38 | while (buff[len] != 0) { |
39 | // uint8_t ch = buff[len]; // Debugging
|
40 | len++; |
41 | }
|
42 | return len; |
43 | }
|
44 | /// Eingabezwischenspeicher leeren
|
45 | void clearBuffer() |
46 | {
|
47 | flushUARTRX(); |
48 | }
|
49 | /// Antwort des VNC1L abholen und auswerten
|
50 | uint8_t getVNC1LAnswer() |
51 | {
|
52 | uint8_t ans=0; |
53 | clearBuffer(); // alle Antworten ignorieren |
54 | return ans; |
55 | }
|
56 | /// Befehle an VNC1L; Ende durch 0x0D markiert
|
57 | void sendVNC1LCommand(const uint8_t *buff) |
58 | {
|
59 | clearBuffer(); |
60 | uint8_t i=0; |
61 | uint8_t ch; |
62 | do { |
63 | ch = buff[i++]; |
64 | putUARTByte(ch); |
65 | } while(ch != 0x0D); |
66 | waitUARTByteSent(); |
67 | }
|
68 | /// Daten (bis zu 255 Byte) im DataMode des VNC1L an PC senden
|
69 | void sendDataToSlavePort(const uint8_t *buff, uint8_t size) |
70 | {
|
71 | clearBuffer(); |
72 | VDIP_CTRL_PORT &= ~VDIP_DATA_REQUEST_OUTPUT; |
73 | while (VDIP_CTRL_INPUT&VDIP_DATA_DATA_SET_READY); |
74 | putUARTBytes(buff,size); |
75 | delayOne10Msec(10); // 10 1/10 MS warten (Timer1 wird benutzt) |
76 | VDIP_CTRL_PORT |= VDIP_DATA_REQUEST_OUTPUT; |
77 | }
|
78 | /// Einmaliger Aufruf zum Initalisieren der VDIP Kontrolle
|
79 | void initVDIP() |
80 | {
|
81 | VDIP_CTRL_DIRECTION |= VDIP_DATA_REQUEST_OUTPUT; // Output DataReq |
82 | VDIP_CTRL_PORT |= VDIP_DATA_REQUEST_OUTPUT; // CommandMode |
83 | VDIP_CTRL_DIRECTION &= ~VDIP_DATA_DATA_SET_READY; // Input |
84 | VDIP_CTRL_PORT &= ~VDIP_DATA_DATA_SET_READY; // Kein Pullup |
85 | clearBuffer(); |
86 | sendVNC1LCommand(scs); |
87 | getVNC1LAnswer(); |
88 | sendVNC1LCommand(ipa); |
89 | getVNC1LAnswer(); |
90 | sendVNC1LCommand(sc_s); |
91 | getVNC1LAnswer(); |
92 | }
|
93 | int main () |
94 | {
|
95 | sei(); // Global Interrupt Enable auf true setzen |
96 | initUART(); |
97 | delayOne10Msec(50000); // 5 Sekunden warten |
98 | initVDIP(); |
99 | while (1) { |
100 | sendDataToSlavePort(hello,getLength(hello)); |
101 | }
|
102 | return 0; |
103 | }
|
Grüße.
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.