Funktionswerte in Array schreiben

[Andreas S. (bedrich)]

Nabend zusammen,

mein ATMega8 liest per SPI Messwerte von einem Sensor aus sechs 
aufeinander folgenden Registern. Folgende Zeilen werden dazu in WinAVR 
GCC anstandslos kompiliert:

1.

for(i=0;i<6;++i)
  res[i]=sensor_read_reg(0x28+i);

2.

res[0]=sensor_read_reg(0x28);
res[1]=sensor_read_reg(0x29);
res[2]=sensor_read_reg(0x2A);
res[3]=sensor_read_reg(0x2B);
res[4]=sensor_read_reg(0x2C);
res[5]=sensor_read_reg(0x2D);

Später im Programm wird res[i] per UART ausgegeben.

*Und jetzt das Rätsel:*
Fall 1 führt bei der stets gleichen Ausgabe "uart_puts(itoa...) zu 
Sonderzeichen-Kauderwelsch, Fall 2 zu den gewünschten Zahlenkolonnen.
Hat jemand einen guten Tipp, was an der ersten Formulierung nicht 
stimmen könnte?

Beste Grüße vom Bedrich

[WK (Gast)]

Andreas Schell schrieb:
> for(i=0;i<6;++i)
>   res[i]=sensor_read_reg(0x28+i);

Hallo Andreas,

ein "i++", statt "++i" sollte Abhilfe schaffen.

Gruß
WK

[Peter II (Gast)]

WK schrieb:
> ein "i++", statt "++i" sollte Abhilfe schaffen.

nein das ändert nichts.

[WK (Gast)]

Hallo Andreas,

Verzeihung, habe gerade das Problem entdeckt:

> res[i]=sensor_read_reg(0x28+i)
0x28 ist Hexadezimal i hingegen Dezimal

0x28 + 1  ergibt also 50, was bei dir zu Kauderwelsch führt.

Gruß

WK

[B e r n d W. (smiley46)]

> 0x28 + 1  ergibt also 50

Ob da 0x28+1 steht oder 40+1, ist vollkommen egal.

[Hmm (Gast)]

Au weia, kann ich da nur sagen.

WK schreibt absoluten Nonsens.

@ Andreas
Zeig mal den kompletten Code. In den Schnipseln ist nichts Auffälliges 
zu sehen.

[Ingo (Gast)]

WK schrieb:
> Hallo Andreas,
>
> Verzeihung, habe gerade das Problem entdeckt:

Kannst du mir das mal erklären? Ich glaube du hast noch weniger Ahnung!

[Andreas S. (bedrich)]

> @ Andreas
> Zeig mal den kompletten Code. In den Schnipseln ist nichts Auffälliges
> zu sehen.
...das würde jetzt den Rahmen sprengen und wäre stinklangweilig, aber 
vielleicht das hier noch: diese read_reg - Funktion tut ihren Job nur im 
zweiten Fall:

uint8_t sensor_read_reg(uint8_t reg) 
{
  uint8_t res;
  sensor_set_csb(0);  // SPI select +
  SPI_Transfer(reg|1<<7);  // Bit7: Lesen von Register
  res=SPI_Transfer(0);  // Dummy Transfer
  sensor_set_csb(1);  // SPI select -
  return res;
}

Was auch nicht bzw. in der beschriebenen Weise funktioniert, ist 
"multiple read out" laut Datenblatt - also alle sechs Byte in einem 
Rutsch auslesen, ohne den SPI select nach jedem Byte hochzuziehen - da 
kommt auch Käse raus. Ich habe die Hoffnung, dass irgendwo noch wer so 
was großartiges weiß wie "Du musst einen 68 Ohm Serienwiderstand in die 
SCK Leitung machen" oder "Das muss man wie folgt mit Zeigern formulieren 
... Nicht 3+4=21 ;-) Der Sensor ist ein Gyro von ST.

[Hmm (Gast)]

>Ich habe die Hoffnung, dass irgendwo noch wer so was großartiges weiß

Wie soll man denn so etwas wissen, ohne:
Schaltplan
Quellcode
Foto vom Aufbau

>...das würde jetzt den Rahmen sprengen und wäre stinklangweilig,
Das ist unlogisch. Der Rahmen wird genau dadurch festgelegt, was nötig 
ist, um das Problem zu lösen.

Ohne Quellcode etc. ist der Rahmen zu eng.

[Hmm (Gast)]

Bist in mein css file aufgenommen.

Schönes Leben noch.

[Andreas S. (bedrich)]

@Hmm: schon richtig: wenn etwas nicht funktioniert, dann ist oftmals 
irgendwo in der Komplexität von Schaltung, elektrischer Umgebung, 
Temperatur und nicht zuletzt Tagesform des Experimentators der Hund 
begraben. Es ist auch sicher bis zu einem gewissen Ausmaß sinnvoll, alle 
Aspekte anzusehen.
Aber was nützt in dem Fall ausgerechnet der Schaltplan für einen SPI 
Bus? Da gehen gerade Striche von MOSI nach MOSI, MISO nach MISO, SCK 
nach SCK, Alle Bauteile sitzen auf der gleichen Masse und haben die 
gleiche, für alle geeignete Versorgungsspannung.
Was nützt fürderhin der komplette Quellcode, wenn das bereits durch 
Codeschnipsel 2 "unelegant" (?) gelöste Problem genau mit der for - 
Schleife in Schnipsel 1 auftritt?
Schönen Abend vom Bedrich

