Ist das 1,3 Zoll OLED-Display für mein Projekt nicht geeignet!?!

Letzer Versuch!

Schreibe den Code in den Empfänger.
Wenn der Code nicht kompiliert, bitte selbst suchen wo es klemmt.
Lasse den Code durchlaufen
Zeige mir die letzten 20 Ausgaben auf dem seriellen Monitor.

// UNGETESTET - nur frei Schnauze Ich will die Laufzeit der Displayroutine ermitteln
#include <Arduino.h>
#include <U8x8lib.h>
#include <Wire.h>
U8X8_SSD1306_128X64_NONAME_HW_I2C u8x8 (U8X8_PIN_NONE);

const unsigned int Anzahl = 100;
unsigned long Werte[Anzahl];
void setup()
{
Serial.begin(115200); // der muss natürlich rein, sonst siehst Du nichts
  u8x8.begin();
  u8x8.setFont (u8x8_font_chroma48medium8_r);
}

void loop()
{
  for (int i; i < Anzahl-1; i++)
  {
    u8x8.setCursor (0, 0); //(X-Achse, Y-Achse)
    u8x8.print (i);
    Werte[i] = millis();
  }
  for (int i; i < Anzahl-1; i++)
  {
    if (i > 0)
    {
      Serial.print ("Laufzeit war: ");
      Serial.println (Werte[i] - Werte[i - 1]);
    }
  }
  while (1); // Hier hört alles auf und bleibt der Sketch stehen....
}

Irgendwie finde ich das alles etwas absurd.

Wir reden doch über 200Hz, oder?
Was kann das Auge? 25Hz?

Macht es also Sinn, mehr als 25 mal pro Sekunde die Anzeige zu wechseln?
Ich sage: Eher nicht!
Gegenargumente?

Bedenke:
1 bis 2 Zahlen/Bilder kann man pro Sekunde lesend/verstehend wahrnehmen.
(schätzung)

Bei den zu messenden Impulse, scheint einzig die Anzahl wichtig zu sein.
Ist dem so?

Dann kann man doch (einfach?) einen der Timer/Conter die Pulse völlig asynchron zum Hauptprogramm zählen lassen. Alles ohne jede Rechenlast, einzig der Counter Überlauf will abgehandelt werden.
Schließlich hat der Hersteller, den Counter, ja nicht zum Spaß in den UNO eingebaut.

Und die Anzeige so verlangsamen, dass man was erkennen kann.

combie:
Irgendwie finde ich das alles etwas absurd.

Wir reden doch über 200Hz, oder?
Was kann das Auge? 25Hz?

absurd? ja
die 200Hz sind das entscheidende Kriterium - aber nicht hier.
Das Auge kann schon einiges - die Frage ist nur ob Wiederholrate oder Frames.
Den Fehler macht der TO:

sebastianhamburg2020:
Was mich aber verwundert ist, dass das OLED-Display eine Refresh-Rate von 200 Hz haben soll. Laut Datenblatt soll das OLED-Display einen 400 KHz schnellen I2C-Bus haben…

1 bis 2 Zahlen/Bilder kann man pro Sekunde lesend/verstehend wahrnehmen.
(schätzung)
[...]
Und die Anzeige so verlangsamen, dass man was erkennen kann.

Kommt wohl drauf an. Ein 16x2 LCD ohne Beleuchtung wird vermutlich anders lesbar sein, als ein ebensolches LED.
Ein Selbstversuch: ein ganzes LED 16x2 Display löschen und mit Zufallswerten füllen. Nach einer Sekunde löschen.
Inhalt mit einem Stift auf Papier aufschreiben.

Der Mensch hat eine Erwartungshaltung - Je nach Erfüllung, ist das Ergebnis anders. :wink:

Der Mensch hat eine Erwartungshaltung - Je nach Erfüllung, ist das Ergebnis anders. :wink:

Meinst du?

Dann lautet meine/die Antwort auf die Frage:

Ist das 1,3 Zoll OLED-Display für mein Projekt nicht geeignet!?!
Falsche Frage!
Dein Vorgehen ist nicht geeignet.

combie:
Dein Vorgehen ist nicht geeignet.

Könnte es sein, daß Du den Themensteller sebastianhamburg2020 und den Helfer my_xy_projekt verwechselst?

combie:

Ist das 1,3 Zoll OLED-Display für mein Projekt nicht geeignet!?!
Falsche Frage!
Dein Vorgehen ist nicht geeignet.

Das wird er erst merken, wenn er die Zeit der Übertragung kennt... Und damit den Unterschied zwischen Übertragungsfrequenz und Nutzdatenrate.

