Geschwindigkeit Serielle Schnittstelle

Geschwindigkeit Serielle Schnittstelle (42 Beiträge, 494 Mal gelesen)

Du bist nicht angemeldet. [ Login/Registrieren ]

Hallo,

ich arbeite gerade an einem kleinen Projekt bei dem ich über die serielle Schnittstelle Daten die ich aus einem Video ermittle senden möchte. Ich wollte eigentlich pro Frame ein Paket bestehend aus 1xint8 als start + 2xint8 und 4xint16 Daten + 1xint8 als Abschluss senden. Jedoch hab ich jetzt irgendwie das Problem das die Übertragung viel zu langsam geht. Jetzt wollte ich mal fragen ob irgendjemand eine Ahnung hat ob das Zeittechnisch überhaupt möglich ist. Die Kamera liefert 30frames/sec ich sende also alle 3,3ms 12 byte.
Kann man sich das irgendwie aus Baudrate, und den restlichen Einstellungen errechnen?

mfg Johannes

das wären pro sekunde gut 303 Pakete oder 3636 byte oder 29090 bit/sec.

Spezifiziert ist die RS232 für 115.200 Bit/sec.
Effektiv gehen aber um die 92000Bit/sec. drüber

Spedi

...mehr Power...

ok danke, dann liegt es entweder an meiner Programmierung oder an meinem Serial Port Monitor von Eltima Software. Ich werds mal mit dem Windowsterminal versuchen.
Falls sich jemand in C auskennt hier mein Code zum senden:

void serialWriteWord(byte sign) {
/*
* serialWriteByte() -- schreibt ein Character auf den Port
*/

unsigned long writtenBytes;

if (WriteFile(port, &sign, 1, &writtenBytes, NULL) == 0) {
printf("Fehler beim Schreiben auf Port\n");
}
}

mfg Johannes

hallo nochmal,

ich habs jetzt mit dem hyperterminal versucht und da hab ich das problem nicht das alles so ewig lange dauert, also liegt es scheinbar an dem Serial Port Monitor.

mfg Johannes

Hallo, ich hab jetzt noch eine weitere Frage zur seriellen Schnittstelle.
Ich sende über die serielle Schnittstelle Daten die auf der Gegenseite verarbeitet werden, wobei für die verabeitung unteranderem auch die Zeit welche zum senden nötig war sehr wichtig ist. Jetzt hab ich mir gedacht um überhaupt irgendwie die Zeit schätzen zu können bau ich mir auf der sendeseite einen Speicher auf der die zu sendenden Daten zwischenspeichert. Von der Empfangsseite sende ich dann in regelmäßigen Abständen (So oft das der Speicher sicher nie überläuft) eine Sendeanforderung zum Sender und speichere die Zeit zu der gesendet wurde. Der Empfänger antwortet auf das Empfangene Codewort mit dem nächsten Datenbit.
Um die Zeit dann schätzen zu können dachte ich mir ich nehme dann einfach Codwortlänge gleich Datenlänge und die Zeit die sich für den Sende Emfpangsvorgang ergibt *1/2.
Gibt es für die ermittlung der Sendezeit vielleicht auch einfachere Möglichkeiten. Ist meine Idee zu ungenau?

mfg Johannes

Ist meine Idee zu ungenau?

ich denke da könnten irgendwann Probleme auftreten, wenn die CPU gerade anderweitig voll beschäftigt ist. Dafür könntest dann ein Realtime-OS gebrauchen.
http://de.wikipedia.org/wiki/Echtzeitbetriebssystem

Ja sicher doch, aber das hat doch nix mit der ermittlung der Übertragungszeit zu tun. Die Kommunikation funktioniert so prinzipell schon (halt nur mit senden ins blaue und hoffen das der empfänger die daten auch bekommt)

mfg Johannes

Hast du die serielle Schnittstelle den vorher auch richtig "eingestellt"?
Also Baudrate usw.?

vor allem: ist der Sendepuffer (16550er) auch wirklich aktiv?
ohne den schnalzt nämlich die IRQ-Belastung nach oben + bremst jede CPU aus...

Baudrate - 38400+, was solls, Handshake würd ich noch in Frage stellen.

Ok, die Übertragung funktioniert schon, die Einstellungen von wegen Baudrate und dergleichen sind also kein Problem mehr. Mir geht es nur darum zu ermitteln wie lange er für die übertragung jeder einzelnen Frame gebraucht hat.

mfg Johannes

?

Kannst dir ja berechnen.

Baudrate ist bei der seriellen gleichbedeutend mit Bitrate (keine spezielle Kodierung). Pro Byte werden 1 Startbit, 1 Stopbit und 8 Datenbits übertragen, macht also 10 Bit / Byte

