Mehrere INOs, oder wie bekomme ich ein float 'global'?

International Deutsch
1

Ich habe mein Projekt in mehrere inos aufteilen. "Der Übersicht halber" haben Sie gesagt.
Jetzt habe ich eine ADS1115.ino , die mir schon einmal, über eine .h ein wenig modifiziert, einen Wert ausspuckt, wenn sie ganz alleine kompiliert wird.

float calibResult = getCalibResult();
  Serial.print("von ADS1115: ");
  Serial.println(calibResult);

Wie bekomme ich jetzt das (calibResult) auch für eine, daneben liegende, nextion.ino verfügbar?
Muss ich über die Projekt.ino gehen?
Die guten Programmierer:Innen rümpfen die Nase, wenn man einen float 'global' macht.
Habe ich gelesen, aber selbst das gelingt mir nicht!
Ich finde auch keine Beispiel dafür. Vielleicht fehlen mir auch nur die Triggerworte, um Tante Google...
Vielleicht erbarmt sich einer mir?

Hier noch die class_f.h, falls sich einer meine Modifizierung ansehen möchte,
vielleicht ist die auch schon völlig überflüssig.

class_f.h (764 Bytes)
consts.h (2,0 KB)

2

Hallo,

wenn du bspw. die consts.h in den Sketch inkludierst, ist alles darin sowieso global verfügbar. Ohne Kontext ist alles Gehörte meistens Sinnfrei. Vieles macht nur unter bestimmten Umständen Sinn.

Mit "calibResult" meinst du sicherlich die Elementfunktion read() der Klasse ADS1115Reader womit calibResult an den Aufrufer zurückgegeben wird? Dann musst du von der Klasse eine Instanz/Objekt erstellen bzw. hast das ggf. schon. Dann nimmste den Punkt Operator und hast Zugriff auf alles was public deklariert wurde.
Bsp.

ADS1115Reader meineInstanz;
meineInstanz.read();

bzw.

Serial.println(meineInstanz.read() );

Wenn faktor konstant ist kannste das gleich konstant initialisieren oder im Konstruktor sauber schreiben.

private:
    const float factor {1.0};
  public:
    ADS1115Reader()    // Default Konstruktor
    { }

private:
    const float factor;
  public:
    ADS1115Reader() :  
   // Initialisierungsliste
   factor {1.0}
    { }

noch besser wäre man lässt den Default Konstruktor automatisch erstellen, schreibt es aber für Nachwelt sichtbar hin.

class ADS1115Reader {
  private:
    const float factor {1.0};
    
  public:
    ADS1115Reader() = default;
        
    float read() {
      int calibResult {0};
      return calibResult;
    }
};
1 Like
3

Im projekt.ino (so das der Ausgangspunkt ist) vor dem setup ()

float calibResult;

In deiner ADS1115.ino nimmst Du das float weg, sonst wird da eine neue Variable erstellt.
Das füllt calibResult und das steht Dir dann überall "global" zur Verfügung.

Ansonsten heisst es: die Header-Dateien in den Projektsketch und dann stehen Dir auch die Funktionen in allen tabs zur Verfügung und Du kannst die jederzeit aufrufen.

4

Wahre Worte! Und Danke für den Code!!
Ich wollte mich drücken, aber es sind wohl doch 'Studien zur Syntax und Semantik' angesagt. :smiling_face:
Bei der consts.h habe ich mir gedacht: schreib erst einmal alles rein, was Du so in Fritzing da randetüddelt hast.
Hier hast du mal ein Bild um ein wenig Kontext herzustellen:
Ich habe die Wahnsinnige Idee eine Frontladerwaage selbst zu bauen! :crazy_face:

Fritzing
Fritzing858×645 75.2 KB

5

Zeichne mall ein Schaltplan, wen das Teil mit der Antenne ein nRF24 ist, ist er total falsch verdrahtet er nutzt doch SPI . Benenne wenigstens die teile was drauf sind :wink:

6

Ist ein ESP-01

7

OK Danke

8

Ich hab's mal ein wenig ordentlicher gemacht! :wink:
Da waren noch ein paar Überbleibsel für die ESP-Programmierung drin.

1 Like
9

Sehr schön Danke :wink:
Nur warum hängt der ADS nicht am I2C?

10

Hallo,

eine consts.h kannst du ja machen, spricht nichts dagegen. Solange darin wirklich nur Konstanten landen und es keine Müllhalde wird. :wink: Mit sowas lagert man Code aus um mehr Übersicht im Hauptprogramm zubekommen. Das Gleiche macht man mit Klassen wie deiner ADS1115Reader. Wobei es dabei hauptsächlich um Datensicherheit, Datenkappselung und Zugriffsschutz geht und eben Wiederverwendung.

Ich sehe aber soeben in deiner consts.h diverse Umgereimtheiten bezüglich I2C und SPI.
SDA und SCL liegen auf Pin 20, 21. Das ist ein Bus den man wiederverwenden kann.

Die Serialen Bausteine kannste auf die USARTs verteilt lassen, macht Sinn.

Wenn der FRAM und ADS1115 mit SPI arbeitet, dann ist das auch ein Bus der wiederverwendet werden kann. Nur die CS Leitung muss separat sein.

Es sind zumindestens einige Bezeichnungen Überarbeitungswürdig.

11

Ist reiner I2C Baustein.

12

Hallo,

okay, dann hat er für mich auf dem SPI Bus nichts zu suchen. :grinning:

13

Und für das FRAM muss Software SPI genutzt werden :joy:

14

Ja, HUCH!
Da können sich tatsächlich Fehler bei der Umstellung von
einem UNO auf den MEGA ergeben haben.
Durch noobsames: "Einfach an die gleiche Pinnummer stecken"!
:woozy_face:

15

Warum?

16

Sorry Uno hat die Pins nicht :wink:
Ok kann passieren, deshalb nochmal Kontrollieren damit danach keine böse Überraschung kommt.

1 Like
17

So wie gezeichnet schon :wink: Das meinte ich.

18

Hmmm, ich bekommen aber Daten rein?
Hab hier n Versuchsaufbau mit nem Poti gebaut und
den aus Wolles examples zurechtgedengelten Sketch, auf dem MEGA laufen lassen.
Oder meinst Du eher: "Man kann ein Bobby-Car durch ein 100qm großes Tor fahren,
man kann auch die Schlupftür nehmen"?

19

Hallo,

ich kann dir aktuell nicht ganz folgen. Ich verwende immer wenn irgendwie möglich den passenden Hardwarebus. Wenn du I2C ICs an SPI Pins verwendest muss das ja Software I2C sein. Klar geht das nur für sinnvoll halte ich das nicht wenn der Hardwarebus zur Verfügung steht.

20

Wenn Du schon so lachst: Soll ich lieber sein lassen?
Ich kann eben noch nicht abschätzen wie viele bits ich so sammeln muss
um die Waage Kalibriert zu bekommen.