@TO: Ergebnis aus Ist das 1,3 Zoll OLED-Display für mein Projekt nicht geeignet!?! - #21 by my_xy_projekt - Deutsch - Arduino Forum ?

agmue:
Könnte es sein, daß Du den Themensteller sebastianhamburg2020 und den Helfer my_xy_projekt verwechselst?

Nein.
Passt schon.
Das einleitende > war der Hinweis, das die Frage nicht von mir kam :wink:
Trotzdem - oder gearde dafür, das noch mitgelesen wird - Danke

agmue:
Könnte es sein, daß Du den Themensteller sebastianhamburg2020 und den Helfer my_xy_projekt verwechselst?

Nöö.

my_xy_projekt:
Nein....

combie:
Nöö.

Ihr seit mal (ausnahmsweise) gleiche Meinung?? :wink: :wink: :wink:
Grüße Uwe

Ist nur ein Versehen.
(kommt nicht wieder vor)
:smiling_imp: :smiling_imp: :smiling_imp: :smiling_imp: :smiling_imp:

uwefed:
Ihr seit mal (ausnahmsweise) gleiche Meinung?? :wink: :wink: :wink:

Dann bin ich wohl das schwarze Schaf aus "Ein schwarzes Schaf, zur rechten Zeit, erspart den Streit, bringt Einigkeit." Jeder ist zu was nütze ::slight_smile:

my_xy_projekt:
Das einleitende > war der Hinweis, das die Frage nicht von mir kam :wink:

Danke für die Aufklärung!

Zurück zum Thema:

sebastianhamburg2020:
... auf einem 1.3 Zoll OLED-Display ...

Du verwendest U8X8_SSD1306_128X64_NONAME_HW_I2C, mein 1,3" OLED verwendet SH1106. Bist Du sicher, der Controller ist richtig angegeben?

sebastianhamburg2020:
Programm-Code: Empfangs-DUE mit dem die Impulse gezählt und das OLED angesteuert wird, mit der Funktion digitalRead()

Danke!

Wie wäre es hiermit?

// Controller SH1106!

#include <Arduino.h>
#include <U8x8lib.h>
#include <Wire.h>
//U8X8_SSD1306_128X64_NONAME_HW_I2C u8x8(U8X8_PIN_NONE);
U8X8_SH1106_128X64_NONAME_HW_I2C u8x8(/* reset=*/ U8X8_PIN_NONE);

// INTERRUPT
const byte PIN13          = 13;   // Setze den Pin für die LED auf 13
const byte INTERRUPT_PIN2 =  2;   // PIN2 für UNO, MEGA - hier Input von DUE-Impuls
volatile unsigned int   i = 0;


// Voreinstellung
void setup() {
  pinMode(PIN13,                OUTPUT);  // Lege den Pin für die LED als Outputpin fest
  pinMode(INTERRUPT_PIN2, INPUT_PULLUP);  // Lege den Interruptpin als Inputpin mit Pullupwiderstand fest

  // OLED
  u8x8.begin();
  u8x8.setFont(u8x8_font_chroma48medium8_r);

  // INTERRUPT-SERVICE-METHODE
  // Interrupt-Pin = 2, Funktion _toggel aufrufen, Funktion aufrufen, bei Flankenwechsel (LOW->HIGH u- HIGH->LOW)
  attachInterrupt(digitalPinToInterrupt(INTERRUPT_PIN2), _toggel, CHANGE);
}


// Hauptprogramm
void loop() {
  // OLED-Impulszählung-Ausgabe
  u8x8.setCursor(0, 0); //(X-Achse, Y-Achse)
  u8x8.print(i);
  delay(200);  // Simulation weiterer Aktivitäten
}


// ISR-Methode
void _toggel() {
  // Pin toggeln
  digitalWrite(PIN13, digitalRead(INTERRUPT_PIN2));
  i++;
}

Dann bin ich wohl das schwarze Schaf aus "Ein schwarzes Schaf, zur rechten Zeit, erspart den Streit, bringt Einigkeit." Jeder ist zu was nütze ::slight_smile:

Eine Ausnahmesituation....
Ja.

Moin,

huuuuuuiiiiiiiiii. Ich komme bei euren Anregungen und Überlegungen gar nicht mehr hinterher.

VIELN, VIELEN DANK AN DER STELLE, dass ihr euch so viel Mühe macht und eure wertvolle Zeit für mich opfert.

Ich glaube ich habe das Problem gefunden!
Vielleicht habt ihr gesehen, dass ich softwaretechnisch beim "Empfangs-Board" den digitalen Pin dazu benutzen, um mir für den CH2 ein Impuls ausgeben zu lassen. Das nutze ich ja dazu, um eine Testmöglichkeit zu haben. Also zur Überprüfung.

