Zitat Zitat von sternst Beitrag anzeigen
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.

Code:
...
//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?