www.mikrocontroller.net

Forum: Hausbus Can Calibration Protocol aka CCP, aber auch XCP

Autor: Mike (Gast)
Datum: 07.08.2006 13:01

Hallo,

ich benötige Infos über CCP und XCP.
Idealerweise ein direkter Vergleich beider Protokolle hinsichtlich
Nutzbarkeit beim notwendigen Aufwand für die Implementierung in dem
Controller eigenen Betriebssystem.

Für hilfreiche Links bin ich zu Dank verpflichtet.

Grüße Mike

P.S. Google habe ich bereits gequält, wiki ebenso, bin gerade dabei die
Protokolle von ASAM durch zu lesen. Jedoch kristallisiert sich bislang
keine Antwort auf meine oben gestellte Frage.
Autor: Axel Barkow (Gast)
Datum: 28.08.2006 08:52

Schau mal auf

www.vector-informatik.de

Gruß,

Axel
Autor: Timo Engelmann (Gast)
Datum: 04.09.2006 14:24

Hier findest Du die XCP-Specs:

http://www.asam.net/03_standards_06.php?memberlogin=

Grüße Timo
Autor: mike (Gast)
Datum: 26.09.2006 13:45

Hi,

danke für die Infos, die sind leider für mich nicht neu und die Spec
ist recht trocken gehalten. Die hatte ich mir ja bereits zu  beginn
reingezogen...
Durch die allgemeine Formulierung der Spec, sind einige Dinge für mich
nicht wirklich klar.

Kennt jemand vielleicht noch einen Mailingliste, auch ausländische
(solange auf englisch)???

Danke
Autor: Tien (Gast)
Datum: 27.09.2006 17:44

Hallo Mike,

der Unterschied zwischen CCP(=CanCalibrationProtocol)
und XCP ist, wenn mich nicht alles täuscht, im wesentlichen,
dass beim XCP das Übertragungsmedium nicht mehr nur auf Can
festgelegt ist, während bei XCP das Übertragungsmedium auch
Ethernet, FlexRay, Lin, USB, usw. sein darf.

Vermutlich gibt es auch Inhaltliche Unterschiede, als
Anwender der XCP-Messtechnik kann ich dazu aber wenig sagen,
mir ist es wichtig, dass Daten aus dem Steuergerät rauskommen
alles andere ist mir zunächst egal.

Aber bei Vector findest Du auch freien XCP-Sourcecode,
da stecken bestimmt recht viel Info über XCP drin :-)

Grüße Tien
Autor: tom (Gast)
Datum: 04.10.2006 09:05

Hi,

ganz kurz gefaßt: XCP ist als Supermenge des CCP gedacht. Während CCP
den CAN als Physik fest vorschreibt und auch die Befehlsmenge bzw.
Struktur, ist XCP da weiter gefaßt. Der bessere Weg ist vermutlich,
zuerst CCP verstehen lernen, dann mit XCP befassen. Zumal XCP so neu
ist, das es auch industriell noch sogut wie keine verwendungsfähige
Software gibt! (bitten nicht von Fachzeitschriften und Firmenflyern
täuschen lassen!) Bei CCP sieht das ETWAS besser aus! ;-)

Schönen Tag noch,
Thomas
Autor: Tien (Gast)
Datum: 06.10.2006 18:31

Hi Thomas,

> Zumal XCP so neu
> ist, das es auch industriell noch sogut wie keine verwendungsfähige
> Software gibt! (bitten nicht von Fachzeitschriften und Firmenflyern
> täuschen lassen!) Bei CCP sieht das ETWAS besser aus! ;-)

da muss ich Dir wiedersprechen.
Wir setzen hier in Steuergeräten XCP ein und es gibt
durchaus auch gute funktionelle (wenn auch teure) Tools.

Grüße,
Timo
Autor: Mike (Gast)
Datum: 27.10.2006 15:08

Hi Tien,

kann dir da eigentlich beipflichten. Haben uns hier für das XCP
entschieden, da es neuer ist und CCP am auslaufen ist.

