Schlechte Datenblätter von Infineon (CAN)

[Fabian H. (Firma: Technische Universität Berlin) (brein)]

Hallo Leute,

ich wollte mich mal hier über die Datenblätter von Infineon auslassen. 
Zum einem um zu sehen, ob ich damit alleine bin oder nicht. Zum anderem 
kann es ja sein, dass ich mich einfach nur doof anstelle und so kann ich 
vielleicht Hilfe bekommen.

Konkret möchte ich mein Problem am User's Manual der XC2200-Familie mal 
erläutern.

Auf den Seiten 20-79 bis 20-81 werden die Register MOCTRnH und 
MOCTRnL erklärt, mit denen man die Message Objekte des Can-Moduls 
einstellen kann.
Man kann dort z.B. definieren, ob es Sende- oder Empfangsobejtke sind, 
ob sie valide sind und natürlich deren Statusbits. Mit dem Register 
MOCTRnH kann man diese Flags laut Tabelle setzen und mit MOCTRnL 
zurücksetzen.

Soweit so gut. (Das funktioniert auch. CAN läuft soweit ganz gut.)

Nun sieht man auch, dass diese Register nur geschrieben werden können 
durch das Zeichen w für write unter jedem Bit. (OK, ich hole jetzt 
sehr weit aus!)

Deshalb wollte ich nachlesen, wie man den Status NEWDAT abfragen kann.

Dazu steht im Datenblatt:

The Message Object Control Register contains control bits for the CAN transfer and the
message object link pointer. Each control bit has a corresponding bit in the CTRL field.
A control bit is set by writing 1 to the corresponding bit in CTRL. It is cleared by writing
1 to the control bit directly. Any other combination leaves the control bit unchanged. ...

Von mir frei übersetzt heißt das soviel wie:

Das Message Object Controll Register enthält die Steuerbits zur CAN-Übertragung und den Linkpointer zu den Message-Objekten.
Ein Steuerbit wird gesetzt, wenn man das entsprechende Bit in das *CRTL* setzt. (Wohl eher *CTRH* oder?)
Es wird gelöscht, wenn man direkt eine 1 hinein schreibt. (Was? Ahhh! Dann heißt das darüber also nicht _set_ sondern _reset_.)
Alles andere lässt das Bit unverändert.

Da ist es wirklich schwer den wahren Sinn zu verstehen. Meint Ihr nicht?

Aber gut. Jetzt sind dass die Set- und Reset-Register. Vermutlich gibt 
es ein separates Register, dass die Daten zum auslesen vorhält 
**Dummstell**.
Wenn man mal schaut wie DaVE den Code erstellt um das Bit auszulesen, 
kommt man aus dem Stauen nicht mehr heraus:

#define CAN_ubNewData(ObjNr) (((CAN_HWOBJ[ObjNr].uwMOCTRL & 0x0008) == 0x0008) ? 1 : 0)

Was? Das hardwarseitig gesetzte Bit wird aus diesen Registern ausgelesen 
und dann auch noch aus dem, der das Bit zurücksetzten soll?
Darauf wäre ich mittels Datenblatt niemals gekommen.
Aber warum steht da etwas überhaupt drin? ich denke man kann es nur 
lesen!? Heißt das, dass das Flag auch schon wieder zurück gesetzt wurde? 
Fragen über Fragen.

___________________________________________________________________

Also grundsätzlich ist mir das schon klar. Es gibt Controller die haben 
Datenregister, deren Bits sich einzeln setzen lassen oder die man mit 
UND löschen respektive mit ODER setzen muss.
Komfortablere Hardware bieten zusätzlich dafür Setz- und Lösch-Register 
an.
Brauche ich zwar persönlich nicht, aber so vermeidet man eher Fehler.

Ich habe es aber noch nie gesehen, dass es nur Setz- und Lösch-Register 
gibt ohne auf die Daten direkt zugreifen zu können.
Gut, dann dient wohl das LOW-Register zum auslesen. Oder vielleicht 
sogar beide?
Damit könnte ich zur Not auch leben. Aber warum steht das nirgends?

Wer glaubt, dass sei ein Einzelfall, dem kann ich noch andere Beispiele 
liefern.
Der XC2000er kommuniziert mit einem XC800er. Da sieht es nicht viel 
besser aus.

Da mir hier im Forum aber schon einer (oder einige?) gesagt haben, dass 
sie mit dem Datenblatt gut zurecht kommen, würde mich mal interessieren, 
ob ich mich wirklich zu dumm anstelle oder ob diese Menschen aufgrund 
ihrer Erfahrungen implizit Informationen herauslesen die so dort nicht 
oder falsch stehen.

Gruß und Danke
Fabian

[Peter D. (peda)]

Fabian Hoemcke schrieb:
> Komfortablere Hardware bieten zusätzlich dafür Setz- und Lösch-Register
> an.

Das ist kein Komfort, sondern ne Krücke, weil die CPU nicht direkt 
IO-Register atomar ändern kann.
Man kann also nicht einfach in C hinschreiben, was gemacht werden soll, 
sondern muß es umständlich in Set- und Clear-Operationen auseinander 
friemeln.

IO-Register werden oft auch von einer 2.Instanz (Interrupt) zugegriffen, 
dann ist ein atomarer Zugriff notwendig.
Bei 32Bit-Befehlen ist es nicht einzusehen, einfach noch ein paar 
atomare Befehle zu implementieren oder einen Befehl zur atomaren 
Kapselung einer Sequenz.

Es traut sich leider kein Hersteller, für diesen groben Designfehler 
eine vernünftige Lösung zu implementieren.


Bei Datenblättern gibt es leider viele schlechte Beispiele.
Die AVR-Datenblätter finde ich sehr gut strukturiert. Aber auch da 
stehen wichtige Sachen manchmal an der falschen Stelle und sind dann 
kaum zu finden.

Eine Unterteilung in Datasheet und Usermanual finde ich generell 
schlecht. Man muß dann immer zwischen beiden Dokumenten hin und her 
blättern.
Insbesondere, wenn ein Usermanual mehrere verschiedene MCs beinhaltet, 
kriegt man schnell Knoten im Gehirn, was denn nun für meinen MC 
zutreffend ist.


Peter

[Korl (Gast)]

Kommt mir bekannt vor... der XE167 war auch ein Monster mit 1700 Seiten 
Datasheet und ich dachte mi auch desöfteren WTF.

[Fabian H. (Firma: Technische Universität Berlin) (brein)]

Peter Dannegger schrieb:
> Das ist kein Komfort, sondern ne Krücke, weil die CPU nicht direkt
> IO-Register atomar ändern kann.

Ganz ehrlich?
Das Problem habe ich jetzt nicht verstanden. Das heißt, intern, wenn ich 
auch nicht darauf zugreifen kann, gibt es einen Datenregister, auf das 
aber selbst die CPU nicht zugreifen kann? Ist dass das Problem mit der 
Atomizität?

Gruß und Danke
Fabian

[Fabian H. (Firma: Technische Universität Berlin) (brein)]

Ich muss mich revidieren, es gibt natürlich einen Status-Register 
MOSTATnL zum Auslesen der Werte. Dieser wird aber natürlich von Dave 
nicht genutzt. Was die Sache also nicht wirklich besser machen.

Gruß
Fabian