Hallo, ich habe bereits mit einem Mikrocontroller, der mit einer
CAN-Schnittstelle ausgestattet ist, die Latenzeit mal mit einem Oszi
gemessen. Wenn eine bestimmt CAN-Nachricht eintrifft, dann wurde am Pin
von einem Port X auf +5V gezogen und anschließend gleich wieder auf 0V.
Was mir dabei aufgefallen ist, dass der Pin nicht erst nach dem Ende der
CAN-Nachricht auf +5V gezogen wurde, sondern ziemlich am Anfang der
CAN-Nachricht.
____________________
______________
CAN-Nachricht:_______| - |______________| _
Portpin: _________| |_____________________________________|
|___________
Warum ist der kurze Impuls vom Portpin nicht nach dem Ende der
CAN-Nachricht zu sehen?
Hat sich schon jemand mit der Latenzeitmessung auf einem
Mikrocontrollersystem befasst?
Gratuliere! Du hast eine Maschine entwickelt, mit der sich die Zukunft vorhersagen lässt. Zwar nur im Millisekundenbereich, aber ein Anfang ist gemacht. M.a.W: Bischen mehr Info. Controller, Pins, lesbares Bild, Zeiten, ...
Angehängte Dateien:
-
Skizze.jpg
8,2 KB
Oh, ich sehe gerade die obige Skizze ist total verzogen. Im Anhang hab ich nochmals eine zeichnung erstellt. Leider konnte das oszi keine Bilder abspeichern.
Ja eigentlich müsste der Portpin erst nach dem Ende der CAN-Nachricht auf +5V gezogen werden oder?
Fehlt immer noch: Zeitachse (Millisekunden, Stunden, Jahre, ...) und dazu die CAN-Rate.
Ok das hab ich mir nicht aufnotiert. Ich werde nnächste Woche am Montag nochmals die Messung durchführen. Dann kann ich auch genau die Zeit hier angeben.
Die Übertragungsrate steht bei mir auf 100kBaud fest. Die CAN-Nachrichten sende ich von einem PC aus. Alle 200ms wird eine CAN-Nachricht vom PC an den Mikrocontroller gesendet. Der Zeitabstand zwischen Anfang von der CAN-Nachricht und dem Portpin liegt in etwa im Mikrosekundenbereich.
Anzahl Bits im CAN-Frame zählen. Multipliziert mit der Dauer eines Bits und ein paar Prozent Stopfbits obendrauf ergibt das die zu erwartende Länge des Frames. Dauert der angezeigte Frame erheblich länger, dann ist das nicht 1 Frame sondern mehere. Warum auch immer (z.B. Error-Frame).
Der Begriff Latentzeit stimmt doch nicht oder? Es müsste Latenzzeit heissen. Stimmt dies? >>Anzahl Bits im CAN-Frame zählen. Multipliziert mit der Dauer eines Bits >>und ein paar Prozent Stopfbits obendrauf ergibt das die zu erwartende >>Länge des Frames. Muss ich da die komplette Zeit vom CAN-Frame überprüfen? Hat hier jemand schon mal so eine Zeitmessung durchgeführt?
Der Begriff Latentzeit stimmt doch nicht oder? Es müsste Latenzzeit heissen. Stimmt dies? >>Anzahl Bits im CAN-Frame zählen. Multipliziert mit der Dauer eines Bits >>und ein paar Prozent Stopfbits obendrauf ergibt das die zu erwartende >>Länge des Frames. Muss ich da die komplette Zeit vom CAN-Frame überprüfen? Hat hier jemand schon mal so eine Zeitmessung durchgeführt?
Guten Morgen, so nun habe ich eine Oszi. Mit dem Oszi habe ich soeben festgestellt, dass die Telegrammlänge (ganze CAN-Nachricht) insgesamt 1ms lang ist. Die Baudrate steht bei mir aug 100kBaud und die CAN-Nachricht wird alle 200ms von dem PC aus zu dem Mikrocontroller gesendet. Ich komme nie auf die 100kBaud.
Mit dem Oszi habe ich nun beobachtet, dass die Latenzzeit zwischen Ende des CAN-Telegramms und +5V Anstieg des Portpins ca. 27ms beträgt. Das ist doch nocht akzeptabel oder? Ich muss dazu sagen dass ich dazu keinen Interrupt verwende, sondern das Empfangen der CAn-Telegramme erfolgt in dem Hauptprogramm in der while(1) Schleife.
Ja mit Interrupt, liegt die Latenzzeit nur noch bei ca. 180us. Das ist ja schon viel viel besser.
> so nun habe ich eine Oszi. Mit dem Oszi habe ich soeben festgestellt, > dass die Telegrammlänge (ganze CAN-Nachricht) insgesamt 1ms lang ist. Das wären dann bei 100Kbps ungefähr 100 Bits inkl. Stopfbits. Wäre möglich, aber die zu erwartende Länge kann ich nicht erraten. die Bits musst du schon selber zählen.
Ähhm - fing dein Problem nicht umgekehrt an? Mit einer negativen Latenzzeit? Oder war die so gross, dass sie zufällig schon in den nächsten Frame reinfiel?
>>Ähhm - fing dein Problem nicht umgekehrt an? Mit einer negativen >>Latenzzeit? Oder war die so gross, dass sie zufällig schon in den >>nächsten Frame reinfiel? Ja du hast recht. Ich hab am falschen CAN Anschluss gemessen.
Messung am CAN-Eingangspin: Die Länge des CAn-Telegramms: 5 * 100us = 500us
Baudrate wurde auf 250KBaud erhöht. Messung am CAN-Eingangspin: Die Länge des CAn-Telegramms: 2 * 100us = 200us
Dann passt das doch. 500µs bei 100Kbps sind 50 Bits. Ein kompletter 11bit Frame mit 8 Bytes liegt bei grob 100. Sehe ich das richtig: Ein 500µs Frame hat hintenweg nochmal 180µs Latenz drin. Das ist das doch ganz ordentlich. Hast du eigentlich überhaupt noch ein Problem?
Naja, dann ist das schon korrekt so. Noch ein Problem habe ich: In der while(1) Schleife ist die Latenzzeit zwischen Ende CAN-Telegramm und +5V Anstieg des Portpins 27ms groß. Wenn ich das ganze in einer Interruptroutine packe, dann ist die Latenzzeit wesentlich kürzer und liegt bei ca. 180us bzw. 200us. Warum ist die while(1) Schleife zu zeitlastig?
> Warum ist die while(1) Schleife zu zeitlastig?
Da niemand ausser dir diese Schleife je gesehen hat, und ebenso viele
Leute wissen, mit welcher Plattform du arbeitest, wär's ein Wunder wenn
sich da schnell eine Antwort findet.
Ich verwende einen 8Bit Mikrocontroller. ALs Compiler benutze ich den Keil C51 (uVision3.0).
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.