- LiTime Speicher und Akkus         
Ergebnis 1 bis 5 von 5

Thema: Rechenproblem beim Feldpointer

  1. #1
    Erfahrener Benutzer Robotik Visionär Avatar von oberallgeier
    Registriert seit
    01.09.2007
    Ort
    Oberallgäu
    Beiträge
    8.651

    Rechenproblem beim Feldpointer

    Anzeige

    Powerstation Test
    Bitte um Hilfe oder Aufklärung.

    Für eine I2C-Kommunikation teste ich meinen Code auf saubere Funktion und exakte Positionierung der verschiedenen Daten. Derzeit zwei Platinen (RNContrl - mega1284/20MHz, RNMotoContrl - m328/20MHz, I2C 100 kHz).

    Ein Test besteht darin, drei Ausschnitte des übermittelten Feldes vom Slave per UART wiederholt auszugeben. Der letzte Ausschnitt sollen die letzten zehn Bytes des I2C-Puffers sein. Leider macht mein Feldpointer nicht das was ich will: die Berechnung (egal ob uint8_t oder ~16~) in der for..Schleife ist fehlerhaft.

    I2C-Definition (Ausschnitt) (danke uwegw für den Slave-Code) :
    Code:
    //%%%%%%%% von Benutzer konfigurierbare Einstellungen %%%%%%%%
    /**@brief Groesse des Buffers in Byte (2..254) */
    #define i2c_buffer_size 127      // I2C_REG_ANZAHL 254 Hier kann eingestellt werden
                                    //   wieviele Register ausgegeben werden
    //##### ÎÎÎÎÎÎÎÎÎÎÎÎÎÎÎÎÎÎÎÎ #####
    ... und die Ausgaberoutine im Slave (Ausschnitt) :
    Code:
    // - - - - - - - - - - - - - - -
        uart_puts("\t\t\t");        // Einrücken
        for (uint8_t i=10; i<20; i++)
          {
          uart_puti(i2cdata[i]);uart_puts("    ");  //uart_puts("\r\n");
          }                         // === Ende for (uint8_t i=0; i<i2c_buffer_size...
        uart_puts("\r\n");          // Neue Zeile und Leerzeile
        _delay_ms( 1000);
    // - - - - - - - - - - - - - - -
        uart_puts("\t\t\t");        // Einrücken
        for (uint8_t i=(i2c_buffer_size-10); i<i2c_buffer_size; i++)
          {
          uart_puti(i2cdata[i]);uart_puts("    ");  //uart_puts("\r\n");
          }                         // === Ende for (uint8_t i=0; i<i2c_buffer_size...
        uart_puts("\r\n");          // Neue Zeile und Leerzeile
        _delay_ms( 1000);
    // - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
    Dabei wird für die letzte Ausgabe immer am Ende des Buffers begonnen, nicht wie ich möchte, zehn Felder davor.

    Code:
        C501 R5MoCo_x01-x10 m328/20MHz 26Sep2012 2335
        Aufbau R5MoCo, I2C-Slave ist Adresse :  130    I2C-WRITE = 0
        Test I2C
    
        I2C-Test - I2C-Slave R5MoCo_i2c10.c
        Teste I2C-Slave mit Adresse :  130    Buffersize :  252
    
        Nr. 1    i2cdata:    10    11    12    13    14    15    16    17    18    19    
                20    21    22    23    24    25    26    27    28    29    
                252    253    254    255    0    1    2    3    4    5    
        Nr. 2    i2cdata:    10    99    12    13    14    15    16    17    18    19    
                20    21    22    23    24    25    26    27    28    29    
                252    253    254    255    0    1    2    3    4    5    
        Nr. 3    i2cdata:    10    99    12    13    14    15    16    17    18    19    
    <0>
        C501 R5MoCo_x01-x10 m328/20MHz 26Sep2012 2335
        Aufbau R5MoCo, I2C-Slave ist Adresse :  130    I2C-WRITE = 0
        Test I2C
    
        I2C-Test - I2C-Slave R5MoCo_i2c10.c
        Teste I2C-Slave mit Adresse :  130    Buffersize :  252
    
        Nr. 1    i2cdata:    10    11    12    13    14    15    16    17    18    19    
                20    21    22    23    24    25    26    27    28    29    
                252    253    254    255    0    1    2    3    4    5    
        Nr. 2    i2cdata:    10    99    12    13    14    15    16    17    18    19    
                20    21    22    23    24    25    26    27    28    29    
                252    253    254    255    0    1    2    3    4    5    
        Nr. 3    i2cdata:    10    99    12    13    14    15    16    17    18    19    
    <0>
        C501 R5MoCo_x01-x10 m328/20MHz 26Sep2012 2335
        Aufbau R5MoCo, I2C-Slave ist Adresse :  130    I2C-WRITE = 0
        Test I2C
    
        I2C-Test - I2C-Slave R5MoCo_i2c10.c
        Teste I2C-Slave mit Adresse :  130    Buffersize :  127
    
        Nr. 1    i2cdata:    10    11    12    13    14    15    16    17    18    19    
                20    21    22    23    24    25    26    27    28    29    
                127    128    129    130    131    132    133    134    135    136    
        Nr. 2    i2cdata:    10    99    12    13    14    15    16    17    18    19    
                20    21    22    23    24    25    26    27    28    29    
                127    128    129    130    131    132    133    134    135    136    
        Nr. 3    i2cdata:    10    99    12    13    14    15    16    17    18    19    
                20    21    22    23    24    25    26    27    28    29    
                127    128    129    130    131    132    133    134    135    136    
        Nr. 4    i2cdata:    10    99    12    13    14    15    16    17    18    19    
    <0>
        C501 R5MoCo_x01-x10 m328/20MHz 26Sep2012 2335
        Aufbau R5MoCo, I2C-Slave ist Adresse :  130    I2C-WRITE = 0
        Test I2C
    
        I2C-Test - I2C-Slave R5MoCo_i2c10.c
        Teste I2C-Slave mit Adresse :  130    Buffersize :  99
    
        Nr. 1    i2cdata:    10    11    12    13    14    15    16    17    18    19    
                20    21    22    23    24    25    26    27    28    29    
                99    100    101    102    103    104    105    106    107    108    
        Nr. 2    i2cdata:    10    99    12    13    14    15    16    17    18    19    
                20    21    22    23    24    25    26    27    28    29    
    <0>
        C501 R5MoCo_x01-x10 m328/20MHz 26Sep2012 2335
        Aufbau R5MoCo, I2C-Slave ist Adresse :  130    I2C-WRITE = 0
        Test I2C
    
        I2C-Test - I2C-Slave R5MoCo_i2c10.c
        Teste I2C-Slave mit Adresse :  130    Buffersize :  99
    
        Nr. 1    i2cdata:    10    11    12    13    14    15    16    17    18    19    
                20    21    22    23    24    25    26    27    28    29    
                99    100    101    102    103    104    105    106    107    108    
        Nr. 2    i2cdata:    10    99    12    13    14    15    16    17    18    19    
                20    21    22    23    24    25    26    27    28    29    
                99    100    101    102    103    104    105    106    107    108
    ... und das sollte eben nicht stimmen. Nur - wieso? Wo ist der Fehler?

    Problem: die Berechnung
    i2c_buffer_size-10
    macht offenbar nicht das, was sie soll. Anm.: ich habe die for..Laufvariable mit 8bit und mit 16 getestet.

    Danke im Voraus für Eure Hilfe und Aufmerksamkeit.
    Ciao sagt der JoeamBerg

  2. #2
    Erfahrener Benutzer Roboter Experte Avatar von sternst
    Registriert seit
    07.07.2008
    Beiträge
    672
    Zitat Zitat von oberallgeier Beitrag anzeigen
    Dabei wird für die letzte Ausgabe immer am Ende des Buffers begonnen, nicht wie ich möchte, zehn Felder davor.
    Ich sehe gar nicht, wie du überhaupt zu dieser Schlussfolgerung kommst.

    Offenbar ist doch die Ausgabe von diesem Teil
    ... und die Ausgaberoutine im Slave (Ausschnitt) :
    diese beiden Zeilen:
    Code:
    20    21    22    23    24    25    26    27    28    29    
    252    253    254    255    0    1    2    3    4    5
    Also ist doch schon bei der ersten Schleife ein "Offset" von 10 vorhanden.
    Das sieht für mich eher so aus, als ob entweder das Array nicht den erwarteten Inhalt hat, oder die Funktion uart_puti() nicht korrekt funktioniert.

    Außerdem: Wenn deine Schlussfolgerung zutreffen würde, wieso ist der Output dann so "regelmäßig"? Die zehn Bytes hinter dem Buffer müssten doch eher wie "Müll" aussehen.
    MfG
    Stefan

  3. #3
    Erfahrener Benutzer Robotik Visionär Avatar von oberallgeier
    Registriert seit
    01.09.2007
    Ort
    Oberallgäu
    Beiträge
    8.651
    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?
    Ciao sagt der JoeamBerg

  4. #4
    Erfahrener Benutzer Roboter Experte Avatar von sternst
    Registriert seit
    07.07.2008
    Beiträge
    672
    Zitat Zitat von oberallgeier Beitrag anzeigen
    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 ...
      }                             //
    // - - - - - - - - - - - - - - -
    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
    Code:
    #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?
    Geändert von sternst (27.09.2012 um 19:54 Uhr)
    MfG
    Stefan

  5. #5
    Erfahrener Benutzer Robotik Visionär Avatar von oberallgeier
    Registriert seit
    01.09.2007
    Ort
    Oberallgäu
    Beiträge
    8.651
    Zitat Zitat von sternst Beitrag anzeigen
    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.
    Ciao sagt der JoeamBerg

Ähnliche Themen

  1. Problem beim Konfigurieren von TIMER1 beim M32-Board
    Von dirty_bird_981 im Forum Robby RP6
    Antworten: 8
    Letzter Beitrag: 10.01.2012, 23:52
  2. Rechenproblem mit Single
    Von Tido im Forum Basic-Programmierung (Bascom-Compiler)
    Antworten: 15
    Letzter Beitrag: 21.07.2009, 11:26
  3. Rechenproblem (Syntax?)
    Von Bääääär im Forum C - Programmierung (GCC u.a.)
    Antworten: 12
    Letzter Beitrag: 07.03.2008, 18:53
  4. Busfrequenz beim PCF8574 und beim PCF8591?
    Von roboter im Forum Elektronik
    Antworten: 2
    Letzter Beitrag: 17.04.2007, 15:34
  5. Antworten: 9
    Letzter Beitrag: 14.03.2005, 21:08

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •  

LiTime Speicher und Akkus