Abtastzeitpunkt bei CAN verschieben (Phasesegm1, Phasesegm2 und SJW)?

[Thomas (kosmos)]

Hallo, ich habe ein kleines Problem zw. AVR ATmega16M1 und einen 
PIC18F2680 (verbaut im Microchip CAN BUS Analyzer).

in meinem BUS funktioniert alles nun habe ich mir einen CAN BUS Analyzer 
gekauft um Sachen Mitzuloggen oder über den Windowsrechner auch über die 
ferne steuern zu können.

Leider macht hier dieser verbaute PIC etwas Probleme.

Die 11 bit ID (0x2C9) wird richtig empfangen und danach würfelt er mir 
die DLC (0x1) mit der CAN Nachricht (0x3) durcheinander.

Ich möchte nun den Abtastzeitpunkt mal verschieben. Habe ich es richtig 
verstanden das ich einvon vom Phasesegment 1 z.B. 2 Tq abziehe und diese 
beim Phasesegment2 draufschlage damit ich die Bitlänge nicht veränderen?

Wie verhält es sich nun mit SJW verschiebt man damit den Abtastzeitpunkt 
Richtung Phasesegment2 ohne die Bitlänge zu beeinflussen, so das man 
nicht die beiden Phasesegmentlängen anpassen muss.

Da ich nur mit 16 kbps arbeite hätte ich nicht gedacht das es hier so 
empfindlich abläuft obwohl ich mit der 3 fach Abtastung arbeite also SMP 
Bit gesetzt beim AVR bzw. SAM Bit beim PIC.

Vielleicht hat ja jemand eine Tip in welche Richtung der Samplepoint 
sollte.



Manchmal erscheint also

[M. Н. (Gast)]

Der Sample Point ist zwischen den beiden Phasensegmenten. SJW hat damit 
erstmal nichts zu tun. Du musst, wie du schon richtig erkannt hast, das 
was du bei einem Segment wegnimmst auf das andere addieren, damit die 
Bitzeit gleich bleibt.

Hier kann man sich für verschieden Clocks etc auch die Tabelle 
generieren lassen.

http://www.bittiming.can-wiki.info/

Thomas O. schrieb:
> Da ich nur mit 16 kbps arbeite hätte ich nicht gedacht das es hier so
> empfindlich abläuft obwohl ich mit der 3 fach Abtastung arbeite also SMP
> Bit gesetzt beim AVR bzw. SAM Bit beim PIC.

Sollte es auch nicht. Wie sieht dein Bus aus? 120 Ohm Terminierung da?
Diese Triple-Sampling Sache ist natürlich von den Machern von CAN 
eigentlich nicht vorgesehen. Das untergräbt die Samplepoint-Einstellung 
ein wenig.

Natürlich noch die Frage: Bei wie viel Prozent ist dein Samplepunkt? 
Zwischen 70% und 90% ist in der Regel okay. Das sollte allerdings bei 
einem normalen CAN eher weniger ausmachen. Bei CAN-FD mit BRS ist der 
Samplepunkt sehr wichtig, da genau in diesem die Bitrate geändert wird.

[Thomas (kosmos)]

so die Antwort hat etwas gedauert. Ich verwende eine Split Terminierung 
2 x 60 Ohm plus ein Kerko, der Fehler tritt aber unabhängig der 
Terminierung auf.

8 MHz Systemtakt über externen Quarz

Teiler 10, TQ 25 bestehend aus 1 Syncbit, 8 Presegment, 8 Phasesegment 
1, 8 Phasesegment 2.

Wenn 25 TQ 100% sind und nach PHs1(17 TQ) abgetastet wird wäre der 
Samplepoint bei 68%.

So wie ich das sehe ist 8 + 8 + 8 eine sehr schlechte Wahl da ich jetzt 
nicht mehr variieren kann.

Mir bleibt jetzt nur die Lösung mit SJW 0-3, aber wie wirkt sich das 
aus? Verschiebt man damit den Samplepoint einfach um 1-3 TQ nach hinten?

ich übertrage die ID 0x2C9, DLC 0x1 und einen die Daten 0x3 also
1011001001, 1, 10

aber raus kommt 0x2C9, DLC 0x16 oder 0x17 und Wert 0
1011001001, 10110 oder 10111 und Daten 0

[Soul E. (Gast)]

SJW verschiebt nicht den Abtastpunkt, sondern das komplette Bit-Timing. 
Das ist quasi die Geschwindigkeit mit der sich der Empfänger dem Sender 
angleichen kann.

Wenn Du den Abtastpunkt innerhalb einer Bitzeit verschieben willst, 
musst Du Phase 1 kürzer und Phase 2 länger machen oder umgekehrt. Bei 
CANoe ist Default 75%, wobei Deine 68% oder 62% auch gebräuchlich sind.

