1. Home
  2. Electronics (German)
  3. Merkwürdiges Verhalten beim Microcontroller (freescale HCS12XDP512)

Merkwürdiges Verhalten beim Microcontroller (freescale HCS12XDP512)

Tach NG,

ich zerbrech' mir grad den Schädel über leicht merkwürdiges Verhalten des hier verwendeten Microcontrollers, nem HCS12XDP512 von freescale.

In dem hier laufenden Programm nutze ich ein paar boole'sche Variablen und auch ein paar Integers als Bitfelder. Die Entwicklungsumgebung definiert bools simpel als char, und gibt TRUE und FALSE die Werte 1 und

0, genau so wie man es erwartet. Schau ich mir den Kram aber mal im Debugger an, so tauchen da ständig auch andere Werte auf, was die Abfrage (x == TRUE) bzw. (X == FALSE) komplett ad absurdum führt. Besonders häufig treten (dezimale) Werte auf wie 212, 128, aber auch nahezu alles andere wurde schon gesehen. Ähnliches passiert mit meinen Bitfeldern: eigentlich werden nur die unteren 4 bit eines 8-Bit-Integers verwendet, setzten per "x ODER Bit", Löschen per "x UND ~Bit". Soweit alles schick, bis ich das Programm anwerfe... Mir fällt überhaupt keine Möglichkeit ein, mit den 4 niederwertigsten Bits Zahlen größer 15 darzustellen, aber genau das passiert hier am laufenden Band.

Habe bereits mehrfach erfolglos gesucht, ob nicht vielleicht irgendwo statt den logischen Operationen ne Addition oder ähnlich bescheuerte Dinge durchgerutscht sind, habe aber nichts dergleichen gefunden.

Hat jemand von Euch vielleicht ne Idee?

Gruß, Florian

Reply to
Florian E. Teply
Loading thread data ...

Florian E. Teply schrieb:

Tach FET

...

Arbeitest Du irgendwo mit Zeigern (SP ist auch einer)? Ein kleiner Fehler kann die "interessantesten" Effekte haben.

Falk

Reply to
Falk Willberg

Florian E. Teply schrieb:

Du programmierst C? Der C-Standard sagt lediglich, dass false = 0 ist und true != false. Ob der 1 ist oder was anders, ist Implementierungsabhängig.

Aber das von dir geschilderte Program sieht eher nach stack corruption aus. Initialisierst du den SP richtig? Hast du irgendwo große Felder allokiert, wird der Speicher knapp?

Viele Grüße, Johannes

--
"Wer etwas kritisiert muss es noch lange nicht selber besser können. Es
reicht zu wissen, daß andere es besser können und andere es auch
besser machen um einen Vergleich zu bringen."     -     Wolfgang Gerber
       in de.sci.electronics
Reply to
Johannes Bauer

Nun ja, der Compiler macht sicher aus vielen Dingen Zeiger-äquivalente Konstrukte, aber selber mache ich in dieser Hinsicht garnix, außer gelegentlich mal ein Array-Index, der aber auf die Grenzen hin überprüft wird.

würde ich selber mit Pointern hantieren, wäre das auch mein erster Verdacht gewesen... ;-)

Gruß Florian

Reply to
Florian E. Teply

Das ist ganz und garnicht so, wie "man" es erwartet. Was passiert denn, wenn der Char, sagen wir mal z.B., 27 enthält und du ihn nach bool castest? False ist es nicht, weil nicht 0. True aber auch nicht, weil nicht 1. Also "vielleicht true" oder "ein bissel false" oder was?

Logisch korrekt ist nur eine bool-Definition, die sämtlichen möglichen Fallen _eindeutig_ einen der zwei möglichen Zustände zuweist. Typisch (und praktisch in der Anwendung) wäre z.B.: 0 entspricht false, jeder von 0 verschiedene Wert entspricht true.

Möglicherweise Bitoperation statt logischer Operation angewendet. Oder umgekehrt.

Reply to
Heiko Nocon

Genau, C. Und richtig, das ist Implementierungsabhängig. Um die Richtige Zuordnung und Auswertung muß sich dann der Compiler kümmern, nicht der Programmierer. Soweit alles klar und in Butter.

Wenn jetzt aber in einer Codezeile eine Variable x auf TRUE gesetzt wird (was auch immer das hinterher bedeuten mag), dann sollte anschließend die Auswertung "if (x == TRUE)" auch wieder TRUE als logischen Wert zurückliefern, und nicht FALSE...

