CAN: Latentzeit messen!

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?

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.

Was meinst du genau? Wie könnte ich dies ermitteln?

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.

Muss ich alle Bits vom komplette CAN-Telegramm 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?

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

Ich versende nur 1 Datenbyte vom PC an den Mikrocontroller.

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?

Ich verwende einen 8Bit Mikrocontroller.
ALs Compiler benutze ich den Keil C51 (uVision3.0).