GCC für ARM Probleme mit "new" ?

[Holger T. (holger1979)]

Hallo,

ich habe hier ein größeres Problem der OOP und komme einfach nicht 
weiter.
Da ich vermute, dass es mit dem GCC Compiler für ARM zusammenhängen 
könnte, schreibe ich es unter Mikrocontroller.
Ich versuche das mal vereinfacht darzustellen.

Ich habe eine Klasse, die von mehreren Basisklassen erbt. Von dieser 
Klasse möchte ich mehrere Objekte erzeugen können.
Sowohl meine Klasse als auch die Basisklassen benötigen alle ein Handle 
für die einzelnen Methoden.
Dieses Handle wird global erzeugt und wird im Konstruktor als Pointer an 
meine Klasse übergeben und von dort aus wird der Pointer des Handle an 
die Basisklassen weitergegeben.

Hier mal eine Basisklasse:

#include <Namespace/Basisklasse.h>

namespace Namespace
{

Basisklasse::Basisklasse(TIM_HandleTypeDef *handle)
{
       pHandle = handle;
       // do Something
}

} /* namespace Namespace */

Dazu die meine Klasse:

#include <Namespace/MeineKlasse.h>

namespace Namespace
{

MeineKlasse::MeineKlasse(TIM_HandleTypeDef *handle) :
             Basisklasse(handle), Basisklasse2(handle), ... , BasisklasseN(handle)
{
       pHandle = handle;
}

} /* namespace Namespace */

pHandle ist jeweils ein Pointer auf den Handle. Dieser wird 
durchgereicht.
Soweit so gut.

Jetzt muss ich die Handle anlegen. Hier mache ich eine Deklaration im 
Header-File:

class Configuration
{
private:
TIM_HandleTypeDef htim1_switch;
...

Dieser Handle wird dann in einem Konstruktor initialisiert:

Configuration::Configuration()
{
       htim1_switch.Instance = TIM1;
...

Das Problem:
Ich muss jetzt Objekte der Timerklassen erzeugen, wobei ich den bereits 
konfigurierten Handle übergeben muss:
switch(&htim1_switch) ergibt: no match for call to 
'(Namespace::MeineKlasse) (TIM_HandleTypeDef*)'
switch = new MeineKlasse(&htim1_switch) ergibt: no match for 'operator=' 
(operand types are 'Namespace::MeineKlasse' and 
'Namespace::MeineKlasse*')

Weiterhin sollen die Timerobjekte außerhalb des Konstruktors natürlich 
erhalten bleiben.
Als Compiler verwende ich einen GCC für ARM. Kennt der vielleicht kein 
"new" ?

Kann mir da Jemand weiterhelfen?

Vielen Dank!!!

[Jörg W. (dl8dtl) (Moderator)]

Holger T. schrieb:
> Kennt der vielleicht kein "new" ?

Der Compiler kennt es, aber du musst (je nach Umgebung, die dir ggf.
durch IDE etc. vorgegeben wird) u. U. das Backend für malloc()
selbst bereitstellen (die Funktion _sbrk()).

"No match" stammt vom Compiler, da fehlt ihm also irgendeine passende
Deklaration (in einem Headerfile).

Bist du dir sicher, dass du innerhalb von Namespace {} nochmal
"Namespace::" schreiben wolltest?  Übermäßig gut kenne ich micht mit
C++ auch nicht aus, aber das sieht mir suspekt aus.

[Holger T. (holger1979)]

Oh, vielen Dank. Sollte natürlich Basisklasse heißen und nicht 
Namespace. Habs geändert.  ;)

Ich suche mal, wo ich das "new" her bekomme.
Du könntest Recht haben, dass der das vermisst.

Vielen Dank schonmal!

[Oliver S. (oliverso)]

Die Fehlermeldung klingt nicht nach fehlendem new. Da gäbs eine 
Fehlermeldung vom linker.

Allerdings ist switch ein Schlüsselwort in C++ ...

Oliver

[Bolko (Gast)]

Kannst Du ein Mickeymausbeispiel wie unten bauen? Was 
handle/timer/switch/Timerklasse usw. sind, wird aus der Beschreibung 
nicht ganz klar und deine Fehlerzeilen fehlen in den Codeausschnitten. 
Und warum man unbedingt new braucht, ist auch nicht klar.

#include <iostream>

class TIM_HandleTypeDef
{
public:
    TIM_HandleTypeDef(int ix) : name(ix)
    {
    }