Wenn du nun sagst du überträgst 10 Bit * 12 (Anzahl der Informationen in Bytes) = 120Bit und das Ganze 30 mal / Sekunde = 3600 Bit ... so hast du ja eh schon deine Information.

Wenn der Sturm losbricht,
verstummen die Einen vor Schrecken,
und die Anderen breiten, einem Adler gleich, die Flügel aus
und schwingen sich empor.

Das dachte ich mir auch, nur komm ich da mit dem Timing nicht ganz klar und die Zeit ist ja jehne welche die Übertragung an sich benötigt. Nur wer sagt mir wieviel verzögerung z.B. ensteht nach dem ich die daten in den (mit C) in den Sendebuffer geschrieben hat bis die daten wirklich gesendet werden, oder wie viel verzögerung ich auf der Empfangsseite habe. Ich denke auf das hab ich ja nicht wirklich einen Einfluss und es wird denke ich auch schwer vorherzusagen sein da man sicher keine so tiefen einblicke in Windows nehmen kann.

mfg Johannes

Also wenn die Daten erstmal im Sendebuffer stehen, gehen sie sofort raus, das erledigt die HW. Dich würde also eher die Zeit interessieren wie lange C braucht um sie dorthin zu schreiben

Und da hast du recht, darauf hast du keinen Einfluss. Das kann sofort sein, bei ausgelastetem PC aber auch erst eine Sekunde später. Dafür ist der Scheduler von Windows zuständig, auf den du - wie du richtig bemerkt hast - keinerlei Einfluss hast.

Wenn du zeitdterministisches Verhalten brauchst, musst du dich nach einem Real Time OS umsehen (aber auch dort wirst du nur in Grenzen eine Genauigkeit erhalten).

Was du jedoch machen kannst:
Du weisst ja dass die Abstände zwischen den Frames äquidistant sind und somit hast du immer wenn ein neues Frame kommt eh die Information, welche Zeit dazwischen gelegen hat. Es kann dir also egal sein, ob das eine Frame jetzt etwas früher oder später kommt.

Wenn der Sturm losbricht,
verstummen die Einen vor Schrecken,
und die Anderen breiten, einem Adler gleich, die Flügel aus
und schwingen sich empor.

Das mit den Frames ist so nicht ganz richtig, da die Bildverarbeitung auch je nach Rechnerauslastung mal 12 Frames, mal 15 Frames mal wieder nur 8 Frames .. schaft und ich eigentlich nur Sende wenn auch Informationen zum Senden da sind. Und es ist besonders Wichtig für jedes einzelne Frame die verzögerung zu ermitteln. Selbst wenn ich in fixen Zeitabständen sende ist es so nicht für jedes Frame möglich absolut die Verzögerung zu errechnen, da ich sie ja vom ersten Frame wiederum auch nicht weiß (und das ganze würde dann glaube ich auch nur theoretisch funktionieren)
Ich glaube die einzige Möglichkeit die verzögerung auch nur in Ansätzen abschätzen zu können ist oben beschriebenes Sende/Empfangsverfahren oder?

mfg Johannes

Evtl. das Ganze mal von der anderen Seite anpacken

Ich schätze mal du verarbeitest in der Bildverarbeitung immer das aktuellste Frame und lässt evtl. dazwischenliegende Frames aus. Könntest du nicht die Frames mitzählen und einfach jeweils die aktueller Framenummer dann über die serielle mitliefern? Macht 4 bytes für einen Integer Wert.

Wenn der Sturm losbricht,
verstummen die Einen vor Schrecken,
und die Anderen breiten, einem Adler gleich, die Flügel aus
und schwingen sich empor.

Ja aber das hilft mir doch nicht bei meinem Timing. Auf der Anderen Seite ist ein Roboter der die Teile welche mit Bildverarbeitung indentifiziert wurden (Art des Teiles, Geschwindigkeit, Lage,....) vom Förderband weghebt (das ganze ist ein Projekt auf der uni). Ich brauche also wirklich die zeit die ich fürs übertragen benötigt habe, sonst ist der teil weg bevor ich ihn hochheben konnte.

mfg Johannes

Ah jetzt kommt das der ganzen Sache näher

Klingt ja fast nach Automatisierung

Das Problem ist wenn bei dir wirklich ein Windows (oder auch Linux) ohne Echtzeiterweiterungen ins Spiel kommt, gibt es für dich keine Möglichkeit zu sagen, dass das Paket zu einem bestimmten Zeitpunkt raus ist. Woher weisst du eigentlich ob deine Bilderkennung nicht eh schon zu spät dran ist? Auch die kann mal vom Scheduler aufgehalten werden.

