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
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
voidputUARTByte(uint8_tval)
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