Rechenproblem beim Feldpointer

[oberallgeier]

Ich sehe gar nicht, wie du überhaupt zu dieser Schlussfolgerung kommst ...

Au Stefan, das kommt von meiner schlampigen und zu knappen Fallbeschreibung.

... Also ist doch schon bei der ersten Schleife ein "Offset" von 10 vorhanden ...

a) Vor der I2C-Routine - bei der in einer while(1)-Schleife die Datenänderung lesbar wird, beschreibe ich den Buffer mit Zahlen - angefangen mit 10.

...
//i2cdata mit Werten füllen, die der Master auslesen und ändern kann
// - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
  for(uint8_t i=0;i<i2c_buffer_size;i++)
  {                             //
    i2cdata[i]=10+i;            // Dummywerte aufwärtszählen ab 10 ...
  }                             //
// - - - - - - - - - - - - - - -
//in einer Endlosschleife den Inhalt der Buffer ausgeben
  while(1)                      // === Beginn while (1)
...

Daher ist diese Belegung ab dem Zahlenwert 10 noch im Sinne des Programmierers.

b) Bei den ersten Tests war i2c_buffer_size gleich 252 (also knapp unterm Limit). Auch der wurde beschrieben wie oben vorgestellt. Und auch nach der Programmierung mit den geringfügigen Änderungen war das Feld wohl am gleichen Platz geblieben - deshalb geht die "monoton ganzzahlige" Feldbeschreibung über die spätere Verkleinerung des Buffers hinaus. Dass über dem I2C-Buffer sonst nicht benötigter/benutzter Speicherplatz sein müsste - wegen dieser Darstellung - war mir auch aufgefallen. Und ich weiß nicht warum. Allerdings wurden bei den Änderungen keine Datenspeicher-relevanten Änderungen durchgeführt - keine neuen Datenplätze eingebracht.

Ist dies eine plausible Erklärung für den Nicht-Müll?

[sternst]

...
//i2cdata mit Werten füllen, die der Master auslesen und ändern kann
// - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
  for(uint8_t i=0;i<i2c_buffer_size;i++)
  {                             //
    i2cdata[i]=10+i;            // Dummywerte aufwärtszählen ab 10 ...
  }                             //
// - - - - - - - - - - - - - - -

Daher ist diese Belegung ab dem Zahlenwert 10 noch im Sinne des Programmierers.

Dann verstehe ich erst recht nicht, was denn nun das Problem ist. Du schreibst in die letzten 10 Bytes des Buffers (Index 242 - 251) die Werte 252 bis 5, und du bekommst genau das als Ausgabe.

Und wenn das hier

#define i2c_buffer_size 127

die aktuelle Größe sein soll, wieso steht dann in der Ausgabe "Buffersize : 252"? Und wenn der Buffer 127 Bytes groß sein soll, und die Schleife fälschlicherweise die 10 Bytes hinter dem aktuellen Buffer ausgeben soll (mit dem Inhalt eines ehemals größeren Buffers), warum besteht die "falsche" Ausgabe dann nicht aus den Zahlen 137 bis 146?

[oberallgeier]

Dann verstehe ich erst recht nicht, was denn nun das Problem ist ...

Danke Stefan. Mein Problem heißt wohl so in der Art "sich selbst ein Bein stellen" oder . . . das will ich nu nicht schreiben.

Beim Nachdenken ist mir jetzt klar geworden was passiert. Ich schreibe (beispielsweise, siehe erstes Posting, drittes Codefenster mit "Buffersize : 252") 252 uint8_t-Zahlen, die ab dem Werte 10 hochgezählt werden, in den I2C-Buffer. Es ist deutlich zu sehen, dass die Einzelwerte nicht bei 252 aufhören, sondern uint8_t-gerecht bis 255 weiterlaufen und mit 0 wieder anfangen. Im 242ten Feld steht auch korrekt 242+10 (krieg ich im Moment sogar im Kopf hin, das ist 252) - und danach gehts weiter und bis über den Zahlenüberlauf hinaus.

Mist, ich hab mich im beschränkten Zahlenraum der 8bittigen, unsigned Welt verheddert.

Danke für die geduldigen Denkanstösse.