mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik AVR AtMEGA328P-PU u. I2C in Arduino: Probleme mit mehrdimensionale Arrays


Autor: M. S. (marvs)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
Guten Tag alle zusammen,

in diesem Beitrag möchte ich mit euch ein Problem von mir teilen.

Ich habe vor, mit I2C, ein mehrdimensionales Array zu versenden an
einen "Slave". Der "Master"- sowie der "Slavecode" bringen nicht das 
gewünschte Ergebnis trotz fehlerfreim Code (glaub ich... es gibt keine 
Compilerfehler.).
Um genauer zu sein: es geht um ein zweidimensionales Array der Größe 
8x8.
Beide Mikrocontroller werden über die Arduino-IDE programmiert. Beide 
sind
ein Klon...(glaub ich zumindest, dass beide Klons sind. Orginale sind es 
beide nicht XD ) von dem Arduino UNO Board.
(Maker Factory, ATMEGA328 UNO Entwicklungsboard)
(Controller:Atmel_1725_ATMEGA328P-PU und Atmel_1735_ATMEGA328P-PU)

Es geht darum, Nullen und Einsen zu versenden und vom anderen anzeigen 
zu
lassen.

Um das Array zu senden lass ich es, weil es wie auf der Arduino-Webseite 
nicht geht, durch eine For-Schleife Wert für Wert verseden.

Dies sieht so aus:
#include <Wire.h>

byte led[8][8] = {    //Array mit dem "Bild" aus Einsen.(Es ist ein Smiley)                
  {1,1,1,1,1,1,1,1},                  
  {0,0,0,0,0,0,0,0},                  
  {0,0,1,0,0,1,0,0},                  
  {0,0,0,0,0,0,0,0},                 
  {0,0,0,1,1,0,0,0},                 
  {0,1,0,0,0,0,1,0},                 
  {0,0,1,1,1,1,0,0},                  
  {1,1,1,1,1,1,1,1}                   
};  
int y=0, x=0;
int i;        //Ich weiß. Unnötig aber war ein anderer Ansatz.

void setup() {
  Serial.begin(9600);
  Wire.begin(9);
  //sendarr(led[8][8]);  //Erste Funktion.
  //sarr(led[8][8]);     //Zweite Funktion.
}

void loop() {
  //sarr(led[8][8]);    //Fehlgeschlagener Versuch,
  //delay(2000);        //es dauerhaft zu versenden mit Zeitabstand.
}

void sendarr(byte led[8][8]) {
  Wire.beginTransmission(8);
  for (int i=0;i<=64; i++) {
    Wire.write(led[y][x]);   //Das geht nicht, auch nicht wenn man versucht
    x++;                     // es auf Wire.write(led, 64); zu bringen.
    if (x==7) { 
      x=0;
      y++;
    }
    if (y==7) {
      x=0;
      y=0;
    }
  }
  Wire.endTransmission();
}

void sarr(byte led[8][8]) {
  Serial.println("Anfang");
  Wire.beginTransmission(8);
  for (i=0;i<=64; i++) {
    byte lol = led[y][x];   //Zweite Variante, die meistens Wirkung zeigt
    Serial.print(lol);
    Wire.write(lol);        //als es so wie oben zu machen.
    x++;
    if (x==8) {
      Serial.println();
      x=0;
      y++;
    }
    //if (y==7) {                   //Hiermit wurde versucht, die Schleife
      //Serial.println(y);          //zu verlassen, als das noch in loop()
      //Wire.endTransmission();     //stand zur dauerhaften wiederholung.
      //break;
    //}
  }
  
  //delay(500);                    //Relikte aus dem loop() bevor es zur
  //i=0;                           //Funktion wurde.
  Serial.println("Ende");
}

Weil der Code keine Fehler warf, nahm ich am Anfang an, der "Slave" wäre 
falsch programmiert. Erst als ich aus Interesse wie das Signal aussieht 
den Beispielcode laufen ließ mit angschlossenem Oszilloskop, fiel mir 
auf, das bei meinem Code noch nicht einmal was gesendet wird.

Der Fehler beginnt also schon am "Master writer".

Wenn jemand weiß, wie man sowas löst oder generell eine Idee dazu hat:
Ich bin stark dran interessiet.


PS: Ich möchte mich für Schreibfehler, falsche Formatierung des Codes 
und oder Programmierungsstil entschuldigen. Entschuldigung.
Ich hoffe, dass das dennoch alles Regelkonform ist was ich hier verzapft 
habe.

Mfg

MarvS