[Ingo (Gast)]

Zum Beispiel lässt sich deine for Schleife garantiert nicht anstandslos 
kompilieren, da i nicht definiert ist. Ergo passiert das woanders. Wenn 
du nun aus welchen Gründen auch immer i global gemacht hast, und in 
Interrupts daran rumdrehst, brauchst du dich nicht wundern wenn deine 
Schleife Müll produziert. Soviel mal dazu...

[Rolf M. (rmagnus)]

Andreas Schell schrieb:
> Aber was nützt in dem Fall ausgerechnet der Schaltplan für einen SPI
> Bus? Da gehen gerade Striche von MOSI nach MOSI, MISO nach MISO, SCK
> nach SCK, Alle Bauteile sitzen auf der gleichen Masse und haben die
> gleiche, für alle geeignete Versorgungsspannung.

Es geht nicht um die drei Drähte für SPI, sondern um den gesamten 
Schaltplan. Haben z.B. alle ICs die nötigen Abblock-Kondensatoren?

> Was nützt fürderhin der komplette Quellcode, wenn das bereits durch
> Codeschnipsel 2 "unelegant" (?) gelöste Problem genau mit der for -
> Schleife in Schnipsel 1 auftritt?

Die beiden gezeigten Codeschnipsel sind gleichwertig (bei geeigneter 
Definition von i). Also muß der Fehler irgendwo an einer Stelle liegen, 
die du nicht gezeigt hast. Da kannst du noch so darauf bestehen, daß der 
Fehler in den geposteten Zeilen zu liegen hat. Auch wenn du beleidigt 
dreinschaust und mit dem Fuß aufstampfst, wird der Fehler nicht dorthin 
wandern.

[Andreas S. (bedrich)]

Ihr habt natürlich Recht. Zum Abschluss: Mein Problem ist in zwei 
Hälften zerfallen.

1. Der UART-Kauderwelsch war mit dem AVR User Manual zu besiegen:
http://www.nongnu.org/avr-libc/user-manual/group__avr__string.html
Das Zitat, das ich gerne auf mich nehme:
"If the destination string of a strcpy() is not large enough (that is, 
if the programmer was stupid/lazy, and failed to check the size before 
copying) then anything might happen. Overflowing fixed length strings is 
a favourite cracker technique." Also jaaaa-jaaaaa, völlig andere 
Baustelle.

2. Das mit der for-Schleife ist nicht so einfach, weil der Fehler nicht 
reproduzierbar Auftritt. Der Sensor ist schluckt offenbar einzelne Bits, 
wenn man das Chip Select Signal nicht lang genug oder zu lang stehen 
lässt. Leider ist das Datenblatt an der Stelle auch nicht sonderlich 
hilfreich.
Verzicht auf for löst, besser umgeht in diesem Falle das Problem (und 
resultiert in einem etwas kleinerem .hex file).

Dank und Gruß vom bedrich

[Karl H. (kbuchegg)]

Andreas S. schrieb:

> 2. Das mit der for-Schleife ist nicht so einfach, weil der Fehler nicht
> reproduzierbar Auftritt. Der Sensor ist schluckt offenbar einzelne Bits,
> wenn man das Chip Select Signal nicht lang genug oder zu lang stehen
> lässt.

Das glaub ich ehrlich gesagt nicht.
Denn zum einen ist die Behandlung des Chip-Select Signals komplett in 
der Funktion sensor_read_reg gekapselt und daher nicht davon abhängig 
wer und und welchem Kontext die Funktion aufgerufen wird. Zum anderen 
ist das auch nicht sonderlich logisch. Und wenn du der einzige bist, dem 
ein derartiges Verhalten auffällt, weltweit gesehen es aber niemand 
anderen gibt, der so etwas beobachtet hätte, dann brauch ich nicht lange 
überlegen, ob ich den IC-Hersteller da in die Pflicht nehmen muss oder 
nicht.

> Verzicht auf for löst, besser umgeht in diesem Falle das Problem (und
> resultiert in einem etwas kleinerem .hex file).

yep. Du hast also einen Weg gefunden, wie du trotz Fehler im Programm 
gute Werte kriegst. Ok. Wenn dir das reicht.

[Andreas S. (bedrich)]

Karl Heinz Buchegger schrieb:
>
> yep. Du hast also einen Weg gefunden, wie du trotz Fehler im Programm
> gute Werte kriegst. Ok. Wenn dir das reicht.

Hallo Karl Heinz, das reicht mir natürlich nicht, muss aber erst mal 
warten. Ich komme am besten mit einem neuen Thread zu dem Thema zurück, 
wenn ich mit den dringenderen Hausaufgaben durch bin. Das SPI-Thema 
passt ja jetzt auch nicht mehr zur Überschrift.