Kannst du mir sagen, wie die ODT´s abgespeichert werden?
Ich mein du schickt dein DAQ Botschaft mit deiner PIDnumber(=ODT),
anschliesend werden die Adressen aus der ODT gelesen, besser gesagt, die
Variablen die hinter diesen Adressen stehen (die länge wird natürlich
mit angeben).
Meiner Meinung nach müssten die ODT in ner Header stehen.
Über Dein Tool wählst du ja nur noch die Variablen aus, die du
messen/schreiben willst. Oder werden die ODT´s über das A2L File
gefüttert?
Aber wann sollen hierfür die Daten Übertragen werden?

Danke

noch ein schönes WE
Grüße
:-)
Autor: Tien (Gast)
Datum: 30.10.2006 11:12

Hallo Mike,

ich bin was XCP angeht im wesentlichen Anwender, da
der Code direkt von Vect*r stammt (sowohl ECU, als auch das Tool).
Deshalb bin ich nicht sehr mit dem dahinter liegenden
Mechanismen vertraut - ich kann nur sagen es funktioniert,
und das sogar recht gut.

Trotzdem, hier was zur Technik:
Bei DAQ wird beim Kommunikationsaufbau der ECU mitgeteilt, welche
Adressen in welchem Task übertragen werden sollen.
Die Daten stammen ursprünglich aus dem .elf-File, welches im
XCP Tool dazu dient, das .a2l-File mit den nötigen Adress Infos
zu füttern.

Du kannst generell ohne weitere Vorbereitung im ECU Code jede
global deklarierte Variable mit XCP auslesen.
Du must einzig das a2l-File mit den aktuellen Adressen aus
dem .map oder .elf File füttern und dann kanns los gehen.

Hoffe das war in etwa eine Antwort - oder hab ich die falsch
verstanden.


Grüße Timo
Autor: Mike (Gast)
Datum: 30.10.2006 13:08

Hi Timo,

wir implementieren XCP selbst, benutzen Programme (Mastertool und XCP
Implementierung) von der Konkurrenz von Vect..
Habt ihr den das XCP Protokoll in eueren ECU selbst eingefügt oder vom
Vect.. Mitarbeiter einfügen lassen?

Wir sind momentan dran, das A2L File "richtig" zu generieren. Das will
irgendwie nicht, wie wir es wollen.

Der Rest schein t easy zu sein.
Jedoch bereiten mir immernoch die AML Files ->A2L Kopf zerbrechen.

Wie konfiguriert ihr euer A2L File?
zum Beispiel: Granularity von den ODT´s oder Allgemein.

Die ODT sind ja in der ECU abgelegt, ich schätze man wählt im Mastertool
einfach seine zu messenden Variablen aus, die werden dann in die ODT der
ECU geschrieben. Von dort aus werden die Variablen referenziert. Dann
nur noch den Aufruf mit dem Event_Channel in die ECU Task einfügen und
die Messung kann beginnen...

Grüße Mike
Autor: Tien (Gast)
Datum: 30.10.2006 15:59

Hi Mike,

> Habt ihr den das XCP Protokoll in eueren ECU selbst eingefügt oder
> vom Vect.. Mitarbeiter einfügen lassen?

In Zusammenarbeit mit dem Vect*r Mitarbeiter. Wobei das
ziemlich schnell ging, die haben ihren Code für den Tricore
in unsere Toolchain eingefügt und dann wurde es mitcompiliert.
Die einzigen Änderungen an unserer SW war die Anpassung der
CAN config und das Hinzufügen der XcpEvent Funktion
in den jeweilgen Tasks. Nach einem halben Tag lief XCP problemlos.

> Wir sind momentan dran, das A2L File "richtig" zu generieren.
> Das will irgendwie nicht, wie wir es wollen.
> Wie konfiguriert ihr euer A2L File?
> zum Beispiel: Granularity von den ODT´s oder Allgemein.

Momentan stehen wir noch ganz am Anfang, d.h. in diesem
Projekt, XCP ist in meiner bisherigen Abteilung bereits
im produktiven Einsatz.
Ziel soll es sein das A2L File direkt aus dem Code und dem
Map File zu generieren. D.h. der Programmierer fügt zu einer
Messtechnisch interessanten Variablen einen Kommentarblock
hinzu, der dann alle nötigen Infos für das A2L File hat.
Ein Codeparser (der noch zu programmieren ist :-) nimmt
diese Kommentare und erzeugt in Verbindung mit dem Map File
das fertige A2L File.