Autor: Stefanus F. (stefanus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> bringen nicht das gewünschte Ergebnis trotz fehlerfreim
> Code (glaub ich... es gibt keine Compilerfehler.).

Wenn das Ergebnis fehlerhaft ist, muss wohl der Code fehlerhaft sein. 
Dass der Compiler keinen Fehler meldet, heisst nicht viel. Zumal in der 
Arduino IDE standardmässig alle Warnungen unterdrückt werden (stelle das 
mal um!).

> for (i=0;i<=64; i++)

Das sind 65 Schritte - einer zu viel!

> x++;
> if (x==7) {
>    x=0;
> }

Damit kommst du nur von 0 bis 6 - einer zu wenig!

> if (y==7) {
>     x=0;
>     y=0;
> }

Gleicher Fehler nochmal.

Ich würde das Senden mit zwei verschachtelten Schleifen machen:
void sendarr(byte led[8][8]) 
{
    for (byte x=0; x<8; x++)
    {
        for (byte y=0; y<8; y++)
        {
            byte b=led[y][x];
            Serial.print(b);
        }
        Serial.println();
    }
}

> Erst als ich aus Interesse wie das Signal aussieht
> den Beispielcode laufen ließ mit angschlossenem Oszilloskop, fiel mir
> auf, das bei meinem Code noch nicht einmal was gesendet wird.

Aber Dir muss doch schon vorher aufgefallen sein, dass die Serial 
Ausgabe auch falsch ist. Wie sieht denn dein Schaltplan aus? Sind da 
Pull-Up Widerstände drin? Welchen Pegel haben die beiden Leitungen SDA 
und SDL während der Blockierung? Hast du die beiden Module mit GND 
untereinander verbunden?

Autor: Elektro Heini (Gast)
Datum:

Bewertung
3 lesenswert
nicht lesenswert
Hi,

ich kenne zwar den Header Wire.h nicht und habe den Code nur kurz 
überflogen, jedoch kann ich dir einen Tipp geben:

Du willst 8x8 Nullen und Einsen versenden und verwendest dafür bytes. 
Das sind insgesamt 64byte. Das ist zwar noch möglichen aber für einen 
Atmega recht viel. Verwende doch lieber einen Array mit acht Bytes, bei 
denen du jedes Bit einzeln setzt, so in etwa:
byte led[8] = {                
  0b11111111,                  
  0b00000000,                  
  0b00100100,                  
  0b00000000,                 
  0b00011000,                 
  0b01000010,                 
  0b00111100,                  
  0b11111111               
};  


Das ist nur 8byte RAM und wesentlich schneller vom Atmega zu 
verarbeiten. Auch dein Programm wird einfacher (keine geschachtelten 
Schleifen mehr). Überarbeite vlt. noch einmal deinen Code oder ändere 
das Konzept. Wofür brauchst du eigentlich 2 µC? Es ist nämlich meistens 
deutlich einfacher nur ein Programm zu schreiben als zwei die 
miteinander kommunizieren müssen (das ist wirklich aufwendig).

LG

Autor: Arduino Fanboy D. (ufuf)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
M. S. schrieb:
> byte led[8][8]

Der Wire Sende und Empfangsbuffer ist nur 32 Byte groß.
Das Array passt da, in einem Block, nimmer rein.

Siehe: https://www.arduino.cc/en/Reference/Wire

M. S. schrieb:
> trotz fehlerfreim Code
Naja...
Wire.write() liefert eine Erfolgs- oder Fehlermeidung, welche du 
großzügig ignorierst.
"Fehlerfrei", ist da nicht das richtige Wort.

: Bearbeitet durch User
Autor: Blabla (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi, ja als erstes mal die Beschaltung prüfen und auch ein 
Minimalbeispiel ausprobieren und daraus lernen.

z.B.: http://hlembke.de/arduinoablage/crate.php?20150411i2c
      https://www.arduino.cc/en/Tutorial/MasterWriter

Abgesehen von der wirklich suboptimalen Programmierung die schon erwähnt 
wurde solltest du auch versuchen zu Verstehen wie I2C funktioniert.

Dein Sender wird wenn ich das richtig sehe als Slave initialisiert. 
Jedoch Steuert der Master immer die Kommunikation. Kann also nicht 
gehen. Auch fehlt mir der Code der Gegenseite.

Dein Problem ist nicht der RAM.

Autor: Arduino Fanboy D. (ufuf)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
> Blabla schrieb:
> Dein Sender wird wenn ich das richtig sehe als Slave initialisiert.
Ja, ist aber nicht schlimm....

Blabla schrieb:
> Jedoch Steuert der Master immer die Kommunikation.
Ja, ist aber nicht schlimm.

> Blabla schrieb:
> Kann also nicht gehen.
Doch doch.
I2C kann Multimaster.
Wire auch.

Blabla schrieb:
> Dein Problem ist nicht der RAM.
Aber der zu kleine Buffer.
Und der liegt im Ram.

: Bearbeitet durch User
Autor: M. S. (marvs)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
Hallo @Stefanus,

ich hätte eventuel anmerken sollen das ich mich bedingt auskenne.

>for (i=0;i<=64; i++) "Das sind 65 Schritte - einer zu viel!"
Ja.

>if (x==7) {

Das ist mir bekannt. Ich hatte das auch schon längst korrigiert.
Ich habe vergessen das so zu speichern.

>Aber Dir muss doch schon vorher aufgefallen sein, dass die Serial
Ausgabe auch falsch ist.

Nein.
Die Ausgabe war:
11111111
00000000
00100100
00000000
00011000
01000010
00111100
11111111
1 (<-Hier der Fehler mit der 65.)
Das war somit für mich richtig.

>Wie sieht denn dein Schaltplan aus? Sind da Pull-Up Widerstände drin?

A5 an A5. A4 an A4. GND an GND.
Auf die Widerstände habe ich verzichtet. Beide lagen direkt vor meiner 
Nase.
Da dachte ich:"Vier cm...brauch ich nicht.".

Das mit dem Ozilloskop war reine Neugier. Ich habe das Ding rausgekrammt 
und einfachmal angeschlossen. Ich bin kein Profi damit. Ich benutze es 
ja auch kaum bishin zu garnicht. Ich besitze es einfach nur.

Mfg
MarvS

Autor: Stefanus F. (stefanus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
M. S. schrieb:
> Auf die Widerstände habe ich verzichtet.

Die sind aber notwendig.

Ich teste I²C gerne mit niedrigen Bitraten und LED's. Dann sieht man sie 
flackern - oder auch nicht. Und man sieht an Dauerleuchten auch, wenn 
der Bus hängt.

            4,7k Pull-Up
SDA o---+------[===]------+-----o 5V
        |                 |
        +---[===]---|<|---+
            2,2k    LED

Und das gleiche nochmal für SCL.

Autor: M. S. (marvs)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
@ Elektro Heini
Hallo,

> Tipp:
>
> Du willst 8x8 Nullen und Einsen versenden und verwendest dafür bytes.
> Das sind insgesamt 64byte. Das ist zwar noch möglichen aber für einen
> Atmega recht viel. Verwende doch lieber einen Array mit acht Bytes, bei
> denen du jedes Bit einzeln setzt, so in etwa:
>
>
> byte led[8] = {
>   0b11111111,
>   0b00000000,
>   0b00100100,
>   0b00000000,
>   0b00011000,
>   0b01000010,
>   0b00111100,
>   0b11111111
> };
> 
> 
>
> Das ist nur 8byte RAM und wesentlich schneller vom Atmega zu
> verarbeiten. Auch dein Programm wird einfacher (keine geschachtelten
> Schleifen mehr). Überarbeite vlt. noch einmal deinen Code oder ändere
> das Konzept.

Ich werde versuchen, das abzuändern.

> Wofür brauchst du eigentlich 2 µC? Es ist nämlich meistens
> deutlich einfacher nur ein Programm zu schreiben als zwei die
> miteinander kommunizieren müssen (das ist wirklich aufwendig).

Einer der beiden ist stark beschäftigt. Da versuche ich den Code klein 
zu halten. Ich speichere auch deshalb das Array auch auf einem anderem 
zudem es auch auf dem geändert werden soll per Tastereingaben.

Mfg
MarvS

Autor: Blabla (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ok Fanby, dann kläre mich mal auf wie die Wire.h funktioniert. Da die 
Arduino Hilfe sa leider sehr dürftig ist und ich das nicht wirklich oft 
benutze kenne mich nicht so gut aus.

1. Darf ein Slave mit dem anderen Kommunizieren? (Vermutung da der 
zweite Teil des Codes fehlt. Aber es werden die Adressen 8 und 9 
verwendet.)

M. S. schrieb:
> Wire.write(led[y][x]);

2. Wo werden hier die Daten in den Puffer geschoben und wann wird die 
eigentliche Übertragung durchgeführt? Ich sehe da immer nur ein byte pro 
Aufruf der write Funktion.

Autor: M. S. (marvs)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
@ ufuf
Hallo,

>> byte led[8][8]
>
> Der Wire Sende und Empfangsbuffer ist nur 32 Byte groß.
> Das Array passt da, in einem Block, nimmer rein.
>
> Siehe: https://www.arduino.cc/en/Reference/Wire

Stimmt. (Facepalm)

>> trotz fehlerfreim Code
> Naja...
> Wire.write() liefert eine Erfolgs- oder Fehlermeidung, welche du
> großzügig ignorierst.
> "Fehlerfrei", ist da nicht das richtige Wort.

Das wirft eine Erfolgsmeldung?
Das es Fehlermeldungen wirft wusste ich aber es gab keins von beidem.
...

Mfg
MarvS

Autor: Arduino Fanboy D. (ufuf)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
M. S. schrieb:
> Das wirft eine Erfolgsmeldung?

Ja!
Aber sie gesagt: Die ignorierst du gekonnt.

> *Returns*
> byte: write() will return the number of bytes written,
> though reading that number is optional
Aus: https://www.arduino.cc/en/Reference/WireWrite

: Bearbeitet durch User
Autor: M. S. (marvs)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
@ Stefanus
Hallo,
>> Auf die Widerstände habe ich verzichtet.
>
> Die sind aber notwendig.

Auch bei Kurzstrecken also.... . Ok, verstanden.

> Ich teste I²C gerne mit niedrigen Bitraten und LED's. Dann sieht man sie
> flackern - oder auch nicht. Und man sieht an Dauerleuchten auch, wenn
> der Bus hängt.
>
>
> 
>             4,7k Pull-Up
> SDA o---+------[===]------+-----o 5V
>         |                 |
>         +---[===]---|<|---+
>             2,2k    LED
> 
>
> Und das gleiche nochmal für SCL.

Werde es beachten. Suche dann Morgen mir Widerstände aus meiner Kiste 
und
hänge sie mit dran.

Mfg
MarvS

Autor: Stefanus F. (stefanus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Blabla schrieb:
> Wo werden hier die Daten in den Puffer geschoben und wann wird die
> eigentliche Übertragung durchgeführt?

Die Übertragung findet erst ganz zum Schluss bei Wire.endTransmission() 
statt.

Anstatt hier so unterschwellig einen auf Oberlehrer zu machen, könntest 
du einen Blick in den Quelltext (Wire.c) werfen, der ist ja alles andere 
als geheim.

: Bearbeitet durch User
Autor: Stefanus F. (stefanus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
M. S. schrieb:
>>> Auf die Widerstände habe ich verzichtet.
>> Die sind aber notwendig.
> Auch bei Kurzstrecken also.... . Ok, verstanden.

Ja sicher doch, denn die Mikrocontroller betreiben ihre Ausgänge im 
Open-Drain Modus (auch als Wired-And bekannt). Den High Pegel liefern 
die Widerstände.

https://hackaday.com/2017/02/08/taking-the-leap-off-board-an-introduction-to-i2c-over-long-wires/

Autor: M. S. (marvs)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
Hallo,

@  Blabla
> 1. Darf ein Slave mit dem anderen Kommunizieren? (Vermutung da der
> zweite Teil des Codes fehlt. Aber es werden die Adressen 8 und 9
> verwendet.)

Das stimmt. Das liegt daran, dass ich beide eine Adresse gegeben habe.
Ich weiß nur noch nicht wie ich das zum laufen bekomme.
Ob der "Master" mit Wire.onRequest(adresse); geht, weiß ich nur nicht.
Das ist der Grund warum beide eine Adresse haben.

> 2. Wo werden hier die Daten in den Puffer geschoben und wann wird die
> eigentliche Übertragung durchgeführt? Ich sehe da immer nur ein byte pro
> Aufruf der write Funktion.

Ich weiß von nichts. Muss ich das beachten? Geht das in der Arduino-IDE?

@ ufuf
>>M. S. schrieb:
>>Das wirft eine Erfolgsmeldung?

>Ja!
>Aber sie gesagt: Die ignorierst du gekonnt.

Oh.


Mfg
MarvS

Autor: Arduino Fanboy D. (ufuf)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
Blabla schrieb:
> 1. Darf ein Slave mit dem anderen Kommunizieren? (Vermutung da der
> zweite Teil des Codes fehlt. Aber es werden die Adressen 8 und 9
> verwendet.)

Nein, es kommuniziert immer nur der Master mit dem Slave.
Das hattest du schon richtig erkannt.

Aber Wire ist so gebaut, dass es als Slave auf Adresse 8 lauschen kann, 
und als Master mit dem Slave welcher mit der Adresse 9 lauscht, 
quatschen kann.
Das kommt sich nicht ins Gehege.

Blabla schrieb:
> 2. Wo werden hier die Daten in den Puffer geschoben und wann wird die
> eigentliche Übertragung durchgeführt? Ich sehe da immer nur ein byte pro
> Aufruf der write Funktion.

Wire.write() stopft in den Buffer!
Wire.endTransmission() sendet den Buffer.

Autor: Blabla (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
return = Wire.write(buffer)
Serial.print(return)

Ach... vielleicht tut es ja.

void setup() {
  Serial.begin(9600);
  Wire.begin();
}

void loop() {
  Serial.println("Anfang");
  Wire.beginTransmission(8);
  sarr(led[8][8]);    //Fehlgeschlagener Versuch,
  Serial.println("Ende");
  delay(1000);        //es dauerhaft zu versenden mit Zeitabstand.
  Wire.endTransmission(8);
}

void sarr(byte led[8][8]) {
  byte return;
  for (byte x=0; x<4; x++)
    {
        for (byte y=0; y<8; y++)
        {
            return = Wire.write(led[y][x]);
            Serial.print(return);
        }
        Serial.println();
    }


Was ist den mit den internen PullUp Widerständen?

Stefanus F. schrieb:
> Anstatt hier so unterschwellig einen auf Oberlehrer zu machen, könntest
> du einen Blick in den Quelltext (Wire.c) werfen, der ist ja alles andere
> als geheim.

Das ist mir bewusst, jedoch sollte vielleicht der der das Problem hat da 
rein schauen dem hilft es mehr.

Welchen Zweck erfüllt das senden erst mit dem endTransmission?
Was wäre denn die bessere Strategie den Puffer zu nutzen?

Arduino Fanboy D. schrieb:
> Wire.write() stopft in den Buffer!
> Wire.endTransmission() sendet den Buffer.

Dann ist die Arduino Dokumentation falsch. Doof.

Autor: Stefanus F. (stefanus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Blabla schrieb:
> Was wäre denn die bessere Strategie den Puffer zu nutzen?

AUf solche Feinheiten darf man bei Arduino nicht achten. Das ist ein 
Quick&Dirty Framework, das nur einfachen Ansprüchen genügt. Mehr als die 
32 Bytes gehen halt nicht.

Autor: Arduino Fanboy D. (ufuf)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
Blabla schrieb:
> Dann ist die Arduino Dokumentation falsch. Doof.

Nein ist sie nicht!

Siehe: https://www.arduino.cc/en/Reference/WireWrite
> Description
> Writes data from a slave device in response to a
> request from a master, or queues bytes for
> transmission from a master to slave device
> (in-between calls to beginTransmission() and endTransmission()).

Die Beschreibung ist korrekt!

: Bearbeitet durch User
Autor: Stefanus F. (stefanus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Es gibt Mikrocontroller, die nicht einzelne Bytes via I²C aneinander 
reihen können. So ist das z.B. beim STM32F103. Da muss man die letzten 
drei Bytes vor dem anders behandeln.

Es gibt vielleicht auch Mikrocontroller, wo das gesamte zu übertragende 
Paket an einem Stück vorliegen muss. Ich schätze, dass die Arduino 
Macher dabei Interrupt- oder DMA gesteuerte Übertragung als Möglichkeit 
offen lassen wollten.

Auf der einen Seite bemüht man sich bei Frameworks um Flexibilität, auf 
der anderen Seite muss man dazu woanders einschränken. Dieses Dilemma 
haben sehr viele Frameworks, weswegen ich sie kritisch betrachte. 
Frameworks bringen oft mehr Probleme als Nutzen.

: Bearbeitet durch User
Autor: Arduino Fanboy D. (ufuf)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
Blabla schrieb:
> Was ist den mit den internen PullUp Widerständen?
Die ca 50K sind nicht ausreichend.
Manche Arduino Boards haben zusätzliche 10K drauf,
Auch das muss nicht reichen.

Autor: Blabla (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
??? Zumindest sind sie unpräzise..
Wire.write(x);              // sends one byte
Wire.endTransmission();    // stop transmitting

Arduino Fanboy D. schrieb:
> Blabla schrieb:
>> Was ist den mit den internen PullUp Widerständen?
> Die ca 50K sind nicht ausreichend.
> Manche Arduino Boards haben zusätzliche 10K drauf,
> Auch das muss nicht reichen.

Reichen? Wofür? Was sind deine bzw. gute Kriterien dafür?


Stefanus F. schrieb:
> Das ist ein
> Quick&Dirty Framework, das nur einfachen Ansprüchen genügt.

Sehe ich auch so.

Evtl eher so...
#include <Wire.h>

byte led[8][8] = {    //Array mit dem "Bild" aus Einsen.(Es ist ein 
Smiley)
  {1,1,1,1,1,1,1,1},
  {0,0,0,0,0,0,0,0},
  {0,0,1,0,0,1,0,0},
  {0,0,0,0,0,0,0,0},
  {0,0,0,1,1,0,0,0},
  {0,1,0,0,0,0,1,0},
  {0,0,1,1,1,1,0,0},
  {1,1,1,1,1,1,1,1}
};

void setup() {
  Serial.begin(9600);
  Wire.begin();
}

void loop() {
  Serial.println("Anfang");
  sarr(led);
  Serial.println("Ende");
  delay(1000);

}

void sarr(byte led[8][8]) {
  byte ret;
  Wire.beginTransmission(8);

  for (byte x=0; x<4; x++)
    {
        for (byte y=0; y<8; y++)
        {
            ret = Wire.write(led[y][x]);
            Serial.print(ret);
        }
        Serial.println();
    }
    Wire.endTransmission(8);
    Wire.beginTransmission(8);
    for (byte x=4; x<8; x++)
    {
        for (byte y=0; y<8; y++)
        {
            ret = Wire.write(led[y][x]);
            Serial.print(ret);
        }
        Serial.println();
    }
    Wire.endTransmission(8);
}

Das mit den schleifen hintereinander ist wirklich nicht schön.

Autor: M. S. (marvs)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
Stefanus F. schrieb:
> Ich würde das Senden mit zwei verschachtelten Schleifen machen:
>
>
> void sendarr(byte led[8][8])
> {
>     for (byte x=0; x<8; x++)
>     {
>         for (byte y=0; y<8; y++)
>         {
>             byte b=led[y][x];
>             Serial.print(b);
>         }
>         Serial.println();
>     }
> }
> 

Ich habe den Code mal aufgespielt....

Das ist meine Ausgabe:

>01250818448184184
>017801841184184
>2551001961840184184
>2540016201840
>100121801841840
>0108018460
>0654305618470
>0080018470

... wie stelle ich das zu "0" u. "1" um?
Bin da jetzt etwas verwirrt. Wie kommt das zustande?
Die Variable "b" wird ja immer neu beschrieben, und es gibt nur
Zwei verschiedene Zahlen im Array... .


Mfg
MarvS

Autor: Arduino Fanboy D. (ufuf)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
Blabla schrieb:
> Reichen? Wofür? Was sind deine bzw. gute Kriterien dafür?
Tja...
Die I2C Spezifikation als Richtwert.
Und Erfahrung.
Oszibilder zeigen dir das auch.
Musst nur hinschauen.

Autor: M. S. (marvs)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
Hallo,

Blabla schrieb:

> Evtl eher so...
> #include <Wire.h>
>
> byte led[8][8] = {    //Array mit dem "Bild" aus Einsen.(Es ist ein
> Smiley)
>   {1,1,1,1,1,1,1,1},
>   {0,0,0,0,0,0,0,0},
>   {0,0,1,0,0,1,0,0},
>   {0,0,0,0,0,0,0,0},
>   {0,0,0,1,1,0,0,0},
>   {0,1,0,0,0,0,1,0},
>   {0,0,1,1,1,1,0,0},
>   {1,1,1,1,1,1,1,1}
> };
>
> void setup() {
>   Serial.begin(9600);
>   Wire.begin();
> }
>
> void loop() {
>   Serial.println("Anfang");
>   sarr(led);
>   Serial.println("Ende");
>   delay(1000);
>
> }
>
> void sarr(byte led[8][8]) {
>   byte ret;
>   Wire.beginTransmission(8);
>
>   for (byte x=0; x<4; x++)
>     {
>         for (byte y=0; y<8; y++)
>         {
>             ret = Wire.write(led[y][x]);
>             Serial.print(ret);
>         }
>         Serial.println();
>     }
>     Wire.endTransmission(8);
>     Wire.beginTransmission(8);
>     for (byte x=4; x<8; x++)
>     {
>         for (byte y=0; y<8; y++)
>         {
>             ret = Wire.write(led[y][x]);
>             Serial.print(ret);
>         }
>         Serial.println();
>     }
>     Wire.endTransmission(8);
> }
>
> Das mit den schleifen hintereinander ist wirklich nicht schön.

Ich habe das jetzt aufgespielt und bekomme nur Einsen.

Die Ausgabe:
...
Anfang
11111111
11111111
11111111
11111111
11111111
11111111
11111111
11111111
Ende
Anfang
11111111
11111111
11111111
11111111
11111111
11111111
11111111
11111111
Ende
...

Versteh ich langsam das Programmieren nicht mehr oder habe ich ein 
Fehler wieder gemacht?
Ich habe den Code 1:1 aus deinem Beitrag übernommen.

Mfg
MarvS

: Bearbeitet durch User
Autor: STK500-Besitzer (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
M. S. schrieb:
> Ich habe das jetzt aufgespielt und bekomme nur Einsen.

Ist ja auch richtig.
Das laesst dir ja den Rueckgabewert der Funktion ausgeben.
Entweder bedeutet die 1 wahr, oder die Anzahl der uebertragenen Bytes
Das kann man anhand der Arduino-Doku herausfinden

Autor: Blabla (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Arduino Fanboy D. schrieb:
> Tja...
> Die I2C Spezifikation als Richtwert.
> Und Erfahrung.
> Oszibilder zeigen dir das auch.
> Musst nur hinschauen.

Nee ich rechne, dann funktioniert es wie ich will.
Ach wenn es schon oft beantwortet wurde:
http://www.ti.com/lit/an/slva689/slva689.pdf

Egal..

M. S. schrieb:
> MarvS

Kannst du mal den ganzen Quellcode zeigen? Was übergibst du denn an die 
Funktion? Sieht mir aus als ob da was schief geht.


Nur Einsen ist super!
Es sind nicht die Daten an sich sondern die Anzahl an bytes die er je 
Aufruf von Wire.write in den Puffer geschrieben hat.

Das sollte interessanter werden:


void sarr(byte led[8][8]) {
  byte ret;
  Wire.beginTransmission(8);

  for (byte x=0; x<4; x++)
    {
        for (byte y=0; y<8; y++)
        {
            ret = Wire.write(led[y][x]);

        }
    }
    ret = Wire.endTransmission(8);
    Serial.println(ret);
    Wire.beginTransmission(8);
    for (byte x=4; x<8; x++)
    {
        for (byte y=0; y<8; y++)
        {
            ret = Wire.write(led[y][x]);
        }

    }
    ret = Wire.endTransmission(8);
    Serial.println(ret);
}

Autor: Arduino Fanboy D. (ufuf)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
Blabla schrieb:
> Nee ich rechne, .....
Nein, tust du offensichtlich nicht!
Denn dann hättest du die recht unintelligente Frage mit den internen 
Pullup nicht stellen müssen.

: Bearbeitet durch User
Autor: M. S. (marvs)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
Hallo,

@ Blabla

naja, er übergibt das Array mit seinem Inhalt.
Die Einsen und Nullen sind ja der Witz dran. Die müssen rüber.
Eine Zwei macht überhaupt keinen Sinn.
Es MÜSSEN die EINSEN und NULLEN rüber kommen einfach.


Hier die Code wo er später drunter soll:
#include <Wire.h>                     
                                      
volatile int sendarray[8][8];         
                                      
byte led[8][8] = {                    
  {1,1,1,1,1,1,1,1},                  
  {0,0,0,0,0,0,0,0},                  
  {0,0,1,0,0,1,0,0},                  
  {0,0,0,0,0,0,0,0},                  
  {0,0,0,1,1,0,0,0},                  
  {0,1,0,0,0,0,l,0},                  
  {0,0,1,1,1,1,0,0},                  
  {1,1,1,1,1,1,1,1}                   
};                                    
                                      
byte ledp=0;                         
byte ledm=8;                 
byte x=0;                             
byte y=0;                             
                                      
void setup() {                        
  pinMode(0, OUTPUT);                
  pinMode(1, OUTPUT);                 
  pinMode(2, OUTPUT);                 
  pinMode(3, OUTPUT);                 
  pinMode(4, OUTPUT);                 
  pinMode(5, OUTPUT);                 
  pinMode(6, OUTPUT);                 
  pinMode(7, OUTPUT);                 
  pinMode(8, OUTPUT);                 
  pinMode(9, OUTPUT);                 
  pinMode(10, OUTPUT);                
  pinMode(11, OUTPUT);                
  pinMode(12, OUTPUT);                
  pinMode(13, OUTPUT);                
  pinMode(14, OUTPUT);                
  pinMode(15, OUTPUT);                
                                      
  //Serial.begin(9600);               
                                      
  Wire.begin(8);                      
  Wire.onReceive(getarray);   //Hier soll es passieren.           
}                                     
                                      
void loop() {                         
  //for (byte i=0; i<=64; i++) {      
      if (led[y][x]==1) {             
        setled(ledp, ledm);           
        delay(1);                     
        noled(ledp, ledm);            
      }                               
                                      
      if (led[y][x]==0) {             
        noled(ledp, ledm);            
      }                               
                                        
      x++;                            
      ledp++;                         
                                      
      if (x==8) {                     
        x=0;                          
        y++;                          
        ledp=0;                       
        ledm++;                       
      }                               
                                      
      if (y==8) {                     
        x=0;                          
        y=0;                          
        ledp=0;                       
        ledm=8;                       
      }                               
    //}                               
                                      
    //Serial.print("ledp: ");         
    //Serial.println(ledp);           
                                      
    //Serial.print("ledm: ");         
    //Serial.println(ledm);           
    //Serial.print("x: ");            
    //Serial.println(x);              
    //Serial.print("y: ");            
    //Serial.println(y);              
    //delay(100);                     
                                      
}                                     
void setled(byte ledp, byte ledm) {   
  digitalWrite(ledp, HIGH);          
  digitalWrite(ledm, LOW);            
}                                       
void noled(byte ledp, byte ledm) {    
  digitalWrite(ledp, LOW);            
  digitalWrite(ledm, HIGH);           
}

void getarray(byte led[8][8]) {    //Hier die leere Funktion.
                                   //Das Sorgenkind das ich mein eigen
                                   //nennen darf.
}                              



Dies ist der Code wo das Array später rein soll.

Mir ist vollkommen bewusst das es andere Wege gibt. Ich habe diesen 
Gewählt. Der Code läuft einwandfrei und zeigt auch das was ich will.
Unter der Funktion "noled()" soll die Funktion "getarray()" kommen.

Aufgrund der Uhrzeit und der Tatsache das ich Schlafmangel habe:
Vielen Dank schonmal für diese Hilfe von diesen abend ....dieser 
Nacht??...
Danke.

Morgen werde ich weiter suchen und mir die "Wire.h" Lib. durchlesen. 
Genauer.

NAbnd.

Mfg
MarvS

Autor: Blabla (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Arduino Fanboy D. schrieb:
> Denn dann hättest du die recht unintelligente Frage mit den internen
> Pullup nicht stellen müssen.

Der war gut. Dann berechne mir doch bitte die Kapazität der Leitungen im 
verwendeten Aufbau, dann rechne ich dir den Widerstand aus ;-)

Auf welcher Seite des Datenblattes steht den der Wert des internen 
Pullup und lassen sie sich bei Verwendung der I2C Schnitstelle nutzen? 
Auch im Zusammenhang mit der verwendeten Bibliothek?

Spass bei Seite. Die frage wollte ich nicht ernsthaft beantwortet haben. 
Es geht mir eher darum Denkanstöße zu geben. Ich halte in der Regel 
recht wenig davon einfach fertige Lösungen hinzu pappen.


Hey MarvS,

für mich beginnt das Sorgenkind schon weiter oben aber das ist 
Geschmackssache.

Hier nochmal die Sendeseite zum Verständnis.
#include <Wire.h>

byte led[8][8] = {    //Array mit dem "Bild" aus Einsen.(Es ist ein Smiley)                
  {1,1,1,1,1,1,1,1},                  
  {0,0,0,0,0,0,0,0},                  
  {0,0,1,0,0,1,0,0},                  
  {0,0,0,0,0,0,0,0},                 
  {0,0,0,1,1,0,0,0},                 
  {0,1,0,0,0,0,1,0},                 
  {0,0,1,1,1,1,0,0},                  
  {1,1,1,1,1,1,1,1}                   
};  

void setup() {
  Serial.begin(9600);
  Wire.begin();
}

void loop() {
  Serial.println("Anfang");
  sarr(led);
  Serial.println("Ende");     
  delay(1000);    

}
//Prints the return values
/*  
 * Output   0 .. success
 *          1 .. length to long for buffer
 *          2 .. address send, NACK received
 *          3 .. data send, NACK received
 *          4 .. other twi error (lost bus arbitration, bus error, ..)
 */
void sarr(byte led[8][8]) {
  byte ret;
  Wire.beginTransmission(8);

  for (byte x=0; x<4; x++)
    {
        for (byte y=0; y<8; y++)
        {
            Wire.write(led[y][x]);
        }
    }
    ret = Wire.endTransmission(8);
    Serial.println(ret);
    Wire.beginTransmission(8);
    for (byte x=4; x<8; x++)
    {
        for (byte y=0; y<8; y++)
        {
            Wire.write(led[y][x]);
        }

    }
    ret = Wire.endTransmission(8);
    Serial.println(ret);
}

//Prints the actuall values
void sarrV(byte led[8][8]) {
  byte ret;
  Wire.beginTransmission(8);

  for (byte x=0; x<4; x++)
    {
        for (byte y=0; y<8; y++)
        {
            Wire.write(led[y][x]);
            Serial.print(led[y][x]);
        }
        Serial.println();
    }
    Wire.endTransmission(8);
    Wire.beginTransmission(8);
    for (byte x=4; x<8; x++)
    {
        for (byte y=0; y<8; y++)
        {
            Wire.write(led[y][x]);
            Serial.print(led[y][x]);
        }
        Serial.println();
    }
}

Ungetestet!
#include <Wire.h>

void setup() {
  Wire.begin(8);                // join i2c bus with address #8
  Wire.onReceive(receiveEvent); // register event
  Serial.begin(9600);           // start serial for output
}

void loop() {
  delay(100);
}

// function that executes whenever data is received from master
// this function is registered as an event, see setup()
void receiveEvent(int howMany) {
  while (Wire.available()) { // loop through all but the last
    char c = Wire.read(); // receive byte as a character
    Serial.print(c);         // print the character
  }
}

Jetzt müssen die Daten nur noch richtig einsortiert werde. Hoffentlich 
;-)

Autor: Stefanus F. (stefanus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
M. S. schrieb:
> Das ist meine Ausgabe:
>
>01250818448184184
>017801841184184
>2551001961840184184
>2540016201840
>100121801841840
>0108018460
>0654305618470
>0080018470
>
> Bin da jetzt etwas verwirrt. Wie kommt das zustande?

Ich auch.

Blabla schrieb:
> Kannst du mal den ganzen Quellcode zeigen? Was übergibst du denn an die
> Funktion? Sieht mir aus als ob da was schief geht.

Ja bitte, ohne den ganzen Quelltext kann ich mir auch auf dieses 
seltsame Ergebnis keinen Reim machen.

Autor: Arduino Fanboy D. (ufuf)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> ret = Wire.endTransmission(8);

KA, wer, aber hier hat wieder jemand die Doku nicht gelesen.

Denn Wire.endTransmission() erwartet keine Adresse als Parameter, 
sondern ein Flag, ob eine Stop Condition gesendet werden soll.
Default, ist true
Die 8 wird beim impliziten Cast zu true.

> ret = Wire.endTransmission(8);
ist also nicht unbedingt ein Fehler, aber dennoch irreführend/unsinnig.

Besser
> ret = Wire.endTransmission(true);

oder ausreichend:
> ret = Wire.endTransmission();


Hier könnte man beim ersten Datenblock  Wire.endTransmission(false) 
verwenden, damit einem kein zweiter Master dazwischen funken kann, und 
beim Zweiten dann Wire.endTransmission().

-------------


Dieses ist eine sehr problematische Idee:

Blabla schrieb:
> void receiveEvent(int howMany) {
>   while (Wire.available()) { // loop through all but the last
>     char c = Wire.read(); // receive byte as a character
>     Serial.print(c);         // print the character
>   }
> }

Hier besteht das Problem, dass receiveEvent() im ISR Kontext aufgerufen 
wird und Serial seinerseits Interrupts benötigt.
Das wird sich verklemmen, sobald der Tx Buffer voll ist,

: Bearbeitet durch User
Autor: M. S. (marvs)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
Stefanus F. schrieb:
> M. S. schrieb:
>> Das ist meine Ausgabe:
>>
>>01250818448184184
>>017801841184184
>>2551001961840184184
>>2540016201840
>>100121801841840
>>0108018460
>>0654305618470
>>0080018470
>>
>> Bin da jetzt etwas verwirrt. Wie kommt das zustande?
>
> Ich auch.

Das kam raus. Ich kann es nicht nachvollziehen im Code. Es sollte immer 
umgeschreiben werden, machen tut er was anderes.


> Blabla schrieb:
>> Kannst du mal den ganzen Quellcode zeigen? Was übergibst du denn an die
>> Funktion? Sieht mir aus als ob da was schief geht.
>
> Ja bitte, ohne den ganzen Quelltext kann ich mir auch auf dieses
> seltsame Ergebnis keinen Reim machen.

Den Quellcode für die Ansteuerung ist da und das komplett.
Der Quellcode für den Sender des Arrays.... naja.
Wenn der laufen würde, wäre er schon drin. Bis jetzt besteht die
"aufgeräumte" Variante nur darin, auf alle Sieben Taster ein Ton 
abzugeben
und zu zeigen im Monitor, welcher es war.

Mfg
MarvS

Autor: M. S. (marvs)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
Hallo,

Arduino Fanboy D. schrieb:
> Dieses ist eine sehr problematische Idee:
>
>> Blabla schrieb:
>> void receiveEvent(int howMany) {
>>   while (Wire.available()) { // loop through all but the last
>>     char c = Wire.read(); // receive byte as a character
>>     Serial.print(c);         // print the character
>>   }
>> }
>
> Hier besteht das Problem, dass receiveEvent() im ISR Kontext aufgerufen
> wird und Serial seinerseits Interrupts benötigt.
> Das wird sich verklemmen, sobald der Tx Buffer voll ist,

Im späteren Code ist sowieso kein Serial mehr drin. Deshalb mache ich 
mir da keinen Kopf drum.

Der "Slave" liest es und hält es, dass macht der solange, bis ein neues 
kommt.

Mfg
MarvS

Autor: M. S. (marvs)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
Hallo,

kann es sein, dass die Probleme teilwese von meinen Funktionen kommen,
weil diese "void" haben?

> https://www.arduino.cc/en/Reference/FunctionDeclaration

Ich meine, ich will ja was haben, also muss ich das auch deklarieren, 
oder?
Sowas wie "byte getarr(byte y, byte x) { }" gibt mir ja dann als byte 
etwas,
"void" hingegen gibt ja nichts.

Mfg

MarvS

: Bearbeitet durch User
Autor: Arduino Fanboy D. (ufuf)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
Ich glaube, bis jetzt weißt nur du, was dein getarr() tun soll.
Also: Keine Antwort von mir.


Ausführliche Fehlermeldungen(Alle) aktiviert?
Datei --> Einstellungen

: Bearbeitet durch User
Autor: M. S. (marvs)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
Hallo,

Arduino Fanboy D. schrieb:
> Ich glaube, bis jetzt weißt nur du, was dein getarr() tun soll.
> Also: Keine Antwort von mir.

Ja es soll wie der Name sagt, das Array entgegennehmen.
Das "sarr()" steht für sendArray. Es soll es versenden.


> Ausführliche Fehlermeldungen(Alle) aktiviert?
> Datei --> Einstellungen

Habe ich eingestellt.

Mfg
MarvS

Autor: Peter D. (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
M. S. schrieb:
> Ja es soll wie der Name sagt ...

Mach den letzten kompletten Stand in ein Zip und häng es an.
Sonst weiß niemand, wovon Du sprichst.

Autor: M. S. (marvs)
Datum:
Angehängte Dateien:

Bewertung
-1 lesenswert
nicht lesenswert
Hallo,

Peter D. schrieb:
> Mach den letzten kompletten Stand in ein Zip und häng es an.
> Sonst weiß niemand, wovon Du sprichst.

Der "Master" ist unfertig. bitte beachten.
Ansonsten hoffe ich das der Code vom "slave" verständlich ist. Ich habe 
den
mal komplett kommentiert.

Mfg
MarvS

Autor: M. S. (marvs)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
Hallo,

Stefanus F. schrieb:
> M. S. schrieb:
>> Auf die Widerstände habe ich verzichtet.
>
> Die sind aber notwendig.
>
> Ich teste I²C gerne mit niedrigen Bitraten und LED's. Dann sieht man sie
> flackern - oder auch nicht. Und man sieht an Dauerleuchten auch, wenn
> der Bus hängt.
>
>
> 
>             4,7k Pull-Up
> SDA o---+------[===]------+-----o 5V
>         |                 |
>         +---[===]---|<|---+
>             2,2k    LED
> 
>
> Und das gleiche nochmal für SCL.

Ich habe nun mir etwas zusammengelötet das diesem nun nachgeht.

Funktioniert top.

Mfg
MarvS

Autor: foobar (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Da die API anscheinend keine so großen Pakete verschicken kann, muß man 
entweder die Daten komprimieren oder bröckchenweise verschicken. Es 
bietet sich an, diese Zeilenweise zu übertragen.  Damit der Empfänger 
nicht durcheinanderkommt, wird als erstes Byte die Zeilennummer 
übertragen.

Hier mal Quick-n-Dirty runtergeschrieben:
#define L       8
#define C       8
uint8_t array[L][C];

void sendline(uint8_t l)
{
    Wire.beginTransmission(8);
    Wire.write(l);
    for (uint8_t i = 0; i < C; ++i)
        Wire.write(array[l][i]);
    Wire.endTransmission();
}

void sendarray()
{
    for (uint8_t i = 0; i < L; ++i)
        sendline(i);
}   

void onReceive(size_t n)
{   
    if (n == C+1)
    {   
        uint8_t l = Wire.read();
        if (l < L)
            for (uint8_t i = 0; i < C; ++i)
                array[l][i] = Wire.read();
    }
}

Autor: M. S. (marvs)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
Hallo,

foobar schrieb:
> Da die API anscheinend keine so großen Pakete verschicken kann, muß man
> entweder die Daten komprimieren oder bröckchenweise verschicken. Es
> bietet sich an, diese Zeilenweise zu übertragen.  Damit der Empfänger
> nicht durcheinanderkommt, wird als erstes Byte die Zeilennummer
> übertragen.
>
> Hier mal Quick-n-Dirty runtergeschrieben:
>
> #define L       8
> #define C       8
> uint8_t array[L][C];
> 
> void sendline(uint8_t l)
> {
>     Wire.beginTransmission(8);
>     Wire.write(l);
>     for (uint8_t i = 0; i < C; ++i)
>         Wire.write(array[l][i]);
>     Wire.endTransmission();
> }
> 
> void sendarray()
> {
>     for (uint8_t i = 0; i < L; ++i)
>         sendline(i);
> }
> 
> void onReceive(size_t n)
> {
>     if (n == C+1)
>     {
>         uint8_t l = Wire.read();
>         if (l < L)
>             for (uint8_t i = 0; i < C; ++i)
>                 array[l][i] = Wire.read();
>     }
> }
> 

Bei dem Code habe ich ein paar Fragen:
Du verwendest diesen ...byte...(unitn8_t) in verbindung von 
"array{L][C]".
Was passiert damit?

(Ich habe unint8_t noch nie verwnedet und weiss daher nur minimal 
bescheit darüber.)

Lässt sich der Inhalt leicht verändern?

Und wieso "L" und "C" definieren?


Mfg
MarvS

Autor: Stefanus F. (stefanus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
uint8_t = byte = unsigned char

uint8_t ist die offizielle Schreibweise seit einer gefühlten Ewigkeit.

byte ist ein Alias von Arduino - die finden das wohl genau so hilfreich, 
wie ihr eigenes Vokabular.

Autor: foobar (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
uint8_t ist die Ansi-Version eines Bytes - kannst du auch gerne was 
anderes nehmen. Die Konstanten L und C sind einfach die Anzahl Zeilen 
(Lines) und Spalten (Columns) deines Arrays - es ist üblich, solche 
Konstanten einmal im Programm zu definieren.

Autor: M. S. (marvs)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
Hallo,

Stefanus F. schrieb:
> uint8_t = byte = unsigned char
>
> uint8_t ist die offizielle Schreibweise seit einer gefühlten Ewigkeit.
>
> byte ist ein Alias von Arduino - die finden das wohl genau so hilfreich,
> wie ihr eigenes Vokabular.

Wenn es die von Arduino lustig macht.... dadann.

Mfg
MarvS

Autor: M. S. (marvs)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
Hallo,

foobar schrieb:
> uint8_t ist die Ansi-Version eines Bytes - kannst du auch gerne was
> anderes nehmen. Die Konstanten L und C sind einfach die Anzahl Zeilen
> (Lines) und Spalten (Columns) deines Arrays - es ist üblich, solche
> Konstanten einmal im Programm zu definieren.

Kann man damit dann auch das Programm kleiner machen?
Ansonsten habe ich bis heute keine Anwendung dafür gehabt.

Mfg
MarvS

Autor: Stefanus F. (stefanus)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
M. S. schrieb:
> Kann man damit dann auch das Programm kleiner machen?

Bytes sind kleiner als int und #defines sind Textersetzungen, die vor 
dem Compilieren angewendet werden. Diese werden beim Compilieren teil 
des Programmcodes (Flash-Speicher).

Im Gegensatz dazu liegen konstante Variablen wie:

const byte x=123;

bei AVR Controllern im RAM.

Autor: pop (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
M. S. schrieb:
> Kann man damit dann auch das Programm kleiner machen?

Bitte korrigiert mich, aber rechnet Arduino nicht standardmäßig mit 
int16_t ?

Auf einem 8bit MCU wie dem AVR macht es aus Effizienzgründen sinn wo es 
möglich ist mit 8Bit langen zahlen zu rechnen. Außerdem spart das Ram.


Elektro Heini schrieb:
> byte led[8] = {
>   0b11111111,
>   0b00000000,
>   0b00100100,
>   0b00000000,
>   0b00011000,
>   0b01000010,
>   0b00111100,
>   0b11111111
> };

Da du ein 8x8 array aus Nullen und Einsen übertragen möchtest, ist dies 
die effizienteste möglichkeit, die sowohl Ram als auch Übertragungszeit 
spart! solltest du auf das Arduino Framework an dieser Stelle 
verzichten, könntest du so auch die empfangenen Werte direkt auf einen 
(freien) Port legen.

Autor: Arduino Fanboy D. (ufuf)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
Stefanus F. schrieb:
> Im Gegensatz dazu liegen konstante Variablen wie:
>
> const byte x=123;
>
> bei AVR Controllern im RAM.

Nöö...
Eher selten.
Nur, wenn es mit der Optimierung gar nicht klappen will, weil z.B. in 
einer anderen Übersetzungseinheit definiert (und als extern deklariert).

: Bearbeitet durch User
Autor: Stefanus F. (stefanus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
pop schrieb:
> Bitte korrigiert mich, aber rechnet Arduino nicht standardmäßig mit
> int16_t ?

Ich formuliere es mal so: Der Datentyp int ist 16 bit gross. Ob du den 
standardmässig verwendest, bleibt Dir überlassen.

Autor: Stefanus F. (stefanus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Stefanus F. schrieb:
> Im Gegensatz dazu liegen konstante Variablen wie:
>
> const byte x=123;
>
> bei AVR Controllern im RAM.

Arduino Fanboy D. schrieb:
> Nur, wenn es mit der Optimierung gar nicht klappen will, weil z.B. in
> einer anderen Übersetzungseinheit definiert (und als extern deklariert).

Ich habe es gerade ausprobiert - scheinbar hast du Recht. Es wird sogar 
bei Zeichenketten gut optimiert. Beide Varianten belegen laut Compiler 
Ausgabe gleich viel RAM:
void setup() {}

//const char s[]="Hallo";
#define s "Hallo"

void loop() {
  Serial.println(s);
}

Beide Verianten lassen 1854 Bytes RAM übrig.

Jetzt wird es komisch:
void setup() {}

char s[]="Hallo";

void loop() {
  s[0]=0;
  Serial.println(s);
}

Auch dieser Programm lässt 1854 Bytes übrig, das kann aber nicht stimmen 
oder?

Ich habe es so in Erinnerung, das einem besonders bei String Literalen 
schnell das RAM ausgeht. Dazu gibt es diese Anleitung: 
https://playground.arduino.cc/learning/memory

Warum empfehlen die dort PROGMEM und F() obwohl const einfacher ist?

Auch hier schreiben mehrere Leute, dass Konstante Strings im RAM liegen: 
https://forum.arduino.cc/index.php?topic=79436.0

Jetzt bin ich verwirrt.

: Bearbeitet durch User
Autor: Arduino Fanboy D. (ufuf)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
Stefanus F. schrieb:
> Warum empfehlen die dort PROGMEM und F() obwohl const einfacher ist?

Bei Strings klappt das nicht so gut.
Darum F() usw.

Stefanus F. schrieb:
> Beide Varianten belegen laut Compiler
> Ausgabe gleich viel RAM:
Das wundert mich nicht!
void setup() {}

//const char s[]="Hallo";
#define s "Hallo"

void loop() {
  Serial.println(F(s)); // braucht weniger Ram
}

: Bearbeitet durch User
Autor: Stefanus F. (stefanus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ach so, das passt hierzu:
void setup() {}

//char s[]="Halloxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx";

//const char s[]="Halloxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx";

//#define s "Halloxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"

const char PROGMEM s[]="Halloxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx";
  
void loop() {
  Serial.println(s);
}

Alle auskommentierten Varianten belegen deutlich viel RAM. Nur die 
letzte Variante spart Speicher.

Werden denn nur Zeichenketten ins RAM kopiert, einfache numerische 
Variablen aber nicht?

: Bearbeitet durch User
Autor: Arduino Fanboy D. (ufuf)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Stefanus F. schrieb:
> Werden denn nur Zeichenketten ins RAM kopiert,

Zeichenketten werden über Pointer manipuliert.
Dazu müssen die Ketten im Ram liegen.
Alles andere wäre ineffektiv bis unmöglich.


Stefanus F. schrieb:
> einfache numerische Variablen aber nicht?

Wenn sie als konstant deklariert sind, kann der Kompiler sie direkt in 
die ASM Statements einflechten. So landen sie um Code, im Flash.
Darum brauchen sie keine Repräsentation im Ram.
Sobald du einen Pointer darauf richtest, ist Schluss damit.

Autor: leo (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
M. S. schrieb:
> Kann man damit dann auch das Programm kleiner machen?

Du gehst das vollkommen verkehrt an, Stichwort "premature optimization". 
Hier snd die bestehenden Probleme (Stand dein rar-Archiv):

1) Generell:
- du zeigst kein Konzept/Skizze/Schaltplan
- du sprichst von "stark beschäftigt". Ich sehe in deinem Code 
keinerweise irgendeine Auslastung von CPU(s). Ev. sprichst du von einem 
Mangel an IO-Pins. Da scheint der Einsatz von Multiplexern einfacher zu 
sein, als ein Master/Slave I2C Einsatz.

2) Master:
- Verwende 8 x Bytes statt 64 x Bits, die du aufteilen musst um diese 
per TWI/I2C zu verarbeiten.
- Deine Schleifen sind immer noch Off-by-one.
- du kannst nicht 64/81 Byte am Stueck per I2c mit der Wire-Lib 
verarbeiten.

3) Slave:
- kompiliert nicht einmal - der onReceive()-Handler ist falsch 
deklariert, usw.
- die 2 Arrays sind zumindest tw. ueberfluessig
- deine pinModes gehoeren in eine Schleife
- der Anzeigecode ist unverstaendlich - delay(1) dort sicher falsch

Die meisten Tipps wurden dir schon gesagt.
wenn obiges mal geloest ist, kannst du Optimierungen angehen, falls 
noetig.

HTH, leo

Autor: Stefanus F. (stefanus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Arduino Fanboy D. schrieb:
> Sobald du einen Pointer darauf richtest, ist Schluss damit.

Danke für deine Erklärung.

Autor: mIstA (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Arduino Fanboy D. schrieb:
> Sobald du einen Pointer darauf richtest, ist Schluss damit.

Bist Du sicher, daß schon das darauf richten eines Pointers damit 
definitiv Schluß macht?

Denn wenn der Pointer nie dereferenziert wird, könnte der Compiler ihn 
schließlich auch kurz und schmerzlos wegoptimieren.

Autor: Stefanus F. (stefanus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
mIstA schrieb:
> Bist Du sicher, daß schon das darauf richten eines Pointers damit
> definitiv Schluß macht?
>
> Denn wenn der Pointer nie dereferenziert wird, könnte der Compiler ihn
> schließlich auch kurz und schmerzlos wegoptimieren.

Ich denke dass er nur Pointer meint, die tatsächlich verwendet werden.

Autor: Peter D. (peda)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
Ich verstehe immer noch nicht, warum man unbedingt 64 Byte senden muß 
für real 8 Byte Daten. Das mach doch alles nur unnötig kompliziert.

Autor: Dirk B. (dirkb2)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Peter D. schrieb:
> Das mach doch alles nur unnötig kompliziert.

Naja, man muss hinterher die Bits wieder auseinander dröseln.
Das ist füe einige auch nicht einfach.

Zudem ist es doch auch gut, das Sendeproblem mit den 64 Byte zu lösen.
Kann man später auch noch gebrauchen.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.