    void do_thing(int i)
    {
        std::cout << "handle #" << name << " sagt " << i << "\n";
    }
private:
    int name;
};


class Basisklasse1
{
public:
    Basisklasse1(TIM_HandleTypeDef *handle)
    {
           pHandle = handle;
    }
    virtual void doit()
    {
        pHandle->do_thing(111);
    }
private:
    TIM_HandleTypeDef *pHandle;
};


class Basisklasse2
{
public:
    Basisklasse2(TIM_HandleTypeDef *handle)
    {
           pHandle = handle;
    }

    virtual void whatever()
    {
        pHandle->do_thing(222);
    }

private:
    TIM_HandleTypeDef *pHandle;
};


class MeineKlasse : public Basisklasse1, public Basisklasse2
{
public:
    MeineKlasse(TIM_HandleTypeDef *handle) : Basisklasse1(handle), Basisklasse2(handle)
    {
    }
};

class Configuration
{
public:
    Configuration() : htim1_switch(42)
    {
    }

    TIM_HandleTypeDef* get_handle()
    {
        return &htim1_switch;
    }

private:
    TIM_HandleTypeDef htim1_switch;
};


int main()
{
    Configuration config;
    MeineKlasse mainz(config.get_handle());
    mainz.whatever();
    mainz.doit();
}

[Holger T. (holger1979)]

Der Quellcode ist noch wesentlich komplexer mit vielen Schaltern und 
vielen Timern. Den Namen "switch" habe ich als Synonym für einen 
beliebigen "Schalter" verwendet. Im Originalcode gibt es aber den Namen 
"switch" nicht. Daran liegt es nicht.

Es gibt im Prinzip einige Basisklassen und meine Klassen (Es sind Timer 
die Pins schalten). Wobei abhängig vom Timer jede meiner Klasse von 
anderen Basisklassen erbt.

Dadurch wird das Ganze so kompliziert.

Was nicht geht ist ein Objekt von "MeineKlasse" anzulegen.
Ganz grob gibt es eine Singletonklasse, diese erstellt im Konstruktor 
mehrere Instanzen von mehreren verschiedenen Klassen. Diese Klassen 
unterscheidet, von welchen Basisklassen diese erben.

Hier gibt es zwei Probleme. Wenn der Konstruktor durch ist sind die 
Objekte wider weg. Und das Aufrufen der Konstruktoren führt zu 
Fehlermeldungen.

Am liebsten würde ich die Struktur jetzt Global anlegen. Da gibt es aber 
das Problem, dass bei der Deklaration im Headerfile bereits ein 
Konstruktor ohne Parameter aufgerufen wird.

[Jörg W. (dl8dtl) (Moderator)]

Holger T. schrieb:
> dass bei der Deklaration im Headerfile bereits ein Konstruktor ohne
> Parameter aufgerufen wird.

Nein, eine Deklaration "ruft" keinen Konstruktor.

Ein globales (oder statisches) Objekt ruft einen Konstruktor während
der Initialisierung der Applikation, also noch vor main().  Aber das
muss man erstmal definieren, nicht nur seine Klasse deklarieren.

> Wenn der Konstruktor durch ist sind die Objekte wider weg.

Kann auch so nicht sein, da ist noch was anderes foul.

[A. H. (ah8)]

Eine Sache vorneweg: Wie viele pHandle hast Du in Deiner 
Klassenhierarchie? Hat jede Klasse ihr eigenes Handel oder nur die 
Basisklasse? Wenn es nur die Basisklasse ist musst Du es auch nur dort 
initialisieren, und das mach man besser mit der initializer-Syntax:

Basisklasse::Basisklasse(TIM_HandleTypeDef *handle) : pHandle(handle)
{
       // do Something
}
MeineKlasse::MeineKlasse(TIM_HandleTypeDef *handle) : Basisklasse(handle) ...
{
       // do Something
}

In der abgeleiteten Klasse genügt es, die Basisklasse zu initialisieren, 
es sei denn, diese definiert ihr eigenes pHandle Objekt, in dem Fall 
dann

MeineKlasse::MeineKlasse(TIM_HandleTypeDef *handle) : Basisklasse(handle) … , pHandle(handle)
{
       // do Something
}

Des weiteren fehlt, wie oben schon gesagt wurde, die vollständige 
Code-Zeile, die den Fehler verursacht. Ich unterstelle mal, sie sieht 
irgendwie so aus:

Namespace::MeineKlasse switch(&htim1_switch);

Wie auch schon gesagt ist switch ein Schlüsselwort und das würde ich 
grundsätzlich vermeiden (zumindest testweise), auch wenn es hier nicht 
das Problem zu sein scheint. Für mich klingt die Fehlermeldung so, als 
findet der Compiler den passenden Konstruktor nicht. Du hast zwar oben 
eine Definition angegeben, aber ist er auch innerhalb der 
Klassendefinition deklariert?

class MeineKlasse
{
        public:
                MeineKlasse(TIM_HandleTypeDef *); // ist diese Zeile da?
};

Falls diese Deklaration fehlt müsste allerdings auch die Übersetzung der 
von Dir angegebenen Definition mit einer ähnlichen Fehlermeldung 
scheitern.

[A. H. (ah8)]

Holger T. schrieb:
> Hier gibt es zwei Probleme. Wenn der Konstruktor durch ist sind die
> Objekte wider weg.

Das ist natürlich klar. In einer Funktion (und ein Konstruktor ist 
letztlich auch nur eine Funktion) lokal angelegte Objekte existieren nur 
bis zum Verlassen der Funktion. Das Verwenden von Zeigern oder 
Referenzen auf lokale Objekte über die Laufzeit der Funktion hinaus 
führt definitiv zu undefiniertem Verhalten. Es sei denn, die Objekte 
werden statisch angelegt. Das würde ich aber nicht unbedingt im 
Konstruktor machen. Ein static class member wäre in diesem Fall 
vielleicht eine geeignete Lösung.

[Vincent H. (vinci)]

Ich glaub immer noch, dass die erste Antwort richtig is...
Wenn der Threadersteller von _sbrk und Co nichts weiß, dann hats was. 
Die newlib-nano enthält halt schlichtweg keine Standard C++ 
Implementierung der ganzen System Calls.

[Jörg W. (dl8dtl) (Moderator)]

Vincent H. schrieb:
> Wenn der Threadersteller von _sbrk und Co nichts weiß, dann hats was.

Das bringt aber einen Linkerfehler, keinen des Compilers.

[Holger T. (holger1979)]

Ich habe jetzt folgendes versucht:

In der Headerdatei der Singleton-Klasse "Configuration" deklariere ich 
für jedes zukünftige Objekt einen Handle und das Objekt selbst.

TIM_HandleTypeDef handle_Schalter1;
MeineKlasse schalter1;

In der C-Datei in einer Init-Funktion (Configuration::Init()) 
initialisiere ich das Handle und das Objekt.

handle_Schalter1.Instance = TIM1;
MeineKlasse schalter1(&handle_Schalter1);

Für jedes Objekt, welches ich anlege gibt es eine Fehlermeldung im 
Konstruktor "Configuration".

Configuration::Configuration() // Hier werden die Fehler angezeigt
{
}

Die Meldung lautet:
no matching function for call to 'Namespace::MeineKlasse::MeineKlasse()'
 Configuration::Configuration()

Also irgendwie will der Compiler im Konstruktor Configuration() meine 
Klassen jeweils mit einem Standardkonstruktor aufrufen. Ich kann mir 
aber leider nicht erklären warum.

[Jörg W. (dl8dtl) (Moderator)]

Zimmere doch bitte mal ein minimales compilierbares (bzw. eben
nicht compilierbares) Beispiel.

Irgendwie werde ich das Gefühl auch nicht los, dass das alles mächtig
„von hinten durch die Brust ins Auge“ gezimmert ist, aber warum du
die Architektur so gewählt hast, wirst du sicher selbst wissen.

[Holger T. (holger1979)]

Ich habe jetzt mal den Code auf ein Minimum reduziert.

Hier ist die CPP-Datei der Klasse Configuration:

#include "Namespace/Configuration.h"

namespace Namespace
{

// Getting instance of class
Configuration& Configuration::getInstance()
{
  static Configuration instance;
  return instance;
}

Configuration::Configuration() // Hier im Konstruktor wird der Fehler angezeigt
{

}

void Configuration::TimerInit()
{
  htim1_highSideA.Instance = TIM1;
  htim2_stimTimeBase.Instance = TIM2;
  htim3_lowSideA.Instance = TIM3;
  htim4_lowSideB.Instance = TIM4;
  htim5_adcControl.Instance = TIM5;
  htim8_highSideB.Instance = TIM8;
  htim9_rangeSelect.Instance = TIM9;

// Folgende Zeilen gehen nicht, weil der Compiler "new" nicht moechte
//  highSideA = new TimerSlaveOCBreak(&htim1_highSideA);
//  stimTimeBase = new TimerUseMaster(&htim2_stimTimeBase);
//  lowSideA = new TimerMasterSlaveOC(&htim3_lowSideA);
//  lowSideB = new TimerMasterSlaveOC(&htim4_lowSideB);
//  adcControl = new TimerMasterSlaveOC(&htim5_adcControl);
//  highSideB = new TimerSlaveOCBreak(&htim8_highSideB);
//  rangeSelect = new TimerBase(&htim9_rangeSelect);

// Darum alternativ so:
  TimerSlaveOCBreak highSideA(&htim1_highSideA);
  TimerUseMaster stimTimeBase(&htim2_stimTimeBase);
  TimerMasterSlaveOC lowSideA(&htim3_lowSideA);
  TimerMasterSlaveOC lowSideB(&htim4_lowSideB);
  TimerMasterSlaveOC adcControl(&htim5_adcControl);
  TimerSlaveOCBreak highSideB(&htim8_highSideB);
  TimerBase rangeSelect(&htim9_rangeSelect);
}

} /* namespace Namespace */

Hier der dazugehörige Header:

#ifndef __CONFIGURATION_H
#define __CONFIGURATION_H

#include "stm32f2xx_hal.h"
#include "stm32f2xx_hal_tim.h"
#include "STM32F215xx.h"

#include "Namespace/MeineKlasse.h"

namespace Namespace
{
  
class Configuration
{
private:
TIM_HandleTypeDef handle;
MeineKlasse schalter;

public:
Configuration();

static Configuration& getInstance();

void TimerInit(void);
};

} /* namespace Namespace */

#endif /* __CONFIGURATION_H */

Hier die CPP einer Basisklasse:

#include <Namespace/Basisklasse1.h>

namespace Namespace
{

Basisklasse1::Basisklasse1(TIM_HandleTypeDef *handle)
{
  pHandle = handle;
}

Basisklasse1::~Basisklasse1()
{
}

} /* namespace Namespace */

Der dazugehörige Header:

#ifndef INCLUDE_BASISKLASSE1_H_
#define INCLUDE_BASISKLASSE1_H_

#include "stm32f2xx_hal.h"
#include "stm32f2xx_hal_tim.h"

namespace Namespace
{

class Basisklasse1
{
private:
  TIM_HandleTypeDef *pHandle;

public:
  Basisklasse1(TIM_HandleTypeDef *handle);