Wenn der Sturm losbricht,
verstummen die Einen vor Schrecken,
und die Anderen breiten, einem Adler gleich, die Flügel aus
und schwingen sich empor.

Das ist natürlich ein guter einwand, an das habe ich eigentlich noch nie gedacht. Gibt es eine möglich keit C Code unter WINXP echtzeit laufen zu lassen?
Ich hab ein Video von der ganzen Anwendung wenn es dich interessiert. Da sieht man auch das Problem mit der Verzögerung.

mfg johannes

Unter normalem Windows: Nein, der Scheduler pfeift dir immer dazwischen (ist ja auch der Sinn davon). Wenn du die Latenzzeit minimieren willst kannst du dem entsprechenden Prozess höchste Priorität geben, aber auch dann hast du noch immer keine garantierte Latenzzeit.

Es gibt (angeblich) Auf/Untersätze für Windows die RealTime Möglichkeiten hinzufügen, aber wenn du wirklich derart genau arbeiten musst, wirst du wohl oder übel auf FPGAs und dergleichen ausweichen müssen (auch das die Bildverarbeitung betrifft).
Ich kenne deine Algorithmen nicht, aber ich könnte mir vorstellen dass sich mit Kantenerkennung (Kenny, oder wie heisst der?) Hardwarebasiert was machen lässt.
Momentan würde ich mir jedoch weniger Gedanken darum machen, wie lange C zum Senden des Pakets braucht als vielmehr darum, wann dein Erkennungsalgorithmus denn nun eigentlich losläuft.

Wenn der Sturm losbricht,
verstummen die Einen vor Schrecken,
und die Anderen breiten, einem Adler gleich, die Flügel aus
und schwingen sich empor.

Der läuft los so bald ein neues Frame im Speicher zur Verfügung steht. Aber eigentlich hast du recht und es wird wahrscheinlich mehr zeit dort verblempert von der ich nichts weis als für die Übertragung, ich speichere zwar die Zeit vom holen des bildes bis zum senden (wird auch mit übertragen) aber ich habe ja auch keine Ahnung wie lange es gedauert hat sich das Frame zu holen bzw. wie lange dieses schon im speicher ist.
Die Bildverarbeitung erfolgt derzeit (wir noch auf eine eigene umgestellt) zu Testzwecken noch mit dem ARToolKit. Eine Umstellung auf FPGA oder ähnlichem ist ausgeschlossen, es soll auf einem Winxp rechner laufen.

mfg Johannes

so bald ein neues Frame im Speicher zur Verfügung steht

Hehe, du hast in Wahrheit keine Ahnung ob das Frame nicht schon eine Sekunde alt ist

Der läuft los

Dazwischen kann grad auch nochmal eine Sekunde vergehen´

wie lange es gedauert hat sich das Frame zu holen bzw. wie lange dieses schon
im speicher ist.

Und vor allem: Wann dein Prozess denn eigentlich Prozessorzeit bekommen hat.

Eine Umstellung auf FPGA oder ähnlichem ist ausgeschlossen, es soll auf einem
Winxp rechner laufen.

Dann würde ich sagen wirst du es einfach probieren müssen. Deterministische Aussagen kann man hier einfach keine treffen. Dafür ist der Windows Scheduler nicht geeignet (wurde halt auch nicht dafür entworfen).

Was dir jedoch helfen könnte solche Probleme in den Griff zu bekommen: Schnellen Rechner verwenden, der sich nicht bereits bei der Bildverarbeitung schwer tut. So kannst du die evtl. auftretenden Latenzen niedrig halten.

Achja, in der Win32API findest du einen sogenannten Precision Timer. Der ist ziemlich exakt, löst aber natürlich deine fundamentalen Probleme auch nicht.

Evtl. könntest du noch andenken ob du nicht eine HW Synchronisation zustande bekommst. Kann die Kamera in dem Moment in dem sie das Bild aufnimmt ein Signal ausgeben? Dann könntest du am PC vorbei bei der Steuerung direkt die Zeit erhalten können (aber das is nur mal grob angedacht, müsste man sich genauer überlegen).

Wenn der Sturm losbricht,
verstummen die Einen vor Schrecken,
und die Anderen breiten, einem Adler gleich, die Flügel aus
und schwingen sich empor.

29.02.2008, 10:03 Uhr - Editiert von Somnatic, alte Version: hier

Jetzt wo du das sagt fällt mir ein, das die Kamera glaube ich externe Triggerung kann, muss ich gleich im Handbuch nachlesen. (ist eine Sony FIREWIRE Kamera)