Ich glaube, bez. gehe sogar davon aus, das da mein Problem liegt!
Das was mir CH2 zeigt, entspricht nicht wirklich dem, was auf der Mikrocontroller-Ebene genau abläuft. Das würde bedeuten, dass der Mikrocontroller alles richtig macht. Sprich, dass die Hardware alle Impulse richtig verarbeitet und mir mein Oszi aber anzeigt, das der Mikrocontroller das aber gar nicht tun würde. Und das ist darauf zurück zu führen, dass ich den Pin benutze und die Ausgabe auf dem Oszi damit gleich setzte.

Das ist NATÜRLICH auf meine Programmierung zurück zu führen!

Ich gehe ganz fest davon aus, das mein Programm mit Interrupts richtig arbeitet und ich das nicht richtig sehe, da das gar nicht möglich ist, wenn ich so programmiere!

Um dem auf die Spur zu kommen, werde ich einfach eine gewisse Anzahl (100, 1.000, 10.000) von Impulsen bei dem einem Board erzeugen und mit dem anderen Board auswerten und gucken wie viele gezählt wurden. Zusätzlich hab ich mir noch überlegt nen Timer auf beiden Seiten nutzen zu wollen, um auch die Zeiten miteinander vergleichen zu können.

Eine weiter Überlegung von mir es innerhalb der ISR den CH2-Pin zu toggeln. Ab aber ob das so klug ist, da bin ich mir noch nicht ganz sicher. Bezüglich der ISR habe ich gelernt, dass man da nach Mögichkeit keine zusätzlichen Funktionen wie Printf ect. ausführen soll. Aber das Vorhaben soll mir nur dazu dienen mir an zu zeigen, das sich da was tut. Zusätzlich würde das aber auch zu zusätzlichen Verzögerungszeiten führen. Na mal schaun. Ich werde damit einfach mal rumspielen.

Noch mal vielen Dank an euch alle für eure viele Unterstützung.

Herzliche Grüße
Sebastian

@agmue
Das wäre natürlich auch eine Möglichkeit!

@my_xy_projekt
Welchen Pin meinst du den, den ich mit einem Widerstand auf GND ziehen soll? Und was würde das bringe, bez. wozu ist das nützlich?

CHANGE hab ich benutz, da mir dann ein Rechteck dargestellt wird. Jedenfalls habe ich das so in Erinnerung. Könnte mich aber auch irren. Ich werde das aber auf nur die steigende Flanke ändern. Ob das jetzt ein Unterschied machen würde weiß ich nicht. Wenn ich es richtig verstanden habe, dann wird die die Funktion der ISR nur ausgeführt, wenn dann eine steigende und fallende Flanke erkannt wird. Auf dem Oszi konnte ich keinen Unterschied zwischen den Impulsen vernehmen und deshalb habe ich das so gelassen.

An die Idee die Funktion millis() einzusetzten, um so Zeiten ableiten zu können, habe ich auch schon gedacht. Hab ich aber so nicht umgesetzt, da ich davon ausgegangen bin und ausgehe, dass millis() bei Start der Mikrocontroller anfängt zu zählen und mir das so zu kompliziert erschien, um da Zeiten abeiten zu können.

@uwefed
Ich habe ein DUE eingestezt, um den Impuls zu erzeugen und zu senden. Und zu Begin habe ich noch ein UNO eingestezt, um den Impuls zu empfangen und zu verarbeiten. Dann habe ich den UNO gegen ein MEGA ersetzt. Und zu guter letzt den MEGA degen ein weiteren DUE ausgetauscht. Momentan läuft mein Projekt mit 2 DUE. Das habe ich aus dem Grund getan, um so ausschließen zu können, dass eine höhe Taktrate zur Lösung beitragen könnte. Aber erhlich gesagt bin ich davon ausgegangen, dass der UNO mit 16 MHz absolut ausreichen würde vom Takt her.

MAX7219 würde leider nicht in Frage kommen, da nach Möglichkeit noch weitere Funktionalitäten dazu kommen sollen.

@combie
Ja, da gebe ich dir recht, dass das Ganze etwas absurt erscheint. Es ist so, dass es bei dem Projekt darum geht, dass eine Rolle eine genau Anzahl von Umdrehung tätigen soll. Und wenn ich nicht davon ausgehen kann, dass die Impuls richt verarbeitet und somit eine richtige Zählung stattfindet, dann hätte ich ein Problem.

