Hallo, ich verwende das STI100 USB Interface (VNC1L Chip). Soweit funktioniert alles, ich kann die Daten auf den Stick schreiben und Lesen. Aber es gibt ein Problem. Die Daten (jeweils ca 400 byte) werden mit 20 Hz, also alle 50ms geschrieben. Ich benutze den /CTS Pin, der signalisiert wann neue Daten geschrieben werden können. Das Problem ist nun, dass das Ding anscheinend zu langsam schreibt, sprich der /CTS Pin ist teilweise nach 50ms noch nicht wieder auf LOW, so dass keine neuen Daten angenommen werden. Habe es mit unterschiedlichen USB Sticks probiert - das Verhalten bleibt gleich. Wenn ich den Pins nicht auswerte und einfach drauf los schreibe, werden teilweise vorhergehende Datensätze im Buffer überschrieben. Hat jemand eine Idee, wie man das lösen könnte? Noch einen externen Buffer vorschalten? Danke!
>CTS Nimm mal RTS. In diesen Beitrag findest Du auch was zur RTS/CTS Nutzung: Beitrag "USB-Stick am Mikrocontroller VNC1L"
Sorry, ich habe mich verschrieben - es ist natürlich RTS. Den Thread kenne ich schon, aber habe nichts gefunden, was mir helfen würde. Kann es sein, dass die "OPW" und "CLF" Befehle so langsam sind? Ich öffne und schließe die Datei so vor/nach jedem Schreibvorgang
Wartest Du nach jeden Befehl auch auf die Bestätigung (PROMPT "D:\>") bevor Du einen neuen Befehl sendest? Welche Baudrate?
Die Baudrate ist bei 115.200, das gleiche Verhalten bei 57.600. "D:\>" warte ich nicht ab, ich werte lediglich den RTS Pin aus. Oder kommt der Prompt etwa vor dem LOW auf dem Pin?
>Die Baudrate ist bei 115.200, das gleiche Verhalten bei 57.600. >"D:\>" warte ich nicht ab, ich werte lediglich den RTS Pin aus. Das reicht nicht aus. RTS-Pin Auswertung ist einige Ebenen tiefer angesetzt und betrifft nur den Buffer. Nur die Prompt-Auswertung liefert zuverlässig ein Ergebnis, wenn ein Befehl akzeptiert und ausgeführt wurde. Erst dann darf weiter im Protokoll verfahren werden.
Aber würde es mein Problem dann nicht weiter verschlimmern? Wenn schon alleine mit der RTS-Pin Auswertung die Datenrate nicht eingehalten werden kann, dann wird es bei der Prompt-Auswertung eigentlich noch langsamer, oder?
Würdest du mir erklären wieso? Irgendwie komme ich da logisch nicht hinterher: Kann es also passieren, dass das Interface schon neue Daten annehmen kann, obwohl der RTS Pin noch etwas anderes signalisiert?
Betrachte das UART-Interface unabhängig von der Befehlsebene. Der serielle Datenstrom wird über die Handshakesignale geregelt (VNC1L-FIFO ist nicht sehr groß!). Die eigentliche Kommunikation mit den Disk-Commands. Die meisten Commands liefern an Ende ein Prompt, damit man weiß, dass der Befehl ausgeführt wurde. Die Ausführungsdauer eines Befehls ist von vielen Faktoren abhängig, wie zB. dem USB-Sticktyp, der Formatierung, RW-Geschwindigkeit, Abnutzung usw. Im Usermanual zur Firmware steht vieles nützliches zur Kommunikaton drin. Lade Dir das mal runter und beschäftige Dich damit;-)
http://www.vinculum.com/documents/fwspecs/UM_VinculumFirmware_V205.pdf Da ist das Manual, meinst du eine bestimmte Stelle? Mir ist immernoch nicht klar, warum man sich an die Prompt-Ausgabe halten soll. Ich bin immer davon ausgegangen, dass der RTS Pin richtig signalisiert, wann gesendet werden kann.
Der VNC1L hat einen FIFO-Buffer. Wenn der voll wird, zeigt das der VNC1L durch setzen von RTS an. Der eigentliche Prozessor in VNC1L arbeitet auch nur den FIFO ab, kümmert sich aber nicht um die Ebene der UART-Kommunikation. Er geht immer davon aus, das die Daten im FIFO gültig vorliegen. Ohne die Prompt-Auswertung kommt nichts zuverlässiges raus. Vielleicht klappt es mit einen bestimmten Stick auch mit großen DELAYs nach jedem Befehl, bei einen anderen Stick muss es aber nicht mehr funktionieren. Die gesamte Commando-Ebene basiert auf der PROMPT-Bestätigung. Nur mal am Rande: Der VNC1L ist nicht als Einsteiger-Projekt geeignet. Dafür sind schon einige grundsätzliche Schnittstellen- und Mikrocontroller-Erfahrungen erforderlich.
Hallo Matthias, ich glaube du verstehst mich falsch. Die Befehlsebene funktioniert bei mir einwandfrei. Wenn die Daten mit WRF geschrieben werden, wird zwischendurch immer wieder der RTS Pin gesetzt. Dieser Vorgang dauert mit nur 400 bytes schon über 50ms, was für meine Anwendung zu langsam ist.
Hier sind die möglichen Transferraten: http://www.ftdichip.com/Support/Documents/AppNotes/AN_112_VNC1L%20Data%20Transfer%20Speeds.pdf Riesige Geschwindigkeiten kannst Du jedoch nicht erwarten. Um Deine 400 Byte seriell mit 115200 Baud zu senden, vergehen schon theoretisch gut 35ms, ein kontinuierlicher Transfer, ohne jede Verzögerung vorausgesetzt. Also sind Deine 50ms schon zielmlich realistisch.
Hmm mist...wie könnte man das denn noch beschleunigen? Vielleicht einen zweiten µC, der als Puffer arbeitet?
Höhere Baudrate, Parallel-Interface. 20x pro Sekunde war auf einen USB-Stick schreiben, ist auch nicht ideal. Macht der nicht lange mit. Alternativ: Daten in einem Datenflash oder SRAM sammeln und nur in größeren Abständen auf Stick schreiben.
>> Alternativ: Daten in einem Datenflash oder SRAM sammeln und nur in >> größeren Abständen auf Stick schreiben. Das wäre eine gute Alternative. Nach welchen Bausteinen könnte ich mich umschauen?
Habe noch was vergessen: Was ich schon ausprobiert habe: ich sammle meine Daten in einem String und schreibe nur noch 5x pro Sekunde, jeweils etwa 1kB.
usb schrieb: > Was ich schon ausprobiert habe: ich sammle meine Daten in einem String > und schreibe nur noch 5x pro Sekunde, jeweils etwa 1kB. 18000 Schreibvorgänge / Stunde ... Immernoch sehr viel für einen Stick.
Och das wird nur an einem Rennfahrzeug benutzt, pro Wochenende ist es ca 3 Stunden unterwegs. Im Jahr sind es vielleicht 10 Wochenenden, also ca 30-40 Betriebsstunden. Wenn dann 2x Sticks pro Jahr fällig sind, kann ich damit leben :) Viel wichtiger wäre die Frage, die man die Daten buffern könnte, damit ich letzendlich alles schreiben kann. Würde es etwas bringen die Baudrate noch weiter zu steigern?
... Ich öffne und schließe die Datei so vor/nach jedem Schreibvorgang ... Verstehe ich das richtig, 20 mal pro Sekunden 400 Bytes schreiben und jedesmal die Datei offnen & schließen?
Nein, mittlerweile 5x pro Sekunde Datei öffnen, ca 1000 Byte schreiben, Datei schließen.
... 5x pro Sekunde Datei öffnen ... Was spricht dagegen einfach munter zu schreiben ohne die Datei ständig zu öffnen & zu schließen?
Da ist auch was dran - spricht eigentlich nichts gegen. Ich weiß nur nich aus dem Kopf, ob die geschriebenen Daten verloren gehen, wenn die Versorgungsspannung abgeschaltet wird und die Datei nicht geschlossen wurde.
Du könntest dir auch überlegen, ob Du so viele Daten brauchst, oder ob man hier eine Reduktion durch eine Vorauswertung erzielen kann. 20 mal pro Sekunde 400 Bytes erscheinen mir für ein Modellrennauto recht viele Daten. Wenn Du hier Werte loggst wie z.B. Akkuspannung, Temperaturen etc, dann reicht dir dafür auch locker 1 Messwert pro Sekunde.
Ach so nochwas zur Datenreduktion, wie speicherst Du die Daten? Als Binärwerte oder als String? Auch hier kann man mit binären Daten deutlich die Menge reduzieren.
Ne, das ist kein Modellrennauto sondern ein Rennmotorrad in groß :) Die Daten sind eigentlich schon recht stark gefiltert - es werden alle 200ms der GPGGA und GPRMC Strings vom GPS Sensor und alle 50 ms Werte wie Drehzahl, Reifentemperaturen, Gasgriffstellung usw gespeichert. 1x pro Sekunde wäre ggf zu langsam, um beispielsweise Stürze nachvollziehen zu können oder das Verhalten von 2 Fahrer zu vergleichen (Bremspunkt, Rausbeschleunigen). Die beiden GPS Strings ergeben zusammen etwa 400byte alle 200ms, die restlichen Daten ergeben etwa 500 byte (grob aus dem Kopf). Damit werden etwa 900byte, oder aufgerundet 1000 byte alle 200ms, also 5mal pro Sekunde geschrieben.
Hmmm ich speichere die Daten als String, entweder stehe ich auf dem
Schlauch oder verstehe Dich falsch - wenn ich zb die "15" speichern
will, wären das 2 Stellen als String aber 4 Stellen als Binärzahl, die
übertragen werden müssten ("1111")
Hi >wenn ich zb die "15" speichern >will, wären das 2 Stellen als String aber 4 Stellen als Binärzahl, die >übertragen werden müssten ("1111") Nein. 15 als String: $31,$35, evtl. noch $00 15 binär : $0F MfG Spess
Achso, war mir gar nicht bewusst - wann wird denn die Darstellung nochmal gewandelt?
Die GPS Strings geben 400 Bytes Wahnsinn! Im Prinzip ist das doch nix anderes als z.B. bei UTM Koordinaten "32 U 0528348 UTM 5396972" Wie zum Geier verbrätst Du da 400 Bytes?????? Und auch diese UTM Koordinaten lassen sich deutlich schrunpfen indem man nur die Werte binär als 4, 6, oder 8 Byte Integer ablegt.
Ja, ich speichere die noch komplett ab. Vielleicht sollte ich da mal anfangen und nur die wirklich relevanten Daten vor dem Speichern schon extrahieren. Wie kann man denn die Werte direkt als Binärdaten rausschreiben? Ich muss ja die Daten auf den UART rausschicken, und wenn eine Variable "i" beispielsweise den Wert 15 hat, dann wird "print i" 15 als String rausschicken.
Selbst wenn Du die weiter als String abspeicherst. Eine Koordinate (sehen wir von der Höhe über NN ab, die ist eh nicht so genau) besteht unabhängig vom verwendeten Koordinatensystem aus einem Hochwert und einem Rechtswert. bei UTM hast Du zusätzlich die Region z.B. "32U". Bei UTM haben die beiden Werte dann noch 7 Stellen. Macht 117 Bytes wenn man auf irgendwelche Trennzeichen wie Blanks oder Kommas verzichtet. Das ist weniger als 1/20 deiner 400 Bytes! Die beiden 7 stelligen Zahlen könntest Du als long Wert abspeichern (C Funktion alol()). Dann hättest Du statt 7 Bytes ASCII nur 4 Bytes für den Long Wert. Dazu musst Du aber die Datei binär öffnen und binär schreiben. Und Du kannst die Werte nicht mehr einfach im Texteditor sehen. hast Du z.B. Koordinaten in Winkel, Minuten, Sekunden und Dezimalsekunden dann sähe es vieleicht so aus N34 25'36.5'' W130 56'43,1'' Auch das sind trotz der unnötigen Blanks und Minuten bzw. Sekunden Kennzeichen weniger als 30 Bytes. Ist also noch massig Optimierungspotential, auch wenn Du weiter einfach lesbare BCD Zahlen speicherst.
Weitere Optimierungsmöglichkeit: Da deine Rennstrecke wohl nicht größer als 10 km in NordSüd bzw OstWest Richung sein wird, könntest Du Dich auf die letzten 5 Stellen (Auflösung 1m) beschränken und hättest 10 Bytes als Text (BCD codiert) oder 4 Bytes als 2 mal Integer Werte für ein Koordinaten-Datensatz. Die Absoluten Koordinaten könnte man einmalig zu Beginn der Messung abspeichern, und alle weiteren Werte relativ dazu sehen. Das wäre mal locker (fast) Faktor 100 gespart :-)
Du hast Recht! Vielen Dank, dann mache ich mich erstmal dran, diese Punkte zu verbessern - möglicherweise reicht es ja schon aus :)
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.