mfg Johannes

So, also externen trigger kann sie (sony dfw x700) nur ist jetzt die frage welche Hardware ich nun für die triggerung noch zusätzlich brauche.

Beim durchlesen der Anleitung ist mir auch noch was aufgefallen. Eigentlich hat doch die Verschlusszeit auch schon einfluss auf das Ganze. Wenn die sehr hoch ist (kann zwischen 1/2000 und 2 s eingestellt werden) dann erübrigt sich sowieso alles andere weil sie viel zu lange ist oder? Ich kenn mich diesbezüglich leider gar nicht aus.

@Somnatic ich hab dir ein Video an deine email geschickt, damit wird vielleicht alles noch ein wenig klarer

mfg Johannes

Eigentlich hat doch die Verschlusszeit auch schon einfluss auf das Ganze

Jap, aber die dürfte eigentlich konstant sein (und hoffentlich nicht 2s

externen trigger

heisst das dass du sie von aussen steuern kannst oder dass die kamera ein entsprechendes signal ausgibt, wenn der verschluss gefallen ist?

Wegen der HW: Du musst (wahrscheinlich, nur mal dahingedacht) deiner Steuereinheit sagen: Genau jetzt ist das Bild aufgenommen worden, das du demnächst ausgewertet bekommst. In der Steuereinheit startet nun der Timer und wartet auf das nächste einkommende Frame. Die Geschwindigkeit des Förderbandes spielt übrigens auch eine Rolle

- aber auch die dürfte (im Zeitbereich der uns interessiert) konstant sein, oder?
Dann solltest du so in der Lage sein, die Geschwindigkeit des Laufbandes miteinzurechnen (muss natürlich die Steueranlage in Echtzeit erledigen) und zur (jetzt veränderten Position gegenüber der Information die du über die serielle bekommst) hinzuzurechnen.

(ich hoffe das war verständlich, und sage nochmal dazu: das sind meine ersten Gedanken darüber, Automatisierung ist nicht mein Spezialgebiet

Wenn der Sturm losbricht,
verstummen die Einen vor Schrecken,
und die Anderen breiten, einem Adler gleich, die Flügel aus
und schwingen sich empor.

Die Geschwindigkeit des Bandes ermitteln wir auch mit der Bildverarbeitung, das funktioniert eh ganz gut.
Der externe Trigger heißt wenn ich einen Impuls reinschicke dann wird ein Bild aufgenommen. Wenn ich diesen Impuls von dem Rechner aus sende mit dem ich den Roboter steuere und die Zeit messe bis die Informationen dann ankommen habe ich eigentlich alle Zeitkonstanten und variablen Zeiten einfach erfasst und müßte um einiges genauer positionieren Können.
Die Frage stellt sich jetzt nur wie ich mit dem Rechner einfach folgenden Impuls genieriere:
http://www.jencam.de/pdf/datenblaetter/sony/DFW-X700-Datenblatt.pdf Seite 2 rechts unten.
Ich hab noch wo anders gelesen das der Impuls eine negative Spannung haben muss.

Kann ich das mit der seriellen Schnittstelle einfach generieren ? (kein Startbit, kein stopbit und nur ein datenbit? oder hat die andere impulsformen?

mfg Johannes

von dem Rechner aus sende mit dem ich den Roboter steuere

Wenn man davon ausgeht dass das Ding zeitlich deterministisch arbeitet ist das korrekt

Was den Trigger anbelangt:
http://tams-www.informatik.uni-hamburg.de/lectures/2005ss/projekt/systemDesign/doc/sx900-benutzerhandbuch.pdf

Seite 16:
Das bedeutet dass typischerweise der Trigger Pin auf High gezogen wird (über einen Widerstand sag ich jetzt einmal). Was du machen musst ist, einfach GND und Trig kurzschliessen, und das für mindestens 1 ms (getriggert wird lt. dem Dokument dennoch zum Zeitpunkt der fallenden Flanke (also in dem Moment in dem du den Kurzschluss machst)). Keine negative Spannung oder sonstwas kompliziertes.

Wie du das von der Steuereinheit aus erledigst weiss ich nicht, ich kenn die Steuereinheit nicht

... Aber wenn die auch einen Triggerausgang hat und dessen Eigenschaften bekannt sind sollte es kein Problem sein. Es stellt sich also nur die Frage - wie kommst du aus der Steuereinheit raus

Wenn der Sturm losbricht,
verstummen die Einen vor Schrecken,
und die Anderen breiten, einem Adler gleich, die Flügel aus
und schwingen sich empor.

Das mit dem Rauskommen muss ich noch abklären. Es ist eine DA Wandler im Rechner verbaut, aber ich weiß nicht ob da noch was für uns frei ist

Ginge es glaubst du auch über die serielle Schnittstelle?
Ich hab mir bei Wikipedia angeschaut wie die Spannungen beim senden sind.
http://de.wikipedia.org/wiki/Bild:RS-232_timing.png
Wenn ich mit einem Startbit gefolgt von einem Datenbit mit Wert 0 und dem Stoppbit sende so kommt doch eigentlich ein impuls mit 15V raus. Mit geeigneter Beschaltung sollte man den dann auf den gewünschent umformen können.
Die Baudrate stellt dan die Impulsdauer ein.

Was sagst du zu dem? Könnte das Klappen?

mfg Johannes

Es ist eine DA Wandler im Rechner verbaut, aber ich weiß nicht ob da noch was
für uns frei ist

Overkill

Ginge es glaubst du auch über die serielle Schnittstelle?

Dann würde ich aber noch einen uC + MAX232 dazwischen hängen. Hast du die genauen Timing Parameter der seriellen Schnittstelle überhaupt, oder ist da auch wieder ein bestimmter Delay drin.

Die Baudrate stellt dan die Impulsdauer ein.

Pfui !

Wenn der Sturm losbricht,
verstummen die Einen vor Schrecken,
und die Anderen breiten, einem Adler gleich, die Flügel aus
und schwingen sich empor.

Der delay für das senden von dem Triggerimpuls wäre da natürlich drinnen. Aber der wäre wahrscheinlich noch am ehesten zu verkraften.
Was meinst du mit Overkill beim DA Wandler?

mfg

Ein DA Wandler soll machen was ein DA Wandler machen soll

Net mehr und net weniger ...

Die Steuereinheit wird doch sicher ein paar digitale IOs haben ..

Wenn der Sturm losbricht,
verstummen die Einen vor Schrecken,
und die Anderen breiten, einem Adler gleich, die Flügel aus
und schwingen sich empor.

okay, stimmt hab ich eigentlich eh gemeint. ich hab nur 1 bit des DA Wandler gemeint

Also zusammenfassend mein Lsgsansatz

Wenn ein I/O frei ist verwende ich diesen für die Impulserzeugung wenn nicht mach ich mir eine kleine müC Schaltung die bei einem bestimmten Steuercode einen Impuls generiert.

mfg

29.02.2008, 15:54 Uhr - Editiert von mayrjohannes, alte Version: hier

Jop ... den IO müsstest halt richtig beschalten ... Wenn er triggern soll entsprechend einen 0er ausgeben.
Aufpassen dass das GND Potential der beidne Geräte nicht zu sehr abweicht.

Wenn der Sturm losbricht,
verstummen die Einen vor Schrecken,
und die Anderen breiten, einem Adler gleich, die Flügel aus
und schwingen sich empor.

29.02.2008, 15:56 Uhr - Editiert von Somnatic, alte Version: hier

Ok, die Übertragung funktioniert schon, die Einstellungen von wegen
Baudrate und dergleichen sind also kein Problem mehr. Mir geht es nur darum zu
ermitteln wie lange er für die übertragung jeder einzelnen Frame gebraucht
hat

völlig Wurscht, wenn man auf Handshake verzichten kann.

Für echtzeitfähige Anwendungen gibt's andere, effizientere Schnittstellen/Busse und Protokolle (CAN etc.)

Es war aber leider die vorgabe die serielle schnittstelle zu verwenden.
Aber ich denke ich hab einen Lösungsansatz für das Problem: externe Triggerung der Kamera. Nur ist die Frage wie man das Signal für die Triggerung am einfachsten mit dem PC steuern kann.

mfg

ich meinte: solange nicht jedes Frame-Paket bestätigt sein muß (Handshake auf serieller und dann SW-Ebene) bevor das nächste geschickt werden darf, ist die Latenzzeit egal, man schickt die Packln raus, und der 16550er fängt OS-Lastspitzen ab.

(hab den thread nur überflogen, und du scheinst es irgendwie nicht erwähnen zu wollen !??!)

auf welche Geschwindigkeit hast jetzt eingestellt?!?!

9600
19200 ?!?!?!

davon hängt zumindest mal ab wie viel später das abschlussbyte ankommt...

115200 mit 1N8

Dieses Forum ist eine frei zugängliche Diskussionsplattform.
Der Betreiber übernimmt keine Verantwortung für den Inhalt der Beiträge und behält sich das Recht vor, Beiträge mit rechtswidrigem oder anstößigem Inhalt zu löschen.
Datenschutzerklärung