Mal ne Frage, in welcher Firma arbeitest Du, (sofern Du mir das
schreiben magst bzw. darfst)?

Grüße Timo
Autor: Mike (Gast)
Datum: 31.10.2006 11:27

Hi Timo,

das ging ja fix mit der Implementierung. Hat euch Vect.. dann mit der
erstmaligen Erstellung der A2L Datei geholfen?
Wir generieren Code automatisch und dort gibt es eine Unterfunktion um
ein A2L File zu erzeugen. Hat bislang aber nicht korrekt funktioniert.

Die Implementierung der Grundfunktion macht mir mittlerweile weniger
Sorgen. Jedoch habe ich halt in gewissen Bereichen Fragen, die
wahrscheinlich selbstverständlich sind, dass ich nirgends Antworten
darauf finden kann ;-)

Weiß net, ob es sinnvoll ist in aller Öffentlichkeit den Firmennamen
bekannt zu machen. Wir sind aber in der Metropolregion Rhein-Neckar.
Mache grad meine Masterarbeit und tue mich an mancher Stelle als
Elektroniker (etwas) schwer...

Lass mich raten, Du arbeitest entweder Großraum Stuttgart, München,
Ingolstadt, Franktfurt oder Wolfsburg??? :-)

Wie lange verwendet ihr XCP bereits, bzw wie lange bist du schon damit
in Berührung? Grundsätzlich würden sich doch die Hauptfunktionen (messen
und parameter verändern) bestimmt auch anders realisieren. Habt ihr in
dieser Richtung ausschau gehalten?

Viele Grüße
Mike
Autor: Tien (Gast)
Datum: 31.10.2006 12:26

Hi Mike,

> Hat euch Vect.. dann mit der
> erstmaligen Erstellung der A2L Datei geholfen?
Das ist mit CAN*ela kein großes Problem, es gibt darin ein
Modul ein a2l File mit ein paar Klicks aus einem Elf-File
oder Map-File zu generieren. Nach erneutem compilieren (d.h.
Adressverschiebung) müssen in diesem Modul nur die Adressen
aktualisiert werden.
Allerdings ist das halt alles "Handarbeit" d.h. ich muss von Hand das
Elf-File ins Tool laden und die Adressen aktualisieren...
Wie bereits geschrieben ist es das Ziel das am Ende eines Builds das
A2L-File automatisch mit generiert wird.

> Lass mich raten, Du arbeitest entweder Großraum Stuttgart, München,
> Ingolstadt, Franktfurt oder Wolfsburg??? :-)

Ja, gut geraten. Meinen Arbeitgeben findest Du ausserdem in so manchem
Hobbykeller und so mancher Küche :-)

> Wie lange verwendet ihr XCP bereits, bzw wie lange bist du schon damit
> in Berührung?

In der Firma bestimmt schon seit Anfang an, ich persönlich
als Anwender nutzte die Messtechnik ca. 3 Jahre in meiner
alten Abteilung und in der neuen Abteilung in der
wir ein neues Steuergerät entwickeln seit ein paar Wochen.
Hier bin ich allerdings eher für die XCP Betreuung und Erstellung
der A2L Files zuständig neben meinem Hauptjob der Kundendiagnose.

> Grundsätzlich würden sich doch die Hauptfunktionen (messen
> und parameter verändern) bestimmt auch anders realisieren.
> Habt ihr in dieser Richtung ausschau gehalten?

Eher nicht, da der Kunde genaue Vorstellungen hat mit welchen
Tools er Messen und Kalibrieren will.

Grüße Tien



Autor: Mike (Gast)
Datum: 31.10.2006 12:38

Hi Tien,

coole Mischung, soviele Städte (kommt man wenigstens rum) und sogar im
Hobbykeller sowie Küche zu finden. Dachte XCP würde nur im Automotive
Bereich eingesetzt werden man lernt nie aus