Desweitern hatte ich das Problem, dass ich das Display nur alle 1/4 Sekunde refreshen wollte, dann aber die Zählung nicht exakt dargestellt wurde. Die Zählung sprung und das jedes Mal um einige 100ter bis 1.000der Stellen. Wo da jetzt das Problem lag, kann ich nicht genau sagen. Als das geschah, hab ich mich erstmal nicht weiter mit dem Problem befasst.

combie

Wie schon gesagt....
Warum in Software zählen, mit problematischen Interrupts, usw. wenn man es doch einer 100% zuverlässigen Hardware überlassen kann?

@combie
Der Impuls wird durch ein Hall-Sensor an den/bez vom MCU ausgelesen. Dazu kommt, dass sich die Fequenz ändern kann. Die 200 Hz sind quasi die max Frequenz, die auftretten kann. Deshalb würde ich Interrupts für am sinvollsten halten.

Ich weiss über Timer, das dies sich nicht direkt auf dem Prozessor befinden sollen. Oder jedenfalls seperat für sich laufen und daher sehr genau sind und nicht die CPU benötigen und dadurch nicht an ihrem Zählvorgang gestört werden können. Ich glaub das hab ich so mal in der Vorlesung vernommen.

Moin,

ich hab da mal getestet. :slight_smile:

Ich habe also 3 Boards eingesetzt. 1 DUE-Board als Impulsgeber, 1 DUE-Board als Impulsempfänger, und noch ein weiteres UNO-Board als Impulsempfänger.

Test 1: 1x DUE als Impulssende-Board, 1x DUE als Empfängerboard
Ich habe drei mal hintereinander 10.000 Impulse zählen lassen.
Durchgang 1: 1x Zählung auf dem Display ausgeben - 10.000 wurden gesendet, 10.000 wurden empfangen, Zählung hat 50 Sekunden gedauert
Durchgang 2: 2x Zählung auf dem Display ausgeben - 10.000 wurden gesendet, 10.000 wurden empfangen, Zählung hat 50 Sekunden gedauert
Durchgang 1: 3x Zählung auf dem Display ausgeben - 10.000 wurden gesendet, 10.000 wurden empfangen, Zählung hat 50 Sekunden gedauert

Test 2: 1x DUE als Impulssende-Board, 1x DUE und 1x UNO als Empfängerboard - diese laufen parallel zueinander

Ich habe drei mal hintereinander 10.000 zählen lassen.
Durchgang 1: 1x Zählung auf DUE Display ausgeben, parallel dazu 1x Zählung auf UNO Display ausgeben - 10.000 wurden gesendet, 10.000 wurden empfangen, Zählung hat 50 Sekunden gedauert
Durchgang 1: 1x Zählung auf DUE Display ausgeben, parallel dazu 2x Zählung auf UNO Display ausgeben - 10.000 wurden gesendet, 10.000 wurden empfangen, Zählung hat 50 Sekunden gedauert
Durchgang 1: 1x Zählung auf DUE Display ausgeben, parallel dazu 3x Zählung auf UNO Display ausgeben - 10.000 wurden gesendet, 10.000 wurden empfangen, Zählung hat 50 Sekunden gedauert

Es hat sich ergeben:

  1. Impulse wurden immer korrekt gezählt
  2. Zählung hat immer gleiche lange gedauert
  3. Zähldauer entspricht der theoretischen Zeit (50mS pro Impuls x 10.000 = 50 Sek)
  4. Parallele Zählung und einsatz unterschiedlicher Boards ergab keinen Unterschied

Es hat sich also das bewarheitet, was ich zuvor angenomen habe. Der Impuls wurde mir nicht entsprechend der Zählung dargestellt. Die Verzerrung, die ich auf dem Oszi gesehen habe, ist wohl da, nimmt aber keinen Einfluss auf die Zählung und die Ausgabe auf dem Display!

Meine Vermutung wäre da an der Stelle, das die Verzerrung vielleicht dadurch zu sehen ist, da es sich bei dem Oszi nicht um ein super teures Modell handelt.

Mit den Erkenntnissen werde ich mich weiter meinem Projekt widmen. Mal schaun, was noch auf mich wartet. :wink:

Herzliche Grüße
Sebastian

Danke für die ausführliche Beschreibung und Rückmeldung - ach wäre das doch immer so ::slight_smile:

Mein Bauchgefühl sagt mir, Du machst noch irgendwo einen gedanklichen Fehler, ohne den Finger "in die Wunde" legen zu können. Möglicherweise habe ich aber auch nur Hunger :grin:

Ich wünsche Dir weiter Erfolg und Freude mit Deinem Projekt.