  virtual ~Basisklasse1();
};

} /* namespace Namespace */

#endif /* INCLUDE_BASISKLASSE1_H_ */

Meine Klasse, die von der Basisklasse erbt (CPP):

#include <Namespace/MeineKlasse1.h>

namespace Namespace
{

MeineKlasse1::MeineKlasse1(TIM_HandleTypeDef *handle) :
    Basisklasse1(handle)
{
  pHandle = handle;
}

MeineKlasse1::~MeineKlasse1()
{
}

} /* namespace Namespace */

Und der zugehörige Header:

#ifndef INCLUDE_MEINEKLASSE1_H_
#define INCLUDE_MEINEKLASSE1_H_

#include "stm32f2xx_hal.h"
#include "stm32f2xx_hal_tim.h"

#include <Namespace/Basisklasse1.h>

namespace Namespace
{

class MeineKlasse1 : public Basisklasse1
{
private:
  TIM_HandleTypeDef *pHandle;

public:
  MeineKlasse1(TIM_HandleTypeDef *handle);

  virtual ~MeineKlasse1();
};

} /* namespace Namespace */

#endif /* INCLUDE_MEINEKLASSE1_H_ */

Der Fehler wird im Konstruktor Konfiguration() angezeigt:
no matching function for call to 
'Namespace::MeineKlasse1::MeineKlasse1()'
 Configuration::Configuration()

[Ralf G. (ralg)]

Jörg W. schrieb:
> Zimmere doch bitte mal ein minimales compilierbares (bzw. eben
> nicht compilierbares) Beispiel.

... soll hier im mikrocontroller.net bedeuten: Ein vollständiges, 
minimalistisches Programm, welches fast nichts weiter als den Fehler 
enthält. Am besten nur eine Datei als Anhang.

[Jörg W. (dl8dtl) (Moderator)]

Holger T. schrieb:
> Ich habe jetzt mal den Code auf ein Minimum reduziert.

Da fehlen mir jetzt immer noch all die STM32-Headers dafür.

Kannst du die nicht irgendwie rauskicken und durch irgendwas
abstraktes "simulieren"?


> // Folgende Zeilen gehen nicht, weil der Compiler "new" nicht moechte
> //  highSideA = new TimerSlaveOCBreak(&htim1_highSideA);
> //  stimTimeBase = new TimerUseMaster(&htim2_stimTimeBase);

Jetzt weiß ich zumindest, woher deine Überschrift des Threads kommt.

Aber deine blumige Ausdrucksweise hilft nicht weiter.  Warum sollte
der Compiler "new" denn "nicht mögen"?  Welche Fehlermeldung bekommst
du denn?

Wie schon geschrieben worden ist, das Backend für new ist ein
schnödes malloc(), und dieses wiederum setzt in der newlib typisch
auf _sbrk() auf, welches du als Anwender liefern musst.

Mit der newlib nano habe ich noch nicht viel gemacht, aber musst du
die denn benutzen, kannst du nicht auch die Standard-newlib nehmen?

> Der Fehler wird im Konstruktor Konfiguration() angezeigt:

Bei welcher Compiler-Kommandozeile?

Sorry, es sind zwar schon viele Stückchen da, aber nichts, was ich
hier unabhängig von deiner Umgebung auch mal bei mir ausprobieren
könnte.

[Eric B. (beric)]

Holger T. schrieb:
> // Folgende Zeilen gehen nicht, weil der Compiler "new" nicht moechte
> //  highSideA = new TimerSlaveOCBreak(&htim1_highSideA);

Wo und wie ist highSideA in diesem Fall deklariert?

> // Darum alternativ so:
>   TimerSlaveOCBreak highSideA(&htim1_highSideA);

Jörg W. schrieb:
> Irgendwie werde ich das Gefühl auch nicht los, dass das alles mächtig
> „von hinten durch die Brust ins Auge“ gezimmert ist,

Mja, geht mir auch so.

[Holger T. (holger1979)]

Meine Configuration.cpp muss so aussehen:

#include "Namespace/Configuration.h"

namespace Namespace
{

// Getting instance of class
Configuration& Configuration::getInstance()
{
  static Configuration instance;
  return instance;
}

Configuration::Configuration() // Hier im Konstruktor wird der Fehler angezeigt
{

}

void Configuration::TimerInit()
{
  handle.Instance = TIM1;

// Folgende Zeile geht nicht, weil der Compiler "new" nicht moechte
//  meineKlasse1 = new MeineKlasse1(&handle);

// Darum alternativ so:
  MeineKlasse1 meineKlasse1(&handle);
}

} /* namespace Namespace */

Das obige Beispiel hat noch nicht die Namen angepasst und war nicht 
minimal.

Es handelt sich um eine Konfiguration, eine Basisklasse und eine 
abgeleitete Klasse. Jeweils mit cpp und h-file.
Das ist jetzt wirklich das Minimum.

[Dr. Sommer (Gast)]

Hier gibt es ein Beispiel, wie man dem GCC "malloc" beibringt, und 
dadurch auch "new" :

STM32 Eclipse JLink Linux/Windows: Optional: Syscalls implementieren

Was auch manchmal hilft ist
#include <new>

[Holger T. (holger1979)]

Hallo,

bei der Verwendung von "new" erhalte ich folgende Fehlermeldung:
no match for 'operator=' (operand types are 'Namespace::Meineklasse1' 
and 'Namespace::Meineklasse1*')
  meineKlasse1 = new MeineKlasse1(&handle);

Der Compileraufruf wird folgendermaßen aufgerufen:
arm-none-eabi-g++ -mcpu=cortex-m3 -mthumb -Og  -fmessage-length=0 
-fsigned-char  -ffunction-sections  -fdata-sections -Wl,-gc-sections 
-DDEBUG -DUSE_FULL_ASSERT  -DTRACE -DSTM32F215xx -DUSE_HAL_DRIVER 
-DHSE_VALUE=8000000 -Wall -Wextra -g3

Auch mir kommt das Ganze wie von hinten durch die Brust geschossen vor, 
aber es muss doch eine Lösung geben.
Das Schwierige ist eben, dass die Objekte zum Anlegen bereits ein 
konfiguriertes Handle benötigen. Daher kann ich die Objekte zum 
Programmstart leider noch nicht anlegen.

[Ecki K. (eck)]

Wie ist meineKlasse1 deklariert? Von der Fehlermeldung her sieht aus als 
wenn's

Namespace::Meineklasse1 meineKlasse1 ist, und nicht

Namespace::Meineklasse1 *meineKlasse1.

Der Compiler beschwert sich, dass er einer nicht-Pointer-Variable einen 
Pointer zuweisen soll.

[Jörg W. (dl8dtl) (Moderator)]

Holger T. schrieb:
> Hallo,
>
> bei der Verwendung von "new" erhalte ich folgende Fehlermeldung:
> no match for 'operator=' (operand types are 'Namespace::Meineklasse1'
> and 'Namespace::Meineklasse1*')
>   meineKlasse1 = new MeineKlasse1(&handle);

Dann musst du einen Zuweisungsoperator implementieren (also sowohl
deklarieren als auch definieren).

Die Fehlermeldung ist auch suspekt: links steht eine Klasse, rechts
ein Zeiger auf die Klasse?

Eventuell hilft es auch schon, wenn du den Konstruktor anders
schreibst:

class MeineKlasse1 : public Basisklasse1
{
private:
  TIM_HandleTypeDef *pHandle;

public:
  MeineKlasse1(TIM_HandleTypeDef *handle):
    Basisklasse1(handle),
    pHandle(handle)
  {};