[M. Н. (Gast)]

Thomas O. schrieb:
> Mir bleibt jetzt nur die Lösung mit SJW 0-3, aber wie wirkt sich das
> aus? Verschiebt man damit den Samplepoint einfach um 1-3 TQ nach hinten?

Wie auch soul e geschrieben hat: SJW hat nichts mit der Samplepint 
Position im Bit zu tun. Du hast ja selbst das Bild gepostet, wo der 
Samplepunkt eingezeichnet ist.

Kannst du nochmals ganz sauber die Konfiguration der beiden, sich nicht 
verstehenden, Busteilnehmer auflisten und eventuell auch mit einem 
Logicanalyzer bzw. Oszi eine Message aufnehmen?

[Thomas (kosmos)]

so habe mal mit dem Oszi etwas geschossen, aber auf die schnelle nur zw. 
CANL und CANH, hinter dem Tranceiver dürfte das Ganze ganz glatt 
aussehen. Habe mal die einzelnen Bits mit neuen Linien aufgeteilt und 
beschriftet X=Stuffing-Bit. CRC-Block... habe ich mal außen vor 
gelassen. das das Problem ja schon im DLC und Datenblock liegt

Habe inzwischen sehr viele bzw. möchte behaupten alle Kombination der 
Baudrate Einstellung durch die 32 kbps ergeben. Nur SJW 0b10 und 0b11 
Kombinationen hab ich noch nicht getestet.

Mein Hausbussystem besteht aus ATmega16M1-MCP2551 Gespannen was absolut 
gut funktioniert, keine CRC Fehler oder wiederholte 
Übertragungsversuche. Das Gegenstück ist ein PIC18F2680 mit MCP2551 
Tranceiver. Einziger Unterschied der mir aufgefallen ist, ist das ich in 
meinem System eine 2x51µH CAN-Drossel benutzte und die Flankenzeiten 
durch 100kOhm am Rs PIN des MCP2551 etwas gestreckt werden. Der 
Microchip-Analyzer hat keine Drossel und mindert die Flankensteilheit 
auch nicht, hier ist lediglich ein 0 Ohm Widerstand vom Rs in gegen GND 
gelötet.

Das Komische ist das die ID richtig erkannt wird nur bei DLC spuckt er 
dann je nach Baudrate konstannt als 16 aus oder mal wechselnd zw. 16 und 
17 und Daten mit 0.

Im DLC Block sind ja 3 und davor im IDT  Block waren es max. 2 gleiche 
Bits in Folge. Wäre jetzt schon super wenn ich das mit SJW 0b10 oder 
0b11 hinbekomme.

[Volker S. (vloki)]

Woher kommt die erste 1 [001][0001] im Control Block?

Müsste da nicht eine 0 sein (Reserved)?

z.B. 
https://upload.wikimedia.org/wikipedia/commons/5/5e/CAN-Bus-frame_in_base_format_without_stuffbits.svg

Vielleicht verursacht das irgendein seltsames Verhalten weil das Bit in 
der Analyzer Software nicht maskiert wurde.
(Angabe von .17 (dezimal?) anstelle von .1 Daten Byte in der Gui und 
bringt auch irgendwie die Datenausgabe durcheinander)

[Thomas (kosmos)]

Habe mich auch schon gewundert, da ich aber keinen Einfluss darauf hatte 
habe ich es ignoriert. Aber komisch dass das GUI da keinen Fehler 
ausspuckt wenn DLC größer als 8 ist evtl. würde das vielleicht als 5 DLC 
BIT reserviert?

Ja 10001 = 17 und das GUI zeigt genau das an, leider wird das Datenbyte 
aber nicht angezeigt.

Edit: In einer Bosch Spezifikation habe ich folgendes gelesen, es wäre 
ein 6 Bit Block 2 Bits für zukünftige Erweiterungen und 4 für die Angabe 
der Datenlänge. Gesendet werden müssen diese dominant und die Empfänger 
müssen alle Bit Kombinationen aus dominant und rezessiv akzeptieren.

Das würde ja einen Fehler auf der Senderseite bedeuten. Aber man hat 
hier doch keinen Einfluss dieses Bit zu ändern.

[Volker S. (vloki)]

Eins von den 2 Bits hat man inzwischen offensichtlich schon für die 
extended ID verbraucht ;-)

[Volker S. (vloki)]

Im MCHP Forum gibt es einen Thread mit überarbeiteten Software für den 
Can Analyzer.
Vielleicht würde ja auch im Fall des eigentlich unbenutzten Bits was 
gemacht.
https://www.microchip.com/forums/m851044.aspx