ISOBUS - CAN PGN Nummern und Daten

[Kampi]

So ich habe nochmal in dem Buch nachgelesen.
In dem Buch steht auf Seite 62 folgendes:

"Nodes recieving remote frames and accepting them will send a data frame with the requested data but only one node can send the data."

Das heißt soviel wie, dass die Knoten den Remote-Frame empfangen und wenn sie ihn annehmen senden sie einen Data-Frame mit den angeforderten Daten.
Ein Absatz weiter unten steht (wenn ich es richtig übersetzt habe) folgendes:
Die Datenanfrage erfolgt nach dem Senden von zwei Frames. Als erstes wird ein Remote-Frame gesendet (RTR = 1) damit die Knoten wissen das Daten angefragt werden.
Der zweite Frame ist ein Data-Frame mit dem selben Identifier wie der Remote-Frame, welcher dann sagt welche Daten angefragt werden.
Der DLC des Remote-Frames muss der gleiche sein wie der DLC des Data-Frames der unmittelbar nach dem Remote-Frame gesendet wird (DLC = Data Lenght Code).
Wenn ein Remote-Frame und ein Data-Frame mit dem selben Identifier gleichzeitig am Bus anliegen, hat der Data-Frame IMMER Vorrang, weil das RTR Bit (welches zur Bus Arbitration gehört) 0 ist und die Frames mit dem niedrigsten Wert des Arbitration-Fields (Message-Identifier + RTR Bit) Priorität haben.
Das heißt eine Message mit einem Message-Identifier von 0x01 und einem RTR-Bit von 0x00 hat Vorrang zu einer Message mit Message-Identifier 0x01 und einem RTR-Bit von 0x01 (RTR = 0 signalisiert ein Data-Frame und RTR = 1 signalisiert ein Remote-Frame).

[wkrug]

Hi Kampi,

Das das Buch in Englisch ist hat mich vor länger Zeit von der Bestellung abgehalten. Da es aber anscheinend doch was taugt, werd ichs mal versuchen.

Das mit den priorisierten Nullen hab ich mir schon gedacht - Ist ja auch bei der Adressvergabe so.
Was leider immer noch nicht beantwortet wurde ist die Sache mit den PGN Nummern und den zugehörigen Daten in den Datenbits einer CAN Nachricht.

Noch was, was ich meine verstanden zu haben, aber noch mal verifiziert haben möchte ist das Bit Timing des MCP2515.
Soweit ich das verstanden habe wird die Taktfrequenz ( z.B. 16MHz ) mit einem Vorteiler heruntergeteilt.
Dadurch ergeben sich pro Bit eine Anzahl von TQ's - Üblicherweise so um die 16.
Das Sync ist ja fest 1*TQ
Die anderen 3 Segmente müssen sich die restlichen TQ's aufteilen
In der Summe müssen aber die TQ's der einzelnen, eingestellten TQ Schritte für das PropSegment + PS1 +PS2 + und das eine Sync TQ wieder die Anzahl der TQ's pro Bit ergeben. - Hab ich das so richtig interpretiert ???
Ist es günstiger den Sample Point einmal abzufragen, ist die dreimalige Abfrage die bessere Option, oder ist das von der Busgeschwindigkeit abhängig.

[Kampi]

Hi,

ob das Buch was taugt (im Sinne auf die Korrektheit usw.) kann ich dir nicht beantworten, weil ich selber nicht so der CAN-Experte bin
Was es mit den PGN Nummern auf sich hat weiß ich leider auch nicht....hab das bisher auch noch nicht gehört.
Zum Bit-Timing:
Ja genau der takt wird mit einem Prescaler geteilt. Dadurch entsteht der "Baud Rate Clock". Ein TQ ist dann ein Takt des Baud Rate Clocks.
Der Synch entspricht 1xTQ und ist fest. Das Prop_Seg und das Phase_Seg1 sind variabel von 1-8 und das Phase_Seg2 ist gleich lang wie das Phase_Seg1.
Und wenn du die ganzen TQs dann addierst hast du die Länge von einem Bit.
Dementsprechend kann ein Bit mind. 4 TQ lang sein (1x Synch, 1x Prop, 1x Phase_Seg1 und 2) oder max. 25 TQ (1x Synch, 8x Prop, 8x Phase_Seg1 und 2).
Kleine Beispielrechnung aus dem Buch:

TBit = TQ x (Synch_Seg + Prop_Seg + Phase_Seg1 + Phase_Seg2)

TQ = 2 x BRP / FOSC
TQ = 2 x 2 / 20MHz
TQ = 0,2µs

TBit = 8 x TQ (Es wurde festgelegt das 1 Bit 8 TQ lang sein soll)
TBit = 8 x 0,2µs
TBit = 1,6µs

NBR = 1 / TBit
NBR = 1 / 1,6µs
NBR = 625000bps
NBR = 625kB/s

Zu der Frage mit dem Sample Point kann ich dir leider keine vernünftige Antwort geben, weil in dem Buch nicht so genau auf den Punkt eingegangen wird. Aber das sollte für dich glaub ich auch nicht so ausschlaggebend sein.
Auf jedenfall wählst du aus wie lang ein Bit sein soll. Dies machst du durch die Wahl der TQs pro Bit.
Aber im Grunde hast du das schon richtig interpretiert
Ich nehme mal an du bist von dem Standpunkt ausgegangen, dass du eine fest definierte Länge des Bits gegeben hast und daraus die Anzahl der TQs herleiten willst.
Ich habe für mein CAN-Bus ein Mikrochip Tool verwendet um den ganzen TQ Rummel auszurechnen (war da ein wenig faul ).

Edit:
Bzgl PGN...hast du das hier schon gefunden/gelesen?:

http://de.wikipedia.org/wiki/SAE_J1939

[wkrug]

Der Link war gut!
Diese Grafik zeigt das was ich gesucht habe: http://de.wikipedia.org/w/index.php?...20090908102337
Ich hab mich auch schon ein wenig in das CAN Tutorial von "kreatives Chaos" eingelesen.
Die Leute da haben das sehr gut beschrieben.
Dann wär bei den PGN's nur noch zu klären, welche Source Adressen ich verwenden kann und darf.

[wkrug]

Ich hab mal das Buch "Controller Area Network Projects" durchgearbeitet.
Sehr viel neue Erkenntnisse hat's mir nicht gebracht. Immerhin bin ich der Meinung den CAN Bus einigermassen verstanden zu haben.

Nun zu meinem neuerlichen Problem:
Ich hab mir die ISOAg lib heruntergelden. Leider find ich in dieser Library irgendwie keinen Einstieg.
Link: http://isoaglib.com/de/download
Die Library besteht aus 360! Header Dateien, aber irgendwie sind das nur Definitionen und Prototypen ohne ausführbaren Code.

Es ist auch irgendwie nicht klar, welche Dateien eingebettet werden müssen ( Diagnostic usw. ) und welche optional sind.
Ich denk mal die Plattform, die da genutzt wird ist der PC.
Ich hätte mir zumindest erhofft irgendwelche Initialisierungsabläufe aus dieser Lib herausziehen zu können.

Doch bei dem Umfang seh ich da mal keinen Weg.

Hat von Euch da jemand eine Idee?