  virtual ~MeineKlasse1();
};

Also für pHandle die Konstruktor-Syntax statt einer Zuweisung
nehmen, und eigentlich kann das dann auch gleich inline in den
Header.

> Der Compileraufruf wird folgendermaßen aufgerufen:
> arm-none-eabi-g++ -mcpu=cortex-m3 -mthumb -Og  -fmessage-length=0
> -fsigned-char  -ffunction-sections  -fdata-sections -Wl,-gc-sections
> -DDEBUG -DUSE_FULL_ASSERT  -DTRACE -DSTM32F215xx -DUSE_HAL_DRIVER
> -DHSE_VALUE=8000000 -Wall -Wextra -g3

Da fehlt der Name der C++-Datei.  Das wäre eine der Fragen gewesen,
welche Datei ich hier überhaupt compilieren muss, um dein Problem
nachzuvollziehen.  Aber wie oben schon geschrieben, es gibt in deinem
Beispiel noch so viele Dinge, die ich hier nicht herumliegen habe,
dass ich das ohnehin nicht selbst probieren kann.

[Torsten R. (Firma: Torrox.de) (torstenrobitzki)]

Holger T. schrieb:

> Dieses Handle wird global erzeugt und wird im Konstruktor als Pointer an
> meine Klasse übergeben und von dort aus wird der Pointer des Handle an
> die Basisklassen weitergegeben.

Pointer auf Handle? Das klingt erst einmal total schräg, da ein Handle 
üblicherweise schon so etwas wie ein Pointer ist. Ein Handle sollte auf 
jeden Fall folgende Eigenschaften haben:
 - klein
 - leicht zu kopieren

> Hier mal eine Basisklasse:
> Basisklasse::Basisklasse(TIM_HandleTypeDef *handle)
> {
>        pHandle = handle;
> }

benutze doch Initialisierung, wenn Du initialisieren möchtest:

Basisklasse::Basisklasse(TIM_HandleTypeDef *handle)
  : pHandle( handle )
{
}

Ok, ich nehme alles zurück, TIM_HandleTypeDef ist sicher kein handle. ST 
ist sich aber auch keine gute Quelle um Software-Entwicklung zu lernen 
;-)