Oder anders gesagt: das Statement "((x != TRUE) && (x != FALSE))" sollte nie zu TRUE evaluiert werden können...

Gute Frage... Um die Initialisierung des SP sollte sich m.E. die Entwicklungsumgebung (CodeWarrior mit ProcessorExpert) kümmern, einstellen kann ich lediglich die größe des Stack...

Spasseshalber habe ich aber gerade mal die Stacksize verdoppelt, und siehe da: nun geht es so wie es soll... *patsch*

Der Speicher sollte mit seinen 32K eigentlich nicht sooo schnell knapp werden, habe gerade mal 17K Codesize. Große Felder könnte schon eher hinkommen, so ne handvoll Arrays (int/char) mit 32-64 Feldern, allein

2-3K nur mit Stringkonstanten, die ich allerdings im Flashbereich ablegen kann und werde, wenn es enger wird. Langfristig wirds dann eh wieder knapp, aber dann reicht auch die Rechenleistung nicht mehr (derzeit bis zu 15.000 Interrupts/s nur aus den seriellen Schnittstellen) und damit wird der µC denn eh hinfällig.

Danke für den Tip, Florian

Reply to
Florian E. Teply

Florian E. Teply formulierte Montag :

Verwendest du large Memory model? Denn im banked mußt du den explizit mit pragmas nutzen.

Xgate schon angeworfen?

LG Andy

Reply to
Andreas Nebenfuehr

Wunschdenken hilft hier nicht weiter ;) Du schreibst doch selber:

#define TRUE 1 #define FALSE 0

BOOL x = 2;

if ((x != TRUE) && (x != FALSE)) printf("Siehst du?!");

--
"Zuse, Zuse" sprach die Tante, als das Rechenzimmer brannte
www.microsoft-hellhounds.de, www.bredobrothers.de
Reply to
Thomas Kindler

#define MOSTLY_TRUE 0.3

(Handbuch fuer angehende Parlamentsmitglieder)

--
SCNR, Joerg

http://www.analogconsultants.com/

"gmail" domain blocked because of excessive spam.
Use another domain or send PM.
Reply to
Joerg

Hmm, weder small noch banked, müsste dann also large sein. Jedenfalls der mit globaler Adressierung...

Äh, nö. Hängt damit zusammen, daß ich dann auf den ProcessorExpert verzichten muß, weil der mit dem XGate nicht kann. Und dann sind 3 Monate Bearbeitungszeit einer Diplomarbeit doch n bissken kurz, wenn man sich alles aus den mMn *seeeehr* besch...eidenen Manuals von freescale rausklauben muß.

Und dann schlägt man sich auch noch zwei Wochen mit unerklärlichen Fehlern rum, weil der Stack zu klein war...

Aber das Konzept an sich ist hier - gefühlt - schon an der Grenze. Wenn's nach mir geht, kommt nach Abgabe der Diplomarbeit sowieso ein Schwenk auf ne andere Hardware-Plattform. Sowas wie n Virtex-II Pro schwebt mir da vor, FPGA mit festverdrahtetem (1 oder 2) PowerPC-Kern.

Dazu dann die doofen Motortreiber wegschmeißen, n paar flinke A/D-Wandler aufs Board geschmissen, etwas Kraftsensorik drangebaut, drei Vollbrücken dazu und ein vernünftiges Netzteil (so 60-70V, mind. 5s kurzschlußfest)...

Gruß, Florian

Reply to
Florian E. Teply

Wenn man das so macht, ist natürlich klar daß das in die Hose gehen muß.

Was aber unter folgenden Bedingungen: #define TRUE 1 #define FALSE 0

bool y = TRUE; bool z = TRUE; bool x = (y || z);

if ((x != TRUE) && (x != FALSE)) printf("Ganz grosses Kino...");

Aber der Grund dafür hat sich inzwischen aufgeklärt, Stack war zu klein... Wenn mir wieder sowas über den Weg läuft, habe ich wenigstens schonmal einen Ansatz, um das eigentliche Problem zu finden.

Gruß, Florian

Reply to
Florian E. Teply

#define MAYBE_TRUE -0.2

(Handbuch für erprobte Diktatoren) ;-)

SCNR, Florian

Reply to
Florian E. Teply

Florian E. Teply schrieb:

[...]

^^^^^^^^^^^^