Ich hatte gehört gehabt, es wäre auch über Diagnose (KWP2000) und ganz
normales flashen möglich. Natürlich dauer das flaschen länger, als eine
einzige Variable über das Mastertool zu verändern.

Das man mit CAN*ela A2L Files erzeugen kann wusste ich bislang gar
nicht. Wahrscheinlich ist das aber wieder ne teurer Angelegenheit die
Software zu beschaffen, dann lieber selbst was Kleines schreiben...
Soviel scheint es ja nicht zu sein...

Grüße Mike
Autor: Tien (Gast)
Datum: 31.10.2006 13:28

Hi Mike,

> coole Mischung, soviele Städte (kommt man wenigstens rum) und sogar im
> Hobbykeller sowie Küche zu finden. Dachte XCP würde nur im Automotive
> Bereich eingesetzt werden *man lernt nie aus*

Naja, ich dachte bei dem Stichwort Hobbykeller und Küche würde
es klingeln und ich muss Stuttgart nicht extra erwähnen :-)
Ich vermute allerdings XCP wird (noch) nicht in einer Küchenmaschine
oder in einem Akkuschrauber Verwendung finden :-)

> Ich hatte gehört gehabt, es wäre auch über Diagnose (KWP2000) und ganz
> normales flashen möglich. Natürlich dauer das flaschen länger, als eine
> einzige Variable über das Mastertool zu verändern.

Natürlich, aber das ist nicht wirklich praktikabel - es kostet einfach
zuviel Zeit. Man will ja nach einer Messfahrt direkt im laufenden
Betrieb einen  Parameter verstellen und sofort weiter arbeiten.
Das geht ohne Probleme, wenn diese Parameter beim
Systemstart ins RAM kopiert werden und Du die RAM Werte per XCP änderst.
Erst wenn die Applikation ok ist kopierst Du die Werte in
eine Hex Datei, die dann geflasht wird und somit beim nächsten System
start in der ECU vorliegen.

> Das man mit CAN*ela A2L Files erzeugen kann wusste ich bislang gar
> nicht. Wahrscheinlich ist das aber wieder ne teurer Angelegenheit die
> Software zu beschaffen,
Ist im CAN*ela von Haus aus drin, aber das Tool ist für
Normalsterbliche tatsächlich nicht ganz billig. Allerdings kostet
die Entwicklung eigener Tools und der µC Software natürlich
auch einiges. Und wenn ich sehe wie reibungslos bei uns die Integration
verlief und wie gut der Support des Herstellers ist war es eine gute
Entscheidung.

> dann lieber selbst was Kleines schreiben...
> Soviel scheint es ja nicht zu sein...

Je nachdem was für Ziele man verfolgt. Ich denke die µC SW
ist nicht wirklich das Problem, die PC SW ist da eher
deutlich zeitaufwendiger (Erfassung, Speicherung, Visualisierung, ...)

Grüße Tien

Autor: Mike (Gast)
Datum: 31.10.2006 14:15

Hi Timo,


> dann lieber selbst was Kleines schreiben...
> Soviel scheint es ja nicht zu sein...

Je nachdem was für Ziele man verfolgt. Ich denke die µC SW
ist nicht wirklich das Problem, die PC SW ist da eher
deutlich zeitaufwendiger (Erfassung, Speicherung, Visualisierung, ...)


Damit meinte ich nen Programm, dass anhand Deines MAP Files und Deiner
Einstellungen selbstständig ein A2L File erzeugt, ohne händisch im A2L
File Änderungen vornehmen oder auf teure Software zurückgreifen zu
müssen.

Die Anwendersoftware (Mastertool) zu schreiben würde den zeitlich Rahmen
sprengen, ausserdem muss man das rad nicht neu erfinden, wenn es nicht
teuer bezahlt werden will...

Bin mal gespannt wie das noch laufen wird. Wie gesagt die Geschichte mit
den ODT´s ist mir immernoch ein wenig unklar...

Grüße in die Landeshauptstadt
Mike
Autor: Mitleser (Gast)
Datum: 11.01.2007 15:03

Hallo?

Ist der Thread noch aktiv?

