Klassen für Mikrocontroller

[Kai H. (Gast)]

Nabend,
wenn ihr fertige Module benutzt (z.B. RFID-Modul, Sensor-Module), 
schreibt ihr dafür einzelne Funktionen in C? oder erstellt ihr Klassen 
in C++, die dann benutzt werden?

[Vincent H. (vinci)]

Weder noch und beides. Das hängt stark vom Modul ab. Ein Flash oder 
EEPROM etwa würde ich zum Beispiel wohl kaum als Klasse anlegen, da 
einfach viel zu simpel. Mehr als lesen und schreiben is da nicht.

Ein RFID Modul etwa hätte vermutlich je nach Anwendung schon die 
Möglichkeit als Klasse zu enden...

[Dr. Sommer (Gast)]

Vincent H. schrieb:
> Mehr als lesen und schreiben is da nicht.
Das heißt ja nix. Sobald es irgendwie Sinn macht dass mehr als ein Modul 
angeschlossen werden könnte (z.B. mehrere EEPROM's des gleichen Typs 
über I²C) macht es schon Sinn das in eine Klasse zu packen. Dann kann 
man über Member-Variablen identifizieren, welche Instanz man meint. So 
ala:

class EEPROM {
  private:
    uint8_t m_moduleAddress;
  public:
    EEPROM (uint8_t moduleAddress) : m_moduleAddress (moduleAddress) {}
    uint8_t read (uint32_t memoryAddress) {
      /* lese von Adresse memoryAdress vom I²C-Modul m_moduleAdress */
    }
    void write (uint32_t memoryAddress, uint8_t data) {
      /* lese an Adresse memoryAdress vom I²C-Modul m_moduleAdress */
    }
};

int main () {
  EEPROM mem1 (42);
  EEPROM mem2 (84);
  
  mem2.write(1, mem2.read (2));
}

Schlau wäre es u.U. noch die gewünschte I²C-Peripherie mit an den 
Kontruktor zur übergeben, für uC's die mehrere haben.

[Vincent H. (vinci)]

Ja, da würde es dann schon mehr Sinn machen...
Wobei man grad bei I²C auf modernen µCs relativ viele Interrupt-Quellen 
haben kann die dann wieder etwas mühsam zu handhaben sind.

Ich wollt ein simples EEPROM eigentlich nur als Beispiel hernehmen, dass 
man oft nicht perse sagen kann ob eine Klasse dafür mehr Sinn macht.

[Frank (Gast)]

Vincent H. schrieb:
> Ein Flash oder EEPROM etwa würde ich zum Beispiel wohl kaum als Klasse
> anlegen, da einfach viel zu simpel. Mehr als lesen und schreiben is da
> nicht.

Erkläre das mal den ganzen SD und SSD Herstellern. Die lachen dich wegen 
so einer Aussage nicht nur einmal aus. Und das zu recht.

Dr. Sommer schrieb:
> Schlau wäre es u.U. noch die gewünschte I²C-Peripherie mit an den
> Kontruktor zur übergeben, für uC's die mehrere haben.

So würde ich das auch machen. Der Flash Klasse wird eine Treiber Klasse 
bekannt gemacht mit einem definierten Interface. Dann wird es auch egal 
ob der Speicher per I2C, SPI oder parallel am uC hängt.

[Vincent H. (vinci)]

Frank schrieb:
> Vincent H. schrieb:
>> Ein Flash oder EEPROM etwa würde ich zum Beispiel wohl kaum als Klasse
>> anlegen, da einfach viel zu simpel. Mehr als lesen und schreiben is da
>> nicht.
>
> Erkläre das mal den ganzen SD und SSD Herstellern. Die lachen dich wegen
> so einer Aussage nicht nur einmal aus. Und das zu recht.

Wie viele SSD Projekte hast du denn in letzter Zeit hier im Forum 
gesichtet? Nona mein ich mit Flash keine 512GB SDD sondern eher 4MB NOR 
oder ähnliches.

Und SD? SD im Sinne von "SD-Card"? Könnt mich nicht erinnern schon 
einmal einen objektorientierten Treiber gesehn zu haben, stimme sonst 
aber zu. Das wäre definitiv etwas, dass zuerst ein Interface bekommt.

[Frank (Gast)]

Ich meinte das auch nicht auf die Verwendung von SD und SSD, sondern 
eher auf die "Einfachheit"  der Implementierung einer  Datenspeicherung 
bezogen. Wenn du einen nackten Baustein nimmst, ist das nicht nur lesen 
und schreiben. Da kommt noch einiges mehr dazu wie Daten Organisation, 
Daten Integrität, Wear Leveling, ...