Wenn handle nie 0 sein sollte, dann zwingt sich ggf. eine Referenz auf 
(oder sogar eine const reference).

Ich fänd' dass "timer" ein passenderer Name wäre.

> Das Problem:
> Ich muss jetzt Objekte der Timerklassen erzeugen, wobei ich den bereits
> konfigurierten Handle übergeben muss:
> switch(&htim1_switch) ergibt: no match for call to
> '(Namespace::MeineKlasse) (TIM_HandleTypeDef*)'

Wo kommt jetzt switch her? switch ist ein reserviertes Wort in C++.

> switch = new MeineKlasse(&htim1_switch) ergibt: no match for 'operator='
> (operand types are 'Namespace::MeineKlasse' and
> 'Namespace::MeineKlasse*')

Ja, auf der linken Seite steht so etwas int und auf der rechten Seite so 
etwas wie int*. Passt nicht! Ansonsten code, den Du im Forum zeigen 
möchtest immer kopieren, nie abschreiben (siehe htim1_switch/switch)!

> Kann mir da Jemand weiterhelfen?

Bei Fehlermeldungen immer ganz genau hin gucken. In der Regel steht da 
schon, was das Problem ist. In Deinem Fall, versuchst Du halt eine 
Initialisierung oder Zuweisung mit nicht kompatiblen Typen.