@Tien(Gast): Ich habe eben mit interesse gesehen, das es wohl möglich
sein soll, mit V*c*o* CANo|ela aus einem map\elf ein a2l zu erzeugen.

Welche Version verwendet ihr??
Wie geht das??


Danke!!!
Autor: Tien (Gast)
Datum: 16.01.2007 13:10

Hi,

hab gerade gemerkt, dass ich mal wieder die vielen
verschiedenen Ve*tor Produkte durcheinander gebracht
habe...

Ich meinte nicht CAN*ela sondern CAN*pe!
In CAN*pe ist ein a2l-Editor enthalten,
mit dem man aus einem map- bzw. elf-File und
zusätzlicher manueller Angaben ein a2l-File erstellen
kann. Dieses a2l-File ist dann der Input für die XCP Messung
in CAN*ela.

Sorry, hoffe ich hab nun niemand allzu durcheinander gebracht.


Grüße Tien
Autor: Mike (Gast)
Datum: 23.01.2007 08:47

Hi

Es gibt mittlerweile auch einen VariablenEditor von d*pace, entweder in
ca*desk mit dabei oder als "stand alone" editor.

Ich weiß nur nicht, in wie fern die sache dann passt oder ob es von der
semantik der AML unterschiede zwischen Ve*tor und d*pace gibt.

asam ist momentan dran einen konverter zu schreiben. AML -> XML!
später sollen dann XML dateien verwendet werden...

Viele Grüße
Autor: Heitzer Tom (Gast)
Datum: 13.02.2007 15:57

CCP nur basierend auf CAN Bus
beim XCP kannst auch FlexRay,RS232,usw...
Autor: deg (Gast)
Datum: 04.05.2008 16:46

Hallo,

ich bin grad dabei einen XCP Slave zu realisieren.
Jedoch sind einige Fragen offen, hoffe auf paar anregungen um die
Unklarheiten zu beseitigen.

Die größte frage ist das Calibration Page switching

was soll das?:)

Ein Speicher ist aufgeteilt in Sektoren. //OK
Im Speicher gibt es Segmente die unabhängig von den physikalischen
Grenzen
sind. // das ist auch OK
Jedes Segment beinhaltet Pages, die alle die selbe Adresse beschreiben
nur mit unterschiedlichen Einstellungen (z.B read/write access) // nicht
OK

Die Page's dienen dazu um Schreib und Leserechte des Speichers zu
Verwalten?
Was ist der Sinn des ganzen, den als ein der Application untergeordnetes
Protokoll soll ich der ECU vorschreiben auf welchen Bereich sie
zugreifen kann und wie sie drauf zugreifen kann.

Die zweite Frage ist Bezüglich der Calibration commands

Wie verhält sich das ganze mit dem Flash Speicher?
Denn Speicher kann ich nur Sektorweise löschen.
Wenn ich jetzt das byte in der Page X im Sector Y verändern möchte sei
es eine Konstante. Muss ich den ganzen Sector zwischenspeichern entweder
im RAM bzw. im gleich großem freien Sector im Flash, dann den Sector Y
löschen
und bei wieder beschreiben der Pages, die Page X manipulieren. Eine
andere Lösung sehe ich derzeit nicht :(. Den RAM kann ich glaub ich
vergessen. Der
größte Sektor beträgt 512 Kbyte

Viele Fragen, wenig Zeit .....

Danke schon mal im Voraus.

Antwort schreiben

Die Angabe einer Email-Adresse ist freiwillig. Wenn Sie automatisch per Email über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Suchfunktion und Betreffsuche benutzen - vielleicht gibt es schon einen ähnlichen Beitrag
  • Aussagekräftigen Betreff wählen
  • Im Betreff angeben um welchen Controllertyp es geht (AVR, PIC, ...)
  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang
  • JPEG-Dateien (.jpg) nur für Fotos verwenden, Schaltpläne, Screenshots usw. als PNG oder GIF anhängen

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [pre]vorformatierter Text (z.B. Code in anderen Sprachen)[/pre]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel





Hinweis: der Originalbeitrag ist mehr als 6 Monate alt.

webmaster@mikrocontroller.netImpressumWerbung auf Mikrocontroller.net