Jetzt schreibt der das schon wieder...

Das sollst Du nicht machen!

Servus

Oliver

--
Oliver Betz, Munich
despammed.com might be broken, use Reply-To:
Reply to
Oliver Betz

Oliver Betz schrieb:

Lieber so: if(x && !x) return(ER_HEISENBERG);?

Falk

Reply to
Falk Willberg

Ja, ich weiß, es ist auch nicht wirklich sinnvoll.

Äquivalent wäre nach den Regeln von DeMorgan: if !((x == TRUE) || (x == FALSE)), was ebenfalls immer nach FALSE evaluiert werden sollte, in diesem Fall aber ebenfalls nicht passiert ist.

Das man sowas nicht macht, ist mir klar, es ging mir eher darum, zu verdeutlichen, daß es hier eine Situaation war, in der x weder TRUE noch FALSE war... Daß das mit nem überquellenden Stack zusammenhing, habe ich ja nach zwei entsprechenden Hinweisen bereits herausgefunden.

Gruß, Florian

Reply to
Florian E. Teply

Moin,

ich kann mich noch an so Sachen erinnern, wo eine Funktion die einen=20 Wahrheitswert liefern sollte so definiert war:

int ungleich(a, b) { return a-b; }

liefert bei einer Bewertung mit

if (ungleich(10, 20)) das gew=C3=BCnschte Ergebnis, ein Vergleich=20 ungleich(10, 29) =3D=3D TRUE w=C3=BCrde (da intern als Integer implementi= ert) in=20 die Hose gehen.

Was veranla=C3=9Ft Dich dem Konstrukt if (x =3D=3D TRUE) warum nicht if (x), dann macht das ganze wie es soll und ist C-typisch=20 (schmutzig).

In C ist alles was nicht 0 ist wahr, nur es gibt viele Arten von wahr,=20 die nicht gleich sind. Ist zwar irgendwo seltsam, ist aber so.

Gru=C3=9F

Hans

Reply to
Hans Müller

Hans Müller schrieb:

Ähm, wieso ist bitte eine ISO-genormte standardkonforme Implementierung "schmutzig"?

Ja, das sagt der C-Standard. "TRUE" definiert der C-Standard jedenfalls nicht - allenfalls "true", siehe 7.16.3. Und eine konforme Implementierung, die den "bool" Typ benutzt, hält sich auch an 6.3.1.2, das sagt "When any scalar value is converted to _Bool, the result is 0 if the value compares equal to 0; otherwise, the result is 1.".

Die Implementierung ist also einfach kein sauberes C, weil Konvertierungen zu dem implizit verwendeten Typ "char" natürlich auch andere Werte als "true" und "false" annehmen können.

Viele Grüße, Johannes

--
"Wer etwas kritisiert muss es noch lange nicht selber besser können. Es
reicht zu wissen, daß andere es besser können und andere es auch
besser machen um einen Vergleich zu bringen."     -     Wolfgang Gerber
       in de.sci.electronics
Reply to
Johannes Bauer

Hallo Florian,

[...]

Du hast m.E. nicht verstanden, deshalb nochmal: Der Vergleich auf "== TRUE" ist gefährlicher Unfug.

Servus

Oliver

--
Oliver Betz, Munich
despammed.com might be broken, use Reply-To:
Reply to
Oliver Betz

Weil Normierung Dreck nicht sauber machen kann, sondern nur zu normiertem Dreck. Nach wie vor schmutzig.

Wenn ich schmutzig programmieren will oder muß, nehme ich statt des aufgeblasenen Makroassemblers namens C lieber gleich Assembler.

Und in jedem anderen Fall eine richtige Hochsprache.

C ist über. Ein Relikt der Comutergeschichte. Nieder damit.

Reply to
Heiko Nocon

Heiko Nocon schrieb:

...

Und hampelst selbst mit Datentypen herum, die ungleich der Registerbreite des Zielsystems sind?

Ich habe keinen Spaß daran, es macht mir auch keinen Spaß, selber Zeugs auf den Stack zu legen und richtig wieder abzuholen, etc...

Hast Du mal ein Beispiel?

Jawoll! Und die Transistoren gleich hinterher. So antiquiertes Zeug braucht doch keiner mehr.

Mir wollte schon mal einer erzählen, daß C böse sei. Ich müsse in Assembler oder Haskell programmieren ;-)

Falk

Reply to
Falk Willberg

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.