mfg Torsten

[Mark B. (markbrandis)]

Jörg W. schrieb:
> aber warum du die Architektur so gewählt hast, wirst du sicher selbst
> wissen.

Komische Software-Architekturen entstehen bisweilen auch und gerade 
deshalb, weil jemand nicht so genau weiß, was er da tut. ;-)

[Torsten R. (Firma: Torrox.de) (torstenrobitzki)]

Holger T. schrieb:
> Configuration& Configuration::getInstance()

Juhu ein Singleton! :'(

> {
>   static Configuration instance;
>   return instance;
> }
>
> Configuration::Configuration() // Hier im Konstruktor wird der Fehler
> angezeigt
> {

Genau: Configuration hat ein MeineKlasse1 als member. Und MeineKlasse1 
hat keinen default c'tor mit dem die Instanz von MeineKlasse1 
initialisiert werden kann.

Vererbung ist so ziemlich die stärkste Kopplung, die man haben kann. 
Bist Du Dir sicher, dass Du Dir das antun möchtest?

[Holger T. (holger1979)]

Habe eine Lösung gefunden!   :-)   :-)

Mir wurde mitgeteilt, dass die angebliche Deklaration im Headerfile in 
wirklichkeit schon den Konstruktor aufruft. Und zwar den 
Standardkonstruktor.

Mir wurde auch empfohlen daraus Pointer zu machen.
In der Initialisierung hat dann das "new" plötzlich funktioniert.

Die Objekte werden jetzt also dynamisch angelegt und die Pointer sorgen 
dafür, dass ich weiß wo ich hin schreibe.

Dies steht im Headerfile:

TIM_HandleTypeDef handle1;
MeineKlasse1* schalter1;

Und die Implementierung:

handle1.Instance = TIM1;
schalter1 = new MeineKlasse1(&handle1);

Und siehe da, es läuft jetzt. Zumindest kompiliert er, den Rest muss ich 
noch testen. :-)

Vielen Dank für die vielen Posts! Ich konnte viel lernen.

[Torsten R. (Firma: Torrox.de) (torstenrobitzki)]

Holger T. schrieb:
> Mir wurde auch empfohlen daraus Pointer zu machen.
> In der Initialisierung hat dann das "new" plötzlich funktioniert.

Schauder :-|

> Die Objekte werden jetzt also dynamisch angelegt und die Pointer sorgen
> dafür, dass ich weiß wo ich hin schreibe.

Der ganze HeckMac, damit Du dieses Singleton Antipattern verwenden 
kannst?

[Holger T. (holger1979)]

Jetzt müssen noch die Werte gesetzt werden. Da weigert sich noch wer.
Wenn ich folgende Zeile habe:

htim->Instance->CR2 |= sMasterConfig->MasterOutputTrigger;

Dann erwarte ich eigentlich, dass der Wert vom MasterOutputTrigger (hier 
32) auch in die Variable OR-Verknüpft wird.

htim->Instance->CR2 bleibt aber 0.

Wobei htim auf 0x20000284 zeigt und htim->Instance auf 0x40000000.

[Mark B. (markbrandis)]

Holger T. schrieb:
> htim->Instance->CR2 bleibt aber 0.

Was je nach Bitmuster auch durchaus ein korrektes Ergebnis sein kann.

Hast Du einen Debugger, mit dem Du das Programm mal durchsteppen kannst? 
Dann mach das. Zum Beispiel gibt es den GDB auch für ARM.

[Holger T. (holger1979)]

Ich habe mich da durchgestepped.

htim->Instance-CR2 ist vorher 0. (Das könnte i.O. sein)

Wenn dann aber

htim->Instance->CR2 |= sMasterConfig->MasterOutputTrigger;

aufgerufen wird, und sMasterConfig->MasterOutputTrigger ist dabei 32, 
dann müsste dies durch die ODER-Verknüpfung eigentlich in der Struktur 
stehen.

Es bleibt aber weiterhin 0.

Vielleicht stelle ich das Problem später ins Forum unter einem anderen 
Namen. Mit dem Ursprungsproblem hat das ja nichts mehr zu tun.

[Robert S. (robert_s68)]

Holger T. schrieb:
> Mir wurde mitgeteilt, dass die angebliche Deklaration im Headerfile in
> wirklichkeit schon den Konstruktor aufruft. Und zwar den
> Standardkonstruktor.
>
> Mir wurde auch empfohlen daraus Pointer zu machen.
> In der Initialisierung hat dann das "new" plötzlich funktioniert.
>
> Die Objekte werden jetzt also dynamisch angelegt und die Pointer sorgen
> dafür, dass ich weiß wo ich hin schreibe.

vom "new" gibt es zwei Varianten:

die "normale" Version holt sich dynamischen Speicher für die Größe des 
zu erzeugenden Objekts, ruft den Konstruktor auf, und retourniert einen 
Zeiger auf das erzeugte Objekt

die "placement" Version bekommt einen Pointer mit, ruft den Konstruktor 
auf, und retourniert den Zeiger auf das erzeugte Objekt. Kommt im 
"normalen" Leben eher selten vor, Anwendungen sind IMHO auf 
Optimierungen oder Spezialfälle (Container) beschränkt.

"new" ist also quasi synonym mit "Objekt ist dynamisch angelegt". Man 
kann zwar "placement new" auf eine lokale oder statische Variable 
anwenden, also sowas wie "Objekt o; new(o) Objekt;", das hat aber keinen 
Sinn, sollte m.E. ein Error sein, und mir ist in über 20 Jahren C++ 
sowas noch nicht untergekommen, daher bin ich mir auch ob der 
syntaktischen Korrektheit nicht sicher.

auf alle Fälle:

Objekt o = new Objekt; // ist falsch

Objekt* o2 = new Objekt; // richtig

sonst noch aufgefallen:

* Ein Singleton sollte man eigentlich vermeiden, zur Repräsentation von 
Hardware mags ja Berechtigung haben, dann kann man das aber anders 
implementieren, so dass man ohne das dauernde "getInstance" auskommt. 
Grund für virtuelle Methoden etc... gibts bei einem solchen Singleton eh 
per Definition nicht, das muss alles zur Compile-Zeit feststehen.

* Mehrfach von verschiedenen Basisklassen zu erben, die dann alle einen 
Zeiger auf das selbe Handle vorrätig halten, verschwendet Platz. 
Virtuelle Basis-Klasse zum Handle-Speichern würde gehen, hat aber 
möglicherweise andere Nachteile.

* Eleganter geht sowas mit templates und dem "CRTP", also sowas a la

template <class C>
class Basis
{
public:
  Basis() {};
  do_something() {C.getTimer()->start();}
}

class Klasse
: public Basis<Klasse>
{
public:
  Klasse() {m_timer = new Timer();};
  Timer* getTimer() { return &m_timer; }

private:
  Timer* m_timer;
}

* Das speichert das Handle nur einmal
* Basisklassen kann man viele machen
* Zusammengestrickt wird alles erst in der konkreten "Klasse", und zwar 
schon zur Compile-Zeit, es gibt also keinen Laufzeit-Overhead

addendum: das "new Timer" ist nur ein Beispiel, das brauchts so auch 
nicht.

[Ralf G. (ralg)]

Holger T. schrieb:
> Dies steht im Headerfile:

TIM_HandleTypeDef handle1;

Eine Definiton im Headerfile??